Hacker News Reader

Comment by edtechdev | Hacker News Reader

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

View on HN

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

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.

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

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

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

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.

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.

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

Reply on news.ycombinator.com