Hmmm. What is this lad thinking, you might ask... Yes, I was/am a programmer by trade, but more and more, I'm thinking that 'programming' as it was is going away.
Give me one good reason why I might need to use a text-based programming language to produce a program. You might say the most obvious answer, which would be that that's the only way you can do some things. Sure. But it doesn't have to be this way.
You may need to enter formulas or mathematical functions for special applications, but since VB everyone knows that UIs don't need to be coded. 99% of other tasks are similar. They can be handled by machines. The user need only manipulate a code-generating application.
I am constantly frustrated and dismayed by the sight of numerous programmers writing complex buggy code to access a SQL database. Doesn't this strike anyone else as a total waste of time? Anything as simple as a database should simply communicate automatically through a protocol to other software components. The code-generating application should handle all details of the protocol, unless tweaks need to be made, in which case they should be made as settings in the code-generation app.
Money is wasted whenever humans do something that machines can do, regardless of how well the machines do it. I could hand-code assembly routines to do a number of things, or let a compiler do it worse. In the end, it really is a waste of my time unless the difference between my code and the machine's code is significant to humans. Currently, it's not.
Is the difference between human-coded and automatically generated data objects that hide a database layer significant to the end user? Absolutely not. Must we hack macros and templates in C++ to avoid all runtime calculation, making our programs scream? Almost never.
Humans should only be coding the things that machines still cannot do at all. Once they can, and no one can tell the difference in the end product, we should move on and apply our expertise somewhere else.
Programmers don't want to think this is true. Unfortunately, the trend is undeniable. The future of programming is VB, Cold Fusion, Flash, etc. 99% of the work in a design app, 1% in code. This is the only way to leverage our knowledge and stop rewriting algorithms. We let the machines do it. I want to say it's really a shame, but I'm not sure exactly what will happen to all the programmers out there today... Maybe all the good ones will just end up writing games, doing research, writing code-generation apps, or doing something else...
Good luck, amigos...
Trev-
For certain applications, code generation via non-text interaction would be quite useful and has been done in several cases.
My personal favorite in terms of its ambition is AVS, which allows you to assemble a data flow model with the intent on processing standard datatypes into customized visualizations. Everything from simple 2D graphs to full hardware-accelerated volume rendering has been implemented.
If you ignore the text interface, Matlab is also on the edge of what you're envisioning. They've managed to abstract matrix manipulation _almost_ to the point of being an extension of your thought process. Many a PhD owes thanks to Matlab for keeping tedious code out of their lives and letting them graduate a little earlier.
The issue with both these development toolkits, as always, is speed. To make them truely abstracted, many high-level decisions have to be made. This implies run-time execution, which, well you know the deal. Matlab can be compiled to C, which I've heard really helps it out. But when you start going for speed, if you're not just trying to get some nice performance numbers for your thesis, you're probably implementing some commercial application. Then you get into licensing code. Yuck.
In the end, as you mentioned in your post, I see databases as the best candidates for this kind of interaction. But for all programming cases, there are several obstacles:
- In most cases, programs are unique in what they are inteded to do. Though UIs and abstractions can help to some extent, in the end the specification of your application will win out and you'll have to dive into some sort of finely detailed description. Right now, that's code. For databases, it's SQL. You probably want it to be Lojban.
- Though reusable components of an a given application can be coded optimally performance-wise, the connection between those components (which you are specifying) is often the slowdown. A way to optimally compile run-time logic needs to be in place.
- Who will code the large abstracted components to a given application? Who will offer them for free? Who will maintain them? Will there be some sort of independent Consumer's Reports for code chunks that evaluates correctness and stability?
- There are always better ways of doing things coming out. Especially algorithms that are primarily mathematical. Volume rendering is emerging faster techniques all the time. Who is going to update this widely-used codebase to the latest discoveries? If I just invented a new raytracing engine, do I want to blow my whole wad and give it away?
- Hardware-specific code like using accumulation buffers in your 3D card for projection modeling versus summing it in main memory needs to have some sort of intelligent placement in code so that it's there when needed and only when needed. If we start trying to make things optimal, portable, and abstracted, we've got some BIG code on our hands.
There's many other issues too. Compilers aren't my field, but Ken and Mike over at GreenHills would probably spew them out like nobody's business.
Remember, programming isn't just about learning how to speak the syntax. It's about knowing how to be unambiguous, how to specify things explicitly, not implicitly. And in the end, it's about manipulating binary switches in a state machine to do what you want. It is a TRANSLATION problem, both in thought and in language and though we invented the machine, we are nowhere near having the machine know how to translate automatically from us to it.
As far as everyday life goes, bugs and mitigation of those bugs play a major role. They suck. But on good days, when I'm using a lot of code that I've written and have proven and have created a nice interface to - then it's almost like talking to the machine, and life is good.
Interesting points, Rich... ;)
So, of course currently there are some major areas you mentioned where this is difficult.
With respect to hardware, I think we need standards for self-discovery which cache information after the first 'meeting', and ways for devices to communicate their capabilities all the way up to the developer in a high-level environment. The drivers basically need to include a compiler plug-in which allows a high-level environment to compile code for it. Someone would still have to write drivers, but coding for new hardware is never going to go away.
Compilers have to get better at reducing run-time calculations to compile-time. This has been a long slow process because it's technically difficult to get right, but I'm sure they'll continue to get better and better.
As for costs and licensing, I'm sure that someone will eventually realize that they can make more by reducing their licencing fees than by keeping them sky-high, and after that we'll see it become more widespread.
As for code being optimal, this requirement becomes less and less important every year. Not that it's never important, but IMHO,
lim[t->inf] (value(speed(code))) = 0
because the value of code speed is inversely proportional to the speed of general-purpose hardware.
We're not going to see everything change soon, nor will all areas of programming go this way (e.g. drivers), but I do think that eventually we'll find, maybe 100 years down the road, that our bad-ass quantum processors can do anything as well as special-purpose hardware, and most code just has to be correct, and do the job in polynomial time, but not necessarily 'fast'.
Posted by: Trevor Hill at October 23, 2002 03:55 PM
Hello VB
Posted by: Vijayendra at January 28, 2003 01:46 AM
Posted by: Rich at October 23, 2002 10:04 AM