The difficult learning curve of Lisp
Dwight Army of Champions
programming") is more difficult to grasp than learning other
programming languages because it forces your brain to operate at
different levels of abstraction. I know nothing of Lisp and come from
mainly a C++ background. Is this true, and if so, why?
RG
<c6e4f310-2fb0-47c7...@n10g2000yqf.googlegroups.com>,
> mainly a C++ background. Is this true...?
No.
Pascal J. Bourguignon
Yes. Because you have a background.
To learn lisp, you will have to unlearn C++.
If you knew nothing, it would be easier to learn lisp than C. But since
your mind has already been distorted, it will be harder.
You may try to ignore what you know, and if you can, you might be able
to learn lisp without too many difficulties. You might even start to
forget C++, and begin to like lisp.
Then of course, another difficuly happens: you won't want to program in
C++ anymore (or Java or PHP, etc), and you'll become unemployable. Well
apart from a very small number of lisp companies.
SICP = Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
http://eli.thegreenplace.net/category/programming/lisp/sicp/
http://www.neilvandyke.org/sicp-plt/
http://www.youtube.com/watch?v=rdj6deraQ6k
PCL = Practical Common Lisp = http://www.gigamonkeys.com/book/
GENTLE = Common Lisp: A Gentle Introduction to Symbolic Computation
http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/dst/www/LispBook/index.html
http://www.cs.cmu.edu/~dst/LispBook/
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Rob Warnock
+---------------
| You may try to ignore what you know, and if you can, you might be able
| to learn lisp without too many difficulties. You might even start to
| forget C++, and begin to like lisp.
|
| Then of course, another difficuly happens: you won't want to program
| in C++ anymore (or Java or PHP, etc), and you'll become unemployable.
| Well apart from a very small number of lisp companies.
Yes, well, that can happen. But you also might learn something from
your Lisp experience and simply *continue* programming that way in
C or C++ or Java or whatever, Greenspunning[1] your way to synthesizing
closures[2] or higher-order functionals or useful macros[3] or the like
in whatever languages you're forced by your employers to use.
-Rob
[1] http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule
[2] Java (and C++?) sort of has (have) them already, though for mutable
closed-over variables you'll have to do your own box-conversion.
[3] Will probably require writing a tiny separate pre-processor
for your embedded DSL.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403
D Herring
Many languages are small excursions from C. Thus they are more
familiar to C programmers; but they also have less benefits.
Do you understand C++ templates? In Lisp, macros serve their place.
A uniform syntax is used to express function calls, macros, method
calls, ... People also tend to reuse lisp sources as configuration
file syntax, a command-line language, simple output format, ...
This simplification can be hard for people to grasp.
void f(int x) { ... } -> (defun f (x) ...)
template <class T> void f(T x) { ... } -> defun as above or (defmacro
make-f (t) ...)
#define F(x) -> (defmacro f (x) ...)
struct S { void f(); } -> (defmethod f ((x S)) ...)
Function, macro, or method, they're all invoked (f x). Thus where
you're used to thinking about parsing {[<()>]} and tracking operator
precedence, lisp programs look more like (((()))). Many people stop
there. Lisp-aware editors simplify the balancing of parentheses, and
standard Lisp indentation splits expressions across lines to eliminate
visual ambiguity.
The different level of abstraction is quite freeing. Forget about
memory management and object lifetimes for a while. Forget about the
inconsistent overlap between struct and class and namespace and enum.
Forget that C macros are required to manipulate names, functions to
manipulate values, and templates to manipulate types.
In Lisp, you can use the same libraries whether writing a macro or
function, whether it runs at compile time or run time. Lisp macros
understand the syntax of what they're manipulating; they manipulate
data structures, not just token strings.
Lisp lets you think more about what you want to do and less about
language restrictions. Need a small function, but can't think of a
name or just want it declared in the loop? Just call (lambda (x)
...). Realize that values have type, not variables. That methods are
functions that dispatch on their parameters, not members of a data
structure. Enjoy invoking the optimizing compiler at run time. etc. etc.
There are some things that are hard in Lisp. Some things are just
hard in any language. There are times where I do miss C++ value
semantics (e.g. aggressive garbage collection like shared_ptr), but
for me Lisp is often a way to relax from C++.
- Daniel
Pascal J. Bourguignon
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
> +---------------
> | You may try to ignore what you know, and if you can, you might be able
> | to learn lisp without too many difficulties. You might even start to
> | forget C++, and begin to like lisp.
> |
> | Then of course, another difficuly happens: you won't want to program
> | in C++ anymore (or Java or PHP, etc), and you'll become unemployable.
> | Well apart from a very small number of lisp companies.
> +---------------
>
> Yes, well, that can happen. But you also might learn something from
> your Lisp experience and simply *continue* programming that way in
> C or C++ or Java or whatever, Greenspunning[1] your way to synthesizing
> closures[2] or higher-order functionals or useful macros[3] or the like
> in whatever languages you're forced by your employers to use.
Not really. The more you greenspun, the more you suffer.
You start by collecting libraries,
http://www.informatimago.com/articles/life-saver.html
all the way to libecl.
And all the way, even the slightest use of higher-order functionals or
templates will be met with incomprehension by most of your coworkers.
If as is usual, your project is already late (sales always promise
unrealistic delays) and understaffed, you won't have time to teach them
how to produce more programmer-time-efficient code.
Bakul Shah
A different level of abstraction but not necessarily harder.
If you know one programming language well, you already know
the basics of `thinking like a computer'. Picking up another
language is much like learning to play another instrument
when you can play one kind well. But you can't play a piano
like a flute, can you?! Similarly you have to learn to "play
in lisp" and not try to recreate C++ in Lisp. With a good
programming book and an interpreter you will get your first
program to work in minutes if not seconds!
So a) don't believe it is hard -- it is actually very easy
& b) don't believe you have to "unlearn" anything. But
"learning lisp" is not the same as becoming truly competent
in it and that can take time (the same is true in any PL).
Marco Antoniotti
I believe the difficulty depends on a number of factors. Grasping C/C++ pointers is something that neither Lisp nor Java prepare you for (YMMV). The other way around has similar pitfalls. The only thing that I believe can be said is that in your 20s and 30s, if you know a few languages, it is easier to pick up one more. Me, I am past that. That is why I don't understand WJ's posts. :)
Cheers
--
Marco
Raffael Cavallaro
> [2] Java (and C++?) sort of has (have) them already, though for mutable
> closed-over variables you'll have to do your own box-conversion.
And you don't even need to do that anymore for C/C++/Objective-C;
Apple's blocks extension to gcc gives you real closures, including the
__block storage type modifier which declares mutable, closed-over
variables. I'm pretty sure it's available on the net for other
platforms than darwin (linux, etc.) as well.
warmest
regards,
Ralph
--
Raffael Cavallaro
Andrew Reilly
Much is made of the different approach to programming, and it is
certainly a mind-expanding experience that I highly recommend.
For me the steepest part of the learning curve was simply the entirely
different vocabulary, more than the different syntax and more dynamic
(heap oriented) memory system. Most post-Algol languages share large
chunks of vocabulary, particularly the post-C languages (and these
include Perl and PHP and the like.) This includes both reserved words
and names for library functions. The corresponding functions and
operations almost all have different names in Lisp. So you need to have
a good reference handy, and expect slow-going for the first few projects.
Once you've got the vocabulary down (or at least started to learn how to
expect what a function might be called, and how to look for it) is when
you'll start to really get to grips with the subtle differences of
approach that the different and more seamless abstraction mechanisms
allow.
Cheers,
--
Andrew
TheFlyingDutchman
> if you know a few languages, it is easier to pick up one more.
> Me, I am past that. That is why I don't understand WJ's posts. :)
LOL
Marco Parrone
Lisp isn't just functional programming and it isn't hard, it will enrich
you with some new paradigms that you will be capable to copy/use/abuse
in other languages too, for example I was inspired by Lisp to write code
like this:
/*
* Apply `fun' to all the elements of `vect', which size is size, with
* 2nd argument arg2, and don't provide a return value.
*/
void
vmap2vect (void fun (void *arg1, void *arg2),
void *arg2, void *vect, unsigned int size, unsigned int type_size)
{
unsigned int i;
for (i = 0; i < size; i++)
fun (vect + (type_size * i), arg2);
}
...
void
print_activity_helper (void *arg, void *arg2)
{
print_activity ((FILE *) arg2, (activity_t *) arg);
}
void
print_activities_vect (FILE *fp, activity_t *activities, unsigned int howmany)
{
vmap2vect (&print_activity_helper, fp, activities, howmany,
sizeof (activity_t));
}
I suggest you to give a try both to Common Lisp and to R5RS, both have
strong points.
Goodbye
--
Marco Parrone <ma...@marcoparrone.com>
PGP Key fingerprint = 5E21 BED2 BF47 B3FB F17F 1DB4 D9BE B2B7 3C3A 07E2
Teemu Likonen
> I've read that learning Lisp (especially this thing called "functional
> programming") is more difficult to grasp than learning other
> programming languages because it forces your brain to operate at
> different levels of abstraction.
In order to learn (Common) Lisp you are forced to unlearn myths about
Lisp. Just go ahead and read some more.
http://en.wikipedia.org/wiki/Common_Lisp
http://www.gigamonkeys.com/book/
Ken Wesson
I was writing C code like that *before* becoming acquainted with Lisp.
Function pointers everywhere and being passed around.