java? wtf? or also, static vs dynamic typing.

One might be wondering why I'm reading a book on Java if I'm already well acquainted with a large variety of programming languages. I'm merely refreshing my knowledge on Java, and getting up-to-date, because I'm starting as a fulltime Java developer on monday.

I've worked as a python developer for the past 7.5 months, and mainly as a C++ developer for a very long time before that. So why Java?

Let me for now dodge that question and discuss the very relevant issue of typing, dynamic vs static, and my now-biggest frustration that I don't understand why I can't have both in one language. (yes, I know, Common Lisp supports both, but let's ignore that at the moment, because it does have issues)

Considering I have experience working in both worlds, I think I'm in a good position to judge, and the simple fact is: I need both.

On the one hand, static typing is just overhead, just documentation. On the other hand, it really helps when you need it, and you need it more and more later in a project's life when your thoughts on the subject have settled and you have a firm grip on the problem domain.

Static typing is not about abstracting, it is about documenting and constraining data for both the programmer and the compiler alike. In fact, it is much easier to write very abstract code in a dynamically typed language, but it is so much easier to understand statically typed code, again for both the programmer and the compiler alike. A compiler can make many decisions at compile time, and hence produce very optimal (byte)code. It can also tell you about any contradictions between the code you've written and the typing information you supplied, helping you to prevent bugs. The programmer has an easier time understanding where what data is coming from and where the hell it's going.

Hence, for 'understandability' for the programmer, a dynamically typed language needs more verbose documentation. Unfortunately, a compiler can't do much with that kind of documentation, which is also the reason why most dynamically typed languages barely 'compile', and are mostly 'interpreted'

Note that there is a language that does a very good job at giving you the best of both worlds, boo, but I wouldn't call it production-ready just yet.

On Bruce Eckel's 'Thinking in Java'(4th edition), continued

I'm quite shocked at Eckel's honesty in the introductory pages. I mean, he's not trying to sell Java to you like most books do. He talks about pros and not so much about the cons, sure, but he mentions python at least twice. On the very first page of the preface, he writes

And yet, of all programming languages of which I am aware, almost none have gone all out and and decided that their main design goal would be to conquer the complexity of developing and maintaining programs.

which then points to the footnote

However, I believe that the python language comes close to doing exactly that.

Later in the preface he thanks python and some python developers, most notably writing

I use python constantly to solve problems

And at the end, he even mentions, gasp, C#

We're all indebted to the brilliance of Anders Hejlsberg, who continues to toil away at C# (which as you'll learn in this book, was a major inspiration for Java SE5)

I find this kind of blatant open-minded-ness refreshing and above all healthy. It is the primary ingredient of an ever-improving mind.

Note to Bruce Eckel (regarding lisp)

On page 24 of 'Thinking in Java', 4th edition, Bruce Eckel writes

The alternative to modeling the machine is to model the problem you're trying to solve. Early languages such as LISP and APL chose particular views of the world("All problems are ultimately lists" or "All problems are algorithms")

I strongly disagree with this statement. Lisp is not about looking at problems as lists, at all. It just happens that a list is simply the most basic organisational unit. (well actually, a cons is). And lisp is all about building new abstractions on top of things that are less abstract. And lisp's macro is where it's true power lies.

Wether or not lisp is a good language for the Real World(TM), is an entirely different question. But in terms of 'modeling the problem you're trying to solve' I believe there is no language more powerful than common lisp or something similarly lispy (like scheme, though scheme seems even more powerful yet even less fit for the Real World)

For those out of touch with Common Lisp, let Practical Common Lisp be your guide. Read the first 9 chapters. (7, 8 and 9 are where it gets interesting)

A problem with Common Lisp

Common Lisp doesn't have python's generators. Or more generally, scheme's coninuations. Now, an often cited problem with continuations is that they are hard to understand, that they do not feel 'natural'. But then neither are GOTO statements. It's just another one of those primitives that are only useful to build 'natural' abstractions on top of.

to blog or not to blog

I'm constantly in 2 minds about wether to use an existing blogging tool like blogger or to develop and maintain my own simple blogging. Common sense would tell me to go with blogger or something else like wordpress, but I keep getting annoyed that they never really exactly do what I want.

At this point I'll just bear with it. I'm not a skilled web developer, and that is not likely to change anytime soon. If I did make my own tool, once again, common sense would tell me to use python and a framework like django. But then, where's the fun in that? It'd be fairly easy and I wouldn't be learning much, and if there's one requirement for doing stuff in my spare time, then it'd have to that I'd need to be learning stuff. So it'd be more interesting to use Common Lisp. Definately.

But then, I have a problem with Common Lisp...