Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The dumbing-down of programming (1998)

archive.salon.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: The dumbing-down of programming (1998)

#21

Post by gabeybaby »

tigerthink wrote: post #12
gabeybaby wrote: post #7

Earlier quoted context omitted.

Agreed. I especially liked the use of "All the lovely graphical skins turned to so much bitwise detritus" I can visualize the 1's and 0's settling on the bottom. Despite his discontent for "the wizards", he seems to realize their usefulness in his last sentence with "the tool as convenient information repository." Certainly, especially in their earlier incantations, the wizards can try to do too much, but a decade la…

Her. Her discontent.

Right, Realized that a bit later.

Re: The dumbing-down of programming (1998)

#22

Post by nailer »

io wrote: post #20
nailer wrote: post #17

Earlier quoted context omitted.

Really? I found the article moronic. Witness: 'Linux: home-brewed, hobbyist, group-hacked. UNIX-like operating system created in 1991 by Linus Torvalds then passed around from hand to hand like so much anti-Soviet samizdat. Noncommercial, sold on the cheap mainly for the cost of the documentation, impracticable except perhaps for the thrill of actually looking at the source code and utterly useless to my life as a so…

This /was/ written 11 years ago. The market for Linux consultants is a little different today.

11 years ago it's still naive.

1. GNU has been going for nearly a couple of decades - Linus didn't magic an OS out of thin air. The modern equivalent is the articles written about Safari that suggest Apple did the same.

2. Nor was was Linux for home brews - Red Hat, the commercial distro, had emerged as the current leader for both businesses and nerds, with Apache (written by the ASF, which still had strong commercial roots) and to a lesser extent Samba (which I guess back then was still relatively uncommercial, so I give the article that).

3. As a Linux consultant at the end of 1998, I started on 75 Australian dollars an hour, because I knew Unix despite having no access to RISC systems. Utterly useless? I think not.

Re: The dumbing-down of programming (1998)

#23

Post by michaelneale »

nailer wrote: post #22
io wrote: post #20

Earlier quoted context omitted.

This /was/ written 11 years ago. The market for Linux consultants is a little different today.

11 years ago it's still naive. 1. GNU has been going for nearly a couple of decades - Linus didn't magic an OS out of thin air. The modern equivalent is the articles written about Safari that suggest Apple did the same. 2. Nor was was Linux for home brews - Red Hat, the commercial distro, had emerged as the current leader for both businesses and nerds, with Apache (written by the ASF, which still had strong commercia…

Well I think it is naive, but that was the mainstream view back then, takes a long time to shift popular views of things...

Re: The dumbing-down of programming (1998)

#24

Post by Zak »

Code generation is nearly always the Wrong Thing. Using the right abstractions is the Right Thing. The problem is it leads to a bunch of duplicated code... and they you have to change something.

The one exception might be scaffolding code, which isn't really intended to be kept.

Re: The dumbing-down of programming (1998)

#25

Post by derefr »

bad_user wrote: post #18
phugoid wrote: post #8

She beautifully explained what draws people like myself to GNU/Linux. I have tried to convey some of these ideas to colleagues who are serious about Windows programming, to no avail. It's not about Microsoft either. In my industry (flight simulation) there are some machines and systems where you can go deep and acquire design-level knowledge, and other systems where you're dealing with black boxes. Some people prefer…

From time to time I have to explain to colleagues why I prefer a minimalistic approach to programming. One analogy to cars :) ... for normal people, having automatic transmission is great ... you can drive the vehicle with only one hand, and it allows you to concentrate more on the actual driving. But race cars still have manual or semi-automatic transmissions. Thus race drivers are empowered to do neat tricks while…

Thing is, a race car is designed with the fact in mind that you're not going to do anything but drive when you're in the seat. If there were racing-while-talking-on-cellphones competitions, the automatic transmission would probably be a better optimization in terms of available-attention-to-performance.

Likewise, for some types of programs (extremely parallel ones, for example), you have so many high-level considerations that also thinking about the low-level implications would simply be too much. Premature optimization is just as much a drain on the programmer as the program.

Re: The dumbing-down of programming (1998)

#26

Post by bad_user »

derefr wrote: post #25
bad_user wrote: post #18

Earlier quoted context omitted.

From time to time I have to explain to colleagues why I prefer a minimalistic approach to programming. One analogy to cars :) ... for normal people, having automatic transmission is great ... you can drive the vehicle with only one hand, and it allows you to concentrate more on the actual driving. But race cars still have manual or semi-automatic transmissions. Thus race drivers are empowered to do neat tricks while…

Thing is, a race car is designed with the fact in mind that you're not going to do anything but drive when you're in the seat. If there were racing-while-talking-on-cellphones competitions, the automatic transmission would probably be a better optimization in terms of available-attention-to-performance. Likewise, for some types of programs (extremely parallel ones, for example), you have so many high-level considerat…

> you have so many high-level considerations that also thinking about the low-level implications would simply be too much

You still have to have a high-level perspective on how things are working, because abstractions are often leaky.

For example, I don't care much about tasks related to systems administration, allowing me to concentrate on what matters to me ... for instance I don't care about the difference between Postfix and Sendmail, or the difference between Apache and Lighttpd ... I just use the one I know until I have a problem with it, but when I do have a problem I have to find ways to solve it. And some knowledge on how the protocols and processes work really help.

Re: The dumbing-down of programming (1998)

#27

Post by jasonkester »

Zak wrote: post #24

Code generation is nearly always the Wrong Thing. Using the right abstractions is the Right Thing. The problem is it leads to a bunch of duplicated code... and they you have to change something. The one exception might be scaffolding code, which isn't really intended to be kept.

The nice thing about Code Generation is that you can do it as often as you like. So if you change something, you just re-generate all the boilerplate and you're back in business.

This is the one instance where I'll argue in favor of duplicated code. When something breaks in one of your generated classes, you'll find yourself on a breakpoint at a single line that does a single thing, so you can quickly figure out what happened and why (and what changes you'll need to make to the Codesmith template so that it never happens again). When your "right abstraction" breaks, you might find yourself seven interfaces deep looking at a hash full of Objects, one of which is probably not supposed to be null, maybe, and it's not going to be any fun to debug.

Re: The dumbing-down of programming (1998)

#28

Post by derefr »

bad_user wrote: post #26
derefr wrote: post #25

Earlier quoted context omitted.

Thing is, a race car is designed with the fact in mind that you're not going to do anything but drive when you're in the seat. If there were racing-while-talking-on-cellphones competitions, the automatic transmission would probably be a better optimization in terms of available-attention-to-performance. Likewise, for some types of programs (extremely parallel ones, for example), you have so many high-level considerat…

> you have so many high-level considerations that also thinking about the low-level implications would simply be too much You still have to have a high-level perspective on how things are working, because abstractions are often leaky. For example, I don't care much about tasks related to systems administration, allowing me to concentrate on what matters to me ... for instance I don't care about the difference between…

You don't (usually) think about your oil when you're driving, and you especially don't change your oil while driving. Just because you understand how the low level works doesn't mean you keep it loaded in your working memory simultaneously to the high-level knowledge. You change your oil when the car is parked; you optimize when you're not in the middle of writing a feature or fixing a bug.

Re: The dumbing-down of programming (1998)

#29

Post by rbanffy »

TallGuyShort wrote: post #11

This is so true - all too often the problems encountered in a project were caused because someone didn't really understand what was going on under the surface.

While high-level languages and nice operating systems are a good thing, they often mask what's beyond them. If someone grows up in a world they can't look beyond the curtain, bad things happen.

Many times I have witnessed sysadmins banging their heads trying to tune parameters on a Linux server that ran under a virtual machine setting and wondering why some counters were off, without realizing the machine underneath their OS didn't really have hardware counters they could, forgive me, count on.

Re: The dumbing-down of programming (1998)

#30

Post by rodburch »

nailer wrote: post #17
phugoid wrote: post #8

She beautifully explained what draws people like myself to GNU/Linux. I have tried to convey some of these ideas to colleagues who are serious about Windows programming, to no avail. It's not about Microsoft either. In my industry (flight simulation) there are some machines and systems where you can go deep and acquire design-level knowledge, and other systems where you're dealing with black boxes. Some people prefer…

Really? I found the article moronic. Witness: 'Linux: home-brewed, hobbyist, group-hacked. UNIX-like operating system created in 1991 by Linus Torvalds then passed around from hand to hand like so much anti-Soviet samizdat. Noncommercial, sold on the cheap mainly for the cost of the documentation, impracticable except perhaps for the thrill of actually looking at the source code and utterly useless to my life as a so…

lol are we the only two ppl on this article who actually know anything about computers? all the other comments seem to have been written by my mom.

did u bust a gut at all that "peeling back the layers" so she could start replacing windows with linux? AHAHAHAHAHAHA

or that crap about rom basic? PUT IN THE FUCKING LINUX FLOPPY MOM!!!

god. this fucktard is a SOFTWARE ENGINEER. plz, kill me now.

no, actually, this kind of person is why ppl who have any skills can basically say YOU'RE GONNA PAY ME THIS AND I'M GONNA DO THAT NOW GET OUT OF MY OFFICE AND DON'T BOTHER ME.

lol.

Post reply on HN