http://en.wikipedia.org/wiki/Greenspun's_tenth_rule

Not saying it's a bad thing

That entire Wikipedia page goes almost entirely over my head.

I don't get it.

Kvallning wrote: I don't get it.

Hahaha amazing image

negascout wrote:http://en.wikipedia.org/wiki/Greenspun's_tenth_rule

Not saying it's a bad thing

It's probably true. At some point I think everyone who builds a sufficiently large system will start to see that the only way to really collapse all of the complexity is to look at it like...pure math / functionalism, like lisp. So seems a reasonable point I definitely wonder what LT would look like had it been written functionally from the beginning.

Course, it wouldn't be running at 100 FPS

Every time i read about lisp i want to learn it.
I should actually start one time...
Has anyone a good link for learning lisp?

What LISP fans don't mention (but which Josh correctly did) is that the price you pay for LISP's self-modifying ability to do anything is that, for any significant real-world functionality, LISP code takes more time to write, more time to modify/maintain, and more time to run.

Like most tools, the value of LISP is context-sensitive: it's good for some things, not so good for other things. So while Greenspun's Tenth Rule might be facially true, at a larger (actual real world project development) level it's less meaningful. Yes, at a certain level of code complexity you probably are reinventing some features you get for "free" in Common LISP. But you're also probably getting code that, because it is custom-written in a less general-purpose and thus more performative language, runs faster and can more easily be understood and enhanced by normal human beings.

LISP is awesome... but not for everything.

I like my languages like I like my games; fun to play with and procedural.

Screw Lisp.

JoshParnell wrote: It's probably true. At some point I think everyone who builds a sufficiently large system will start to see that the only way to really collapse all of the complexity is to look at it like...pure math / functionalism, like lisp. So seems a reasonable point I definitely wonder what LT would look like had it been written functionally from the beginning.

Course, it wouldn't be running at 100 FPS

I've definitely been drinking the Clojure koolaid recently. I hate that it doesn't have a static type system (though the core.typed project is working on an optional one, but I'm skeptical), and heterogeneous collections seem like a really bad idea to me, but I really dig the homoiconicity and the community is really productive, creative and responsive. There's even an existing Clojure library that does pretty much what my River project that I sent you recently does (though it lacks laziness and therefore doesn't scale as well I think): http://www.infoq.com/presentations/Cloj ... pt-Javelin.

Flatfingers wrote:What LISP fans don't mention (but which Josh correctly did) is that the price you pay for LISP's self-modifying ability to do anything is that, for any significant real-world functionality, LISP code takes more time to write, more time to modify/maintain, and more time to run.

Not to turn this into an age old functional/imperative flame war, but I actually have to disagree w/ the "more time to write/modify/maintain" bit. Functional programming is a very different mindset than imperative programming, but in a similar, but deeper way that English is a different mindset than Chinese. It doesn't mean Chinese takes more time to write. I just haven't learned it so it takes more time for me since I have to look up each thing in the book first. I recently used Clojure to build a tool to generate a certain type of logic puzzle and found it to be a very low-friction experience. It was much quicker to implement in Clojure and port to C++ than to develop initially in C++. It has taken a few years to get my mind to think functionally, but now that I do it's much more pleasant and quick, and far far less error prone than reasoning imperatively.

Clojure is actually pretty fast too. Certainly not anywhere as fast as Josh's well tuned C++, but faster than you might think. The persistent data structures it is built with are really phenomenal.

I understand, negascout. Making that switch took some time when I taught myself LISP [mumpty mumble] years ago. I never got good at it, but I got good enough to know that -- as with many computer programming languages -- once you use it enough it gets easier. There was a time when I was writing everything in various flavors of assembly language.

But to be clear, I didn't just aver that LISP takes more time to write and enhance in a universal way -- I said it takes more time for some problems. There are things it's good at, and things it's not so good at. I could write device drivers in C; I don't think I'd want to try to do that in Prolog. At the same time, there are things I don't want to try to do in C. (That's one reason why I transitioned to Java.)

Which goes back to my point about GTR: yes, you get some stuff for "free" when you choose to use LISP... but there are costs as well. There is no one Perfect Language -- different tools work better for different functional purposes.

I don't think I'd want to live in a house whose builder thought that the only tool he needed was a hammer.

(Note: Josh may prove me wrong with his notion of a node-based visual language for software development. Maybe that is the Perfect Language that can do everything reasonably well. If so, I'll be the first to admit I was wrong... but with respect to Josh, I don't think that's going to happen. Structure implies contextual fitness. But we'll see. )