On Nov 17, 3:52 am, Luc Prefontaine <[EMAIL PROTECTED]> wrote: > Since it's existence, LISP has not gained a large acceptance in the > commercial market compared to other "conventional" programming > languages.
This is true; I think, though, it's largely a fashion thing. In the days when you and I learned LISP, LISP was inherently too big (and played with too big ideas) for the computers most people used. Now we have computers - hell, we have cellphones - which can actually run big LISP systems effectively, but LISP is still out of fashion because managers in IT - people our age - still think of it as 'too big' and 'too strange' (and the successor generations see it as 'too old'). > I started to use it 28 years ago (UCI Lisp on a DEC10) and never crossed > over it in my professional work except twice I started with Portable Standard LISP (on 32016 and later on the first generation ARM) in 1984 and went onto InterLISP-D on Xerox Dandelion (1108) and Daybreak (1186) before the ubiquitous but unlovely Common LISP took over. I still think PSL (which had some faults) was the best LISP I've used from the programmers point of view - elegant, orthogonal, simple to use and simple to build things in (as an aside both PSL and InterLISP were designed for in-core development and the use of structure editors, both of which I see as very important to ease and speed of development). > For a language that's been around for 50 years, it's at least annoying > if not strange given the power of the language. Could not agree more. > Certainly, having "t" to represent the truth value instead of "true", > using defun instead of defn or making an indigestion of parenthesis > are not essential LISP features. I mostly agree with you about the names of functions. Willfully changing things to make life difficult for people seems perverse, but at the same time 't', 'car', 'cdr' and so on are historical accidents. However, you're dead wrong about Lots of Irritating Stupid Parentheses. They are the heart of the language: the fact that it does not need any irregular syntax, because everything is regular. This makes learning - after the initial 'where am I what the f*** is this' phase - very simple and quick. Obviously, structure editors help... which is why Common LISP makes them so bloody awkward to implement (though Harlequin managed). > Compromises at the syntax level are very small concessions to get LISP > endorsed by a majority in the software community. People have been saying that for fifty years, and those people have been this: wrong. The SExpr notation was not LISP's original syntax - it was adopted in preference to infix syntax because it works better. InterLISP had an alternative 'conventional' syntax which looked like an Algol family language - it was used so rarely I've forgotten what it was called. Dylan was another LISP which used an Algol-like syntax in an attempt to gain popularity. Where is Dylan now? And these are only the best known of dozens - they've all failed, been lost in the dustbins of history.. Arc is also following this path. I am convinced it is a mistake. Of course syntax is a sprinkling of sugar on the top of a language; of course the same underlying semantics can be expressed in many different syntaxes, and it is the semantics that matter. But SExprs are the second most successful programming syntax after the Algol family; and, as compared to Algol-derived languages (BCPL, Pascal, C, Java, C#) the very regularity of SExprs and their lack of special cases makes LISP relatively easy to learn. > The post fix notation is already a challenge (look back at people using > HP calculators in the 70s/80s), so lets make things a bit easier for > the non LISP programmer used to left-right assignments... > Clojure is not a second citizen LISP because it implements a simplified > syntax. But that is precisely my point. The syntax isn't simplified: it has special cases /added/. > You may need to start from a blank sheet if your Common Lisp knowledge > interferes with your learning curve :))) > Get Stuart's bookhttp://pragprog.com/titles/shcloj/programming-clojure > and start from there. > This should give you a clear vision of what Clojure is and is not. I don't want to preserve Common LISP, heaven knows - Common LISP is a perversely bad LISP variant. I was on the BSI LISP standardisation committee at the time that Common LISP was going through and I was one of several people who voted against, for a whole slew of reasons. There is no reason to slavishly follow Common LISP. > It's time for LISP to get a significant share of commercial success > stories and the only way is to add some sex appeal to it to > attract the masses. Considering that the software industry stagnates > since the 1980s, it's a welcomed change. Making a LISP which interoperates well with (and can leverage the libraries of) Java or .Net is a big win. Some of the other stuff in Clojure looks extremely interesting - I'm looking at concurrency in particular. These are 'sexy' features. Syntax changes are not. Any SExpr-base syntax looks initially foreign to someone brought up with Algol-family languages. I've no objection to sprinkling syntactic sugar in places which don't matter, but making breaking changes to well known and well understood language features seems to me a bad thing. > I think that Clojure's main audience are these people drowning in this > ocean of java code, not the LISP advocates :))) Very probably true. I'm currently evaluating technologies for a new project which is going to need to do a lot of fairly sophisticated inference in the back end, and have a rich 3d graphical user interface on the front end - and needs to be fairly platform agnostic. The front end solution boils down to (probably) Java or Python; the back end really lends itself to LISP. So Clojure is an obvious possibility for me; but I'm probably not the core target audience of Clojure, and if I eventually choose to use JScheme or ABCL it's probably not much skin off Clojure's nose. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
