201–210 of 276 posts
Earlier quoted context omitted.
Almost all Lisp code will put the closing parens all together at the end. And the idea is to not care about how many there are by using an editor that provides the appropriate assistance.
> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
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…
Referring to the broad Algol-family isn't uncommon (well, at least, I do it quite a bit.)
> 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.
Java and C# are frequently described as being part of a single close language family (much closer than the broad Algol-family; sometimes in an intermediate-breadth family that also includes ), and Ruby and Python are much less similar than Scheme and Common Lisp.
Earlier quoted context omitted.
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
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…
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 closer to the difference between C (with a bunch of different compiler extensions) and C++ than C and Python, but it's a pretty big difference.
Ultimately I think the claim of Common Lisp being the "true Lisp" is simply that deciding such a thing was the whole point of Common Lisp. Without a standard, you're left with someone writing http://wiki.call-cc.org/eggref/4/multi-methods#examples (or http://wiki.call-cc.org/eggref/4/fast-generic) and someone else writing https://docs.racket-lang.org/multimethod/index.html and neither being able to share code with each other. Most code isn't as trivial as the birthday paradox.
Would you want to try writing a (R6RS) Scheme driver for that 1960 code and see how straightforward it is?
Where do you slot https://en.wikipedia.org/wiki/Dylan_(programming_language) ? Should it be in the running for "the true Lisp"? If not why not?
Earlier quoted context omitted.
> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
Having to depend on an editor to make your code legible seems like a bad thing.
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…
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, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.: https://github.com/rongarret/ergolib and in particular the…
>> 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…
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);
}
}
bignum fact(bignum n) {
if (bignum_is_zero(n)) {
return n;
else {
return bignum_multiply(n, fact(bignum_subtract_1(n)));
}
}
Earlier quoted context omitted.
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…
Lastly one wonders why we don't go calling all these C-like languages ALGOLs. We sometimes do though, don't we? Not that terminology, but I often see the people talking about "curly brace languages" or "C/C++/Java/C#".
Edit: In hindsight at the end of the day I should have been more careful with the "Scheme is not Lisp" (at least I didn't say "Scheme is not a Lisp") comment...I'm only continuing these threads because I read the original submission pretty close to when it was posted and back then I only knew a bit of SICP, tried enough Lisp to duplicate some SICP examples, and was frustrated with the Lisp-2 syntax along with what I perceived as a REPL freakout on any error so I put Lisp aside. It would have been helpful for someone to tell me "Scheme is not Lisp" back then and get me to actually explore all that Common Lisp has to offer.
Earlier quoted context omitted.
> Caml Light, Standard ML, pure lambda calculus The first two being based lisp, and the third being what inspired lisp. It's like saying: I learned low level imperative programming from using Go, C++, and register machines. Which, sure, but the C language was hugely influential to all of that.
What does ML, initially developed for theorem proving, have to do with Lisp?
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, and that is necessary for theorem proving that is based on lambda calculus.
Because they likely prototyped the system in a set of lisp macros before writing the language (all the authors knew lisp and had taught each other it).
Earlier quoted context omitted.
Having to depend on an editor to make your code legible seems like a bad thing.
Why? (And what language do you use where you don't have to rely on the editor to format your code?)
I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary.
I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line just seems like needless noise.
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…
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…