4 ms·

I would like to make a claim that ETN doesn't reduce complexity of programs, it merely splits it in two: the TN that declares the data structure and the interpr

I would like to make a claim that ETN doesn't reduce complexity of programs, it merely splits it in two: the TN that declares the data structure and the interpreter on the other side. To fully understand a piece of code one has now to study both sides. 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.

breck 9y ago
Thank you zimbatm! These are great comments. 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/ But in reality what's happening is just the complexity is shifted from the user to the interpreter creator. 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.
- kazinator 9y ago
  > 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/ https://www.dwheeler.com/readable/ Wisp: - http://dustycloud.org/blog/wisp-lisp-alternative/ http://dustycloud.org/blog/wisp-lisp-alternative/ and some others.
  - deleted 9y ago
    [deleted]
- kazinator 9y ago
  https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html
zimbatm 9y ago
Take the JSON encoding example. How does it know that 802 is a number? What if I want to have "802" as a string? Is it because visitors.mozilla has a fixed schema that it's value is an int or does it try to parse the string as an int first and then bails off back to a string if it doesn't work?
- drostie 9y ago
  It's the latter. The JSON encoding example is actually a really bad example for this language because there is a huge class of JSON which it cannot easily be seen to encode, though you can probably make some exceptions. An example of the many undefined things would be: {"abc def": ["123 456", 789, 101112, null, false]} A better DSL for JSON would have to include actual data types or so, obj abc def arr str 123 456 num 789 num 101112 null bool f ...or so.
  - breck 9y ago
    The paper takes the example from jsonETN. The first letter is the data type. s: StringNode n: NumberNode a: ArrayNode o: ObjectNode b: BooleanNode j: OtherNode I just posted the repo here if you're curious. https://github.com/breck7/jsonetn https://github.com/breck7/jsonetn 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.
  - breck 9y ago
    I do like the 3 letter word better than my 1 letter word. Nice job!
- breck 9y ago
  In the jsonETN I whipped up, the first word indicates the node type. n is number, s is string. Seemed good enough. Probably could be a better ETN for JSON if someone wants to give it a whirl. (For reference; https://github.com/breck7/jsonetn https://github.com/breck7/jsonetn)
zimbatm 9y ago
Take the other example in the paper: https://github.com/breck7/treenotation/blob/master/paper/treenotation.png https://github.com/breck7/treenotation/blob/master/paper/tre... 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.
- breck 9y ago
  Good points! 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.
  - zimbatm 9y ago
    Nice. Pardon for the skepticism but I have seen a number of languages making similar claims. Lisp and SmallTalk where some of the earlier ones. 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?

breck 9y ago

Thank you zimbatm! These are great comments. 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/ But in reality what's happening is just the complexity is shifted from the user to the interpreter creator. 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.

kazinator 9y ago
> 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/ https://www.dwheeler.com/readable/ Wisp: - http://dustycloud.org/blog/wisp-lisp-alternative/ http://dustycloud.org/blog/wisp-lisp-alternative/ and some others.
- deleted 9y ago
  [deleted]
kazinator 9y ago
https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html

zimbatm 9y ago

Take the JSON encoding example. How does it know that 802 is a number? What if I want to have "802" as a string? Is it because visitors.mozilla has a fixed schema that it's value is an int or does it try to parse the string as an int first and then bails off back to a string if it doesn't work?

drostie 9y ago
It's the latter. The JSON encoding example is actually a really bad example for this language because there is a huge class of JSON which it cannot easily be seen to encode, though you can probably make some exceptions. An example of the many undefined things would be: {"abc def": ["123 456", 789, 101112, null, false]} A better DSL for JSON would have to include actual data types or so, obj abc def arr str 123 456 num 789 num 101112 null bool f ...or so.
- breck 9y ago
  The paper takes the example from jsonETN. The first letter is the data type. s: StringNode n: NumberNode a: ArrayNode o: ObjectNode b: BooleanNode j: OtherNode I just posted the repo here if you're curious. https://github.com/breck7/jsonetn https://github.com/breck7/jsonetn 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.
- breck 9y ago
  I do like the 3 letter word better than my 1 letter word. Nice job!
breck 9y ago
In the jsonETN I whipped up, the first word indicates the node type. n is number, s is string. Seemed good enough. Probably could be a better ETN for JSON if someone wants to give it a whirl. (For reference; https://github.com/breck7/jsonetn https://github.com/breck7/jsonetn)

zimbatm 9y ago

Take the other example in the paper: https://github.com/breck7/treenotation/blob/master/paper/treenotation.png https://github.com/breck7/treenotation/blob/master/paper/tre... 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.

breck 9y ago
Good points! 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.
- zimbatm 9y ago
  Nice. Pardon for the skepticism but I have seen a number of languages making similar claims. Lisp and SmallTalk where some of the earlier ones. 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?