Programming Languages Analyzed, Web Edition

Quite a lot of time passed since my last post. My job and my family are taking up a lot of my time that should be spent on my future business. I promised in a comment that I would do a web edition for the Programming Languages Analyzed post. Since I haven't used web technologies in the last three years, I had to look up a lot of things that appeared in the mean time: AJAX, Ruby on Rails etc. So, without further ado, here we go analyzing the programming languages and their associated frameworks that are used for building web applications.

The most important language, for a modern looking web application, is JavaScript. You can get around most of it if you use some another-language-to-JavaScript translator like GWT or pyjamas. The problem with JavaScript is described perfectly in this quote from GWT:

"Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatibilities between web browsers and platforms, and JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile."

Unfortunately, if you need some special JavaScript trick, you really have to understand the language and the browser quirks that go along with it. Using one of the many AJAX libraries can help reduce the common problems.

For the server part, we can use many languages and frameworks. The most important factor is, again, easy-to-use, since we still would like to concentrate on business problems instead of technical ones. The second factor is speed, though it's not as important as in a desktop application (network delays usually far surpass the server delay). More important than speed is scalability, but this is also dependent more on the application design than actual language, though some frameworks might constrain the design. Portability, size and reverse-engineering-potential are non-issues if you host the web application yourself, but if you intend to distribute it as a product, they will be as important as for a desktop application (well, size might not matter much in this case).

.Net/C#/ASP.NET is one nice platform, with clear separation between code and HTML, though the resulting HTML and JavaScript are not very nice. You can also use a nice AJAX library, which is nicely integrated with the rest of ASP.NET and speeds up development considerably. This combination only fails on portability (maybe not, Mono might help) and reverse-engineering.

Java is quite similar to .Net, with a lot more frameworks to chose from (Struts, Spring, JSF, plain old JSP etc.). Also note that GWT is designed to work with Java, but of course you can use any AJAX library. Portability is included by design, which is also nice.

PHP is the Visual Basic of the web world, and I say this in the sense that everybody knows it (except me), and everybody uses it, and the ugliest web code is written in it. Well, maybe except for Perl. Anyway, it has all the advantages (and disadvantages) of the Java and .Net worlds, with tons of libraries available.

Python is one of the nicest platform for web development, with a lot of frameworks to mix and match to suit your needs: Zope, Django, TurboGears etc. It also has all the advantages of Java and .Net, but with a much nicer language underneath.

Ruby and Ruby on Rails. If you like less libraries than Python, less choice and a Perl-ish language, Ruby does the trick.

Perl can be successfully used to write web applications and has the nice CPAN libraries to help. That's if you can get used to decipher line noise, because that's how the source looks like when you first see it. Of course, you can write line noise in any language, but in Perl it's the norm rather than a weird contest.

Programming Languages Analyzed

Since I'm not too keen on selecting or generating a product idea, I'll start my analysis a little backwards. A couple of days ago I talked about having a barrier to entry and I think I found a good one. Today, I'll try to analyze the programming languages I know in the context of selling a product written in that language.

The most important point of the language should be easy-to-use. That should help me concentrate on the business problems and not on problems like memory management or lack of libraries that I need. One thing to note about the libraries is that they should be commercially friendly, so no GPL licensed libraries (LGPL is okay) or non-royalty-free libraries would be considered. The second most important point should be speed. Since my barrier to entry is neural networks and evolutionary algorithms, speed is quite important because these kind of things are computationally intensive. Also nice to have would be small-size. I would like to NOT have to drag around a big runtime like .Net or Java, because I would have quite an unpleasant time writing the installer (installing 3rd party software can be tricky) and also would increase the download size significantly. Yet another nice thing would be portability. The ability to run on Linux and OS X should not be ignored. The last (and debatable) point of the language should be hard-to-reverse-engineer. Even if somebody will eventually crack the product and even if the people using unlicensed versions of the product would not be paying customers anyway, making it harder to crack your product should be on the list.

The C++ language fails slightly on the first criteria, since it has no garbage collection. But it has lots of nice libraries that can be used (boost etc), speed is almost unmatched, size is also good, portability can be tricky but doable and it passes the hard-to-reverse-engineer test with flying colors. Still, garbage collection is important for rapid development and C++ lacks it badly.

Java passes the first test quite well, having both garbage collection and lots of nice libraries. Also, portability is mostly taken care of, which is a nice thing. Unfortunately, speed is a little worse than C++, size is quite big, and it's easiest than most to reverse engineer, even if I use DashO (I've seen what it does and I'm not even remotely impressed, it's still easy to crack).

C# is in the same boat as Java, with less libraries (but the nice Java libraries are quickly being ported to .Net, so this should not usually be a problem). Unfortunately, it also has the exact same problems as Java: speed (faster than Java, slower than C++), size (bigger than Java) and easy-to-reverse-engineer. Hey, even the byte code obfuscator was ported for .Net. One last disadvantage of C#/.Net is that the crossplatform port is not exactly ready and stable.

Onward to more exotic places, Python looks like a nice candidate. It passes the easy-to-use test very well. Speed can in theory (and in practice) be addressed by rewriting the slow code in C++. Size overhead is much better than Java or .Net (about 5MB), and portability is also well covered. Unfortunately, decompiling it is also easy.

There are also other languages that I don't know well enough but I'd be willing to learn if they would provide a clear advantage. Ruby (with RoR) and Perl seems to be targeted at scripting and web development, which limits their applicability. They also seem to have the same advantages and suffer from the same problems as Python. Eiffel is a C++ (ok, it looks more like Pascal) with garbage collection and Design by Contract, but without the nice libraries. Lisp, Scheme, OCaml, Haskell look promising, but libraries are still hard to find and speed is sometimes not acceptable. Erlang seems to be optimized for concurrency, not for general software development. When I'll decide about the actual product I'll develop, I'll have to take another look at these last languages and see if they provide any decisive advantage, otherwise I'll use what I know best. The shortest path is the one that you already know.

Random ideas

I'm still trying to decide what product to build. In the meantime I'm reading a lot of articles and forums about MicroISVs, which should help me get acquainted with the usual problems that they face and maybe will help me avoid some traps along the way.

Some time ago I've read an article (sorry, I can't seem to remember where) that basically stated that there are actually two types of products that will be successful in the market and can't be easily copied by the competition. One type of product is based on lots of small and simple components that work well together; the trick to the "not easily copied" property is that there is quite a lot of code to write to replicate the functionality and, since all the components interact with one another, getting them to work well together and squashing all the bugs takes a long time. The other type of product, which is more interesting to me, gets its "not easily copied" property from the fact that it needs really advanced and hard algorithms to work well (think neural networks, genetic algorithms, compilers and the like), which means that the barrier to entry for the competition is actually finding the developers that understand all those concepts and algorithms. Apparently, these developers are rare, but I'm one of them.

Oh, I just found that article I was talking about and my summary above looks like I could still remember the essential points of the article about six months after I read it. Not bad. Since I am mostly interested in neural networks and genetic (evolutionary) algorithms, my idea is to use this as the basis of my barrier to entry of the "small body of clever code" type.

One area where neural networks and evolutionary algorithms can be applied is, of course, games. I think that it would be awesome if a computer controlled enemy in a game would actually learn and adapt to the style and strategy of the person playing the game. If this would be implemented properly the cheating "AI" in current games would fall out of style. On the other hand, building a game means much much more than a nice AI and I have no experience or talent for designing nice graphics and sounds. A smart-but-ugly game will always lose when compared with a not-so-smart-but-good-looking game.

Another area where neural networks and evolutionary algorithms can be used is in stock trading applications, particularly stock price prediction. They can either be used directly to estimate the future stock price (see for example this article) or to find patterns in the stock (akin to what this article describes, see the comment for the nice details).

Actually, you can expect to find these algorithms everywhere.

First post ;-)

Following Ian Landsman's advice, I decided to start this blog. I'll be posting about how I'll try to start a MicroISV and I hope it will be an interesting read.

At the moment I don't have any idea about what product to build. Maybe I should start some brainstorming like Benji Smith, although I don't think I can manage to get 30 ideas in 30 days (and neither did him).

The "short term" goal of the MicroISV should be to replace my job, so it should bring enough money to be able to sustain me and my family. The long term goal is to be determined. ;-)