Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Lisp homepage

lisp-lang.org

Post reply on HN
Print view View original

141–150 of 313 posts

Re: Common Lisp homepage

#141

Post by Jach »

taeric wrote: post #125
BeetleB wrote: post #97

Earlier quoted context omitted.

>Lisp related books are among the best in CS. SICP, LoL, etc. are timeless. Lisp books also tend to have the characteristic where you have to find the "right" compiler for the examples to work. I've yet to pick up a book where all the examples "just work".

Land of Lisp worked well for me. Can't remember any major issues. (That said, I think I also used racket for most of the work, so I had to change some things consciously.) Though, this is a bit of a hard problem for authors. Most code that can fit as snippets or short examples does not have what any code in real projects would have. To that end, the code is literally made mainly for you to try and simulate in your he…

I wonder if LoL was not referring instead to Let Over Lambda which I'd call more timeless... For Land of Lisp there is some implementation specific code the author uses, but he points that out, points out that there are libraries that make a de facto standard for the behavior, but didn't want to introduce quicklisp. (It's a fun book but not the best if your goal is getting productive in a work environment fast, in which case learning about asdf and quicklisp early on is crucial...)

Lisp books in my experience have been the most reliable for running old code. I can take Lisp code from 1960 and almost entirely unmodified run it in a modern Common Lisp implementation because there's a direct line of heritage. If a book from the 90s says it supports Common Lisp, well hey, barring errata the code still works every time...

Re: Common Lisp homepage

#142

Post by lispm »

pjmlp wrote: post #128
rjsw wrote: post #68

Earlier quoted context omitted.

Lisp ran on the first UNIX workstations too, Franz Lisp ran fine on even the earliest Sun machines. Lucid pivoted from Lisp on UNIX to C++ on UNIX, they didn't have anything to do with Lisp Machines.

Correct, but it wasn't part of the platform tooling, requiring an additional expense, with a price tag which on the 80's computing world very few companies were willing to shell out. Yep, I always get that part of Lucid's history wrong.

Actually Lisp systems were no more expensive than other advanced language implementations. But one needed a bunch of expensive RAM.

At that time there were already free implementations of Common Lisp for Unix: AKCL (later GCL), CMUCL, CLISP, XLISP, ... IDE for those were usualy GNU Emacs or Xemacs with ILISP.

Windows had less choice for free implementations, but one used the commercial implementations anyway and some were not that expensive.

On the Mac everyone used Macintosh Common Lisp - which at some point was owned and sold by Apple itself - not very expensive.

Re: Common Lisp homepage

#143

Post by giancarlostoro »

greymeister wrote: post #139

The giant header that fills the first page, forcing a scroll into content, is right up there with unskippable flash intro videos from 10 years ago.

I'm not sure why this is even a thing, even on news articles with huge images, it's just POINTLESS to me. "Oh I guess you don't want me to read this article" click

Re: Common Lisp homepage

#144

Post by oblio »

drmeister wrote: post #110
oblio wrote: post #81

Earlier quoted context omitted.

> 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).

I say this with a perspective of watching it happen over forty years. I'll get all kinds of heck if I start saying this or that language has faded. But many languages have changed over time, sometimes in breaking ways, as their developers work to make them more expressive and add features. Code that is written one year often doesn't work a few years later - that's a kind of fading as specific reference implementation…

Thing is, except for CS theory evolving, the programming language environment from 30 years ago is in my opinion irrelevant from a maturity perspective. The number of practitioners was probably 1 million or so worldwide, now there’s probably 20-40+ million programmers worldwide. We didn’t have widespread internet access, barely a handful of Open Source communities, compilers were generally commercial and extremely expensive, companies behind technologies were extremely volatile, etc.

While that made for very nice war stories, it also meant that you’d have the “ship” sinking under you completely. Now a tech still stays around to some degree.

A C developer from 1990 could still be a C dev in 2018. A Java dev from 1998 could still be a C dev in 2018. And a programmer in your average mainstream language in 2018 could reasonably expect to be working in the same language in 2018. Especially if that language has enterprise traction (Cobol, Java, C#, Javascript, SQL, etc.).

Also, languages are a lot more similar to each other than they used to be, in terms of expressiveness and power. Lisp was a “lightsaber” to the “stones” of the 80’s, now it’s at most a slightly more powerful “machine-gun”, at best.

And regarding language evolution itself, everything evolves. Or did Common Lisp programmers generally write unit tests, have integration test harnesses, use package repos, etc. back in 1995? I somehow doubt that :)

Re: Common Lisp homepage

#145

Post by giancarlostoro »

nerpderp83 wrote: post #115

This is not good , the info density for the screen area is too low. This could have been one maybe two screens worth. Is this the credits to Friends? Am I consuming Lisp Content while chillin in my penthouse on my 20k couch using a gold plated IPad X Tablet? Millennials are Killing Common Lisp. one page, https://www.rust-lang.org/en-US/

The Racket-Lang site almost had it perfect:

http://racket-lang.org/

The stuff above the language description should be shoved to the bottom (excluding obviously the top menu) and it would be perfect. I miss their old site because it was obvious and to the point and had examples right away.

Re: Common Lisp homepage

#146

Post by lisper »

s_kilk wrote: post #18
susam wrote: post #7

Lisp is quite popular at my current workplace. A few popular open source projects published by our organization have been written in Clojure (a dialect of Lisp that runs on JVM and CLR). A few domain specific languages used internally in our organization are also inspired by Lisp. On a more personal front, I find Lisp to be simple, elegant, and expressive. I use Common Lisp (SBCL) for personal use. Working with Lisp…

> I sometimes wonder why Lisp has not been more popular in the technology industry. Is it the lack of sufficient marketing? Is it the lack of an extensive library ecosystem? Data-point of one here, but I was instantly turned off by the conflation of the empty-list, nil, and boolean-false. I could tell instantly that I'd have a hard time interfacing with data from other real-world systems, so I decided to skip CL and…

You can easily change that behavior if you really want to.

(in-package :my-package)

(shadow 'if)

(defmacro if (condition then else) `(cl:if (true? ,condition) ,then ,else))

(defgeneric true? (thing) t)

Defining appropriate defmethods to make things work the way you want is left as an exercise.

Re: Common Lisp homepage

#147

Post by segmondy »

vesak wrote: post #84
oblio wrote: post #81

Earlier quoted context omitted.

> 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).

Pascal, perl, ASP, every ML, Fortran, Cobol, Eiffel, Modula, all "4GL" languages.

Perl, ML, Fortran, Cobol has not faded. You might not like them, you might not use them. But there are tons of them out there and being used in the real world and production systems.

Re: Common Lisp homepage

#148

Post by kazinator »

s_kilk wrote: post #18
susam wrote: post #7

Lisp is quite popular at my current workplace. A few popular open source projects published by our organization have been written in Clojure (a dialect of Lisp that runs on JVM and CLR). A few domain specific languages used internally in our organization are also inspired by Lisp. On a more personal front, I find Lisp to be simple, elegant, and expressive. I use Common Lisp (SBCL) for personal use. Working with Lisp…

> I sometimes wonder why Lisp has not been more popular in the technology industry. Is it the lack of sufficient marketing? Is it the lack of an extensive library ecosystem? Data-point of one here, but I was instantly turned off by the conflation of the empty-list, nil, and boolean-false. I could tell instantly that I'd have a hard time interfacing with data from other real-world systems, so I decided to skip CL and…

Your guess was wrong; there is no such hard time. There is no difficulty in precisely mapping data from the "real world" onto Lisp data structures, in both directions.

If it doesn't have nil that is also false and the empty list, it is not a Lisp.

The conflation is a stroke of genius. I was immediately attracted to Lisp because of its clever handling of lists and booleans. Also how nil is a symbol, but () means the same thing as an alternative spelling.

People who wake these things out are imbeciles who are mutilating their language to the point it shouldn't be called Lisp.

How nil works in Lisp has a tremendous virtue: it blows away a lot of useless verbiage from code that manipulates code.

Ancient Lisp in the 1960's didn't allow car and cdr on the empty list nil. The Interlisp people realized that it was an inconvenience to always have to test consp before using car or cdr so they turned the functions polymorphic, allowing (car nil) -> nil, and (cdr nil) -> nil. According to the HOPL History of Lisp paper, the MacLisp and Interlisp people held a conference. They didn't agree on some things, but MacLisp adopted (car nil) -> nil and (cdr nil) -> nil from Interlisp. It's a compelling idea; taking it out of a supposed Lisp dialect is a counterproductive regression.

Re: Common Lisp homepage

#149

Post by kazinator »

lisper wrote: post #146
s_kilk wrote: post #18

Earlier quoted context omitted.

> I sometimes wonder why Lisp has not been more popular in the technology industry. Is it the lack of sufficient marketing? Is it the lack of an extensive library ecosystem? Data-point of one here, but I was instantly turned off by the conflation of the empty-list, nil, and boolean-false. I could tell instantly that I'd have a hard time interfacing with data from other real-world systems, so I decided to skip CL and…

You can easily change that behavior if you really want to. (in-package :my-package) (shadow 'if) (defmacro if (condition then else) `(cl:if (true? ,condition) ,then ,else)) (defgeneric true? (thing) t) Defining appropriate defmethods to make things work the way you want is left as an exercise.

However, wanting to is rather a problem for the psychiatrist's couch.

Re: Common Lisp homepage

#150

Post by stassats »

kbp wrote: post #108
stassats wrote: post #106

Earlier quoted context omitted.

It needs (optimize safety debug) and the function needs to be compiled (interpreted code doesn't perform any optimizations based on the types).

Sure, but the point is that that exact same code will throw a type error in SBCL. It at least complicates what you need to do before you can say "what implementation doesn't behave like that?".

But what is the point, really? SBCL will disable type checks with safety=0, LW will enable with safety=3, debug=3. Is the point "read your documentation before relying on things"?

Or is the OP's point that SBCL shouldn't exist because it's "poisoning" and "a bad thing"?

That's the problem with such FUD, can't ignore it or somebody might actually believe it, can't just say "nonsense" since that's not convincing.

Post reply on HN