Live data from Hacker News

Programming is Terrible

programmingisterrible.com

51–60 of 73 posts

Re: Programming is Terrible

#51

> The only supporting evidence for the “uberhacker” was a study on batch processing vs interactive programming, in 1960. On a handful of people, in a half hour session. The rest of the noise is untamed adolescent egotism. I present exhibit A: Richard Mathew Stallman before he got RSI.[0] The stories of those early computer pioneers should make computer users everywhere take pause and seriously think about the damage…

Must be a random selection from a list. When I tried it I got Linus Torvalds :-) That, Wikipedia, is very cool!

Re: Programming is Terrible

#52

This guy gets it wrong in his last post on reliability (but the other posts seem reasonable). Reliability is hard because we continue to move the goalpost. I can write a pretty reliable program to compute sin/cos tables or to sort a phonebook or to do some basic projectile trajectory. But those aren't even table stakes anymore. Today a first year undergrad student might be expected to write a program that in 1970 the…

That last point rings quite true with my experiences. I've been writing PHP and some other languages off and on for about 10 years now. Looking at current jobs listings it's difficult to find things that I am particularly well suited for, even in web programming. Since I was using PHP well before the current crop of mature frameworks and CMS the majority of my experience is in trial and error development of my own da…

That's one of the reasons to invest in lasting knowledge. Compiler construction is one of the evergreen topics.

Re: Programming is Terrible

#53

"Another hope might be academia, but much of the focus is on program verification, rather than reliability. Well typed software will eliminate some failure classes, but it doesn’t give you robustness." For anyone who's curious, academic research into verification extends far beyond "Well typed software". For example: Klee: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs [PDF, v…

And there's also proving code correct. Like the recent example of seL4.

Re: Programming is Terrible

#54

> The only supporting evidence for the “uberhacker” was a study on batch processing vs interactive programming, in 1960. On a handful of people, in a half hour session. The rest of the noise is untamed adolescent egotism. I present exhibit A: Richard Mathew Stallman before he got RSI.[0] The stories of those early computer pioneers should make computer users everywhere take pause and seriously think about the damage…

> [0]: In fact, if you type "uberhacker" into wiki it redirects to him.

It redirects to Torvalds now.

EDIT someone must have changed it moments ago:

http://en.wikipedia.org/w/index.php?title=Uberhacker&act...

Re: Programming is Terrible

#55

> The only supporting evidence for the “uberhacker” was a study on batch processing vs interactive programming, in 1960. On a handful of people, in a half hour session. The rest of the noise is untamed adolescent egotism. I present exhibit A: Richard Mathew Stallman before he got RSI.[0] The stories of those early computer pioneers should make computer users everywhere take pause and seriously think about the damage…

Must be a random selection from a list. When I tried it I got Linus Torvalds :-) That, Wikipedia, is very cool!

Not really; someone changed the redirect moments ago:

http://en.wikipedia.org/w/index.php?title=Uberhacker&act...

Re: Programming is Terrible

#56

> The only supporting evidence for the “uberhacker” was a study on batch processing vs interactive programming, in 1960. On a handful of people, in a half hour session. The rest of the noise is untamed adolescent egotism. I present exhibit A: Richard Mathew Stallman before he got RSI.[0] The stories of those early computer pioneers should make computer users everywhere take pause and seriously think about the damage…

Must be a random selection from a list. When I tried it I got Linus Torvalds :-) That, Wikipedia, is very cool!

[deleted]

Re: Programming is Terrible

#57

This guy gets it wrong in his last post on reliability (but the other posts seem reasonable). Reliability is hard because we continue to move the goalpost. I can write a pretty reliable program to compute sin/cos tables or to sort a phonebook or to do some basic projectile trajectory. But those aren't even table stakes anymore. Today a first year undergrad student might be expected to write a program that in 1970 the…

>Experience means very little. Why? Because I can capture 70% of your experience in your code -- in your library -- and build directly on top of it.

If you depend on my experience, it's going to make me money one way or another. And it's going to be money that you don't make, either because you have to share your revenue with me, or because it doesn't give you an edge as many others will use my library to compete with you.

But the problem is that age doesn't automatically give me the kind of experience that others depend on. There's a lot of knowledge that becomes utterly useless or even misleading over time.

And you can be quite sure of one thing. If your experience comes from gluing together a bunch of libraries to chase the fashions of the day, your experience will indeed mean very little down the road.

Re: Programming is Terrible

#58
post #50
post #40

Earlier quoted context omitted.

There are many classes of products that require what I like to call "fractal attention to detail." These include most consumer goods (which are usually cost and performance constrained), man-rated stuff that has to work (aerospace, medical), and products with stringent security requirements (game consoles, smart cards). By fractal I mean that you can have good abstractions, but you can't afford black boxes, and desig…

Why can't you have black box abstractions in things that "have to work"?? And even "has to work" can be relative, as if you can prove that something will work for a p value small enough to guarantee risk of failure is small enough in the next 100 years for a device/system that will at most stay in use for 10 it good enough... And if you're not constrained by power use or computing power, you can also use redundant su…

Yeah 'cause instead of buying a reliable japanese car, you bought an unreliable swarm of american scooters.

This probabilistic stuff is academic nonsense

Re: Programming is Terrible

#59

> The only supporting evidence for the “uberhacker” was a study on batch processing vs interactive programming, in 1960. On a handful of people, in a half hour session. The rest of the noise is untamed adolescent egotism. I present exhibit A: Richard Mathew Stallman before he got RSI.[0] The stories of those early computer pioneers should make computer users everywhere take pause and seriously think about the damage…

> [0]: In fact, if you type "uberhacker" into wiki it redirects to him. It redirects to Torvalds now. EDIT someone must have changed it moments ago: http://en.wikipedia.org/w/index.php?title=Uberhacker&act...

They should redirect uberhacker to Torvalds, and GNU/uberhacker to Stallman.

Re: Programming is Terrible

#60

Finally, a reasonable programming blog post. I'm so tired of the inane myths coming out of the programming community like the recent 'liberal/conservative' thing and the 501 manifesto. It seems like every 2 months I have to stop visiting hacker news and proggit while another one of these seemingly intuitive but unsupported link-bait blog posts comes around followed by a deluge of links saying NUH-UH. Here's the thing…

I disagree - distilled intuition is priceless.

Intuition is why I learnt most of what I know about hacking came not from university courses () but from scouring the internet for interesting reading, studying open source and RFCs, and reading blogs. Intuition is why I come to HN and and stackoverflow (or formerly to the c2 wiki and usenet) instead of reading ACM journals.

The programming landscape is vast, and there are a 1000 ways to do the same thing, but a few of them are beautiful, and I want to know why, and what guided their design, and how should I think about these things.

Research is mostly silent on this, and when there is research it's hard to tell how credible it is. Whereas if Bram Cohen writes something about networking, I listen up, because having created bittorrent is a way stronger signal of credibility than having an X citation index.

And yes, I'm deeply biased. E.g. I read Stevey's Rants because I share a lot of his beliefs, and love his writing style. So I get confirmation of my beliefs, and they may still be wrong, but at least now I have a good vocabulary* to discuss my beliefs, e.g. "liberal"/"conservative". I loved the Unix style before reading TAOUP, but now I have clearer definitions - and names - for the qualities I admired. BTW, the Jargon File is an early example of hackers seeking out a shared vocabulary of intuition.

(*) SICP was an outlier (as were some other courses my university borrowed from MIT). Written by exceptional hackers, talking about design principles explicitly, and exemplifying elegance on every corner (it wouldn't be half as great if it used CL instead of Scheme!). "Programs should be written for people to read, and only incidentally for machines to execute." - SICP didn't cite research to support this intuition, but I'm ready to repeat this one as fact. What was bullshit was an OOP course taught by a CS professor who doesn't code much and TA'd by a Java drone.

Post reply on HN