Commit 20499546 authored by Nicolas Lenz's avatar Nicolas Lenz
Browse files

Update Language design

parent 67470129
Pipeline #1093 passed with stage
in 8 seconds
......@@ -6,11 +6,13 @@ discussion: https://forum.eisfunke.com/t/language-design-machine-or-human
abstract: When designing a computer language, be it for programming, data exchange, document markup or configuration, the first thing you should do is decide as to whether your language is meant for use by humans or by machines. Well, obviously, every language will be used by both, but still, who is your main target audience?
---
This question is important because depending on your answer, there are a few specific contradicting design principle that you should follow.
This question is important because depending on your answer there are a few specific contradicting design principles that you should follow.
### Easy to Parse **vs.** Easy to Read
It should be easy to write parsers for machine language. The syntax should therefore be very explicit and the grammar simple without syntactic sugar. A good example is [JSON](): There are booleans, numbers, strings, lists and dicts, each with a clearly distinguishably syntax without exceptions. That's it. I can write a parser for it in very little time. Another example is [Scheme](https://en.wikipedia.org/wiki/Scheme_(programming_language)) or [Lisp](https://en.wikipedia.org/wiki/Lisp_(programming_language)): Its exhaustive bracketing makes it easy to parse[^scheme] as there is, among other things, no operator precedence to consider, but it makes it harder to read.
It should be easy to write parsers for machine language. The syntax should be very explicit and the grammar simple without unnecessary syntactic sugar. A good example is [JSON](): There are booleans, numbers, strings, lists and dicts, each with a clearly distinguishable syntax without exceptions. That's it. I can write a parser for it in very little time. That makes JSON well-suited as an data interchange language for APIs or in other places where humans will never have to touch it directly.
Another example of something easy to parse is the bracketing of [Scheme](https://en.wikipedia.org/wiki/Scheme_(programming_language)) or [Lisp](https://en.wikipedia.org/wiki/Lisp_(programming_language)): Its exhaustive bracketing makes it easy to parse[^scheme] — there is, among other things, no operator precedence to consider.
However, a language that is easy to parse through a machine is not necessarily easy to read for a human. JSON is easy to parse, but [YAML](https://yaml.org/)[^yaml] is easier to read, as it has pretty syntactic sugar (e.g. you can often leave out the quotes), less syntactic noise and enforces using line breaks. Things that make it harder to parse, but easier to read.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment