Page 1 of 1

Whats your view of Lisp in the large picture?

PostPosted: Wed Sep 07, 2011 12:15 pm
by adam33147
I have programmed in Turbo Pascal, Basic, Visual Basic, Java, C, and Common Lisp (not that I got good at any of them). I would say that Lisp blows them all away in terms of thinking about a program through the tools of a progamming language. Its funny that when I talk to programmers trained on more popular language breeds, they can be either mystified by what I can accomplish, or annoyed by how I would accomplish something (Dont you know the standard? Your overcomplicating things, we dont need a server for this, just a command <that coincidentally might run a client to a program that runs on a local server>). There are different ways to the top of a mountain, so Im not saying that Lisp in an all powerfull abstraction of perfection. Far from it. Further, a project has good reason to keep itself compartmentalized to a language, mainly maintainability.

With Lisp, when I want to implement something that integrates with a system, I study the system, do exploratory programing, and really figure out how things work. I find that the main architecture of some of my more ambitious Lisp projects require accessing outside programs, so one of the topic I find interesting is IPC, perhaps born out of necessity. With PHP, I would look on the internet for the program that does the thing that I want and tweak it. Perhaps the power of Lisps core gives a fighting chance in these circumstances.

Another important point is that it is relatively hard to find Lisp programmers. This could be considered either a benefit (strategic advantage), or a cost (must overcome bigger hurdles for cooperative efforts).

I think its important to look at the advantages and disadvantages of using Lisp as a primary technology. Further, I think the disadvantages might be like opportunities in disguise. For example, using Lisp, you can design programs that could integrate with any another programming Language seemlessly (from a programmers perspective, maybe not from a system admin's perspective though).

This perspective is based on my very limited experience, and I am very curious about how experience guides in thinking about this topic. Im sure we all have alot to learn from eachother.

Re: Whats your view of Lisp in the large picture?

PostPosted: Fri Sep 09, 2011 11:14 am
by saulgoode
I would break the big picture down into three different parts.

There are the Algol-like imperative languages in which the main paradigm is to pass arguments to a function. Then there is the Lisp family where functions are applied to a set of arguments. And then there are the object-oriented languages where a function (method) belongs to an argument (object) and that function can also have other arguments passed to it.

While based on that simplified characterization, there would seem to be little more than a semantic distinction between the first two, I would be preaching to the choir here in pointing out that the impact on programming can be huge (and, after all, semantics is at the core of the very concept of programming).

The ramification of thinking of your program in terms of passing your data as arguments to various function and procedures (in languages such as C, Pascal, and Ada) is that the elegance of your program is dictated largely by how well you've designed your data structures. For the most part, this elegance (if it exists) stems more from how well the data structures fit the functional APIs than how well they match the real-world entities they represent. This generally makes these languages well-suited for tasks involving "core level" hardware interaction and efficient mathematical computation but not so much for the meaningful abstraction of real-world processes.

With the Lisp approach, the programmer is offered complete freedom to abstract not only the data but the operations on the data themselves. At every level of the program, the semantics of the language support the ability to structure the flow of your code without worrying about either the implementation of the data being manipulated or how that data has been or is going to manipulated.

I don't have much affinity for OO languages; it just seems like arbitrary constraints placed on functional programming for the sake of conformity. It is admittedly a useful paradigm suitable for many situations, but when all programming tasks have to be forced into the OO model, you end up with code whose actual structure is scattered all over the place and a complete disjunction between what the code states and what it actually does.