Californickation

SV

2009-12-21T12:18:00.000-08:00

So I went to Mountain View last Fri. It's a fascinating area with anything from googleplex to computer history museum just around the corner. And it looks more or less like a park, very different from filthy stone jungles of SF. The company and its headquarters feel so vibrant it made me want to join them on the spot (not to mention their impressive cafeteria). I really feel like moving to SV this year one way or another.

Surprisingly enough, the interview was not particularly challenging. Reversing a list and a couple general design discussions (e.g. about a peculiar Map implementation). I guess the interviewing team was representative of SV demographics - Russian/Indian/Filipino/American engineers, American manager and HR. Let's see if I get invited to the second round.

Or, and one more thing. Driving (even almost 60 miles one way) feels so much better than public transport. Although losing 1.5 hours of daily reading on BART would be hard to compensate.

External motivation

2009-12-10T14:49:00.000-08:00

Curiously enough, they responded with an invitation to a real on-site interview. I guess I have no choice but to re-learn CS 101 in a week or less. Algorithms in Java should do the trick (and I definitely prefer it to Cormen's Introduction to Algorithms for practical purposes).

And I guess I'd better buy a car within a week although renting one to go there could be an option. Strangely enough, there is no reasonable way to commute from the East Bay to the Valley by public transport.

2009-12-09T17:29:00.000-08:00

As I understand, big and famous software companies have a pretty different style of interviewing than typical employers in the Java land. They virtually do not care about one's expertise in mundane subjects such as particular languages, frameworks and other acronyms you can find in a typical resume. Sure, they will ask you a few Java questions to warm up but the real meat will invariably be CS 101.

Personally, I find it very challenging. I am not a CS graduate so I tend to quickly forget the details of algorithms I read about. As most probably most Java developers I do not need them on the daily basis. So when I decide to refresh my knowledge of this area, in a year I do not remember much. I heard at least some people with their eyes set on GOOG hit the books for a few months before applying.

In general, I agree that the best HR strategy is to find and hire smart and motivated people. And arguably one's prowess with algorithms and puzzles is very likely to correlate with IQ. I believe that for reasonably smart people all the good design skills/best software engineering practices/TDD/OOA&D/UML/Patterns/etc are just a mandatory part of their skill set. It's pretty much a commodity based on common sense and some time in the industry. This explains why the best employers use different metrics.

On the other hand, not so many people are lucky to deal with stuff more challenging than util.concurrent and basic caching. Which means that there's a significant gap between what one actually practices/knows/uses in normal development and what is required to pass an interview in a cool company. I am not quite sure how to reconcile these two things.

Trying to learn by heart a couple of books on algorithms and data structures sounds like a plan but it would take a lot of time otherwise allocated to new things such as Scala or Hadoop. And if I remember my college days correctly, most of that knowledge will have a rather unimpressive half-life. Moreover, judging from job ads most companies ask specifically for experience with particular technologies (be it Lucene or J2EE) and could not care less about your ability to implement binary tree rebalancing in ten minutes. And from what I know, they will even pay you comparable money.

Anyway, today I had a phone interview with such a famous company from the Valley. We started from a discussion of singletons. Curiously enough, I correctly came up with three ways to get multiple instances of a Singleton in the same JVM address space although I remembered only one off the top of my head. But when we progressed to the algorithmic section I did at best averagely. Not a big surprise but it hurt to demonstrate so much ineptitude. I think more and more about finding a more challenging employer and relocating to the Valley. So probably I should postpone trifling with new and interesting stuff and hit the books for some time.

Seniors among Java engineers

2009-12-04T12:09:00.000-08:00

If you were to trust what you read on the Net you would think Java is a brain-dead language and people who develop in Java are the alternatively gifted among software engineers. While the former is a multidimensional question the latter could make you nervous if you've been in the Java land for many years. Allegedly, in some circles a decade of predominantly Java experience raises a red flag.

I am inclined to think that Java is mostly infamous for its enterprise branch. Surely once fashionable J2EE technologies are good for outsourcing but the damage they inflict on developers is very real. But if you ask me, I'd rather do EJB2 than any kind of web UI from JSP to ajax. Luckily I have not had to deal with either for a long time.

Occasionally I participate in interviewing potential future coworkers. And some of them position themselves as Sr Java engineers and even have CS major backgrounds. You would think that in the Bay Area developers are likely to be a uniformly enlighten group. After all, this is arguably the most expensive place to hire and an international magnet for software engineers.

Not really if my experience is representative. I have interviewed and even worked here with people who demonstrated almost appalling lack of professional skills (e.g. decent OO design with proper decoupling and meaningful responsibility assignment) or relatively basic knowledge (the role of hashCode/equals in the HashMap context, anyone? optimistic/pessimistic locking strategies? ACID? mapping of class hierarchies on relational DB tables?). On a few occasions after a decade or two in the industry.

Or is it just me? Probably I am supposed to ask candidates to implement a RW lock (unless your name is Doug or Brian I'd rather know you are intimately familiar with the util.concurrent package) or recursive tree scanning? But those look like more advanced concepts to me than the difference between volatile and synchronized in protecting a long variable. And it's not like in their defense they could show years of non-OO (although I am pretty sure FP folks are into good design, only by different means) or non-Java/C++ experience (then again, what makes him a Sr Java engineer?).

Could it be the case that Java is merely so dominant that it covers wildly different domains (e.g. util.concurrent/NIO v J2EE; telecoms or financial middleware v a web UI for DB access) and we do not have specific terms for people with the corresponding expertise?

CAP for the rest of us

2009-12-01T12:12:00.000-08:00

A nice two-part discussion of the CA P theorem with practical examples.

I did not call you stupid, I called you a Democrat

2009-11-09T12:35:00.000-08:00

Last year I had some hopes for the impact of the last recession on the Socialist Republic of California. Even basic things like sending the Mexicans home and the Democrats packing, cutting free goodies for the alternatively gifted (e.g. welfare, section 8, rent control in SF, mortgage modifications and moratoriums) would do miracles.

Apparently we are nowhere even remotely close to addressing real issues. As the latest illustration shows, the unwashed masses are happy with both the America-hating communists from the White House and their local accomplices. The other week CA elected another Democratic congressman. All the while lamenting the state's future.

If only Silicon Valley were located somewhere else :(

Some people are living the future today

2009-08-20T21:49:00.000-07:00

This is the first pubclicly available long presentation by Click Cliff on their HW to the best of my knowledge. They seem to be both living in the future and doing hardcore CS/EE. I am surprised Doug Lea does not work for them :)

Best sticky note presentations on concurrency ever

2009-08-13T18:01:00.000-07:00

I stumbled upon a few very impressive, useful and uniquely designed presentations . They discuss a few classical but very realistic concurrency problems using a distinct visual and didactic approach. Frankly, I have never seen anything like that, the author seems to be in a league of his own.

The only inconvenience is that you need a connection all the time because the system hosting those presentations does not cache all the images.

CTM for dummies

2009-06-23T10:38:00.000-07:00

I heard a lot about Concepts, Techniques, and Models of Computer Programming but I have not read it yet. It turns out there's a 30-page paper by one of its authors which crams most of the book into a high-level overview. I was instantly fascinated when I started reading it. It's short enough to read while commuting and it puts into perspective most major languages and concepts and paradigms they implement.

Multicore prorgamming lectures from MIT

2009-06-23T10:30:00.000-07:00

Yesterday I found this newly uploaded course. The content seems to be very interesting at least from hardware and conceptual points of view.

How to leak Linux pipes from Java code

2009-06-19T15:56:00.000-07:00

Fixing a bug in legacy code I found a moderately counter-intuitive rule for dealing with Process instances returned by Runtime when one executes a process. It turns out that the three standard streams associated with each instance must be closed regarless of whether you use them anywhere in your code.

By default I expect that unless I explicitly open something there is no need to close it manually. Moreover, I double-checked javadocs and Java Programming Language and I have not found any related warning. On the other hand as it happens on the boundary between java world and OS it is probably natural to expect very strict requirements for disposing of unused resources. At least it was not me who wrote that code in the first place :)

An easy way to check if pipes are leaked is to run something like "/usr/sbin/lsof | grep pipe | grep java" and see if the number is growing. In my experience if you get a "too many open files" error it's likely to be either about leaking pipes or sockets (if you can see an unreasonable number of sockets in CLOSE_WAIT state in netstat output).

A-Z of Programming Languages

2009-06-16T13:31:00.000-07:00

A nice series of interviews with 21 language designers from Ada to Erlang.

Glimpses of Scala future

2009-06-05T10:29:00.000-07:00

Yesterday we had another BASE meeting. This one was particularly interested because Martin himself attended it. It was intriguing to observe an international celebrity sitting 6 feet from him. Curiously enough his laptop was an ordinary Windows machine, not an Apple.

I was much more impressed with a few remarks concerning future Scala plans than by discussion of changes forthcoming in 2.8 (mostly re-designed Collections, support for continuations and specialization of genertics with annotations). To begin with, Doug Lea was reported to be so frustrated with lack of Java progress that he was going to participate in Scala concurrency library. If it actually happens I think it will be a clear indication that Java is beyong the point of no return.

Another prominent engineer, Josh Bloch, was said to be going to seriously look at Scala. It would be interesting to hear his opinion, after all there is no guarantee that Scala will be the next Java and Josh is surely among top 3 people qualified to judge Java-related matters.

In general, Martin's vision is to make Scala the language of choice for concurrent and scalable systems on the JVM within next five years. I would say that the time frame for choosing Java's successor will be shorter, probably something like a year or two. If Scala manages to have a stable and performant implementation of FP/Actors/Collections (and limit the number of inconsequential syntax changes) and incorporate Doug Lea's concurrent abstractions omitted from Java7 it will position itself perfectly in the future JVM space.

They knew it but they still ended up with Java as we know it

2009-05-23T10:41:00.000-07:00

Ten years ago I did not know who Guy Steele was or that I would spend years programming in Java. Seven years ago I thought that a language without operator overloading and templates was an ugly toy. A few years later I got so used to it I mostly stopped worrying.

It turns out Java authors were not morons. Probably they thought the users of their language were. Or they just could not imagine that a language for programming refrigerators (or was it set top boxes?) would be of any wider use. What is painful to learn in hindsight is that they knew about all the good suff , liked it a lot themselves but somehow chose to ignore it.

Back to basics

2009-05-22T14:57:00.000-07:00

When I started reading about Erlang and Scala last year I felt rather uncomfortable. Many small syntax details looked rather odd after years of C++/Java development and made little sense. I remember how learning Java I just had to remember what is missing in it in comparison with C++ (pretty much everyting advanced - templates, operator overloading, STL). This time it was different and even vague recollections of overloaded parenthesis were not sufficient to easily grasp a functional language.

With pretty much everyone online saying that Java is either dead or at least brain-dead and looking forward to multilanguage programming future I decided to dig slightly deeper. So recently I found myself learning basic Lisp/Scheme. Conveniently enough, there are MIT and Berkeley video courses on YouTube based on the legendary SICP book. To me mixing medias helps a lot.

I am not sure so far how significant the influence of all this will be on my work. Certain qualities such as immutability had been appreciated long before Java became popular (const int* const i ; anyone?). And I am still struggling with suspicion that lambdas and classes are merely two sides of the same concept. After all lambdas are not "functions", they are associated with frames which actually represent hidden state and not merely a bunch of machine instructions.

Not being a CS major I missed early indoctrination and so now I am re-discovering for myself things which are probably self-eveident to better educated people. FP in general, and Lisp in particular seem to be very common in different CS fields. So much so, that most AI books and many introductory CS textbooks are written with Lisp examples only.

With my EE background it is not entirely clear whether it means that I have spent my professional life in some low-life corners of the software field or that those nebulous areas are of very limited usefulness in real life. It's not like I see many positions for Lisp/Scala/Erlang programmers or AI developers even here in the SFBA. Most startups I am aware of are not working on robotics or something like that either.

A relatively unexpected observation is that it is not that difficult to learn the basics of a new language. The core of Lisp is both small and excitingly related to CS. My problems with Scala/Erlang seem to have been caused exclusively by my total FP illiteracy. So the motto of "a new language a year" makes more sense to me now.

M&A

2009-05-21T10:01:00.000-07:00

Probably as a sign of weakening VC climate we have been acquired. By a publicly traded company and they even promised to give us their stocks. On the negative side, they have significantly more expensive health insurance (especially in comparison with HSA we used to have) and absolutely atrocious choice of 401K funds. At least there could be some interesting tech stuff to do related to scalability/cloudness because of their extensive network infrustructure. We'll see.

This is the third startup I have worked for so far. The first one, a few years ago grew to a self-sustaining business. The second went down is style. This one got acquired. Judging from the trend, the next startup I will work for is likely to fail :)

Big4 on YouTube

2009-04-16T17:15:00.000-07:00

Recently I noticed that the Big 4 (i.e. MIT/Stanford/Berkeley/CMU) shared a number of their introductory courses online. At first glance, only Stanford and Berkeley actually have a few CS-related ones. MIT shared mostly general engineering/math courses while CMU, the home of robotics and software engineering, has virtually nothing online.

I am watching two courses currently to get some idea of Lisp/Scheme and how the best and the brightest are inculcated true meaning of CS in general :)

Stanford

Programming paradigms - a very nice review of a few languages (from Assembly to Python) including four or five lectures on Scheme. The lecturer is very energetic and gives an impression of someone who has real life experience.

Berkeley

CS61A Structure and interpretation of computer science - more of a CS course using a Lisp dialect than a language course which arguably makes it even better. The lecturer here is less impressive and at times seems to be too old (incidentally, the equipment is also less shiny than at Stanford .. is there some kind of correlation?). There's also CS61B but it seems to be based on Java (?!) so it is less likely to be of significant interest.

MIT

MIT 6.001 Structure and interpretation of computer programs - vintage '86 edition, narrated by Messrs. Abelson and Sussman themselves.

In addition, there are a couple more courses on subjects such as robotics and machine learning but those have less immediate applicability. So I encourage you to browse their offerings.

Book marketing for real programmers

2009-03-15T19:13:00.000-07:00

ForkJoinWorkerThread.java :

"... If you are unfamiliar with them, you probably want to read Herlihy and Shavit's book "The Art of Multiprocessor programming" ..."

The book seems to be JCiP on steroids (would you expect less from something Doug Lea himself refers to? :) ) with 100+ pages on theory (pretty standard topics with nice illustrations, Java-friendly examples and quite detailed explanations) and 500 pages of everything you always wanted to ask Doug about (personally, I would not expect to understand most of the answers anyway, at least before reading this book).

It took me five cover-to-cover readings of JCiP (guess who is the slow one in my family? :) ) to get sufficiently comfortable with the subject. And I still occasionally re-read parts of it. AoMP addresses much harder questions although is probably less practical unless you are writing your own j.u.c or want to understand how the real one works.

Scala Lift book

2009-03-06T14:25:00.000-08:00

So it turns out there is a free book on the Scala web framework written by Lift developers. It is 255 pages long in pdf so it is not a toy. The bad news is that for some reason the book is provided as a bunch of LaTeX-like files. I had to downlosd a 100MB (sic!) installer for a converter to pdf. WTF?!

[Edited on Mar 09]

I skimmed through the book on Fri. It is a really nice introduction covering all the basic things (from Maven 101 and generating an empty Lift project to O/RM and AJAX support) so I believe the Lift guys should be more vocal about it (not to mention sharing a version in some user-friendly format). It definitely answered my beginner's questions about Lift.

On the negative side, the Lift framework is work in progress and so the book marks up some chapters as "provisional/partly to be deprecated". I was particularly confused with the chapter on OR/M because they mostly cover the original approach which seems to be deprecated. By no means this is something to blame authors for and I hope they will ultimately synchronize the book with the Lift roadmap.

I am not really into UI/presentation tier so I am in no position to judge the Lift framework. For some reason I was not impressed with what I saw but do not trust me in this respect. In addition, taking into account how many XML manipulations are hidden under the hood (and Scala's ability to make XML processing look cheaper) I am worried about performance.

One area I want to research further is their approach to continuations. As I understand they rely on the container to provide basic infrastructure and so no magic should be expected from, say, Tomcat5 deployments. A related questions could be COMET support with Actors because both are quite new to me. I think those two areas could be of general interest from the usage of the Scala language perspective as well.

In conclusion, I applaud the authors for a very useful resource for people interested in Scala.

Small language changes for JDK7

2009-03-02T15:27:00.000-08:00

I am a thoroughly conservative guy and quite naturally tend to be a late adopter even if I am aware of a particular new technology in general. Watching a panel on future of Java on infoq.com a couple of years ago I was quite surprised by people of Joshua Bloch caliber discussing Java as a probably mature/declining language.

Back then I expected that somehow that language changes of Java5-magnitude would be added with each new release. I believe that only in Java5 the language was getting some of the C++ power it was originally deprived of (e.g. STL and all the features enabling it). So it felt as Sun finally decided to get serious about the language and stop dumbing it down to almost VB level.

Surely enough the titans were right and saw it coming even back then. In contrast to the JVM (as in garbage collectors or contested monitor performance) Java does not seem to have meaningful progress anymore. Syntactic sugar just is not worth it in my opinion. And Doug Lea seems to be the only one pushing Java's limits.

Things like catch blocks for multiple exceptions do not bring much to the table, not to mention all the legacy code which is not likely to be migrated. And to have mixed styles in the same code base is even worse than to have gratuitious blocks in the first place. As a creature of habit, I do not even notice such things anymore, I code them on auto-pilot.

Last year I was reading the Erlang book and got so confused with FP idioms that I had to digress and read the Scala book to better grasp what all the FP hype was about. It did not convert me from OOP but definitely made me appreciate FP (and incidentally reminded me about STL which enabled all the FP-style fun with lists fifteen years ago).

And somewhere down that road I found myself thinking that I do not want Java to be changed dramatically anymore. An attempt to make Java more sophisticated would result is a limited version of, say, Scala. It would be a new language and all the existing code would immediately become non-idiomatic. Or in the worst case there would be just a few special cases hard-coded into the language instead of meta-protocol-like facilities.

So, if even I have this funny feeling that any potential Java upgrades (years ahead, and some people have not migrated even to 1.6) are not as appealing as a modern language such as Scala probably the tide is actually turning.

Programmer Competency Matrix

2009-02-27T14:08:00.000-08:00

It is not he first such matrix but it made me think a little. In a week I will be celebrating my first ten years in professional software development. And looking back I can only laugh at myself back then. It's been a long way from almost "Unable to find the average of numbers in an array" but log(n) (Level 3)-like requirements show that the next decade will probably make me feel something similar :)

WFH

2009-02-25T11:11:00.000-08:00

We are working from home for a few days because of moving to a different office (this time it will be 3 blocks from Market St istead of just accross the street from Montgomery St BART station). As was predictable, productivity is going through the roof. Few things can be as valuable as a quite space where it is possible to keep concentration for a long time (not to mention 2 hours spared from commuting).

I wish we routinely worked from home, say, 50% of time, especially in the middle of a sprint when requirements and design are already well understood and it is time to code.

Not even two months later

2009-01-30T12:05:00.000-08:00

.. and we are losing another three people. This time it is not just about auxiliary folks from support and QA, the least experienced developer is let go as well. So we are down to 13 from the peak of 20 which is a 35% cut. And we are moving to a new significantly less spacious and expensive office next month. And we do not even have water service anymore.

I would say it is not down to bare metal yet but it is getting pretty close. The board of directors think that the lucky head count of 13 is reasonable for the rest of 2009 but let's see what they think in a couple of months. Last December they thought the same about 16 people :)

Programming in Scala on Actors

2009-01-29T12:47:00.000-08:00

I am through my first reading of the book and somehow it seems to be less helpful than I hoped it would be. I do not think it is bad or merely repackaged online documentation but I guess I expected more from a book written by the language author. Sublime wisdom or something :)

I believe most people are interested in Scala because it is an OOP-friendly tool for learning practical FP and Actors. So I was particularly irritated by chapters on GUI (who cares?) or minute details on integration with Java (better to be online instead of wasting precious book space). On the positive side, my feeling is that FP is covered in the book adequately.

What truly disappointed me was the chapter on Actors. To begin with, why only 1 chapter on this exciting topic? It is not like best Actor practices are better known than FP among us mere mortal with mostly C++/java background. And in my opinion that event simulator example is actually a good illustration of what not to do.

What I wanted to see was a clear comparison with traditional concurrent designs. So some universally-known concurrent system (e.g. a network /web server) would not require any explanation what it is and would immediately conjure up many examples from java world. Some code snippets would be probably even useful in real life. Not only modelling circuitry won't, it actually complicates the discussion with essentially unrelated clutter.

In addition, it would be really useful to learn how all this Actor machinery actually works. Is it some native magic or just a Scala library? How does it compare with j.u.c-based abstractions, at least performance-wide? Not a single word.

As a matter of fact, there is a much more elucidating paper named Actors that Unify Threads and Events. It really helps to read it before you delve into the dark internals of Actor.scala. It turns out that some interesting (and somewhat dirty? or truly ingenious? exceptions for control flow ..) design decisions were made to make it work.

As for the Actor-related code itself, I found it quite messy. Makes me wonder if the root cause was extreme performance fine-tuning or certain sloppiness. There is even a recent post where an independent Scala enthusiast comes up with a more orderly design of Actor.scala (and provides a few more hints on the official design). Hopefully Martin&Co will listen to him.

Is Java relevant?

2009-01-11T09:18:00.000-08:00

My previous post made me think about my attitude towards Java. Even if it happens to be behind its pinnacle, is Java any good beyond paying my bills for years? If we know what Java gave this world probably we will be better equipped to decide when to move to a new language and how to judge it.

History teaches us that non-technical aspects matter more than what is habitually referred to as technical excellence. Which is actually difficult to define. I have a growing suspicion that what matters a lot is something I would call, for a lack of standard term, "age and experience demographics". The idea is that certain technologies are perceived to be cool by people entering the field. Those technologies in a sense create an imprint on that particular generation.

As an example, in the early nineties Assembly was for real men and C++ for real programmers. At least how I felt it back then under certain circumstances (no influence from CS-savvy people, and extremely limited literature in the absence of the Internet, most people using and targeting MSFT platform). I know that years before I discovered computers people had been writing in HEX code and considered Assembly to be unmanly. It very well may be that nowadays something like scripting/dynamic languages are all the rage among the young.

There must be also a heavy influence of experience resulting in some kind of "shifting interest curve". You need to be through a complete life cycle of a major language such as Java to be able to see that not everyting is new under the sun. As an example of a self-made developer, I have progressed through Pascal, C++, OOP, OOA&D, RUP, UML, Java, algoritms and data structures 101, development methodologies, software architecture, really understanding OOA&D, really understanding Java concurency, TDD (disclaimer: for simplicity sake the sequence was artificially serialized and stripped of many things).

Right now I value good analysis and design (assuming OOA&D; I am not aware of FP/dynamic language alternatives to it; and yes, I appreciate UML) and best software engineering practices more than a particular language. I like reading about algorithms much more than I did ten years ago. I am dabbling with FP in its safely diluted incarnation (Scala) and planning to look again at Erlang later next year. Who knows, probably in my next ten years I will be able to get interested and even like highbrow stuff such as LISP. The point is that in addition to normal technological progress each individual has another learning curve which includes things not affected directly by his current job.

And last but not least, not everyone majored in CS. As a matter of fact, I believe I have worked with more people from Engineering/Physics backgrounds than properly educated CS graduates. Naturally, the former were not indoctrinated in seemingly non-practical subjects such as LISP, FP or even the details of compiler design. Some of those are probably later picked in spare time but I would still expect a gap between originally CS and non-CS folks.

So, what do I like about Java? I happen to maintain an Apache module written in C and every time I fix a bug there I appreciate our warm and fuzzy Java world more. This juxtaposition elucidates good things about Java although by no means it is even remotely scientific or exhaustive. Disclamer: borders between Java the language, the JVM and Java ecosystem at large are blurred to reflect real life.

Java has a standard API (or a de facto standard API) for nearly everything. And innumerate open-source implementations of those.
Java has multiple open-source components available for anything from reliable messaging and IoC to web UI and Map/Reduce on serious scale.
We have a set of widespread mature technologies covering most important mundane areas (e.g. Maven/Spring/JUnit)
Java has a memory model and an amazing util.concurrent library. It was Doug Lea and not James Gosling who was my youth hero :) And Brian Goetz wrote really nice javadocs :)
Java has a decent Collections library
Java dominates the server side. Jobs are abundant in interesting domains from Finance to Telecommunications
Java promotes OOP and interface-based design. Not really design by contract though :(
Because Java is a dumbed-down language, it is easy to read (well, multi-screeen methods are still found out there but I guess you catch my drift). Though I have always missed overloaded operators and proper generics (enabling the STL library in C++).
Nowadays there are enough high-quality Java books
Without IntelliJ IDEA I would go out, shoot myself in the foot and die :)
Java does not look weird (presumably in comparison with the C branch of evolution)

Most of us would be able to continue this list for a long time. When I look at it the point seems to be indeed that it is not about Java the language. Libraries and the JVM sneak into the picture all the time. As a creature of habit I like Java because I am used to it but if a JVM language more sophisticated than Java comes along I would be all for it.

Harking back to Scala, the language looks smart to me (yes, I am enamored with C++ like complexity and things like covariant/contravariant type annotations attract me rather than scare away). I detest languages that restrict me (Java more than C++, Erlang more than Scala). I cannot imagine living with a language where I would not be able to do OOP even if I like the idea of trying out at least elements of FP. And Martin reminds me Bjarne more than others do :)