Linked by Alexandru Lazar on Mon 5th Jan 2009 19:13 UTC
General Development In the age of dynamic languages and closures, most of you have probably heard of a mighty dragon called Lisp (which stands for LISt Processing), whose fans look almost with despise at other languages rediscovering it. Invented half a century ago, Lisp went on to become a de facto standard in the world of AI research, and has stood behind a handful of very neat inventions in the 1980s. Nevertheless, the long AI winter and the drift of technology towards other paradigms have almost lead to forgetting Lisp alltogether; IT has only recently started to rediscover parts of what made Lisp so cool back then.
Permalink for comment 342468
To read all comments associated with this story, please click here.
Member since:

The IDE and tool chain part is the easy part, really. If you have some clean code in lisp that translates into a mess in java, then you should use lisp, because managing an IDE and installing a tool chain for lisp is nothing when compared to debugging messy code: THAT is the hard part, and the bigger the code, the harder it gets. For small programs, it's ok to use a random language, but when your programs have more than 100 000 lines of code, you better choose the right language, no matter how hard it is to install an IDE. When you have more than 1 million lines of code, you spend less time learning a new language and reading clean code than reading bad code in the language you know best. When the code gets really big, even writting a new language from scratch is easier than using a less than perfect language for your project.

Edited 2009-01-06 14:01 UTC

Reply Parent Score: 1