[Openmcl-devel] bad impressions to Lisp newbies

Leslie P. Polzer sky at viridian-project.de
Mon Apr 27 08:07:32 UTC 2009


Hi Alex,

>> I'm not sure how it is with the CCL Cocoa interface or CCL on Mac in
>> general, but isn't the IDE a non-essential gimmick?
>>
>> Rather like "No, we don't need to build it actually, but see here CCL
>> gives us this cool matching IDE for free!".
>
> I hope this is just flame bait... OK, I bite

Just as well because it wasn't intended as flame bait. Just trying to
be helpful. :)


> I can see that for some experienced Lisp users perhaps the command
> line or SLIME may be fine but this simply does not work to attract new
> programmers at any meaningful level. CS students are used to Visual
> Studio and Eclipse these days. They would not even call the CCL IDE an
> IDE. There is something to be said for a simple IDE such as the one
> MCL supported. I have successfully gotten students interested in that
> one but I have NEVER seen a student getting into Lisp via command line/
> SLIME kinds of interfaces. Even most browsers, e.g., Safari, have
> built in IDEs with JavaScript REPL, breakpoints, object inspectors.

I fully agree, yet you should explain it to future might-be Lispers
that the IDE is a non-essential add-on and that Lisp (...Ruby, Python,
PHP, Perl, C, C++, Java, ...) will work without it, too.


> If an IDE a non-essential gimmick why do you even use SLIME?

I do not use Slime or anything like it.


> Why not program with punch cards.

That's plain hyperbole. I can just work most effectively with the
command-line and separate editor and REPL, and the comparison
between punch cards and the command line is comparing apples
and oranges.

Command line and IDE/GUI are two fundamentally different paradigms,
and I wouldn't dare to say that one is archaic (or something else
that would denigrate one of them substantially).


> I am not even sure where all this back to the basics comes from.

I'm not sure what you mean. The command line is a well-proven tool[1]
and I use it for all of my daily work, achieving multiple times
the speed of others.

Again, that is not to say that IDE programmers are slower in
general when compared to their peers that work primarily with
the command line.

I'd just like to point out that the command line approach is not
inferior to the IDE approach, although of course if you're not
used to command line work then my talk may not mean anything to
you.


[1] Not a proof or anything, but an interesting read that might
    help you understand why I and many others like to work with
    the command line:

    http://www.rap.ucar.edu/staff/tres/elements.html


> Certainly not from Lisp. Lisp actually invented many of the
> great IDE concepts. Remember the Symbolics?

Not directly, but I get your point.

Reiterating: command line and IDEs are fundamentally different
and may easily co-exist or merged in hybrid approaches.


>> Lisp communities are small and most projects often don't have enough
>> man-power (and/or varied system environments exposure) to keep all
>> aspects of their software in good shape, so it should become second
>> nature to prepare and double-check a demo before showing it to
>> someone.
>
> Ask yourself: WHY are the Lisp communities so small? It is because
> Lisp has gotten a bad reputation suggesting that it is hard to use.
>
> It may be some work to fix a non working example to be sure but I
> would claim it is better to hide broken stuff from new users.

It was not my intention to say that your criticism is invalid,
or that it shouldn't be fixed. The statement that a small community
might be the cause of such errors also wasn't intended as an excuse,
only as an attempt at explanation.

So yes, stuff should be fixed or hidden.

My suggestion was only that you give stuff a quick test run before
you attempt to show it to someone else in order to detect any
problems.

  Cheers,

    Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




More information about the Openmcl-devel mailing list