5 ms·

As a user of programming languages, I don't care about s-expr vs infix syntax, but I do care about the amount of semantic innovation that went into a language (

As a user of programming languages, I don't care about s-expr vs infix syntax, but I do care about the amount of semantic innovation that went into a language (as in I refuse to learn any language whose main contribution is syntactic), and sadly it seems that wasting time on syntax distracts many PL creators from the semantic poverty of their creations.

johnbender 13y ago
This was my primary frustration with the article. It notes that the "bulk" of the work in building a programming language is in defining the semantics but devotes absolutely no space to the process, tools, and tradition. A programming language is the semantics and without a strong notion of those semantics and the interactions you end up with confusion and difficulty. For an example one need look no further than Ruby's "implementation as specification" crazyness. I won't go as far as to say that all language creators should adopt operational semantics when building a language, but if you're serious about it then you should at least investigate the process.
- WalterBright 13y ago
  I deliberately tried to avoid topics that are well-covered elsewhere.
  - dllthomas 13y ago
    Appropriate, but can you point us at some of those elsewheres?
    - WalterBright 13y ago
      If you want to figure out how to write a lexer or parser, what better way than to read the code for one? https://github.com/D-Programming-Language/dmd/blob/master/src/lexer.c https://github.com/D-Programming-Language/dmd/blob/master/sr... https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c https://github.com/D-Programming-Language/dmd/blob/master/sr... There's a lot of detail there, but the operation of both is straightforward.
      - dllthomas 13y ago
        I'd thought this subthread was discussing semantics.
      - johnbender 13y ago
        For anyone who comes across this thread and is genuinely interested in educating themselves about how programming languages can be constructed in a principled way (what I would call sane) you can consult Pierce's Types and Programming Languages. With some work anyone can learn the material. It's not as simple as reading a blog post unfortunately, but you'll have a much deeper understanding of what it means to build a programming language.
        ericbb 13y ago
        I'm in the midst of reading Types and Programming Languages right now. I'm also reading the more recent Practical Foundations for Programming Languages by Robert Harper. It's written for a similar audience. I would recommend both.
- he_the_great 13y ago
  If someone wants to build a language and "A programming language is the semantics" doesn't it really make sense to tell them what the semantics should look like?
  - johnbender 13y ago
    Sorry I thought I was being clear when I mentioned operational semantics but in retrospect that may have been totally unclear. I recommend Pierce's Types and Programming Languages. It has everything you need to learn about operational semantics and types systems.
sdegutis 13y ago
I fully agree. Syntax is the least of my concerns when I'm using a programming language. I use many languages in many IDEs and editors, and when I'm coding, I don't really see syntax, I see the algorithms and patterns behind it.
jeffdavis 13y ago
Although I largely agree, I think that line of thinking can be taken too far. One reason I think that is because syntax helps develop conventions and make them obvious. If everything is an s-expr and you can do absolutely anything with macros anywhere, then two programmers might not really be able to communicate even if they are technically using the same language.
- wirrbel 13y ago
  When several programmers develop on a mutual codebase, there is not one programming language where coding conventions are unnecessary. This is hardly an argument against Lisps. In fact the clojure code I read so far seems to adhere far more to conventions than code of almost any other programming language I have worked with so far. Macros are pretty much like Classes, Gotos/Loops, Exceptions, Functions, etc in this respect, the communities have mostly agreed on conventions _when_ and _how_ to use them. I think the argument that macros will make a codebase unreadable to other programmers is largely an exaggeration to turn a pro-Lisp argument against Lisp. Its a pattern I have heard a little too often: "C++ is powerful" -> "C++ is too powerful" "Macros let you express ..." -> "Macros can do just too much" Now in my non-Lisp programming, I miss macros a lot. Especially those that are built into a lot of lisps and are quite "simple" additions. The Clojure threading macro for example, or `if-let` variable binding, or the awesome xml-templating languages that are realizable with macros. On the other hand, I have seen code that - for me as an outsider - came quite close to what you describe, just that it hardly was Lisp but PHP, Javascript, etc. Macros, like functions and classes are part of the vocabulary programmers build. So next time when you criticize macros, talk about something that is worth debating, like the fact that they can be unsafe (hygiene), they are not intuitively writable like functions, they might make debugging harder, etc.
  - agentultra 13y ago
    I'm not sure there is a point worth debating. Hygiene is left to the programmer and the facilities exist to write "safe" macros (gensym). Debugging isn't terribly difficult with macro-expansion facilities. The only "problem" with them, if you can call it that, is that newbies like to over-use them once they learn them. However that problem goes away with time. Macros in the hands of an intermediate-to-experienced programmer are powerful tools. They remove patterns from your code. They allow you to modify the compiler to efficiently run your program. And all sorts of good things. People arguing that X "is too powerful" are saying that nobody needs a combine harvester when a team of farmers with scythes will do.
klipt 13y ago
I dunno, I definitely find d = {} d[key] = value easier to read/write than (set! d (make-hash-table)) (hash-table-put! d key value)
- WalterBright 13y ago
  Yes, syntax matters.
- wtetzner 13y ago
  On the other hand, I find (define d (make-hash-table)) (hash-table-put! d key1 value1 key2 value2 key3 value3) easier to read than d = {} d[key1] = value1 d[key2] = value2 d[key3] = value3 So syntax matters, but it's not obvious which syntax is best.

johnbender 13y ago

This was my primary frustration with the article. It notes that the "bulk" of the work in building a programming language is in defining the semantics but devotes absolutely no space to the process, tools, and tradition. A programming language is the semantics and without a strong notion of those semantics and the interactions you end up with confusion and difficulty. For an example one need look no further than Ruby's "implementation as specification" crazyness. I won't go as far as to say that all language creators should adopt operational semantics when building a language, but if you're serious about it then you should at least investigate the process.

WalterBright 13y ago
I deliberately tried to avoid topics that are well-covered elsewhere.
- dllthomas 13y ago
  Appropriate, but can you point us at some of those elsewheres?
  - WalterBright 13y ago
    If you want to figure out how to write a lexer or parser, what better way than to read the code for one? https://github.com/D-Programming-Language/dmd/blob/master/src/lexer.c https://github.com/D-Programming-Language/dmd/blob/master/sr... https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c https://github.com/D-Programming-Language/dmd/blob/master/sr... There's a lot of detail there, but the operation of both is straightforward.
    - dllthomas 13y ago
      I'd thought this subthread was discussing semantics.
    - johnbender 13y ago
      For anyone who comes across this thread and is genuinely interested in educating themselves about how programming languages can be constructed in a principled way (what I would call sane) you can consult Pierce's Types and Programming Languages. With some work anyone can learn the material. It's not as simple as reading a blog post unfortunately, but you'll have a much deeper understanding of what it means to build a programming language.
      - ericbb 13y ago
        I'm in the midst of reading Types and Programming Languages right now. I'm also reading the more recent Practical Foundations for Programming Languages by Robert Harper. It's written for a similar audience. I would recommend both.
he_the_great 13y ago
If someone wants to build a language and "A programming language is the semantics" doesn't it really make sense to tell them what the semantics should look like?
- johnbender 13y ago
  Sorry I thought I was being clear when I mentioned operational semantics but in retrospect that may have been totally unclear. I recommend Pierce's Types and Programming Languages. It has everything you need to learn about operational semantics and types systems.

sdegutis 13y ago

I fully agree. Syntax is the least of my concerns when I'm using a programming language. I use many languages in many IDEs and editors, and when I'm coding, I don't really see syntax, I see the algorithms and patterns behind it.

jeffdavis 13y ago

Although I largely agree, I think that line of thinking can be taken too far. One reason I think that is because syntax helps develop conventions and make them obvious. If everything is an s-expr and you can do absolutely anything with macros anywhere, then two programmers might not really be able to communicate even if they are technically using the same language.

wirrbel 13y ago
When several programmers develop on a mutual codebase, there is not one programming language where coding conventions are unnecessary. This is hardly an argument against Lisps. In fact the clojure code I read so far seems to adhere far more to conventions than code of almost any other programming language I have worked with so far. Macros are pretty much like Classes, Gotos/Loops, Exceptions, Functions, etc in this respect, the communities have mostly agreed on conventions _when_ and _how_ to use them. I think the argument that macros will make a codebase unreadable to other programmers is largely an exaggeration to turn a pro-Lisp argument against Lisp. Its a pattern I have heard a little too often: "C++ is powerful" -> "C++ is too powerful" "Macros let you express ..." -> "Macros can do just too much" Now in my non-Lisp programming, I miss macros a lot. Especially those that are built into a lot of lisps and are quite "simple" additions. The Clojure threading macro for example, or `if-let` variable binding, or the awesome xml-templating languages that are realizable with macros. On the other hand, I have seen code that - for me as an outsider - came quite close to what you describe, just that it hardly was Lisp but PHP, Javascript, etc. Macros, like functions and classes are part of the vocabulary programmers build. So next time when you criticize macros, talk about something that is worth debating, like the fact that they can be unsafe (hygiene), they are not intuitively writable like functions, they might make debugging harder, etc.
- agentultra 13y ago
  I'm not sure there is a point worth debating. Hygiene is left to the programmer and the facilities exist to write "safe" macros (gensym). Debugging isn't terribly difficult with macro-expansion facilities. The only "problem" with them, if you can call it that, is that newbies like to over-use them once they learn them. However that problem goes away with time. Macros in the hands of an intermediate-to-experienced programmer are powerful tools. They remove patterns from your code. They allow you to modify the compiler to efficiently run your program. And all sorts of good things. People arguing that X "is too powerful" are saying that nobody needs a combine harvester when a team of farmers with scythes will do.

klipt 13y ago

I dunno, I definitely find d = {} d[key] = value easier to read/write than (set! d (make-hash-table)) (hash-table-put! d key value)

WalterBright 13y ago
Yes, syntax matters.
wtetzner 13y ago
On the other hand, I find (define d (make-hash-table)) (hash-table-put! d key1 value1 key2 value2 key3 value3) easier to read than d = {} d[key1] = value1 d[key2] = value2 d[key3] = value3 So syntax matters, but it's not obvious which syntax is best.