Evidence-based programming language design (PhD thesis)(jyx.jyu.fi)
jyx.jyu.fi
Evidence-based programming language design (PhD thesis)
https://jyx.jyu.fi/dspace/handle/123456789/47698#
15 comments
> 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
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.
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.
Fitting the expectations of existing communities is valuable for programming languages. Not having operator precedence made Smalltalk eaiser to learn by 8 year olds, but much harder to sell to engineers.
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.
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.
> we probably should do some research by introducing programming languages to children
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.
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.
> We have good reason to believe that some languages which excel at productivity when working on small projects, are actually detrimental to large ones.
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.
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.
> Research found that the number one cause of errors in learning Python was its case-sensitivity
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.
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.
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.
By the way, I have all of that when writing Python, using PyDev on Eclipse, and other IDEs certainly offer the same.
By the way, I have all of that when writing Python, using PyDev on Eclipse, and other IDEs certainly offer the same.
Case insensitivity is a curse visited upon us by people who were otherwise extremely intelligent but completely missed the boat on the fact that there are more than 26 + 10 symbols used by humans to communicate in written language and that no matter how much you want it to be A != a.
I find the fact that Guido was considering making Python case insensitive in 2000 very fascinating. 15 years later and case insensitivity is still viewed as being "wrong". I only know one "new" language that is brave enough to be case insensitive and that is Nim, funnily enough its syntax is very much inspired by Python.
By now I think case insensitivity is probably good (back then I don't think I did), but the idea of introducing it into an existing language, breaking much more than Python 3 eventually did doesn't sound great.
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.
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.
I don't care about Nim case insensitivity, but underscore insensitivity??
Breaking grep is a _very bad idea_.
TL;DR the thesis researches how evidence-based programming language design could be conducted, but it does not actually goes into what such a design would be given the available evidence.
I'm going to read some of this thesis. If this piques your interest, Andreas Stefik has a fascinating Strange Loop talk (~40 minutes) where he talks about 1) the history of evidence-based endeavors 2) the curious lack of evidence-based programming language design 3) a programming language informed by evidence, quorum.
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.
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.
Sorry, that's a bit too long to read all. I would however be interested in seeing a language resulting from this methodology, if there is any.
Otherwise, good work advancing.
Otherwise, good work advancing.
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...