In a bigger program, and because this approach seems to encourage the proliferation of DLS, one has to do the same process repeatedly. It seems to be a lot of context a developer has to maintain in their head.
How does it know that line starting with a number translates into a switch case. Is it the case for all function definitions or just because it's named getLocation?
In any case some logic is hidden there and making the ~10x size reduction is dubious. It only works because there is some other code that's not show here that implements that casing logic.
The example is arbitrary. In a real world use case, Ohayo, with a very large and complex program, my ES6 code base is reduced by a factor of 10x.
My tests, in an ETN, are super simple to run, run concurrently, and are about 400 lines of code. They are equivalent to about 4k lines of very good ES6.
The tests cover about 70% of all branches in the app (that test coverage number isn't near 100% because lots of files are still experimental and I haven't segmented those out yet in Istanbul). Being able to write great test coverage concisely has been one of my favorite uses for ETNs so far.
I guess a lot comes down to tooling, will Ohayo be able to understand the various DSLs to extract meaningful context or is it more like a tree editor?
Your point is a great one. I could write a program in bash with 2 words that might take dozens of nodes in Python:
wget https://news.ycombinator.com/
LISP programmers are used to this. ETNs are very much like Lisp, except it removes the AST parse step (and the parentheses!), leaving the resulting programs simpler than their Lisp equivalents.
I don't see how this is different from:
Sweet Expressions:
- https://www.dwheeler.com/readable/
Wisp:
- http://dustycloud.org/blog/wisp-lisp-alternative/
and some others.
{"abc def": ["123 456", 789, 101112, null, false]}
obj
abc def
arr
str 123 456
num 789
num 101112
null
bool f
s: StringNode
n: NumberNode
a: ArrayNode
o: ObjectNode
b: BooleanNode
j: OtherNode
It used to pass every test, but I haven't touched it in a while and seems like a few lines need to be updated to bring it up to date with TN 4.0 (it's on 3.8 now). Handles the tricky JSON edge cases fine.
It would be great if someone wanted to maintain a solid JsonETN! I'm on to the Turing Complete ETNs nowadays, but a JSON ETN would be great and would let you use ETN tools to work with JSON.
Package.json for NPM should eventually switch to an ETN. Would provide noticeable benefits.