6 ms·

I actually think that easy parsing is something you should try for. the easier your language is to parse, the less edge cases there are, and simpler it is for p

I actually think that easy parsing is something you should try for. the easier your language is to parse, the less edge cases there are, and simpler it is for programmers to understand. In short, I'd rather have Scheme than Ruby. But I seem to be in the minority...

martincmartin 11y ago
Also tools become much easier. There are few good refactoring tools for C++ because the language is almost impossible to parse. In fact, even generating tags for vim/emacs is nearly impossible.
- pldrnt 11y ago
  My thoughts exactly, as someone who has spent quite some time creating a (usable and readable) LALR syntax that can do everything modern C++ does (plus named arguments, a null-coalescing operator and extension methods) and is currently writing a transpiler based on it, I hope more people share your concern :)
  - nickpsecurity 11y ago
    Anyone who used Modula-3... https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 ...knows that one can have key features of C++ for systems programming with an easy-to-parse, safer, and [for a time] more efficient language. The SPIN OS team even modified it with type-safe linking so one could hotload code into the OS. What I saw there was "hotload code into running system" w/ associated benefits during updates. Or safer, better JIT. ;) Anyway, combined with LISP-style macros & irritating parts removed (eg uppercase, verbosity), you get a system language that blows C++ away in productivity (esp w/ DSL's), compiler efficiency, maintenance, and possibly run-time efficiency. The world might have went in a different direction but they better be honest about parsing pain they created. And all the productivity opportunities lost due to that.
    - msie 11y ago
      Takes me back to the past when Metrowerks created a Modula-2 compiler for the Mac: https://en.wikipedia.org/wiki/Metrowerks https://en.wikipedia.org/wiki/Metrowerks
      - nickpsecurity 11y ago
        Didn't know they started out with Wirth's compiler. Picked the best one. Then market rejected it. Then pivoted to a more successful approach supporting whatever crud was popular. The recurring pattern. Also didn't know they supported that many platforms. Impressive.
- lultimouomo 11y ago
  While syntax surely doesn't help, I think the real blocker is actually the preprocessor.
  - umanwizard 11y ago
    C has basically the same preprocessor, and ctags works mostly fine.
    - pjmlp 11y ago
      ctags is a pretty bare bones compared with what an IDE with semantic analysis is capable of.
  - qwertyuiop924 11y ago
    No, the real problem is the both C and C++ are context sensitive. (In C compilers, though not C++ ones, 'the lexer hack' is the most common solution) That's fairly hard to parse, although not as bad as some languages. For preprocessing, it's fairly easy to write a C preprocessor, and then look at how your code will look if various options are defined... Actually that would be a really good debugging tool. I should go write that. And then make an emacs mode for it, so that you can type one command at any point, and see how your function/file/whatever will be transformed by the preprocessor.
deleted 11y ago
[deleted]
bryanlarsen 11y ago
And I don't think that Walter Bright would necessarily disagree with you. My interpretation of his "false gods" list is that those are probably OK as secondary goals, but that the "true gods" list should be primary goals. In this case, "easy parsing" is OK, but not when it conflicts with "tried and true". Choosing Lisp as your "tried and true" is acceptable, though...
- Avshalom 11y ago
  Particularly he has CFG as a true god, for ease of parsing and tooling. Bright hangs out here so if he wants he can come in and expand but I think it's a case of look at the moon(CFG) not the finger(parsing ease) pointing at the moon.
brianberns 11y ago
Easy (for a computer) to parse does not necessarily mean simpler for programmers to understand. I think Lisp's deeply nested parens are a good example of this problem.
- pvitz 11y ago
  J is also quite easy to parse, but could be difficult to understand. (See e.g. http://sblom.github.io/openj-core/iojSent.htm#Parsing http://sblom.github.io/openj-core/iojSent.htm#Parsing)
  - stepvhen 11y ago
    J is one of my favorites. The syntax is cryptic at first, but the lack of ambiguity makes programs easier to understand and easier to design in the long run.
    - Avshalom 11y ago
      I dunno, I think proper anonymous functions would have been a lot better than hooks and forks. Though I'm not sure if that falls under syntax or semantics for purposes of this discussion.
- kevin_thibedeau 11y ago
  Lisp has never been fully implemented. If M-expressions were in active use (and modernized over time) there wouldn't be so much parentheses hell.
  - SpaceCadetJones 11y ago
    The only people who refer to it as parens hell seem to be non-lispers. As I understand it m-exps were never implemented because people don't really want them. I definitely prefer s-exps over them.
    - Avshalom 11y ago
epidemian 11y ago
I agree in that easy parsing is a good quality of languages. But i also think a language can have a rather rich (i.e. big) syntax that's also straightforward to parse. That is, that the dichotomy of either having a very lean syntax like Scheme or a bloated and complicated syntax like Ruby is not so clear-cut. The difficulty of parsing Ruby's syntax (both for machines and for humans) comes from some unfortunate design decisions, not so much from its vastness. For example, using the same symbols, {}, to denote hash literals and blocks makes parsing/understanding the syntax of method calls more difficult: def foo(*args) puts "args: #{args}, block_given?: #{block_given?}" end # Parentheses can be omitted when calling methods: foo # args: [], block_given?: false foo 42 # args: [42], block_given?: false foo 42, "bar" # args: [42, "bar"], block_given?: false # *Except* when the first argument is a hash. This: foo({}) # args: [{}], block_given?: false # Means something completely different than this: foo {} # args: [], block_given?: true # But if the hash is not the first argument then it's OK, you can omit parens # again :3 foo 42, {} # args: [42, {}], block_given?: false This is not a problem of having dedicated syntax for blocks and hash literals. It's a problem of having chosen conflicting syntactic forms for them. If blocks could only be denoted with do/end, or with a different set of symbols than hash literals, this would not be a problem. And this is just one example of conflicting syntactic forms. In Ruby, sadly, there many cases of this. E.g., using * both for multiplication and for argument "splatting" means that a * b is not the same as a *b when `a` is a method, but actually is the same when `a` is a local variable; or `foo "bar"` and `foo"bar"` being two perfectly valid ways of calling foo with "bar" as an argument, but `foo [42]` and `foo[42]` not being two perfectly valid ways of calling foo with [42] as an argument; and probably more. So, as long as syntactic forms are carefully chosen so that they don't have weird and conflicting edge cases between each other, i think a language can have a rather big syntax without it being difficult to parse/understand. Disclaimer: i love Ruby; it's my bread-and-butter language. But i wish it didn't have as many syntax quirks as it does :)
- qwertyuiop924 11y ago
  This is what I mean. Syntactic ambiguity is evil, and pretty common. Even C has it (google "lexer hack"). And I definitely think that Scheme could do with a bit more syntax. Some of the whitespace indent extensions (WISP, for example) are nice, and I could do with hash table literals. So I'm off to go write those...:-D
nbardy 11y ago
When I first started writing Lisp I was put off by how simple the syntax was. Everything looks the same and it was so hard to tells things apart. After working with Lisp for a long enough time I began to love the simplicity. Everything is so simple, nothing gets in the way of reading code.
- moron4hire 11y ago
  To poorly paraphrase Bruce Lee: "When I first started to learn Lisp, I thought it was all just parens. After I truly learned Lisp, I realized it is all just parens."
mindslight 11y ago
Humans like parsing - witness the love for mathematical notation. It takes time to learn the grammar, but after that it's a background process. Simpler general parsing (eg Lisp) is more powerful, but that's a negative for learnability of the language.
chipsy 11y ago
The simplest parser style is assembly code: one line, at most one statement. But there's always some desire to get a little more code density than assembly, it's just a matter of how one wants to go about the problem. The syntax of older-style BASIC, for example, hews close to the assembly parsing model, just adding a few special cases for different keywords. Algol syntax has a tradition of design based around algorithm description first, with generalized power second. The Forth or Lisp approaches, because they are very generic and powerful, naturally pull those languages in the direction of extensive metaprogramming. In that sense one can see that the more sugary syntaxes treat the programmer more like an end-user, because they direct the workflow. Generalized ones encourage a DIY approach to everything. There are tradeoffs to each strategy.

martincmartin 11y ago

Also tools become much easier. There are few good refactoring tools for C++ because the language is almost impossible to parse. In fact, even generating tags for vim/emacs is nearly impossible.

pldrnt 11y ago
My thoughts exactly, as someone who has spent quite some time creating a (usable and readable) LALR syntax that can do everything modern C++ does (plus named arguments, a null-coalescing operator and extension methods) and is currently writing a transpiler based on it, I hope more people share your concern :)
- nickpsecurity 11y ago
  Anyone who used Modula-3... https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 ...knows that one can have key features of C++ for systems programming with an easy-to-parse, safer, and [for a time] more efficient language. The SPIN OS team even modified it with type-safe linking so one could hotload code into the OS. What I saw there was "hotload code into running system" w/ associated benefits during updates. Or safer, better JIT. ;) Anyway, combined with LISP-style macros & irritating parts removed (eg uppercase, verbosity), you get a system language that blows C++ away in productivity (esp w/ DSL's), compiler efficiency, maintenance, and possibly run-time efficiency. The world might have went in a different direction but they better be honest about parsing pain they created. And all the productivity opportunities lost due to that.
  - msie 11y ago
    Takes me back to the past when Metrowerks created a Modula-2 compiler for the Mac: https://en.wikipedia.org/wiki/Metrowerks https://en.wikipedia.org/wiki/Metrowerks
    - nickpsecurity 11y ago
      Didn't know they started out with Wirth's compiler. Picked the best one. Then market rejected it. Then pivoted to a more successful approach supporting whatever crud was popular. The recurring pattern. Also didn't know they supported that many platforms. Impressive.
lultimouomo 11y ago
While syntax surely doesn't help, I think the real blocker is actually the preprocessor.
- umanwizard 11y ago
  C has basically the same preprocessor, and ctags works mostly fine.
  - pjmlp 11y ago
    ctags is a pretty bare bones compared with what an IDE with semantic analysis is capable of.
- qwertyuiop924 11y ago
  No, the real problem is the both C and C++ are context sensitive. (In C compilers, though not C++ ones, 'the lexer hack' is the most common solution) That's fairly hard to parse, although not as bad as some languages. For preprocessing, it's fairly easy to write a C preprocessor, and then look at how your code will look if various options are defined... Actually that would be a really good debugging tool. I should go write that. And then make an emacs mode for it, so that you can type one command at any point, and see how your function/file/whatever will be transformed by the preprocessor.

deleted 11y ago

[deleted]

bryanlarsen 11y ago

And I don't think that Walter Bright would necessarily disagree with you. My interpretation of his "false gods" list is that those are probably OK as secondary goals, but that the "true gods" list should be primary goals. In this case, "easy parsing" is OK, but not when it conflicts with "tried and true". Choosing Lisp as your "tried and true" is acceptable, though...

Avshalom 11y ago
Particularly he has CFG as a true god, for ease of parsing and tooling. Bright hangs out here so if he wants he can come in and expand but I think it's a case of look at the moon(CFG) not the finger(parsing ease) pointing at the moon.

brianberns 11y ago

Easy (for a computer) to parse does not necessarily mean simpler for programmers to understand. I think Lisp's deeply nested parens are a good example of this problem.

pvitz 11y ago
J is also quite easy to parse, but could be difficult to understand. (See e.g. http://sblom.github.io/openj-core/iojSent.htm#Parsing http://sblom.github.io/openj-core/iojSent.htm#Parsing)
- stepvhen 11y ago
  J is one of my favorites. The syntax is cryptic at first, but the lack of ambiguity makes programs easier to understand and easier to design in the long run.
  - Avshalom 11y ago
    I dunno, I think proper anonymous functions would have been a lot better than hooks and forks. Though I'm not sure if that falls under syntax or semantics for purposes of this discussion.
kevin_thibedeau 11y ago
Lisp has never been fully implemented. If M-expressions were in active use (and modernized over time) there wouldn't be so much parentheses hell.
- SpaceCadetJones 11y ago
  The only people who refer to it as parens hell seem to be non-lispers. As I understand it m-exps were never implemented because people don't really want them. I definitely prefer s-exps over them.
  - Avshalom 11y ago

epidemian 11y ago

I agree in that easy parsing is a good quality of languages. But i also think a language can have a rather rich (i.e. big) syntax that's also straightforward to parse. That is, that the dichotomy of either having a very lean syntax like Scheme or a bloated and complicated syntax like Ruby is not so clear-cut. The difficulty of parsing Ruby's syntax (both for machines and for humans) comes from some unfortunate design decisions, not so much from its vastness. For example, using the same symbols, {}, to denote hash literals and blocks makes parsing/understanding the syntax of method calls more difficult: def foo(*args) puts "args: #{args}, block_given?: #{block_given?}" end # Parentheses can be omitted when calling methods: foo # args: [], block_given?: false foo 42 # args: [42], block_given?: false foo 42, "bar" # args: [42, "bar"], block_given?: false # *Except* when the first argument is a hash. This: foo({}) # args: [{}], block_given?: false # Means something completely different than this: foo {} # args: [], block_given?: true # But if the hash is not the first argument then it's OK, you can omit parens # again :3 foo 42, {} # args: [42, {}], block_given?: false This is not a problem of having dedicated syntax for blocks and hash literals. It's a problem of having chosen conflicting syntactic forms for them. If blocks could only be denoted with do/end, or with a different set of symbols than hash literals, this would not be a problem. And this is just one example of conflicting syntactic forms. In Ruby, sadly, there many cases of this. E.g., using * both for multiplication and for argument "splatting" means that a * b is not the same as a *b when `a` is a method, but actually is the same when `a` is a local variable; or `foo "bar"` and `foo"bar"` being two perfectly valid ways of calling foo with "bar" as an argument, but `foo [42]` and `foo[42]` not being two perfectly valid ways of calling foo with [42] as an argument; and probably more. So, as long as syntactic forms are carefully chosen so that they don't have weird and conflicting edge cases between each other, i think a language can have a rather big syntax without it being difficult to parse/understand. Disclaimer: i love Ruby; it's my bread-and-butter language. But i wish it didn't have as many syntax quirks as it does :)

qwertyuiop924 11y ago
This is what I mean. Syntactic ambiguity is evil, and pretty common. Even C has it (google "lexer hack"). And I definitely think that Scheme could do with a bit more syntax. Some of the whitespace indent extensions (WISP, for example) are nice, and I could do with hash table literals. So I'm off to go write those...:-D

nbardy 11y ago

When I first started writing Lisp I was put off by how simple the syntax was. Everything looks the same and it was so hard to tells things apart. After working with Lisp for a long enough time I began to love the simplicity. Everything is so simple, nothing gets in the way of reading code.

moron4hire 11y ago
To poorly paraphrase Bruce Lee: "When I first started to learn Lisp, I thought it was all just parens. After I truly learned Lisp, I realized it is all just parens."

mindslight 11y ago

Humans like parsing - witness the love for mathematical notation. It takes time to learn the grammar, but after that it's a background process. Simpler general parsing (eg Lisp) is more powerful, but that's a negative for learnability of the language.

chipsy 11y ago

The simplest parser style is assembly code: one line, at most one statement. But there's always some desire to get a little more code density than assembly, it's just a matter of how one wants to go about the problem. The syntax of older-style BASIC, for example, hews close to the assembly parsing model, just adding a few special cases for different keywords. Algol syntax has a tradition of design based around algorithm description first, with generalized power second. The Forth or Lisp approaches, because they are very generic and powerful, naturally pull those languages in the direction of extensive metaprogramming. In that sense one can see that the more sugary syntaxes treat the programmer more like an end-user, because they direct the workflow. Generalized ones encourage a DIY approach to everything. There are tradeoffs to each strategy.