4 ms·
One of the biggest problems is that these language designers, who want to design an "idealized" language, continue to make big decisions without regards to any
by acbart 7y ago
One of the biggest problems is that these language designers, who want to design an "idealized" language, continue to make big decisions without regards to any kind of actual data collection. I just had the chance to meet and talk with Andreas Stefik, who summarized the utter and embarrassing lack of research by the PL community about actual language usability[1]. I'm not exactly jumping into line to adopt his evidence-based language "Quorum", but thank goodness that someone cares enough to do actual HCI research instead of just arguing theoretical merits. My own history and feelings about Racket are with regards to its connections with the controversial "Program by Design" curriculum - feelings that are both complicated and narrow (all revolving around introductory computing contexts). But I certainly resonate with this quote from the article:
"But in the last 60 years, simply grabbing these dissenters by the lapels and fumigating them with the stinky garlic breath of parenthesized S-expressions has not been a winning strategy. If Lisp partisans want different results in the next 60 years, we need to try something new."
[1] https://quorumlanguage.com/evidence.html https://quorumlanguage.com/evidence.html
- didibus 7y agoI'm big on evidence based, but I'm also not sure I believe evidence can be adequately demonstrated. The PL used is a tool for the programmer. If you take other disciplines, has their ever been proper evidence that some tools are better then others for any practice? What knife a chef chooses to use, what design a F1 car incorporates, etc. It seems a lot of it depends on the practitioner's style and symbiosis. Most evidence based research into PL seems very inadequate, and I'm not sure we'll ever have good experiments. How do you measure the language over its level of mastery? Certain novice somewhat being more productive or making less bugs on trivial programs in beginner contexts doesn't tell you much. Also, the very clear PL improvements have mostly been universally adopted. Lexical scopes for example, if/else conditionals, procedures, runtime types, GCs, dependency managers, unit and integ tests, etc. It's only the insignificant details which are often debated. And for those, I think it becomes much more a decision to be made by masters, like your favourite chef knife, you pick what best fits your style and maximises your own productivity while minimizing your own weaknesses.
- fouric 7y agoAnecdotally, I spent five years writing C, C++, and Python before trying a Lisp, but after I got used to them, I found parenthesized s-expressions (with sufficient indentation and coloring - but that should be a given) to be significantly _more_ readable than C-style syntax. You can reasonably make the argument (and I do) that the reason why mainstream programming culture hasn't adopted parenthesized s-expressions is not because they're inherently less readable, but because of massive bandwagon effects + inertia of C-style syntax due to the proliferation of...C-style languages, which trains peoples' minds to prefer said syntax, even if their steady-state characteristics are worse than that of s-expressions.