Arc3.1 and Anarki are built on the outdated mzscheme language. But you might be able to use Pauan's Arc/Nu: https://github.com/arclanguage/arc-nu. We'd love to hear your experiences if you try it out.
Feel free to rename ac-scheme to $ or % if you think you'll use it often enough.
If you start using this you'll start finding the need for some of the other functions in that link, which transform data back and forth to the way racket or arc likes it. Come back and ask us more questions when you run into errors like this:
I would just like to point out that Arc/Nu is fully compatible with Arc 3.1, and it doesn't need conversions between Racket and Arc, so it's the easiest way to deal with Racket in Arc programs.
Yeah should be pretty easy to do. Easiest way might be to save the html of https://news.ycombinator.com/bookmarklet.html, make your edits, and save it under the static/ subdirectory.
My one-sentence summary of arc: minimalist common-lisp-flavored lisp-1 atop scheme. It takes quasiquoting and some other more dynamic design choices from common lisp and overlays them atop the more modern Racket runtime with as little code as possible. Other than that it's lots of tiny ergonomic conveniences. Maybe you should read/show him the tutorial next: http://ycombinator.com/arc/tut.txt. And arc.arc is a pretty fun read: https://github.com/arclanguage/anarki/blob/3fc14d16e9/arc.ar.... What really got me into arc was writing programs in one split window with the friggin compiler for my language in the other.
I did have a short look at the tutorial, but I had a bit of a hard time diffing it mentally, as I am still fairly new to Lisp. But I will definitely point him in that direction if he is interested in having more than a cursory glance.
It's hard to say. I think most people might be discovering arc and never coming to the forums or our community frontpage: http://arclanguage.github.io. They're probably still using arc 3.1.
I prefer anarki because Arc 3.1 has been around for five years without updates, and we've found some serious bugs in it, and also made some serious improvements (tests, online help).
Thanks! I don't really have any concrete questions, but any advice on learning Lisp would be welcome. Maybe I should learn Scheme and read SICP before learning Clojure? Maybe I should forget Lisp altogether until I have more experience with programming in general? I get the feeling Arc is not the best place to start learning Lisp.
I personally think Arc is a fantastic way to learn Lisp:
#1 Arc is minimal. This makes it a lot easier to learn, because it has so few axioms.
#2 Arc heavily emphasizes recursion, and recursion is fundamental to computing in general. So it's important to understand recursion.
#3 You learn about closures and first-class functions, which are very useful and are used in lots of other languages (including JavaScript, Python, and Ruby).
#4 Arc's macros are simple enough that it's easy to fully understand how they work.
Arc is basically a stripped down minimal Scheme with Common Lisp unhygienic macros. It shouldn't be hard to convert the Scheme code in SICP into Arc.
As to whether Arc would be a good first programming language in general... I don't know. I suspect that if you take two programmers, one learns a functional language first, and the other learns an imperative language first, that they would have radically different mindsets.
Because of the recent surge of parallelism, functional languages have a significant advantage, because immutability and purity give both increased correctness and performance compared to mutability. So I don't think it's a bad idea to learn a more functional language like Arc first.
Re #2 and #3: I think Clojure also puts a heavy emphasis on closures, first-class functions, and recursion (although it seems you have to jump through a hoop to get TCO working (Java and JavaScript don't support TCO (yet))).
Arc may be more minimal and have simpler macros, but I think it'll take me a lot less time to actually start making things with Clojure because there are more resources available for learning it, and it has good support for making web apps (good libraries, good compiler to JavaScript). The Arc docs seem to be good, but targeted more at people who are already familiar with Lisp.
I tend to learn best by creating things, and seeing as I already know HTML and CSS, a language that would allow me to dive right in by creating web apps would be great.
There's also the fact that if someone asked me why I chose Arc over any other Lisp, I wouldn't really know what to say. I like the sound of your philosophy, but at the moment I don't really have the knowledge to understand how Arc is different from other Lisps (other than by being very minimal).
Maybe once I've got some practical experience and a good grasp of the basic concepts behind Lisp and macros, I might start learning Arc, and be able to appreciate it for what it is.
You're right, Clojure is not a bad choice either, in my opinion. It's even more heavily functional than Arc, so it's an excellent way to ease into functional programming. There are certain things I really dislike about Clojure, but on the other hand there are some things I absolutely love about it. I think it gets a lot of things right.
I think Arc is a better language for learning Lisp, but you are correct that Clojure would be better for writing actual applications that do things. Solving actual problems with actual applications can give you a lot of motivation, and motivation is important when learning anything.
The reason I use arc: I can't seem to stop. Before arc I tried to learn common lisp and scheme, but they required me to be persistent, and I kept falling off the wagon. With arc, I didn't need to be persistent. That was the concrete, tangible benefit of minimalism for me: the entire experience seemed to cater to me. There were fewer things that were like, "this may seem overly complex, but there's good reason for it, you'll understand when you gain experience." That argument is almost always a rationalization for accidental complexity (https://en.wikipedia.org/wiki/Accidental_complexity), in my experience.
Eventually I grew more fluent with common lisp and racket as well. You're right that they're more grown-up, and sometimes one needs something grown-up and industrial-strength. But arc was the gateway drug, and I can't seem to outgrow it.
I said this in another thread: "What really got me into arc was writing programs in one split window with the friggin compiler for my language in the other." (http://arclanguage.org/item?id=18954) That's really valuable, because to get really good at programming requires breaking out of every box other programmers create for you. Yes it's more immediately valuable to learn to use a few platforms or libraries. But understanding how they work, the design decisions and tradeoffs that are common to all platforms, that gives you superpowers in the long term.
In fairness, all my experiences predate clojure, which may well have all the same benefits. Several people have switched to it from arc in the past. I'd love to hear about your experiences after you try it out. I haven't much experience with it, though I've heard that the boxes it creates are harder to break out of (https://plus.google.com/110981030061712822816/posts/KaSKeg4v...)
I'm curious what docs you looked at that seemed to require familiarity with lisp. Feedback most appreciated.
These docs (https://arclanguage.github.io/ref/) are the ones I was talking about. I haven't read much, but there's no mention of parentheses anywhere. Also, there are symbols in circles to the left of concepts, e.g. F ! ? M, but no explanation of what they mean.
Generally, the docs seem rather terse to me; there's a lot of stuff that only makes sense now, after reading (http://aphyr.com/posts/301). "Clojure from the ground up" does start slowly, but by the end of Chapter 4, I really understood the idea of recursion and representing code as a tree, something that I don't think I could have got from the Arc docs.
That's fair. I think we worked on the reference because the tutorial seemed pretty good. Do you think we need something in between?
Edit: I thought the tutorial had come up in this thread, but it hasn't. I'm not used to having two questions from newcomers at once :) Are you aware of http://old.ycombinator.com/arc/tut.txt?
Ahh, I got a server error when I first tried to look at that; it seems to be working now, though. I've read the tutorial - it does seem pretty good. Thanks for the link :)
What gives you that feeling? (You might well be right; we don't have much experience being a first language.)
What language you use doesn't matter much, within reason. It's just the easy/fun question to think about. Pick one and try to do things with it. If people around you prefer something, use that. Feel free to ask questions here about any language.
SICP is a pretty good choice. Might make sense to work through regardless of what lisp/language you choose.
I stopped at spliceable-list (in scan-past) which needed lib/spliceable-list.arc. I didn't want to go down the rabbit hole of loading it after I saw a redefinition of append.
The dependencies might not be incompatible but I didn't try.
But yes, it might make sense to avoid pulling in spliceable-list. As long as you can see what it's being used for, there are other ways to get the behavior it provides, though the easy alternatives will be slower.
But as you're finding out, it's work. You can't just pull in dependencies willy-nilly. Fundamentally, arc3.1 and anarki are both about sharing code as ideas, not code as functionality. We've repeatedly mentioned how neither makes promises of compatibility. You can't treat them as interchangeable lego blocks and expect them to just snap into place. No matter how similar they look, they're not close to each other. They're really more like separate universes that you're 'wormholing' matter and energy through. Start with the assumption that that will cause some annihilation unless you're willing to be careful and detail-oriented. How much time should it take? Maybe "dawn to midnight" is reasonable. There's no way to tell until you try to do it. You're in terra incognita with every single little task like this.
Anarki tries to make such wormholing easier by providing tests. Tests are a better "unit of transplanting" than functions or something else. Try to first understand what's involved in making a test pass, then copy the test over, then make it pass. Think of the file upload code in anarki as merely an exposition to help guide you when creating your own version.
But this is harder when transplanting to arc3.1 because it has no tests. Honestly I have no idea why you stick with it. Imagine I'm a villain in a superhero movie or a bollywood movie: "where is your savior now? How long will you be faithful to him?" :) Stay with one repo and you'll be out on a limb less. Pick a repo with tests, and you won't be locked in to it when you do need to go out on a limb and transplant code from somebody else.
I feel bad that you struggled for so long by yourself. If you'd ask for help sooner, and if you provide more information, I think your path could be much eased. For starters, it sounds like you've added to arc3.1 over the years. It makes it harder for me to be sure that any code I suggest won't harm you. I recently made a suggestion to tvvocold over email that caused problems because it turned out he'd made changes I wasn't aware of. I'd prefer not to have more of that on my conscience. Can you share the current state of your codebase?
The final thing that helps us help you: forget about compatibility. Programming gets harder the more constraints you add, so try to focus on concrete issues rather than imaginary abstractions. How do you know your existing changes to arc 3.1 are "compatible"? If someone not called pg magically included file upload atop arc3.1, how would you be sure it was "compatible"? In my opinion the reason that "sending anything to a server requires this whole complicated way of multipart encoding/decoding stuff" is the expectation that things just work when you transplant them from one setting to another. I'll make a moral judgement as kindly and respectfully as I can: To the extent that you care about compatibility, you're part of the problem. Uploads are complicated because somebody else decided they didn't want to know about the details and just wanted uploads to work. Add thousands of such people with slightly different scenarios and vague fears of breaking each other, and you end up with all this complexity.
This is your main point really. Compatibility is nowhere close in importance.
I stick with Arc because one of its premises is following an axiomatic approach to building up a language. I don't know enough about Anarki to know if it does the same thing. I could be poorly informed. An admittedly casual survey of the source didn't make me confident that it does. I thought Anarki had logic it didn't need. It was also suspicious how little I ended up needing to add to Arc 3.1, at least until the issue of uploads.
I also stick with Arc because HN is written in it while I don't know of applications written in Anarki. I don't know if even Anarki's primary contributor uses it for web apps (do you use Anarki?) If they don't, that's a dangerous sign of building out of love for building, not need. It can be a good way to explore ideas, but not as good of a way to pick a language to write a web application in.
I do see the savior argument though. Pg admits Arc is missing a lot and doesn't recommend people use it, and he's the one who wrote it.
> Pick a repo with tests, and you won't be locked in to it
What also prevents someone from being locked in is compatibility, not just tests. Having tests for an incompatible language doesn't help a user when switching the language. They have to rewrite their program, and what they have in their head is the source of their program, not the source of the language. It's harder to switch.
> How do you know your existing changes to arc 3.1 are "compatible"?
They added to Arc 3.1, but they did not remove from it or modify semantics.
> If someone not called pg magically included file upload atop arc3.1, how would you be sure it was "compatible"?
I wouldn't be sure, it would need testing. But I know without testing Anarki is not compatible with Arc 3.1.
If pg released Arc 3.2, I know I only need to modify my application to account for the diff between Arc 3.1 to Arc 3.2. That should be a smaller changeset than the changeset between Arc3.1 to Anarki.
> The final thing that helps us help you: forget about compatibility.
This isn't your main argument. Whether I used Arc 3.1 or Anarki, the compatibility issue would still be an issue. I agree that breaking compatibility helps, by the way. Me complaining about multipart data in HTTP is, you guessed it, a result of not breaking compatibility. If there was a new version of HTTP that was not compatible with the older ones but communicated with sexps, I'd switch.
But what you really want from me is to use Anarki.
What I really want from you is exactly nothing. I couldn't give a rat's ass what you choose. I'm pointing out that the chains you find yourself shackled in are of your own creation, in your own imagination.
I mean, I did say I'd help you with whatever your repo was, didn't I? What an ungracious insinuation!
> If pg released Arc 3.2, I know I only need to modify my application to account for the diff between Arc 3.1 to Arc 3.2. That should be a smaller changeset than the changeset between Arc3.1 to Anarki.
You're making some big assumptions about Paul Graham's lack of productivity in the last five years.
> They added to Arc 3.1, but they did not remove from it or modify semantics.
If you define a new function and arc 3.2 happens to define the same name, is that incompatible?
> I also stick with Arc because HN is written in it while I don't know of applications written in Anarki.
I don't understand. Anarki provides the HN codebase just like the arc codebase that constitutes 99% of its code.
> What also prevents someone from being locked in is compatibility, not just tests. Having tests for an incompatible language doesn't help a user when switching the language.
I have no idea what the words you use mean. Tests help you if you're willing to, you know, open a file and write code to make them pass.
This is an unproductive discussion. I'll leave you to keep searching for "compatible" additions to a language that never promised compatibility, where that very concept is utterly meaningless.
I'm sorry I insinuated you want something from me. You've done a lot to selflessly help Arc since it was released, probably more than its own authors and I appreciate that. I'm also sorry I upset you.
It seems the problem with Anarki is that Arc's lists are terminated with the symbol 'nil rather than Racket's null. So you have to convert from Arc lists to Racket lists (and back again). Here is the relevant code:
I think A should be doable. Just call process-comment after submit-item? You'd be double-counting some stats, like for the oversubmitting check. But we can worry about that later.
