Great Hackers 10x as Productive
Thursday, 20. December 2007, 15:21:37
In this other blog, there's an article about why this person believes Paul Graham's assertion that great hackers are 10x as productive. First off, functional programming and hacker being used in the same sentence is rather odd. That's completely alien to me. I knew quite a few hackers and none of them used functional programming. And for good reason. You'd never get anything done and most software came in binary. And if you had a machine big enough to use functional programming, then you weren't really hacking. You had privileged access to local hardware that contradicts the notion of being a hacker. In any case, today you can use whatever you want. I just feel that the term has been diluted and that getting your definition of hacker from Paul Graham is laughable.
The author really is going all over the map (no pun intended). He seems to be on a journey of discovery and that's to be commended. Here's one striking quote.
Before Ruby, I'd used for loops over and over again, never really thinking that I could abstract a for loop. It wasn't until they were taken away in Ruby did I realize that map, inject, and their cousins are all abstractions of the for loop.
Many functional programmers say this. I don't know why they think map is a functional construct. It's a limited version of data flow. In fact, everything that functional programming can do comes from either data flow or imperative. An abstraction is meant for something that you need and want to handle in a simpler manner. The only reason you need loops is if you use imperative programming. Data flow has no need to do this. So there is no abstraction for loops. It just operates differently. The error here is thinking that functional programming gives you something unique. There is nothing unique in it and you can build a functional environment from an imperative one by restricting what you can do. This alone makes functional closer to imperative than most would want to admit. Recognising what the tools really are and what they can do is what makes for being a better programmer.
A great hacker will take the initial time upfront to create this generalized code, and will save in the long run being able to use it.
Uh, no. I think this definition of hacker is wrong. A hacker has sets of tools. Not sets of programming idioms. There's a difference. When a hacker sits down to code, he doesn't need a library or pre-built code. He will usually have it. But he doesn't need it. So this is NOT what makes him faster.
Done over and over again, it all adds up. So it's not that for any given problem, a great hacker will be done in 4 hours what it takes an average programmer 40 hours, but that over time, a great hacker will invest the time to create a tools and vocabulary that lets him express things easier. That leads to substantial savings in time over the long haul.
A great hacker is exactly the opposite of this. They are fast on that instant. Not a little faster on every item that accumulates over the long haul. There is simply no other way the hacker knows to be but to be fast, right now, all the time, by at least 10 times.
I still believe you should know how things work underneath the hood, but afterwards, but all means, go up to the level of abstraction appropriate for the problem domain.
Out of the entire article, this one sentence that he casually tosses out there is actually closer to the truth than anything else. A hacker is one who knows the hardware inside and out. So that when they use high level abstractions, they can feel and sense the code that will be output at the hardware level. This is what makes them fast. Imagine that by flipping a few switches, these were attached to mechanical machines that would construct an entire 20 story building in under an hour. At every step, the person manipulating the switches would be fully in control of the final results at the lowest level. THAT is why a hacker is fast. They can see THROUGH abstractions all the way down to the hardware. But they also recognise that certain parts don't need that much attention, but that's no longer hacking.
DSLs (Domain specific languages) are really just tool-making and vernacular creation taken to the level of bending the language itself.
Still doesn't get it. DSLs aren't about bending the language itself. It's just about being able to control another environment. Not related in programming faster though it certainly can give you easier and more uniform control.
It was with this in mind that I did a talk on DSLs this past weekend at the local Ruby meetup.
A talk!? OUCH!
This is what really gets me.
secondly, and more seriously, learning a new programming language makes you think differently about problems.
Really? You think differently about problems? I don't. Never have. Languages get in the way. They don't actually help. The less they are in the way, the faster you can code. There's this imaginary thought that programming faster is due to the language. Here's a little secret. By the time a great hacker sits down to code, the programming is already done no matter the language. It's now only a matter of time until all the code has flowed from the mind and into the machine. The speed at which this happens is irrelevant because this is not what makes the difference in speed. It's the process that came BEFORE typing.
So picture this. You figure out in your mind or with the help of a few notes what you're supposed to do. No pseudo code. Maybe a few data structures and a list of what needs to be done. Work out what needs to be done. Then when you sit down, you have to mold what you want to do to the tools you are using. Whatever they are, they do not matter that much as long as the language doesn't protect you. Protection means hindering my ability to see transparently through any abstraction. It means that I cannot mold what I need to do to the language since the language has now become the platform. This is bad. It's really bad because the language is not what runs your code. It's the machine. For great hackers, it makes no difference what the ultimate destination of the code is, so why not just use the hardware directly? This is why hackers write their own tools. They know what it does. If you use someone else's language or toolset, then it slows them down. They must relearn how the abstraction works. Like I said, the tools and languages aren't the important points.
The best I can describe languages is like this. Say you want to go to Toronto. That's your program. You want to be IN Toronto. The rest is details. So when you sit down to actually go to Toronto, you have many choices where you adapt your plan to the specifics. But whatever it is doesn't matter. If it's a bus, then you have to go to the bus station, buy your ticket and wait for the bus to leave. Same thing for plane or train. If you drive, well, you have to check your oil and gas up and choose a route. Whatever the details are (programming tools, libraries and languages) are unimportant. This is NOT the program. The program is being IN Toronto. The final code is ONE such representation. This means that I always see ONE and only ONE goal when programming. I NEVER think differently. The details (programming languages and libraries) can slow one down. But it can NEVER make you faster. This is why I'm writing Project V. The main reason I gave is that C++ is slowing me down. And that there are no languages that get out of the way more than C (which I also use). By using pluggable components, the framework will get out of the way even more and I can concentrate on the new stuff.
I really do get the impression some people think there is one best way to create something or that what you specify in the machine is "the code". It isn't. It's one possible version. In the days of real hacking, there was always a quest to find the best possible version. But we all knew that the hardware is what determined this. Not anything the human could think up. In today's world, we think that the language should be the environment. Why this came about is rather strange. But it makes sense if you think of regular programmers as users. Like how most people just want to drive a car that has an automatic transmission. They don't care about how the car works. They just want to drive it around. That's a user. If you want to use libraries and whatnot that makes repetitive tasks easier, then you're a user. A hacker doesn't do the same thing over again, or at least doesn't want to. If he does, then he will want to hurry up because it's so damn boring. Hacking is about doing something new that no one has done before (or in a way that no one has done before that has tangible results beyond the programming of it). So the earlier explanation that the language or toolset is what makes a hacker faster is flawed because the hacker is doing something new.
So if you go about programming in a way that decides what tools and how you are going to translate the objectives into actual lines of code, then you are not programming. You are dealing in logistics, but it's not programming. If you're convinced that I'm wrong, which is perfectly fine, do not be surprised if you find yourself struggling to "program" faster. If you believe that programming happens in front of the computer, then it should come as no surprise if you find yourself looking for better techniques.
The only further clarification I can make is this. If you have a set of goals and a set of hardware, then programming is deciding how those goals can be converted to an interconnection of hardware and sequence of operations. Where I think most people get tripped up is that they think the conversion process happens with a language. They think in terms of the tools when they should be thinking in terms of the hardware. The tools hinder and get in the way of the conversion process. When I hear that people think in new ways when they learn a new language, I know they're slow. Maybe not in their favourite language. But if they ever need to do something new, they'd be lost. The tools and programming languages are a means to an end. They are not what's used for programming. Anyone that uses a programming language to program just doesn't get it. At that point, the programming's already done. It's now only a matter of details (which is NOT programming).
WIDGETIZE
If I were cutting down a tree, I'd prefer to take my chances with a modern chainsaw, rather than use a simple axe. Same with C: you don't have the full range of tools. It's like trying to build with hand-axes and shovels - sure, it's possible, but why take the trouble when you have chainsaws and diggers?
I guess I don't understand what you're trying to say. What makes getting close to the hardware and using C so much better than a language like Ruby? Heh, aside from speed
By anonymous user, # 20. December 2007, 21:52:06
Let's use your tree analogy. An axe will slow you down a LOT. A chainsaw will slow you down a little. But this isn't the goal. The goal is having the tree down. It'd be best if you arrived and the tree was already cut. Having to cut it down is something outside of what you want to do even though it's necessary. This is how I think about programming. I don't think about the necessary parts that fall outside the objective. These are details that can be worked out when you start typing. Any language will do. In short, you write the whole thing in your mind in a generic fashion. And then when you type it in, you convert your generic program into whatever it is you're using.
Here's perhaps a better way to explain it (though it's not quite accurate). Is taking the bus travelling? Is taking a plane? What about a taxi? They're all methods of travel. Same with programming. Is C programming? Is Ruby? Or are they methods of input (aka languages)? I have a feeling most people mold their way of thinking to the way the language works instead of just having their own way of doing things and then converting that to the programming language they are using. If you do the latter, the language has very little effect on your speed.
About C (or C++), I prefer it simply because I don't have to take anything on faith. I know exactly what it's going to do. And with C++, you can write perfectly safe code. RAII with exceptions works quite well and cannot crash under any circumstance (though I rarely use exceptions because they are slow). So there's nothing in other languages that I find necessary (though I wish C++ came stardard with closures and properties, but the version I'm using already has them).
By Vorlath, # 21. December 2007, 05:04:55
When I start a new Project, it takes me 1-2 months of walking down the streets - then and back - thinking out all things about the project design before I write even one line of code. It looks quite crazy from aside. But this is a main part, which I call Programming. Sometimes I even spend 2 or 3 sheets of paper for various draft schematic pictures. After that phase it almost done. Then it comes Coding. It's just a routine job which I have to pass through as quick as possible. And it's not very exciting, - rather annoying and boring.
So I could enumerate procedures which I count as NOT programming:
1. Fighting with tools, finding ways out for workarounds and bugs.
2. Optimizing innermost loops for better performance (yes, it's just a method, but not a goal of a project)
3. Tweaking with various issues in the code. Making it better and faster.
4. Finding out border conditions, fencepost errors and race conditions.
5. Making the code structured better.
6. All other things which coders like to do with their code.
7. Writing sophisticated and complicated constructs just to be seen by others.
Maybe I have a strange look at Programming, but thats it.
By vladas, # 21. December 2007, 06:58:59
Took a while to see what you were on about, but I do agree, and you've hit the nail on the head for me. If you want code to run fast, you have to deconstruct everything that the language is doing, so that at best, new language features are simply convenient ways to do something that you might have done anyway; at worst, they add overhead that you don't need.
By anonymous user, # 21. December 2007, 11:04:37
The key part of functional programming is that it can use functions as data types. Java doesn't know about map or functions, so you need a handful of crud to perform a loop. map hides that crud. That prevents a lot of bugs that happen when writing out the crud.
The largest improvements to productivity come from removing the need to write code, because code is buggy. If I were writing in Ruby, should I care that 'x' is a VALUE* that could end up in EDX at some point on IA-32? Should I worry about how many bytes the VALUE* takes up, compared to a native int? That would only consume space in my mind, taking away from what I could be using to solve the real problem.
Smaller code is also easier to rewrite. The future is unknown, despite the amount of thinking that can be done in advance. Not reacting to change is the kiss of death for all business, all the way from startups to large corporations. (It just takes longer for bigger companies.)
I also don't get your hate for 'hacker'. If you don't like Paul Graham's definition, then write your own. I see Graham's as someone who seeks to produce the 'best' code, for any given value of best. When best==short, you get the IOCCC and Golf. But laugh at me, too, if you want. I'll be off somewhere else, trying to become a better hacker.
By anonymous user, # 21. December 2007, 16:06:27
Fair enough. I take the perspective that the best way to achieve "language neutrality" is to know a lot of languages, and a lot of different types of language. I find that's the best way to keep in mind a language's limitations.
I'm not smart enough to know what C is doing at any one time. When I write C, I can't predict exactly what assembly is going to be produced. The only languages I can really do that with are assembly (obviously!) and dialects of Forth. Stack based languages are a lot easier to reason about than languages that have variables.
I'm also not smart enough to write perfectly error-free code without help, though I take solace in the fact that not many other people can, either! I tend to prefer languages that give me a lot of tools for checking I haven't made any mistakes. I want to have a compiler and unit testing framework that catches as close to 100% of the errors I make as is possible
By anonymous user, # 21. December 2007, 17:48:40
Oh, and walking!!! I do that too. I heard it was confirmed that walking does help mental concentration because it gets the blood flowing.
To cojoco:
That's a great quote! I must clarify that it's not just about making code go fast, but also about knowing how different language features will affect what you do both in code speed and development speed (how different features interact at the lowest of levels). This has profound effects on how easy or difficult it will be to maintain your code.
To sapphirecat:
You're using an argument that applies to non 10x programmers and then applying it to the general case. 10x programmers will find the bugs quite quickly and set up the code in a manner that is much less prone to errors than conventional programming. The problem arises when you have less experienced programmers trying to update the code. They may see things that are "less safe" and don't realise the consequences of their changes. Meanwhile, functional languages have some of these very same problems in that less experienced programmer do not know about some of the more terse ways of doing things and their code ends up being a mess. So pick you poison. But for real hackers, languages that get out of the way instead of in front will always win out. This is not an extreme view. Most of the language "gurus" at MS (and elsewhere) say the same thing. They too believe that you should be able to go up or down "levels" when the need arises.
These are logistics. Should you know about EDX? Maybe not. It depends what you are doing. If you're coding up a copy routine, then yeah, you best know where your data is going because copying is done everywhere. 1 ms slowdown per byte multiplied by a terabyte of data can cripple your software. If the language can get out of the way for that specific case great. Otherwise, maybe you need more details, maybe you need less. But these are logistics. Not part of programming, and neither are what you type for use with Ruby. I could say the same thing. Do I really need to specify that x is a function in Ruby? Do I really need to program at that low a level that I need to specify the specific interface used for communicating between elemental processing units? It's all about context. None of this is about programming. And if you asked yourself "what else is there?" when I claimed specifying a function is low level, then you're confusing programming with the tools.
Are you talking about the seeming trend toward functional programming? If so, you're in for a surprise. Functional programming has been around since before OO. There's nothing new there. People have had the option to use since forever. But some people think it'll help with concurrency. But you know what? It won't. It's still all hard coded.
Will functional tools help? Maybe, but not a whole lot. I predict, as I've predicted before, that if functional does catch on, it'll be in passing only toward another destination. Functional programming is NOT the destination. Will you be singing the same tune when the market moves onto something else? This will be in a matter of years, not decades. The best years for functional are in the next several years. Enjoy them now! After that, well, I'll have on open bag of popcorn watching the show.
Don't have to. I use the real definition.
To Anonymous:
A valid point. However, achieving "language neutrality" should be done before you learn a lot of languages. You should have ONE mental state when programming. This makes it so that all you need to do is associate features of programming languages to items of your mental state. IOW, learning a new language is one of recognition only. It's not about learning anything new. If you learn something new then I dunno, maybe there needs to be more time spent in developing a complete state of mind and reading up on languages is one way to do that I suppose. And this sense of discovery is usually a lot of fun.
I don't think anyone is claiming error-free code without help. I use debuggers, memory checkers and profilers all the time. I simply believe that emphasis should be on the learning abilities. Finding errors is something that takes time in whatever language you use. That's experience with the tool. Even so, it should not be what takes up most of your time (unless you're just starting out in that language). Yes, there are the occasional snags that drain your time. But overall, if finding bugs is what is keeping you up at night, then maybe the way things are being done haven't been thought through completely. There's a lack of cohesion somewhere.
BTW, no language can catch the kinds of errors I'm talking about. This is what I disliked about Java initially. The program kept running when the data was corrupted making it near impossible to find out where the bug is located. But executing (though incorrect) programs makes people feel warm and fuzzy inside. Whatcha gonna do? I remember one of the initial prime objectives of Java was to keep software running so that programmers felt good about their work in order to attract more users. This has had drastic negative effects on the quality of code.
By Vorlath, # 22. December 2007, 01:14:26
Ok, I agree again on what you're posting here vorlath.
My personal idea is that the CS community is where it is nowadays because they prefered to ignore things like this:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html
And worship tools because they sell books and fill CVs in short time.
We need more:
Dijkstra, Ritchie, Kernighan, Pike.
and less:
Gosling, Matsumoto, Van Rossum.
-gerel
By anonymous user, # 22. December 2007, 05:30:40
And your metaphore about Toronto is also flawed, by the way---how you get there *is* an important detail. Sure, my "program" may be to be in Toronto, but why? If it's to visit a friend that was in an accident and this may be the last time I get to see her alive, then I'm off to the airport. If I'm going there to visit friends or family in a non-emergency setting, then I may end up taking the train (which in this age, may end up being marginally slower than flying), or my own car if I want to have the freedom to explore the surounding area. To say that being in Toronto is the *only* critera is misleading.
Then again, I think it's really misleading to apply metaphores to programming anyway, since it's always a very imprecise mapping. Personally, I never think in metaphores when programming; I find they get too much in the way.
Also, I think your definition of programming is flawed---all programming is, is a sequence of instructions to a device, which is why the first two programmers are usually considered to be Jacques Vaucanson (writing "programs" to control his looms) and Ada Lovelace (writing "programs" to control Babage's Analytical Machine).
By spc476, # 22. December 2007, 07:45:10
By spc476, # 22. December 2007, 07:48:44
Project phases (in my view):
1. Programming
2. Development (may be omitted)
3. Coding
4. Debugging
5. Testing
By vladas, # 22. December 2007, 09:42:16
Hi Vorlath,
I'm not sure it's always possible to think outside the constructs of the language you're using, as different languages require different solutions to the same problem.
I mean, say I want to find the frequencies of items in a list. My C++ is rusty, but I believe it would go something like:
std::map<T, int> bag(std::list<T> values)
{
list<T>::iterator value;
std::map<T, int> bag = std::map<T, int>;
for (value = values.begin(); value != values.end(); value++)
{
if (bag.find(*value) == bag.end())
{
bag[*value] = 1;
}
else
{
bag[*value]++;
}
}
return bag;
}
If anyone can correct the inevitable mistakes in my bad C++, it would be appreciated! But hopefully my code isn't too far off.
Haskell I'm more familiar with these days. The solution I'd code in Haskell would be:
bag = sort >>> group >>> map (head &&& length)
Which is pretty much a completely different approach to the same problem, and not just because it's shorter! Whilst a lot of programming is language independent, sometimes the language you're coding in affects the solution you apply to the problem.
That's my take on it, anyway
By anonymous user, # 22. December 2007, 14:23:17
I think what everybody's getting at, is not how the solution is the same regardless of the language, but the problem. Understanding the problem, the task, itself in entirety is usually very demanding and often is never complete. Sure, "ending up in Toronto" is a simple problem, but most problems in programming are unendingly complex. How to get there changes, but not the destination. Some people do it in their head, others use a prototyping language first to figure out what parts of the problem they're missing, others just code in C iteratively. That's why declarative languages like Mercury, Prolog, Refal (to some degree) etc... are not so amazingly productive that everyone switches to them. Figuring out the problem to describe isn't easy.
By anonymous user, # 23. December 2007, 21:21:38
I have no disdain for coding (the typing part). I actually like it a lot. It's just that all tools currently slow me down.
You're using my argument that how you get there is a detail. If it's a detail and not part of the goal, then it's not programming. It's logistics. Sure, other factors come into it. It's still not programming. (Yeah, it's programming in the sense that you're typing stuff in, but it's not what takes up the most development time [it's one small step]).
I used to think this way a long time ago. If you want to get faster, break through this illusion. There are MUCH better ways to program faster. I think of coding (the typing part) as an interpretation of the interconnected goals onto the computer's dialect (whatever that may be).
So again, when you ask about asm or C/C++, some languages can slow you down a lot, some slow you down a little. So I use C++ for some stuff and asm for others (this still amazes people). I also hope you understand that I often write programs that write other programs. But at all points, I need to have a basic understanding of what kinds of instructions it will produce for the final output. Not always, but a lot. Understanding how the machine works as you're programming has profound effects on the maintainability of your software and how well it works.
The way I look at code is kind of like data. While my code will manipulate data at runtime, *I* will manipulate the opcodes at design time. So code is nothing more than data at design time. I will use the best tools I can find as long as I can see the results of my work. But all these tools are to help translate my finished code that's in my head and put it into the machine. This CANNOT be programming. If it is, then my sympathies. I call this way of programming, "poor man's programming".
Here's EXACTLY how I form a mental picture of programming. The list of opcodes is my paint and the tools (languages including assembly) are paintbrushes. I'm also able to build whatever else I can come up with (parsers, DSL) to apply paint in broader strokes. Sometimes you don't need fine brushes. Sometimes, you spraypaint is good enough. Sometimes, you need a machine that you step into and manipulate directly (like DSL) to make really massive changes, but you still see the final product and how it all comes together. I need a uniform canvas. Otherwise, I can't see the whole thing. If I take things for granted, I don't know that it's coming out the way it's supposed to.
More than that, the canvas is more than just paint. It is itself a painter. The canvas must then be able to be activated and produce the final goal, the true canvas that I had in mind all along. That is what I'm really trying to paint. Most people are stuck on the first canvas as you obviously are. I'm on the second one all along. That's programming. Everything in between is NOT necessary. It's ONE method out of many. It's a means to an end. In the future, machines will be different and you'll have to learn a new way to paint. I don't. I'm on the second canvas that never changes. The goals are always the same no matter the final machine or whatever else it may be that we come up with like organic machines or hybrids.
By Vorlath, # 23. December 2007, 23:19:47
For Project V, I had to break through this prior focus on minute details. I needed a way to specify the problem without the specifics. This is how I want to achieve portability. The overall definition is the same, but how they are implemented is different. Project V is about the second canvas, and compiling is about the first. You can go along and specify what specifics you want. But for most cases, you don't need to. This is why I don't believe that abstractions exist. They seem like hardcoding from my POV. It's also why I believe that the way to portability is allowing different machines to specialise different functionality. Like I said, the ultimate goal is always the same (second canvas), but the methods of achieving it can be different (first canvas).
To everyone:
I also want to mention that I would not have been able to break through and define it in concrete terms usable in a development environment without the help of my readers on this blog. Regardless if I've agreed or not, you've all helped in making sure to point out if there were any errors or not to my satisfaction that I can make a workable system. It's quite a difference between having your mind do something as opposed to defining on "paper" what it is you've been doing all along. It's a further leap to actually get a working prototype. So for those who think I'm taking a long time. Well, you're right. But this is unlike any software that I've ever written. The concepts are nothing like anything I've seen before. Unfortunately on the surface, all you'll see are this first canvas unless we can adapt. If I can get a few people to see and understand the second canvas, then I'll be happy. No other tool is able to work in this fashion. And this is why all current tools are unable to make me code any faster. They're stuck on the immediate task of plugging in hardcoded code.
By Vorlath, # 23. December 2007, 23:47:53
Okay. My greylist program. I want to delay incoming email.
Okay, fine. That's pretty much the problem without specifics (and really, it only works because of an implementation detail spammers neglected for SMTP based email, which to me, is a pesky detail you don't seem to care about).
Now what? "Hey! Project V! I want to delay email! Go to it, boy!"
By spc476, # 26. December 2007, 00:05:04
By spc476, # 26. December 2007, 00:08:38
I think this is a design flaw, which then was "implemented". Mostly because of sending millions spam mails, which if they'd delay, will never be sent.
By vladas, # 26. December 2007, 09:30:55
So, their spam mail software must be a specialized mail client, and not legacy mail server.
Greylisting just exploits this specific.
By vladas, # 26. December 2007, 09:48:12
The goal is to be in Toronto. This would be your actual program. This is the second canvas I talked about. No matter *HOW* you get to Toronto, this second canvas will never change. BUT, there are many ways to get to Toronto. That is canvas #1. This is the implementation layer. It really doesn't matter what you use. Speed is not a factor just as long as you get there. Now, if speed happens to be important, then you can SELECT which implementation you want. This is how Project V will work.
There's more. One level's "design" is another's "implementation". So you can layer these things to whatever depth you want.
As another low level example, if I want to add two numbers, I simply say I want to "ADD" them. But the actual opcode is different for different types and even different machines. If you understood the above, then it's a simple matter for portability. The goal is to add, but HOW I add them will be different based on types and the hardware it is running on. So you can stack these "design" and "implementation" layers one atop each other where at one level X will be a design and at another, X will be an implementation.
By Vorlath, # 26. December 2007, 17:01:37
By spc476, # 26. December 2007, 20:46:00
Unless I'm missing something.
By spc476, # 26. December 2007, 20:47:30
What I'm saying is that each layer is both design and implementation. It depends if you're looking at it from above or from below.
When you tell someone to deliver a package, you don't care how it's done. Here's the difference between how Project V will work and how we program today. In conventional languages, we specify EXACTLY how this package should be delivered right down to the kind of tires on the truck that picked it up from you. Even if you leave it to others and don't look into it and use encapsulation, you've still committed to ONE specific way of doing things, whatever that may be.
With Project V, it doesn't work like that. Instead, you say I want package X to be delivered to city Y. That's it. How it's done is irrelevant. If I need speed, then I attach more information like latest arrival time. Once you give this to the computer, it will look at what it has that can accomplish this task. Usually, there will be several ways of doing this. It'll pick the most efficient one (by whatever calculations) and use that. If it ends up not being efficient, then it'll log it for any future reference. So over time, your software will start to pick better and better ways of doing things. It'll never have to do the same thing twice if it doesn't want to. And indeed, it can customize any code to be specific to your package.
Note that for any specific package, you may indeed specify the delivery method if you wish, but overall, you would not do so.
There's more. Say the machine picks delivery by truck. In this case, you need to have a driver, gas, oil, tires, vehicle brand, etc. Each of these you don't actually care about just as long as the truck can get to its destination in the time alloted. Again, the machine will pick a specific item for each of these and over time, it will get better and better parts.
As time goes on, there'll be more and more components until we don't need to worry about specifying any minute details anymore. The machine will already know that sorting 40 items is best with insertion sort and sorting large amounts on a single core is best done with quicksort and that with multicore, it should use some kind of even odd sort, or some combination of all these depending on the machine configuration. So you can even add hardware or remove it and over time, the runtime will adapt exactly because you don't have to give it specifics about the low level stuff.
But that's the punch line. What does it mean to be low level? It's all about perspective. I consider imperative and functional to be awfully low level. It's all hardcoded. To an intergalactic traveller, entire planets are low level details that you only consider upon leaving and arrival. So no matter where you're at or at what scale you're at, what is considered low level should constantly be changing with you POV. With conventional programming, this does not happen. In fact, I've had people comment that encapsulation should only happen at the top level. So there is MUCH MUCH more that can be done in terms of development.
By Vorlath, # 26. December 2007, 23:51:12