We also have ClojureScript, which is basically Clojure that compiles to Javascript: Lisp for the web browser. It combines the power of Clojure with Google's Closure web development library to spit out tight Javascript without any of the bad parts.
It's still not fully baked, but it's getting there. Clojure Lisp for web client development on top of Clojure on the desktop and server - my cup of Lisp doth brimmeth over.
I looked at ClojureScript at the source and perhaps I am wrong, but I like the simplicity of Arc and his approach.
But it is fine that others also go into this direction.
I think the difference is that to run an Arc powered website, you would need an Arc box on the server side, which is what you would need for running Clojure websites as well. What ClojureScript does is generate and compile the necessary JavaScript which can be off-loaded onto any (or at least most) web hosting sites, including shared web hosts. Additionally, the use of compiled JavaScript gives you the benefit of leveraging client-side processing, as opposed to Arc or Clojure boxes which are server-side solutions.
But you are right, Arc is great too, and it ultimately boils down to individual choice. Arc is my first Lisp, and I like it above Scheme/Common Lisp, as well as Python and Ruby.
[kdd@780 wart]$ ./wart
g++ -O3 -std=gnu++0x -Wall -Wextra -fno-strict-aliasing boot.cc -o wart_bin
In file included from file_list:21:0,
from boot.cc:75:
029posix.cc: In function ‘Cell* compiledFn_socket()’:
029posix.cc:47:1: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
which: no rlwrap in (/usr/local/bin: ... )
ready! type in an expression, then hit enter twice. ctrl-d exits.
(+ 22 22)
=> 44
(prn "hello")
hello
=> "hello"
Ran it on Arch Linux (3.6) and played around. Looks pretty good though I'm not so sure about the double enter requirement. Very superficially I'd say I prefer the empty line after the result, keeping the expression and result together and segregating each expression/result set; the absence of a prompt looks quite good:
"Looks pretty good though I'm not so sure about the double enter requirement."
It's not just wart: readable has the same issue. The problem is that you don't know if the user is finished or if they want to enter a multi-line expression. With parentheses, you always know whether the expression is completed or not, but with whitespace, you don't.
The same is true even in Python. If you type in this:
>>> def foo(x):
... return x
You have to hit enter twice. In some cases, Python is smart enough to know that the expression ended, so you only have to hit enter once:
>>> 1 + 2
But that's because Python's grammar is more restricted in certain areas. That doesn't work with S-expressions because they're so general.
I realized after I'd read wart's readme that parens were optional, though I don't think that would have been enough to clue me in on the double enter requirement. :)
Yeah, I didn't expect everyone to remember that :) I just wanted a sense of whether the no-prompt prompt was intuitive. So far it seems to be intuitive!
Thanks a lot for the comments! Pauan's right that the indent sensitivity seems to require the two newlines, and it is indeed weird that responses get grouped with the next command. I'm still looking for a better approach.
I'm interested in that warning you get. Are you on a 64-bit system? Could you type in the following into gdb and share the results?
$ gdb -q
(gdb) p sizeof(int)
(gdb) p sizeof(long)
(gdb) p sizeof(void*)
Edit: I just noticed that gdb on my machine gives different results with and without a binary. So you'll need to invoke it from the wart directory like so:
Also, it seems that error message came up only the first time I ran wart. I haven't seen it in later executions so there's probably no need for any additional concern. :)
It comes up when building the C files. Since you haven't made any changes to the sources since there's no need to rebuild. But you can see it again if you first run:
This interview was on HN a couple of weeks ago. I really liked it, especially the way it highlighted Torvalds practical approach to life and work:
Pragmatic: Going the GPL way was the right decision for him, and yet any other proprietary way is also fine if you so choose with your own software; copyrights and patents are problematic, but only in the extent to which they are being implemented - no problems with the concepts themselves.
Balanced: "So I can be very passionate about some things, but at the same time I don't tend to really hold on to some particular issue for too long, and I think that helps avoid burn-out."
Strong values: "Don't work for a commercial Linux company even if it seems like such a natural thing to do - keep working in a neutral place so that people can continue to work with me"
Sounds like a guy who has everything pulled together, in addition to being the creator of a very successful and highly regarded OS. Torvalds is climbing rapidly up my chart of technology heroes. :)
I hope to, at some point. Unfortunately I'm nowhere in the range of riffin' on language design issues, and have a lot of catching up to do. Definitely very passionate about technology but I lost some years (20+ years to be precise) working in the civil service, including my free time in at least ten of those years which I thoroughly buried on the golf course. ;)
Yes, I got my handicap down to 10 or 11, which was nice, but what would be nicer would be getting those 20 years back and putting them to use leveling up on my coding skills!!! Still, those twenty years weren't entirely lost - I did manage to pick up a fair amount of experience writing hobby desktop applications and honed my SQL skills to a decent level. But I would like to have learned much more than that! I'm working on it now... finally.
I recall listening to an interview with Uncle Bob Martin in which he said he just figured he loves coding so much, he'll just continue doing it till they find him with his nose between the keyboards. I guess he meant it like how a cowboy means it when he says he wants to die with his boots on. I just want to echo those sentiments. And I get the sense from Arc Forum regulars that you all feel that way as well. That's why I like it here. :)
Yep :) No pressure, but metaphors like 'leveling up' and 'handicap' are just that -- metaphors. Just build something that scratches an itch, whether it's here or on the golf course. You might even be building something already. Just throw it over the wall. We're all nice here, so there's no downside compared to not showing, and unlimited potential upside in terms of getting feedback, more ideas, accelerating learning, and just getting an endorphin rush from having done something :) It doesn't have to be hacking on internals or anything. It doesn't have to be in arc or any lisp. Any little baby program will do.
One way to think about it: this is a small enough community that we can afford to get to know each other better. That's precious given the world we live in, the tendency to move fast, be busy, not know neighbors. And the best way to accelerate that process here is by sharing our code. (Or rants, but those can be harder to write and put out there, at least for me :)
---
You know, I don't know if I'm passionate about technology. I just care about code, man. Code and the using of it to make sense of how the world works.
Thanks zck and akkartik. And I especially like this: One way to think about it: this is a small enough community that we can afford to get to know each other better. That's precious given the world we live in, the tendency to move fast, be busy, not know neighbors. And the best way to accelerate that process here is by sharing our code.
I'm a computer hobbyist and am (or was) an economist and business major by training. I spent most of my coding time in the past in proprietary languages and environments (dBase, Visual FoxPro, Paradox, Visual Basic, C# and MS SQL Server), with a little bit of MySQL and PHP thrown in the mix. That was from about 20 to about 8-10 years ago. It was only in the past 2-3 years or so that I opened my eyes to the open source world, stupid me. :)
I spent the early parts of this current stage learning Python, which I liked. And sometime earlier this year I moved on to Ruby, which I liked more. It was when I moved to Ruby that I realized I didn't really like Python's mandatory white space rules (among other things), and later, after I'd got into the innards of Arc, I got to see Steve Yegge's point that Ruby also has some of the whale gut strewn around as a result of borrowing too much from Perl.
I find Arc to be a really clean implementation of Lisp, producing clear, tight code - but two things draw me back. One is the smallness of the Arc ecosystem (primarily libraries, community developed toolkits, etc) and the other is the apparent neglect by its developers. So I made a second stab at Clojure (my first attempt cooled off after facing initial difficulties figuring out the Clojure tool chain, set up requirements etc. which seemed rather off-putting then).
The second attempt was good, and I've come to appreciate the simplicity and beauty of Clojure, and the relentless effort that Rich Hickey and others like Stuart Halloway are making in evolving it further, as well as getting their design philosophy and message out to the wider community. I've caught the Clojure bug and have settled on using Clojure and Clojurescript to scratch my itches. I'm also assessing Datomic to handle my data requirements. Let's see how it turns out - I'll post reports of my evolution in this direction as I move along.
I sincerely hope that Paul Graham and Robert Morris will give a little more attention to Arc's development in the near future. It's hard to see Arc become a 100 year language without some kind of nourishment from its authors. Of course, I will continue to play with Arc, will continue to enjoy the thoughts of fellow regulars on the Arc Forum, and will do whatever I can to help maintain http://sites.google.com/site/arclanguagewiki.
What language was that? J looks very interesting, particularly the jdb side of it. I'd only recently come across q/kdb so learning about the free j/jdb alternative was great.
Sounds great. Datomic already packs a lot of great features, and from what I'm reading, Rich Hickey, Stuart Halloway and Co. are far from done yet. I'm watching this space very closely though I haven't dived in yet. Up to my gills in Clojure right now, which is proving to be a very enjoyable expedition. Arc was my first Lisp, and learning it made Clojure very approachable. Not a bad year this: learned Ruby, Arc and Clojure - and all three were great fun. Datomic's up next.
Yeah, it's the same in Arc 3.1. Personally, I would put it into arc.arc, since I use it frequently when dealing with strings, but one of Arc/Nu's goals was to run Arc 3.1's arc.arc unmodified.
Maybe I could have Arc/Nu autoload lib/strings.arc?
If you ever want something auto-loaded, just add it to the "arc" executable. It's very easy, just one line of code per file. Maybe I should have it autoload "lib/re.arc" as well...
Thanks Pauan. Regarding lib/re.arc, my take is that if Arc 3.1 does it by default, arc/nu should do the same to match Arc 3.1's out-of-the-box functionality, unless of course if you have specific reasons that justify not loading it up front.
I hadn't tried regex support in Arc earlier so I just figured Arc 3.1 must have it. However, I checked and found that Anarki does have lib/re.arc loaded by default.
