Java Redux. Redux.

I was perusing the internet last evening to pass the time before getting into a vicious round of Champions of Norrath : Return to Arms with my lovely wife.  I had Java on my mind for a bit of the commute home and as such decided to do a bit of googling.  For whatever reason, I decided to lookup “Java for Python Programmers" much along the lines of a great "Perl to Python Migration" book I'd acquired years back.  To my utter shock, results were actually returned.  

This whole 'ordeal' with Java has been going on with me for something over 7 years.  I started teaching myself Java way back when, but found it to be utterly too verbose for productivity, opting for perl in its place.  Then perl very quickly proved to be lacking when it came to large projects, and code cleanliness (by design mind you, I have written production code which after 7 years upon seeing it again, was very easy to follow in spite of its 7,000+ line codebase), and utter hackishness about it, regardless of the raw power.  I moved to Python both personally and then shortly thereafter, professionally where I enjoy myself most.  

However, there are certain things I've come to realise over the past many years, more so over the past few specifically.  One is that I should force myself to code in one of the behemoth languages to the point of solid fluency regardless of how dreadfully painful it can be.  Two is that most jobs are hybrid these days and require a wider set of disciplines in terms of technologies, languages and toolsets than in the past, and whilst I don't have any need for Java in my current work endeavours, it doesn't negate said need in the future.  Three is that Java makes the most sense being that C/C++ are for all purposes outside of hardware tied code (such as operating systems, device drivers, compilers), dead for application creation, period.

And so it is that I venture forth again into the wonderful realm of re-re-learning the evil behemoth formerly known as oak.  May she not be as cruel a mistress as in the past as my understandings of her workings have been greatly enhanced thanks to python sharing so many of those conceptual designs and paradigms coupled with my adoration for the latter language.  

Wish me luck.

Thinking in Lisp (with respect to Bruce Eckel)

It isn't what you might think based solely on the title of this post.  Bruce Eckel of www.mindview.net isn't coming out with yet another book prefixed with "Thinking in"...  or maybe he is.  As far as I know though, he has yet to, nor is he expected to write one on Lisp.   

On a quasi-regular basis I make the effort to learn something new in the realm of computing whether a concept, paradigm, and/or language.  I decided that given my past experience and interest (since I was considerably younger) in artificial intelligence programming concepts coupled to early leanings towards Prolog, a French born AI/logic language created around the same time as I was back in the early seventies, that it was time to return to my roots.  This time around I decided that after being an emacs junkie for so long, that the obviously choice for me this time around would be the Lisp functional programming language.  

Now the point of this post is not to go into the semantics of the Lisp language but to stress a more important point which I feel would be of greater value to any and all who might stumble across these pages.  Learning to think in Lisp changes the way you think about code logic.  I'm a fairly big proponent of OO design and programming, though I ultimately believe in using the right tool for any given job/project.  Lisp has a wonderful simplicity about it, a simplicity with a considerable amount of power behind it.  

The concept is not unlike Unix methodologies.  Simple, small programs which do one thing, but do it exceedingly well, which can then be piped to one another to do larger tasks.  Mind you this is slightly different but not by much.  Lisp works dealing with functions (and lots of parentheses).  You string together multiple simplistic functions together to produce more complex functionality.  A simple example might be finding the average of two numbers.

(defun AVERAGE (x y) (/ (+ x y) 2.0))

defun is used to define the function with the given name "AVERAGE", followed by its parameter requirements.  The actual body of said function consists of doing a division operation (/) by 2, against the results of an addition function (+) of the two provided parameter.

I feel that this example while a little simplistic does at least point out the basic mindset of Lisp programming, which still hold consistent with my above statement on its likeness to Unix shell mannerisms.  While I don't see myself coding entire systems (on a regular basis at least) in Lisp, I do have admit that I'm going to continue my studies on this language as I have been finding that my perspective has shifted thanks to learning this new and different programming paradigm, which ironically isn't new when it comes down to it.  It was just pushed aside to make way for the 'next great thing™.'

I heavily recommend some of the freely available books and information on learning Lisp and its concepts as listed below (Note: All items are PDF formatted for convenience):

Practical Common Lisp

Common Lisp: The Language

Common Lisp: A Gentle Introduction to Symbolic Computation