Live data from Hacker News

A difference between Haskell and Common Lisp

chrisdone.com

91–100 of 203 posts

Re: A difference between Haskell and Common Lisp

#91
post #64

You have to be clear about which Lisp. Clojure and Scheme are Lisps, and their focus is very much towards simplicity and the use of combinators. The complex, do-it-all-in-one-huge macro is a Common Lispism, not a Lispism. Secondly, Clojure, like Haskell, is focused on sequence abstractions, not lists. Sequences can include collections, streams, observables, sockets and many other kinds of process that can be modelled…

> Clojure and Scheme are Lisps Basically new languages with strong Lisp influence. > very much towards simplicity Scheme maybe until the early 80s. Later it grew to Common Lisp size and beyond. See Scheme R6RS which is a complex language with tons of features and still underspecified. > The complex, do-it-all-in-one-huge macro is a Common Lispism, not a Lispism. Not really. Macros appeared in Lisp in the early 60s an…

Calling Scheme a "new language with a strong Lisp influence" is a bit rich. It's certainly not new, and in many respects it's more representative of Lisps-of-Old than Common Lisp.

Re: A difference between Haskell and Common Lisp

#92
post #68

Earlier quoted context omitted.

> Check out the UNIX man for tail, grep, ... to see how strange above quote about 'unix philosophy' is. The "UNIX philosophy" is good, it's just that UNIX doesn't really follow it. The C and shell programs that make up UNIX commands are actually UNIX's own little programming language , complete with ad-hoc data types. Look at `cat` for example. It might as well be `str + str...`. Or look at `grep`, it's basically `fi…

> The "UNIX philosophy" is good, it's just that UNIX doesn't really follow it. It never did, beyond some examples in beginner books. > Look at `cat` for example. It might as well be `str + str...`. Or look at `grep`, it's basically `filter` or `reduce` at heart. Then look at the options of `cat`. On my Linux system cat has a -n option, which numbers the output lines. If it were following the 'UNIX philosophy', this o…

UNIX may have been about small commands ("cat -v", anybody?), but its most important property is COMPOSABILITY. You could use small programs to build larger programs, allowing you to do things by gluing together code that you would previously have to write new programs to do. It made this very easy, and you could also do it from within C, so it wasn't an either/or situation. This is something your namesake system could have learned to do. The Right Thing isn't always the right thing.

Re: A difference between Haskell and Common Lisp

#93

And us schemers would express it like this: (cut take 5 (filter (drop 3 ))) or, without the cut macro: (λ (pred list) (take 5 (filter pred (drop 3 list)))) And yes, in most schemes, you can use λ as a synonym for lambda. Sometimes you have to define it first, though. Anyways, that looks a lot like the Haskell to you, doesn't it? It doesn't have the laziness, but other than that... Oh! Oh! I almost forgot! you can als…

It's easier for people propping up one language over another language family to ignore the similarly easy ways to do things in prominent members of that language family. ;)

Re: A difference between Haskell and Common Lisp

#94

Perhaps it's just me, but I don't see that Haskell and Lisp are that similar, other than... 1. They're both programming languages. 2. They both allow you to pass functions as arguments to other functions. Am I missing something here? Why are the two linked? Is it because Lisp is seen as the birthplace of functional languages (because of point 2)?

"They both allow you to pass functions as arguments to other functions."

" Is it because Lisp is seen as the birthplace of functional languages (because of point 2)?"

That was my feeling. Some tenuous connection that leads to meaningless comparisons. They have such different styles, cultures, and attributes that direct comparisons don't even make sense. People might technically be able to do something that's unnatural in one in the other easily. And vice versa. Question: would any idiomatic user of either really want to or waste time doing it that way? Probably not...

Re: A difference between Haskell and Common Lisp

#95
post #68

Earlier quoted context omitted.

> Check out the UNIX man for tail, grep, ... to see how strange above quote about 'unix philosophy' is. The "UNIX philosophy" is good, it's just that UNIX doesn't really follow it. The C and shell programs that make up UNIX commands are actually UNIX's own little programming language , complete with ad-hoc data types. Look at `cat` for example. It might as well be `str + str...`. Or look at `grep`, it's basically `fi…

> The "UNIX philosophy" is good, it's just that UNIX doesn't really follow it. It never did, beyond some examples in beginner books. > Look at `cat` for example. It might as well be `str + str...`. Or look at `grep`, it's basically `filter` or `reduce` at heart. Then look at the options of `cat`. On my Linux system cat has a -n option, which numbers the output lines. If it were following the 'UNIX philosophy', this o…

"On my Linux system cat has a -n option, which numbers the output lines. If it were following the 'UNIX philosophy', this option would not exist."

Gnu's not Unix. "The GNU coreutils version of this on my Linux box behaves this way" is not a good way of getting at finer points of what is or is not Unix-y.

That said, -n exists in BSD cat as well. It's not required by POSIX, though.

Re: A difference between Haskell and Common Lisp

#96
post #91
post #64

Earlier quoted context omitted.

> Clojure and Scheme are Lisps Basically new languages with strong Lisp influence. > very much towards simplicity Scheme maybe until the early 80s. Later it grew to Common Lisp size and beyond. See Scheme R6RS which is a complex language with tons of features and still underspecified. > The complex, do-it-all-in-one-huge macro is a Common Lispism, not a Lispism. Not really. Macros appeared in Lisp in the early 60s an…

Calling Scheme a "new language with a strong Lisp influence" is a bit rich. It's certainly not new, and in many respects it's more representative of Lisps-of-Old than Common Lisp.

Lisp started in 1958. Popular Lisps in the 60s/70s were Lisp 1.5, Lisp 1.6, Interlisp, Maclisp and Standard Lisp.

Scheme grew out of research from 75-80 (the Lambda Papers), investigating Actors and bringing ALGOL and Lisp together.

Thus Scheme is the newer language.

>it's more representative of Lisps-of-Old than Common Lisp.

Common Lisp contains a direct core of the original McCarthy Lisp. One can develop in Common Lisp in the typical styles of the 60s and 70s. With PROGs and GOTOs, symbols and property lists, dynamic binding, procedural macros, ...

Scheme was different: it introduced a more functional style, lexical scope, closures built-in, away from symbols and dynamic binding, ..., continuations, hygienic macros, TCO (recursion instead of direct iteration constructs), ... for some years people tried to bridge the gap (for example by providing a Scheme in Common Lisp, by reusing the concepts or by writing to a compatibility layer), but nowadays there is very little sharing.

Re: A difference between Haskell and Common Lisp

#97
post #64

You have to be clear about which Lisp. Clojure and Scheme are Lisps, and their focus is very much towards simplicity and the use of combinators. The complex, do-it-all-in-one-huge macro is a Common Lispism, not a Lispism. Secondly, Clojure, like Haskell, is focused on sequence abstractions, not lists. Sequences can include collections, streams, observables, sockets and many other kinds of process that can be modelled…

> Clojure and Scheme are Lisps Basically new languages with strong Lisp influence. > very much towards simplicity Scheme maybe until the early 80s. Later it grew to Common Lisp size and beyond. See Scheme R6RS which is a complex language with tons of features and still underspecified. > The complex, do-it-all-in-one-huge macro is a Common Lispism, not a Lispism. Not really. Macros appeared in Lisp in the early 60s an…

R6RS was basically DOA, with only 3 or 4 implementers (Guile, Ikarus, Ypsilon, and (partially) Racket) actually going along with it. Most of the other implementers, most notably CHICKEN's Felix Winkelman, refused. R7RS is now split into a small core, and a large standard library for practical, as opposed to teaching, use, whose development STILL isn't done.

Re: A difference between Haskell and Common Lisp

#98
post #48

Earlier quoted context omitted.

> Check out the UNIX man for tail, grep, ... to see how strange above quote about 'unix philosophy' is. I wish someone would take that hoary old meme out behind the barn and put it out of our collective misery.

unix commands may not be the pinnacle of minimalism, but the most important thing UNIX taught is about composability. Yes, I did recognize the irony of the fact that the common lisp example was much more like a unix command line than the haskell example, but if you're talking about composing (relatively) small commands, unix is still a pretty good comparison.

For being a pinnacle it is really unsatisfying. It tells you very little about how or what programs can be composed. It's either trial and error or reading man pages. In addition every program has to be written to take in anything as there are no constraints.

Function composition via types is a much more satisfying take on this problem. It's too bad Unix is regarded as the holy grail of this technique when it barely provides a passable implementation of it.

Text just isn't a great medium for IPC.

Re: A difference between Haskell and Common Lisp

#99
post #64

Earlier quoted context omitted.

> Clojure and Scheme are Lisps Basically new languages with strong Lisp influence. > very much towards simplicity Scheme maybe until the early 80s. Later it grew to Common Lisp size and beyond. See Scheme R6RS which is a complex language with tons of features and still underspecified. > The complex, do-it-all-in-one-huge macro is a Common Lispism, not a Lispism. Not really. Macros appeared in Lisp in the early 60s an…

R6RS was basically DOA, with only 3 or 4 implementers (Guile, Ikarus, Ypsilon, and (partially) Racket) actually going along with it. Most of the other implementers, most notably CHICKEN's Felix Winkelman, refused. R7RS is now split into a small core, and a large standard library for practical, as opposed to teaching, use, whose development STILL isn't done.

The R7RS homepage says something different:

>This is the home page for R7RS, the Revised⁷ Report on the Algorithmic Language Scheme. This version of Scheme has been divided into a small language, suitable for educators, researchers, and users of embedded languages; and a large language focused on the practical needs of mainstream software development.

>The report on the small language was finalized on July 6, 2013. It is available in PDF format and as LaTeX source code. There are errata.

>The development of the large language is still in progress. For details on the development process of both languages, see the ​Scheme Reports home page and the Working Groups home page.

Re: A difference between Haskell and Common Lisp

#100

And us schemers would express it like this: (cut take 5 (filter (drop 3 ))) or, without the cut macro: (λ (pred list) (take 5 (filter pred (drop 3 list)))) And yes, in most schemes, you can use λ as a synonym for lambda. Sometimes you have to define it first, though. Anyways, that looks a lot like the Haskell to you, doesn't it? It doesn't have the laziness, but other than that... Oh! Oh! I almost forgot! you can als…

It's easier for people propping up one language over another language family to ignore the similarly easy ways to do things in prominent members of that language family. ;)

Well, yes. Lisp and CL are not the same.

If anything, this has made me rethink possibly going over to common lisp, which I was thinking of for the larger stdlib, because SBCL is very fast, supports TCO, and you can disable case insensitivity.

Post reply on HN