February 01, 2005
The state of art sucks
There is a friendly discussion about the philosophical implications of the halting problem going on over at Netalive. I thought you might enjoy the following, slightly off-topic rant I contributed. Quoted is Neil Harmon, another Netalive user.
At least for me, it's hard to imagine a better programming language than the ones we already have.
Personally I am dissatisfied with the current state of language design. I don't have the overwhelming feeling that we're closing in on the best way. The state of art merely seems to be the result of many next logical steps stacked on top of each other. There is little overall concept to what we do. We’re nailing planks together and seeing what happens.
Of course it is hard to imagine something better, because we immediately associate "better" with "improvement to what we have" and the obvious improvements have already been implemented. No one can come up with something radically different on the spot.
What can't you do with today's programming languages if you had enough time and resources?
Even if I could do everything with the languages we have, it doesn't mean there isn't something vastly better. The biggest problem in software design is currently the fight against complexity. Even when implementing mildly extensive requirements complexity grows over our heads much faster than one would intuitively think it would. Object oriented design and, more recently, aspects, have taken away some of the pain, but what remains is a strong suspicion that there has to be a better way.
Also you can only throw so many people and resources against a problem until time required for coordination reaches some sort of equilibrium against productivity. And even unlimited resources do little to banish the scourges of complexity, increase of coupling and loss of cohesion.
Comments
The overwhelming success of OOP has a part in this, though it is not really to blame in itself. It is not actually a paradigm in itself any more than structured programming is, but rather a modelling methodology. It has helped to mount contemporary complexity levels, in implementing these models, we are still using the same paradigm we started with 50 years ago: imperative programming. Alternative approaches have fallen by the wayside to a degree. Functional and logic programming in particular are way underestimated, though would be much better suited to a number of problems.
