This is a reply to smi 's article Developing a state of the art Web Application.... I just picked out the paragraphs that I want to criticise here, so if you want to get the whole picture, you have to read his article before this one.


Ok. First things first. Talking about Platforms is really not necessary. One of
the fields where we can truly stick to is that no application in this world
needs a specific OS to perform well. There are other reasons, such as
scalability, security or existing environments to choose platforms wisely, but
don't believe anyone who wants to convince you that you can only build great
applications using, let's say, BeOS. Those days are over.


if we are talking about operating systems here, I totally agree. But platform is
one of these "usemeforeverything" buzzwords (actually, I think it is THE
usemeforeverything buzzword right now).

When people use the word platform in context of web development, they usually
don't talk about operating systems. They probably talk about writing their
applications on top of the Java platform, or the dotnet platform, the oracle
platform, the cpython platform, the websphere platform, the helma platform,...

And I think we both agree that the choice in these platforms have a big impact
to your applications success.


So assuming you found your environment of choice (I hear techies in our office
argue for different Linux distros every day, so the paradox of choice definitely applies)


I also hear (and read) many of these discussions, but they are hardly ever about
productivity in web development. They are most often about ease of
installation/administration or desktop environments. The only people that argue
about what operating system is better for developing web applications are ASP
and ASP.NET developers (because the choice of operating system is crucial here).


We here at Knallgrau use Helma every day, for several reasons, but wait, we said
first things first. The question in my head was: "What would one search if
she/he had to choose a application framework for a specific task?". And I think
that the following criteria work for both, programming languages as well as
whole application frameworks. Some points apply to both, where necessary I will
make some distinctions.

Here are my considerations, others are (as always) very welcome:
1. Popularity: Sure, you don't want to use something nobody uses. Using a
programming language like Whitespace may be fun first, but as soon as you
want to move your personal boundaries you might run into problems.


Whitespace is rally a bad example here, because it is a pure fun language that
was not designed to be used in real world applications.

But isn't its lack of popularity a big no for using helma? There are only a few
companies that use helma, and development with helma is very different from most
other popular web frameworks out there.

However, companies like knallgrau are still using it, because they think that
the advantages of the platform out-weights the learning curve for new employees
in the long run.

We humans tend to learn by imitation (at least half of the time), by just
copying things of others that help us to understand how the whole thing works.
We have to nearly "touch" it, to grasp its nature. So that is one reason why
popular things get more popular and unpopular things stay unpopular. Because
imitation is what we are designed to do.

But we never out pace our masters that way. Learning by imitation means that we
also copy errors, and then we produce memes of bad practices that are copied
over and over by each generation.

Humans learned by imitation to avoid fire for millions of years, but they did
not advance before they broke that meme and tried to control it.

Counting on imitation is also the reason why in the 90ties, hundreds of search
companies where focusing on storing large amounts of websites, instead of
focusing on ranking the results.

Learning by imitation can be a good thing if
you want to keep up with others, but it also means that you will never leave
them behind.

But don't underestimate the Geek Factor. No matter if you are a techno
Geek or a English literature Geek, there will always be people that prefer using
some unpopular language, just because they can. Just to be different.

Hmm, since some languages I like to program in are not very popular, I'm somehow
feel like your talking to me here. And, no offend, I think its somewhat
adventurous to claim that the only advantage to use a language is "to be
different", if you did not take the time to study the language by yourself.

Just imagine how difficult it would be to explain the benefit of higher order
functions to a Java developer: "Why would I need that? " he would claim. "I can
use the Command Pattern for that". But in fact most Javacript/ruby/lisp/PHP
programmers would argue that programming would be a pain without them.

If you don't know languages like ruby or python, it is similar hard to get the
advantages of things like Meta programming, without making experiences with these
features first.

The reason why I'm trying to learn a new language at least once a year is
because I think that knowing many different language designs is a necessary
step to write good code in the few languages I will end up using at work. It is
also important to learn by imitation, because a lot of interesting concepts in
software programming is written in languages other than Java or PHP.


4. Powerful: No matter if you think of programming
languages or frameworks, you'll almost always would want to have a powerful
tool. Something that eases the tasks you have to perform. Be it the object
relational mapping of Helma or Ruby on Rails. Or the special MySQL functions
that PHP provides. Power is relative to your task, but you definitely want
it.


Agree, except that I don't know what special MySQL functions PHP provides.


5. Maximum Overview: Also no matter if it is a framework or a language you
have to choose, you want a maximum of overview about the architecture and the
individual code. Why? Because you want maximum control over it. Thats one of
my objections against Ruby or Perl or Haskell and a point for Java,
Javascript or PHP. If you read a little bit of source code you'll grasp the
what in a minute.


You have a strange way to mix languages together here. I guess most people would
put PHP and Perl together in their own "produce fast to write, hard to read
code" box. And Javascript is somehow even more confusing than these two, but I
think I need to write another blog entry for that topic.

Sure, one can argue after a little bit of
programming you'll know the language anyway, but I suppose that this doesn't
count as ease of use having to use something for a while, or reading through
manuals for hours, just to grasp what it does. I managed to use PHP within days
in a productive matter without great skills in programming a few years ago. I
would say my skills haven't radically improved, but reading PHP or Java code is
definitely easier than reading Ruby or Rebol.

No, its not easier. It's just that PHP and Java's C-like syntax (i think this
is the ALGOL family) look familiar to you at first, because you had experiences
with other languages that use that style. If you had studied at MIT, where they
use Scheme as an introductory language, you would probably have a better start
with Haskell than with PHP.

As a fact, what you write down in these languages is often very different
from what you where thinking of in the first place:

You rarely think like this:

"I want to create a variable that starts at zero and increment it by one and
multiply a variable n with 25/100 as long as that variable is smaller than the
number 10000000000."

You would rather think "I want to increment that number by 25 percent, 10 million
times", and the Ruby solution is much closer to that than what one would do with
PHP:

10_000_000_000.times do 
  number += 25.percent_of number
end

Ruby is a very simple language. For example, it has only 38 reserved words in
the language specification, while PHP has 72 and Java has 50. The language is
designed by only a few rules (like "everything is an object, and you talk to
objects by sending them messages"), with little or no exceptions to that rules.

In Java and PHP there are rules too, but to explain them you have to append a
lot of "except if..." to your explanation. And this makes it very hard to
understand code written in that language.


I see a programming language as some kind of barrier between me, my coworkers
and the computer: I have an idea how to solve a particular problem, but to make
my computer 'understand', I first have to translate it in some cryptic syntax so
some compiler/interpreter can translate it to some even more cryptic syntax,
until the machine can execute the code.

And, worst of all, what I'm writing down is also the most important
document that tells other developers what I was trying to do in the first place.

The reason I like Ruby is not because it is a language that many people don't
know about. In fact I wish the language was more popular, so I could use it at
work more often.

I try to use Ruby in many situations because I believe that it shortens the time
It takes to produce, modify and explain the code, so I have more time to focus
on more interesting things.

As an example, say you are writing some graphic framework in Java. At some point,
you decide that you need an object that describes a single point in your (lets say 2D)
environment:

public class Point {
  public double x;
  public double y;
  public Color color;
}

This works, but to shorten your client code, you add some constructors so your
point can be used more convenient:

public class Point {
  public double x;
  public double y;
  public Color color;

  public Point(double x, double y, Color color){
    this.x = x;
    this.y = y;
    this.color = color;
  }

  public Point(double x, double y){
    this(x,y,null);
  }

  public Point(){
    this(0.0,0.0)    
  }
 
}

fine. But we cannot do it this way, because if we want to keep the option to add
additional behaviour on how to get or set the members of a point. So we need to
encapsulate them into getter and setter methods:

import Java.awt.Color;

public class Point {
  private Color color;
  private double x;
  private double y;

  public Point(double x, double y, Color color){
    this.x = x;
    this.y = y;
    this.color = color;
  }

  public Point(double x, double y){
    this(x,y,null);
  }

  public Point(){
    this(0.0,0.0)    
  }

  public Color getColor() {
    return color;
  }

  public double getX() {
    return x;
  }

  public double getY() {
    return y;
  }

  public void setColor(Color color) {
    this.color = color;
  }

  public void setX(double x) {
    this.x = x;
  }

  public void setY(double y) {
    this.y = y;
  }
 
}

The stupid thing with all these get and set methods is that we currently do not
need them, maybe we never need them at all. But if we at one time decide that a
point may not have negative values for their x and y members, we would have to
change all client code that uses our framework to change their calls from
point.x = 5 to point.setX(5). So we had to instruct our IDE to insert all these
additional methods just in case we want to use them someday.

in Ruby, we would accomplish the same thing with

Point = Struct.new(:x,:y,:color)

So what? We had to write some constructors in Java, and our IDE was generating
the get- and set-methods for us. No big deal.

Well, it is.

Consider you have finished your framework that includes dozens of these class definitions. Then,
one month later, you go back to the code to fix a bug or implement a new
feature. Of course you don't know anything about that code anymore and why you
did things they way you did them in the first place. In your Java
implementation, you now have to deal with thousands of lines of code, while in
ruby you have maybe a few 100 lines. The clue is that although you did not have to
write all these lines by yourself, you still have to understand them all.

You are now wasting ~8 hours for something you could have done in ~1, just
because that Java/PHP syntax looked so familiar to you in the first place.