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

211–220 of 276 posts

Re: Not Lisp again (2009)

#211

Post by Volt »

Frondo wrote: post #195
brianberns wrote: post #152

Earlier quoted context omitted.

>> 1 - All those parenthesis. (Still a top objection) > If you actually count parens fairly you will find that Lisp has no more than any other language Bull. For example, compare the Lisp factorial function from the article: (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))))) with the corresponding F# implementation: let rec fact x = if x = 0 then 1 else x * fact (x - 1) That's 7 vs. 1 pair of parens. Also, the p…

Yeah, you know what else I'm realizing? All the different kinds of punctuation let my eyes skim over different parts of code so easily, and lisp doesn't give me that. You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? That's how I read code, too, I'm realizing. When I see the parentheses in C#, my brain just goes "oh that's a method/f…

>You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency?

As difficult as it is to imagine, you can indeed achieve fluency in reading Lisp code. Like with everything else, it takes time and practice.

Re: Not Lisp again (2009)

#212

Post by Volt »

int_19h wrote: post #188
AceJohnny2 wrote: post #163

Earlier quoted context omitted.

Sounds like a common objection to C++, where the language is so large that every team chooses its own subset of features they'll use, and ignore the rest :)

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

Re: Not Lisp again (2009)

#213

Post by Volt »

Jach wrote: post #203
openasocket wrote: post #190

Earlier quoted context omitted.

I read that answer, I didn't find it helpful on two points. 1. There's this really nice analogy about German and English languages, but it doesn't have any specifics. In particular, the crux of his entire argument is in this statement > The two languages and their attendant communities have drifted so far apart that there is nothing of value in their intersection. Which he simply states as fact without any sort of fo…

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…

>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?

Re: Not Lisp again (2009)

#214

Post by Volt »

Jach wrote: post #141
icc97 wrote: post #133

Earlier quoted context omitted.

> SICP uses Scheme, which is not Lisp. Wikipedia [0]: > Scheme is a functional programming language and one of the two main dialects of the programming language Lisp. [0]: https://en.wikipedia.org/wiki/Scheme_%28programming_language...

Keyword: dialect . But Erik Naggum, 2002 [0]: > The "Lisp" Scheme is a dialect of is no longer the current meaning of "Lisp". It is somewhat like calling English a dialect of German because of ancient history that has since between invalidated by each of their separate evolution, Fahrvergnügen, Weltanschauung, Kindergarten, and Pennsylvania to the contrary notwithstanding. There is also a very limited value in talkin…

What is the other dialect?

Re: Not Lisp again (2009)

#215

Post by openasocket »

Jach wrote: post #203
openasocket wrote: post #190

Earlier quoted context omitted.

I read that answer, I didn't find it helpful on two points. 1. There's this really nice analogy about German and English languages, but it doesn't have any specifics. In particular, the crux of his entire argument is in this statement > The two languages and their attendant communities have drifted so far apart that there is nothing of value in their intersection. Which he simply states as fact without any sort of fo…

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 creating Common Lisp doesn't necessarily mean that is the case.

And Common Lisp isn't the only language with a standard: Scheme had an IEEE standard less than a year after ANSI Common Lisp, and has several RnRS updates since then.

Long story short, I don't think any language should be considered the "true Lisp". Maybe the original Lisp, but even then only as a technicality. And trying to declare a language as the "true Lisp" comes off as a little insulting to related languages and a little bit arrogant. It implies, to a certain degree, that you look down on other languages as lesser, inferior, failed attempts to reach the true zen of Lisp. I'm sure you didn't mean it that way, but as a fan of Scheme (and Common Lisp too!) it reads that way.

Re: Not Lisp again (2009)

#216

Post by openasocket »

Volt wrote: post #213
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…

>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?

Re: Not Lisp again (2009)

#217

Post by jhbadger »

Jach wrote: post #168
gizmo385 wrote: post #157

Earlier quoted context omitted.

I feel like there should be a "No True LISP" fallacy in CS... It expresses pretty much all of the core principals of a LISP. If it looks like a LISP, thinks like a LISP, behaves like a LISP; then do you really gain anything by trying to separate from other LISPs?

Is Python a LISP? Is JavaScript a LISP? Is Java a LISP? What do you mean by LISP, by its core principles? What does a different set of core principles look like that lends itself to a different family? I threw in my vague classification above: sexps and macros. But you can have macros without sexps, and sexps without macros (lots of "toy lisp interpreters" do that), are they LISPs? Lastly one wonders why we don't go…

Is Picolisp a Lisp? Is Newlisp a Lisp? Is Emacs Lisp a Lisp? Maybe it's because I first learned programming in the 1980s in BASIC, but I'm pretty used to the idea of programming languages having dialects. Apple ][s, Commodore 64s, and Atari 800s all supposedly were programmable in BASIC, but it didn't mean you could take a program written on one and expect to run it without changes on another.

Re: Not Lisp again (2009)

#218

Post by spacemanmatt »

Frondo wrote: post #195
brianberns wrote: post #152

Earlier quoted context omitted.

>> 1 - All those parenthesis. (Still a top objection) > If you actually count parens fairly you will find that Lisp has no more than any other language Bull. For example, compare the Lisp factorial function from the article: (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))))) with the corresponding F# implementation: let rec fact x = if x = 0 then 1 else x * fact (x - 1) That's 7 vs. 1 pair of parens. Also, the p…

Yeah, you know what else I'm realizing? All the different kinds of punctuation let my eyes skim over different parts of code so easily, and lisp doesn't give me that. You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? That's how I read code, too, I'm realizing. When I see the parentheses in C#, my brain just goes "oh that's a method/f…

You get used to reading lisp, the same as you get used to reading all that boilerplate syntax.

Re: Not Lisp again (2009)

#219

Post by lisper »

brianberns wrote: post #210
lisper wrote: post #206

Earlier quoted context omitted.

F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable. But compare to, say, C where no one complains about the parens: int fact(int n) { if (n==0) { return 1 } else { return n*fact(n-1); } } That's six pairs of parens. The only reason it's not more is because some function calls in C are disgu…

Only if you assume that curly braces function as parens in C, which isn't true.

It's not an assumption, it's a fact. Curly braces serve the same function in C as (some of the) parens do in Lisp.

Re: Not Lisp again (2009)

#220

Post by Jach »

Volt wrote: post #213
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…

>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 that if you drop "Lisp" in a conversation you really mean Lisp 1.5. (Maybe if you write it as LISP...) It's either going to mean Common Lisp, or maybe a reference to the vague Lisp Family. I don't think Lisp will ever be synonymous with "Scheme".

Maybe you'd appreciate some Lisp history, to also answer your question about "what other dialect[s]"?

http://www.paulgraham.com/thist.html

http://lispm.de/30ycltl

Post reply on HN