Summary by Dan Luu on the question about whether for statically typed languages, objective advantages (like having measurably fewer bugs, or solving problems in measurably less time) can be shown.
If I think about this, authors of statically typed languages in general at their beginning might not even have claimed that they have such advantages. Originally, the objective advantage was that for computers like a PDP11 - which had initially only 4 K of memory and a 16-bit adress space - was that something like C or Pascal compilers could run on them at all, and even later C programs were much faster than Lisp programs of that time. At that time, it was also considered an attribute of the programming language whether code was compiled to machine instructions or interpreted.
Todays, with JIT compilation like in Java and the best implementation of Common Lisp like SBCL being at a stone’s throw of the performance of Java programs, this distinction is not so much relevant any more.
Further, opinions might have been biased by comparing C to memory-safe languages, in other words, when there were perceived actual productivity gains, the causes might have been confused.
The thing which seems more or less firm ground is that the less lines of code you need to write to cover a requirement, the fewer bugs it will have. So more concise/expressive languages do have an advantage.
There are people which have looked at all the program samples in the above linked benchmark game and have compared run-time performamce and size of the source code. This leads to interesting and sometimes really unintuitive insights - there are in fact large differences between code sizes for the same task between programming languages, and a couple of different languages like Scala, JavaScript, Racket(PLT Scheme) and Lua come out quite well for the ratio of size and performance.
But given all this, how can one assess productivity, or the time to get from definition of a task to a working program, at all?
And the same kind of questions arise for testing. Most people would agree nowadays that automated tests are worth their effort, that they improve quality / shorten the time to get something working / lead to fewer bugs. (A modern version of the Joel Test might have automated testing included, but, spoiler: >!Joel’s list does not contain it.!<)
Testing in small units also interacts positively with a “pure”, side-effect-free, or ‘functional’ programming style… with the caveat perhaps that this style might push complex I/O functions of a program to its periphery.
It feels more solid to have a complex program covered by tests, yes, but how can this be confirmed in an objective way? And if it can, for which kind of software is this valid? Are the same methodologies adequate for web programming as for industrial embedded devices or a text editor?
Thanks for posting this! That blogsite is always very productive reading.
I don’t get the obsession with the scientific method. Movie quote: “we don’t live in the courtroom, your Honor; do we?”. You can eliminate outliers like experts and students, hobby projects and lives-at-stake projects; everything you are left with is a good reflection of the industry. Example: any study with Java versus Python has to count.
I have no real experience with dynamic languages, so I can understand where the blog responses about dynamic languages having extra bugs come from. But they miss the important point about dynamic languages allowing for non-trivial solutions in fewer lines of code - matching that would basically need <AnyType> to be implemented in the static language, with the accompanying code bloat, under-implementation, bugginess, etc.
I think the reference to 0install’s porting is real experience of the difference between Python and OCaml. Caveat: author Thomas Leonard is a seriously expert practitioner.
Because actually knowing and understanding something is better than believing stuff. There is a lot of stuff that sounds plausible but is wrong.
I submit that laboratory-experiment-based understanding being valid in real-world use, in any domain, is itself a belief rather than knowledge. And in such an unstructured domain as software development, it is even less likely.
I dunnow, man. Did you use a plane recently? A computer? Something that contained electronics, like transistors? GPS? A weather forecast? All these are based in things like fluid physics, particle physics, quantum physics, electrodynamics, mathematics, and so on. Our modern world would simply not exist without it.
Granted, there are areas where applying the scientific method is harder. But we still do, for example in medicine. Why should this not be possible in software development?
That sounds like a laundry list of tech thrown together for effect. It is not even relevant. You are talking empirically-proven tech as a counterpoint to laboratory-only experiments, aren’t you?
I don’t know about the Wright brothers, but the human-powered flight bounty was apparently won using the strategy of fast iteration to empirically identify the solution. GPS too would have been built on real-world feedback iterations.
Computing hardware is a special case, where they replicate the laboratory into a billion-dollar structure and call it … ‘fab’ ;-)
The scientific method shorn of contact with reality, like with most research nowadays and especially in medicine, is just for show.
The Wright brothers actually were big fans and brilliant practitioners of the scientific method, and it is fascinating to read how they worked. They invented laboratory aerodynamics. And they were not iterating fast - given that so many early aviation pioneers had died in crashes, they took their time and made a lot of small experiments, and this allowed them to realize that control is essential for safe powered flight, and they invented the control system which until today is the base for all fixed-wing planes.
That is great. But isn’t this more than the scientific method? It is rigor, and the capacity to look at all the factors in reality instead of cherry-picking one for a laboratory experiment.
I do agree we all could do with more rigor and also avoid cherry-picking factors to study, in any discipline.