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…
A difference between Haskell and Common Lisp
91–100 of 203 posts
Re: A difference between Haskell and Common Lisp
#92Earlier 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…
Re: A difference between Haskell and Common Lisp
#93And 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…
Re: A difference between Haskell and Common Lisp
#94Perhaps 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)?
" 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
#95Earlier 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…
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
#96Earlier 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.
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
#97You 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…
Re: A difference between Haskell and Common Lisp
#98Earlier 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.
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
#99Earlier 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.
>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
#100And 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. ;)
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.