A Function of Life
The reason I started this blog, was to document my exploration into LISP. It's basically a programming language, and is the second oldest programming language after FORTRAN, if I am not mistaken.
Now, I want to state, I am still quite a beginner, but eager to learn, and implement something useful with LISP. So, if there's anything wrong, or you disagree with what I wrote, I am willing to listen.
LISP stands for List Processing. Here are some code samples on how LISP looks like:
(+ 1 2 3)
(* (+ 1 2) (/ 10 20))
Now, from what I have read so far, the essence of LISP is functions. There's a blur distinction between what is a data, and what is a function. A function could be a data that can be passed to a higher level of function.
So, in this way, you could build bigger applications, by writing functions, upon functions. Now, this is not something new. You can write functions in other programming languages, and do the same thing. But what makes LISP different is that functions are treated as data too.
And just by looking at this perspective, you could relate on how the real life is modelled. A high rise building, a car, a society can be broken down into it's sub components, which does something.
That activity can be at the lowest level, or intermediate level. But all those components has to contribute, or does it function in order to support that entity.
I haven't really tackled on how to write programs for LISP. Should I think of all programs as lists? or should I think of them as functions, build from the lowest until the highest level.
So, when you take a walk next time...just think about it. The complexity we have around us, are build upon functions right from the atom, to items that we could see, and wonder.
Now, I want to state, I am still quite a beginner, but eager to learn, and implement something useful with LISP. So, if there's anything wrong, or you disagree with what I wrote, I am willing to listen.
LISP stands for List Processing. Here are some code samples on how LISP looks like:
(+ 1 2 3)
(* (+ 1 2) (/ 10 20))
Now, from what I have read so far, the essence of LISP is functions. There's a blur distinction between what is a data, and what is a function. A function could be a data that can be passed to a higher level of function.
So, in this way, you could build bigger applications, by writing functions, upon functions. Now, this is not something new. You can write functions in other programming languages, and do the same thing. But what makes LISP different is that functions are treated as data too.
And just by looking at this perspective, you could relate on how the real life is modelled. A high rise building, a car, a society can be broken down into it's sub components, which does something.
That activity can be at the lowest level, or intermediate level. But all those components has to contribute, or does it function in order to support that entity.
I haven't really tackled on how to write programs for LISP. Should I think of all programs as lists? or should I think of them as functions, build from the lowest until the highest level.
So, when you take a walk next time...just think about it. The complexity we have around us, are build upon functions right from the atom, to items that we could see, and wonder.
posted by Steven Yip at 8:57 AM
3 Comments:
hi angel..
thanks for your comments...do you happen to be in the computer field?
I haven't really tackled on how to write programs for LISP. Should I think of all programs as lists? or should I think of them as functions, build from the lowest until the highest level.
Have you run across from MIT yet?
In the Structure and Interpretation of Computer Programs lectures, Abelson and Sussman present a methodology of "programming by wishful thinking." You write each high-level function wishfully thinking that someone else (or you at a later date) will write the lower level abstractions it needs.
This principle has completely revolutionized my way of thinking in approaching a new program. I first write a fully functional program at the highest level of abstraction (fully functional, that is, if only my low-level functionality was finished...), then work my way down -- it's a depth-first process of fleshing out the lower levels of abstraction until the program is done.
I.e., a program (silly example, probably poorly designed, but well-suited for a short demonstration):
(defun sudoku (board)
(with-permutations (permutation board)
(if (valid-boardp permutation)
permutation)))
This program solves Sudoku puzzles... well... if it made friends the "with-permutations" macro and the "valid-boardp" function. So that tells me I need to write them now. And when I do that, they will be suitably abstract that it will require some other support functions. But, for moving forward, the #'sudoku function describes the behavior of my program at the highest level.
By turning the process on its ear, I enjoy it so much more. It is pleasurable to reason through the way I want my program to look at the highest level before beginning on the low level. Naturally, there are times when a hitch is discovered part way through, but it's a totally revolutionary idea to write programs top-down instead of bottom-up.
Best part, as has often been said, Lisp lets you then write the language up to your level of abstraction and both ends grow towards the middle, where they converge on a complete program.
-Josh-
hi josh,
thanks for the comments.
Yes, I have just completed the first chapter of SICP.
I would say, thinking of writing this way, is pretty good. But LISP makes it much more easier to think it such a way.
But reflecting on this idea alone, other languages have the same thing also. You build from top to bottom. But what LISP allows you to do, is to assemble the whole program just like lego sets.
steven yip
Post a Comment
<< Home