Have you noticed that these articles almost never do?
they have argument from authority and anectdote. Language research is still in the phase of bad humors and blood letting.
Without rigorous evidence we're left to argue from theoretical models / principles and anecdotal data. This is still useful. It would certainly be more useful to have rigorous empirical results to back up the claims and validate the models but we, as practitioners, have to make decisions on language choice now using the available resources.
Love this. Practically all the claims I've seen are just small code samples accompanied by the author's vague endorsement.
In category theory we might have different categories. Some might instruct the compiler and programmers that the function obeys certain rules when applying. It could be trivial to parallel or perhaps it specifies a strict sequencing for computation. Following Haskell research, you can really see the evolution as people find more useful generalizations (which in the end, has made things simpler!)
https://sites.google.com/site/stefanhanenberg/ https://link.springer.com/article/10.1007%2Fs10664-013-9289-...
The above papers are not about FP but about static type systems (there tends to be lots of crossover), but I think you'll find that what it really comes down to is guarantees provided by a language. I would be surprised if similar research that focused solely on purity did not exist.
This is an incredibly difficult area to study. "Better software" is a difficult metric, and even a more meaningful metric is incredibly hard to measure. For a field as young as CS it's no wonder that the research into this is still immature, so we largely have to rely on anecdotal evidence and common sense.
So yeah we have some research and we have some basic common sense and we have people demonstrating through their projects that it has worked well for them.
More to the authors point - what they are really talking about here is modularization being a benefit to a moving codebase. Their quotes, their 'argument from authority', is mostly about modularization. Their argument is that functional programming lends itself to modularization by limiting state space and focusing on composition.
The kind of empirical evidence you are asking for is extremely expensive to provide. Even if you conduct a massive controlled trial, experiment will have several biases which will invalidate any conclusion. As an exercise try looking for scientific evidence that programming in Java is more efficient than programming in assembly. No scientific evidence for this exists. Yet most of us would never choose to write a web service in assembly! The only evidence that can be provided are discussions and benefits of particular features and anecdotes.
It's not like you cannot write short functions in other languages - you can - but it's often too easy not to do it.
It would be nice to have some empirical evidence for this, unfortunately I am not aware of any.
Do you think programming productivity is possible to measure and if so how?
> Do you think programming productivity is possible to measure and if so how?
For the purpose of discussion, I would propose that a team of developers are given a simple task with highly specific and explicit functionality requirements. This team of developers should Ideally have no experience with any of the technologies used. Experience with the problem domain is acceptable. These developers would then be tasked with building out the solution with various different technologies (languages, frameworks, libraries). We then compare the time it took for the developers to complete the task relative to the amount of bugs present in the solution. For example, the team could be tasked to build a gui calendar with Haskell and then Python.
The issues with the above proposed experiment are as follows:
* We would need to find some way to adjust for problem domain familiarity. The developers are going to get better, and thus more productive, at the task after they have completed it the first time.
* We need some sort of concrete numerical measure of "bug likelyness" for lack of a better term. All software has bugs, but some are very hard to find or appear only during runtime under very specific conditions.
* We need to decide whether or not we take the language ecosystem into account. In the calendar example I provided above, Python would obviously be more productive because there are a ton of different packages available that make creating a GUI extremely trivial.
* Do we take into account time spent on learning the language/tool/package/framework/library? Do we measure the amount of time that it takes the team to feel comfortable working with a new technology?
All in all, it's an interesting thought experiment and I'm interested to hear what you think.