Lua looks good to me. I was trying to see the performance benchmark from the shootout link, but it's down. I'm pretty sure I put Lua along with python. Docs/libraries are great, but is on the slower side. Lua is on my list to learn :)
I've started haskell. I chose haskell because it appears there is a good balance between performance/documentation/libraries. I already know one language that can be slow, so I think learning a language that's blazing fast will balance the mix. And although Python/Ruby have better docs/libraries - they are much slower than even scheme/arc. Erlang docs are horrific. IMHO.
You came to pretty much the same conclusions I did. I'll probably try out Haskell too. It fits nicely with the kind of side-effect-free-even-to-the-point-of-monads-and-arrows programming I try to do in other languages anyway, and the main thing keeping me away from it has been a perception that it had a really slow implementation.
What I had ended up voting for in the poll though was Clojure. I figure it's lenient about types, it's very reliably cross-platform ('cause of all the business interest in maintaining Java), it has better documentation than Erlang, it can still communicate with C and Erlang (as pretty much any language can, apparently), and beyond that, it has a language-level focus on communicating with other JVM code, which should give you good access to lots of other well-worked-on codebases. As far as I can tell, once you've got access to C and JVM libraries, Python libraries are the next gold mine, but I don't know how to access those libraries except through Python somehow (like through system calls or something), so it didn't affect my decision. (Incidentally, for many of the same reasons I recommend Clojure, I'm hooked on Groovy, but I did consciously try not to let my own criteria make a difference.)
In any case, yeah, now that I see it as fast, Haskell looks great. :-p
I wonder if it's possible to build the beautiful arc syntax as a layer upon haskell. Probably not doable ~ macro's/expansion and all, but still - would be awesome.
Liskell sounds very close to what you're thinking about. Also, the "Write Yourself a Scheme in 48 Hours" Haskell tutorial might interest you. I think this is a pretty popular train of thought. ^_^
That's actually where I'm starting with Haskell. It turns out Haskell is a much more natural home for Blade (my pet lisplike) than any of the other languages I've tried: JavaScript, Groovy, Arc, and Blade itself (with an intent to port/bootstrap it). It's almost scary!
One note: I needed to change the dbslayer source code, prior to making the install, in order to eliminate the spaces that aw's combinator would choke on. It was a trivial change though...
[EDIT: Correction I was using an older version of aw's combinator - the new version handles spaces]
That's cool. It's a neat idea that by default (if there isn't an explicit reason why you have to do something else), all interfaces can be HTTP, and as a bonus use JSON as your data interchange format...
Exactly. The concept is great. Even now when I am starting to learn haskell, the first thing I am doing checking out haskells' JSON parser to communicate via HTTP. Conceptually I can keep doing this and communicate easily across any language. And since SQL to URL is so basic I can re-use/apply dbslayer to any language too.
Yep, way slower. Arc works only because of its escape valves. When I want to parse html I escape to python's beautiful soup and emit JSON. When I wanted a faster JSON parser I escaped to scheme. When I needed something to be still faster I escaped to C through scheme's FFI.
I've only gotten about a quarter through this, but I like what I've heard. Is there a place where I can experiment, aside from the one already mentioned?
I generally take the scheme folder and put it inside the arc folder. This is not required, but earlier I found it easier to manage as they become one movable install.
Arc is best suited to unix/linux or mac operating systems. Arc has some issues on Windows, but In the past I still managed to get it working on windows.
If you're using a unix/linux or mac os you need to find the Terminal application that is already there and launch it.
In the terminal window you need to navigate to the arc directory. You can do this by typing 'cd' (change directory)
followed by the path to the arc folder...
In my case:
Terminal $ cd /users/thaddeus/arc
If all goes well, as a test, you should be able to type 'ls' which will show you the files existing in the arc directory.
Terminal $ ls
now to you can invoke arc by typing (note change the paths to respect your install directories):
Windows is similar only you're using the 'cmd' utility rather than the terminal.
You can start 'cmd' (command prompt) by going to your operating systems 'Start' button then select 'Run' and type 'cmd' into the text entry box (& hit 'ok'). A dialog window should come up. Here you also need to navigate to the arc directory:
Mine starts like this:
C:\Documents and Settings\thaddeus>_
So I change the path to the arc directory like so (note change the paths to respect your install directories):
C:\Documents and Settings\thaddeus> cd C:\thaddeus\arc
I typed all this up on my lunch hour at work, so I didn't actually do the steps - just memory recall. So if you hit a snag ask, I may have typed something wrong.
"Arc requires the clearing of srvops* unless you want the webserver to respond to a dozen URLs in unexpected ways."
Specifically, the Arc web server automatically implements /login, /logout, /whoami, /admin, /mismatch, and various other things, unless you clear out srvops*. I don't know that any of these are security holes, but I'd rather disable them since I don't want them.
I wouldn't worry about using this forum as a means to learn programming. I did. The member's have treated me very well even when some of my newbie questions hadn't made much sense.
The only unfortunate part is that many of the more senior members have left, but the few still kickin around are very helpful - so just keep posting your questions.
pg had been writing about plans for Arc for several years, and so there was a big wave of interest when Arc was first released, and the forum was more active then. We've settled down for the long haul now :-)
Though, without disparaging forum contributions, I wouldn't necessarily equate leadership with the "leaders" list of people with high karma values. Many of the people who have made some of the most significant documentation and code contributions aren't at the top of the "leaders" list.
You have the impression I plan to stop working with/on arc, which is not the case.
The whole point of the FFI is to interface with other languages and such... so I would then need to know the other languages to make further use of the FFI.
I don't know why I would want to write a packaging system, but assuming we're referring to the same kind of packaging... I probably wouldn't use arc when many well developed solutions in other languages already exist.
As for goals/uses... really I just want options. Ideally in the future I can interface between arc and this/these languages. This way if arc is not a good fit for doing some thing then I can use another language to do that part.
Then I look for libraries or API's that will do that thing for me.
If there are several options, I look for one which seems to be the most practical and straightforward implementation.
These days when I go through this process I most often end up with a library or API written for Perl, Python, Ruby, or Java.
What I would suggest is learning enough of each of these languages so that you can make library calls. Which is pretty easy to do; you don't need to learn a lot to do that.
Then how much you need to program in that language vs. Arc usually comes down to efficiency. Each call from Arc to the other language involves a round-trip of some sort; so if you're doing something in a loop then you'll often want to push the code to do that loop into the other language. So you may end learning more of the other language as you translate some parts of your Arc code into the other language.
