Hacker News new | past | comments | ask | show | jobs | submit login
Can We Crowdsource Language Design? (2017) [pdf] (brown.edu)
11 points by luu 3 days ago | hide | past | favorite | 3 comments

So the first issue I have with the paper is that I am not convinced that the results should be relevant to the programming languages I work with. It is a survey of the behaviour of people who aren’t particularly expert programmers, who don’t know the language, and who are trying to do things very quickly rather than thoroughly. That sounds like the opposite of the kind of person I would want my work optimised for. But maybe optimising for these people makes things easier for expert users too. It’s true in other parts of life that eg writing websites for people with poor literacy makes them faster for people with good literacy.


I find the dynamic scoping[1] experiment pretty unconvincing. The other way to get their “believes dynamic scoping” result is to assume that their language has JavaScript-like semantics and the variables are global. I think an example program to test this might be:

  func f(x):
    return g()
  func g():
    return x + 2
But I realise that is then not independent from some of the other tests.

I think a separate problem is that usually when I read code, I’m not thinking “well this code might just not work at all” because 1. It’s just not my prior, and 2. It seems a bit rude to start from such an oppositional position to someone else’s code. Instead I’ll try to assume that it works and work out why it works. This is especially true for code written in languages I’m unfamiliar with. I remember enjoying this especially before I learned any haskell when the haskell blogposts were frequent on HN. But this position puts me at odds with the study where for many examples you are supposed to guess Error whereas I want to figure out what assumptions make it not an error, then which is most reasonable, then what results those assumptions would imply. But maybe my expectations of how a programming language behaves wouldn’t be so useful for designing languages as I already have pretty strong expectations for this.

[1] perhaps I just disagree about the definition of dynamic scoping here.

Another way to get the “dynamic” scoping answer is to ignore functions as well as scoping and just guess based on reading too down. Eg the last line says print(a), first the program wrote a=10 then it wrote a=15, so I guess a=15. In the next example you see print(d), look up and see d+3, make a guess as to what that means and look up again and see d=5, so guess d=8.

I'm surprised not a single mention of the process of having RFCs collected, examined, weighed, and responded to in the design of Perl6/Raku in the whole paper. Final decisions were made by a committee and lead by Larry Wall as an individual, but the overall process very much involved the public.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact