I wanted to learn lisp, but the default formatting is just terrible. If it had a different formatting and supported infix notation, it would be readable to me.
The polish notation is the simplest thing to wrap you head around. Instead of operations being special syntax exceptions, they’re just functions! Functions that take parameters.
the only syntax of lisps are (myfun p1 p2 p3)
Mathematical operations are no exception (unlike otger languages). To make it simpler, think of it like this: + is just an alias (macro) for a function named plus which does addition. (plus 1245) is the same as (+ 1245). We don’t use infix notation because then that would be a syntactic exepction (like other languages) while this is the only syntax we have in lisp, for everything it’s really simple.
and also, how is (1 + 2 + 4 + 5) (15 chars) better than (+ 1245) (11 chars)? It’s a conceptual shift and once you make it, it makes so much more sense.
Why should LISP always be formatted in a way that’s unreadable? That can’t that be the defining property of LISP, can it?
Haskell unfortunately has literature which doesn’t read well to me. All examples are jumbles of letters f(a, b, c) with “as one can clearly see”. It’s as if I’m reading a math textbook. It’s like nobody writing a Haskell book is an actual educator. Python’s documentation is a better intro to the language than any Haskell book I’ve read.
Never heard of rhombus, but I’ll check it out, thanks.
Because if you don’t write it this way, then it’s not lisp. I would recommend you to read PG’s essay: On Lisp, and (a hard read) SICP.
As for Haskell, I am a teacher and I teach Haskell. I use Learn you a Haskell and Haskell programming from first principles. Haskell and Lisp are languages that by nature pull CS and math wizards. So is the documentation also written in that way. Hoogle is still one of the best sources of documentation.
“If you don’t paint a picture with this specific paint, it’s not a painting”. So if someone were to format the code differently, say put each right bracket on a new line, the compiler would fail?
Haskell and Lisp are languages that by nature pull CS and math wizards
They pull them because he learning material is written for them. If the learning material were written for non-wizards, it would attract non-wizards.
“Learn you a Haskell” is not a good book, IMO. It teaches exactly in the style mentioned. Just look at the part on applicative functors.
fmap :: (a -> b) -> f a -> f b
It says: give me a function that takes an a and returns a b and a box with an a (or several of them) inside it and I’ll give you a box with a b (or several of them) inside it. It kind of applies the function to the element inside the box.
He has to describe what the function does because the function declaration doesn’t use clear variables or type names. He says the word “box” but writes “f”. Why not just write “box”?
The entire CS and maths field is filled with people who suck terribly at explaining anything to anybody who doesn’t think like them. Monads aren’t terribly complicated, but the way they are explained is. Every book trying to explain them makes the mistake of going deep first and then zooming out. They explain in excruciatingly minute detail how monads are built, what other complicated concept they are like, and use single letter names for everything in that explanation.
class (Functor f) => Applicative f where
pure :: a -> f a
(<\*>) :: f (a -> b) -> f a -> f b
Same here. Then the examples use Just which doesn’t help with readability either. It would read much better if the code were actually literal instead of using shorthands for everything. More mental energy has to go into keeping a mapping table for every letter in the alphabet instead of it being written explicitly, right there.
It’s why I hate reading Haskell declarations and old code. Programmers back then just used 1-4 characters for everything. char, bool, m_lnr, T, R, I, f, g, h,… As if they were constantly on the run from the last person who had to read and maintain their code.
You might be a Haskell teacher, but that doesn’t say anything about the quality of your teaching. I play basketball and could even coach a team, but there’s nothing that will say whether I’m a good coach. If I get a team of people who already play well together, speak my lingo, and jive with me, they might think I’m a good coach. But if I get a team of beginners who have never heard my vernacular, can’t understand my mannerisms, and think “tough love” and the cold shoulder make me a dick, they’ll think I suck.
My students who did Haskell last year all passed with flying colors. I think the examples above are plenty clear, and the students also found them clear after I explained them, and with enough practice it wasn’t an in issue. I read the literature, practice it, and then use my teaching skills to teach it. It’s my job, and I take pride in what I do.
I’d say maybe the hypothetical you just needs a good teacher to show how it’s done, or the hypothetical student needs to read it enough till you understand it. In math we also have symbols, in math we also use shorthands. Why not in compsci?
Bar that, Haskell is just not a language that’s suited as a first language. The literature expects from you to be able to understand technical manuals. You don’t go teaching Rust to 8th graders, you don’t go learning Haskell without knowing at least what currying means.
As for brackets, you’re free to put them wherever you want; the professional are also free to do what they want, and it’s usually a good idea to adhere to a standard.
It seems to that you just have a difficult time going outside your comfort zone. The functional paradigm in general seems to be outside your comfort zone.
The actual quality is homoiconicity, meaning that code in the language is represented in the language’s own data structures (beyond the entire source file being a string). This enables structural macros - using the language to manipulate code before execution.
Some languages have tried to do this without the language syntax actually being data structure literals. Rust does it, but a typical Lisp macro looks like a simple template where some things are marked to happen at compile-time and others get spliced in at runtime. Rust macros don’t beyond the most trivial examples.
To add to the point about homoiconicity, both the article and my toplevel comment mention thread macros. The article talks about them being equivalent (syntactically at least) to method chaining, which I agree with.
The thing is, to get method chaining, the language has to have an object system, and the functionality you want to use has to be written in an object-oriented style. To get a thread macro, you need ten lines of code (aside from the docstring and metadata).
I wanted to learn lisp, but the default formatting is just terrible. If it had a different formatting and supported infix notation, it would be readable to me.
The polish notation is the simplest thing to wrap you head around. Instead of operations being special syntax exceptions, they’re just functions! Functions that take parameters.
the only syntax of lisps are
(myfun p1 p2 p3)Mathematical operations are no exception (unlike otger languages). To make it simpler, think of it like this:
+is just an alias (macro) for a function namedpluswhich does addition.(plus 1 2 4 5)is the same as(+ 1 2 4 5). We don’t use infix notation because then that would be a syntactic exepction (like other languages) while this is the only syntax we have in lisp, for everything it’s really simple.and also, how is
(1 + 2 + 4 + 5)(15 chars) better than(+ 1 2 4 5)(11 chars)? It’s a conceptual shift and once you make it, it makes so much more sense.So if lisp wasn’t lisp, you’d like it? 😂 you might want to take a look at Rhombus, or even Haskell.
Why should LISP always be formatted in a way that’s unreadable? That can’t that be the defining property of LISP, can it?
Haskell unfortunately has literature which doesn’t read well to me. All examples are jumbles of letters
f(a, b, c)with “as one can clearly see”. It’s as if I’m reading a math textbook. It’s like nobody writing a Haskell book is an actual educator. Python’s documentation is a better intro to the language than any Haskell book I’ve read.Never heard of rhombus, but I’ll check it out, thanks.
Because if you don’t write it this way, then it’s not lisp. I would recommend you to read PG’s essay: On Lisp, and (a hard read) SICP.
As for Haskell, I am a teacher and I teach Haskell. I use Learn you a Haskell and Haskell programming from first principles. Haskell and Lisp are languages that by nature pull CS and math wizards. So is the documentation also written in that way. Hoogle is still one of the best sources of documentation.
practical common lisp is also nice for a quick practical intro
“If you don’t paint a picture with this specific paint, it’s not a painting”. So if someone were to format the code differently, say put each right bracket on a new line, the compiler would fail?
They pull them because he learning material is written for them. If the learning material were written for non-wizards, it would attract non-wizards.
“Learn you a Haskell” is not a good book, IMO. It teaches exactly in the style mentioned. Just look at the part on applicative functors.
He has to describe what the function does because the function declaration doesn’t use clear variables or type names. He says the word “box” but writes “f”. Why not just write “box”?
The entire CS and maths field is filled with people who suck terribly at explaining anything to anybody who doesn’t think like them. Monads aren’t terribly complicated, but the way they are explained is. Every book trying to explain them makes the mistake of going deep first and then zooming out. They explain in excruciatingly minute detail how monads are built, what other complicated concept they are like, and use single letter names for everything in that explanation.
Same here. Then the examples use
Justwhich doesn’t help with readability either. It would read much better if the code were actually literal instead of using shorthands for everything. More mental energy has to go into keeping a mapping table for every letter in the alphabet instead of it being written explicitly, right there.It’s why I hate reading Haskell declarations and old code. Programmers back then just used 1-4 characters for everything. char, bool, m_lnr, T, R, I, f, g, h,… As if they were constantly on the run from the last person who had to read and maintain their code.
You might be a Haskell teacher, but that doesn’t say anything about the quality of your teaching. I play basketball and could even coach a team, but there’s nothing that will say whether I’m a good coach. If I get a team of people who already play well together, speak my lingo, and jive with me, they might think I’m a good coach. But if I get a team of beginners who have never heard my vernacular, can’t understand my mannerisms, and think “tough love” and the cold shoulder make me a dick, they’ll think I suck.
My students who did Haskell last year all passed with flying colors. I think the examples above are plenty clear, and the students also found them clear after I explained them, and with enough practice it wasn’t an in issue. I read the literature, practice it, and then use my teaching skills to teach it. It’s my job, and I take pride in what I do.
I’d say maybe the hypothetical you just needs a good teacher to show how it’s done, or the hypothetical student needs to read it enough till you understand it. In math we also have symbols, in math we also use shorthands. Why not in compsci?
Bar that, Haskell is just not a language that’s suited as a first language. The literature expects from you to be able to understand technical manuals. You don’t go teaching Rust to 8th graders, you don’t go learning Haskell without knowing at least what currying means.
As for brackets, you’re free to put them wherever you want; the professional are also free to do what they want, and it’s usually a good idea to adhere to a standard.
It seems to that you just have a difficult time going outside your comfort zone. The functional paradigm in general seems to be outside your comfort zone.
So much so that I use nix
you really want infix notation? go do some APL
If it supported infix notation (outside of reader macros), it wouldn’t be Lisp.
Why not? Is LISPs only, and major quality, polish notation?
Yes. Well, sort of.
The actual quality is homoiconicity, meaning that code in the language is represented in the language’s own data structures (beyond the entire source file being a string). This enables structural macros - using the language to manipulate code before execution.
Some languages have tried to do this without the language syntax actually being data structure literals. Rust does it, but a typical Lisp macro looks like a simple template where some things are marked to happen at compile-time and others get spliced in at runtime. Rust macros don’t beyond the most trivial examples.
To add to the point about homoiconicity, both the article and my toplevel comment mention thread macros. The article talks about them being equivalent (syntactically at least) to method chaining, which I agree with.
The thing is, to get method chaining, the language has to have an object system, and the functionality you want to use has to be written in an object-oriented style. To get a thread macro, you need ten lines of code (aside from the docstring and metadata).
I don’t know much lisp, but in scheme you can do
(1 . + . 2)=(+ 1 2)