8 ms·

Controversial opinion but I believe that eventually these grammars and complex parsers will be found to have been a huge mistake for computer science. A mistake

Controversial opinion but I believe that eventually these grammars and complex parsers will be found to have been a huge mistake for computer science. A mistake made for the sole reason of making programming languages resemble natural languages, even though they are not meant to be read fluently. Everyone who experienced the magic of lisp understands how beneficial it is to have the textual representation as close to the parsed abstract syntax tree. One can create new languages fit for the purpose of a given class of problems and thus reducing size of codebase 10 to 100 fold (or even million times in case of modern multi million LOC software projects). The biggest mistake lisp ever made was the unintuitive parenthesized prefix notation. Which can be thrown away by having all operations strictly infix. Ie. instead of doing combinations of the following: lisp: (plus 1 2) methods: 1.plus(2) algol,C: plus(1, 2) haskell: plus 1 2 One can use the simplest form ever and achieve even simpler lisp: 1 + 2 but use it consistently for every function call or operator within the language. (even for functions of multiple arguments). APL came close, but for some reason decided to ignore the important Phoenician discoveries of 1. reading from left to right 2. use of phonetic alphabet instead of hyeroglyphs.

platform 7y ago
> One can create new languages fit for the purpose of a given class of problems and thus reducing size of codebase 10 to 100 fold interesting, thank you for sharing. Could I transpose your thought into: -- Solutions (or large scale programs), should not be written in a general purpose language. Instead, there should be core domain language (solution DSL) developed (using a general purpose language) and then the solution should be developed using the solution DSL. ?
- AnimalMuppet 7y ago
  Here's another unpopular opinion: Not much of the value of a DSL is in the syntax. That is, I'm trying to write a program to do X. In, say, C++, I create data structures and functions as building blocks to write the higher-level functionality of the program. That's my "DSL" - just classes (structures and functions). In Lisp, I can go further. In creating a DSL, I can not only create function (and, through functions, data structures), but I can also create syntax. This may let me write less code, and may make the code I write clearer. My assertion is that, while that's nice, most of the DSL is actually the functions and data structures. The syntax is sugar - say, maybe 10% of the benefit, but not more.
  - celeritascelery 7y ago
    > My assertion is that, while that's nice, most of the DSL is actually the functions and data structures. The syntax is sugar - say, maybe 10% of the benefit, but not more. I don’t know, thinking of some DSL’s like HTML or SQL, syntax seems to be a really big part it.
    - Lutger 7y ago
      It isn't immediately obvious that it is, to me. Could you expand on that? For example, what works for html is basically the dom (data structure) and its functionality (the functions). There are others ways of creating and working with those than the specific html syntax. For example, haml. Or you might say, jsx, or elm,is also such a syntax for the same data structures. These other approaches work perfectly fine, too.
      - celeritascelery 7y ago
        Touché. I understand better what your saying. But even though the syntax changes, we always have some specialized syntax for using it. But it does make it seem like the data is more important since that is what stays the same.
  - vidarh 7y ago
    Most constructs in most languages are syntactic sugar + varying degrees of enforcing constraints. The core you need to e.g an object oriented system or first order functions or any other higher level construct is tiny. You can do closures in C for example (done it). But it gets ugly and unreadable and hard to follow. Syntax matters hugely in making the expression of an idea concise and readable. Blocks in Ruby (or Smalltalk..) for example are pretty much just syntactic sugar over closures, are just syntactic sugar over functions, but both makes a substantial difference in ease of use, which again affects how people tend to think about problems. E.g we are much more sparing with closure like constructs in C, even though nothing prevents it, because it is tedious.
ColanR 7y ago
J fixed the second problem you have with APL, and many people think that was a mistake. What do you think the better version of lisp/apl/whatever would actually be? I get the idea of a simple 1 + 2, but that doesn't express all the power of what makes lisp lisp.
AnimalMuppet 7y ago
> One can create new languages fit for the purpose of a given class of problems and thus reducing size of codebase 10 to 100 fold (or even million times in case of modern multi million LOC software projects). I find that a bit hard to believe. Here's a 100 million line codebase; I seriously doubt that you can express it in 100 lines in any language. Lisp may be good, but it isn't that good.
- chubot 7y ago
  Yeah to be honest one of the things that made me skeptical of the code compression / productivity claim is looking at the implementations of Chez Scheme and Racket (after also looking at 20+ compilers / interpreters, and working on a language for a few years). I'm pointing to them as very long-lived and valuable codebases written in Lisp dialects. Chez Scheme is a 35 year old codebase and Racket is also decades old. So I'm not saying there's anything wrong with them, but I am saying that it doesn't appear that they're 10x easier to understand or modify than LLVM or CPython (Chez being a compiler and Racket being an interpreter as far as I remember). Or that you can get a 10x better result. Basically for the claim to be true, why can't you write something like Racket in Racket 10x faster? Like 3 years instead of 30 years. And why doesn't it do way better things than CPython or Ruby? Those claims might be "slightly" true depending on who you are, but they're not devastatingly true. There's been more than enough time to evaluate the claims empirically. In other words they would have already proven themselves in the market if that were the case. You would have extraordinarily productive teams using these languages -- along the lines of what PG hypothesized 15+ years ago. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html In fact the thing I found was interesting is that at the core of Racket is a big pile of C code, just like CPython. A year or 2 ago I watched a talk about them self-hosting more, and moving to Chez scheme's backend, but I don't recall the details now. https://github.com/cisco/ChezScheme https://github.com/cisco/ChezScheme https://en.wikipedia.org/wiki/Chez_Scheme https://en.wikipedia.org/wiki/Chez_Scheme https://github.com/racket/racket/tree/master/racket/src/racket https://github.com/racket/racket/tree/master/racket/src/rack... (FWIW I also looked at and hacked on femtolisp around the same time, since I was impressed by how Julia uses it.) correction: it looks like Racket has a JIT too, written in C. Still same point applies: it's not magic and looks a lot like similar codebases in C. Chez is more self hosted AFAIR but it's also hundreds of thousands of lines of code.
analbumcover 7y ago
> 1. reading from left to right This seems a strange quibble when it is an arbitrary convention that doesn't really matter in the slightest. It's just the natural extension of the usual mathematical function composition f(g(x)) to include dyadic functions and thus do away with function/operator precedence. It doesn't make things any easier or harder if you were to prefer generalizing ((x)g)f instead so that the language could be read left to right, it's just a different convention. > 2. use of phonetic alphabet instead of hyeroglyphs. The purpose of the symbols in APL is that they are meant to be a "tool for thought" [0]. But I'm a mathematician so I was already trained to this way of thinking. Using more verbose languages becomes an exercise in tedium, they make programming feel like trying to chop down a tree with a herring. The "hieroglyphs" are a large part of what make APL feel like wielding a lightsaber by comparison. [0] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...
- deleted 7y ago
  [deleted]
jcranmer 7y ago
> the important Phoenician discoveries of 1. reading from left to right 2. use of phonetic alphabet instead of hyeroglyphs. The Phoenician alphabet was written right-to-left or boustrophedon (alternating left-to-right and right-to-left, usually mirroring glyphs when writing them backwards). The Greeks appear to have started with boustrophedon writing and then settled with left-to-right writing. The other Semitic scripts that borrowed from Phoenician (e.g., Hebrew and Arabic) copied Phoenician's right-to-left writing direction. While we're being pedantic here, the Phoenicians also didn't invent an alphabet. They used an abjad, not recording any vowels. The Greeks were the first to create a true alphabet, adapting 'aleph (representing the glottal stop, which Greek did not have) into alpha (representing the open front unrounded vowel 'a'), he into epsilon, and 'ayin into omicron. Phoenician semivowels waw and yodh furnished upsilon and iota, respectively. A final point is that the principle of using glyphs to represent phonetic values does not originate even with Phoenician. The rebus principle was already present in both cuneiform and hieroglyphics, and Middle Egyptian already developed a full inventory of consonant glyphs, although these were not used exclusively.
- agumonkey 7y ago
  I use to dislike linguistics, but you made me change my mind. Any book suggestion on early language development ?
rustybolt 7y ago
Infix notation is closer to natural language, but it's only easier to read for simple expressions. You really have to know the precedence and associativity of each and every operator that is used to make sense of an expression.
lmm 7y ago
Interesting idea. How would you write functions of multiple arguments as infix? Scala can get close to myListOfInts foldLeft 0 + which is... honestly not much more readable. How do you resolve ambiguity when functions take optional arguments / are overloaded? Or would you not allow that?
- snidane 7y ago
  Make the right side of the function call a list or a dict. myListOfInts foldLeft (0, +) or if you make : to be right associative cons function myListOfInts foldLeft 0 : + or using dict myListOfInts foldLeft (zero: 0, op: +)
  - lmm 7y ago
    At that point you're introducing significantly more syntax, destroying the nice lisplike properties.

platform 7y ago

> One can create new languages fit for the purpose of a given class of problems and thus reducing size of codebase 10 to 100 fold interesting, thank you for sharing. Could I transpose your thought into: -- Solutions (or large scale programs), should not be written in a general purpose language. Instead, there should be core domain language (solution DSL) developed (using a general purpose language) and then the solution should be developed using the solution DSL. ?

AnimalMuppet 7y ago
Here's another unpopular opinion: Not much of the value of a DSL is in the syntax. That is, I'm trying to write a program to do X. In, say, C++, I create data structures and functions as building blocks to write the higher-level functionality of the program. That's my "DSL" - just classes (structures and functions). In Lisp, I can go further. In creating a DSL, I can not only create function (and, through functions, data structures), but I can also create syntax. This may let me write less code, and may make the code I write clearer. My assertion is that, while that's nice, most of the DSL is actually the functions and data structures. The syntax is sugar - say, maybe 10% of the benefit, but not more.
- celeritascelery 7y ago
  > My assertion is that, while that's nice, most of the DSL is actually the functions and data structures. The syntax is sugar - say, maybe 10% of the benefit, but not more. I don’t know, thinking of some DSL’s like HTML or SQL, syntax seems to be a really big part it.
  - Lutger 7y ago
    It isn't immediately obvious that it is, to me. Could you expand on that? For example, what works for html is basically the dom (data structure) and its functionality (the functions). There are others ways of creating and working with those than the specific html syntax. For example, haml. Or you might say, jsx, or elm,is also such a syntax for the same data structures. These other approaches work perfectly fine, too.
    - celeritascelery 7y ago
      Touché. I understand better what your saying. But even though the syntax changes, we always have some specialized syntax for using it. But it does make it seem like the data is more important since that is what stays the same.
- vidarh 7y ago
  Most constructs in most languages are syntactic sugar + varying degrees of enforcing constraints. The core you need to e.g an object oriented system or first order functions or any other higher level construct is tiny. You can do closures in C for example (done it). But it gets ugly and unreadable and hard to follow. Syntax matters hugely in making the expression of an idea concise and readable. Blocks in Ruby (or Smalltalk..) for example are pretty much just syntactic sugar over closures, are just syntactic sugar over functions, but both makes a substantial difference in ease of use, which again affects how people tend to think about problems. E.g we are much more sparing with closure like constructs in C, even though nothing prevents it, because it is tedious.

ColanR 7y ago

J fixed the second problem you have with APL, and many people think that was a mistake. What do you think the better version of lisp/apl/whatever would actually be? I get the idea of a simple 1 + 2, but that doesn't express all the power of what makes lisp lisp.

AnimalMuppet 7y ago

> One can create new languages fit for the purpose of a given class of problems and thus reducing size of codebase 10 to 100 fold (or even million times in case of modern multi million LOC software projects). I find that a bit hard to believe. Here's a 100 million line codebase; I seriously doubt that you can express it in 100 lines in any language. Lisp may be good, but it isn't that good.

chubot 7y ago
Yeah to be honest one of the things that made me skeptical of the code compression / productivity claim is looking at the implementations of Chez Scheme and Racket (after also looking at 20+ compilers / interpreters, and working on a language for a few years). I'm pointing to them as very long-lived and valuable codebases written in Lisp dialects. Chez Scheme is a 35 year old codebase and Racket is also decades old. So I'm not saying there's anything wrong with them, but I am saying that it doesn't appear that they're 10x easier to understand or modify than LLVM or CPython (Chez being a compiler and Racket being an interpreter as far as I remember). Or that you can get a 10x better result. Basically for the claim to be true, why can't you write something like Racket in Racket 10x faster? Like 3 years instead of 30 years. And why doesn't it do way better things than CPython or Ruby? Those claims might be "slightly" true depending on who you are, but they're not devastatingly true. There's been more than enough time to evaluate the claims empirically. In other words they would have already proven themselves in the market if that were the case. You would have extraordinarily productive teams using these languages -- along the lines of what PG hypothesized 15+ years ago. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html In fact the thing I found was interesting is that at the core of Racket is a big pile of C code, just like CPython. A year or 2 ago I watched a talk about them self-hosting more, and moving to Chez scheme's backend, but I don't recall the details now. https://github.com/cisco/ChezScheme https://github.com/cisco/ChezScheme https://en.wikipedia.org/wiki/Chez_Scheme https://en.wikipedia.org/wiki/Chez_Scheme https://github.com/racket/racket/tree/master/racket/src/racket https://github.com/racket/racket/tree/master/racket/src/rack... (FWIW I also looked at and hacked on femtolisp around the same time, since I was impressed by how Julia uses it.) correction: it looks like Racket has a JIT too, written in C. Still same point applies: it's not magic and looks a lot like similar codebases in C. Chez is more self hosted AFAIR but it's also hundreds of thousands of lines of code.

analbumcover 7y ago

> 1. reading from left to right This seems a strange quibble when it is an arbitrary convention that doesn't really matter in the slightest. It's just the natural extension of the usual mathematical function composition f(g(x)) to include dyadic functions and thus do away with function/operator precedence. It doesn't make things any easier or harder if you were to prefer generalizing ((x)g)f instead so that the language could be read left to right, it's just a different convention. > 2. use of phonetic alphabet instead of hyeroglyphs. The purpose of the symbols in APL is that they are meant to be a "tool for thought" [0]. But I'm a mathematician so I was already trained to this way of thinking. Using more verbose languages becomes an exercise in tedium, they make programming feel like trying to chop down a tree with a herring. The "hieroglyphs" are a large part of what make APL feel like wielding a lightsaber by comparison. [0] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...

deleted 7y ago
[deleted]

jcranmer 7y ago

> the important Phoenician discoveries of 1. reading from left to right 2. use of phonetic alphabet instead of hyeroglyphs. The Phoenician alphabet was written right-to-left or boustrophedon (alternating left-to-right and right-to-left, usually mirroring glyphs when writing them backwards). The Greeks appear to have started with boustrophedon writing and then settled with left-to-right writing. The other Semitic scripts that borrowed from Phoenician (e.g., Hebrew and Arabic) copied Phoenician's right-to-left writing direction. While we're being pedantic here, the Phoenicians also didn't invent an alphabet. They used an abjad, not recording any vowels. The Greeks were the first to create a true alphabet, adapting 'aleph (representing the glottal stop, which Greek did not have) into alpha (representing the open front unrounded vowel 'a'), he into epsilon, and 'ayin into omicron. Phoenician semivowels waw and yodh furnished upsilon and iota, respectively. A final point is that the principle of using glyphs to represent phonetic values does not originate even with Phoenician. The rebus principle was already present in both cuneiform and hieroglyphics, and Middle Egyptian already developed a full inventory of consonant glyphs, although these were not used exclusively.

agumonkey 7y ago
I use to dislike linguistics, but you made me change my mind. Any book suggestion on early language development ?

rustybolt 7y ago

Infix notation is closer to natural language, but it's only easier to read for simple expressions. You really have to know the precedence and associativity of each and every operator that is used to make sense of an expression.

lmm 7y ago

Interesting idea. How would you write functions of multiple arguments as infix? Scala can get close to myListOfInts foldLeft 0 + which is... honestly not much more readable. How do you resolve ambiguity when functions take optional arguments / are overloaded? Or would you not allow that?

snidane 7y ago
Make the right side of the function call a list or a dict. myListOfInts foldLeft (0, +) or if you make : to be right associative cons function myListOfInts foldLeft 0 : + or using dict myListOfInts foldLeft (zero: 0, op: +)
- lmm 7y ago
  At that point you're introducing significantly more syntax, destroying the nice lisplike properties.