As a man of both theory and practice, the age-old debate on the “best” language rests in the hands of what programming theory is best. When I first started learning programming (using Logo on an Apple II, the C on a Sun Sparc Station 10), I thought I knew all there was to know. I was in second grade and I had already started to put a few languages to work. “All I don’t know is the vocabulary of a new language- I know how to program.”
Einstein put it best when he said, “We know nothing at all. All our knowledge is but the knowledge of schoolchildren. The real nature of things we shall never know.”
Learning how to program in a functional language really reminds us of that. To quote GIML’s Introduction for Functional Programming:
There has been a great deal of progress in recent years in defining methodologies and design techniques which allow programs to be constructed more reliably. Some would claim that object orientation for example builds on and improves on structured programming which undoubtedly contributes to a better process of software construction. Using a rational methodology software engineers can produce better code faster - this is to be applauded, however it does not bring us any closer to the goal of correct programs. A correct program is not just more reliable - it is reliable. It does not just rarely go wrong - it cannot go wrong. The correct program should be the philosophers stone for the programmer, the pole star of our efforts. Software engineering may allow the intellectual effort of the programmer to be used "more efficiently" however it does not necessarily give us accurate programs.
It seems almost idealistic to think we can make perfect software but that’s where computer science started- before there were big calculators to evaluate our line-by-line instructions on if/then. We wanted to evaluate what a problem is. If we can solve it. What the definition of a problem is. Programs are built on man-made logic.
I believe that computer science is quickly reaching its potential in its current form. We haven’t really changed architecture in a few decades (though we have made things faster and smaller). We haven’t really changed the way we program in a few decades. And we’re no closer to achieving the level of AI that we once thought computers would possess. Our main downfall in software engineering is that it’s impossible to capture every case in iterative programming. This is where exceptions are thrown. This is where problems occur.
I can’t answer what the next leap will be, but I think it’s going to be a complete rethink. Back when LISP was invented, it was never intended to be compliable by a computer. It was only when a student managed to write a simple compiler in an iterative language that it exists today.
By definition our hardware is iterative. This is limiting since it forces us to think in terms of gates, ands, ors, and simple line-by-line logic. Maybe if hardware was rethought so it’s capable of directly running functional languages we’ll have our next breakthrough.
Machines need to look more like life if they’re ever going to compete with it. We need computers that make connections on their own, that can grow, that must learn.