By: Howard Chu (hyc.delete@this.symas.com), February 17, 2008 4:42 pm
Room: Moderated Discussions
David Kanter (dkanter@realworldtech.com) on 2/15/08 wrote:
---------------------------
>Howard Chu (hyc@symas.com) on 2/15/08 wrote:
>---------------------------
>>I'm not saying that this shouldn't be done in a higher level language. I'm saying
>>that I would prefer not to waste cycles re-discovering optimizations each time my
>>code is executed. I'd prefer to pay all of the cost of optimization once, and then
>>just let the code run without any introspection/virtualization overhead.
>
>So there are two issues here:
>
>1. You're not an average programmer - average programmers are not as good at optimization and are probably lazier
Those folks should find another career then, one where their aptitude will allow them to be excellent instead of just average.
>2. Some things are impossible using static optimizations that are trivial when you have run time information
The obvious solution is to build systems that allow all of the optimization results to be persisted into a backing store and then have all the introspection turned off from that point on.
>>>>* To maximize programmer productivity, future programming >models must be more
>>>>human-centric than the conventional focus on hardware or >applications.
>>>>
>>>>Kinda like what I touched on before, designing programming >languages whose input
>>>>tokens aren't character-based. Aside from that it's all >bunk. 3000+ years ago a
>>>>guy named Hercules had to clean out the Augean stables. >Today mucking horse stalls
>>>>is still a dirty job. That's the nature of the job.
>>>
>>>Some things are easier in python than in C though...
>>
>>I guess. It just strikes me that you can go too far here. >Make a job so easy that
>>any idiot can do it, and you'll wind up with lots of >products created by idiots.
>
>That's right, and that's economics for you. Programming has already evolved from
>a specialist activity to one that is easier and more approachable (ASM-->C-->C++/Java-->Python/Ruby).
>That trend will continue, so I think making parallel programming easier is the right idea.
>
>I think Intel would be more than happy to trade 5-10mm2 of silicon for letting
>programmers use their hardware more easily.
That's the wrong approach. It's the same thinking that Hollywood uses. Rather than dumbing down your offerings to make them accessible to more people, you should be educating more people to elevate them to a level of understanding for your products.
Back in the 80s Apple IIs and Commodores all came with built-in BASIC interpreters. It pretty much went without saying that if you were going to own a computer, you were going to learn how to program it. Compared to the switch-operated, paper-tape/punch-card driven machines that came before, those machines were already extremely easy to use. In fact, I'd say they were *sufficiently* easy to use. If there was any usability gap, it was up to the people to bridge that gap, and learn. From the millions of personal computers sold in that era, we got hundreds of thousands of motivated, competent programmers.
The fact that PCs are mass-marketed today as appliances is part of Intel's problem. Again, the approach has been too dumbed down, treating the population only as consumers instead of as creators. If PCs were sold with an emphasis on programming, there'd be a larger percentage of population ready/willing/able to tackle the next big thing.
---------------------------
>Howard Chu (hyc@symas.com) on 2/15/08 wrote:
>---------------------------
>>I'm not saying that this shouldn't be done in a higher level language. I'm saying
>>that I would prefer not to waste cycles re-discovering optimizations each time my
>>code is executed. I'd prefer to pay all of the cost of optimization once, and then
>>just let the code run without any introspection/virtualization overhead.
>
>So there are two issues here:
>
>1. You're not an average programmer - average programmers are not as good at optimization and are probably lazier
Those folks should find another career then, one where their aptitude will allow them to be excellent instead of just average.
>2. Some things are impossible using static optimizations that are trivial when you have run time information
The obvious solution is to build systems that allow all of the optimization results to be persisted into a backing store and then have all the introspection turned off from that point on.
>>>>* To maximize programmer productivity, future programming >models must be more
>>>>human-centric than the conventional focus on hardware or >applications.
>>>>
>>>>Kinda like what I touched on before, designing programming >languages whose input
>>>>tokens aren't character-based. Aside from that it's all >bunk. 3000+ years ago a
>>>>guy named Hercules had to clean out the Augean stables. >Today mucking horse stalls
>>>>is still a dirty job. That's the nature of the job.
>>>
>>>Some things are easier in python than in C though...
>>
>>I guess. It just strikes me that you can go too far here. >Make a job so easy that
>>any idiot can do it, and you'll wind up with lots of >products created by idiots.
>
>That's right, and that's economics for you. Programming has already evolved from
>a specialist activity to one that is easier and more approachable (ASM-->C-->C++/Java-->Python/Ruby).
>That trend will continue, so I think making parallel programming easier is the right idea.
>
>I think Intel would be more than happy to trade 5-10mm2 of silicon for letting
>programmers use their hardware more easily.
That's the wrong approach. It's the same thinking that Hollywood uses. Rather than dumbing down your offerings to make them accessible to more people, you should be educating more people to elevate them to a level of understanding for your products.
Back in the 80s Apple IIs and Commodores all came with built-in BASIC interpreters. It pretty much went without saying that if you were going to own a computer, you were going to learn how to program it. Compared to the switch-operated, paper-tape/punch-card driven machines that came before, those machines were already extremely easy to use. In fact, I'd say they were *sufficiently* easy to use. If there was any usability gap, it was up to the people to bridge that gap, and learn. From the millions of personal computers sold in that era, we got hundreds of thousands of motivated, competent programmers.
The fact that PCs are mass-marketed today as appliances is part of Intel's problem. Again, the approach has been too dumbed down, treating the population only as consumers instead of as creators. If PCs were sold with an emphasis on programming, there'd be a larger percentage of population ready/willing/able to tackle the next big thing.
Topic | Posted By | Date |
---|---|---|
Multicore is unlikely to be the ideal answer. | Anders Jensen | 2008/02/14 03:24 AM |
And the links.. | Anders Jensen | 2008/02/14 03:25 AM |
Disappointing.. | Linus Torvalds | 2008/02/14 09:17 AM |
Disappointing.. | Mark Roulo | 2008/02/14 10:03 AM |
LOL (NT) | Linus Torvalds | 2008/02/14 04:43 PM |
Disappointing.. | David Patterson | 2008/02/15 10:53 AM |
Disappointing.. | Linus Torvalds | 2008/02/15 04:01 PM |
Disappointing.. | anon | 2008/02/15 07:54 PM |
Disappointing.. | JasonB | 2008/02/19 06:45 PM |
Disappointing.. | Ilya Lipovsky | 2008/02/22 05:27 PM |
Disappointing.. | Scott Bolt | 2008/03/16 10:36 AM |
Need for new programming languages | Vincent Diepeveen | 2008/02/19 05:18 AM |
Need for new programming languages | Pete Wilson | 2008/02/24 10:41 AM |
Disappointing.. | Zan | 2008/02/25 09:52 PM |
Disappointing.. | Robert Myers | 2008/02/19 08:47 PM |
Disappointing.. | Fred Bosick | 2008/02/22 05:38 PM |
Disappointing.. | Robert Myers | 2008/03/01 12:17 PM |
The limits of single CPU speed are here. | John Nagle | 2008/03/14 09:55 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/15 12:02 AM |
The limits of single CPU speed are here. | slacker | 2008/03/15 07:08 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/17 12:47 AM |
The limits of single CPU speed are here. | slacker | 2008/03/17 09:04 AM |
And the links.. | Howard Chu | 2008/02/14 11:58 AM |
I take some of that back | Howard Chu | 2008/02/14 12:55 PM |
And the links.. | Jesper Frimann | 2008/02/14 01:02 PM |
And the links.. | Ilya Lipovsky | 2008/02/15 01:24 PM |
And the links.. | iz | 2008/02/17 09:55 AM |
And the links.. | JasonB | 2008/02/17 06:09 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 12:54 PM |
And the links.. | JasonB | 2008/02/18 09:34 PM |
And the links.. | Thiago Kurovski | 2008/02/19 06:01 PM |
And the links.. | iz | 2008/02/20 09:36 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 02:37 PM |
And the links.. | JasonB | 2008/02/20 05:28 PM |
And the links.. | JasonB | 2008/02/17 05:47 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 01:27 PM |
And the links.. | JasonB | 2008/02/18 09:00 PM |
And the links.. | JasonB | 2008/02/19 02:14 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 03:29 PM |
And the links.. | JasonB | 2008/02/20 05:14 PM |
And the links.. | Ilya Lipovsky | 2008/02/21 10:07 AM |
And the links.. | Howard Chu | 2008/02/14 12:16 PM |
And the links.. | Jukka Larja | 2008/02/15 02:00 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 10:41 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/15 11:49 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 02:48 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/17 04:42 PM |
Berkeley View on Parallelism | nick | 2008/02/17 08:15 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/18 03:23 PM |
Berkeley View on Parallelism | nick | 2008/02/18 09:03 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 12:39 AM |
Berkeley View on Parallelism | rcf | 2008/02/19 11:44 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 02:25 PM |
Average programmers | anon | 2008/02/18 11:40 AM |
Berkeley View on Parallelism | JasonB | 2008/02/15 07:02 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 07:02 PM |
Berkeley View on Parallelism | Dean Kent | 2008/02/15 07:07 PM |
Berkeley View on Parallelism | Ray | 2008/02/20 02:20 PM |
Berkeley View on Parallelism | JasonB | 2008/02/20 05:11 PM |
Berkeley View on Parallelism | FritzR | 2008/02/24 02:08 PM |
rubyinline, etc. | nordsieck | 2008/02/22 02:38 PM |
rubyinline, etc. | JasonB | 2008/02/23 04:53 AM |
rubyinline, etc. | nordsieck | 2008/03/02 12:40 AM |
rubyinline, etc. | Michael S | 2008/03/02 01:49 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 06:41 AM |
rubyinline, etc. | Michael S | 2008/03/02 07:19 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 07:30 AM |
rubyinline, etc. | JasonB | 2008/03/02 04:26 PM |
rubyinline, etc. | JasonB | 2008/03/02 05:01 PM |
rubyinline, etc. | Anonymous | 2008/03/03 01:11 AM |
rubyinline, etc. | JasonB | 2008/03/03 08:40 AM |
rubyinline, etc. | Foo_ | 2008/03/09 08:59 AM |
rubyinline, etc. | JasonB | 2008/03/10 12:12 AM |
rubyinline, etc. | Gabriele Svelto | 2008/03/10 01:22 AM |
rubyinline, etc. | JasonB | 2008/03/10 03:35 AM |
C++ for beginners | Michael S | 2008/03/10 04:16 AM |
C++ for beginners | JasonB | 2008/03/10 05:35 AM |
C++ | Michael S | 2008/03/10 03:55 AM |
rubyinline, etc. | Linus Torvalds | 2008/03/03 10:35 AM |
rubyinline, etc. | Dean Kent | 2008/03/03 01:35 PM |
rubyinline, etc. | JasonB | 2008/03/03 02:57 PM |
rubyinline, etc. | Dean Kent | 2008/03/03 07:10 PM |
rubyinline, etc. | Michael S | 2008/03/04 12:53 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 06:51 AM |
rubyinline, etc. | Michael S | 2008/03/04 07:29 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 07:53 AM |
rubyinline, etc. | Michael S | 2008/03/04 10:20 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 01:13 PM |
read it. thanks (NT) | Michael S | 2008/03/04 03:31 PM |
efficient HLL's | Patrik Hägglund | 2008/03/04 02:34 PM |
efficient HLL's | Wes Felter | 2008/03/04 08:33 PM |
efficient HLL's | Patrik Hägglund | 2008/03/05 12:23 AM |
efficient HLL's | Michael S | 2008/03/05 01:45 AM |
efficient HLL's | Wilco | 2008/03/05 04:34 PM |
efficient HLL's | Howard Chu | 2008/03/05 06:11 PM |
efficient HLL's | Wilco | 2008/03/06 01:27 PM |
efficient HLL's | anon | 2008/03/05 07:20 AM |
And the links.. | Groo | 2008/02/17 03:28 PM |
And the links.. | Vincent Diepeveen | 2008/02/18 01:33 AM |