That's something I think I still need to learn. Typically I haven't realized a language's weaknesses until I tried to do something in it where it does just an OK job.

Sometimes practicality intrudes as well. Last year I was working on trying to improve the install process for a Win32 app. It would've been much easier for me to do this using a .Net DLL. The API for what I needed to do would've been very simple. The problem was the client didn't have the .Net Framework installed on their machines, and I knew there was no way they were going to install it just for the install process. So I "dropped down" into native C code to do the same thing. I created a nice compact DLL. I think it was around 30K. Barely noticeable. It was harder to write than the .Net equivalent, but it got the job done effectively and without the customer having to change their system configuration.

The reason I got into this at all was due to some articles I read on Lisp. Paul Graham wrote an essay on his web site (www.paulgraham.com), called "Beating the Averages" that really impressed me. It's the first article I think I've ever seen where a programmer/entreprenuer attributed his competitive advantage and success to a *programming language*, Lisp. Graham is probably biased, but he said that he considers Lisp to be the most powerful programming language out there.

Up to that point, I knew there were some languages that were ill-suited to a task and wouldn't work out, and there were ones that could slow you down some if used for certain things, but I had never heard of a language being a critical factor in a business's success. Further, Paul G., Eric Raymond (someone who I hardly ever read), and I think Joel Spolsky as well said that Lisp is a good, enriching language to learn, even if you never use it on a real world project. Basically they said that by using it, you'll learn new ways of programming that you did not know were possible. It'll make you a better programmer. You can bring those skills, even without Lisp, into your projects. Plus, I was reading good things (quotes, anyway) about this language from all sorts of sources, like Dr. Edsgar Dijkstra (who rarely endorsed a programming language), and Phil Greenspun. So I thought it was worth diving back into it and giving it another chance.

The one weakness that languages like Lisp and Smalltalk probably have is lack of external support. It's just easier to accomplish some tasks with more mainstream languages, because it's easy to find libraries online, or ones you can buy, that support them and do just what you need, whereas in the minority languages you might have to write the code for it yourself. This would probably be fun to do, if you have the time for it (that's a big "if").

The popular OSS languages like PHP, Perl, and Ruby probably have sufficient support to where this isn't a problem. It seems that way with Ruby, anyway.

Another potential weakness is it's easy to write "write-only" code. In other words, code that made sense at the time, but if you come back later and try to modify it...good luck! I think this comes from the fact that these languages are so dynamic. They use dynamic typing, and it's possible to generate code dynamically, a common tactic in Lisp.

Dynamic typing is a strength and a potential weakness. On the one hand it makes code more expressive, because you can express your intent without getting into what type something is. The problem can come in (I've had a bit of this experience) when you come back later and try to add to what you wrote before. It's easy to forget what types were assigned to which variables, and therefore how to use them in new code. So I consider variable documentation as essential in this situation.

Dynamic code generation (macros in Lisp) is a way to solve some thorny problems, I'm sure, but I think even Paul Graham acknowledged that it can get to the point where it's extremely difficult to decipher how those things operate, especially for a new programmer being added to a team. Again, it may have made sense at the time they were put in. So overall, documentation becomes even more important than it used to be.

Lastly, I've heard recently that with dynamic languages it *really* helps to use TDD with your code. You could probably get away with not doing this in past projects using other languages, but apparently you're just asking for trouble if you don't do this with dynamic languages. Maybe it has to do with what I talked about above.