Show HN: Programming is Now Two-Dimensional(breckyunits.com)
breckyunits.com
Show HN: Programming is Now Two-Dimensional
http://breckyunits.com/show-hn-programming-is-now-two-dimensional.html
65 comments
He also fired a low shot across the bow at us tab-indenters. Unfortunately for him, I :set sw=8, and am therefore out of range.
Haha love it! Was delivering that low shot (sorry!^1) as well paying homage to a great one.
^1 That's a "Sorry, I'm not sorry (:P)". I hate tabs. I rarely go a month without a tab bug popping up somewhere unexpected. We would be better off without them, imo. (Richer too, if you believe everything on HN).
^1 That's a "Sorry, I'm not sorry (:P)". I hate tabs. I rarely go a month without a tab bug popping up somewhere unexpected. We would be better off without them, imo. (Richer too, if you believe everything on HN).
Haha, I hope if it was satire I could write better satire than this. I'm definitely inspired by Taleb and Wolfram, as the style shows. I enjoy their styles, although sometimes I wish they were more concise. ANKoS would be amazing as a 50 page book.
I... think some humility would serve you well.
You are making some very audacious claims about the data structures,
Of course as you're undoubtedly aware, the deserializer for this only gives you a `TN` and to do useful things with this requires a `TNT token` for some more interesting (semantically) token type, your approach is apparently to use the simplest tokenizer,
On the flip-side, S-expressions have certainly changed the world computing-wise... I am just dubious that in reinventing a subset of them with slightly better syntax that you have fundamentally changed computing beyond what they already innovated for you.
But, if you want to start a new smallish programming language and see where it goes, this means that a lot of that way is already cleared out for you; feel free to translate Scheme[1] into your new syntax and you will be able to do some things that you are not even dreaming about yet, like macro expansion.
[1]: http://www.scheme.com/tspl4/
You are making some very audacious claims about the data structures,
-- rose tree storing data on internal nodes rather than leaves
data AugmentedRoseTree x = ART {node :: x, children :: [AugmentedRoseTree x]}
deriving (Show, Eq, Ord, Functor)
type TNT token = [AugmentedRoseTree token]
type TN = TNT String
serialize tn unlines $ concatMap linesOf tn where
linesOf (ART x subtrees) = x : [' ' : line | tree <- subtrees
, line <- linesOf tree]
Of course as you're undoubtedly aware, the deserializer for this only gives you a `TN` and to do useful things with this requires a `TNT token` for some more interesting (semantically) token type, your approach is apparently to use the simplest tokenizer,
tokenize :: TN -> TNT [String]
tokenize = map (fmap words)
sexpr :: [AugmentedRoseTree [String]] -> String
sexpr (ART xs subtrees) = "(" ++ unwords (xs ++ map sexpr subtrees) ++ ")"
On the flip-side, S-expressions have certainly changed the world computing-wise... I am just dubious that in reinventing a subset of them with slightly better syntax that you have fundamentally changed computing beyond what they already innovated for you.
But, if you want to start a new smallish programming language and see where it goes, this means that a lot of that way is already cleared out for you; feel free to translate Scheme[1] into your new syntax and you will be able to do some things that you are not even dreaming about yet, like macro expansion.
[1]: http://www.scheme.com/tspl4/
With all the revolutionary claims at first I thought that neither of Breck or a,a,b,b,c,c,d,d,j,j,m,m,m,n,n,p,r,s,t,t,x heard about sexp, but they actually mention Lisp in the paper...
Haha, thanks for stating this. Very helpful to see the common reactions from various folks (lispers being a category of folks whose reactions I am extra curious about).
I'm quite familiar with sexp, (had not seen https://srfi.schemers.org/srfi-49/srfi-49.html before though--thanks!).
What TN and ETNs allow is the power of Lisp, with many more ways to build your programs. You give up a few tiny things (like the ability to have an arbitrary number of arbitrary nodes separated by arbitrary whitespace), and in return gain new powers like visual programming, fast/simple/easy-to-parallelize top down parsers, machine written programs with perfect code, et cetera.
I'm quite familiar with sexp, (had not seen https://srfi.schemers.org/srfi-49/srfi-49.html before though--thanks!).
What TN and ETNs allow is the power of Lisp, with many more ways to build your programs. You give up a few tiny things (like the ability to have an arbitrary number of arbitrary nodes separated by arbitrary whitespace), and in return gain new powers like visual programming, fast/simple/easy-to-parallelize top down parsers, machine written programs with perfect code, et cetera.
What a helpful comment, thank you!
> I guess I just want to point out that while syntax is certainly super important, these data-semantics are not all that novel.
I agree! The data structures and semantics aren't novel at all. Nothing there that Lisp doesn't have.
> On the flip-side, S-expressions have certainly changed the world computing-wise...
Agreed!
> with slightly better syntax that you have fundamentally changed computing beyond what they already innovated for you.
It's a great point, and that's what I think the debate will be about. What's new is the matching of the syntax with the semantics, via geometry. The "\n" and " " are arbitrary, really what's going on is the YIndent and XIndent. In my plane, the x indent is " " and shifts a node right by 1, and the y indent is "\n" and shifts a node down by one, but that is arbitrary and just because English goes in that direction. I believe there will be many tricks that will now be borrowed from geometry to augment programmers in new ways.
> But, if you want to start a new smallish programming language and see where it goes, this means that a lot of that way is already cleared out for you; feel free to translate Scheme[1] into your new syntax and you will be able to do some things that you are not even dreaming about yet, like macro expansion.
A SchemeETN would be great! I've played around with macros in ETNs and there are some really interesting things you can do.
> I guess I just want to point out that while syntax is certainly super important, these data-semantics are not all that novel.
I agree! The data structures and semantics aren't novel at all. Nothing there that Lisp doesn't have.
> On the flip-side, S-expressions have certainly changed the world computing-wise...
Agreed!
> with slightly better syntax that you have fundamentally changed computing beyond what they already innovated for you.
It's a great point, and that's what I think the debate will be about. What's new is the matching of the syntax with the semantics, via geometry. The "\n" and " " are arbitrary, really what's going on is the YIndent and XIndent. In my plane, the x indent is " " and shifts a node right by 1, and the y indent is "\n" and shifts a node down by one, but that is arbitrary and just because English goes in that direction. I believe there will be many tricks that will now be borrowed from geometry to augment programmers in new ways.
> But, if you want to start a new smallish programming language and see where it goes, this means that a lot of that way is already cleared out for you; feel free to translate Scheme[1] into your new syntax and you will be able to do some things that you are not even dreaming about yet, like macro expansion.
A SchemeETN would be great! I've played around with macros in ETNs and there are some really interesting things you can do.
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.
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.
Take the other example in the paper: 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.
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.
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.
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.
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?
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?
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:
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.
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.
> 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.
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.
[deleted]
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?
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]}
obj
abc def
arr
str 123 456
num 789
num 101112
null
bool f
The paper takes the example from jsonETN. The first letter is the data type.
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.
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.
I do like the 3 letter word better than my 1 letter word. Nice job!
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)
since each line is parsed a second time, couldn't you take yaml's approach to value encoding and asking ambiguous strings to be quoted?
I can smell the potential of this revolutionary approach already. I have two questions:
1. how are you handling recursive semantic analysis for the creation of the TN code representation? You say HAL is Turing complete, so a bottom up approach could be better for the semidecidible parsing structure of ETN
2. What insights do you have about applying this technology to AI and big data analitics? Social IOT apps could really change the world we live in if they truly embraced this coding paradigm
1. how are you handling recursive semantic analysis for the creation of the TN code representation? You say HAL is Turing complete, so a bottom up approach could be better for the semidecidible parsing structure of ETN
2. What insights do you have about applying this technology to AI and big data analitics? Social IOT apps could really change the world we live in if they truly embraced this coding paradigm
1. I haven't done a fully bootstrapped ETN yet so Turing Completeness comes from ETNs that compile to TC languages. I haven't played with a bottom up parser, just because a top down parser works so fantastically.
2. For data analytics, stay tuned for later today. Releasing Ohayo, an ETN editor which ships with an ETN called Flow for data science and analytics. For AI, I have some rough prototypes but it is clear to me that a better representation for large trained models is to be found in ETNs.
2. For data analytics, stay tuned for later today. Releasing Ohayo, an ETN editor which ships with an ETN called Flow for data science and analytics. For AI, I have some rough prototypes but it is clear to me that a better representation for large trained models is to be found in ETNs.
So this is basically sexp with indentation instead of parentheses, that is I-expressions: https://srfi.schemers.org/srfi-49
Wow, thank you so much! I had not seen this before.
I just requested to be put on the mailing list and will reach out to those folks. I'm not sure if they realized the potential of this notation. (Or maybe they have long known this--I don't want to assume anything).
It appears Egil Möller had 90% of the details correct years ago! This is really well explained and clear. I am not surprised to see this come from the Scheme world. TN/ETNs and LISP are quite closely related.
I think the distinction between TN and the ETNs is important (and not having the additional S-expr construct in the base). Also, a minor technical detail or two in the implementation that matters in terms of anti-fragility.
Thanks again, really super helpful. The number of notations and languages I've carefully looked at is over 300 (I'll post a full list soon), but I've long suspected that others have been super close or already found TN and ETNs.
I just requested to be put on the mailing list and will reach out to those folks. I'm not sure if they realized the potential of this notation. (Or maybe they have long known this--I don't want to assume anything).
It appears Egil Möller had 90% of the details correct years ago! This is really well explained and clear. I am not surprised to see this come from the Scheme world. TN/ETNs and LISP are quite closely related.
I think the distinction between TN and the ETNs is important (and not having the additional S-expr construct in the base). Also, a minor technical detail or two in the implementation that matters in terms of anti-fragility.
Thanks again, really super helpful. The number of notations and languages I've carefully looked at is over 300 (I'll post a full list soon), but I've long suspected that others have been super close or already found TN and ETNs.
He's citing an article about the Culler-Fried system. This accepted math notation on a screen in the 1960s. A modern equivalent is Mathcad, which supports standard mathematical formula notation on input.
(I used to use Mathcad when it cost about $200. It's quite nice. Now it's $595/year.)
(I used to use Mathcad when it cost about $200. It's quite nice. Now it's $595/year.)
Thanks for the mention of Mathcad! I hadn't seen that before.
It appears the file extension is "MCDX". Do you have any MCDX files? Would love to look at the source of those to see the structure of the encoding.
It appears the file extension is "MCDX". Do you have any MCDX files? Would love to look at the source of those to see the structure of the encoding.
Also, do you have any good links on the Culler-Fried system?
I'm not really sure what this adds to programming as a practice, other than another way to represent expression trees. Building trees from data has never been the hardest point of building a programming language. The semantics of said expressions/statements are where the rubber meets the road.
To be fair, it is much easier to program using trees, and they make metaprogramming more managable, but I suspect that the effects this has had on things like Ohayo and the like are more related to the benefits of building a DSL, and less to the ETN structure itself.
Still, if you've managed to build a good visual tree editor, kudos. That is a problem that takes some consideration to get right.
To be fair, it is much easier to program using trees, and they make metaprogramming more managable, but I suspect that the effects this has had on things like Ohayo and the like are more related to the benefits of building a DSL, and less to the ETN structure itself.
Still, if you've managed to build a good visual tree editor, kudos. That is a problem that takes some consideration to get right.
2:02pm. Thanks so much everyone for your feedback so far! It seems people want to see more evidence. And so I need to ship Ohayo! I'm going to sign off of all forums for a couple hours until Ohayo is done. Please do continue to leave feedback, and I'll address later on.
Thank you!
Thank you!
I think that will be the tasting necessary to prove this pudding.
I would also point out that you do have parse errors in your scheme (incorrect indentation errors) and that parse errors are not actually a bad thing (if you think about static analysis tools, they can only work under the assumption that not every bytestring is a valid, useful program, and they get better the sparser that valid, useful programs become).
I would also point out that you do have parse errors in your scheme (incorrect indentation errors) and that parse errors are not actually a bad thing (if you think about static analysis tools, they can only work under the assumption that not every bytestring is a valid, useful program, and they get better the sparser that valid, useful programs become).
Thanks for the feedback!
You still can have errors at the ETN level, but you cannot have parse errors at the TN level. TN will parse all inputs fine.
I totally agree that compile time error checking is a great thing! ETNs support that too, and you can make your ETNs behave at compile time exactly like languages do today if you want. But they also allow easy to implement cool new error handling patterns beyond just "crash and point to the offending character".
You still can have errors at the ETN level, but you cannot have parse errors at the TN level. TN will parse all inputs fine.
I totally agree that compile time error checking is a great thing! ETNs support that too, and you can make your ETNs behave at compile time exactly like languages do today if you want. But they also allow easy to implement cool new error handling patterns beyond just "crash and point to the offending character".
Author here. Happy to answer any questions or comments people may have. Also will be launching an app later today, called Ohayo, which demonstrates the benefits of ETNs.
i couldnt find any normal code -> your new system examples that made sense. can you post a short one here? like 10 lines or something?
Appears to be some in the test files here https://github.com/breck7/treenotation/tree/master/etns
To make this specific, Fibonacci would be a great example
Fib
etn fire
fn fib n
< lessThan1 n 1
if lessThan1
return 0
<= lessOr2 n 2
if lessOr2
return 1
- oneLess n 1
- twoLess n 2
call oneLessFib fib oneLess
call twoLessFib fib twoLess
+ sum oneLessFib twoLessFib
return sum
call result fib 10I'm not really understanding how this is superior to existing notation. It looks like the only unusual thing being done is putting the lvalue as the first argument to the "function", otherwise this looks like a fairly bog standard imperative language. Is the secret sauce in the GUI used to create this? If so couldn't you just use an existing programming language with the editor? Why create a new language?
Great points. Here's a sneak peak at Ohayo, which helped me quickly whip up Fib:
http://breckyunits.com/files/ohayo.png
> If so couldn't you just use an existing programming language with the editor? Why create a new language?
No. Because with all existing languages, to have machines and humans coauthor code has proved impossible. We needed TN and ETNs to enable this: one right way to write programs. With ETNs, humans can write code that machines can easily work with, and vice versa.
http://breckyunits.com/files/ohayo.png
> If so couldn't you just use an existing programming language with the editor? Why create a new language?
No. Because with all existing languages, to have machines and humans coauthor code has proved impossible. We needed TN and ETNs to enable this: one right way to write programs. With ETNs, humans can write code that machines can easily work with, and vice versa.
I should note: the UX of Ohayo won't be great in the first week or two. Although I've been building this for quite a while, it wasn't until this morning that the last pieces of the puzzle finally clicked into place.
That being said, using it for a few minutes is more than enough to get where this is going.
That being said, using it for a few minutes is more than enough to get where this is going.
> http://breckyunits.com/files/ohayo.png
I have no idea what I'm looking at. This could be a code editor, a debugger, a plain code listing. No. Idea.
I have no idea what I'm looking at. This could be a code editor, a debugger, a plain code listing. No. Idea.
It's taken from Ohayo, the ETN editor. It's a rendered view of the Fire program. Sorry, I'm responding to some really helpful feedback and comments now, but will get back to Ohayo shortly and get it out today.
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)Please don't mistake this question as offensive, but: How many people did you show this to before putting it out in the open? The biggest problem of the whole thing is that it doesn't even get its motivation across to me. I read through the blogpost and the paper and I have no idea why I should care.
The paper is in dire need of some peer review (also proofreading, but that's not why I'm here). Here's some points that came to my mind while reading it. (Looking over it after writing it all down makes this appear like a rant. Please don't take it that way. I want you to improve, and you can only do so with honest, constructive feedback, which is what I'm aiming to provide.)
> Our current high-level antique languages (HALs) add to this complexity.
It doesn't inspire confidence when you use inflammatory language ("antique") in the second sentence. You should present your ideas in a neutral way and let readers arrive at judgments themselves.
> ASTs have enabled local minimum gains in developer productivity.
What do you mean? ASTs are not a tool for application developers, they're a tool for compilers and compiler developers.
> But programmers lose time and insight due to discrepancies between HAL code and ASTs.
Unsubstantiated claim.
> GitHub ES6 repo
What's an ES6?
> TN [...] makes reading code locally and globally easy, and ETN programs use far fewer source nodes than equivalent HAL programs. ETNs let programmers write much shorter, perfect programs.
A litany of unsubstantiated claims. You should either use a much more neutral language (e.g. "Our goal was to devise a notation that does X" instead of "ETN does X") or present evidence to support your claims (e.g. "we wrote 100 functioning programs in ETN and in $common_language and found that ETN programs use 35.6% less source nodes"). Also, you didn't explain why "number of source nodes" is a useful metric.
There are a lot more unsubstantiated claims in the subsequent sections. I'm not going to point these out individually because I think you will get what I'm going for.
> Every text string is a valid TN program. [...]
This whole section is conceptually fuzzy. I kind of get why you would consider this property useful, but I don't see that having any value in practice. Why should I care about the program being invalid for the 1 second while I type out this particular variable name? I only care if the program is valid once it's being passed into the compiler/interpreter. If the momentary invalidity of a source code during character-wise editing really were a problem, we would have switched to AST-based editors decades ago (at least once we had access to GUIs). But my bigger gripe is this:
> "Errors" still can exist at the ETN level, but ETN microparsers can handle errors independently
So you're just moving the problem to a different layer. Also, this same behavior can be had with any "antique" programming language whose grammar defines synchronization points. For example, in C/C++, if a parser error occurs within a statement, the parser can jump ahead to the next semicolon token and continue parsing the next statement from there. How is TN/ETN superior to this?
> C. Semantic diffs
I don't get the point of this section. When I have a merge conflict between two changes, it's because they touch the same stuff, and therefore human-level intelligence is required to merge them. What is (E)TN bringing to the table to make merges more automatic? The best way to clarify this would probably be to present a concrete example.
> HALs ignore whitespace
I would have replied that you apparently never used Python, but the next example uses Python, so I don't know how to explain this.
> JSON program
JSON is not a programming language.
> For example, the JSON program below requires extra nodes to encode Python
Why on earth would you wrap Python in JSON (or ETN or anything)? Related:
> multi-lingual programs
I assume you mean that the code contains the same program in multiple programming languages. Why would I want to do this? This whole section looks like a solution in want of a problem. Why would I need to wrap Python into any of these structures?
> The GER demonstrates how...
So this paper is only a teaser and I should look at the Github repo for the real deal? Sorry, but that's not how research papers work. I feel like I'm reading a blog post here. It's okay to link to references (e.g. websites or other papers) when you're introducing an existing idea. But when presenting a novel idea, a paper should be reasonably selfcontained.
> Prediction 1: no structure will be found that cannot serialize to TN.
That's not a prediction, that's a tautology. In a world where I can serialize everything as a string of 1s and 0s, of course I can serialize everything as TN, too. This could be a prediction if you defined the serialization(s) in some way (at least by their properties).
> Below is some code in a simple ETN, JsonETN:
This snippet looks like a rendering error. If you're not going to describe what's in it, I'd rather cut it.
> ETNs will be found for great ALs including C, RISC-V, ES6 and Arc.
Now that's just namedropping. What particular relevance do these languages have that warrants their mention over others, except for (in the case of RISC-V or ES6) appealing to the HN crowd?
And by the way, RISC-V is not a language. The RISC-V ISA's machine code is a language. This lack of rigorousness is one of the most pervasive patterns in the paper, and one of the reasons why I said earlier that I feel like reading a blog post instead of a paper.
> Some ETNs have already been found
> discovering an ETN for an AL
I take issue with how you use the word "find". Why are you so insistent in denying that languages are invented?
> Tree Oriented Programming will supersede Object Oriented Programming.
These are two entirely separate concerns, as far as I can see. TOP, as you show it in the paper, happens on the syntactic level only. OOP happens on the semantic level. To witness, observe how most nontrivial C libraries are object-oriented, even though C itself is not object-oriented in any way.
> High level ETNs will be found to translate machine written programs into understandable trees.
I said before that I won't point out any unsubstantiated claim, but this one gets an honorable mention for being particularly egregious.
> At time of publication, 312 programming languages and notations are searched. Over 10,000 pages of research was read.
Similar to namedropping, this is numberdropping. Again, this is something for a blog post, not for a paper. It doesn't add any useful information for the reader.
> [Figure 2]
What is this image supposed to tell me?
> [References] http://sci-hub.cc/[...]
Pro-tip: Don't link to SciHub in a paper.
The paper is in dire need of some peer review (also proofreading, but that's not why I'm here). Here's some points that came to my mind while reading it. (Looking over it after writing it all down makes this appear like a rant. Please don't take it that way. I want you to improve, and you can only do so with honest, constructive feedback, which is what I'm aiming to provide.)
> Our current high-level antique languages (HALs) add to this complexity.
It doesn't inspire confidence when you use inflammatory language ("antique") in the second sentence. You should present your ideas in a neutral way and let readers arrive at judgments themselves.
> ASTs have enabled local minimum gains in developer productivity.
What do you mean? ASTs are not a tool for application developers, they're a tool for compilers and compiler developers.
> But programmers lose time and insight due to discrepancies between HAL code and ASTs.
Unsubstantiated claim.
> GitHub ES6 repo
What's an ES6?
> TN [...] makes reading code locally and globally easy, and ETN programs use far fewer source nodes than equivalent HAL programs. ETNs let programmers write much shorter, perfect programs.
A litany of unsubstantiated claims. You should either use a much more neutral language (e.g. "Our goal was to devise a notation that does X" instead of "ETN does X") or present evidence to support your claims (e.g. "we wrote 100 functioning programs in ETN and in $common_language and found that ETN programs use 35.6% less source nodes"). Also, you didn't explain why "number of source nodes" is a useful metric.
There are a lot more unsubstantiated claims in the subsequent sections. I'm not going to point these out individually because I think you will get what I'm going for.
> Every text string is a valid TN program. [...]
This whole section is conceptually fuzzy. I kind of get why you would consider this property useful, but I don't see that having any value in practice. Why should I care about the program being invalid for the 1 second while I type out this particular variable name? I only care if the program is valid once it's being passed into the compiler/interpreter. If the momentary invalidity of a source code during character-wise editing really were a problem, we would have switched to AST-based editors decades ago (at least once we had access to GUIs). But my bigger gripe is this:
> "Errors" still can exist at the ETN level, but ETN microparsers can handle errors independently
So you're just moving the problem to a different layer. Also, this same behavior can be had with any "antique" programming language whose grammar defines synchronization points. For example, in C/C++, if a parser error occurs within a statement, the parser can jump ahead to the next semicolon token and continue parsing the next statement from there. How is TN/ETN superior to this?
> C. Semantic diffs
I don't get the point of this section. When I have a merge conflict between two changes, it's because they touch the same stuff, and therefore human-level intelligence is required to merge them. What is (E)TN bringing to the table to make merges more automatic? The best way to clarify this would probably be to present a concrete example.
> HALs ignore whitespace
I would have replied that you apparently never used Python, but the next example uses Python, so I don't know how to explain this.
> JSON program
JSON is not a programming language.
> For example, the JSON program below requires extra nodes to encode Python
Why on earth would you wrap Python in JSON (or ETN or anything)? Related:
> multi-lingual programs
I assume you mean that the code contains the same program in multiple programming languages. Why would I want to do this? This whole section looks like a solution in want of a problem. Why would I need to wrap Python into any of these structures?
> The GER demonstrates how...
So this paper is only a teaser and I should look at the Github repo for the real deal? Sorry, but that's not how research papers work. I feel like I'm reading a blog post here. It's okay to link to references (e.g. websites or other papers) when you're introducing an existing idea. But when presenting a novel idea, a paper should be reasonably selfcontained.
> Prediction 1: no structure will be found that cannot serialize to TN.
That's not a prediction, that's a tautology. In a world where I can serialize everything as a string of 1s and 0s, of course I can serialize everything as TN, too. This could be a prediction if you defined the serialization(s) in some way (at least by their properties).
> Below is some code in a simple ETN, JsonETN:
This snippet looks like a rendering error. If you're not going to describe what's in it, I'd rather cut it.
> ETNs will be found for great ALs including C, RISC-V, ES6 and Arc.
Now that's just namedropping. What particular relevance do these languages have that warrants their mention over others, except for (in the case of RISC-V or ES6) appealing to the HN crowd?
And by the way, RISC-V is not a language. The RISC-V ISA's machine code is a language. This lack of rigorousness is one of the most pervasive patterns in the paper, and one of the reasons why I said earlier that I feel like reading a blog post instead of a paper.
> Some ETNs have already been found
> discovering an ETN for an AL
I take issue with how you use the word "find". Why are you so insistent in denying that languages are invented?
> Tree Oriented Programming will supersede Object Oriented Programming.
These are two entirely separate concerns, as far as I can see. TOP, as you show it in the paper, happens on the syntactic level only. OOP happens on the semantic level. To witness, observe how most nontrivial C libraries are object-oriented, even though C itself is not object-oriented in any way.
> High level ETNs will be found to translate machine written programs into understandable trees.
I said before that I won't point out any unsubstantiated claim, but this one gets an honorable mention for being particularly egregious.
> At time of publication, 312 programming languages and notations are searched. Over 10,000 pages of research was read.
Similar to namedropping, this is numberdropping. Again, this is something for a blog post, not for a paper. It doesn't add any useful information for the reader.
> [Figure 2]
What is this image supposed to tell me?
> [References] http://sci-hub.cc/[...]
Pro-tip: Don't link to SciHub in a paper.
This is such amazing feedback. I'm truly touched and appreciative that you took the time. Thank you.
I copied and pasted this into a gist, with responses, which seemed to make it easier to read:
https://gist.github.com/breck7/42a00b00cdcc797e4bb0b6c291a1b...
I copied and pasted this into a gist, with responses, which seemed to make it easier to read:
https://gist.github.com/breck7/42a00b00cdcc797e4bb0b6c291a1b...
A JSON object like:
{
"title" : "Jack and Ada at BCHS",
"visitors": {
Can be written in Tree Notation like this:
title Jack and Ada at BCHS
visitors
mozilla 802
couldn't this be parsed as:
{
"title Jack" : "and Ada at BCHS",
"visitors": {
{
"title" : "Jack and Ada at BCHS",
"visitors": {
"mozilla": 802
}
Can be written in Tree Notation like this:
title Jack and Ada at BCHS
visitors
mozilla 802
couldn't this be parsed as:
{
"title Jack" : "and Ada at BCHS",
"visitors": {
"mozilla": 802
}
}It could. TN doesn't have a notion of "words", so ETNs are free to parse each line as they see fit. In my experience, it's best to stick to the convention of words, separated by a single space, and for the first word to be "head". Also works great for the first word to be indicate the node type.
You lost me. Can you explain the actual values of ETN over current programming languages? While I do see value in leaving out the unneeded key variable in Figure 1, are there actually any other other benefits? Also for Figure 1 is there no better antique solution than the provided source code?
Great, great point, thanks! I will be releasing the app later today, which gives a better demonstration of the value.
Wow. This feels a little too ambitious :-)
Haha, you could be right! Ah well, life is short! Also, I have to admit that discovering Well's paper and prediction, gave me the courage to just go for it, because he was taking a chance, and I'm sure knew it, and as it turns out was wrong (at least, by his timeframe), but went for it anyway. Thank you to him, whoever he is.
I posted a quick demo video: https://news.ycombinator.com/item?id=14608632
[deleted]
I'm not completely sure I get the joke.