> it's not very common for people to change sides after their initial indoctrination.

I was initially repulsed when I saw examples of Lisp code. After I had been in the static, Algol-like world for many years (Pascal, C, Ada, C++) I encountered more dynamic languages like Perl, Java, Python, and Ruby. I was fascinated by things you could do in those languages (especially Python and Ruby), and then learned that Lisp had been doing these kinds of things better for decades. That got me interested enough to move beyond the dislike of things like parentheses.

However, now things are different. There are now several choices of languages that have a mix of expressive power and efficiency that rival or surpass Lisp such that it doesn't stand out as much. I would say it's ability to be customized is now the main feature and curse of the language. It causes some people to love it, but makes it unsuitable for the typical large team project unless you have very strict controls on how it is used.

I've always wondered why LISP was such a hot-topic of discussion for CS people. I'm not technical myself, but the idea of different computing languages being more/less efficient in certain tasks is interesting.

I don't know how valid this is, since I've only spoken with a handful of Lispers, but it seems that they appreciate the freedom and lack of boundaries/rules/limits that Lisp provides. They talk about it like a language that can do anything, because it has no rules on what it can or cannot do.

But at the same time, my friends also remind me that the lack of limits means that they are more accountable for every line of code, and that as a beginner, it'd be best for me to use something more structured (they always say Python) until I'm comfortable taking off the training wheels.

Can anyone share their thoughts?

The 'freedom' of Lisp that you're describing comes from a different relationship between the language and the programmer than you have in other languages. In almost all non-lisp languages (including all the popular languages you've heard about), you're a user of the language. There's a set of syntactic and semantic rules provided by the language designers, and you're supposed to use them to express your programs. There's a strong separation between the language designers and the users of that language.

On the other hand, Lisp languages (affectionately called "programmable programming languages"), remove that separation almost completely. As a programmer using a Lisp, you're provided with enough tools to build new syntax and semantic rules, so that the language better matches your problem domain. This is a very powerful technique, but obviously also dangerous.

As a simple example, say you wanted to do OOP in Python, but for some reason Python didn't provide the "class" keyword. At this point, you'd be totally out of luck. Your best bet would be to send a request to language designers, and in the meantime try to program OOP-style in structural code. On the other hand, if someone took away the "defclass" macro from Common Lisp, you could quickly reimplement it yourself and thus introduce OOP facilities that look and work as if they were a part of the language from the start (in fact, building your own simple OOP is pretty much a textbook exercise for lispers).

That much of power can obviously confuse people who didn't do much programming before. It's good to start with a simpler language first - be it something like Python, or even subset of Scheme that's used in SICP, which sacrifices some of the Lisp power for making it suitable as an introduction to programming.

> I've always wondered why LISP was such a hot-topic of discussion for CS people.

Because in a discussion with five CS people, only one has actual real Lisp programming experience, one has some freshman experience in some professor's one-weekend Lisp-like dialect where a run-time type error segfaults, and the other three have different misconceptions about what Lisp is.

The number of times I've mentioned common lisp and gotten "Oh yeah, that's the language with no loops, just recursion, right?" does sadden me a bit.

To clear it up for anyone reading this:

Scheme has tail-call elimination as a requirement of the language; common lisp does not, and even includes an (overly?) sophisticated DSL for iteration in the standard library.

Also 95% of what you learned about lisp in your "Survey of programing languages" course was wrong.

The loop macro may be described as overly sophisticated. However, I can't help but get a chuckle with how much all of the new "stream" based mechanisms in java[1] mimic it. Ironically, with what appears to be more parens.

[1] https://docs.oracle.com/javase/8/docs/api/java/util/stream/C...

python's list comprehensions and generator expressions can get pretty complex too.

To be fair, the LOOP facilities are ridiculously complex. Similarly so are the FORMAT facilities.

I regret not knowing more about them as a younger programmer. Most of the "power" of lisp is always shown in the ability to compose programs out of forms. It is amazing how much code you can avoid writing by just using either loop or format. Or both.

I'd be interested to see some data on what the real ratio is.

I suspect that 1 in 5 might actually be high, which IMHO is sad -- not because I think less of those without any kind of Lisp experience, but because I think they are seriously missing out.

For any CS folks (or just developers in general) who have thought about learning a Lisp of some sort, but for some reason have never gotten it done, I would encourage you to do so -- it really is worth the effort.

I know; if any random sample of five CS people could be expected to have 0.9 to 1.1 Lispers in it with a 19/20 confidence, that would be a different world, ha!

Universities sometimes do their fair share to screw this up even further. In my Alma Mater, there is this famous PhD who managed to discourage a generation of students from Lisp by the sole virtue of how she did the classes. :/.

Some examples/anecdotes would be interesting. with-genyms to protect the guilty.

Some languages are absolutely more efficient for certain tasks.

Here are some probably not very contentions examples:

If you pick Brainfuck for your language it will probably take you longer to write your program than Java.

You will probably be able to write a network server in Go faster than you will be able to write it in assembly.

Those may seem contrived, but if you start to compare things that could be actual business decisions it becomes much harder for everybody to remain objective.

You also get to the point for which there may be no universal answer for each programmer. This is at least partly because many programming tasks are quite mundane, and so wouldn't be any faster/slower in general between, for example, Javascript and Lisp. You give them to me and I'll do it much faster in Lisp, while a javscript developer will do it much faster in javascript just because the task is simple enough that individual proficiency with the tools trumps any minor differences for such tasks.

It's common for Lisp newbies to think they can just hack a Lisp program until it works because it's so forgiving. Wrong. Lisp does provide an enormous amount of freedom, and knowing your integers and your buffers cannot overflow, taking the sqrt of -1 just works, and having infinite precision fractions are all pretty great. But you still have to know about algorithms, data structures, and software engineering if you're going to succeed at Lisp.

I think the underlying point of contention is that in Lisp, your code is basically a serialized AST. That gives you considerable power (macros, the ease of "compiling to Lisp" even in a running program), but working that close to the compiler can also be a pretty raw experience.

The only thing you need to do to understand lisp's entrancement is to write an interpreter for it, and in doing so you'll see why it's easier to write a lisp interpreter than it is for any other language. All you need to understand the appeal is a look at https://github.com/kanaka/mal.

Personally I learned the appeal of lisp while following this tutorial on writing a scheme in Haskell: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_.... There's a reason there'll never be a tutorial like that for a toy Haskell interpreter.

That whole argument "you have to write your own Lisp and then you will see the light" is completely wrongheaded and should be retired. Any computing person with two brain cells to rub together sees red flags in it. Did you build your own bicycle from scratch before understanding the wonder of riding a bicycle? The way Lisp is taught is wrong too; students in some courses are given too many exercises involving hypothetical scenarios in which some half of Lisp is missing and they have to put it back.

A Scheme that someone wrote in 48 hours following a tutorial isn't something I'd want to use in production. It's missing the whole angle of Lisp being a feature-rich, mature language suitable for production use.

A Lisp is valuable because of what you don't have to write in it to get the job done.

You're arguing against the concept that writing one's own Lisp is necessary, and you're right: it's not necessary to implement Lisp to appreciate it.

The post you replied to, OTOH, was arguing that writing one's own Lisp is sufficient, and I think it's right: if one implements Lisp from scratch, one will end up appreciating Lisp. Outside of half-assed homework assignments, anyway.

What people need isn't sufficient so much as efficient.

To appreciate Lisp (or anything) is really to appreciate the underlying requirements (and that they are done).

Some people absorb requirements very well (and then appreciate them) if they force themselves to implement the requirements, which is fine. Even those people can't just confine their appreciation to that which they're able to implement, because then the scope of their appreciation will be rather small.

I really appreciate John Carmack's approach to determining shadow maps for a scene: the clever "cast a ray from a point on the surface to infinity and determine whether it intersects a shadow volume boundary an even or odd number of times" so then you know whether it's in the shadow volume (w.r.t a light source) or not. So we go backwards from a pixel on the screen, to some point on an object's surface. For each such point (consequently pixel) we can determine whether it's in shadow; and we can reduce that to a 2D shadow map in pixel space. Terrific, right? And about the shadow volumes, they are basically just conical shapes made using the 2D contour of the objects as seen from the POV of the light source, and capped at the end somewhere so they are finite. I'm not going to sit here and implement it all though. It's not that I couldn't find the time but that it's out of scope. I can play it out in my head though and see it working which is a good enough facsimile.

I don't mean to imply that I've done this (aside from copypasting from that wikibook). I just think that understanding why it's easy to do this for lisp is important.

Interestingly this is also true of FORTH, which is why we have hundreds of poorly documented FORTH compiler/interpreters and almost no decent libraries or actual programs written in FORTH.

I agree entirely with that.