hello, i find "LISP" to be frustrating

[badbetty]

hello, im new to LISP (and this forum).

Firstly, I must apologise for the subject text. It is hardly an endearing opening likely to garner support.
However, I do stand by it in some senses. I apologise too for choosing to not include some examples to back up my statement below.

As a new to the LISP world with fresh unbiased eyes...I see it like this: LISP has many flavours and that doesn't help and to make matters worse, [some of] the libraries of modules/apps/etc that are available only work with the certain flavours (or are tested to work with) and not others and then....well there are a few other things.

This makes the whole thing a bit of a bind. Of course one could pick a flavour and redevelop/resolve the stuff one requires (perhaps using a base of code from some of the hard work already gone in elsewhere) to work with one's chosen flavour if it is causing issues, but that defeats the object of shared open libraries of hard work and skilfull effort already gone in.

It is a shame as LISP comes across to me as intriguing - I've know about it, seen it rarely, never experienced it until delving in of late.

What would be great - as with the effort of 'common lisp' to bring some order to the previous - would be if there were not many flavours, but one and libraries were working with the one LISP...as in LISP is LISP is LISP.....when at the moment it is not.

I dont find this happens much (in fact at all) with other languages/environments I have encountered.

Still, I am very intrigued by LISP for some reason..should have got involved years ago.
Perhaps I am being too harsh....but it may be another reason why the perception of LISP (at least that I have read from critiques) is as it is in some areas...care about that or not

Cheers. I bat on.

[badbetty]

Well.. having read a little more of the few commentary bits and pieces about since my [arguably poor] post above, it would seem that there is support from [some] 'lispers' for this variety of lisp platforms/versions or what have you. In some senses I can see why that is held, but still for me it is an issue when someone develops a lisp library/app/tools and it is not usable (for want of a better word) in one/some other flavours if the 'common lisp' ideal is to stack up. My naive ramblings (possibly to my self are most likely misplaced and as I get more familiar, my views may change I suppose.

Have a good day everyone - where ever you are or whatever you do.

[David Mullen]

It might be nice if there were a Super Lisp, subsuming the various dialects and implementations—but that would imply convergence on a whole set of trade-offs, agreement on how to standardize the (currently non-standard) extensions, in particular: the Foreign Function Interface, etc., while still leaving elbow room in the implementation details. In the meantime, picking a supported, time-tested Lisp implementation wouldn't seem likely to leave anyone high and dry—right?—even if there are bound to be pain points, here and there (as with anything else).

[sylwester]

With fresh unbiased eyes? Do you mean this is your very first programming language? Then this would be much easier than us people who has learned Algol first. If you have learned an algol dialect then it will be as learning a new natural language with LOTS of false friend words.

As with flavors there are just a handful lisp dialects and perhaps 5 algol dialects per lisp dialect. AFAIK you cannot take a library written in the algol dialect python and use it in the algol dialect JavaScript.

Here are the most common lisp dialects:
Common Lisp (Several implementations, one standard, large core library)
Scheme (several versions with R5RS being the most common, R6RS got lots of libraries, but not as batteries included as CL. R7RS-large might change this)
Racket (A Scheme fork that is incompatible on som easpects. It's a one implementation language, but more batteries included like CL than Scheme)
Emacs Lisp (Most used since many uses Emacs editor and it was originally very similar to CL but somehow leaning towards being a Scheme)
Clojure (A lisp very similar to Scheme, but that is based on the Java VM. Clojure leaks its host such that a port of actual source is not straight forward since using a Java library is not portable to JavaScript which would need a JS library.)
AutoLisp (A embedded language in Autocad applications)

The other dialects are really not worth the effort unless you are very interested. Like new algol languages they don't get their niche so they tend to stay uncommon. Clojure is perhaps the newest in the list and its main feature is that it runs on the JVM and you can use all your existing Java stuff and you can even use Clojure stuff from Java. Arc is cool and I might have used it if they made it a language under Racket since then you could use Racket libraries in it or even used Arc libraries in other racket languages, but since it was made an interpreter written in Racket I lost interest very fast.

[DionG]

Great insights sylwester. Thanks for sharing the info.

[HappyMacXL]

hello, im new to LISP (and this forum).

Firstly, I must apologise for the subject text. It is hardly an endearing opening likely to garner support.
However, I do stand by it in some senses. I apologise too for choosing to not include some examples to back up my statement below.

As a new to the LISP world with fresh unbiased eyes...I see it like this: LISP has many flavours and that doesn't help and to make matters worse, [some of] the libraries of modules/apps/etc that are available only work with the certain flavours (or are tested to work with) and not others and then....well there are a few other things.

This makes the whole thing a bit of a bind. Of course one could pick a flavour and redevelop/resolve the stuff one requires (perhaps using a base of code from some of the hard work already gone in elsewhere) to work with one's chosen flavour if it is causing issues, but that defeats the object of shared open libraries of hard work and skilfull effort already gone in.

It is a shame as LISP comes across to me as intriguing - I've know about it, seen it rarely, never experienced it until delving in of late.

What would be great - as with the effort of 'common lisp' to bring some order to the previous - would be if there were not many flavours, but one and libraries were working with the one LISP...as in LISP is LISP is LISP.....when at the moment it is not.

I dont find this happens much (in fact at all) with other languages/environments I have encountered.

Still, I am very intrigued by LISP for some reason..should have got involved years ago.
Perhaps I am being too harsh....but it may be another reason why the perception of LISP (at least that I have read from critiques) is as it is in some areas...care about that or not

Cheers. I bat on.

Hmm- have you considered an alternative approach for learning? As a starting point what if you were to look at learning Lisp to program a short text adventure game? Bear with me on this for a moment. Part of the challenge I have always had is having a need or reason to learn beyond "because I need to for work" etc With Lisp I am currently learning ZIL. It's extremely uncommon now, but there is a core niche group of users, and the beauty is that the entire purpose of ZIL is to create text adventure game programs. It will teach you some essentials (objects, routines, properties) in a way that is fun and open-ended.

Just a thought.

Adam.