Live data from Hacker News

Why software sucks?

scottberkun.com

71–80 of 82 posts

Re: Why software sucks?

#71
post #45

Here are some thoughts I'd put into the mix. 1. Software that is built to deadline will decay, even if the developers are good. That doesn't mean that an occasional deadline is the end, but if a long-term "deadline culture" sets in, get out. A long-standing deadline-oriented culture means you should be looking to jump to another project or company before the maintenance phase starts, because (1) the maintainers will…

I'd be curious to hear why you're so anti-IDE: do you have extensive experience working in Java with a good IDE like IntelliJ? I've heard this "IDE's are to help mediocre programmers be mediocre" argument before, but it's so alien to my experience with IntelliJ (which I've used every day for about 10 years now) that there's nearly no way to reconcile that argument with my personal experience. When I'm writing C or Ja…

I'd be curious to hear why you're so anti-IDE: do you have extensive experience working in Java with a good IDE like IntelliJ?

My objection has more to do with IDE-dependence. Also, Java is a language in which it's way too painful not to use an IDE-- I certainly use an IDE when I'm in Java-- and IDEs tend not to play nice with outside-of-IDE actors such as version control, so there tends to be a Mafia (once you're in, you can't get out) nature to them.

I don't dislike IDEs themselves. I dislike the fact that people use them to make insufficient languages less bad in lieu of using a better language, and worse yet, that business types end up with the impression that other languages are less mature/usable because they lack IDE support. When you have an expressive language, you don't need an IDE (or, at least, I've never found myself missing one).

That said, it may be that an IDE is pleasant to use with a better language, and makes it even better. A lot of what IDEs offer is useful. That said, I'd rather have a good language like Ocaml and no IDE than Java and the best IDE on the market. Java development is just not very "flow"-ful in my experience, and the productivity benefits conferred by an IDE are small compared to the astronomical bump conferred by an expressive language.

It's not exactly the same as a REPL (I can't call the method right then, of course, but I'll get to that in a minute), but it serves a different purpose, and your argument in that linked post about how IDEs aren't made to read code is, honestly, laughable: it's way, way easier to read and explore a Java code base within an IDE than it would be in a text editor and a REPL.

Ok, I see where you're coming from. I agree that reading Java code pretty much requires an IDE.

Now, you can argue that Java itself is verbose enough that reading it is painful because of all the boilerplate: sure, that's a fair point, but it has nothing to do with an IDE.

Not directly, but I think there's a cultural problem that might be enabled by the IDE. Just as it's said that 4-wheel drive helps a person get stuck in an even more inaccessible place, I feel like IDEs enable people to program who shouldn't be programming, inappropriate languages to just kinda work, and bad practices not to totally fall flat on people who use them. I can't prove this, but it seems like this is the case, taking an industry-wide perspective.

If you had a language with cleaner syntax and an IDE, that would be better than just a language with cleaner syntax and a REPL when it came to reading code.

I'd like to try this experiment. You could easily be right. My experience with IDEs is in weak languages and they seem not to be used in strong languages (Scala being an exception, although I haven't tried its IDE support).

In addition, it's worth pointing out that many Java programmers use unit tests as a poor-man's REPL; it's not the same, but it serves a similar purpose

Interactivity and unit tests serve different purposes. I don't think either is an acceptable substitute for the other (and yes, I've seen people attempt both substitutions).

For me, interactivity is the only thing that keeps me in a state of flow (instead of boredom) when I have to read code, especially because there's at least one library for which I really want a REPL so I can see what the calls do.

I just really feel like your "the REPL is essential" argument is pretty misguided.

I guess I should be saying "interactivity is essential". C technically doesn't have a REPL, but it succeeded as a language because the C/Unix philosophy encouraged small programs that could be used and explored at the command line, which keeps the C environment engaging and tractable as long as people aren't writing huge programs. I haven't seen interactivity superior to what the REPL provides, but I haven't seen enough to rule it out either.

Re: Why software sucks?

#72

Earlier quoted context omitted.

It fits most cases.. except that web applications are _constantly_ polling for information. Web applications are a very small part of the web as a whole. you can implement polling with interrupts But why would you? Are you aware that the OS is using an interrupt-driven system to poll the server? Yes. So? In that case, interrupts are a great fit. In others, they aren't. This is just dumb engineering. Why? And to say t…

You haven't made any technical points. You just waffled nonsense about scalability. I see you're bowing out of the argument because you have no case. Once you have interrupts on a platform, you have polling. If you're stuck with polling you can't recover interrupts. Which is why we have websockets decades late. The truth is there is not tension between interrupts and polling. Interrupts are plainly superior, since yo…

Notice how the posts that are downvoted have no replies, because the downvoters cannot argue their case. How sad.

Re: Why software sucks?

#73
post #36

Software sucks because too often developers fail to learn what the software is supposed to do. Developers trivialize things and interpret them in far "superior" ways that lead to huge gaps of "they never told us". Development has to move from just coding, to learning to first understand what details are being managed, and how those details interact in a system in all the stages the details/data exist. If we believe e…

So in summary: When you have a great idea, translate your intended statement of "we can improve things by doing X instead of Y" to the question "why are you doing Y?". And again: Paper prototyping. Sticking an interactive bit of paper in front of a user is an effective and inexpensive way to get him to explain the holes in your great idea, and you can adapt it there and then and maybe come up with something that fixe…

Why, always before how.

A question I like asking is, "Teach me why this needs to be improved".

So when a question like this takes us 8 hours a week, every week, comes up, you can say we can save 416 man hours a year if you let me work on this for 40 hours.

I'm not sure whether or not there's paper prototyping. I use a lot of different tools, the most important of which helps me whittle down an idea to it's essence. For me that magic happens on whiteboards, and on paper first.

I've recently started doing it using a stylus on an iPad and a Galaxy Note with increasing success. I almost prefer the iPad or Galaxy Note because I can keep erasing and refining to get the perfect layout/design.

Re: Why software sucks?

#74

Here are some thoughts I'd put into the mix. 1. Software that is built to deadline will decay, even if the developers are good. That doesn't mean that an occasional deadline is the end, but if a long-term "deadline culture" sets in, get out. A long-standing deadline-oriented culture means you should be looking to jump to another project or company before the maintenance phase starts, because (1) the maintainers will…

I did not appreciate how useful IronPython is when developing with C# at work until read this and thought about what the alternative would be like. To test our wafer handling robot, I can just instantiate it's individual axes at the REPL and move them around. Our I can create the whole device object and move them around in a coordinated manner. Any level of the system can be tested or cycled for reliability without having to write test fixtures in C#

Re: Why software sucks?

#75
One reason I don't think gets mentioned enough for software sucking: developers don't really use the product enough to optimize it (they don't have time). Especially for complex applications. If there isn't an effective feedback loop from users about pain points, and an institutional drive to address them, major problems in software persist version after version.

Re: Why software sucks?

#76

Earlier quoted context omitted.

You haven't made any technical points. You just waffled nonsense about scalability. I see you're bowing out of the argument because you have no case. Once you have interrupts on a platform, you have polling. If you're stuck with polling you can't recover interrupts. Which is why we have websockets decades late. The truth is there is not tension between interrupts and polling. Interrupts are plainly superior, since yo…

Notice how the posts that are downvoted have no replies, because the downvoters cannot argue their case. How sad.

I had not downvoted you, but I thought about it - because you are making ranty, ad hominem attacks ("lazy thinking", "dumb excuses"), and you appear to be ignoring or handwaving away all the actual points anyone makes. I have no interest in engaging you in any discussion for these reasons, and I expect that other people feel the same way: hence, downvotes and lack of replies. Feel free to do what you wish with this information.

Re: Why software sucks?

#77
In this thread many people give different reasons why they think software sucks. This prompts some meta-questions:

1) Why are all these people so confident, if only a minority of them can be right?

2) What procedure would make everyone converge on the same correct answer?

Re: Why software sucks?

#78

Here are some thoughts I'd put into the mix. 1. Software that is built to deadline will decay, even if the developers are good. That doesn't mean that an occasional deadline is the end, but if a long-term "deadline culture" sets in, get out. A long-standing deadline-oriented culture means you should be looking to jump to another project or company before the maintenance phase starts, because (1) the maintainers will…

I'd like to see some empirical evidence for some of your arguments. Not that I don't _want_ to believe you - I do, but my occam's razor is starting to twitch a little.

Re: Why software sucks?

#79

Earlier quoted context omitted.

It just goes to show that market forces do not care about technical merit and ultimate purpose in the least. NeWS never got traction, yet the advance of the web is inexorable. Why? Well the web is supported everywhere because it was simple. The fact that it is available everywhere (which is actually pretty amazing and unique in the entire history of media if you stop and think about it) meant people kept pushing the…

Well. You're getting downvoted for wishing death on people you've never met. >The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;) That sounds like some sort of evil plot. For that matter my beard isn't anywhere close to being gray and I know that things could have been better. And if you didn't…

Who's wishing death on anyone? It's just a colorful way of saying that people will soon enough take the web heritage of apps for granted.

Re: Why software sucks?

#80

Earlier quoted context omitted.

Your first sentence is in conflict with your example. The UI complication of the refresh button is minuscule in comparison to the technical complexity of implementing universally canonical web page views. But even assuming you could make that work well enough it's impossible to make software that anticipates all needs correctly. A good example was brought up on 5by5 a few weeks ago: should the iPhone alarm be silence…

Stop making stupid excuses. The fact that some people might get confused by some detail (like your iPhone alarm example) does not change the fact that some some other things are idiotic (like the refresh button). And your take on the refresh problem shows why this whole thing is a complete mess: I'm not suggesting "universal" auto-refresh. This is why the browsers is such a failure technologically: people want to try…

You're off the deep end man. Sure, things could be immeasurably better if you could get everyone to swim in the same direction to solve the big problems. That's not how things work though, we're all in the same boat you are, trying to do the best we can in an imperfect world. This is not a failure of the profession, it's a universal human failing, maybe even more universal than that.
Post reply on HN