[zoky]

I’m not really familiar with Lisp, but from glancing at this article it seems like all of these are really good arguments for programming in Ruby (my language of choice). Easily predictable syntax, simple substitution between variables and method calls, dynamic typing that provides ad hoc polymorphism… these are all prominent features of Ruby that are much clunkier in Python, JavaScript, or really any other commonly used language that I can think of.

Lisp is on my list of languages to learn someday, but I’ve already tried to pick up Haskell, and while I did enjoy it and have nothing but respect for the language, I ultimately abandoned it because it was just too time-consuming for me to use on a day-to-day basis. Although I definitely got something out of learning to program in a purely functional language, and in fact feel like learning Haskell made me a much better Ruby programmer.

[hxegon]

I have about 6 years of ruby experience and if you're saying that ruby has "easily predictable syntax"...

You really should try lisp. I liked clojure a lot coming from ruby because it has a lot of nice ergonomics other lisps lack. I think youd get a lot out of it.

[shadowgovt]

Ruby and LISP have a lot of overlap. To my money, LISP is a little more predictable because the polymorphic nature of the language itself is always in your face; you know that you're always staring at a list, and you have no idea without context whether that list is being evaluated at runtime, is literal, or is the body of a macro.

Ruby has all those features but (to my personal taste) makes it less obvious that things are that wilding.

(But in both languages I get to play the game "Where the hell is this function or variable defined?" way more often than I want to. There are some advantages to languages that have a strict rule about modular encapsulation and requiring almost everything into the current context... With Rails, in particular, I find it hard to understand other people's code because I never know if a given symbol was defined in another file in the codebase, defined in a library, or magicked into being by doing string transformations on a data source... In C++, I have to rely on grep a lot to find definitions, but in Ruby on Rails not even grep is likely to find me the answer I want! Common LISP is similarly flexible with a lot of common library functions that magick new symbols into existence, but the codebases I work on in LISP aren't as large as the Ruby on Rails codebases I touch, so it bites me less).

[speedbird]

Go back to the source, use Smalltalk in a nice environment like VisualWorks and get all that built in :-)

[rjsw]

Common Lisp has compilers that produce fast code.

[shadowgovt]

On this topic: My absolute favorite Common Lisp special operator is `(the`. Usage, `(the value-type form`, as in `(the integer (do-a-bunch-of-math))`.

At first glance, it looks like your strong-typing tool. And it can be. You can build a static analyzer that will match, as best it can, the type of the form to the value-type and throw errors if they don't match. It can also be a runtime check; the runtime is allowed to treat `the` as an assert and throw an error if there's a mismatch.

But what the spec actually says is that it's a special operator that does nothing but return the evaluation of the form if the form's value is of the right type and the behavior is undefined otherwise. So relative to, say, C++, it's a clean entrypoint for undefined behavior; it signals to a Lisp compiler or interpreter "Hey, the programmer allows you to do shenanigans here to make the code go faster. Throw away the runtime type identifier, re-represent the data in a faster bit-pattern, slam this value into functions without runtime checks, assume particular optimizations will succeed, paint it red to make it go fasta... Just, go nuts."

[cess11]

If you want something similar to Ruby but more functional, try Elixir. The similarities are superficial but might be enough to ease you in.

Haskell is weird. You can express well defined problems with relative ease and clarity, but performance can be kind of wonky and there's a lot more ceremony than your typical Lisp or Scheme or close relative of those. F# can give you a more lispish experience with a threshold about as low as Haskell, but comes with the close ties to an atrocious corporation and similar to Clojure it's not exactly a first class citizen in the environment.

Building stuff in Lisp-likes typically don't entail the double programming languages of the primary one and a second one to program the type system, in that way they're convenient in a way similar to Ruby. I like the parens and how they explicitly delimit portions that quite closely relate to the AST-step in compilation or whatever the interpreter sees, it helps with moving things around and molding the code quickly.