Evidence-based programming language design (PhD thesis)
jyx.jyu.fi
jyx.jyu.fi
The point of evidenced-based X (medicine, teaching, etc.) is improvement and change, things that people are often hostile to: https://en.wikipedia.org/wiki/Semmelweis_reflex
Research found that the number one cause of errors in learning Python was its case-sensitivity, and you can guess what people's reactions were when it was suggested that python support a case-insensitive option: (NIMPY - not in my python) https://mail.python.org/pipermail/python-list/2000-May/03710...
A crucial point is that the Semmelweis reflex isn't (just) hostility (or unacceptance) of change but of any evidence countering your beliefs, whether mainstream or not. Since people's attitude towards programming languages resembles religion (personal experience, emotional reaction) rather than "common wisdom" (as, say, in medicine), evidence-based language design may challenge those who favor or resist change (or different kinds of changes) equally.
The bigger problem with evidence-based approaches (and I don't know if this is covered in the thesis) is when the model tested is mutable (in this case, human behavior), which isn't really the case with medicine. The evidence may well show that most change has adverse effect, but that is only because it is different from the status-quo, and any adverse effect would dissipate given enough time. This makes the evidence-based approach problematic whether or not it uses agreement as its measure.
However, if we'd like to get at what in language design can facilitate learning, reduce bug rates, and enhance productivity, we probably should do some research by introducing programming languages to children. It would be useful to be able to separate out qualities and features that affect bug rates and productivity, without the confounding effect of programmer preconceptions.
That might be a good data point, but it is hardly sufficient. One of the biggest problems of objectively evaluating languages is that many languages "behave" differently when the project in question is large (large team, many LOC, long expected lifetime) than when it is small. We have good reason to believe that some languages which excel at productivity when working on small projects, are actually detrimental to large ones. How well a language affects productivity of small projects is certainly important (as small projects are important as is fast prototyping), but in terms of overall significant effect on software development in the industry at large, it is large projects that are far more interesting. Sadly, testing a language on large projects is expensive (and makes using children as the test subjects completely impractical), and as a result some languages have gone completely or near-completely untested in this regard even decades after their introduction. Their benefits (or problems) are therefore often as much folklore and religious belief than anything supported by actual evidence (let alone convincing evidence).
This sad fact, however, is what makes arguments over languages so much fun (for some) and endless.
Personally, my belief is that other than some outliers, the actual effect of modern languages (say any of those made in the past thirty years or so) on large project productivity is measurable but far less significant than some would have us believe (to the point where switching languages for this important class of projects is rarely justified[1]). And when the effect is larger, it has more to do with extra-linguistic features (like GC, performance, monitorability) than any language-level abstraction. But, of course, I can't prove it...
[1]: I am not suggesting languages can't make a bigger impact on large-project productivity, only that the ones we currently have don't. Indeed, more than one language has made such significant impact in the past.
Yes, but it's more than that: languages that are easy for novices to learn are bad for large projects; and furthermore, the very features that make them approachable are the ones that don't scale:
() weak typing/"helpful" implicit conversions, that do things like gloss over the number/string distinction, or provide conversions from various types to boolean
() simple scoping rules rather than full block scoping
() poor or nonexistent abstraction mechanisms (the original BASIC had no procedures with parameters and no user-definable datatypes); fortunately, in recent years, there seems to be more recognition that abstraction is important even for novices
Anyway, the obvious consequence is that because people like to keep using what they've learned once they've learned it, languages designed for approachability get used for large projects, whether that's a good idea or not.
You don't make that kind of error in other case-sensitive languages which offer better tooling.
E.g. you start writing "canv" and auto-complete that to "CanvasElement". You just auto-complete everything. And if you actually do screw something up, you get a squiggly line and a hint.
Simply ignoring all kinds of errors does not make the language easier to use. In JavaScript, for example, there are many cases where semicolons can be omitted. However, they aren't actually optional. There is a list of exceptions. It didn't actually make the language any easier.
Another example are things which should be type errors (`'foo' - 123` and so forth), but you get NaN instead. Or when you go outside some array's bounds you just get undefined instead of an exception. This stuff does not make the language easier to use.
By the way, I have all of that when writing Python, using PyDev on Eclipse, and other IDEs certainly offer the same.
And as an option? I can't remember what the actual proposal was, but having case insensitive code trying to use a case sensitive library sounds like lots of fun.
It's herehttps://www.youtube.com/watch?v=uEFrE6cgVNY
Short note upon skimming this thesis: Matthias Felleisen, of How to Design Programs and the Little Schemer series, is a reviewer.
An awesome paragraph from the introduction:
The genesis of this dissertation is a question I asked myself over a decade ago. How can I, as an aspiring programming language designer, improve upon existing languages instead of simply making another variation of a well understood theme? The well established research paradigm in language design would have me identify a deficiency in the expressiveness of some class of languages and then propose an alteration of these languages which arguably removes the defi- ciency. However, there already is several decades’ worth of such contributions, suggesting two much more pressing questions. How does one compare design alternatives that are present in the literature? And the question I focus on in this dissertation: How does one use the existing literature to aid in language design?
I cannot overemphasize the importance of being able to compare the merits of programming languages without taking sides. Philip Wadler's Why Calculating is Better than Scheming ( http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p... ) is wonderful. The problem appears when I tell you, "It'll make a Haskeller out of ya." Switching teams is an unscientific way to think about it.
Evidence keeps us sober. Like another commenter said the point of evidence is improvement and change. To extend that, by contrast the point of team-behavior is improvement mixed with identity-formation and group-cohesion, which often interfere with improvement and change.
Otherwise, good work advancing.