Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management

From: Robert Strandh (
Date: 07/16/04

Date: 16 Jul 2004 07:43:07 +0200

"Jörn W. Janneck" <jwjanneck at yahoo dot com> writes:

> > Not so. First, the uniformity exists, partly because software is a
> > "winner takes all" market where a slight initial advantage rapidly
> > translates to market domination.
> hm, it seems you *do* assume that there in fact *is* an initial advantage?
> and how do you explain the veritable zoo of programming languages out there
> by the "winner takes all" theory.

You seem to be thinking that I am referring to programming languages
as having initial advantages and winning. In fact I was referring to
software companies.

Uniformity exists partly because a company has made some initial
(sometimes arbitrary) choice. Others then follow because the that
company is successful.

> but given the observable fact that programing languages come and go,
> sometimes within a decade or so, it wold seem as if the market has both
> sufficient dynamics and sufficient variation to perform selection on.

It might seem like that, but I suspect you give much more credit to
the ability of the market to come up with good things than it

> saying that the market is not rational is almost like saying that people are
> not interested in money.

I do not know where and when you studied economics, but most
economists these days know that the market is not rational.

> remember, the products of the market we discuss
> (programming languages and corresponding tools) are themselves tools, used
> to produce other products (i.e. applications, operating systems, controller
> software, ...) whose customers most likely could not care less about the
> tool used to create them. and it is *those customers* that effectively speak
> the ultimate verdict on what tool *users* are successful, and hence whether
> tool *suppliers* produced sufficiently good products.

I am not sure what makes you think this is true.

Software has almost no unit production cost. Therefore, the cost per
unit is approximately inversely proportional to the number of units
sold. If company A uses unproductive tools and sell X units of some
software, and company B uses tools that make them 10 times as
productive, but only sell X/20 of them, then A is going to produce
less expensive software.

Furthermore, A will influence the choice of tools of other companies,
the tools that are taught in schools and at universities, so whether
the tools that A uses are good or bad, they are going to dominate the

Before there were pure software companies, new languages became
popular because universities used them in teaching (Pascal, C). Now,
many new languages become popular because of huge investments in
marketing and development (Java, C#).

The quality of those languages, as measured by productivity almost
does not enter into the equation at all. Obviously, if a company were
to develop a new language that is considerably worse that what is
currently widely used, it might fail. But the fact that there might
be even better languages out there does not influence the market at
all, especially of these better languages are only used by smaller

> but you do not have to measure productivity differences in order for them to
> exist and make a difference. what you say above may be a problem for
> statisticians (and i agree, it is a very big one---software productivity
> data is for the most part pretty useless), and it may also be a problem for
> companies and the developers, but it is not a problem for customers---if you
> can build a comparable car at half the price, you'll get my business. i
> don't care whether you could *predict* that your tools would make you more
> productive, or whether it was pure fool's luck that made you make the right
> choice: your car costs less than the car of your competition, so i'll buy
> it.

The big difference between cars and software is that the cost of a car
is dominated by its production cost. Therefore, the unit cost is
going to be largely determined by how productive the company is. As I
said above, this is not the case for software.

> and granted: for the consumer products as well, there are of course also
> network effects that may superimpose onto the productivity differences, and
> even overwhelm them. but that does not change that more productive is always
> better than less productive. even a monopoly provider is interested in
> producing the same features faster. of course, if you actually *do* have a
> monopoly the pressure to worry about your productivity is lower, but it's
> still a matter of having more or having less, and given that choice, most
> people opt for more.
> (but clearly, in the case of monopoly, they are no longer compelled to
> choose, and so my market reasoning fails there. the only force that makes
> them choose is their own greed, and it is quite possible that their
> ignorance is greater than their greed.)


> true, but that is a lot of ifs. i do not believe that most choosers are
> ignorant of better technology (at least not when you consider whole
> companies, or perhaps divisions in them, as choosers, rather than individual
> programmers), and "most" would actually not suffice---it would require
> almost all choosers to be ignorant.

I have seen dozens of software companies in several different
countries, and I have seen only one single company that is not totally
ignorant of technology such as dynamic languages. I am therefore
prepared to state that almost all choosers are ignorant of better
technology. In fact, it is sometimes pretty spectacular to see how
they waste time and energy on bad methods and tools. Even more
spectacular, they are not willing to improve.

> i also don't think that the market is
> incapable of picking more productive tools, because it is picking (new)
> tools all the time, and there just does not seem to be a good reason why it
> should make the choices it clearly does make in favor of less productive
> alternatives.
> but admittedly these are judgments, so we might have to agree to disagree
> here.

I think we do.

Robert Strandh
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.