5 ms·

I'm interested in how this compares to other languages with reference implementations. Is ruby the odd one out here, not providing a formal grammar, or is that

• masklinn 14y ago
  > Ruby has a stated design goal of making developers happy. As far as I'm aware, it hasn't been designed to be easily parsed. That does not mean they're opposite goals. Having parsing ambiguities means insufficient thought has been given to parsing, or the language has been defined as "as implemented" with an ad-hoc and organically grown parser (other examples of such case: Perl, PHP) > I, as an end user (i.e. programmer), prefer it this way. You prefer that languages have broken, inane or completely missing grammars? So you like PHP even more than Ruby?
  • cllns 14y ago
    > That does not mean they're opposite goals. Having parsing ambiguities means insufficient thought has been given to parsing, or the language has been defined as "as implemented" with an ad-hoc and organically grown parser (other examples of such case: Perl, PHP) Of course they're not opposite, but you have to choose what to focus on. > You prefer that languages have broken, inane or completely missing grammars? So you like PHP even more than Ruby? Sorry if it wasn't clear, I was comparing easy parsing to developer happiness. That is, I prefer a language tries to make me happy rather than be easy to parse. (this goes back to your point above)
    • nine_k 14y ago
      A language which is hard to parse for a computer is often hard to parse for a human. For instance, computers have fewer problems with the amount of short-term context memory. 'Magic' is often considered bad because it's inexplicable, while clarity is a principal virtue of a programming language in the eyes of many. This is the key problem with DWIM interfaces in general. When it does what you mean, it's so nice. But sometimes you're stuck with ambiguity and lack of a precise means of expression; then you have to jump through hoops to push the 'intuitive' thing out of your way. (Curiously, both MS Word and Perl, of all things, manifest this problem.)
      • jshen 14y ago
        "A language which is hard to parse for a computer is often hard to parse for a human." Whether it often is the case isn't relevant. It may be possible, or even necessary, to make a language hard to parse in order to make it better for the programmer. Otherwise, by your logic LISP is by definition the best programming language. That maybe be true, but I'm not sure if you would follow your own logic to it's logical conclusion.
        • klibertp 14y ago
          "LISP is by definition the best programming language" Well, that's exactly right, it is the best! Not sure for the GP but I would follow this logic to this conclusion happily :) Um, er... Sorry, I just recently wrote my first program in Lisp (in Racket exactly) that was something more than a few tens of lines of code and am very happy because of this and I couldn't resist posting this here :)
        • deleted 14y ago
          [deleted]
        • krichman 14y ago
          There was no claim that a language that is easy to parse for a computer is always easy to parse for a human. And you don't present any data that easier to parse for the human makes it better other than that you like it. I like Ruby too, it's actually my favorite language because it's so easy to do metaprogramming, but sometimes I wish it were clearer what the execution will be even if that comes at the expense of some clarity elsewhere.
    • masklinn 14y ago
      > Sorry if it wasn't clear, I was comparing easy parsing to developer happiness. The problem is that this is a statement which does not make sense. You can have both. And as nine_k notes, a language which can also be harder to read: an ambiguous syntax is also ambiguous for a human reader.
      • cllns 14y ago
        Maybe it'd be better to think about this as a list of priorities, where there has to be ordinality. For example, developer happiness is the first priority, and ease of parsing falls somewhere further down. When Matz was creating the language, when he came across a problem with multiple solutions, he picked the one that would result in highest developer happiness, not which one is easier for the parser. Is that a better way of wording it?
        • ori_b 14y ago
          I believe we understand the dichotomy you're trying to point out, and calling it a false one. It is possible (and often correlated) to maximize developer happiness with an easy to parse syntax.
  • mnarayan01 14y ago
    > Having parsing ambiguities means insufficient thought has been given to parsing, or the language has been defined as "as implemented" with an ad-hoc and organically grown parser (other examples of such case: Perl, PHP) Also C, Java, really just about every language in common usage.
    • brazzy 14y ago
      Not sure about C, but definitely not true for Java. Or C#. Or Python. Or Pascal.
• lucian1900 14y ago
  Python, Haskell, Java, Go have formal and even context-free grammars. It makes me as a developer happy since it's much easier to predict how the language will parse something.
  • cllns 14y ago
    Ah okay. Cool, thanks!
  • peterwoo 14y ago
    Python is not context free.
    • masklinn 14y ago
      And there's no way java is. Not sure about Go.
      • lucian1900 14y ago
        The Java language specification includes a description of the language as a context free grammar. That alone does not make it a nice language, of course.
        • masklinn 14y ago
          > The Java language specification includes a description of the language as a context free grammar. I can only assume that it's lying its pants off, as I noted in an other subthread `(a) - (b)` can't be parsed (to an AST) without knowing the identity of `a` in the current scope: if it's a type the expression is a cast of `-(b)` to `a`, if it's a value it's a subtraction of `(b)` from `(a)`.
          • peterwoo 14y ago
            It can be parsed to an AST -- as you note, it can be parsed into two ASTs. It's called an ambiguous grammar, which can still be context free.