Such old urban places would just be car-free in the Netherlands (sometimes with limited access for delivery and emergency vehicles), a trend fortunately becoming popular in other European cities now.
The “urban” in the title is a bit misleading, this intersection is definitely more suburban, or on the boundary of an urban center. (Or rather, the author has a different definition of urban - in my definition cities like den Bosch are really just a small medieval urban core surrounded by continuous medium-density suburban neighborhoods.)
I would love to see the diff between the hand-rolled recursive-descent parser and the ANTLR syntax!
I certainly feel the amount of boilerplate in my hand-rolled recursive-descent parser is manageable. Of course it's not as succinct as an EBNF grammar:
- For example, you have to write an actual loop (with "for" and looping conditions) instead of just * for repetition
- The Go formatter demands a newline in most control flows
- Go is also not the most succinct language in general
So you do end up with many more lines of code. But at the end of the day, the structure of each parsing function is remarkably similar to a production rule, and for simpler ones I can mentally map between them pretty easily, with the added benefit of being able to insert code anywhere if I need something beyond old-school context-free parsing.
Yeah, ultimately there's an element of personal taste at play.
The authoritative tone of "how to write ..." is meant in jest, but obviously by doing that I risk being misunderstood. A more accurate title would be "how I wrote ...", but it's slightly boring and I was trying hard to get my talk proposal accepted you see :)
Did you set your login shell to Elvish? Vim unfortunately relies on your shell being a POSIX shell, but you can fix that with "set shell=/bin/sh" in your rc file.
Right, I may have forgot to mention that lexerless parsers are somewhat unusual.
I didn't have much time in the talk to go into the reason, so here it is:
- You'll need a more complex lexer to parse a shell-like syntax. For example, one common thing you do with lexers is get rid of whitespaces, but shell syntax is whitespace sensitive: "a$x" and "a $x" (double quotes not part of the code) are different things: the first is a single word containing a string concatenation, the second is two separate words.
- If your parser backtracks a lot, lexing can improve performance: you're not going back characters, only tokens (and there are fewer tokens than characters). Elvish's parser doesn't backtrack. (It does use lookahead fairly liberally.)
Having a lexerless parser does mean that you have to constantly deal with whitespaces in every place though, and it can get a bit annoying. But personally I like the conceptual simplicity and not having to deal with silly tokens like LBRACE, LPAREN, PIPE.
I have not used parser generators enough to comment about the benefits of using them compared to writing a parser by hand. The handwritten one works well so far :)
As the sibling comment mentioned, you can find documentation on Elvish itself on the website https://elv.sh. There are tutorials and (not 100% but fairly complete) reference documents.
The remaining 8% mostly falls into the following categories:
- Code that use OS functionalities that are cumbersome to mock in tests
- Code paths that are triggered relatively rarely and I was simply too lazy to add tests for them
Nothing is impossible to cover, but for whatever reason it was too much work for me when I wrote the code.
However, it's worth mentioning that I only settled on the transcript test pattern fairly recently, and if I were to rewrite or refactor some of the untested code today I would add tests for them, because the cost of adding tests has been lowered considerably. So Elvish's test coverage is still increasing slowly as the cost of testing decreases.
That seems to be a bad translation, the original text means something like “sharpen something fully and it won’t last so long” (presumably due to it being more brittle). The text (like the rest of Tao Te Ching) is pretty vague and doesn’t actually refer to knives, so it could also be read metaphorically.
There is something missing in the "simple vs. easy" argument. You need to put things in the perspective of evolution.
Designing an "easy" language is easy because you can usually resort to human intuitions, yours or somebody's else. Everyone can tell your language is easy or not; although there is no single criteria of what is easy, it's still possible to come up with something that many people agree are easy.
Evolving easy languages is also not hard. Just follow the trend and keep making it easy to do whatever just became popular. Statistics, backend development, machine learning, whatever. If some early design choice turns out to be a bad move, just provide alternatives. People don't have very high expectations about the internal coherency of your langauge, so you have much freedom in evolving your language.
Designing a "simple" language is much harder because it requires a very deep understanding of the underlying structure of your runtime environment, the kinds of systems you want to build with the language, and the structure of computer programs in general. Appreciating easiness requires experience and insights, and simple things can appear complex when looking from a different perspective.
Even if you are super smart and came up with a amazingly simple language, that's only the beginning. Sooner or later, whether it's new area of programming or a design mistake surfacing, you need to evolve your language. And that is hard, because blindly adding features will destroy the simpleness and your language degenerates into an "easy" one. Instead, you need to carefully think about the natures of the new requirements, challenge the assumptions underneath the original design, and restructure your design. This process is often slow and can be more challenging than the original design process.
Of course as the article says, "simple" and "easy" is hardly a dichotomy; what I described are extreme cases, and most if not all languages fall somewhere in between and exhibit properties from both sides. But I think it's helpful to think the two dimensions in this way.