It's so refreshing to hear about fixed requirements, as a separate stage. I know it's waterfall, but too many requirements, ill-defined, changing, lead to dread-invoking code. But we don't need to have separate requirements with software, because it can be changed much more easily cheaply than physical products. There are other advantages of requirements, but they seem to be on the wane.
Reminds me of compiled, statically-typed languages: they used to be necessary for speed. These days, hardware is so fast, non-compiled, non-statically-typed languages like ruby and python are fast enough. But there are other advantages of static-typing, but those languages seem to be on the wane... (is that true, or just an artifact of the preferences of HN/startups?)
These are still hotly debated and one paradigm is hardly 'waning' compared to the other. I think when you say "non-compiled, non-statically-typed" you actually mean "dynamically-dispatched." This page: http://madhadron.com/?p=191 popped up on HN a while ago and talks about this, the author talks about how dynamic dispatch lets you create and mold the language as you see fit -- "language as medium."
It's not a better/worse comparison as much as it is a design decision: non dynamically-dispatched languages (C, Go) don't have their semantics modified at runtime and behave in a more "predictable" manner (and are easier to analyze and prove, which compilers take advantage of for speed). On the other hand, dynamically-dispatched languages (Smalltalk, Ruby and Lisp) let you modify the semantics of the program as it's running (see Ruby's method_missing and define_method for an example). This gives you tremendous power to craft really amazing things (Rails magic), but it also creates tremendous complexity and makes things less predictable. A side-effect of this is that a JIT is needed for programmatic analysis/optimization.
I tend to consider dynamic dispatch the transfinite numbers of computing -- staying within the realm of regular integers "frees your mind" from mind-blowing concepts; you're limited in what you can make but you have more brainpower focused on making that "perfect." On the other hand, full dynamic dispatch opens up so many possibilities that sometimes you worry too much about making "the perfect abstraction" than actually writing code. You may be inexperienced in working in such complexity and (like Cantor) slowly go insane :). One may look down upon the other but I tend to think they're just two different ways to solve the problem.
I'm not sure I understand your use of the term dynamic dispatch. Single dispatch is pretty run of the mill, basically everyone does it if they do OOP. Multiple dispatch used to be a lot less common but these days most interesting languages can attain equivalent functionality e.g. even C# can now achieve some semblance of multiple dispatch using 'dynamic'.
The really interesting mode of dispatch is predicate dispatch since it generalizes pattern matching and all forms of dynamic dispatch. I haven't seen it done fully or with wide use yet. Clojure, Lisp, Haskell (views) and F# (active patterns) all have close approximtions of it. But I don't think that is what you meant.
Best I can figure from what you mean based on naming smalltalk, ruby , lisp is that you mean powerful reflection and metaprogramming abilities in the language.
-----------------------------
You know, the fact that you mention dynamic dispatch and Transfinite numbers in the same post makes you a really cool person in my book but its not fair on Cantor to perpetuate the myth that he went crazy trying to grapple with infinity. He struggled with depression through out his life.
Note also that you don't even have to invoke the transfinite numbers to get some craziness. I am sure you know that the reals are pretty weird themselves - really more an indictment on nonconstructive mathematics.
...Pick a real at random, and the probability is zero that it's accessible - the probability is zero that it will ever be accessible to us as an individual mathematical object...
p.s. if you like transfinite numbers then you may be interested in reading about jaina mathematics who had a notion of sets and mathematics on infinite numbers nearly 1000 years before Cantor.
In large companies, where your code might be worked on by numerous other people, and it';s not guaranteed that the next person to change it will have ever seen it before, statically typed languages are still prevalent, because it means the stupidest errors are spotted as early as possible.
In the wider world most people are still using C, C++, Java and C#. And then in the more interesting statically typed languages the most used are Haskell, Scala, F# and Ocaml. So no I don't think static languages are in the wane.
Reminds me of compiled, statically-typed languages: they used to be necessary for speed. These days, hardware is so fast, non-compiled, non-statically-typed languages like ruby and python are fast enough. But there are other advantages of static-typing, but those languages seem to be on the wane... (is that true, or just an artifact of the preferences of HN/startups?)