Arc Forumnew | comments | leaders | submit | zck's commentslogin

Readb and writeb work! Thanks so much!

I'm not sure why it doesn't work otherwise, but it points to something about interpreting the bytes as characters.

reply


I just checked; it's not the first 0 byte.

Just to provide a little extra information, the image I'm testing with is my favicon: http://zck.me/favicon.ico

reply

4 points by zck 49 days ago | link | parent | on: Seeking new host for Try Arc

> So responding to your forum comment above and this, I would love for Try Arc to run purely client-side on a static site host like GitHub Pages. Unfortunately, as you mention here, it runs on a VPS (Linode) instead. The reason is that it's not all client-side - it actually communicates with an system arc3.1 hosted on the server.

I looked around a little bit for solutions. There's a project called Whalesong, but the most up-to-date fork only runs on Racket 6.2: https://github.com/soegaard/whalesong .

In trying to find the github link for Whalesong just now, I came across Racketscript, a Racket -> Javascript compiler: https://github.com/vishesh/racketscript . I'll see if I can make it work later, but it looks promising.

reply

5 points by zck 53 days ago | link | parent | on: Seeking new host for Try Arc

What's involved? I'm not much of a system maintainer, but I think tryarc is a great tool.

Thanks for creating and maintaining it for as long as you have.

reply

3 points by zck 55 days ago | link | parent | on: 3-Dimensional Source Code

Can you explain what the axes are, again? The Y axis is the line; that's pretty clear. But it seems like both the X axis and the Z axis are related to how many characters into the line one goes. (Edit: I just listened to the FAQ, and the Z axis is level of indentation. So for each Y axis, there's only one possible Z value, for any number of X values? That is, you can't have both (42, 27, 3) and (42, 27, 4). Is that right?)

On ohayo.computer, you might want to make it obvious that you have to open the developer console to see the output from running the code. This is the last thing I would think to do. Compare it to many other "run code online" sites, e.g. https://repl.it/JtNz/0, where there's both a "run" button so I don't have to hunt for hidden menus that explain what command to press, and a box in which output goes.

On a technical note, Ohayo's fib.fire seems to be broken for me. Every box seems to have "no block 'X' found" in it: http://imgur.com/a/fwM8X. This happens in both firefox and chrome.

This presentation doesn't seem to answer many of the questions I have about 3D Languages. Why are they better? You say you expect them to have fewer bugs, but I don't see why. You say that they're easier to understand, but even you have a problem figuring out what the location of a given character is! I want to know why you think something, not just that you think something.

And, not to nitpick, but I really don't get the whole "ETN" phrase. It stands for "Extends Tree Notation", but then it's not even a noun, but an adjective! So something can't be an ETN, it can have the quality of ETN. You even seem to acknowledge this. At 7:35 in the video, you say "What fire is is a thing called an ETN. It extends tree notation." You should be able to replace "ETN" with "Extends Tree Notation", and have the sentence still make sense, like "I'm playing a CD" vs "I'm playing a Compact Disc". I'm harping on this because I think it's something I'm misunderstanding, but it seems to be near the core of your argument. Should ETN be a noun? Maybe it should be "Extended Tree Notation". And also, "ETN" seems to be identical to "indentation-based languages with weird syntax".

reply

1 point by breck 48 days ago | link

First, just want to say thank you so much, zck, for taking the time to write this feedback. It is so helpful and very much appreciated!

> Can you explain what the axes are, again? The Y axis is the line; that's pretty clear. But it seems like both the X axis and the Z axis are related to how many characters into the line one goes. (Edit: I just listened to the FAQ, and the Z axis is level of indentation. So for each Y axis, there's only one possible Z value, for any number of X values? That is, you can't have both (42, 27, 3) and (42, 27, 4). Is that right?)

Sorry, this is still slightly up in the air. The Y axis is equivalent to line number (this is fixed). The X axis is equivalent to indent level (this is fixed). Still running some hardware experiments to determine whether to use the Z axis for the words and model these programs as 3-dimensional or whether to stick to just the X axis and save the Z dimension for lines connecting assignment words with their references. I realize that's still not clear and I hope to add something on hover to Ohayo soon, so you can hover over a word and see the X,Y,Z location.

> On ohayo.computer, you might want to make it obvious that you have to open the developer console to see the output from running the code. This is the last thing I would think to do. Compare it to many other "run code online" sites, e.g. https://repl.it/JtNz/0, where there's both a "run" button so I don't have to hunt for hidden menus that explain what command to press, and a box in which output goes.

Thank you, so, so much for this feedback! I prioritized the heck out of that and just shipped version 3.0, which opens with the source editor visible on the top left, and a console for displaying the output on the bottom left. If you go to a fire program, you can now put your cursor on any line and press "Command+enter" to compile and execute that tree (either just that individual line, or that line and any child lines). You can also press "Command+shift+enter" to just compile the tree and print the compiled version to Javascript.

> On a technical note, Ohayo's fib.fire seems to be broken for me. Every box seems to have "no block 'X' found" in it: http://imgur.com/a/fwM8X. This happens in both firefox and chrome.

I'm sorry! I'm still figuring out best practices for designing ETNs, and I've been changed the instruction words a lot. I'm currently building a suite of utilities that will easily migrate programs from and older ETN version (in this case, Fire), to a newer version. This is definitely a critical need before this thing is ready for people to depend on, and I'm sorry about the trouble now. We have made a lot of progress in figuring out some best practices for ETNs (largely by stealing the best ideas from Haskell), and one of the next big changes will be a highly improved version of Fire that implements those best practices. But even when we have a much better and more stable version of Fire, I expect there will always be room for improvement, so will get some better systems in place to ensure people don't have to worry about breaking changes. Really sorry about that. I should add more disclaimers.

> This presentation doesn't seem to answer many of the questions I have about 3D Languages. Why are they better?

I hope the new console (which allows you to run/compile just a branch or single line of your program) starts to provide some hints as to how different ETNs are, and how they enable lots of beneficial things not possible in 1-dimensional languages and 1-dimensional terminals.

> You say you expect them to have fewer bugs, but I don't see why.

Much more to come on this. Basically the thrust is that empirically 99%+ of bugs occur in extanenous parts of the code. ETNs start bringing us closer to the absolute minimum, perfect program necessary to solve a problem. We will see a huge reduction in bugs just from going to ETNs => current high level languages => machine code, however, that's just the beginning. We're inventing a completely new non-von neumann architecture, 3-d machine architecture, that can compute high level ETN programs directly. But realistically that is years away from reliability. In the short term we'll be able to realize a lot of gains in bug reduction just from using ETNs that compile to 1D languages.

> You say that they're easier to understand, but even you have a problem figuring out what the location of a given character is!

I know, very embarrassing! That one is because the Z/X axis debate is still up in the air. Hopefully the correct answer in the design decision will emerge soon.

> I want to know why you think something, not just that you think something.

A lot of it is empirical. But it's the type of thing where I can see that ETNs will be 10-100x faster because they solve a lot of unsolved problems or poorly solved programming problems, but they won't be 100x faster until all the other stuff is there too (stuff like the code editor, which we finally just added). At this point I see no deal breakers and am highly confident all the predictions will come true (and then some), but it's a matter of still doing lots of grunt work to eliminate the trivial (but impactful) road blocks. But yeah, I fully agree with your sentiment and hope we can start to provide more hard data and direct proof about why we think these things.

> And, not to nitpick, but I really don't get the whole "ETN" phrase

This is a great nit! "Extended Tree Notation" is probably better. Thanks!

reply

3 points by akkartik 48 days ago | link

Wait, you're writing about "3-dimensional source code" and the dimensions aren't settled yet? That just makes me glad I didn't read your slides, and even less likely to put in the effort next time. I'll repeat my earlier comment: your MVPs are too M and insufficiently V.

How are you so sure that you won't settle on 2 or 4 dimensions? (Let us stipulate that 5 is right out.)

> empirically 99%+ of bugs occur in extraneous parts of the code

You'll need to show me these empirical studies.

I haven't actually ever heard a story that accounts for 99% of bugs. Pretty much every software engineering study ends up with a much flatter profile than that. You have to do many things right to eradicate 99% of bugs.

> ETNs start bringing us closer to the absolute minimum, perfect program necessary to solve a problem.

From what I can tell, ETNs are mostly about eliminating punctuation and replacing it with indentation. Is that right? If so, is your claim that "99% of bugs" are hiding in the punctuation?

Is upgrading the syntax to ETNs all that's needed to eliminate 99% of bugs? What about DRY? The value of good interfaces? Parnas's theory of information hiding? SOLID?

I'll trade my pulled-out-of-my-ass theory for yours. I think bugs arise because our representation of algorithms ("code") over-emphasizes the rules the algorithms performs, and under-emphasizes the input space that the rules are meant to operate on. Bugs arise when people modifying the code forget about rare areas of the input space, and the scaffolding around the project is unable to remind them. Nail down the input space, and bugs go down because your tests fail more often. You won't fix this problem no matter how much you tweak the superficial syntax with which you write code. (I work on this, so it was not pulled out of my ass just now: http://akkartik.name/about; https://github.com/akkartik/mu)

reply

3 points by shader 12 days ago | link

> ... trading of programming theories ...

Clear and simple syntax / representation is important; combined with matching editing tools it enables us to communicate ideas easily and fluently.

I also like the idea of well defined input spaces. Many theorems or algorithms only work under certain conditions, and much damage has been done by applying them outside of their intended domains. But I think that's only part of the problem.

My own theory is that programs are specifications, and the more clearly and precisely they specify the better. Programs can fit into a matrix of good/bad ideas and good/bad specifications. Of these, two kinds are interesting bugs:

  1) Incorrectly specified good ideas
  2) Correctly specified bad ideas
Well specified good ideas are correct programs, and incorrectly specified bad ideas are just hopelessly confused.

Improving the languages and tools will never fix bad ideas, but they can make them more obvious. Now the goal is to make programming as close as possible to 'saying what you mean'. In other words, making the semantics as explicit as possible.

Basically my goal is 'declarative programming', which turns out to be a very vague concept to most people. They all agree that it's better, but nobody seems to have a good explanation for why. I think the difference is that declarative programs specify the only the relationships which are important, leaving the rest up to the platform to optimize or interpret as it sees fit. This leads to powerful and concise languages such as SQL, but at the cost of placing the burden on the platform rather than the programmer. Good for communication and clarity, bad for development and adoption.

Basically, declarative languages can be more concise because they rely more on shared knowledge; predefined vocabulary. If the language doesn't already have a way to express the concept you want, however, it is much more work to add. Imperative / procedural programs are more flexible because they rely on implicit semantics. You just tell the computer what to do—you don't have to explain what it is doing or why. Everything the program "accomplishes" is imaginary and external to the specification. This leaves very little room for the computer to optimize your selection of operations, and leaves a lot of room for you to accidentally provide an incorrect sequence of steps.

It's like the difference between giving directions by saying "Go to the grocery store at 5th and Main" vs. "Take a left, go three blocks, take a right, go two more blocks, park on the right side of the street and enter the blue building." The first is much clearer, but places much higher expectations on the navigation abilities of the recipient, while the second can be followed by anyone even though they have no idea where they're going - and mistakes are correspondingly harder to notice.

Sadly, the nature of declarative languages makes them fairly domain specific, which may explain part of why they're so rare and hard to make. Creating a declarative language for solving a class of problems is much harder than solving a single problem imperatively; you actually have to think of how and why you're solving those problems. But I think we could probably create some general patterns and guidelines for defining them, and maybe even start building up some tools to reduce the effort required.

reply

1 point by breck 47 days ago | link

> Wait, you're writing about "3-dimensional source code" and the dimensions aren't settled yet? That just makes me glad I didn't read your slides, and even less likely to put in the effort next time. I'll repeat my earlier comment: your MVPs are too M and insufficiently V. > How are you so sure that you won't settle on 2 or 4 dimensions? (Let us stipulate that 5 is right out.)

Sorry, the language itself is fully settled, the only question is with our hardware prototypes, we've found a way to compute with the ETN programs mapped to 2-dimensions, and a machine structure where we can compute answers with a source program mapped to 3-dimensions. But really both are 3-dimensional, the former it's just the Z-axis doesn't vary.

In the 3-D version, the first word of a node (aka the head/base/instruction/type/command), is at z 1, and subsequent words go up the z-stack. In the 2-d version, subsequent words just go up the x-dimension. They actually both offer advantages, and we'll figure out which is better I'm sure in the next year or so.

Again, this stuff is at the cutting edge of the hardware research. We're talking about a whole new type of machine architecture without registers.

> You'll need to show me these empirical studies.

Totally agree. We will.

> I haven't actually ever heard a story that accounts for 99% of bugs. Pretty much every software engineering study ends up with a much flatter profile than that. You have to do many things right to eradicate 99% of bugs.

Agreed. And to hit that 99%, we're going to need the new hardware, so that is quite far off (3 - 20 years, hard to predict). But we can hit 90% fewer with ETN software alone.

> From what I can tell, ETNs are mostly about eliminating punctuation and replacing it with indentation. Is that right?

No. Forget about the punctuation of newlines and spaces. Think about it as Cartesian coordinates. ETNs are about giving source code physical dimensions. About making sure that source code could directly be built out of circuitry. Think of ETN programs like something you could build in a Voxel editor like MagicaVoxel. Each block holds a word, which is just a number from 0 to infinity, and problems are trees of these numbers connected in physical space. Sorry if that's not clear. I think the more code and tools we build the easier it will be to understand.

> Is upgrading the syntax to ETNs all that's needed to eliminate 99% of bugs?

No. To reduce bugs by 90% (99% won't be possible until we have ETN machines) you also need well designed ETNs. Which have good FPL things like no side effects, prefix notation, DRY, good naming, good interfaces, et cetera. Great question. Working on a release shortly with a lot more tools and help on building great ETNs.

> Nail down the input space, and bugs go down because your tests fail more often.

I like that! I'm a big fan of strongly typed languages and the idea they basically prove your program correct at compile time if you think more about your types.

Thanks for the feedback! I hope the next wave of ETN stuff will help start to demonstrate the benefits better.

reply

4 points by shader 12 days ago | link

While the concept of a cartesian program space is interesting, it seems largely unrelated to TNs. This is probably a good thing though, as programs require semantic relationships ("lines" between nodes) that are lacking in cartesian spaces. If there was semantic significance to adjacency or distance between points, or along each axis, that might be reasonable. Otherwise the "dimensions" are just an irrelevant and cumbersome alternative to line numbers.

Additionally, a third dimension is meaningless as long as your fundamental representation is two-dimensional. Unless you use an editor that is natively 3-dimensional, mapping a two-dimensional representation onto three-dimensions will leave a lot of redundancy or sparseness, as demonstrated by your conflation of x and z.

reply

1 point by breck 11 days ago | link

> If there was semantic significance to adjacency or distance between points, or along each axis, that might be reasonable

Yes, there is semantic significance to adjacency & distance from the y-axis (which indicates an edge that connects parent and child nodes).

We are approaching everything simultaneously from the highest abstract level and lowest logical level. We have some more stuff coming out soon that shows off the benefits of the dimensionality more. One of the cooler experiments is a new type of processor with a graph-paper-esque 2D grid that can load a high level tree program and then execute it directly (no cumbersome series of transformations to a bunch of 64 bit registers). AFAIK this is original, though I wouldn't be surprised if Lisp Machines, Thinking Machines, Alteryx, Nvidia, Intel, et cetera have dabbled in this space a bit (though to date haven't been able to find anything on machines that execute trees directly).

reply

2 points by shader 8 days ago | link

> Yes, there is semantic significance to adjacency & distance from the y-axis (which indicates an edge that connects parent and child nodes).

Actually, it seems like your tree relationships have a very confusing relationship to the coordinates. Adding a newline increments Y, and a space increments X, but children are those nodes such that that

  1) child.Y > parent.Y
  2) child.X == parent.X + 1
With additional complications that only the node with the lowest X value for a given Y becomes the child; all others on the same line become part of the content of that node.

This means that the relationships between two elements depends not just on their coordinates, but also the coordinates of nearby nodes. (6, 4) may or may not be a direct child of (5, 3); it depends on if (5, 3) is a full node, or just a content element that's actually part of (5, 2) or (5, 1).

So the coordinates do not actually define the relationships between nodes; they do not clearly relate to the tree structure at all.

reply

2 points by breck 7 days ago | link

You are right, this is great feedback thanks.

> have a very confusing relationship to the coordinates

Agreed. I sometimes get confused too.

One rule that always holds is this:

  1) One line === One node
So every node has an absolute Y coordinate (just the line number), but also a relative coordinate(s), relative to its ancestor(s).

Both are useful at various times. There's probably a better way to eliminate confusion here.

> So the coordinates do not actually define the relationships between nodes

Given an array of node coordinates {y,x} [{1,1}, {2,2}, {3,1}, {4,2}], one has enough information to define the whole tree structure of the program. But you are right, you need the full set of coordinates of a certain node's ancestors to properly know its coordinates, and having a line that begins with 1 or more spaces, it is impossible to deduce how many nodes deep it is without also having access to the previous line(s).

reply

3 points by shader 12 days ago | link

I think the TN/ETN parsing model is somewhat neat in its simplicity, which means it will probably have some longevity.

However, most of the work you have done is just a simplification of the syntax; it has no relation to the semantics whatsoever, and as such is unlikely to cause a major paradigm shift.

Perhaps the coolest part of your notation is the concept of constant validity, which in this case you achieved by simplifying the notation until it matched the medium. Every atomic operation on the text (add a character, new line, or space) is also a valid atomic operation on the tree. Especially because it works with any text editor, instead of fancy semantically (or at least syntactically) aware editors. However, I think any true advances in programming will require improvements in the semantics.

reply

1 point by breck 11 days ago | link

Thanks for the feedback!

> However, most of the work you have done is just a simplification of the syntax; it has no relation to the semantics whatsoever,

Agreed. However, I think one thing that is starting to emerge from our data (17 useful ETNs now compiling to Javascript, Rust, TypeScript, Logo, Haskell, C++, LLVM IR, SQL, HTML, CSS, JSON, and Regular Expressions) is how well this Tree Notation syntax can work for every programming paradigm (functional, imperative, declarative, dataflow, oo, logic, stack ...). Perhaps it is best explained as a universal syntax. The neat thing about this is that once you learn the TN syntax, you now know the complete syntax for languages with very different semantics. So while I agree we aren't changing semantics here yet, instead just leveraging the semantics and VMs of existing languages, this universal syntax could be big in that it can lead to better cross language static tools and enable developers who generally stick to one or two paradigms to make use of more.

> Perhaps the coolest part of your notation is the concept of constant validity

Agreed! The elimination of parse errors is one of my favorite features. Of course, the user can still make errors at the ETN level like mistyping a word or providing invalid parameters to a node. To help catch and fix these kinds of errors, I just launched version 5.0 of Ohayo (Ohayo still shitty, but the core is getting really solid) which includes a revamped compiler-compiler that supports 100% type checking of every word in your program. It makes it easy to create, as you say above "well defined input spaces".

reply

2 points by shader 8 days ago | link

> this universal syntax could be big in that it can lead to better cross language static tools and enable developers who generally stick to one or two paradigms to make use of more.

An alternate syntax will not allow you to use any additional paradigms unless you also provide alternate semantics. It might enable more powerful editing tools or effective macros and metaprogramming though.

reply

2 points by breck 7 days ago | link

> An alternate syntax will not allow you to use any additional paradigms unless you also provide alternate semantics.

Right. The syntax for ETNs is the same, but the semantics are different. For example, I have a language called "Flow" that is a data flow language, passing a matrix through a series of nodes. I also have a logic language called "Project", that can solve relational issues among nodes. Different semantics, identical syntax.

Right now to use different paradigms, a user generally has to learn different semantics and different syntaxes. This eliminates the latter.

reply

1 point by akkartik 7 days ago | link

Is that a good thing, though? A classic design principle is that similar things should look similar and different things should look different. Imagine a project with both Flow and Project files. Wouldn't it be nice to be able to tell them apart at a glance?

reply


I'm having a pretty hard time understanding what this is, and I think a large part of this is that claims are stated instead of proven or explained. I see that the author thinks this is the future, but "what this is is self-evidently better" seems to be the argument most put forward, without being backed up by examples.

Let's take the article "The flaw in Lisp" (http://breckyunits.com/the-flaw-in-lisp.html):

> In Lisp, which uses parantheses for structure and allows arbitrary whitespace, there are many ways to write your code, and not all of those ways arrange your source code into “geometric trees”. That is, if you connect the nodes of your program with lines, sometimes those lines will intersect or be coincident.

The presentation below^0 mainly seems to take as an axiom that tree-structured^1 languages are better. If you already believe tree-structured languages are better, then yes, Lisp is not as good.

But if you're not (yet) convinced? Ok, then that's just a property of languages that Lisp doesn't have. It also doesn't have the property that it requires semicolons at the end of the line, but by itself, that proof doesn't mean Lisp is worse than Lisp-with-semicolons-at-EOL. What about ETNs are better? Yes, if you draw lines from each node to its parent, they intersect -- but why do I care? Drawing lines like that is something I've never done. I assume your argument is something like "it's easier to understand code when it's clear", but I don't see you even state that argument, nevermind make a case for it.

===

So, being the non-academic that I am, I want to go to see how the code works. I open http://ohayo.computer/, and the first thing presented to me is the Apple "The Crazy Ones" video. This is an extremely offputting message. Between that and the article submitted here (Programming is Now Two-Dimensional), I'm seeing far more self-promotion than argument. It's like listening to a professional wrestler cut a promo: "Yeaaaaah brother. What 'chu gonna do, when tree languages run wild on you", but when it comes to that wrestler getting into the ring, the wrestler is nowhere to be found.

And that aside, I can't even seem to run any code! After reading the README, I learn that there are two languages -- Flow and Fire. I'm not a data science guy, so I click on `fib.fire`. I see this: http://imgur.com/a/3sIxf. There's no connection of anything at all, just a dozen random blocks of noise. How do I actually run any code? I don't see any "run" buttons. The File menu has no "run" option. How do I see this work? Also, I have no idea how this is connected to tree-structured languages! There are no lines between things, as seems to be the motivating factor of this paradigm!

Looking at the "sneak peek" video (http://breckyunits.com/ohayo-sneak-peak.html), apparently there is some sort of source code that corresponds to what's shown. But unlike in the video, I can't click to drag around things. I can't see the source code. Why not?

===

I really just want to see how these things work. I don't want to see unsupported claims. I want to be able to write some code, or modify existing code. Please don't make it so hard for me to understand what this is.

[0] I'm not trying to pick on the presentation for the sake of picking on it, but the pictures are extremely difficult to read, making it difficult to understand the argument. At least rotate the pictures so they're right-side-up. Scan them if you can, and do your best to write them with your best handwriting -- I have similarly bad handwriting, so I don't present people with handwritten documents if I can avoid it.

[1] There appear to be multiple terms for this. It's somewhat confusing, because the picture proofs talk about "pure tree languages", but other things talk about ETNs (Extends Tree Notation), or "geometric trees". I don't think "pure tree language" in the picture means anything different from "tree" in the text, but I'm not sure of that. It would be useful to pick one name for each concept and stick to it.

-----

2 points by breck 91 days ago | link

Thanks zck!

I agree with every point you made and am working on fixing them.

> mainly seems to take as an axiom that tree-structured^1 languages are better.

Correct! And also correct that I haven't proven this to be the case yet. I'm heading in that direction and think by the end of week 1 of the announcement there should be more evidence in that regard. I just launched version 1.2 just now. In a Flow program, you can now add a ">3d" block, which can have a "content" property where you can add some ETN code and see it somewhat visualized in 3d. Rough version, but starting to hint at what's to come. Basically imagine a 100,000 line program, where you can visualize and manipulate the source (and AST!) in 3D, and it all runs blazing fast. That's where we are headed with this. I believe 2D/3D languages may be better because 1) it seems the constraints imposed by the criteria that source must map to physical dimensions helps avoid anti-patterns (but i don't have a proof yet on why) 2) our brains are wired to work in 3D. Although those are theoretical guesses. For me, 95% of why I believe they are better is because of my experience working with them the past few months (which I'm trying to bring that experience to others asap).

But yes. Agreed that I haven't proved this yet.

> I open http://ohayo.computer/, and the first thing presented to me is the Apple "The Crazy Ones" video. This is an extremely offputting message.

Haha, thanks for that feedback. Last week was a week with little sleep, and didn't have time to make a proper intro screencast, so put that up as a placeholder because I thought the "ones who see things differently" was apropos. That won't be up much longer. Thanks for sharing your thoughts.

> I'm seeing far more self-promotion than argument

Agreed. I just do believe in the potential impact of ETNs, and truly believe if anything I'm underselling the impact they could have, and if I got hit by a bus before I could provide more evidence I wanted to make sure people took notice and continued where I left off. Low bus factor last week--but now that is much higher! Maybe once more evidence is out there I can revisit all those posts and tone them down.

> fib.fire

Another person emailed me and said it should start with "hello world", and not Fib. That's coming soon. Thanks for this additional feedback. Also, the Fire editing is brand new. It was very theoretical until last week. So the UX has a long way to go. I made some improvements this morning but still it's quite shitty. Working on it.

> How do I actually run any code?

Version 1.2 (today) introduces the shortcut "shift+b" to build program, which will show you the compiled Js output for Fire programs. You can also use "command+shift+b" to build and save to file.

> The File menu has no "run" option.

Great suggestion! Will likely add next version.

Also, another suggestion I got is to have a "Quick tips" that shows the top 5 things to do (like double click to add a node, ? for help, et cetera). Coming soon.

> source code that corresponds to what's shown

Shift+u. Again, great feedback. I'll add a File toggle and also a quick tip.

> I really just want to see how these things work. I don't want to see unsupported claims. I want to be able to write some code, or modify existing code. Please don't make it so hard for me to understand what this is.

Agreed! Thanks! I also made a lot of speed and test improvements this morning and will have project editing very soon.

> [0] I'm not trying to pick on the presentation for the sake of picking on it, but the pictures are extremely difficult to read, making it difficult to understand the argument. At least rotate the pictures so they're right-side-up. Scan them if you can, and do your best to write them with your best handwriting -- I have similarly bad handwriting, so I don't present people with handwritten documents if I can avoid it.

Haha, great points!

> [1] There appear to be multiple terms for this. It's somewhat confusing, because the picture proofs talk about "pure tree languages", but other things talk about ETNs (Extends Tree Notation), or "geometric trees". I don't think "pure tree language" in the picture means anything different from "tree" in the text, but I'm not sure of that. It would be useful to pick one name for each concept and stick to it.

Correct. I haven't found the correct mathematical term for it (I've searched graph, braid/knot, set, and some other theories). I bet there is one. If not, maybe I'll standardize on "Geometric Tree".

Thanks again for these comments. Super helpful!

-----

4 points by zck 91 days ago | link

Cool. I look forward to reading some new stuff about it. I'll just comment on some of the things here.

> Version 1.2 (today) introduces the shortcut "shift+b" to build program, which will show you the compiled Js output for Fire programs. You can also use "command+shift+b" to build and save to file.

This is interesting, but might actually work at cross-purposes to what you want to show. This presents it as "a graphical interface to write javascript", which isn't quite what you want. I want to _run_ the code, not just compile to js. (Obviously compiling to js and then running the js is fine, but don't make me do two steps when one is enough)

But for a run button, I'd think you want this to be as obvious as possible. So don't even bury it in a menu -- make a header with a giant "run" button. Or maybe not "giant", but somewhere that's displayed when you open the page.

> Another person emailed me and said it should start with "hello world", and not Fib. That's coming soon.

I feel like you want to have both. But yes, it's useful to have Hello World.

I do want to play around with this, so hopefully I can understand what it is soon.

-----


Thanks akkartik for updating all the tests! I'm hoping this test framework helps out.

Feel free to ping me if there are any questions, problems, or other feedback. I think the test framework is pretty solid now, in terms of features.

-----

5 points by zck 127 days ago | link | parent | on: How many people still lurk here?

I, too, am around.

-----


Interesting! My first reaction is that I would very much dislike reading code with this (I've never gotten used to Arc's`(a:b c)` syntax).

But it's cool to cross-pollinate languages!

-----

4 points by rocketnia 149 days ago | link

I understand, I think. I think it adds regularity, which is a benefit and drawback, like it is with Lisp's parentheses. But I got used to Arc's (a:b c) at a time when I didn't need a strong reason; the fact that someone put it in a language was enough to convince me it was worth a try, and by "try" I mean using it everywhere I could. :)

This Parendown syntax tackles the a lot of the same needs as quotation sugars, right-associative infix operators, multi-branch conditionals, and imperative blocks. Those individualized pleasantries no longer need to exist as much, but some of what was pleasant about them might slip through the cracks and be neglected entirely by the more regulated approach. Lisp's parentheses didn't solve the things this does, and this doesn't solve some things that other syntaxes do (such as left-associative infix operators, perhaps).

Programming this way in Cene for a while, one thing I keep wanting to reintroduce is quotation sugar. But that's probably unrelated; Cene has a more elaborate syntax for quotation to help with programs that involve several nested quotes, and since I only actually use it in shallow cases, it's a bit hard to explain why I've made it so elaborate. :-p A sugar would brush some of that complexity under the rug until it's useful.

-----

4 points by prestonbriggs 138 days ago | link

I quite like ':' for function composition, especially in situations like this

  (map odd:car '((1 2) (4 5) (7 9)))
where you're composing a new function to pass along as an argument.

-----

3 points by rocketnia 137 days ago | link

Well, that's a use case Arc supports and Parendown doesn't. :)

Depending on the example, Parendown can get close:

  (map odd #/map car '#/(1 2) (4 5) (7 9))

-----


Whoa, that's fantastic. How difficult was it to set up?

Thanks for doing it!

-----

3 points by fauria 306 days ago | link

A little bit tricky, there were some issues with permissions and shared volumes. If you find any issue just let me know!

-----

More