Trying to kill creativeness in programming: Why a "Programsmith" would fail

Ever wanted to be a great musician but cannot read notes? No problem, using a computer program will help you getting along and famous: Microsoft Songsmith.

Songsmith composes music for you, the only thing to do is to adjust some sliders and sing into a microphone. From that moment on music will fill your laptop, quick and easy, nice and dandy, for every occasion in every phase of your life.

Why there is no "Programsmith"...

So much for the idea the creators of Songsmith try to sell. But, as we all know, in real life it is not so easy to just create an algorithm that scans sound and spits out world-class music. The idea surely is appealing. And it is not really new: Many customers and project managers dream of an IT-service-provider/programmer/administrator that exactly solves problems in the same way: Best would be to "sing" a little requirement into the phone so that the complete and working program can be deliverd a week later. And do not technologies like RAD, XML, EJB, Webservices suggest the possibility of a Programsmith? Simply connecting the modules and you are done?

... and why a "Programsmith" would fail

Certainly not, projects in IT do not work that way. You have to communicate and get the requirements right, make project plans, split the workload into functional points and instruct the programmers, involve third-party-modules and interfaces. All in all it is a creative process and we all know that. But our customers (and quite a hand full of programmers) would like a "Programsmith" to exactly do that: Draw a little plan, involve some kind of magic compiler (UML, anyone?) and deploy the program.

Well I had fun scanning through the results of Songsmith videos on youtube viewing classical hits interpreted by the program like "Roxanne" from "The Police". I think that this is the hearable pendant of a (more sophisticated) program how a kind of Programsmith would compose it. It will not work out in the end, at least not as long as the to-be-written-program is a counterpart to the complexity of a "Stock Aitken Waterman" tune simple enough to be more or less replicated by Songsmith. But even that one crackles and creaks a lot.

I wonder if there is a similar video out there treating programming in such a way (videos like singing to be successful selling "Glow In The Dark Towels") using the sliders "XML", "Webservices", "Cloud-computing" and such. Would be funny to see the results of them. Well, let me search a bit... .

Are programmers open minded enough in technical opinions? Why not?

Today I checked an entry on stackoverflow.com to see how the answers were doing and which answer the questioner selected for himself to be valid. Again I was totally disappointed because the answer selected was in my opinion far away from being the best answer, rather it seemed to be the most convenient answer for the guy who asked at first place.

Are we open minded enough?

Questions of programmers mostly divide in two parts: The technical questions (i.e. questions which provoke solutions that either work or won't) and questions which - at least - elict to give an opinion in the answers because they cannot be answered that simple (i.e. "which framework is best", "what is the fastest method to..."). The latter kind of questions troubles me here.

When we ask for opinions of the community we should stay as open minded as possible judging the answers, but this, alas, is very difficult. Let me state some points why this is so.

Why aren't we open minded enough regarding our technical opinions?

So, why is it so? I gathered some reasons and their descriptions I stumbled upon in my life and wrote them down:

• Projects, timelines, customers and change requests to be done "until yesterday". In a perfect world we would have enough time to evaluate different approaches for a programming project or problem. But in the real world you often have to just get the job done and have no time to rely on fancy stuff like other opinions. This may get a habit that is hard to be dealt with so that finally the own opinion counts (more).
  
• Experience vs. half knowledge. Every programmer has a certain experience in a certain moment in his life. You certainly cannot have a (completely) valid opinion of things you didn't "experience" until now, be aware that half knowledge is a bad judge. Anyway, many people in cs trust their half knowledge more than (other) opinions from more experienced people, often even without really recognizing that they do so.
  
• Sticking with own tools / frameworks / languages. Regarding their languages, tools and frameworks most programmers are very conservative and do not want to change them. That is not bad per se, things that worked out should be kept and experience gathered stays preserved, but it leads to programmers who do not try (or accept) new ways and therefore being "open minded" gets really hard.
• Only the newest tools / frameworks / languages are the best. This seems to be the opposite of the argument above but it merely isn't. Someone who only relies on the latest techniques may not be aware that a problem can be solved better using an "old" technology. This perhaps because he never got deep enough using something (long enough) to see the advantages that are not obvious at first place. On the other hand the drawbacks of a new technology are not known at the beginning so everything looks more simple than before. That creates prejudices which constrain to be open minded.
• It worked fine in my project so it works fine for everyone else. Generalization. Nearly everyone fails on this and it is perfectly human to do so. But in cs all project are, more or less, different. Be it because of the (slightly) different requirements or the environments or specifications a program has to run in. Even small varieties may make the great difference and everyone should keep this in (an open) mind.
  

This all is not really new and there are many slogans that reflect them like: "A fool with a tool is still a fool", "If all you have is a hammer then everything looks like a nail", "Use the right tool for the right job" or "Some tools make simple things even more simple and complex things impossible". Anyway, every time I answer a "technical opinion question" I lean back and try to evaluate my answer against the points I mentioned above. I think this improves my answers a lot.

Related posts:
Different types of programmers
How to choose the best programming language

Google Chrome without data sniffing: Iron is here.

A german software company named srware took the GPLed source code of Google's chrome and ironed it down to create a browser that does not phone home to Google any more. The latest release of Iron (1.0.155.0) from December 14 already contains WebKit version 528.5 and JavaScript engine V8 version 0.4.4.1 and therefore is slightly newer than the respective versions in Chrome.

Your data is private again

The goal creating a Chromeclone was simple: Although Google Chrome delivered fantastic rendering and JavaScript speed from scratch and is pretty stable and compatible, criticism arose because the new browser shared it's data with Google.

Every time a new URL is entered this data is sent to Google. And Google can match these with the browser because every browser gets a unique id when it is installed. Furthermore, the Google Updater is installed and runs in background every time you start your computer (check your Task-Manager for "GoogleUpdate.exe"). This and more is deactivated in Iron, according to this page.

BSD-licensed, USB-stick version and source available

The browser identifies itself as "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/528.7 (KHTML, like Gecko) Iron/1.0.155.0 Safari/528.7". The geeks at srware provide downloads for an Iron-Installer, an Iron-USB-version (without installation) and the source code they altered. The source is available under a BSD-license, so everyone can use it completely free even for commercial products.

Conclusion, language tips and full incognito

The rendering and JavaScript performance of Chrome attracted us from the beginning, alas the privacy drawbacks stopped us from using it. Iron does a good job here and comes, as a bonus, wit a USB-stick version and without installation but preconfigured with the german language.

To change the language choose the "SRware Iron anpassen" icon (top right in the tab of the browser) and click "Optionen". Then click the third button ("Schriftart- und Spracheinstellungen ändern"), choose the tab "Sprachen" and select your language in the "Iron language" - dropdown.

One more option at startup is the "--incognito" parameter. Start Iron with this (i.e. like "IronPortable.exe --incognito" to immediately switch into the anonymous mode. Have fun!

Google Chrome: A first little test with highly complex AJAX/Javascript web applications

Google Chrome - what is it's real performance for highly AJAX-based web applications?

Some five hours ago Google introduced Google Chrome and put it on their site for download. Google Chrome is a stand-alone web browser and therefore has to compete with browsers like Internet Explorer, Firefox, Opera and Safari. Here at first a core Javascript test (as stated in a previous Javascript-post):

Chrome 0.2	FF 2.0.0.14	FF3 RC1	IE 7.0.5730.13	Opera 9.27	Safari 3.1.1
3471,8	26271,4	5447,0	40846,2	12358,2	6318,8

Time in milliseconds the browsers needed in this performance test

But Google Chromes main goal is (according to Google) an other goal than that of other browsers: Highly AJAXed Javascript "web applications" shall run faster and more safe with Google Chrome, thus enabling a new era of web based applications like Google Maps, Google Mail or others. Time to look at speed and compatibility issues with more complex applications, even though the browser is stated as a "Google beta". Again.

YAWB or not YAWB, that is the question.

Yet Another Web Browser? Or: Why is Google in the web browser market? Because that is Googles business, the idea fits. Why not presenting the browser as a gift and earning money with the applications they run?

Internas and testing environment

Time to do a kind of real life test using an internal application that makes heavy use of Javascript and AJAX. At the moment Google Chrome is too much of an early bird to do this excessively, but we can have a look under the hood and run a fairly complex application on it.

The new features include

• A new Javascript Engine called V8 is in use.
  
• Better performance through compiled Javascript, it is compiled into machine code and not necessarily always interpreted.
• The new Javascript VM has a better garbage collection included to preserve memory.
• Browser tabs or new browser windows run in dedicated threads.

The testing application has some thousands of lines of self-written Javascript-code and relies on Prototype and other frameworks. It (re)opens different "windows" as DOM-elements and is able to switch through them via ctrl-tab and shift-ctrl-tab. Data is drawn from the background via AJAX, the usability allows drag-and-drop of single (or multiple) elements from one window into others. The application "runs" on IE, Firefox and Safari. Pretty complex stuff for a first test.

Compatibility will be the key...

What use is a new browser if the sites you want to visit will not work with it? Right, none. So the browser has to be as compatible as possible. I was fairly surprised and impressed as I saw the application running smooth and dandy. There was no itch regarding the Javascript-compatibility, every function I tested simply worked. The whole Javascript-code ran without the need to apply a single patch or something similar from our side. You know the moments where you hope "ah, come on, it will work out somehow. I believe, I strongly believe..." and you run it and it works out? That was one of that rare moments. Impressive.

... and performance will be the door-opener.

So it seems to be pretty compatible, right, but the second side is, is it faster, more useable than other browsers? The rendering engine seems to be partly from the webkit.org - project, rendering was pretty fast and compatible (to say the pages looked like in other browsers). From the look and feel of the thing I would say Google Chrome is at least one of the fastest rendering browsers if not the fastest, anyway.

And the Javascript-performance was astonishing (see here for numbers of a normal Javascript test suite). The application, running pretty fast in Firefox 3 and Safari 3.1 got a little extra speed-kick. That way it really feels like a real application on the computer rather than rendered web results. The clear separation of tabs and windows into threads does its additional work: Because no tab has to wait until an other tab releases the processor you have the feeling that it works faster or smarter.

So is it worth the hassle?

I think it is worth giving it a try. I do not think that I will use it yet as a browser-user, because I need my Firefox-plugins or IE-updating. But I will definitely test it with/for Javascript and AJAX-driven pages and our own developments. The gain in there is definitely worth the hassle.

How to choose the best programming language

Inspired by a new blog-article "Best programming language" there are some more open points to discuss on how to choose the best programming language for life, universe and everything. Let me give 5 of them.

First things first: Is choosing the right language even remote possible? And if so, how can it be done? Well, to set things clear let's have a real-world-example: Which (spoken) language shall I learn to succeed at most? If it's only a matter of understanding and talking to the most people this would be chinese. Do you achieve your goals with that? Most probably not.

Why wise selection is necessary

You can speak with one billion people in case you choose to learn chinese, but you could not read this blog (in case you prefered learning chinese before learning english). And how many people in your neighbourhood do speak chinese? Is it worth learning (under respect of this argument)?

Choosing a programming language too depends on many factors which you have to name and select with care. You want to show the best performance in programming (be it in programming-speed, stability, scalability ...), here is how:

5. Complexity of setup is not counting for evaluation

So, setting up an environment to evaluate the new programming language will last one to two hours (or even more)? Be honest: Setting up a testing environment for two hours is more easy than living with a not at all appropriate programming language for the next 6 month on a eight-hour-per-day-working-base in your new project. And of course you have to think about administration workload later on (which too reflects in evaluation, of course), but there are tools, workflows etc. which, done right, may help you to get rid of this point. Test the availability of tools, too.

4. The most hyped language may not be the best to choose

What is a hype (spoken in language selection)? Well, there is a new language out in the market. All people talk how easy and neat it is to work with it. Pretty cool so far. The drawback is that these languages are not widely "broadcasted" out there, mostly information is sparse on both the language and the usage/projects done with it. Of course you may use it, but be sure not to see things through rose-colored glasses.

3. Programming for fun is one, doing a project the other thing

Think of team-working, releasing, "changing one little bit might affect many others (and how can I prevent/check this)". This will help a great lot in case the project gets bigger and you will have to hire new people.

2. Prototyping and "getting things done (as fast as possible)" is not your daily work

Of course, most bosses and clients want to see what you do as fast as possible. They are more eager to compare your work with their business plan than to hear "no, we are setting up servers/software/configurations - please stand by". But on the long trail, as a programmer, you only can win if your work is profound and, in best case, solves problem other peoples like your bosses and clients do not even think of now. Test your desired language(s) if they fulfill your own personal claims on that regard, then test the language if it serves well in a programmers team and client-centric manner.

1. A fool with a tool is still a fool

Do not blame the programming language if you run in first problems (at first sight). Search for other ways if your goal cannot be reached with your first shot. Use Google to find new ways and thoughts (a good test to show if enough people using it / documentation on how to use it is out there, too). And even if you used the language for some years and think that the new project does not fit to it, give it a try on Google/the community. There are other people who might help you to solve a brain-nut-problem, sometimes on-the fly.

Not sure what langauge to choose now?

Watch out! There are a couple of languages on the market. And there is no easy answer to this question, if someone provides you with an easy answer, be most careful! Evaluate some languages, program some more in the languages that reach the "inner circle" for you and never forget the old but true saying: Use the right tool at the right time.


Other "Thoughts on" and "how to" articles:

• 10 thoughts on successful server programming
• Thoughts on successful exception handling
• How to successful log in programming
• Thoughts on successful logging

Related posts:

• Different types of programmers