/pld/ - Programming Language Design Thread

Lisp.

Can someone recommend a good book on programing language design? Never done it before.

You will at best find opinions in books, as in they will biased towards OOP, FP, minimalism and other dogmata. Read the second and third link to get a general overview of what ideas and problems will await you in non-esotheric langs.

>Operator definition & overloading: Dedicated array assignment operator vs assignment and index operator.
Operators are gay and you don't want them. Just have functions, which can include non-alphanumeric characters.
What languages use a dedicated array assignment operator? That sounds stupid.

That image is stupid. Obviously the best approach is iterative language design that builds off previous languages and fixes real problems that clearly present themselves in real usage.

Alternatively, you bounce ideas off a committee of language designers. You don't ask "users" because they aren't language designers, they have no idea what they want, and will just say retarded things that break the entire paradigm and turn the language into a clusterfuck.

Design by need resulted in C. Design by committee resulted in C++. Take that as you will.

>Operators are gay and you don't want them. Just have functions, which can include non-alphanumeric characters.
Congrats, you just reinvented operator overloading.
>What languages use a dedicated array assignment operator? That sounds stupid.
It's only stupid syntactically, but under the hood those are two different operations. C++ and similar languages with reference semantics can get away with overloading them in one definition most of the time, but most other languages define something like [] and []=.

OP here. It's just a random pic I found, but you are right.
>Design by need resulted in [excrement]. Design by committee resulted in similar [slightly better excrement that is still recovering from its origin]. Take that as you will.
Shouldn't you look at the best examples that came out of such processes, not the failures?

The key difference is that users' access to operators and their syntactic forms are dictated by the language designer. If you've ever used Haskell or a Lisp you will see why it's better not to introduce this distinction.

Yeah, programmable lvalues are useful. Common Lisp's setf is better than Java's get/set methods and C#'s get/set properties.

If you see C++ as anything other than a failure of language design then you do not belong in this thread.

The same applies to C.
>The key difference is that users' access to operators and their syntactic forms are dictated by the language designer.
It's actually, unironically good to enforce this. If I add macros, they will be full, by default only pure compile time evaluation, which means that this facility comes with enough overhead to warrant additional, simple metaprogramming facilities.

Macros are orthogonal to operator overloading and operator/function distinctions, although the syntactic regularity that follows from the lack of an operator/function distinction may make macros easier to understand. I'm not sure why you bring this up.

>and operator/function distinctions
Ah, I thought this was about subscript getter/setter distinction. In that case, it's just an implementation detail.
But the point still stands, certain things like operator precedence should be enforced and restricted and brutally so. And fuck Lisp (all four and a half families), Perl6, Hasklel and other esoteric languages like seed7 that attempt to fuck with their syntax for no to little gains.

With strict prefix notation, operator precedence becomes a non issue.
You will learn to love the parentheses, user. Some day.

Minimalism is even more disgusting, user. You will learn to hate it in the unlikely event you have to maintain non-trivial software written by somebody else. Some day.

What's the problem with syntactic minimalism?

When exposed to the real world and brainlets, everything becomes PHP and worse. Since with syntactic minimalism and homoiconic languages everything can be changed trivially, expect everything to become PHP and worse.
Having a slight cost and rules put on metaprogramming lessens this effect and filters the brainlets.
Take C++ for example: Instead of even far longer compile times you get a few brilliant things like JSON for modern C++, compile time regexes and on the other hand stuff like boost spirit that nobody uses.

This is the one and only redeeming side effect of C macros and the reason, Cniles irrationally praise their heap of shit, because it makes them mistake their simpleton language for easy. Unfortunately the remaining parts of C are too easy and therefore the quality of libraries and tools is scratching the barrel of the bottom.

Perceived language usage interaction and language concurrenting interaction as complex systems that bear a simulation, user.

>Since with syntactic minimalism and homoiconic languages everything can be changed trivially, expect everything to become PHP and worse.
This follows from macros, not from simple syntax. Simple syntax loses many of its advantages without macros but it still remains useful.
Simple syntax does not also necessarily mean simple semantics, particularly if you have a lot of special forms (read: keywords).

>but it still remains useful.
no
>particularly if you have a lot of special forms (read: keywords).
that's where it stops being simple already
Just because I can parse something with actually regular regexes doesn't mean it's simple.

So basically you're saying C and other low level langs are complete shit. And you're right

stop arguing over stupid shit
start writing compilers

Attached: cover100.jpg (490x650, 247K)