im looking into Arc as a way to broaden my knowledge in programming.
i know a little c++, java and python but want to learn all the languages to some degree before i decide what to specialize in so im also looking into ruby, smalltalk, prolog etc.
when it comes to smalltalk, is it similar in the way that the reflective part of smalltalk is comparable to s-expressions and macros and code is data data si code?
or is this not the same thing at all?
Considering that arc doesn't even have slime support - it's accurate. Now when using slime supported lisps, the environments are at least comparable. Debugging in Smalltalk is awesome and straightforward after you are up to speed. It still takes more dedication to learn slime well enough to debug a gnarly bug.
Both smalltalk and lisp will allow you to create DSLs (domain specific languages) easily for your application. Both see code as data and allow customization of internals. They do this through different approaches. Each approach has different strengths and weaknesses. Also some people are just more comfortable with one approach over another.
I think it speaks volumes about Smalltalk that Avi Bryant could just add continuations (saved closures) to the language for seaside. This sort of ability to add powerful new forms to a language is key and helps set it apart from other languages and put it in the same category as Lisp.
If you are interested there are interesting "History of" papers on Smalltalk and Lisp from the HOPL ACM conferences. They help explain the different philosophies in detail and do a great job of explaining why each language is the way that it is.
I was talking to a fellow lisper recently and he said "If I weren't writing lisp or scheme, I'd be writing smalltalk". I entirely agree with that. In fact I may still end up writing some projects in smalltalk.
Unfortunately I don't have any huge insights. I've been using it on and off since 2005. It was recommended by a friend who lives in emacs. It makes lisp approachable and it makes me way way more efficient when writing and debugging lisp. No swank backend (and thus no slime) makes arc a hard sell. For those wondering what's so great about it - slime supports every major debugging feature I've seen in Eclipse or Visual Studio.
This is what I would recommend for someone learning slime:
If you are a complete slime n00b watch the screencast over at the slime homepage. I just watched it recently and it is well done.
I think the best way to learn from there is through using it to implement a non-trivial yet small project. Make sure the project isn't too challenging, so you have a chance to learn the new environment. Anytime you think there must be an easier/better way to do this - spend time learning slime. Keep coding and you'll continue to put yourself into situations where you can use slime in new ways.
If you have specific questions or problems it is worth asking the community or searching blogs / mailing lists. The questions are either answered already or someone will give you an answer. This is much like all the lisp and smalltalk communities.
I will see if I can get an expert slime user to post some more specific information. Maybe someone else can chime in. I know I have some useful information on specific parts of slime but it wouldn't help someone that is a new user.
They're very very different things, but they have two commonalities. The first is a uniformity: in Lisp, you have data-code correspondence and everything returning a value; in Smalltalk you have everything being an object. The second is syntactic simplicity: Lisp (pretty much) only has its function/macros application with parentheses, (so (all your) 'code (looks like (this))). Smalltalk (pretty much) only has objects and message sending, so all:(your code) looksLike:this.
In fact, given Smalltalk's syntactic uniformity (if, while, etc. are implemented as methods on booleans, etc.), I've occasionally wondered if one could write a Smalltalk with macros. Does anyone know if this exists or why it wouldn't work?
There's a longstanding debate between the two communities about whether or not macros provide any meaningful benefits that Smalltalk blocks don't. (The archives of the LL1 mailing list contain a gold mine of posts on this.) In general, I doubt that most Smalltalk hackers would be very interested in macros in Smalltalk; they'd probably see it as out of sync with the spirit of the language. (Compare this to how Lisp hackers react to the inevitable newbie attempts to "fix" Lisp by removing parentheses or making it infix.)
I think macros in smalltalk are plausible. I have nothing to back that up. I am definitely not a smalltalk hacker. I think that smalltalk can solve the same problems that macros solve just through a different approach.
Well, I can't write up a big description right now, but they're definitely completely different sorts of things.
The basic way I'd think of it is that LISP lets you do clever things by keeping the core design of the structures inside of the compiler/interpreter as simple/primitive as possible.
Smalltalk lets you do clever things by having the run time system "take care of the hard stuff for you."
...Although maybe this description is overly simplistic.
Smalltalk: everything is wrapped around (real!) Object Orientation.
Lisp: everything is wrapped around Lambda Calculus using nothing but lists, lists and lists.
Now, you can express OO in LC (and vice versa), but Lisp is simply much simpler at its very base (and this means, in this context, that it's automatically more ingenious).
And that's the whole point. So, if you have the choice...
Everything is python is not an object. Python uses procedural control structures like if/else/while/for implemented as special keywords. Smalltalk implements those control structures with objects, the Boolean subclasses True and False which have methods ifTrue:ifFalse: and the class BlockContext which implements methods such as whileTrue: and whileFalse:.
Having objects is entirely different from using objects as the basic building block of every abstraction in the language. Objects in Smalltalk are what S-expressions are to Lisp. Python and Ruby just have objects, but those languages aren't built from objects.
