What do you faggot think of LISP?

it's placebo autism

(((Lisp)))

Bad enough to put me off finishing SICP. I don't want to re-learn how to implement recursion in an ancient decrepit abandoned programming language.

>(((((but (the brackets) tho)))))

>LISP
We Clojure now

>I couldn't finish SICP
>I'm too intelligent to know how to do these things
>They're ancient and abandoned (just by me)

Linux is the best

Attached: smug923.png (354x360, 111K)

I'm so impressed at your ability to pretend I said things that I didn't actually say. Go eat a crayon.

...

Sad

I tried to learn lisp a while back. I just kept getting redirected to x version is better. And when I would try to find a book to read I got x book is better read that and those books would be out of date. It’s a hell hole world and I couldn’t even get started to learn it.

Well scheme is defined by being almost nothing, very minimal core stuff. Other lisps have lots of other standards but secretly also have an extremely minimal base functionality that is shared among every lisp. If you learn one lisp well you will be fine in any lisp.

The differences are incredibly superficial but are unfortunately kind of mutually incompatible on lots of levels, otherwise lisp would have a ridiculously huge ecosystem.

>I hate it for it's permission to use []

thats only racket

it's weird and i think it touches a lot of people inappropriately

I don't think I've really got the hang of it, but i have a lisp project for myself i'm working on, just building an API. nothing fancy i just felt like it'd cover all the typical things clisp would be ideal for. sbcl is nice to work with, the toolsets are pretty cozy, quicklisp is easy to use too.

>implement recursion
Would be a funny lisp that didn't have recursion built in. Come on now.

>book out of date
If it's common lisp, this simply isn't going to happen.
The standard is ancient, and hasn't been touched much because frankly, it doesn't need to. Adding to or modifying the language is so simple programmers can do it themselves as needed without fuzing with standards.
And which book you start with doesn't really matter because you can just read all of them anyways.

>scheme
I rather don't get why they need to be so nothing they can't even have nil. I get that it's the same as an empty list, but given that nil becomes the empty list by being treated as a linked list terminator I'd rather have both so it wouldn't be so confusing.

>linked lists
>dynamic typing

I like CL via SBCL. The syntax is not as bad as people like OP's pic make it out to be. When you consider languages like C/C++ with {};[], etc you realize that the () autism isn't that bad as people make it out to be.

kernel*

Btw CL has normal arrays and you can define your types ahead of time if you really think your premature optimization is going to help (it won't). Be smart and profile afterwards and you'll find where the biggest slow downs really are.

it was an interesting thing to learn. Also I had fun using Clojure

I remember seeing a mention of it in the little schemer, so there's that.

Schemes typically allow for the use of [] (or {}) in place of (), but outside of Racket the convention is to only use () for sexp delimiters. It definitely shouldn't be used as a reason to avoid Scheme.

For reference, R7RS states:
> The following four characters from the ASCII repertoire
are reserved for future extensions to the language: [ ] {
}

>not usable
Clojure is used in the industry and Elixir is syntactic sugar for a LISP bound to Erlang. It is being used.
Of course, LISPs will never be as popular as other languages, simply because average programmers are too dumb

It's not the character choice, it's the density. Having to keep track of nested parents is painful.

You're just not using the right tools. There's this thing called paredit. Saying that keeping track of parentheses is difficult is like coding in notepad and saying keeping track of variables and methods without syntax highlighting is difficult. Well yeah it is but because you're shooting yourself in the foot

>I rather don't get why they need to be so nothing they can't even have nil. I get that it's the same as an empty list, but given that nil becomes the empty list by being treated as a linked list terminator I'd rather have both so it wouldn't be so confusing.

I believe it's a matter of purity; Scheme doesn't have CL-style nil because the empty list shouldn't also be a symbol type. This is also why Scheme has #t and #f instead of the special t and nil symbols.

>Clojure
>blog.skyliner.io/fourteen-months-with-clojure-beb8b3e4bf00
literal soi language

Attached: 1*bzuf-4Q5FgZIfd683YyV3g.png (1158x562, 100K)

>Schemes typically allow for the use of [] (or {}) in place of (), but outside of Racket the convention is to only use () for sexp delimiters. It definitely shouldn't be used as a reason to avoid Scheme.
that sounds pretty comfy

I wonder why lispfags don't use other kinds of parens just for readability's sake.

le soi meme XD

R7RS makes sense. [] shouldn't be used for normal expressions elisp (and possibly clisp) use these for vector literals.
Now I should complain about empty list not being the falsy value. I don't like the idea of having a boolean type in lisp.

...

Editing tools should be a convenience, not a necessity. I have no problem grokking other languages in plaintext.

You don't even need something like Paredit. A parenthesis matcher and an auto-indenter are sufficient.

>I wonder why lispfags don't use other kinds of parens just for readability's sake.
Personally, I like the uniformity of regular parens. I find it a bit annoying to see a mix of ] and ) at the end of a sexp.

As long as the Lisp is properly indented, then I find that using []/{} doesn't usually make much of a difference. It's gets easier to parse the parentheses after you get familiar with them.

This.

I've been writing CL for years, and I can't remember the last time that I worried about parenthesis. The thought "are they balanced? are they where they need to be?" literally never crosses my mind.

I'm a PhD student a top American university. I use Common Lisp for almost everything, and I work in distributed systems and runtime research. Common Lisp certainly has warts, but it still is by far *the best* language for quickly building a system and testing its capabilities.

My only complaint is that the type system isn't more useful when defining methods because it only works on classes. For instance, I would like this code to work:
(defun tomp (name)
(and (stringp name) (string= (string-downcase name) "tom")))

(deftype tom () `(satisfies tomp))

(typep "ToM" 'tom) ; T

(defmethod test-method ((person tom))
(format t "Hi Tom!~%")) ;; error - tom isn't a class

I've been building personal workarounds for similar problems, and I'm thinking of publishing them as a quicklisp lib.

I guess I'll just have to stick with it.

I would think that determining precedence would be annoying if it did work for types. Any strong reason to stick with defmethod here?