Earlier quoted context omitted.
>for the vast majority of programmers, Lisp syntax is not easy I suggest that learning Lisp's syntax is easier than learning C-like syntax. There is learning involved, however, and that undoubtedly keeps people from lisp. But s-expressions are the secret sauce; there is no modern lisp without them. >installation and package management This is basically a solved problem at this point. Clojure has both Lein and Boot to…
Lisp's syntax is indeed easier to learn, but the vast majority of programmers have made it clear that they DO NOT want to READ code in S-expression format. And you typically have to read more code than you write. I created 3 layered notations to keep Lisp's capabilities (including macros and homoiconicity) while making it easier for normal programmers to read. Instead of "getting rid" of S-expressions, I think adding…
Common Lisp homepage
231–240 of 313 posts
Re: Common Lisp homepage
#232Earlier quoted context omitted.
{by whom} Not by me. I'm a skilled Lisp programmer, yet Scheme isn't usable to me a the rudimentary coding level using the core language. There are stumbling blocks at every turn against straightforward Lisp coding. How can it be a Lisp? I can't even rely on Scheme to evaluate the function arguments left to right. Many forms have an "undefined" return value; in Lisp, everything returns a defined value, as a fundament…
> "Lisp" has to do with the little design details, not superficial resemblance. Would you consider LISP 1.5, MacLISP, InterLISP, etc. to be Lisps? They differ on different design details than Scheme does, but they differ significantly. Related: does Lisp these days or in your community just mean Common Lisp?
I would count Emacs Lisp, ISLisp, and some similar languages as mainline Lisps. Scheme is now called Scheme. Racket was renamed from DrScheme (IIRC), to avoid being directly associated with Scheme - since it is now its own language.
Re: Common Lisp homepage
#233For those who want to use Lisp on the JVM, there is ABCL: https://abcl.org ABCL was originally used to write and extend an editor called J - but then morphed into a full implementation of Common Lisp. One can also develop with SBCL - since it has a great compiler - and then move the code to ABCL.
There's also clojure on the JVM.
Re: Common Lisp homepage
#234Earlier quoted context omitted.
>3.) the lisp ecosystem is fractured into too many lisps like SBCL, Clojure, Racket, Allegro, Franz, Picolisp, ABCL, Shen...etc, so some confusion amongst those that are new You are mixing things into that list. Common Lisp, Racket, Clojure, and Shen are different languages, serving different purposes, etc. "Franz", "Allegro", "ABCL", "SBCL" are implementations of Common Lisp, exactly the same language. ALGOL-family…
You quoted two companies using Lisp when there are millions of Java devs. That's like a boxer with a record of 1-500. I love Lisp, but c'mon...I guarantee it has far more hobby users than professional users. ABCL, FRANZ, ALLEGRO, SBCL, CLISP, GNU CL, Clozure might all be common lisp, but they are different implementations with different tools that will confuse a new person and several cost money. Practical Common Lis…
That's better than having different languages with different tools: Python, Ruby, Perl, ... share nothing - though they are in a similar coding domain.
Re: Common Lisp homepage
#235(mapcar #'string-downcase (list "Hello" "world!")) This is a great example of why I don't want to use Common Lisp. Compare with Python: [word.lower() for word in ("Hello", "world!")] Beating Node and Ruby in terms of speed is also a big non-argument, with so many attractive programming languages to choose from that are both fast and good looking.
A little more general:
(map 'list #'string-downcase (list "Hello" "world!"))Re: Common Lisp homepage
#236Earlier quoted context omitted.
>3.) the lisp ecosystem is fractured into too many lisps like SBCL, Clojure, Racket, Allegro, Franz, Picolisp, ABCL, Shen...etc, so some confusion amongst those that are new You are mixing things into that list. Common Lisp, Racket, Clojure, and Shen are different languages, serving different purposes, etc. "Franz", "Allegro", "ABCL", "SBCL" are implementations of Common Lisp, exactly the same language. ALGOL-family…
You quoted two companies using Lisp when there are millions of Java devs. That's like a boxer with a record of 1-500. I love Lisp, but c'mon...I guarantee it has far more hobby users than professional users. ABCL, FRANZ, ALLEGRO, SBCL, CLISP, GNU CL, Clozure might all be common lisp, but they are different implementations with different tools that will confuse a new person and several cost money. Practical Common Lis…
Just they have different IDE's and REPLs.
That's like saying Visual C will confuse someone used to Turbo C. So C is bad.
Re: Common Lisp homepage
#237Earlier quoted context omitted.
> "Lisp" has to do with the little design details, not superficial resemblance. Would you consider LISP 1.5, MacLISP, InterLISP, etc. to be Lisps? They differ on different design details than Scheme does, but they differ significantly. Related: does Lisp these days or in your community just mean Common Lisp?
Common Lisp mostly superseded Lisp 1.5 and Maclisp. Interlisp went away - Xerox included Common Lisp into Interlisp-D and later sold the product to a tiny vendor, renaming the product to Medley. Most Interlisp users were switching to Common Lisp - including Xerox. Xerox even was a driving force behind the Common Lisp Object System (CLOS) and its Meta-Object Protocol. Xerox paid for much of the research that went into…
See: a laudably reasonable behavior.
Re: Common Lisp homepage
#238Earlier quoted context omitted.
Common Lisp has: generic functions, homo-iconic macros written in Common Lisp, reflection, multiple dispatch, closures, optional typing, correct implementation of lexical scope, dynamically scoped variables, a metaobject protocol, conditions & restarts, and a compiler that is available for customization. One or a few of these have made it into other languages in some form or another - but not all together. Common Lis…
At least optional typing and macros are not considered to be universal benefits for programming. Having a ton of features has been proven in many occasions to be counterproductive. Paradox of choice, higher learning curve, etc.
I don't agree that Common Lisp has a higher learning curve than other languages. To become operational - Common Lisp is no more difficult to learn than other languages. Bind variables, conditionals, loops and a little arithmetic and you can start doing some damage. You can write procedural code, functional code, object oriented code - whatever your problem needs.
It's that Common Lisp has a LOT more "up" than other languages. It keeps going up and up as you learn about macros and CLOS and multiple dispatch and restarts and upwards. It's really neat discovering all the things that you realize you were missing from other languages - some things that they add over time with ever more complex and arbitrary syntax.
When you get tired of writing "for" loops and agonizing how to manage memory for the next fancy data structure you want to implement - dive into it - it's great. Common Lisp will still be there.
Re: Common Lisp homepage
#239Earlier quoted context omitted.
At least optional typing and macros are not considered to be universal benefits for programming. Having a ton of features has been proven in many occasions to be counterproductive. Paradox of choice, higher learning curve, etc.
As a Professor of Chemistry - I'm all about higher learning and I love curves (non-linear functions that is). I don't agree that Common Lisp has a higher learning curve than other languages. To become operational - Common Lisp is no more difficult to learn than other languages. Bind variables, conditionals, loops and a little arithmetic and you can start doing some damage. You can write procedural code, functional co…
Re: Common Lisp homepage
#240This is a very nice web site describing a programming language with unparalleled expressiveness, power and permanence. I am heavily invested in Common Lisp. We are developing a programming environment for designing new materials and molecules called Cando ( https://github.com/drmeister/cando ) using Common Lisp as a scripting language. Cando is running on Clasp ( https://github.com/clasp-developers/clasp ), a new Com…
> how I don't have to worry about it fading like the next programming fad. I'm not sure I understand this bit. What other programming language has "faded" and how has it "faded"? At least since the more mature age of software, which I'd say started around '95 or so (so 20+ years).
C++ template programming necessarily followed a very different style than it does since variadic template were introduced with C++11. There were books written before C++11 wherein much of them was obsoleted by variadic templates. You do not want to let students get hold of those books and think the old way was the way things have to be done. Compare how boost::python was (is? I haven't dug into it recently) written compared to pybind11 - night and day differences in readability thanks to variadic templates. That's not a dig at boost::python - it was written with the C++ they had back then and it had to use Lisp-like list comprehension with tedious replicated boilerplate code to unpack argument lists.
Then there are raw pointers in C++ - we aren't supposed to use raw pointers anymore. We are supposed to use references and std::unique_ptr and std::shared_ptr and this thing called "move semantics". That stuff sucks for directed graphs and so I switched to compacting, tracing garbage collection for Cando.
C++ is being developed in a way that it retains backward compatibility with existing code - thank goodness for that! But there are styles of programming even for something as staid and venerable as C++ that, while supported, should pass silently into the long, dark night.
Then you have a language like Python that made sensible but breaking changes between versions 2.x and 3.x. Wow - look at the problems that is still causing. I love Python but I won't do anything with it that I can't rip out root and branch with more than a few weeks work. I say that even though Clasp's build system is completely implemented using the very excellent Python based build system 'waf'.
Then you have Javascript - it seems to change every time I blink. That doesn't mean I will stop using it for our web based Jupyter notebook user interface. Javascript is the only game in that town. I just close my eyes and hold on tight and try not to scream.
Common Lisp isn't like any of those, it grew out of a lot of very careful thinking and was specified around 1984 darn near perfect. There are some warts (logical pathnames - I'm looking at you) but even its warts are better thought out than some other languages features. Better implementations and more and better libraries come along - but the language has the same expressiveness, power and permanence it has always had.