12 ms·

> I don't think removing the parser will take you across the finish line if you otherwise were running out of steam. Everyone's different. The problem with par

> I don't think removing the parser will take you across the finish line if you otherwise were running out of steam. Everyone's different. The problem with parsing isn't the difficulty, but rather the potential for endless bikeshedding. You're having to make a ton of opinionated decisions that in turn produce more questions about your syntax. If your personality is like mine in that it's a bit obsessive "completing" a phase, then parsing feels like an endless quagmire. In comparison, AST -> type inference -> codegen feels more structured and straightforward.

rewmie 3y ago
> The problem with parsing isn't the difficulty, but rather the potential for endless bikeshedding. You're having to make a ton of opinionated decisions that in turn produce more questions about your syntax. I fail to see your point. OP was commenting on the technical difficulty of actually rolling out a parser, but you're not arguing the technical side. You're arguing the project management sides where "endless bike shedding" results in code churn. That's not the parser's fault, but the person's fault. You're bound to get hung up on details regardless of what part of the project you're working on, because it's not the parser compelling you to get hung up on details.
- convolvatron 3y ago
  but it is. language syntax design is a total sinkhole. you give me a spec - I'll crap out a parser for you. tell me to design a textual language and chances are pretty good I won't get back to you. and if I do, chances are really high that you're gonna want me to do something different.
  - rewmie 3y ago
    > language syntax design is a total sinkhole. Sintax design, not implementing a parser. You're arguing that you might not make up your mind and feel compelled to churn parts of your implementation due to your indecisiveness. That's not the parser's fault, and I fail to see how anyone avoids this indecisiveness by replacing a proper parser with a bunch of ad-hoc hacks. > chances are really high that you're gonna want me to do something different. So what? Just work on it. How many parser generator tools are there? It's as if people have been doing this for decades.
- lmm 3y ago
  > That's not the parser's fault, but the person's fault. You're bound to get hung up on details regardless of what part of the project you're working on, because it's not the parser compelling you to get hung up on details. Disagree. The fact that you're working on "a parser" creates the bad project structure that leads you to get hung up on details: a parser whose backend doesn't exist yet inherently has unclear requirements and a lot of bikesheddy decisions to make.
thunderseethe 3y ago
This captures exactly the sentiment I was trying to express. Thanks for chiming in!
giovannibonetti 3y ago
That explains why Lisp is so convenient for implementing DSLs. Homoiconicity skips all the bike shedding around syntax and parsing.
- nielsbot 3y ago
  Lisp: "We got around parsing by getting rid of the syntax!" :)
  - eru 3y ago
    Lisp has syntax. It's just usually fairly straightforward (for the most parts). Forth also has an interesting simple syntax.
    - deredede 3y ago
      "Lisp has no syntax" really means "Lisp has no specific syntax". Any well-parenthesized S-expr is a syntactically valid Lisp program, even if it is nonsensical. Most other languages (including Forth) have keyword and syntax-dependent structuring.
      - eru 3y ago
        > Any well-parenthesized S-expr is a syntactically valid Lisp program, even if it is nonsensical. Which version of Lisp are you talking about? A very brief web search showed eg https://stackoverflow.com/questions/40210896/syntax-error-in-dr-racket https://stackoverflow.com/questions/40210896/syntax-error-in... For something really simple, try `(define define)` in Scheme. I'd say Forth has less syntax than Lisp. But that's perhaps a reflection of most Forth implementations using some clever tricks to offload much of what's handled by syntax in other languages. Eg defining new functions (ie 'words' in Forth terms) is not done via a special syntactic construct in Forth, but via 'immediate words'. The lines are a but blurry, though.
        deredede 3y ago
danybittel 3y ago
You need to better define the goal of your PL. If you have an exact vision of your end user and what she or he is going to use it for, it becomes easier to navigate any trade offs.
LoganDark 3y ago
> The problem with parsing isn't the difficulty, but rather the potential for endless bikeshedding. You're having to make a ton of opinionated decisions that in turn produce more questions about your syntax. Considering the author is talking about an endless graveyard of abandoned projects it kind of sounds like ADHD. I have ADHD and have a similar problem. I still do endless bikeshedding where I'll do things like insist on zero memory allocations or streams/iterators over slices and those arbitrary limitations will completely compromise the project. Either I never finish it because I can't get it to work, or I get it to work but it sucks because of stuff like "the amount of work to avoid memory allocation might be much larger than the work of just making a damn memory allocation".

rewmie 3y ago

> The problem with parsing isn't the difficulty, but rather the potential for endless bikeshedding. You're having to make a ton of opinionated decisions that in turn produce more questions about your syntax. I fail to see your point. OP was commenting on the technical difficulty of actually rolling out a parser, but you're not arguing the technical side. You're arguing the project management sides where "endless bike shedding" results in code churn. That's not the parser's fault, but the person's fault. You're bound to get hung up on details regardless of what part of the project you're working on, because it's not the parser compelling you to get hung up on details.

convolvatron 3y ago
but it is. language syntax design is a total sinkhole. you give me a spec - I'll crap out a parser for you. tell me to design a textual language and chances are pretty good I won't get back to you. and if I do, chances are really high that you're gonna want me to do something different.
- rewmie 3y ago
  > language syntax design is a total sinkhole. Sintax design, not implementing a parser. You're arguing that you might not make up your mind and feel compelled to churn parts of your implementation due to your indecisiveness. That's not the parser's fault, and I fail to see how anyone avoids this indecisiveness by replacing a proper parser with a bunch of ad-hoc hacks. > chances are really high that you're gonna want me to do something different. So what? Just work on it. How many parser generator tools are there? It's as if people have been doing this for decades.
lmm 3y ago
> That's not the parser's fault, but the person's fault. You're bound to get hung up on details regardless of what part of the project you're working on, because it's not the parser compelling you to get hung up on details. Disagree. The fact that you're working on "a parser" creates the bad project structure that leads you to get hung up on details: a parser whose backend doesn't exist yet inherently has unclear requirements and a lot of bikesheddy decisions to make.

thunderseethe 3y ago

This captures exactly the sentiment I was trying to express. Thanks for chiming in!

giovannibonetti 3y ago

That explains why Lisp is so convenient for implementing DSLs. Homoiconicity skips all the bike shedding around syntax and parsing.

nielsbot 3y ago
Lisp: "We got around parsing by getting rid of the syntax!" :)
- eru 3y ago
  Lisp has syntax. It's just usually fairly straightforward (for the most parts). Forth also has an interesting simple syntax.
  - deredede 3y ago
    "Lisp has no syntax" really means "Lisp has no specific syntax". Any well-parenthesized S-expr is a syntactically valid Lisp program, even if it is nonsensical. Most other languages (including Forth) have keyword and syntax-dependent structuring.
    - eru 3y ago
      > Any well-parenthesized S-expr is a syntactically valid Lisp program, even if it is nonsensical. Which version of Lisp are you talking about? A very brief web search showed eg https://stackoverflow.com/questions/40210896/syntax-error-in-dr-racket https://stackoverflow.com/questions/40210896/syntax-error-in... For something really simple, try `(define define)` in Scheme. I'd say Forth has less syntax than Lisp. But that's perhaps a reflection of most Forth implementations using some clever tricks to offload much of what's handled by syntax in other languages. Eg defining new functions (ie 'words' in Forth terms) is not done via a special syntactic construct in Forth, but via 'immediate words'. The lines are a but blurry, though.
      - deredede 3y ago

danybittel 3y ago

You need to better define the goal of your PL. If you have an exact vision of your end user and what she or he is going to use it for, it becomes easier to navigate any trade offs.

LoganDark 3y ago

> The problem with parsing isn't the difficulty, but rather the potential for endless bikeshedding. You're having to make a ton of opinionated decisions that in turn produce more questions about your syntax. Considering the author is talking about an endless graveyard of abandoned projects it kind of sounds like ADHD. I have ADHD and have a similar problem. I still do endless bikeshedding where I'll do things like insist on zero memory allocations or streams/iterators over slices and those arbitrary limitations will completely compromise the project. Either I never finish it because I can't get it to work, or I get it to work but it sucks because of stuff like "the amount of work to avoid memory allocation might be much larger than the work of just making a damn memory allocation".