31–40 of 40 posts
Earlier quoted context omitted.
I think we need a linkbait article about whether or not F# is an acceptable Lisp before I seriously consider it.
I don't really care if it is an acceptable Lisp when I decide if I will or will not learn something. :P BUT, I will use that excuse on my teacher on the Calculus class.
This was said in 'The Next Lisp'
Earlier quoted context omitted.
I don't really like this analogy because you can more easily shared piece of useful software across Linux distributions than you can across lisp implementations. True that the differences are limited to things outside the specs, but somehow my applications almost always stepped in these parts.
It is not a matter of software, but a matter of usability. Think of a Windows user only perspective. When installing a distro, you are confronted with the choice between X, KDE, Gnome, Compix, or whatever else Windows Manager is out there now, just to SHOW the Desktop. You haven't even started to use the OS and you must already make decisions about what to Window Manager to use. Most people don't even know what a Win…
There usually not a lot of development time to rework an application from one distro to the next. Also very rarely you'll need a package that is only available on another distribution. It is the case with CL implementations tough.
There are basically two main camps, Lisp-1 and Lisp-2 and consequently two divergent major families, Scheme and Common Lisp. From my recollection, the "Lisp Wars" started with hardware implementations, Symbolics vs. Lisp Machines, et al., see http://en.wikipedia.org/wiki/Symbolics.
My take is that the hardware implementations came at a time when CPU speeds and memory capacities where not up to the demands of integrated Lisp environments. By the time speed and memory were sufficient to host Lisp, the world of IT got preoccupied with x86 architecture and Windows. Neither of these being suitable (in 1980's) as a production Lisp hosting environment.
In the hands of an expert Lisper, any version of Lisp quickly becomes extremely productive. The issues of libraries (FFI) and compilation are addressed in different ways, it's like you have a choice! It's like asking a guitarist why there are so many brands of guitars? Why don't they all use ____ (insert your pref. brand).
To research further, I suggest looking-up "John McCarthy", "Guy Steele", "Richard Gabriel", "Symbolics", "Lisp Machine" on Wikipedia and Google.
Nonetheless, you'd be able to answer most of them if you tried to make a few of your own knock-off programs in lisp. ;) To do that, you'd have to decide on a lisp, installing a few and trying them out, and then decide on a project -- hopefully, something small and manageable. Perhaps a visual "hello, world" program. Or a code-golf exercise. My personal "hello, world" for learning a new language is usually a basic 1D cellular automata.
Once you've written your hello world, you'll have answered many of your questions. Next, rewrite it! Is your code idiomatic? What are some common idioms, and why do they exist? Could you make it shorter?
Next, extend it. Can you use it from the web? What would it take? What about letting people customize your helloworld? etc etc. See what it feels like to develop in the new language, even though the entire "project" cycle could conceivably be done in a single day. (Disclaimer: not by me. It takes me, at least, two months of part-time hacking to feel affection for a language).
After that kind of a learning process -- which isn't terribly onerous; it's the sort of thing you end up doing with almost any interesting language -- you'll look back at these questions and laugh.
And, if you aren't willing to go through that sort of "learning lite", why bother asking the questions?
( If you're looking for enlightenment about the process of actually using Lisp, in book form, I recommend Practical Common Lisp, which is available as a free pdf ).
"If this is true and everything on the language are built atop of those, or atop of stuff built atop of those (in n-levels), how can different implementations possible be incompatible?" You cannot build i/o atop of axioms. It would always be a foreign thing that you have to deal with, incompatibly of using a long spec.
Details matter, and ultimately the code needs to run on a machine. Hence the implementation matters.
As for the Linux comparison, once you really know (i.e. can use command line, the shells, awk, grep, sed, etc) one Linux distro, you can work your way through the others and even AIX, the various BSDs, HPUX, Mac OS/X and Solaris.
When you write C, you can be reasonably sure it will compile with a decent C compiler. There is no way to write 'Lisp'. Each Lisp dialect has different goals. A person might as well think of them as completely different languages belonging to the Lisp family. It might be analogous to think of Perl, Python and Ruby as being high-level dynamically typed interpreted languages as being part of the same family, but having…
C, C#, C++, Objective C, C with extensions, ...
Earlier quoted context omitted.
1. choose your lisp dialect: do you want to learn CL, Scheme, Arc, ...? 2. randomly pick an implementation of your chosen lisp. It really makes no difference as a beginner. I speak from experience. You can always switch later in a painless way. regarding CL, choose an open source implementation if you don't fear things like emacs. If you prefer a more polished IDE, choose a commercial implementation.
CL on Lispbox is what I have now. Which means I use (use being a overstatement) e-Macs with a Lisp extension.
Read the bipolar lisp programmer, it's quite an interesting insight. http://www.lambdassociates.org/blog/bipolar.htm
I'm a self taught(obsessed?) programmer, barely finished high school, quit collage the first month. And I just started with Arc Lisp. It feels so right and has improved my programming in other aspects. The good thing is that now I'm in nerdvana doing what I love for a small but cool company.
Read the bipolar lisp programmer, it's quite an interesting insight. http://www.lambdassociates.org/blog/bipolar.htm