

Learn lisp in 5 steps - michaelbwang
http://anthonyf.wordpress.com/2006/07/13/learn-lisp-in-5-easlily-written-steps/

======
Breefield
This list of steps applicable to learning any programming language. 1.) Switch
to appropriate environment 2.) Download an IDE built for your language 3.) 2 +
[insert language]Lint 4.) Read some books on the language 5.) Write a program
that actually does something useful

~~~
silentbicycle
Requiring an IDE specific to your language should be the exception, not the
rule. Why the hell should you have to learn a completely different editor just
to try out a new language? Is the language really so verbose and inexpressive
that you can't even maintain it by hand?

~~~
kenjackson
An IDE is about making it easier to deal with your own code, not the language
per se.

Any nontrivial program... say 50,000+ lines, would benefit from an IDE. Helps
even simple tasks like finding all uses of a given function or pretty
printing.

~~~
silentbicycle
Oh. My objection isn't to having to learn _an_ IDE, it's having to learn a new
IDE, _specific to that language_. If you already know an editor which is
excellent for editing, indexing, searching, navigating, slicing and dicing
text, why should you have to learn a new editor that only even works for that
one language (that you may not even use, in the long run)? Being that tightly
coupled to the IDE should raise a red flag about the language's longevity /
flexibility.

If my editor/IDE has to call out to utilities included with the language to
run build tools, generate some kind of navigation tags, etc., that's fine.
Needing a completely different editor just for that language seems crazy,
though. If it's going to insist on that, it should at least be Smalltalk. ;)

By all means, put your time into an IDE which will remain useful for the next
years (if not decades).

~~~
kenjackson
Ok, I largely agree... you really should be able to get away with knowing any
of vi, emacs, vs, or eclipse ... getting language specific features via
addins.

------
Tiomaidh
I feel like anyone on HN has a basic idea of how to go about learning a
programming language. If you sub in appropriate $books and $IDEs, there's
nothing language-specific in the post. And to be honest, nothing all that new
or all that notable.

~~~
silentbicycle
Agreed, this is fluff, people are only responding to it because mentioning
Lisp pushes HN's buttons.

If you want to read something good about Lisp, check out _Paradigms of
Artificial Intelligence Programming_ by Peter Norvig, David Kranz's _ORBIT_,
SICP, Dybvig's _Three Implementation Models for Scheme_, or the Lambda papers
(<http://library.readscheme.org/page1.html>).

------
jefe78
I keep seeing all this talk of learning lisp but not a whole lot of rationale.
Why should we learn lisp?

What will it replace? Why will it replace? etc...

~~~
pnathan
I'll take a small stab at giving a satisfactory answer.

Some of these apply to all Lisps, some don't apply to different Lisps, for
varying reasons of implementation.

There are two basic reasons for learning a language - personal growth and for
creating a product. In the realm of 'personal growth', Lisp opens the doors in
your mind to working with macros and homoiconic code. It also shares with
other dynamic languages the features of closures, currying, and the usual
benefits of first-class functions. Scheme (as opposed to Common Lisp) has
continuations, which are very powerful. These are all features that open the
mind to new ways of thinking, hopefully for the better.

In the realm of the pragmatic -

Lisp- unlike other modern dynamic languages I know of ( I think Smalltalk can
do this)- maintains an ability to version running objects in a system. It can
perform hot-swapping of code remotely without bringing the run-time down. I
haven't delved into this deeply yet, but I plan to later on. I _believe_
Erlang is the only other major language that can hotswap well. Further, unlike
the other mainstream dynamicaly typed languages going (Ruby, Perl, Python),
Common Lisp can compile functions directly to native code. You will find SBCL
is one of the best dynamic language contenders on the Alioth Shootout. (I'm
not sure how Haskell and OCamls classify - I think they might generate
binaries).

Therefore, Lisp is a good candidate for code that requires 'relatively' good
performance, but isn't worth taking the time to do in C++.

The commercial Lisp implementations have GUIs that are supposed to work
seamlessly on any of the 3 major OSs. That's a major feature in my book.

Lisp is famous for its ability to be expressive via its macro facility and the
regular notation. So if you have a problem which your language is fighting you
with - maybe you should find Lisp and check it out.

I've done some small work with a Lisp program that dynamically created random
functions and then mucked with them on the fly in an optimization effort. It
was, bluntly put, trivial to do the meta-function work. The chief difficulty
was the actual algorithm (and my inexperience with Lisp. :-) ).

In regards to basic Lisp data storage, it is analogous to JSON's relationship
with Javascript: really easy.

So to move this from a boostering to an engineering post, I'd like to consider
some of the cons of Lisp.

Con 1 is the tooling. It's not as flashy as Java's or C#'s. If you need your
IDE and refactoring tools, it's not going to fly for you. Personally, I just
hang out in emacs for all development, so it's water off a duck's butt to me.
:-)

Con 2 is the wreck of library finding. Quicklisp moved us into the 2010s with
its release: it's on par or better than, say, cpan or gem. But there are still
tons of libraries floating out there with crufty code that MAY be useful. This
goes along with the ability of Lispers to write the same utility over and over
again. Or, worse, have the same name for multiple libraries (clon for
instance). I think that the library situation is getting way better though
thanks to Xach.

Con 3 is the system integration. Like Python/Perl/Ruby, directly integrating
into system calls is not trivial in the core language. This is massively
different from C# or C++, where a system function just an using or an #include
away. Common Lisp does have a solid foreign function interface from what I
understand. I haven't used it yet though.

Con 4 is the lack of ability to run on super-low memory systems easily.
Usually a Scheme-Lisp can be crammed in (I know of one that's been put on a
system with 64K of memory). But I'm not convinced anything but C or ASM is the
right tool for this job.

Con 5 is, let's face it, the weird. Continuations. Closures. Unrestricted
lambdas. Macros. Parentheses. _It's not Python/C++_.

I'm not saying Lisp is the Uber-Language, the Ultimate Language From Which We
All Go To (although historically, the ur-Lisp is the primordial ancestor of
all dynamic languages from what I can tell). What I am saying is that it is a
_respectable general purpose language_.

~~~
silentbicycle
Haskell and OCaml both typically compile to native code, and since they have
REPLs, may fit your criteria for "dynamic" languages (which is a very fuzzy
classification). LuaJIT also performs _quite_ well, and IMHO is very pleasant
to work with. Either way, Lisp performance is quite good, _significantly_
better than Python or Ruby, which are often good enough.

Lisp's convenient format for data was a HUGE win, for a while, but other
languages have caught up. Python has dicts, Lua has tables, Javascript has
JSON, ML has its variant types, Erlang inherited Prolog's terms (its parallel
to Lisp's s-expressions), etc. All of the above are _extremely_ useful.
Expressive data and simple code is far easier to maintain than overly simple
data and compensatingly elaborate code. Languages without a good high-level
format for structured data either lose out on a lot of functionality, or
(sigh) fall back on XML.

Also, Quicklisp is quite nice, and props to Xach for setting it in motion.

~~~
pnathan
I'm not sure what I mean by a 'dynamic' language. I know it when I see it. ;)

Well, less facetiously: if I can add in-language functions to the image, using
the language facilities, while the deployed application is running/paused, I
think of that as dynamic.

Data is an interesting thing. There's a crossover point between structured
textual data that can be sucked in and when you want to start doing relational
queries and stores. Then there's how data is handled in the program. The
methods you describe above are very useful, but - insofar as I know of - I
think they can be reimplemented without massive grief in other languages,
depending on extensibility. Lua has a good reputation for speed; I take it you
use it as a standalone?

~~~
silentbicycle
If being able to update code from a REPL while it's running counts, then yes,
though OCaml and Haskell (AFAIK, less experience there) usually involve more
edit-compile-reload, to take advantage of the _utterly_ superior compile-time
checking. OTOH, Erlang handles "change-in-flight" even better than Lisp does.
Of the four, I prefer Erlang, but they're all respectable.

I use Lua both standalone and with C. (Its convenience with linked-in C code
won me over from Python, actually.) It's my favorite general purpose language.
Nothing against the great performance, but it was a great language before
LuaJIT even existed.

Datalog also has a lot of potential as a data format. The industry seems to
forget anything invented more than a fortnight ago, though, so it's probably
passe until somebody charismatic finally invents it.

------
onewland
Step #2 involves learning LISP. As I embark to learn elisp, am I then to re-
install Linux and emacs and SLIME? Then make my way to step 2 again...

