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 10http://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 have no idea what I'm looking at. This could be a code editor, a debugger, a plain code listing. No. Idea.
That being said, using it for a few minutes is more than enough to get where this is going.
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2){
"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
}
}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.
I copied and pasted this into a gist, with responses, which seemed to make it easier to read:
https://gist.github.com/breck7/42a00b00cdcc797e4bb0b6c291a1b...