Live data from Hacker News

Not Lisp again (2009)

funcall.blogspot.com

161–170 of 276 posts

Re: Not Lisp again (2009)

#161
post #141
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…

I think Erik Naggum was a bit imperialistic in wanting 'Lisp' to mean Common Lisp. One nice thing Clojure did was to revitalize the Lisp-as-language-family meme.

Re: Not Lisp again (2009)

#162
post #140

Earlier quoted context omitted.

"SICP uses Scheme, which is not Lisp." --- is that a "no true Scotsman" argument or do you just mean "Scheme is not Common Lisp"?

I mean Scheme is not Common Lisp, and Common Lisp is Lisp. Both are "a Lisp" (as is Clojure), or perhaps "a dialect of Lisp", but it's questionable if that really means anything beyond s-exps and macros.

So when somebody says "I am going to write some Lisp now", in your mind they are always going to write Common Lisp?

Re: Not Lisp again (2009)

#163

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…

To me the hard part about lisp is that every programmer that uses lisp tailors it so to their own taste that it can become quite hard to read the 'top level' of a lisp program without first having gone through all the lower layers. It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

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

Re: Not Lisp again (2009)

#164
post #75
post #45

Earlier quoted context omitted.

> I think you should really be pushing more for SML or Haskell or something like that. There are two clues in this sentence (mentioning SML and not OCAML, "something like that") that suggest you do not regularly program in a "something like that" language. I wrote my first Haskell program over a decade ago. I find Haskell very hard to read. The grammar is very complicated[1] and is actually context-sensitive[2]. [1]…

I do like OCaml, but have never had the opportunity to write more than a few toy programs for fun. I put SML in there just to be like "and other ML-family functional programming languages." Haskell is complicated, but some complication is needed and that's more of a learning-curve problem. If humans were capable of simple, we'd all be typing 1s and 0s. We do better with grouping, context, similar things being similar…

> Haskell is complicated, but some complication is needed and that's more of a learning-curve problem.

That is a junk argument. No one needs context-sensitive grammars. I think designing a language that cannot be parsed with an LL(1) or LALR parser is just dumb. It guarantees that your compiler will be slow right from the start. In addition that applies to all the tooling - syntax highlighting and navigation in the editor, linters, pretty-printers, etc. And in practice the tooling is not just slow but also has a ton of bugs around corner cases.

Re: Not Lisp again (2009)

#165
post #141

Earlier quoted context omitted.

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…

I think Erik Naggum was a bit imperialistic in wanting 'Lisp' to mean Common Lisp. One nice thing Clojure did was to revitalize the Lisp-as-language-family meme.

[deleted]

Re: Not Lisp again (2009)

#166
post #49
post #32

Earlier quoted context omitted.

Better example would be symbolic differentiation[1][2] which requires more quirks even in modern languages[3][4] [1] https://mitpress.mit.edu/sicp/full-text/sicp/book/node39.htm... [2] https://github.com/clojure-numerics/expresso [3] http://docs.sympy.org/latest/tutorial/intro.html#a-more-inte... [4] https://github.com/yuemingl/SymJava#examples

Note that the simplistic approach doesn't scale well, as terms tend to "explode" in size and hence computation time. There is a whole sub field of mathematics / computer science called "algorithmic differentiation", also known as "automatic differentiation". The goal is to take an existing computer program and transform it into another computer program that calculates the derivatice just as efficiently (up to a const…

What do you mean by reverse mode? I assumed integration, but that doesn't seem to be what you're talking about.

Re: Not Lisp again (2009)

#167
post #140

Earlier quoted context omitted.

"SICP uses Scheme, which is not Lisp." --- is that a "no true Scotsman" argument or do you just mean "Scheme is not Common Lisp"?

I mean Scheme is not Common Lisp, and Common Lisp is Lisp. Both are "a Lisp" (as is Clojure), or perhaps "a dialect of Lisp", but it's questionable if that really means anything beyond s-exps and macros.

Why does Common Lisp get the distinction of being the "true Lisp" and not Scheme? Scheme precedes Common Lisp by almost a decade

Re: Not Lisp again (2009)

#168
post #141

Earlier quoted context omitted.

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…

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 calling all these C-like languages ALGOLs. What do you gain by trying to separate from other ALGOLs?

Or less extremely, why don't we consider Python and Ruby to be the same family, or Java and C#? Those pairs are arguably more similar than the pair of Common Lisp and Scheme.

Re: Not Lisp again (2009)

#169
post #39

I'm having trouble understanding why the derivative example was so impressive to the author. Can someone explain? It seems trivial to do in any language where functions are first class citizens.

I was hoping for a symbolic derivation.

Did that for simple polynomials back in the early 80s. The approximation of an arbitrary function is more interesting to me, precisely because I didn't do that, I guess :-)

Cal State (Stan) only had (some) Lisp available because I was interested in AI. We only had shallow treatment of it (GC scoffed at...), and I've only been discovering deeper features second hand by reading about it the last 10 or 15 years.

Re: Not Lisp again (2009)

#170
post #140

Earlier quoted context omitted.

I mean Scheme is not Common Lisp, and Common Lisp is Lisp. Both are "a Lisp" (as is Clojure), or perhaps "a dialect of Lisp", but it's questionable if that really means anything beyond s-exps and macros.

Why does Common Lisp get the distinction of being the "true Lisp" and not Scheme? Scheme precedes Common Lisp by almost a decade

Naggum has a pretty good answer for that, linked in the other comment branch: http://www.xach.com/naggum/articles/3224964049435643@naggum.... You could also argue based on things like Common Lisp can run LISP code from 1960 with a very small driver, or the general history of code porting and sharing, as done here: https://news.ycombinator.com/item?id=9387131#9404543
Post reply on HN