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

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.

reply

2 points by breck 29 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!

reply

4 points by zck 29 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.

reply


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.

reply

5 points by zck 65 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 87 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 76 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 75 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 244 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!

-----

3 points by zck 254 days ago | link | parent | on: Unit-test.arc 1.0 incoming (part II)

Heh, no worries. It's taken me, oh, 202 days to update the dang library (I feel like my macro skills have something to be desired, or it would be easier). So no worries about taking four to see this. I was planning on pinging you in a few days if you hadn't seen this.

A coordinated launch would be cool. I'm pretty much ready here; the readme is updated (although it does not explicitly have a version number, which I should add).

But before we get into that, would you mind playing with it a little bit to see if there's anything broken or not working? Thanks.

-----

3 points by akkartik 254 days ago | link

Hmm, strangely I just sent you a pull request to update the Readme. I'm not too familiar with Mercurial or Bitbucket; maybe I'm doing something wrong?

https://bitbucket.org/zck/unit-test.arc/pull-requests/2/upda...

I'll play with it today or tomorrow and make sure all of Anarki's tests update correctly.

-----

3 points by zck 253 days ago | link

Yeah, that was right. Thanks for catching the readme changes -- I guess I had made some but not all.

-----

4 points by akkartik 250 days ago | link

I've updated my script to auto-upgrade Anarki tests[1], and things look pretty good. Just a couple of minor comments:

a) I see a message about redefining assert. Perhaps we should change the name in Anarki or unit-test.arc?

b) The new version complains about duplicate nested suite names inside a test suite. That seems like a reasonable idea, and I just want to confirm that it's intended.

c) If you have a duplicate test name in a suite the error is confusing. Here's the example I ran into from Anarki:

  $ cat x.arc
  (load "unit-test.arc/unit-test.arc")

  (suite cut
    (test finds-element-in-string
      (assert-same '(3 4 5) (cut '(1 2 3 4 5) 2)))
    (test finds-element-in-string        ; duplicate name
      (assert-same "cde" (cut "abcde" 2)))
  )

  (test)

  $ ./arc.sh x.arc
  Can't coerce  #<procedure: cut> string
    context...:
     anarki/ac.scm:1015:0: ar-coerce
      map1
      map1
      string
     anarki/ac.scm:1279:0: aload1
Once you switch to unique names everything works fine. But perhaps we can improve the error message?

[1] I'll post the final script here once we "launch".

-----

4 points by zck 250 days ago | link

Yes, it's a desired feature that a suite can't contain two things with the same name -- either suites, tests, or one suite and one test. This is because I want names to be unique. Saying (test cut.finds-element-in-suite) shuld run only one test.

What you ran into is actually a bug I fixed at a meetup on Tuesday. The current error message is:

  Error: "In suite cut, there are two things named finds-element-in-string."
The commit is here: https://bitbucket.org/zck/unit-test.arc/commits/bb41b4183938.... Can you re-pull (hg pull; hg update) and see if it works then? The most recent commit is 96652e5.

-----

3 points by akkartik 250 days ago | link

Ah, you're right. Looks great now!

-----

4 points by zck 290 days ago | link | parent | on: Ask Arc: How to improve the Arc ecosystem?

I think it would be useful to have things built in Arc. That way the language can feel like there's more life in it. Right now there aren't too many things built in Arc that aren't part of the language ecosystem.

To promote that, it would be useful to have a page that lists things built in Arc. I just made a page on the Anarki wiki here: https://github.com/arclanguage/anarki/wiki/Things-built-in-A...

-----

3 points by akkartik 290 days ago | link

Great idea! You should put your unit-test.arc in there.

Edit: added a couple of things.

-----

3 points by zck 305 days ago | link | parent | on: How to run anarki as utility, not REPL?

Just echoing that rlwrap isn't needed. I actually added an arg (-n) to arc.sh that doesn't use rlwrap. I use it when running arc inside an emacs shell, because emacs has terminal integration that I prefer.

-----

3 points by jsgrahamus 305 days ago | link

I started using ansi-term in emacs to launch a shell file which wrapped rlwrap around the file I wished to execute. Turns out that M-x no longer works in that buffer.

-----

2 points by zck 320 days ago | link | parent | on: Errors in anarki stable

Hrm, perhaps it shouldn't be called "stable". That suggests a more-tested release cycle. Maybe something like "original" or "pure", or even "3.1-release"?

I like the idea of having something that's what was originally released, but doesn't really suggest that it's what someone should use if they're new to Arc.

-----

4 points by akkartik 320 days ago | link

Well, we do also have 'official' which is exactly what was released.

I think the intent is that 'stable' is guaranteed to be backwards compatible with 'official'. So the real issue is that 'official' is stale.

-----

2 points by zck 342 days ago | link | parent | on: Y combinator in arc

I agree; the nested case is a bit difficult for humans to parse.

I wonder if there's a way to make (fn (x) ...) even more lightweight.

What if, to do the same thing, we had a new anonymous function syntax?

    {x ...}
It would work somewhat like this:

    arc> (let my-fn {arg (string "I got " arg)}
              (my-fn "this thing"))
    "I got this thing"
This is somewhat analogous to "let"

    (let x ...)
It could also allow for multiple arguments, like this:

    {(x y} ...)
Allowing for multiple arguments prevents destructuring-bind style function calls, though, which is a downside. I guess you could use other kinds of brackets for that?

    {{x y} ...};; this would be non-destructuring-bind
    {(x y) ...};; this is destructuring-bind
    {{(x y} ...);;; this is the same as #2; it would destructuring-bind the first argument, a list.

Heck, we could even build it into the existing anonymous function syntax:

    [{x y} ...]
Would be the same as

    (fn (x y) ...)
But I'm not sure that's a big enough win.

-----

3 points by mpr 342 days ago | link

As per akkartik's comment, we already have multi-argument anonymous functions in anarki:

    ([prn _1 _2] "hello " "there")
But yeah maybe having full lambda list capabilities in the anonymous function would be cool.

    ([((a b) c) (prn c b a)] (list "is" "name ") "my ")
So if the first argument to the bracket function is a list, it acts as a lambda list.

But this interferes with the arc special syntax of having lists act as functions on their indices. Because the following is already valid arc code:

    (let x (list 1 2 3)
      (x 2))
    ;; > 3
In that case having different delimiters might be the way to go. So your brace notation would be used for anonymous functions with full lambda list capability.

    (let x (list 1 2)
      ({((a b) c) (prn c b a)} x 3))
Edit: trying some other formatting...

    (with (f {((a b) c)
               (prn c b a)}
           x (list 1 2))
      (f x 3))

-----

3 points by zck 342 days ago | link

I was thinking that if you have an even simpler way to bind specific variables in the function call, you can nest these anonymous functions, and not have the arguments shadow each other.

> In that case having different delimiters might be the way to go. So your brace notation would be used for anonymous functions with full lambda list capability.

Yeah, I think you're right. The square-brace anonymous function could have optionally a curly-braced first argument. If that argument isn't there, it works as the square-braced anonymous function currently does. If that argument is there, it's the arguments to that function. Since curly braces aren't used anywhere else in Arc, it can only be parsed in that one way.

But perhaps this is all a lot of work to avoid writing `fn (arg1 arg2)`. Other than golfing, I don't know if you really want to nest functions this way. And this seems like a waste of the only paired characters Arc doesn't use.

-----

3 points by rocketnia 342 days ago | link

"And this seems like a waste of the only paired characters Arc doesn't use."

I don't think even the [] syntax really pulls its weight. Between (foo [bar baz _]) and (foo:fn_:bar baz _), the latter is already more convenient in some ways, and one advantage is that we can define variations of (fn_ ...) under different names without feeling like these variations are second-class.

(Arc calls it "make-br-fn" rather than "fn_", but I wanted the example to look good. :-p )

-----

2 points by zck 342 days ago | link

Interesting.

Personally, I've never gotten comfortable with the colon intrasymbol syntax. Even in your example, I'm having trouble parsing it right now. I really don't like how it makes "bar" look like part of the first part, not the second.

-----

More