Don't do it, you'll hate every other language after that (I do).

I like LISPs conceptually. However, I have a strong preference for static type systems, so I have probably written 10x more lines of code of LISP implementations than LISP code itself.

A Common Lisp implementation may have static types:

    (defun foo (x)
      (declare (type fixnum x))
      (1- x))

If you don't specify them, types all default to T.

Although I like OCaml way better than lisp, there is some static typing in Common Lisp. Sure there would be a lot of T (basic object) in your signatures, but you can have some typing discipline within it (although not as strict and beautiful as in ML languages).

Racket has Typed Racket, you might want to try that out!

Have you tried it yourself though? That thing is so slow it's barely usable.

Is it the type checking or the runtime that's slow?

Yeah, this happened to me when I migrated to Clojurescript. But it really only lasted until I (finally) got my arms around Elm. Lisp, of course, is a lot more versatile than Elm since Elm is specifically a browser language, so it's taken the job of being my scripting language away from Python and JS.

It makes everything feel like putting together IKEA furniture

Is that good or bad? IKEA is thrown a lot as a metaphor but I have no idea most of the times what it should mean.

I've never heard the IKEA metaphor before but it makes sense to me. There's really only one way to put any two pieces together. If they forgot to ship the right bolts, you're SOL.

Lisp is like a wood and metal shop. It may take a little more time to become proficient with the basic tools, but once you do, anything is possible. You don't hear Lisp programmers complain they can't do X with Y, and you don't hear builders complain they don't have the right piece to attach X to Y. If you don't have one sitting around, you take a few minutes and make one.

No good. Furniture is nice and cheap, but you ensemble it yourself at home. Honestly, I find it easy, but I'm good with that kind of handiwork. Most people find the instructions unclear and difficult to follow. There are many references, from the top of my head I remember The Wire... look for Mc Nulty IKEA on YouTube, I bet it will work.

For a little more money they serve the furniture to your house and ensemble it.

I've done it, now I hate Lisp. I've read On Lisp and Let Over Lambda, I've used Clojure in production, and I still hate Lisp, any and all of them. What am I doing wrong? Perhaps it's that reading code is more important than being clever when writing it. Or maybe that Lisp syntax doesn't pass the squint test[0] because it makes the wrong tradeoff of catering to the machine instead of us good ole' humans?

When I make my own language, I'll make sure to make macro calls as clumsy and hideous as possible to discourage their unexpanded use. I'll also make the whole language available at compile time but without syntax manipulation (a la Zig) to make most macros unnecessary.

So no, Lisp is far from "the language to end all languages" or whatever it is you smug Lithp weenies imagine it to be.

[0] https://www.teamten.com/lawrence/writings/the_language_squin...

I'm not sure what the Language Squint Test is supposed to tell me here. I can clearly see the structure of the Lisp code, too. It's only half as long as the Java one, which is great for reading. A single character can completely change the meaning of an entire block of Java code, too -- that has nothing to do with macros.

> I claim that this squint test is important, and that languages should deliberately make different constructs look different.

For your example, you just happened to pick a programming language you already know well. If this is a beneficial goal, why pick that particular point on the spectrum? Java and Lisp aren't the only games in town. It would be a remarkable coincidence if the language you already know were the optimal point.

COBOL's constructs look even more distinct from each other. A COBOL programmer probably thinks your Java methods all look the same despite having completely different calling conventions. After all, COBOL was definitely designed for "us good ole' humans".

> When I make my own language, I'll make sure to make macro calls as clumsy and hideous as possible to discourage their unexpanded use.

Sounds like Rust beat you to it.

Maybe instead of reading On Lisp and Let Over Lambda you should have started with something that explains and encourages the use of CLOS, because that's where Common Lisp really shines.

I know about CLOS, multi-methods, the meta-object protocol. It's a nice, dynamic OOP system (though I'm not a fan of dynamic languages). The thing is, CLOS isn't Lisp-specific: it can easily be recreated in a language with a normal syntax, e. g. Smalltalk. So there's no reason, ultimately, to sacrifice readability and maintainability to the demons of Parenthethes and Pervathive Macroth like the Lithp acolytes would have us do. Lisp is just a bad tradeoff from the get-go: reading code is more important than writing, language simplicity is more important than extensibility, and macro-writing is secondary to regular code writing.

Nice, but I think you are exaggerating a bit. Not every Lisper is a smug Lisp weenie. Actually I don't see many of those these days so I don't get the hate. Most of the annoying tribalist folks jumped ship to the Rust and Haskell camp.

Syntax is highly subjective, and funny that you mention Smalltalk, as I had a hard time selling that to some developer friends of mine because the method based syntax really put them off.

I also prefer statically typed languages, at least in the context of professional work with developers with various degrees of expertise contributing to the codebase. Then again, if I have to work in a dynamic language, I definitely take something image based with great tooling and feedback loop such as Pharo or LispWorks over Python or Ruby any day of the week.

Since people have different needs and tastes, there is no single type of syntax mechanism agreed upon.

Lisp generally favors flexibility, easy code generation/transformation, code as simple data structures, extensibility... that's attractive and useful for some.