|
Re: The Myth of Paradigms and TMTOWTDI
|
Posted: Sep 15, 2006 6:49 AM
|
|
> There are two big schisms in the programming community: > one along dynamic versus static type checking and another > along functional and procedural programming styles. I > believe that there is no real difference between these > so-called paradigms, and they are just different, but > limited ways, at looking at the complete space of > programming problems.
I do not thing dynamic/static is a "paradigm".
I also think the correct categorization is imperative vs functional, not procedural vs functional.
> The big reason for the functional/procedural schism is the > fact that computers are in fact machines that do separate > yet very important things: > <ol> > <li>perform actions</li> > <li>perform computations</li> > </ol>
Not really. Machines only perform actions. For machines, computations are side effects.
> Consider that when you want certain kinds of computations > performed, functional programming is often the correct way > to do things. When you want to write a controller for an > assembly line robot then then procedural programming is > usually the best approach.
But all imperative languages can do computations in the exact same way (...well, more or less) functional languages do.
> This leads to a separate but intriguing question: why > aren't true multi-paradigm languages like Scala and OCaml > more popular? I propose that the fundamental problem of > being a multi-paradigm language is that there is no clear > correct way to do things. They suffer from the challenges > of TMTOWTDI (There's More Than One Way To Do It). This may > remind you of another reasonably succesful language, Perl, > which suffers from severe marginalization. It is a truly > multi-paradigm language, which is only used in a specific > niche.
Not really. The real reason is that these other languages don't offer anything significant over the mainstream languages.
My Java programs are usually correct from the first go. Isn't that an argument in favor of functional languages? When I was programming in C++, I had great pains with manual memory management. With Java these pains are gone, and 99% of the bugs of my programs are now gone. I have no reason to move to another language, and so are most of other programmers.
> Well then what's the answer? These issues seem to be add > odds with each other. I don't know the answer. Perhaps > mixed language code? Perhaps some unwritten language could > unify everything elegantly.
Actually all programming languages are essentially the same thing, and what differs is the amount of glue code need to be written in order to make a specific task.
Even functional languages are the same, because for any serious work you have to use the imperative style (i.e. monads)...
And the so-called "proof of correctness" of functional programs is just a myth: there is no algorithm to prove the correctness of another algorithm. I had to run my dissertation' program several times to catch the errors, although it was written in ML, and the program perfectly typechecked. I have seen my professors being puzzled from a deadlock that shouldn't be there, again in ML.
Object-orientation is nothing but pattern matching on different types: if your object is an A, do this, otherwise if your object is a B, do that etc.
Finally stack-based languages are also the same, with the only difference being that the arguments are implicit and on the stack.
Programming essentially comes down to being able to abstract the computations in your mind in order to see if the outcome is the desired one. And the abstractions are possible due to prior knowledge, because in some way or another, computations are similar.
And in order to back this last statement of mine up, I will use the factorial example in another thread that we tried to analyse and find its input / output values: the only reason we expect a positive return value is because we know we only multiply positive values. If we did not know that, we wouldn't know what to expect, and therefore we wouldn't know how to analyse/prove the algorithm's correctness. In a sense, we already have done factorial in our minds, and we simply project that knowledge over our problem. Since programming involves unknown problems of high complexity, there is no way to prove correctness of anything.
Therefore the reason that other "better" languages are not adopted is that they do not offer something so advanced as to really change the way we are programming. I have often heard functional languages supporters claim that "once the program typechecks, it is usually correct". Well, guess what? that happens to me with Java as well; and to my colleagues. So why should I learn Haskell or Ocaml, for example? just to type a few less characters? it really doesn't matter any more...especially when the Java platform solves so many problems of the Haskell side (libraries, support, documentation, etc).
|
|