|
StanleyKnutson.com |
||||
|
Navigation |
"Higher Order Thinking"There are some approaches to writing programs that can greatly simplify complex problems. These include:
It so happens that lisp has been providing these capabilities for many years. Other tools [like C++] can't do them at all. Java is beginning to offer these capabilities, but use of them is not easy. Many of the things I've done with Lisp as part of the ICAD system would be simply too hard to do in other languages. Functional ProgrammingThe concept of functional programming is pretty simple: make the majority of the application be non-procedural, so each function can be called to return a result, without any side effects. Properly applied, functional programming greatly simplifies large systems and enhances maintainability of code. See this description of functional programming that has a list of resources. Lisp vs. other languagesThe ICAD product is written in lisp. I've worked with many programming languages, but lisp is still my favorite. Lisp simplifies creation of higher-order functions, and makes it easier to apply functional programming techniques. Both of these ways of thinking are much more important than lisp as a language. Having written large projects (more than 10,000 lines of code) in six different programming languages, I can safely say my experience is productivity in Lisp is 3 to 10x that of other languages. This is a big win. Some tasks that we did at KTI in just 100 or so lines of lisp code would take 300 or even 1000 lines in other languages. I remember one specific application where the lisp code was 2 lines, but the Java equivalent was 115 lines! More important is the dynamic environment provided by lisp reduces time needed for experiments and bug fixes. Other tools I've used require re-starting the application for each change the application code, which means 30 seconds to several minutes (or even hours) lost for each change or experiment in implementation. Now Java is useful and the portability between UNIX and Windows is a win. Its automatic memory management solves one of the big problems of C++. However, Lisp is still much better and easier to use. The lisp KTI uses [From Franz Inc.] has an integrated debugger that allows any kind of modification to the running code, even while the code is stopped at a breakpoint. This is a major improvement: if it takes two minutes to get to the error, in Lisp, you can inspect things, alter the code, and restart the function. Java and C++ just don't allow that. The net result is the bug can be fixed and done in 2.5 minutes If the first fix does not work, try again: another 30 seconds to try it, and you're done. In C++, you have modify the code, recompile, link and restart, and rerun the two minutes to see if that fixed it. So it does not fix it, try again, another 3 minutes to run the test. Elapsed time: 3 tries through the process: 9 minutes in C++ vs. 3 minutes in lisp. Combined with Lisp needing only 1/4 the lines of code [hence 1/4 the bugs], and the result is amazing productivity. Microsoft .NET might be approaching the productivity of the lisp environment, I've not yet used it. I'm looking for work, and will use whatever language is appropriate (most commonly Java or Perl these days). In particular lisp is particularly weak in available libraries. Perl, java and python all have sizable existing open-source libraries that are relevant to today's issues. The available lisp libraries are more complex algorithms, but lack some of the necessary bits for today. An example is web services (SOAP over HTTP), which is readily available in java, but does not exist in lisp as of 2002. Eventually I'll write a bit of side-by-side comparison. The Association of Lisp Users and Franz have some of that kind of information already. |
|||