> In my many years of experience doing software professionally, the serious bugs...
> This is not just a claim, this is my personal experience after about 23 years of programming where 90% of those years were spent using statically typed systems.
If most of your experience was with statically typed systems, it's just logical you would have very little experience with bugs that are prevented by statically typed systems - because this prevention would be at work. Looks like an opposite of survivor's fallacy, really.
>If most of your experience was with statically typed systems, it's just logical you would have very little experience with bugs that are prevented by statically typed systems
And then, when I used a dynamically typed language (Python) for serious stuff for the first time, I didn't miss those checks. Sincerely, the great majority of those "bugs that are prevented by statically typed systems" are bugs that only a novice programmer would make.
Moreover, a dynamically typed language with strong typing (Python & and many others) would prevent those bugs anyway; the only difference is that the check is done at runtime, not at compile-time. You do need to test the system at runtime anyways (no matter what language), so it isn't a big deal.
It's only dynamically typed languages with WEAK typing the ones that give "dynamically typed" a bad name. (In)famous examples: Javascript and PHP. Perhaps your experience of dynamically typed languages has been with Javascript?
> It's only dynamically typed languages with WEAK typing the ones that give "dynamically typed" a bad name. (In)famous examples: Javascript and PHP. Perhaps your experience of dynamically typed languages has been with Javascript?
Javascript, exactly.
I have to admit, Python have already been mentioned here a couple of times, so it seems that I have to try using it in some big project to get more experience on the matter.
Thanks for replying, because I didn't mean to be rude to you.
>Javascript, exactly.
Well, then consider you had experience with only one dynamically typed language, and one with a notoriously poor type system. Thus, you wrote: "But some people are still praising dynamically typed languages for their "speed" and "lack of compiler errors"."
If we consider "dynamically typed languages" == "Javascript", then your assertion is correct: Javascript isn't particularly fast (although it's decent in speed), and no, it doesn't help you prevent errors. But this is not because of it being "dynamically typed". It is because of many other things: Weakly typed, lack of good exception handling mechanism, lack of a good module/encapsulation system, and so on.
>Python have already been mentioned here a couple of times, so it seems that I have to try using it in some big project to get more experience on the matter.
Python is easy to learn and one of my favorites (i've used it extensively), but, however, it wouldn't be my candidate for "really good dynamically typed language". Python isn't too fast, it has some limitations for concurrency, it also has some awkward limitations for functional programming, it's OOP system isn't particularly great (but still, useful) and so on. But for example python brings something that neither Java nor C nor Javascript have and do help a lot in preventing errors: Named arguments (named function parameters.)
I like Python because it's fun/comfortable to use.
But If you want to explore really good dynamically typed languages, you should try taking a look at Common Lisp and Julia. Both of them have:
* Very strong typing
* A flexible type system
* Lots of data types (i.e. complex numbers, fractions, arbitrary length numbers)
* A very, very powerful OOP system (particularly Common Lisp... far more powerful than what you'd get on Java, C++, Objective-C or even Smalltalk)
* A decent package/module system
* Speed that can be tailored to get close to C
* Easy parallel and distributed computing (particularly Julia)
* Metaprogramming (particularly Common Lisp)
* Easy interop with C
Julia is modern and was inspired by Common Lisp. Common Lisp started in the mid '80s and it's still one of the most advanced languages you can find today. I'd say Julia is probably easier to learn and focused on scientific computing, and that CL is probably a bit more powerful and more general purpose.
Common Lisp also has an exception handling mechanism called "conditions and restarts" that is simply exemplary, because it's not only intended for catching exceptions but also for overcoming them.
You would be surprised by the safety provided by Common Lisp -- the runtime will complain if anything looks suspicious or if some error is caught; will then give you a very explicit explanation of what's wrong, and then it will give you alternatives of action. You could even go to the source code, correct the function that has the mistake, recompile that specific function, while the code is running, and watch your program continuing running, this time correctly.
Well, I've gone through SICP (book and exercises), so I might say that I have some familiarity with Lisp, as well as Python - but it's one thing to do toy or personal projects and another altogether to work on a full-scale project with several collaborators and a complicated history. There's a whole class of issues you experience in such a project that really shed a new light on a language as a tool of communication between developers.
By the way, the speed I mentioned is speed of development. Both Javascript and Python are used nowadays in speed-critical applications, with NodeJS on the servers and Python in various roles in big data and machine learning because the critical path is actually done on C level (I/O for NodeJS and GPU/math stuff for Python) while these languages are in charge of the stuff that is not that critical in terms of speed but much more complicated in terms of logic. This brings me to think that if you use a language on an appropriate domain and separate concerns between domains in a good way, it wouldn't matter if the language itself isn't that fast.
> This is not just a claim, this is my personal experience after about 23 years of programming where 90% of those years were spent using statically typed systems.
If most of your experience was with statically typed systems, it's just logical you would have very little experience with bugs that are prevented by statically typed systems - because this prevention would be at work. Looks like an opposite of survivor's fallacy, really.