Evidence-based programming language design (PhD thesis)

https://jyx.jyu.fi/dspace/handle/123456789/47698#

by sampo • 11 years ago

47 15 11 years ago

jyx.jyu.fi

rhaps0dy• 11 years ago

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.

mkiwala• 11 years ago

http://quorumlanguage.com/

edtechdev• 11 years ago

I don't know that I would associate "evidence" with "coder agreement".

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...

pron2• 11 years ago

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.

stcredzero• 11 years ago

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.

ahoge• 11 years ago

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.

icebraining• 11 years ago

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.

hyperion2010• 11 years ago

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.

dom96• 11 years ago

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.

Scarblac• 11 years ago

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.

renox• 11 years ago

I don't care about Nim case insensitivity, but underscore insensitivity?? Breaking grep is a _very bad idea_.

murbard2• 11 years ago

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.

delish• 11 years ago

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.

Evidence-based programming language design (PhD thesis)

Related Stories