Monday, August 13, 2007

LISP Cycles

I admit it, I like LISP. There are a certain set of programming problems that it handles elegantly. I feel the same about AWK, BASH, SQL and even JAVA. Each language has a sweet spot, that domain of problems it is well suited to solve. While other languages can address the issue, some are more painful than others. My "perfect world of programming": Allow the programmer to solve the problem using the correct tool. That is, remove the "If all you have is a hammer, everything looks like a nail" attitude. I am sick to death of OR mapping in Java, as an example. If there were some way to build pieces using the proper tool and then combine them into a complete solution. See SEWER.


TMadden said...

Ah, Star Wars: A New Hope. Is there no end to the paraphrases and quotes you provide? (My favorite is still "I find your lack of faith disturbing").

I overheard an interesting conversation the other day. The VP was complaining that the JAVA code was having so many problems, and the C code was working great. The analysis left out the fact there are only one tenth as many changes in the C code as the JAVA, because the JAVA code took those over from the C. Only one programmer works on the C code, versus 10 on the JAVA. I think the problems would exist on the C side if all of the coding was done there.

Your "perfect world of programming" doesn't work with the attitude of most management and developers. Management wants the 'one size fits all' solution, and the cogs in the process to be easily replaceable. Developers often hate languages they only have limited exposer to. I've lost track of how many times I've heard '.NET sucks' and 'JAVA sucks.' 'C++ is too complex and error prone'. 'You work with LISP?!? That's ancient!' And on and on.

Finally, there's a trap. Work on a elegant and simple solution to problem, and YOU get to maintain it for the next decade.


Matt said...

I have been working on my basement, you should drop by and see it. The number and type of tools I have been using has been surprising. Having the proper tool for the job makes for a better final product.

Consider the task of attaching the bottom plate of the wall to the concrete floor. There are several ways to do this including using a hammer and chisel or drilling a hole in the cement with a special drill and hoping you got it in the right place. There is also a tool called a "stud nailer" that uses .22 caliber shells to shoot the nails through the wood and into the cement. Saves time, no worrying about where to drill the holes and it makes the place smell like gunpowder. Guess which one I chose. Using the proper tool for the job.

Management usually does not care all that much about how it gets done, just that it get done. They do care that, were the developer to be hit by that proverbial bus, another person be able to maintain the code. Were developers to adopt the attitude of "use the best tool for the job" the maintenance issue goes away. All developers would be skilled in a set of tools, just as a builder must be skilled in many different tools. Indeed, because the right set of tools was used to complete the job, the system would be more stable and easier to maintain. Even if the maintainer has to learn a new set of tools as part of the job.

The problem then lies with the developers. We need to break out of the confines of all our prejudices and start thinking "what is the best tool to solve this problem" rather than "how can I solve this problem with [insert favorite language here]".

It also might mean you have a job for the next 10 years.