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

Not Lisp again (2009)

funcall.blogspot.com

Post reply on HN
Print view View original

221–230 of 276 posts

Re: Not Lisp again (2009)

#221

Post by Jach »

openasocket wrote: post #215
Jach wrote: post #203

Earlier quoted context omitted.

Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Maybe Racket (or Chicken or Chez or Guile or...) has all of these things, Racket is pretty awesome, but those things aren't standardized, whereas I can get those things in Lisp regardless of if I use SBCL/Clozure/clisp/etc. Maybe it's cl…

I agree they are pretty different languages, and you give some solid points as to why: CLOS, dynamic scoping, multi-methods, etc. My point was your link mentioned exactly none of those examples, in fact gave no examples at all, and so wasn't very convincing. The second point that the argument that Common Lisp is the "true Lisp" because that's why it was made is a faulty syllogism. Just because that was their goal of…

Maybe there's no platonic ideal Lisp, and that's the problem, since the thing that makes programmers feel good is some vague sense that there is such an ideal. A sort of god. ;) On the level of communication and definitions though, it seems totally reasonable to me that if your goal as a community of all sorts of versions/dialects of Lisp is to unify into one standard, then you get to call your new unification the Lisp.

I see your point about arrogance, though I think the insulting tone could be turned around easily -- you have these Lisp-like languages that don't even have Lisp in their name nor a lot of Lisp's crucial features trying to appropriate/claim an inheritance on all the hard work and glory and name recognition that went into Common Lisp and its predecessors. Let them have their name. I'm a pretty big fan of Clojure (and do like what Racket is doing when I read up about it) but imagine trying to sell Clojure to an old Lisp hand with "it's like Lisp" and watching them type (inc "a") vs (1+ "a"). https://pastebin.com/kBfNvxei vs https://pastebin.com/hPB2cy1X and there's no contest. (You might win them over with further persistence but they'll probably be wondering where all their favorite parts about Lisp are in this so-called Lisp-like.)

Re: Not Lisp again (2009)

#222

Post by Volt »

openasocket wrote: post #216
Volt wrote: post #213

Earlier quoted context omitted.

>Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?

He was just giving those as examples of ways in which Scheme and Common Lisp differ. Which is a fair point. Of course it does raise the question: are those features essential attributes of the Platonic ideal that is True Lisp, or simply nice addons Common Lisp provides?

Yeah, that's what I was getting at.

Re: Not Lisp again (2009)

#223

Post by Volt »

Jach wrote: post #220
Volt wrote: post #213

Earlier quoted context omitted.

>Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?

How I see it, Lisp 1.5 was Lisp, but as time went on and many 'versions' of Lisp for different systems with different capabilities came into being, there was no longer really a singular Lisp. Then there was a great unification that spit out Common Lisp, and that became Lisp. So if Lisp 1.5 was released today as something new, it wouldn't be Lisp, but merely another Lisp-like. It's too different. No one today thinks t…

I do know some of the history. I was just asking those questions as a challenge. Regarding the question of the other dialect, the parent used the term as a way of distancing Scheme from what I assume is the one true Lisp: Common Lisp. But the point the passage they had an issue with noted two dialects. The other, of course, being that one true Lisp.

The way I see it, the things that make Lisp "Lisp" are not exclusive to either one. One might say that the intersecting characteristics aren't interesting, but these characteristics are what Lisp is truly about.

SML and Caml are both ML. Haskell 98 and Glasgow Haskell are both Haskell. Dyalog APL and APL2 are both APL. And so on.

Re: Not Lisp again (2009)

#224

Post by int_19h »

Volt wrote: post #212
int_19h wrote: post #188

Earlier quoted context omitted.

That's much less of a problem, because if you know the whole thing, then any subset of it is also known. It only becomes a problem if you need to change the code, because then you have to be aware of the subset to restrict yourself to. C++ actually has a similar problem with developing idiosyncratic in-house solutions to common problems - it's not uncommon to find hand-rolled collections, reference-counting pointers…

I don't know anyone who claims to know the whole of C++.

Knowing the language itself is not that hard. It's big, but manageable. Obviously there will always be corner cases where you need your language lawyer hat (and the copy of the Standard), but those exist for pretty much any language.

The library is more complicated, especially once you get to iostreams and locales. But also less of an issue in this scenario.

Re: Not Lisp again (2009)

#225

Post by pjmlp »

SolarNet wrote: post #208
pjmlp wrote: post #178

Earlier quoted context omitted.

What does ML, initially developed for theorem proving, have to do with Lisp?

Because lisp is good at anything? But especially alternative evaluation systems (of which theorem proving is one). Because they took lisp and added types to it; via the ISWIM language document ("The Next 700 Programming Languages") which was based off of the original lisp. Because the lisp language family is a formulation of lambda calculus and has first class functions, unlike any other language family at the time,…

Can you point me to a good reference paper about this?

Re: Not Lisp again (2009)

#226

Post by grey-area »

oxryly1 wrote: post #153
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

Using Lisp (in the form of Racket) for many years in a production environment, I've observed: 1. People do complain about the parentheses but they generally get to work dealing with them right away. It's the loudest complaint, but it doesn't really even slow people down. 2. This is a similar complaint, and does scare people off from jumping in if they have a real choice. 3. Racket in particular solves this one to an…

The hesitation I'd have with Lisp(s) as an outsider, which ties in to number 3, is that the language itself is compact, elegant and extensible. It's the opposite problem to C++ (the language is too large) - the language is too small and it encourages you to build other languages inside it. So it'd be very hard to share code with others because as soon as you start building abstractions your language and worldview diverges from everyone else's version of lisp - to use a library you have to learn someone else's mini-language. Maybe this is an invented concern though, did you find integrating other libraries a problem?

Did you have any problems with development speed or performance in production or was that fine?

Re: Not Lisp again (2009)

#227

Post by golergka »

lmm wrote: post #74
golergka wrote: post #20

Earlier quoted context omitted.

Unreadable? Personally, I think that Lisp has the clearest possible syntax - because it basically doesn't have any. It's just straight ASTs - something that I have to visualize myself in other languages wich have more syntax sugar.

It makes e.g. arithmetic expressions look rather awkward.

That's if you choose to think abiut them as arithmetic expressions and not function applications. If you work with arithmetic expressions a lot, you should probably use appropriate domain language - in fact, you can build it in Lisp itself.

Re: Not Lisp again (2009)

#228

Post by Nanshan »

> An Introduction to Programming in Emacs Lisp > 1 List Processing > To the untutored eye, Lisp is a strange programming language. In Lisp code there are parentheses everywhere. Some people even claim that the name stands for "Lots of Isolated Silly Parentheses". But the claim is unwarranted.

Someone show code in other programming languages want to show Lisp's parentheses is silly or other languages more elegant.

BUT: I can't find any language can treat the code is data and the code is data AND: I can't find any except Lisp there is just one syntax ().

Re: Not Lisp again (2009)

#229

Post by DigitalJack »

grey-area wrote: post #226
oxryly1 wrote: post #153

Earlier quoted context omitted.

Using Lisp (in the form of Racket) for many years in a production environment, I've observed: 1. People do complain about the parentheses but they generally get to work dealing with them right away. It's the loudest complaint, but it doesn't really even slow people down. 2. This is a similar complaint, and does scare people off from jumping in if they have a real choice. 3. Racket in particular solves this one to an…

The hesitation I'd have with Lisp(s) as an outsider, which ties in to number 3, is that the language itself is compact, elegant and extensible. It's the opposite problem to C++ (the language is too large) - the language is too small and it encourages you to build other languages inside it. So it'd be very hard to share code with others because as soon as you start building abstractions your language and worldview div…

I think that objection is likely true of scheme. Scheme is like the Assembly language of lisps. To build it up to the level of usefulness requires a lot of wheel re-inventing, and those wheels are likely to be not quite standard.

Clojure and Common Lisp are larger languages and don't really suffer this problem.

Re: Not Lisp again (2009)

#230

Post by Singletoned »

Will_Parker wrote: post #53
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

7 - It's too easy to make a mess. And the mess made by brilliant people who are looking for any excuse to put higher order metaprogramming and functional concepts into production is considerable. 8 - It has consistently lost in the marketplace in the last 20 years. We had most top CS grads in North America groomed on SICP at one point in history. You'd think many of them would want to use Lisp in production. Many of…

I strongly suspect that it is possible for a language to be too powerful.

The more capacity a language has to let you do wonderful things, the more capacity it has to let you do truly awful things as well. ("With great power comes great responsibility" and all that).

Also, something about the expressivity of the code means that your code is wonderful, but other peoples code is potentially a nightmare.

Post reply on HN