[santu11]

I am a intermediate programmer with just over one year experience.

Everywhere I read about the power of lisp and really want to use it. If it is so good why ain't it is used more?

It is very easy to get sites running using ASP .NET, wordpress, RoR or Django. I have worked on production sites using the first two. And personally tried on small projects on the last two.

Is there a way to use Lisp professionally?

[muuh-gnu]

> If it is so good why ain't it is used more?

* Weird syntax (for most people).

* No free implementations existed during a key period (80s, 90s) so no initial traction, no useful libraries and killer apps which would pull the whole ecosystem. Implementations didnt even exist for commodity hardware.

* The commercial implementations cost too much, so they suffocated the ecosystem. People preferred coding for free in C or Perl, than paying an arm and a leg for Lisp. So they wrote all the useful libs in C, Perl, Java and Python instead of Lisp.

* No canonical implementation, late and incomplete standardisation, which led to extreme fragmentation, which further killed off the growth of the ecosystem. Instead of writing useful libraries, Lispers wasted effort writing 1001 incompatible implementations of the same basic system.

So to summarize, I'd say the Lisp ecosystem is _still_ suffering the consequences of the bad strategic decisions made 30-40 years ago.

But it is slowly but steadily healing and improving, especially the last few years. It has a high-quality free implementation with SBCL [1], consolidated CPAN-like library management with Quicklisp [2] and a IDE with Emacs-based SLIME [3]. Everything is getting better.

[1] http://www.sbcl.org/

[2] http://www.quicklisp.org/beta/

[3] http://common-lisp.net/project/slime/

[mseebach]

To take the reverse perspective, why it is coming up now, I think that in the 80s and 90s, the increase in processing power came in the form of faster processors. Then, pretty suddenly, really, over the past decade, that trend hit a wall, and instead we're getting more cores, but at the same speed. This rekindled the interest in concurrent programming, and Lisps have a distinctive edge in that space.

[xradionut]

Add in the flame wars and jerks on Usenet that crapped on many folks that were interested. People went off in search of friendly enivironments and ended up in C, Perl and Python...

[lazyjones]

> * No free implementations existed during a key period (80s, 90s) so no initial traction, no useful libraries and killer apps which would pull the whole ecosystem. Implementations didnt even exist for commodity hardware.

Emacs LISP (OK, a limited dialect) was available and so was CMUCL (full implementation), which I believe was used for teaching in 1992 when I first got in contact with LISP at our uni ...

Also, back then (80's and 90's) most people still paid an arm and a leg for C, Modula and Pascal on their platforms, so that can't have been an issue. My take is that LISP implementations were too slow to justify their use for most people over faster compiled languages. Whether you paid for the language or not, you expected to be able to get the most out of your hardware.

[colomon]

I used LISP for several AI classes in the early 90s. My final big class project could do things that were impressive compared to my (non-AI) programs in C++ -- but debugging was absolute hell, because relatively trivial changes would cause the Unix workstation I was working on to run out of stack space running my code. I never used LISP again after that.

[chimeracoder]

> faster compiled languages

Lisp is a compiled language.

For that matter, it's a damn fast one, too. The Lisp implementation of PCREs are actually faster than Perl's, by some benchmarks.

I don't want to start a tangent about benchmarks and their relevance, but it's clear that Lisp performance isn't a limiting factor.

[fusiongyro]

Whenever Lisp's history is mentioned we get another free replay of this classic "who's on first" bit:

A: Lisp didn't succeed in part because it was slow

B: What? Lisp isn't slow!

Do you see the problem? No, it isn't slow now, but it was slow and a resource hog and that is a legitimate variable that may have negatively affected uptake during key points in its history. Times have changed, implementations have improved, resources have become less scarce, but the past is still the past.

[lazyjones]

C is still faster at common tasks and back then, code from readily available C and Pascal compilers was much faster than CMUCL or ELISP (both had a bytecode interpreter only AFAIR). My point is that in the 80s and 90s, computers were much slower and a factor of 2 was a big deal then, especially for professional developers who had to write well-performing applications, though nowdays a good language is "fast enough" if it's only half as fast as C.

[lispm]

cmucl has native code generation for a VERY long time.

[lispm]

> IDE with Emacs-based SLIME

That's also not new. Common Lisp has an Emacs IDE since before the dark ages. It was called ILISP. Every Lisp + Emacs user was using it. Well, Franz had/has their own Emacs interface called ELI.

[lispm]

> No free implementations existed during a key period

BS.

CMUCL. AKCL. CLISP.

[muuh-gnu]

OK, let me correct myself: No competitive free implementation existed able to take a leading position and bootstrap the ecosystem, like gcc, cpython, perl and javac did for their respective language ecosystems.

I did not intend to imply that nothing. existed. whatsoever. cmucl, gcl (akcl) and clisp even today are insignificant also-rans and basically unmaintained abandonware.

[lispm]

CMUCL was from the start very significant.

DEC Common Lisp was based on CMUCL. LispWorks was based on CMUCL. Scieneer Common Lisp is also based on CMUCL.

SBCL is a fork of CMUCL. SBCL is very popular in the 'free software' Lisp community - it's just a repackaged CMUCL.

Lot's of other Lisp implementations took and still are taking code from CMUCL, since it is 'Public Domain'. Free software.

Btw., CMUCL still has monthly releases.

AKCL spawned several implementations. Including GNU Common Lisp (GCL), which was widely used for some time - in combination with GCC.

GCL has been long used to run Maxima, the free version of Macsyma.

AKCL/GCL is nowadays ECL. Another fork. Which is maintained until today. Again ECL is possible because GCL was Free Software.

[JabavuAdams]

The paradox of choice.

One implementation that's good for 80% of users will gain more traction than 10 implementations where each user has to figure out which one to use.

Lisp attracts maximizers, while satisficers are more successful at delivering software to real people.

[lispm]

> No competitive free implementation existed able to take a leading position and bootstrap the ecosystem, like gcc, cpython, perl and javac did for their respective language ecosystems.

it was never a goal in the Lisp community to develop a single unified or leading implementation. This has nothing to do with 'free software' or not.

[randallsquared]

"it was never a goal in the Lisp community to develop a single unified or leading implementation"

...and that's one reason it hasn't ever achieved critical mass: it's so easy to write software that only works on one implementation that the various CLs effectively compete with each other on the same level that each is competing with other rapid development languages. It wasn't CL vs Python vs PHP, but instead CMUCL vs Python vs SBCL vs Lispworks vs PHP vs Allegro. Scheme has a similar problem. These are the problems that come from having a standard instead of a canonical implementation, in my opinion. Canonical implementations promote growth in a way that a standard for a language doesn't.

[lispm]

Yeah, and Python competes against Ruby against Perl against Javascript against Python 3 against Perl 6. Without sharing any code. And you win almost nothing. CPython, Perl, Ruby, ... are all slow scripting languages. With the newest implementation, Ruby, being the slowest programming language of all.

CL implementations can share a lot of code.

I've just compiled Mark Tarver's Shen in another Lisp by just changing less than ten lines of code. It took me ten minutes.

[spacemanaki]

I've struggled with various Scheme programs not working in different implementations (mostly code from books like Lisp in Small Pieces) and have heard plenty about the fragmented Scheme landscape, but is this really such a big problem with Common Lisp? And is/was that really a big reason why Lisp has failed to catch on? (being genuine here, I have no idea really about the history and have only use CL a bit)

It seems to me that there are plenty of more popular languages with a similar glut of implementations: there are multiple JVM vendors, multiple implementations of Java (Sun/Oracle and now Dalvik, ...), many C and C++ compilers, etc...

This is total speculation, but it is perhaps because things like threads and networking were not part of the Common Lisp standard that there are fragmentation issues that impeded adoption? Or do you still think that canonical implementation vs language standard is that much better, in almost all cases?

[jjwiseman]

In 2002 I was trying to use free Lisps in production and finding it untenable due to serious bugs in fundamental areas like network sockets, and terrible support for threads. I was also surprised that implementors didn't seem to take these issues seriously.

It was very disappointing compared to my experience using commercial Lisps like Allegro Common Lisp and Macintosh Common Lisp in grad school in the mid 90s. They weren't perfect, but MCL on a machine with lots of memory was a pleasure I will always remember.

[arethuza]

I was paid to develop in Lisp (in a research environment) from '89 to '95 and from what I recall the commercial Lisp environments were way better than the free implementations - at least on the hardware we used (Sun 3s, Sun 4s and the DEC Alphas).

[lispm]

That's still true - for various criteria.

[cturner]

    > If it is so good why ain't it is used more?

My guess is that it's hard to create well-gelled lisp programming teams.

If you're using Java or C#, there are certain ways of going about things, and there's general consensus about this. You can pick up Java code that is written by someone you've never met and have a pretty good idea of being able to work out what's going on.

Something similar with python: whitespace forces a lot of style, and it's backed up by the style guide.

Whereas lisp is completely open-ended. Want to run a large system built entirely from lists? Fine. Want to build an object system tinted by your weird philosophies? Fine. Want to create sophisticated self-modifying code? Fine.

It's a worse version of a problem you have with C++, finding a common subset of things that the team will stick to (or only hiring gurus who are interested in all the quirks and who know the history).

Style arguments within teams are draining, but you need to have commonality to be able to work as a team.

Clojure has some edge here for weird reasons. It discourages recursive techniques because of limitations in the JVM. And, if you're going to be interacting with libraries from other parts of Java, you probably don't want to be acting as funky as you might be tempted to otherwise.

[cgag]

I'm coming from a Clojure perspective (around a year of using it), so maybe some of this stuff is different with CL, but Clojure is incredibly simple compared to C++ and in my experience there's no problem with everyone simply using the entire language.

I've read a decent amount of Clojure source, since documentation is admittedly a problem with a lot of libraries, but it's the language I've found actually easiest to read. The Clojure way of going about things is to pass around and manipulate simple immutable data structures, which I find easier to understand than large class hierarchies. Macros are usually used for creating DSLs or removing simple boilerplate, which leads to smaller, easier to understand code bases in my experience, rather than implementing custom object systems or something like that.

I don't think Clojure really discourages recursion so much as it lets you avoid using it explicitly by providing a good standard library, but many of the standard lib functions are themselves written recursively.

Anyway this was all in response to why isn't it used more. I don't really have a good answer for that, but a lot of it comes to from people being weirded out from its simple syntax, and also not wanting to learn to think functionally. It is being used though, the most successful Clojure example I can think of off the top of my head is Storm, which is usually billed as a Hadoop for realtime processing, and it's being used at a lot of large companies: http://storm-project.net/

[cturner]

The books I learnt lisp from emphasised recursion early, and were taught from a perspective of emphasising the power of the language and tricks available to programmers. This approach encourages arcana, similar to bit-shifting tricks you'd find in C books like _Hacker's Delight_ (Warren). Through lisp macros (present in Clojure), you can create your own sub-language.

So merely through the absence of this emphasis on expressive power, Clojure is a bit different. And I think that's great. I might be using Clojure at the moment, except I need to be able to make native builds for the project I'm working on, and so I went with Racket.

Yeah, people are weirded out by the syntax as well. Which is sad, because people who are used to it tend to love it. But if this was the only problem, it could have been easily bypassed decades ago with a whitespace alternative. That is, where developers would be able to denote blocks with python-style whitespace and colons as an alternative to parens. Last time I mentioned this someone pointed me to a distribution of arc that already did it.

    > many of the standard lib functions are themselves
    > written recursively

Maybe the JVM has been updated while I wasn't looking and no longer has a problem with deep recursion. What are some stdlib functions that are recursive?

[cgag]

The JVM still doesn't do tail call optimization but Clojure has a special form, recur, that you can only use in tail position and doesn't use consume stack space. An example: https://gist.github.com/4493547 (loop is like let but works with recur).

A simple one from the standard lib is last: https://github.com/clojure/clojure/blob/master/src/clj/cloju...

[dizzystar]

Here's one bank that is blogging about moving to Clojure: http://www.pitheringabout.com/?p=778

It is used in a few places, but its not common. The reason it isn't used often is because no one bothered to build anything with it. So, if Clojure / Lisp / etc want to make the language popular, you should build something that makes money and tell the world about it. This is what happened with RoR and Django.

I have a CRUD site written in Clojure. All total is around 1,500 LOC. I only have to add in a mailing feature and and one other small operation and take it off the now-deprecated Noir framework. All told, it will still be 1,500 LOC, I think. It takes in quite a bit of information, has multiple "views," dynamically generates HTML, connects to a database, and allows quite a few unique operations, so it's actually very easy to create a website in Clojure, and it can be highly elegant once you get used to the data structures and how to destructure.

The Clojure community has done an excellent job to make the process of building -> deployment very easy, it's just that no one has stepped up to the plate and did anything with the tools, and unfortunately, I fear Lisp will always be a Land of Toys and No Product Shipped.

[meric]

Do the 1500 LOC include markup, script and css?

[dizzystar]

I used Twitter Bootstrap for the CSS...

The 1500 LOC is only Clojure. I could probably dump off 300 if I wanted to.

[gnosis]

"Everywhere I read about the power of lisp and really want to use it. If it is so good why ain't it is used more?"

In a sense, people are using it more. A lot of features that Lisp pioneered and that used to be radical back in the day (like built-in garbage collection, lambdas, first-class functions, etc) have now been assimilated in to other languages.

As a result, many Lispish things are now pretty mainstream. Not everything about Lisp has caught on, though (yet). In particular, many people are still averse to Lisp's syntax (or lack thereof), and its many parenthesis. Because of this, they're missing out on some of Lisp's most powerful features (lack of syntax and parenthesis are features, as is Lisp's very simple macro system).

Also, a lot of people have a pretty skewed, outdated view of Lisp, often based on rumors of a bad experience with some crippled Lisp they were forced to learn in school.

Very few people who have a very negative impression of Lisp have had much experience with a modern, full-featured implementation of Common Lisp (like SBCL), or Scheme (such as Chicken or Racket).

Those that have quite frequenly describe their experience with them as enlightening and often wish they could use Lisp/Scheme on their day job.

[bitdiddle]

for sure, what folks complain about the most (syntax) is where it's power is.

I've been getting Guile recently and find the very tight integration with C to quite nice. It's like the best of both worlds

[gnosis]

When I first learned Lisp, I quickly got to the point where I "don't even see the parenthesis". Shortly after that I learned to love them, and see them (and Lisp's simple syntax as a great strength).

Now extraneous syntax, even in a half-Lisp like Clojure, seems ugly to me. It's a real pity more people don't appreciate the elegant simplicity of Lisp (and especially Scheme).

[firepoet]

Just a curiosity -- why do you call Clojure a "half-Lisp?"

[Munksgaard]

Not me, but I would guess it's because, while both Common Lisp (ie. SBCL) and Clojure are both Lisp-like languages per se, Clojure departs further from "pure" Lisp than Common Lisp, in that it replaces lists with things such as vectors in a lot of places (see defn syntax).

[jhuni]

It could also be that it is hosted on the JVM.

[Jach]

Geometric Algebra is really cool and powerful and good, why isn't it used more? The best things aren't often the most popular ones. (And in a practical business setting, the best is often the enemy of the good enough as well as the better. You get the circular cause problem because Lisp isn't mainstream, so most programmers will not know it, and will be faced with the decision to learn it or go with what they know.)

[cgag]

Clojure is very capable for web development, but getting started is not as clear cut as it is with something like Rails or Django. This is because the Clojure community tends to eschew large frameworks, and instead prefers using smaller, more focused libraries. This provides a lot of flexibility, but is intimidating at first because it requires you to choose your own libraries for routing, db interaction, templating, etc.

Everything is to be built on top of Ring, which is the Clojure equivalent of Rack or WSGI. Compojure is pretty much the standard for routing at the moment. Korma is a very popular DSL for writing SQL. For templating, Hiccup and Enlive are popular, but there are other options as well.

I would start off by getting a decent understanding of Ring and Compojure and building from there.

--

https://github.com/ring-clojure/ring

https://github.com/weavejester/compojure

https://github.com/weavejester/hiccup

https://github.com/cgrand/enlive

http://sqlkorma.com/

http://www.clojure-toolbox.com/ is really helpful for finding appropriate libraries.

[mark_l_watson]

I do a lot of web development in Clojure using Noir, Compojure, Hiccup, etc.

I find this setup similar to using Ruby + Sinatra.

I still keep up to speed with Rails versions, etc., but in the last year almost all of my web development has been with either Clojure or Ruby + Sinatra.

[JeanPierre]

    If it is so good why ain't it is used more?

pg has written about this [1], and the main reason he found was that popularity is always self-perpetuating. If one of the languages get a head start with libraries, it's usually easier to develop programs and libraries within this language than other languages. If you know a popular language, you're more likely to have more job opportunities. If you're a manager, you would prefer to be able to replace programmers easily.

That's one of the reasons why Clojure started off on the JVM in the first place: It has libraries and an already thriving ecosystem. In addition, it's a nice bonus for language developers to not have to worry about performance related to GCing, threading, OS-specific differences etc, which the JVM abstracts away.

[1]: http://paulgraham.com/iflisp.html

[toolslive]

> If it is so good why ain't it is used more?

I'm too pessimistic, but there is almost no correlation between quality and frequency as far as programming languages are concerned. Reasons for that are legio.

[lispm]

For many things you won't even know that it is written in some kind of Lisp.

* the first Gulf War in Iraq was won because a Lisp application took care that US soldiers had everything from toilet paper, ammunition to gasoline. Plus it took care that the troops were at the right place.

* the missions of various Telescopes, especially the Hubble Space Telescope are planned with a Lisp-based planner

* American Express has been checking complex business card transactions with a Lisp-based rule system

* many cars (Ford, Jaguar, ...) were designed using a Lisp-based design software developed by Evans & Sutherland

* turbines for various airplanes were designed in Lisp (Boeing, Airbus, ...)

Some of that stuff survived. Some not.

But still today, if you see product descriptions like this, you would not suspect that it is written mainly in Lisp, but it is:

http://www.ptc.com/product/creo-elements-direct/modeling/

[pretoriusB]

>the first Gulf War in Iraq was won because a Lisp application took care that US soldiers had everything from toilet paper, ammunition to gasoline.

Really? Because IIRC it was won because it was fought by superpower against a small country with 1/1000 the military resources.

I'm not talking politics in this comment. What I mean to say is it's another thing to say "Lisp was used in that system" and totally another to say "the war was won because of it".

There is a big possibility that there was absolutely no correlation between what that language that system was written on and the war being won (and is far more likely, anyway: wars have been won, before and after, without Lisp).

Lot's of NASA missions use plain old C and do just fine. Should we say that they succeeded "because of" C?

[lispm]

Basically they had to wait for the Iraq invasion until the Lisp software was ready.

> Because IIRC it was won because it was fought by superpower against a small country with 1/1000 the military resources.

The Lisp software moved the 1000* military resources to Iraq.

[mturmon]

Software does not move tanks. It's one part of an overall system that moves tanks. You over-reached on that point; it happens.

[lispm]

Software moves fleets. Coordinates ten of thousands flights. Make sure that hundred thousands soldiers have supplies.

It's called logistics.

It's a new world.

It happened.

It's been said that this single piece of software paid back for all DoD AI research.

[jgeralnik]

Just because supposedly a piece of software performing a critical purpose was written in lisp does not mean lisp won the war.

If the software wasn't written in lisp, it would have been written in any other language.

And if the software wasn't written at all there would have been hundreds of people doing the software's work manually instead.

Did the software help? Probably. It's likely there would have been more screw ups if there was no software. But it takes a big leap to credit the software with winning the war.

[pretoriusB]

May I propose the alternative explanation that you are overstating the case for Lisp and this software, because you just happen to like Lisp? I mean, look at your HN alias.

That particular software could have been written in any bloody language. Logistics is one of the more boring areas of software engineering anyway -- and the majority of it in the world runs in Cobol, Java and similar boring languages, just like most of the banking world runs.

Plus, it's not like the US army haven't made a mess with war logistics. How much did the Iraq war cost to the country again?

[JabavuAdams]

Productivity is about language + libraries + frameworks + community + your own familiarity with all of the above. The language is really the least concern when actually delivering features in a timely manner.

Programming is a high-variance activity. It's not that some programmers are 10x faster than others -- it's that an individual programmer may have 10x variance in performance on different days/weeks.

So, the two most effective things a programmer can do to become more productive are: (1) Get enough sleep. (2) Don't write code -- use libraries.

To the extent that Lisp's meta-programming support can help with (2), it's useful, but usually the lack of discoverable, minimalist, production-tested libraries is a worse tradeoff.

Essentially, the other ecosystems are good enough, and the Lisp ecosystem is not great for the bang-out-10-features-today style of most app development.

[smartial_arts]

I am not too sure about Lisp in particular (especially there's at least few dialects of it, afaik) but I am currently looking into Clojure and, apart from bending my brain, tossing it into a rubbish bin then fetching and putting it back in, I like it very much.

Also, there's a Noir [1] framework build on top of it.

[1] http://www.webnoir.org/

[jonahkagan]

Apparently Noir is deprecated in favor of Compojure, according to http://news.ycombinator.com/item?id=5027560.

[DigitalJack]

I was surprised to hear this, but it's true: http://blog.raynes.me/blog/2012/12/13/moving-away-from-noir/

[Sandman]

Noir lives on through lib-noir [1]. I also suggest checking out Luminus [2].

[1] https://github.com/noir-clojure/lib-noir

[2] http://www.luminusweb.net/

[mseebach]

Here's a good tutorial on how to do web development in Clojure. No, it's not as "batteries included" as Rails, but I found the learning curve pretty gentle.

http://www.vijaykiran.com/2012/01/11/web-application-develop...

Once you have a Ring-based Clojure web-app, you can run it as any other Java Servlet app, eg. in Heroku.

[bane]

http://blog.reddit.com/2005/12/on-lisp.html

[deltasquared]

Well if you want to use common lisp to make a web page, Conrad Barski(who drew the OP comic) has a guide here: http://lisperati.com/quick.html

[akx]

Heads up - that's circa 2004.

[falcolas]

> If it is so good why ain't it is used more?

Speaking just for myself, it's because most commonly available distributions (such as SLIME) require you to learn a new editor on top of learning a new language.

I think emacs is great, but it's not my editor of choice, and when a language distribution all but requires you to use emacs, it's going to have a hard time gaining traction with me.

This may have changed over the past few years, but it certainly stopped me from learning Lisp some 10 odd years ago.

[wglb]

There is slime for VI. And Paul Graham and team used VI and clisp to build the store software--no IDE.

If you read Coders At Work http://codersatwork.com/ the grown-ups don't use IDEs.

[falcolas]

Ignoring the condescending remark for now, it probably was possible to run lisp without Emacs, but none of the tutorials mentioned how. They all pointed towards Emacs.

If I recall correctly, one tutorial (and several IRC lispers) even stated the following: "How do I use this with vim? Just use Emacs + SLIME, you'll be better off for it."

It's probably changed (at least I certainly hope it has), but it certainly hampered my adoption of lisp.

[klibertp]

It didn't change last time I checked - Emacs is still almost mandatory for almost all tutorials on Lisps (I searched for beginner tutorial for Clojure about half a year ago). I find this attitude stupid too. Emacs is a great editor, not to mention operating system, but I just don't like it and I feel that I have the right to do so. It shouldn't be too costly to list the alternatives and help with getting expected functionality in other environments.

This was never really an issue for me though, because I was lucky enough to start my adventure with Lisps from Racket and it's excelent IDE, DrRacket. I then used it with other Lisps, because I was already familiar with it and adding some keywords (well, names - for indentation purposes) was trivial. I didn't use them (other Lisps) long enough to be seriously irritated by the lack of built-in repl, so obviously YMMV - but I would recommend DrRacket as low-entry-barrier alternative to Emacs for Lisps editor - it handles parentheses rather well :)

[falcolas]

Good information, thank you.

[klibertp]

Well, I work solely with VIM now, but I have worked with Visual C++ 6.0 in the past and later with Zend Studio 5 & 6 version and then with Komodo IDE. I never touched Java, but I briefly came back to Visual Studio when doing some projects in C# and then when learning F#. There's also DrRacket, formerly DrScheme, an IDE for Racket, which I use sometimes and love (I used it instead of Emacs for other Lisps too btw). Ok, to the point: you are wrong.

Take my VIM for example, which I use for Python and (Java|Coffee)Script development (along with Erlang and a few other languages for hobby projects). I have a file list/tree/browser with NERDTree. I have a list of classes and functions in currently opened files with TagBar. I have "go to definition" and "display help/docstring" through Rope, along with four different auto-completion modes (partially built in, enhanced with SuperTab and a few other plugins, including Rope). Similarly I have support for refactoring from it. I have "find in files (quickly)". I have "fuzzy file name matcher" with Command-T. I have three different linters for Python. I have access to git log, blame, status, add and everything else with fugitive and diff is pretty, side-by-side one thanks to vimdiff. I can open remote files easily (this is built in). I have a bar with snippets (with placeholders I can fill in when pasted, of course) with SnipMate. I can open command line (like bash, ipython or coffee) in a window or tab with Conque. I can easily evaluate bits of code thanks to IPython (and thanks to their recent refactor, it's really paying off!). I use zencoding when I have to write HTML structure. And these are just things I use most often.

Now, I use VIM, which, I assume, means to you that I don't use an IDE - but what is the difference between, say, Komodo IDE and my VIM (aside from my vim being able to display in the console) really? It's IDE all the way down to unix shell and all the way up to git integration... And I'm old enough to be called a "grown up". Of course, I assembled my IDE myself from pre-made and some custom components, but it's IDE nonetheless.

The thing is that IDEs are there for a reason. Every single feature I mentioned above is a timesaver to greater or lesser extent. Every one of them increases my productivity in some common situation - and we're talking about Python and back-end (mostly) web-development here, which has much less repetitive, tedious tasks than, say, writing MFC app in C++.

Anyway, if you want to program in Notepad - feel free. Just don't, really don't, try to convince anyone to do the same by saying that notepad is somehow superior to Visual Studio for programming. It isn't. You'll understand this when you have to immediately fix a bug in production code on the server with something like nano, joe or mcedit and you introduce three other errors in trying to do so due to unbalanced parens, messed up indentation and a huge number of other issues that IDEs (yes, VIM included) protect you against. Well, I guess you need to grow up first to get access to that production code, I mean afterwards ;)

[lukego]

Check out Lispjobs. http://lispjobs.wordpress.com

[martinced]

"If it is so good why ain't it is used more?"

You know that Hacker News was created by Paul Graham right?

You definitely do want to read Paul Graham's essays.