4 ms·

Programming languages force programmers to think clearly and express ideas unambiguously. It's not a bad thing we should avoid; it helps us write robust softwar

Programming languages force programmers to think clearly and express ideas unambiguously. It's not a bad thing we should avoid; it helps us write robust software.

Zak 16y ago
Both points are valid. Programming languages should be designed for people to use, and only secondarily for machines to execute. However, they should be designed so as to encourage clear expression of ideas when practical. I think whether a general-purpose language should discourage or prevent unclear thinking is an open question. I don't think I've seen an example of a language doing so without being somehow crippled, and that's a Bad Thing.
- binaryfinery 16y ago
  " Programming languages should be designed for people to use" Exactly. Which means that it must be tool friendly, hence LALR/LL(k). Unless you want to do all your refactoring yourself.
  - singular 16y ago
    I don't think LALR/LL(k) implies automated refactoring is easy and anything else does not!! Obviously non-context-free grammars are a problem, but a GLR or PEG grammar is still perfectly refactorable. You forget that refactoring an intuitive grammar to LALR involves totally mangling that grammar and making it more difficult for everyone. If the language is expressed as a GLR or PEG grammar then tool makers have it easier I reckon - easier to understand grammar. The way to really ensure it's easy for everyone is for the compiler write to provide some abstract yet intuitive representation of the underlying grammar. It really isn't an either/or, it's a case of both at once, I think!
    - binaryfinery 16y ago
      I think you hit the nail on the head there. "Context-free" is more of a requirement than LALR or LL. The author clearly isn't a parser writer. I am, but I've yet to try a PEG grammar because ANTLR does such a great job. But this doesn't change his point (or mine): languages should be created that are easy to write parsers for, so that its easier to write good tools. And I think this applies to the grammar too: ANTLR's .g files are a good grammar language because its easy to write tools for - hence AntlrWorks.
      - beza1e1 16y ago
        I'm the author and i did write some parsers. However i'm more in the write-parser-by-hand camp and context-free is not so hard here. ANTLR needs strange hacks to parse Python with its whitespace indentation. A handwritten parser just needs some context within the lexer. In my eyes a parser generator is the solution, if you want to trade efficiency for cross-language-portability. ANTLR is probably the best solution at this point, though the C backend is quite wierd.
        binaryfinery 16y ago
        I like to get shit working first, and then downcode if the PG does a horrible job. Nothing better than a hand-written anything, but I like the options of tools. Stange hacks for python supports your original argument I believe.
joe_the_user 16y ago
There's no language of higher order than machine code that allows you to specify computer behavior unambiguously (even that's doubtful). In fact, any entity abstract enough to be called "an idea" is going to be ambiguously specified. The question is what sort of ambiguity is most useful - ambiguity about about which object shows itself on the screen is great in an object-orient window manager. Ambiguity about which memory location to read when dereferencing an uninitialized pointer is less useful.

Programming languages force programmers to think clearly and express ideas unambiguously. It's not a bad thing we should avoid; it helps us write robust software.

Zak 16y ago

Both points are valid. Programming languages should be designed for people to use, and only secondarily for machines to execute. However, they should be designed so as to encourage clear expression of ideas when practical. I think whether a general-purpose language should discourage or prevent unclear thinking is an open question. I don't think I've seen an example of a language doing so without being somehow crippled, and that's a Bad Thing.

binaryfinery 16y ago
" Programming languages should be designed for people to use" Exactly. Which means that it must be tool friendly, hence LALR/LL(k). Unless you want to do all your refactoring yourself.
- singular 16y ago
  I don't think LALR/LL(k) implies automated refactoring is easy and anything else does not!! Obviously non-context-free grammars are a problem, but a GLR or PEG grammar is still perfectly refactorable. You forget that refactoring an intuitive grammar to LALR involves totally mangling that grammar and making it more difficult for everyone. If the language is expressed as a GLR or PEG grammar then tool makers have it easier I reckon - easier to understand grammar. The way to really ensure it's easy for everyone is for the compiler write to provide some abstract yet intuitive representation of the underlying grammar. It really isn't an either/or, it's a case of both at once, I think!
  - binaryfinery 16y ago
    I think you hit the nail on the head there. "Context-free" is more of a requirement than LALR or LL. The author clearly isn't a parser writer. I am, but I've yet to try a PEG grammar because ANTLR does such a great job. But this doesn't change his point (or mine): languages should be created that are easy to write parsers for, so that its easier to write good tools. And I think this applies to the grammar too: ANTLR's .g files are a good grammar language because its easy to write tools for - hence AntlrWorks.
    - beza1e1 16y ago
      I'm the author and i did write some parsers. However i'm more in the write-parser-by-hand camp and context-free is not so hard here. ANTLR needs strange hacks to parse Python with its whitespace indentation. A handwritten parser just needs some context within the lexer. In my eyes a parser generator is the solution, if you want to trade efficiency for cross-language-portability. ANTLR is probably the best solution at this point, though the C backend is quite wierd.
      - binaryfinery 16y ago
        I like to get shit working first, and then downcode if the PG does a horrible job. Nothing better than a hand-written anything, but I like the options of tools. Stange hacks for python supports your original argument I believe.

joe_the_user 16y ago

There's no language of higher order than machine code that allows you to specify computer behavior unambiguously (even that's doubtful). In fact, any entity abstract enough to be called "an idea" is going to be ambiguously specified. The question is what sort of ambiguity is most useful - ambiguity about about which object shows itself on the screen is great in an object-orient window manager. Ambiguity about which memory location to read when dereferencing an uninitialized pointer is less useful.