Just in general - is there anything in arc which gives it a big edge to programmers when compared to clojure?
Here are some of the differences, but I can't tell if one of them is crucial. I listed three below for which I've no clue what the impact is.
http://clojure.org/lisps
* The read table is currently not accessible to user programs
* Keywords are not Symbols
* Symbols are not storage locations (see Var)
* immutable data and first-class functions
* *first* is clojure's *car* ;)
2. Arc3F is the latest (and so far, only) version of Arc-F. Arc-F is a fork of Arc I created, featuring some neat stuff, particularly packages. The page you linked to is the Anarki repository, which contains a very modified version of Arc2.
3. When we say "Arc2" or "ArcN", we refer to the official PG release. Anarki is the community's repository of Arc, and the community version of Arc that is based on the latest ArcN. Arc-F is a more recent fork of Arc; it includes a full-fledged symbol-based package system and a partially rewritten standard library.
4. None at all. Anarki accepts all patches. Arc-F accepts all patches too, but Arc-F has very much larger differences to ArcN than Anarki.
5. None from me, I'm afraid; I'm a VIM guy ^^
6. Download rlwrap. You should be able to get it by:
sudo apt-get rlwrap
If you have rlwrap installed and use the arc.sh launcher, or the arc-f/arc launcher script, the launcher script will automatically use rlwrap.
I was confused by this as well, until I figured it out...
He's not talking about about CONTENT sharing a tail- He's talking about two association lists sharing their ENTIRE STRUCTURE...
Let's say you have a database made of key-value pairs and then need to fork it. The fork only contains one difference- One of the keys has to have a different value.
If the database is in a hash table, you're gonna have to clone the entire existing hash table. (They could share content, but the table, itself, needs to be a clone)
If the database is in an assoc list, the fork with the changed key can just have an extra pair for the new key, but then it can "borrow" the entire rest of the data from the other database. So virtually the entire database is shared between the two forks.
This was an earlier experiment that didn't work. Or at least, that I gave up on. The plan was to write a maximally brief (and thus horribly inefficient) meta-circular interpreter, and generate the compiler from it. So you'd literally have the metacircular interpreter as a sort of executable language spec.
I still believe this could be done, but it would be a dissertation's worth of work.
After I gave up on that, Rtm and I decided one summer to just hack together something that compiled into Scheme, and that's what's generating the page that you're reading.
I thought it would be cool to be part of new Lisp community also, and it may eventually develop into that, but it's increasingly seeming like just a pet project of pg's that may or may not develop into something more. That's not a criticism - I think it was generous of pg to open source Arc and invite folks to participate, and he's been straightforward with his intentions. It's just a slightly different project than I expected initially.
I'm also a Lisp newbie. If I was already experienced in Common Lisp or Scheme, I might be more interested in investing more time with Arc to learn something new, but at this point, I'm simply looking for the best Lisp to learn. Given that I primarily develop web based software, you'd think Arc might be the one; however the ease of creating simple web apps is offset by the lack of other stuff I need and the question of long term viability.
So, learning PLT Scheme seems like a reasonable course of action because I expect I can bring most of that knowledge back to Arc if it gains more traction. Who knows, if developing web apps with PLT Scheme becomes too painful, maybe I'll just switch back to Arc and give it a few months of learning.
Any plans to move arc away from scheme to a more stand alone situation? Maybe via arc2c? Then we don't have to worry about it working with different scheme implementations.
I haven't tried it with Arc, but given the fact that it's actively being developed and comes with a web server, I'm considering simply switching to it.
In other words, why not just go to the source? If there's anything that Arc provides that I would miss, it shouldn't be a big deal to add since Arc is just built on top of it, right?
The main thing I wish someone would write is a profiler that (a) had sufficiently low overhead that it could run in production code and (b) could be installed without huge changes to ac.scm and/or the underlying MzScheme.
Yeah, that 1830 is the number of characters since the start of the stream, like you say. (I think it's specifically 1 plus the number of bytes, as documented at [1].)
Racket errors tend to report whatever location information they can, and Racket ports track four things: The name of the file, the line number, the column number, and the overall position in the stream. But line-counting isn't enabled by default on Racket streams, so the error you see doesn't contain the line number information.
I just pushed a commit[2] to Anarki that enables line-counting on the stream when an Arc files is loaded, which should mean you can now see the line and column of a reader error. A reader error on line 17, column 6 should now be printed like so:
Thanks for the reminder! Your comment reminded me that the Arc tutorial (http://arclanguage.org/tut.txt) doesn't quite match the state of Anarki, so I created copies of the tutorial for both stable and master branches at http://arclanguage.github.io.
The master branch of Anarki has one major incompatibility with Arc 3.1, and I created a version of the tutorial with it highlighted in bold: https://arclanguage.github.io/tut-anarki.html
micoangelo, if you decide to try out Arc, be sure to start at http://arclanguage.github.io rather than the instructions here at http://arclanguage.org. Even if you use the stable branch which is compatible with Arc 3.1, it has a couple of crucial bugfixes that are otherwise liable to bite you at an inopportune moment.
I think "learning Lisp" is Arc's best niche. So yes, try using it and come ask us questions. Feel free to also ping me over email, that is sometimes faster. My address is in my profile.
One caveat: it can be easier to learn from a book if you follow the language it was written for. Land of Lisp is a fine book by all accounts, so if you use it you may be better off just using Common Lisp or whatever. But feel free to come ask questions anyway. Maybe we can show you both Common Lisp and Arc versions of programs.
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.
> 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.
That motivation makes sense. Bear in mind, though, that the "less modest" approach has a limited amount of gas. It will stop working at some point.
I can relate with having these questions and considering the different strategies as well. If you really think that this is going to be your life's work, it's reasonable to burn some 'reputation' to get the word out. However, I've often been wrong before. Now I tend to err on the side of playing a long game.
Over time I've gained respect for the essential wisdom of this quote:
"We knew that Google was going to get better every single day as we worked on it, and we knew that sooner or later everyone was going to try it. So our feeling was that the later you tried it, the better it was for us because we’d make a better impression with better technology. So we were never in a big hurry to get you to use it today. Tomorrow would be better." -- Sergey Brin, as retold by Seth Godin in "The Dip"
Applicable to ideas like here just as much as products.
I thought all the emphasis of how great it was made it harder for people to understand _what_ "it" was. Probably a good idea to keep an initial post like this matter-of-fact. Motivate it with just one simple strength that's easiest to communicate. Describe the broader context and implications in a separate post, later, after people understand what it is.
I know of 2 examples of Lisp being used to develop an OS (there may be more): one by Symbolics (called Genera) and the other by Lisp Machine Inc (aka LMI). Apparently both of these descended from code developed at MIT's AI Lab. Googling, it sounds like some of the source code for one of the versions was released as open source.
Of course, Lisp Machine Lisp (or Zeta Lisp, et al.) are not the same as Arc, but I expect that what you can do in one, you can do in the other. Small matter of programming :-)
The interesting question is not the implementation language, but what you intend to build.
