“Contact: The first four minutes” is the title of a book from Zunin and Zunin about the importance of the spontaneous impressions people get from another in the very short first moments of encounter.
From the book description:
In four minutes, you will know if the person you are talking to is someone you’re interested in. Yes, it only takes about four minutes to decide. Yet in that brief time, you and your partner will have made an indelible impression on one another. Contact: The First Four Minutes shows you how to make that impression a positive one and to develop the skills that will make you an interesting conversationalist to anyone-from a casual acquaintance to your spouse.
I detected that the same is true for a programmer getting in contact with a new programming language. The first moments determine the acceptance of and further effort put into learning a new language.
There are some different factors which play a role.
1: The character of the programmer
Some programmers are very adventurous and curious, blessed with a spirit of a pioneer. They easily embrace new languages even if (and especially when) this languages develop a completely new paradigm; at least new to him.
On the other extreme we find the programmer who is very shy, easily scared by new languages becoming hype in the press, especially if they are far from his former experiences and current skills. He wants always to feel ‘at home’.
Most programmers are somewhere between this extremes. In the center you may find the pragmatic one, torn between the two sides expressed by the statements”there’s no The Tool, always use the best one for the job” and “another hype? Well, what shall that be good for? Where is it different? I just can do it with X”
Sometimes it may even be a matter of age. When you are young, the old stuff is uncool (COBOL?? psaw !!) and the new is sexy and hip. But when you become aged, the adventuresomeness ceases, learning new stuff is not as easy as it was before (even learning must be trained to stay fit in it), continuous context switches are considered cumbersome more and more. The question Why becomes more important, there is the desperate desire to eventually find The Language, which -once learned- would be the swiss army knife for the rest of the life. (Well, this search for The Language -by the way- is also detectable in some lesser weary groups, more driven by an idea comparable to the Grand Unified Theory in physics).
2: The character of the language
Languages are developed by different people. There are languages which come to life due to the necessity to have a tool for a specific task. They are practice driven. Then there are languages developed in a scientific or engineering environment for specific purposes, providing a powerful expressiveness for specific domains. We should not forget the academic breeding ground, where languages evolve from scientific researches about development per se.
As some languages are considered common at one time by the overall developer community (most of them in enterprise contexts today) , a new language is evaluated by its similarity and comparability to this languages. So a new programming language which mostly enhances the already known ones without bringing in too much new concepts will gain a broader acceptance than others, which would be considered ‘esoteric’ by the average programmer.
So it is understandable that we can observe a kind of ‘evolution’ of PLs, where extreme variants can at most survive in niches, while the mainstream languages show more similarities in geno- and phenotype. The more a language can provide ‘some good improvements’ while on the other hand being easily recognizable as derivate of the already known stuff, the more chance there is to be accepted by the developer community.
This ‘similarities’ consist of different things:
a) Is the syntax easily understandable? When you see some code snippets, do they look even slightly ‘known’ (this can be regarding already known programming languages or regarding languages outside the IT domain, like prosa, mathematics or even specific domains. See Chef as an esoteric extreme of what I mean.)
b) Does the language provide features and concepts already known by the ones currently in use? To my opinion this is one main question of the current Java-with-Closures debate. Who is used to Ruby or Groovy can hardly imagine to develop without closures. Who is used to Java only can hardly imagine what this additional, complexity enhancing feature shall improve. We already can use inner classes, if such a application design is necessary; see Swing.
c) Does the new language target the problems I currently try to solve with a mainstream language? If you are a business developer, you will not be very much attracted by a language in which you can easily represent chemical formulas as a main feature.
If the new language is perfect for statistic calculation, but has no web framework and does not ease GUI development, it may be interesting for that specific component’s development department only, but not for the company as a whole. Introduction of such a language may become a political/strategical issue then.
3: The character of the documentation
When a developer gets in contact with a new language, it is often due to some sort of marketing. You read somewhere about it, hear from a colleague, there is a session on a conference…
Then you start by visiting the respective home page(s), possibly even download and install the software, and almost always nowadays you will search for a ‘getting started’ document, accompanied by a ‘tutorial’.
These documents now are your first closer contact with the Realm of the New Power. The quality of these is vital for your further interest in the new language. What you read here will be crucial for your (concious or unconscious) decision, if the new language is considered ‘appealing’ or ‘charming’ or ‘irritating’ and ‘weird’ or simply ‘not relevant’ or whatever words you would find for it.
In the same way as a person you meet seems as likeable as it is addressing your interests in some way, so does a programming language and its documentation seem attractive if it addresses your needs or interests as a developer.
Example: Groovy and Scala
All this parts together describe, why I liked Groovy from the first time I met it, and why there is some sort of love-hate relationship in my first encounter with Scala.
Groovy is conceptually based on Python and Ruby (which I encounterd in this order and fell in love with in this order too), but due to the tight integration with Java-the-language and Java-the-platform and due to the fact that it exactly addresses the every-day problems of an enterprise java developer, it is currently my language of choice, used in as much situations as possible.
Scala on the other hand attracts due to its conciseness in comparision to Java, that it seems to be fast (reg. some Benchmarks), fit for enterprise size projects due to its static typing and generally its typing concepts, does even run on Android mobile platform (what Groovy perhaps never will). I read many things which indeed may make Scala imaginable as the Next Java. But the complexity of e.g. the type system and other concepts of Scala are also a barrier for the all-day developer.
What I told about Documentation and the first four minutes above is why I consider my encounter with Scala a mixed experience.
When you start, the first thing you will try out typically is what you find behind a link named “beginner’s guide“. In this case “A Scala tutorial for Java programmers”. It is a nice start, shows some similarities (classes, generics) and improvements (traits) compared to Java, but leaves one with perplexity and the question: “how does this now address my daily problems as a Java programmer? What can I do (better) with Scala now?”. Especially the case classes may be a barrier as they are most far from the common Java developer’s mindset.
Even the second quick introduction, to be found behind the link “a paper giving an overview“, is not really a stumble free way to Scala. At first it seems that this paper would address some considerations of an average programmer, but the paper stays on an academic and abstract level of speech, presenting the reader with short snippets but not a continous example which seems somehow to come out of a prototypical practical experience (or are local variables really meant to be one-chars, and methods really never longer than four lines?)
Not until you come to the link of “Scala by Example” (157 pages) you find an introduction which declares the basics of the language. But after reading that, a Java developer will miss the next steps. Full of all the new language concepts you do not get the feeling that you are familiar enough with it to take a simple challenge and write a little application doing file I/O, supported by a small GUI or something like that.
The questions arise now: “How am I meant to read and write a file?”, “How does GUI programming in Scala look like?”, “Could I write a little Servlet with it and start it in Jetty?”, “What about JDBC connection or higher ORM support?”
That are exactly the subjects directly addressed by the Groovy developers and authors, what in my opinion leveraged Groovy to the current state of broad acceptance.
I’m also not shure if the upcoming “Programming in Scala” book will address this questions. Perhaps we have to check out what we see on the “Papers” page, to get a better picture? Currently I stopped with the bunch of papers I already have, and will see to gain some more understanding by a hands-on approach, taking the risk of applying Scala in a much too javaesque way.
What I am mostly looking at when testing a new language:
- Syntax constructs
- What is the intented way to work with files, console in and out
- What is the intented way for logging
- How is unit testing be integrated
- What about Database support
- How to create GUIs
- Does it simplify XML handling
- Is Rapid Development possible,
- Would I write One-time quicks with it
- Is there a modularisation concept
- What about IDE integration