The community exhausted the entire design space (along with some full-blown prototypes). Eventually, the core Julia team chose to use more forgiving scoping in the REPL (virtually always the first point of contact for beginners), while actual projects enforced stricter scoping rules.
My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation. I have found the Julia team to be consistent in this pursuit. If the first point of contact is intractable for beginners, the project is dead on arrival. A technical tool should be tailored for experts, but you don't want to kill adoption along the way. Engineering is tradeoffs.
This article goes more in depth along the same lines: https://pchiusano.github.io/2016-02-25/tech-adoption.html
[1] https://discourse.julialang.org/t/another-possible-solution-...
Please please, how do we convey this to the mathematicians that infest wikipedia?
And in so doing, they slowly bootstrap themselves so far away from any grounding context that it is incredibly difficult for anyone to _learn_ mathematics from reading wikipedia articles.
There are groups doing great things like Setosa [1], nLab [2] and for concepts, Simplicable [3]
1. It's vaguely mnemonic of FirST and ReST, but compactified enough that it's still parseable as abstract names with no particular semantics
2. It's composable the same way that CAR and CDR are, e.g. FFRST == CAADR.
Another good pair of names is LHS and RHS for Left Hand Side and Right Hand Side. Same argument applies.
Lather, rinse, repeat.
For extra credit, write a macro that will save you having to type every possible combination out manually.
For example, ruby has plenty of warts and annoyances that become evident with experience, but I still find plenty of ruby code that’s lovely to read (like it’s telling a story). Plenty of atrocities too, which is exacerbated by the language.
I see the value in succinct languages too, which require a knowledge investment to be productive. Just more efficient.
It’s kinda like QWERTY typists and stenographers, but with far more middle ground. No one can argue that stenographers are faster, but it’s also not a realistic expectation for everyone to learn it.
Look at Perl for an example of what happened to a language with syntax that appealed only to people who were already Perl-practitioners.
It became for several years one of the most successful and widely used scripting languages on Unix?
The idea that today's languages and technologies are truly better than the past is laughable, particularly when they recycle so much of what is old and slap on a new name
That's really orthogonal to the discussion, though. This isn't about general superiority, it's about legibility and barriers to understanding/skill due to syntax and keywords. Perl is infamous for the "code golf is the default style" syntax, keywords, and tokens it employs in this context, and in my experience at least its most ardent fans believe it is a badge of honor.
It isn't, really, and it's the same mistake PG makes when discussing "car", "cons" and the like.
Indeed. And I disagree with your opinion. For all its terseness its still wonderfully expressive and it goes against the horrible trend set by Python with its "one true way" bullshit. That we all so willingly accept the commodification of our trade so the paymasters can eventually decrease our demand is shameful.
We should strive for a certain level of difficulty if anything to separate the wheat from the chaff. You wanna play with the big boys? Learn to code in a big boy language.
Instead we let the trainwreck that is modern JS take over.
Now, you are right that the syntax is for practitioners. But if it's too bizarre to non-practitioners, it is in fact a barrier to entry.
What about languages who support multiple ways to do something in a semi-inconsistent manner?
For example with Elixir, in a lot of cases you end up calling certain standard library functions like foo(hello: :world) while others are foo(:hello, :world). Now, there's special magic happening in the first case but stuff like this is super confusing and it gets easily compounded with more complex examples.
As a beginner I found Ecto's various ways to calls things super confusing and I had to reference examples almost all the time to get the syntax right (which often had multiple ways of being "right"), but I've also talked with more experienced Elixir developers and they get hung up with Ecto's syntax too.
So where do you draw the line between making the language / DSL better and keeping it catered to only folks who are basically at the same skill level of the language creator?
But that's not really a beginner-specific problem. Even practitioners will likely find it to be a nuisance.
One of the super cool things about Elixir is how easy it is to extend the language with DSLs. However (and Jose et al are very up front about this), the more DSLs and macros you use, the more confusing it's going to be. Using macros is a tradeoff because it can be a very neat solution but it also obscures what the code is doing quite a bit.
Re. foo(hello: :world) vs foo(:hello, :world) - that one I got the hang of more quickly, though I'll admit it's confusing at first. In the first you're providing a keyword list (which is merely a list of 2-membered tuples where the first member of the tuple is an atom). And when a keyword list is the last (or only) argument to a function it can be provided without the brackets. So the same thing could be written as foo([{hello:, :world}]) or also foo([hello: :world]). In foo(:hello, :world) you're just providing arguments. When you're first learning the language this can definitely trip you up but I think once you become a "practitioner" it's not too bad and ends up being pretty nice.
God Elixir is so cool.
They seem like a good thing to me!
The aim is never to make things difficult for beginners on purpose. The point is that making things less confusing for beginners is not worthwhile if it comes at the cost of making things more cumbersome for practitioners.
I actually agree with the comment which states "But that's not really a beginner-specific problem. Even practitioners will likely find it to be a nuisance."
Sure, being a beginner is a temporary situation, but let's not excuse absurdities and unnecessary convolutions as a result.
The argument actually says "don't optimize notation for beginners, optimize for practitioners". It doesn't imply making things difficult for beginners on purpose; just that they are not the priority.
I just don't even think it's a useful remark because you can just claim people you disagree with are beginners and people you agree with are practitioners and now anything can be argued.
I wouldn't call people who disagree with me on PL design issues beginners. I would call beginners beginners. It's not a matter of disagreeing, it's a matter of experience and time working on real projects with a language.
Concepts are way more important. Spending time on syntax is like having a course in tar --flags.
> As names, car and cdr are great: short, and just the right visual distance apart. The only argument against them is that they're not mnemonic. But (a) more mnemonic names tend to be over-specific (not all cdrs are tails), and (b) after a week of using Lisp, car and cdr mean the two halves of a cons cell, and languages should be designed for people who've used them for more than a week.
In particular, the last sentence. I find arguments that go "but this looks confusing to a beginner!" unconvincing. Language syntax and notation should be aimed at actual practitioners, not beginners.
----
[1] https://news.ycombinator.com/item?id=21256727