Hacker News new | past | comments | ask | show | jobs | submit login

If you want to do a really poor, minimal job of implementing something that processes and executes programs, you will find that most of the complexity will rest in handling syntax. Any reductions in that complexity will have a big relative impact on trimming down the code and amount of work.

Now you can duck out of implementing solid semantics, without changing what a language looks like. For instance, programs language with broken scope can look superficially like programs in a language with working lexical scope. Or, a language that works by interpreting a syntax tree using a few lines of code looks and works just as well as a compiled one, just slower.

But if you don't negotiate about what a language looks like, there is only so much simplification you can do while still correctly handling the syntax which allows the language to look like that.

Further reductions in complexity require simplifications in syntax (how the language looks), which leads toward one of several existing well-understood design families for minimal syntax: Lisp-like, Forth-like, APL-like.




I've implemented things with "Lisp syntax" a couple of times, neither of which had anything whatsoever to do with Lisp. I used to call it the "Lisp non-syntax".

Nowadays I usually bite the bullet and just use JSON or something, but if you want to implement an interpreter starting just from bare minimum string functions pretending you're in 1980 and can't just grab half-a-dozen serialization formats out of your language's package manager (not a bad thing to practice!), Lisp-non-syntax is still a pretty good choice.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: