I started writing this piece because a friend of mine recommended I write an article about Duck and post it on Reddit. I don't do a lot of writing and I started thinking about it and it seemed like it would really be a huge task.
HN crowd is a little bit more "sophisticated" so maybe that helps, but writing it I felt like it was going to be harder to get to the end when I started, so I really skipped over all of the details at the end. I'd like to give a better explanation of both the parsing step (to an understandable degree) and the interpreter itself, so that it is easier to follow along and implement the steps.
When I developed the project, it was sort of a stop-and-go process. I wrote an LR parser because I wanted to brush up on topics from a compilers course and it seemed like the most exhaustive way to do that. With adjustments, I can use the tables generated with any language to work on my next programming languages project.
After finishing the parser/parser generator, I was mainly throwing context-free grammars at the wall to see what was working or wasn't, without really analyzing them to see if the fit in the LR(1) category. I used a mini Java CFG I had from the compilers course and played around with that for a while, and I started working on a C grammar but that became annoyingly complex. Duck represented a kind of pseudocode that I could use.
Eventually I came back to it, maybe about a year or two later, and started to realize how easy it would be to get this thing able to run programs. So in about the course of a week I had the initial runtime functional.
I appreciate any advice for ways to explain it that might be better. I think this piece could use some editing. I would like to expand parts, I'm just concerned that it would be too long to read then. I think the initial suggestion was supposed to be a brief explanation, but I thought the only way to write this would be to go over everything completely.
I'll be sure to go back and improve this as it progresses. I've also been meaning to make improvements to the programming language itself, so I need to find a way to balance my spare time.
> ... so I really skipped over all of the details at the end. I'd like to give a better explanation of both the parsing step (to an understandable degree) and the interpreter itself, so that it is easier to follow along and implement the steps.
That pretty well describes the problem and the way to make it more digestible. Giving a step-by-step explanation of the parser will be very useful. Illustrating what the parser is doing with clear examples would be very helpful.
Reading it again, I think the "sticky" parts begin with discussion of the grammar. A couple of examples, then the reader encounters a blizzard of phrases, "<terminal>", "<non-terminal>", "<S>", etc., strewn through the explanatory paragraphs which rapidly become confusing. Readers may be wondering "what 'production' are we talking about now?" and so on. Once losing the thread it's impossible to follow the text all the way down.
True, HN attracts a more knowledgeable crowd. Even so I'm sure there are many here who are not that familiar with the intricacies of parsing but want to gain a better grasp of it. Condensing the article's preliminaries, while expanding the parsing (and subsequent) sections and slowing down the pace, would likely make it better for both author and the reader.
I started writing this piece because a friend of mine recommended I write an article about Duck and post it on Reddit. I don't do a lot of writing and I started thinking about it and it seemed like it would really be a huge task.
HN crowd is a little bit more "sophisticated" so maybe that helps, but writing it I felt like it was going to be harder to get to the end when I started, so I really skipped over all of the details at the end. I'd like to give a better explanation of both the parsing step (to an understandable degree) and the interpreter itself, so that it is easier to follow along and implement the steps.
When I developed the project, it was sort of a stop-and-go process. I wrote an LR parser because I wanted to brush up on topics from a compilers course and it seemed like the most exhaustive way to do that. With adjustments, I can use the tables generated with any language to work on my next programming languages project.
After finishing the parser/parser generator, I was mainly throwing context-free grammars at the wall to see what was working or wasn't, without really analyzing them to see if the fit in the LR(1) category. I used a mini Java CFG I had from the compilers course and played around with that for a while, and I started working on a C grammar but that became annoyingly complex. Duck represented a kind of pseudocode that I could use.
Eventually I came back to it, maybe about a year or two later, and started to realize how easy it would be to get this thing able to run programs. So in about the course of a week I had the initial runtime functional.
I appreciate any advice for ways to explain it that might be better. I think this piece could use some editing. I would like to expand parts, I'm just concerned that it would be too long to read then. I think the initial suggestion was supposed to be a brief explanation, but I thought the only way to write this would be to go over everything completely.
I'll be sure to go back and improve this as it progresses. I've also been meaning to make improvements to the programming language itself, so I need to find a way to balance my spare time.