Is it worth learning lisp in 2019?

Any books you’d recommend for a beginner interested in Common Lisp?

>Is there a significant difference between CL, Scheme and other Lisp dialects?
Between Scheme and CL, it's mostly a stylistic one. Common Lisp permits whatever style you want, but it's mostly used as an imperative, object-oriented language (think Python, but better).
Although SBCL (the de facto primary Common Lisp implementation) has tail call optimization, the standard does not guarantee it. As such, recursion is not guaranteed to be optimized and can result in stack overflows. Use of loops is encouraged.

Scheme encourages a functional style (recursion, passing lambdas, returning closures, etc), but allows mutation. If you want, you can always write macros to simulate loops via repeated calls to mutate values.
Some Scheme dialects are more like Common Lisp than others (e.g. Guile), encouraging a wide variety of styles.
>Also is it very easy to pick up other Lisp dialects if you know one already?
Emacs Lisp is almost identical to Common Lisp most of the time, both being heavily based on Maclisp. The big differences are missing features (no packages, namespaces, or object system in Emacs Lisp) and dynamic scope by default (this can be changed in the file header).
On the whole, knowledge can be transferred between Scheme, Common Lisp, and Emacs Lisp.
I haven't done Clojure, but it looks like it's more different and would benefit from prior knowledge of a functional language (Haskell, Scheme) and the underlying JVM platform (I've heard that its stack traces morph into Java's at some point).

Not him, but this one is pretty good

Attached: IMG_20190328_145105128.jpg (1836x3264, 1.43M)

...

a lisp machine
pure lisp in a box

Attached: Symbolics3640_Modified.jpg (308x608, 130K)

youtube.com/watch?v=xx6QPgi7RSQ

Attached: lispmachine.jpg (480x360, 15K)

That was the case 30 years ago, expert systems are not the state of the art in AI anymore

OP, basically covered all the major points for why you'd want to learn Lisp but I'll add this one: learn it to realize just how much you're actually missing when you use macros or template systems in other languages in comparison to the way Lisp does macros

decent demos of lisp machine are on youtube in english .. most impressive demos of smalltalk
what microsoft didn't get, from the start and why it's so crud.

>Is it worth learning lisp in 2019?
Knowing a variety of languages isn't a bad thing, but mastering your preferred language is always best.

>466664

It's true. It's all true.
It's funny that you bring this up, because I was messing around with C++ templates yesterday, and I thought to myself when I fucked up, "it would be so nice if I could throw an exception to avoid the error spam" because I knew what most the errors would be and which I would be looking for. However, exceptions are a runtime construct, and templates are a different language unto themselves. Template exceptions would have to reinvent the wheel because there's a mismatch between the compile-time and run-time languages.
Then I thought back to writing macros in Lisp and how nice it was by comparison!
Macros in Lisp are very powerful because the language can process itself. Lisp processes lists at run-time, and the source code itself is written in lists. As such, the compiler is a Lisp program which rewrites Lisp programs. You get all the good runtime stuff at compile time!
What's more, if a feature is missing, you don't have to wait for the standards committee to add it. There is no AbstractProxyManagerBean design pattern spam because you can generate the boilerplate at compile time.

'homoiconic'

Is Lisp actually used for anything useful today? (Academemes need not apply)

Yes. It's the best way to fight Bell Labs Cnile/Eunuchs revisionism.

Racket

Yes.
common-lisp.net/lisp-companies

I heard that Lisp and dialects aren't pure functional langs, while Haskell is.
Someone care to explain in what way?

because they're imperative (ie useful)

@70471523
How does being imperative imply being useful?

Yeah but what in particular is imperative, and how Haskell do it instead?

imperative programming is commands that are issued one after the other that change the state of the computer
nobody knows how haskell does it, it's a closely guarded secret that you need to be a haskell programmer to understand

Why do you quote in such a retarded way? Are you gay?

Should I learn Lisp if I hate Jews?

@70471584
Aren't you? LMAO fag

>nobody knows how haskell does it
Are you saying there are no Haskell programmers? How does a compiler for it exist then?

nobody who isn't a haskell programmer knows and if you ask one they won't tell you

emacs

>used for anything useful
This is redundant. By definition, any "use" of Lisp would be "useful".

By useful, I mean actual code deployed and running in production systems. School projects do not count.

>emacs
>school project
Kill yourself.

Well emacs is the only good text editor, which can be useful for any of your gay projects or whatever

>not using the superior text editor

Attached: Vimlogo.svg.png (1022x1024, 90K)

@70471800
Why would I use a shitty knockoff when I can use the real thing?

>imperative
call_action_a() ; call_action_b()

programmer has to check manually if he is allowed to `call_action_b()` after `call_action_a()` has been called (or not, or the params might be wrong, who knows? I don't)
>haskell
call_action_a >>= call_action_b

so you replace `;` with `>>=` and then the compiler tells you if it is okay to do it that way.
depending on what you want to do `;` translates to different symbols. if there is no state that needs to be passed from a to b then `>>` is enough. If there are only primitive values without any state then use `.` to compose those two functions into a new one.
if you have a special state (e.g. an OPTIONAL int) then you have to use ``
and so on and so on.

so in haskell you don't have this `;` but a set of other compose operators so that the compiler tells you if you fucked up.

hope this explains it somewhat, in the end both approaches might produce the same assembly but the imperative could not be checked thoroughly.

grammarly is written is lisp
A lot of projects choose not to use lisp because there aren't really that many lisp programmers, sort of a chicken and egg problem.

static analysis has little to do with imperative vs functional
you can statically analyize appropriately written imperative code

Go back to /b/

>frankenvim
>bloated as shit
>horrible configuration language
>piss poor customization capabilities
>vimuser.org
>the superior text editor
Ok lad.

Attached: 1553372085610.jpg (2500x3372, 3.96M)

I didn't have a proper VI logo

>you can statically analyize appropriately written imperative code

except when you can't

this `appropriately written imperative code` is exactly what is produced by ghc (the haskell compiler) in an intermediate repesentation. the language is called c-- (c minus minus) it mosly just enforces tail call recursion. Because this strict enforcement is missing in c and c++, they (simon peyton jones) had to write his own version of mostly compatible c (even with preprocesser).

haskell builds up on the notion that ALL code is appropriately written, otherwise it does not compile.

in other language most of time it is a mix and match between good code, mediocre code and bad code. (in respect of being `appropriately` written).

people argued that some problems just can't be solved efficiently with `appropriately` code. or even can be solved at all.

this where haskell comes into play. The missoin was to see if you can solve all problems by only using `appropriately` written code.

They did succeed.

Now people are moving the goal post and try to find some other flaw (e.g. syntax, or some badly worded error message, file size of produced binaries (they are by default statically linked and therefore bigger))

in the meantime most other programming languages started implementing all the haskell features. e.g python's `with` statement that is a badly implemented monad, optional types that are called`maybe` in haskell, or just fucking bad `promise` or `defered` stuff where you can compose functions that should be applied on values (and type checked) before the value exists ... which is haskells IO-monad.

and in the end it's just about how to compose functions to create new functions (which can be done with `;`) but in a way that the result is always `appropriately` typed to make the compiler happy.

read sicp

Attached: smug.jpg (788x443, 128K)

Haskell is not completely provable or solvable or whatever the word is, you have to program under strict restrictions for it to be so, just the same as an imperative language
Functional vs imperative is not strongly correlated to static analysis, Haskell is just a functional language with strong static analysis tools

Bump
I wanna learn cl soon

Kek

Attached: comment_RVhVUV6YotUQjgeyi2DOIqpWvghaQm8l.jpg (395x492, 24K)

Of course it is? Functional programming removes most problems in doing static analysis. Imperative have to be severely limited to be similar in this aspect to basic functional programming, e.g. Ada SPARK.

>Functional programming removes most problems in doing static analysis
no, it removes a few of them
Haskell's provability comes from its type system, which isn't intrinsic to functional languages

bebg finowie

Read "Practical Common Lisp". It's available online for free.