Reimplementing the bulk of std.meta iteratively

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Sep 29 13:48:57 UTC 2020


On 9/29/20 8:02 AM, Patrick Schluter wrote:
> On Tuesday, 29 September 2020 at 03:14:34 UTC, Andrei Alexandrescu wrote:
>> On 9/28/20 6:46 PM, Bruce Carneal wrote:
> 
> [..]
>>
>> Years ago, I was in a panel with Simon Peyton-Jones, the creator of 
>> Haskell. Nicest guy around, not to mention an amazing researcher. This 
>> question was asked: "What is the most important principle of 
>> programming language design?"
>>
>> His answer was so powerful, it made me literally forget everybody 
>> else's answer, including my own. (And there were no slouches in that 
>> panel, save for me: Martin Odersky, Guido van Rossum, Bertrand Meyer.) 
>> He said the following:
>>
>> "The most important principle in a language design is to define a 
>> small core of essential primitives. All necessary syntactic sugar 
>> lowers to core constructs. Do everything else in libraries."
>>
> Sorry to not be completely convinced on the pertinence of that 
> statement. For the language designer it might well be true, for the 
> users of the language I'm not completely sold. There are two languages 
> that imho fit that description very well, they are both very powerfull 
> and extremely elegant, but boy do they suck when you just want to get 
> shit done: Lisp and Forth. And (I know, one should not start a sentence 
> with and) it had been mentioned often in this forum, it is this shear 
> flexibility that are in the way of wider adoption as there are so many 
> ways of doing things, but none of them completely right.
> Your AA example is a good one. If it wasn't in the language, it would be 
> the same issue with AA as in any other language that defines it in 
> libraries: several different incompatible restricted implementations.
> 
> Just my uninformed 2 cents.

Completely agree with the sentiment! Also, being informed in language 
internals paraphernalia is not at stake here.

I've studied classical guitar for many years. Got a couple of prizes, 
too, but never broke out of the amateur ranks. Nevertheless, I got to 
meet a few professional players and also played to a variety of audiences.

One thing that's obvious to a music performer that is not at all clear 
to listeners is that deficiencies in performance show up as second-order 
effects.

What do I mean by that? I mean that the audience doesn't sit there with 
the sheet music in hand following the notes and the directions written. 
They won't put the finger on paper and say, hey, hey, what happened to 
the mezzoforte in here? No, they just sit back and listen to the music. 
If they like it, they don't know why. If they don't, they don't know 
why. Music critics write all about some performer's technique, touché, 
style, rubato - but listeners are like, yeah, that's beautiful or isn't. 
An exegete knows that that came out poorly because the performer moved 
their wrist too much.

No bug report will come as "D uses too many tricks in the compiler that 
are inaccessible to programs, and that's very problematic." No, they'll 
all come as problems with surprising limitations and inconsistencies, 
frustration in use, platform dependencies, deficiencies in 
implementation, lack of orthogonality, very concrete and very many bugs, 
bugs, and bugs.

Deficiencies in programming language design show up as second-order effects.

There's also something about limits that needs clarification. Small 
language kernel being good does not mean the smallest language kernel is 
the best. (In guitar technique economy of motion is a key ideal, i.e. 
one should minimize movement of both left and right hand. That of course 
doesn't mean zero movement is best, because that would produce no 
sound.) So keeping the core small and reducing sugar to it is an ideal 
to live into, not a rigid requirement.


More information about the Digitalmars-d mailing list