We don't have access to the actual code running live on the site, but looking at policies from back in 2009 or so, it looks like you may have run afoul of the sockpuppet detector: https://github.com/arclanguage/anarki/blob/8e330f1242/lib/ne.... That's too bad; sockpuppet detection is overkill for a site this niche.
BTW I'm thaddeus. I check in once in a blue moon, but decided to vote on this and forgot my password so I created another account;).
And it looks as though, because I created the account seconds before voting, I failed at least one test in 'legit-user':
It's possible I failed new-age-threshold* too, but I wasn't all that interested in investigating further.
I dunno; I understand the reasoning, but it still seems like a bad design choice. I'd much rather, circumstantially, be put through a better legit-user test on account creation than to see a forum introduction like that. Oh well, the odds are low for a new user to vote on a poll as a first action anyway. I just seem to always beat the odds :) haha.
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.
Whoa, I could have sworn I responded to this one :/
rocketnia is right that I tend to just run Arc from within its directory, keeping it alongside any Arc program I may be working on at the moment. As a result, I'd kinda always assumed you could run it from anywhere and find yourself in the Arc directory once you loaded up. Now I find this isn't the case:
One interesting point here is how he prioritizes choice of language based on relationships. This connects up with my comment on avoiding dependencies at http://arclanguage.org/item?id=20221. The conventional wisdom that the community of a language matters more than its technical attributes is a diluted version of this idea.
This is short for "no dependencies". I think a lot of software's ills stem from people's short-sighted tendency to promiscuously add dependencies. In fact, our fundamental metaphor of libraries is wrong. Adding a library to your program isn't like plugging a new block into your Lego set. It's like hiring a new plumber. You're not just adding a few lines of code to a file somewhere, you're creating a relationship. Everytime I see someone talk about "code smells", I wait to see if they'll bring up having too many dependencies. Usually they don't, and I tune them out. And the solution is easy. When you find a library that does something useful, consider copying it into your project. That insulates you from breaking changes upstream, and frees up upstream to try incompatible changes. As a further salubrious effect, it encourages you to hack on the library and tune it to your purposes. (Without giving up the options of merging further changes from them, or submitting patches upstream.)
More broadly, Mu is suffused with this ethos. My goal is that if you have a supported platform you should be able to run it with three commands:
$ git clone https://github.com/akkartik/mu
$ cd mu
(That highlights another benefit: your software becomes easier for others to try out. Without giving out binaries, because what's the point of being open-source if you do that?)
Mu's also geared to spread this idea. I want to build an entire software stack in which any part is comprehensible to any programmer with an afternoon to spare (http://akkartik.name/about). Which requires having as little code as possible, because every new dependency is a source of complexity if you're building for readers rather than users. In chasing this goal I'm very inspired by OpenBSD for this purpose. It's the only OS I know that allows me to recompile the entire kernel and userland in 2 commands (https://github.com/akkartik/mu/wiki/Building-OpenBSD-on-Open...). People should be doing this more often! I think I'm going to give up Mu and build my next project atop OpenBSD. But that's been slow going.
The Pike maxim "A little copying is better than a little dependency" comes to mind. I think the overhead of dependencies is underrated ("it's just a 1 line import statement!"), and often a little repetition is a good thing.
It's reading the invalid sequence as � U+FFFD REPLACEMENT CHARACTER, which translates back to UTF-8 as EF BF BD (as we can see in the actual results above). The replacement character is what Unicode offers for use as a placeholder for corrupt sequences in encoded Unicode text, just like the way it's being used here.
"There's a mirage when you first look at it, like with a lake. What you see is just the surface of the lake, and that's a two dimensional view. But when you put your hand in, you find that there's depth to it. It's not just one dimension or two, but a three dimensional design." -- Carl Sassenrath on Rebol, 1996 (https://web.archive.org/web/20000830133509fw_/http://www.lin...)