“No one makes bad software on purpose” is not strictly true: many esoteric programming languages are designed to be “bad” in interesting ways. That extends to any subversion of highly-regarded tropes in games and other media, even the non-interactive kind. It’s also not true that “in order for people to say ‘this sucks’ they have to care enough about the thing you’ve made to spend time with it and recognize how bad it is”. People routinely criticise programming languages and other software they’ve never used before, even if said software doesn’t actually suck much at all.
Why software sucks?
41–50 of 82 posts
Re: Why software sucks?
#42If we invented the car, but there was no reverse and no left turn, we could say that the problems were due to poor drivers and poor planning, but the problem would clearly be that the car is not sufficiently wieldy. You can say that software sucks because of poor programmers and poor project management, but the truth is that the code is not sufficiently wieldy. There's no way to manage the code. I can't query all pla…
"I can't query all places in the code where the UI interacts with a database column." Why can't you?
Re: Why software sucks?
#43Earlier quoted context omitted.
Writing desktop apps within a browser running on a desktop is what's crazy... Pointless layers of abstraction.
What are the practical issues you're concerned about? Dev time? performance / reliability?
Dev time, you say. Well let me tell you a story. I am quite into 8-bit, I like buying micros from the 80s as junk and fixing them up. Recently, my old lady and I wanted a spreadsheet to track days off, vacations and so on. I could have done it on the quad-core, 8G Mac in Excel or online with Google Docs... But I actually did it in ViewSheet on a BBC Micro.
So dev time, well the last THIRTY YEARS of dev time haven't gotten me any anything I didn't have already.
Re: Why software sucks?
#44Software is too complicated. Now that we have a generation growing up with computers software engineers are happily brain-damaging them into expecting hugely complex software that doesn't really work. The browser is the perfect example. Why can the user manually reload a page? Shouldn't it all update automatically? The answer is: it's that way because it was convenient for lazy designers a long time ago and nobody bo…
This isn't rationalizing, but... no, automatic refreshing isn't being 'lazy'. They're called browsers because they were meant to let people browse , not consume as a TV watcher. If I was reading a book, and the author made an update, I wouldn't necessarily want the new update from the author. Notify me there's an update? Sure! Automatically replace the copy I'm reading with the update, simultaneously removing my abil…
Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading?
This is an asinine example. Why would the author do this except to correct typos or update the kind of information you want updated? Who are these nefarious authors trying to destroy your reading experience? They don't exist, and this kind of lazy thinking is why it took until very recently for browsers to even have the possibility of auto-update without polling (hello 1970).
Re: Why software sucks?
#45Here 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 Javascript, I'm hesitant to, say, rename a method, because finding and fixing all references is a pain. In IntelliJ, it's trivial. The end result is that I refactor my Java code much more aggressively than code in a language where I don't have a (good) IDE. Similarly, while you use the REPL to explore libraries, I use the IDE: exploring source in a Java project is trivial because every class and method is instantly cross-linked, and my IDE knows where all the code is (including for my libraries). 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. 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. 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.
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: I want to write some code, then execute it to make sure it does what I think. It's less dynamic, but it has the advantage of leaving you with regression tests, and it does let you explore and quickly iterate your code. If I'm not sure how to use a library, I'll do exactly what you'd do with a REPL: I'll write some code to use the library, then write a simple test that executes that code, and then I'll iterate my way to a correct solution. Again, the integration of the IDE with the unit tests makes running, debugging, and bouncing between the test and the code much easier than it would be in, say, vim/emacs and a terminal.
My point is that good programmers in any language find a way to do the sort of iterative evolution and exploration of code that you act like is only possible with a REPL, allowing them to fix errors early.
Many of your other points here are good, I just really feel like your "the REPL is essential" argument is pretty misguided.
Re: Why software sucks?
#46A little while ago I overhead a conversation between some friends of mine, one of whom is an interior designer who does residential remodeling:
a: "We always tear out everything, down to the rafters." b: "That sounds expensive." a: "It can be, especially if you find out the wiring or something isn't up to code." b: "What if someone wants only---" a: "No, there's no 'only'."
In my experience, if programmers always had a complete design specification before starting, and if we always "tore up" the old mess (down to something unquestionably stable) before making any improvements, our software would be much, much better. It'd probably also cost more.
The biggest cause of this that I see is that the people paying for it are not the people using it. In the consumer market we are starting to see that good design does sell (I think it was Gropius who predicted that the cost of design is amortized). But with enterprise software, the people paying for it are rarely the ones using it, so they're perfectly willing to buy a lousy program if it means saving cash in the short term.
Re: Why software sucks?
#47Software is too complicated. Now that we have a generation growing up with computers software engineers are happily brain-damaging them into expecting hugely complex software that doesn't really work. The browser is the perfect example. Why can the user manually reload a page? Shouldn't it all update automatically? The answer is: it's that way because it was convenient for lazy designers a long time ago and nobody bo…
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 to solve all the problems in the platform instead of just providing simple, powerful primitives. As you recognise we need to restrict scope. The only software that actually works is simple and small. And I'm not just "admonishing others". I dropped out of academia and industry and moved into a cheaper neighbourhood to be independent so I can write the simplest software possible. To me that's better than empty talk about "UX" and other modernistic double-talk about how hard we've got it. And having an independent perspective, I can see that it's rationalisations all the way down. We will have botnets etc forever until people tackle the problems as a basic level by simple designs that eliminate the problems. But people can't even conceive of putting ethics before their own financial well-being because as an industry we have no ethics. Just pride in spreading our bullshit around as much as possible.
If software engineers built bridges we'd make it drive up and down the river, put in a few houses to be "efficient". And then when the thing breaks down we'd complain that it's "too hard". No shit it's too hard: because we promise more than we can deliver, hiding the risks and problems from the user. Firefox has as a feature in every version the ability for criminals to install rogue programs on your computer. And yet you won't see this in their marketing material. This is a solved problem. We know how to eliminate memory-safety problems, but Mozilla would rather take N years to do their rust rewrite (if it even happens) because it's in their self interest. If we had any ethics as an industry Firefox would come with a warning that it makes it possible to install rogue programs on your computer. But it won't.
Re: Why software sucks?
#48Earlier quoted context omitted.
What are the practical issues you're concerned about? Dev time? performance / reliability?
Dev time, you say. Well let me tell you a story. I am quite into 8-bit, I like buying micros from the 80s as junk and fixing them up. Recently, my old lady and I wanted a spreadsheet to track days off, vacations and so on. I could have done it on the quad-core, 8G Mac in Excel or online with Google Docs... But I actually did it in ViewSheet on a BBC Micro. So dev time, well the last THIRTY YEARS of dev time haven't g…
And today I walked a mile from my grandmother's to my house. The last HUNDRED YEARS of car manufacturing haven't gotten me any anything I didn't have already.
Re: Why software sucks?
#49A little while ago I overhead a conversation between some friends of mine, one of whom is an interior designer who does residential remodeling: a: "We always tear out everything, down to the rafters." b: "That sounds expensive." a: "It can be, especially if you find out the wiring or something isn't up to code." b: "What if someone wants only---" a: "No, there's no 'only'." In my experience, if programmers always had…
In my experience, if programmers always had a complete design specification before starting, and if we always "tore up" the old mess (down to something unquestionably stable) before making any improvements, our software would be much, much better. It'd probably also cost more.
And by the time the software was done, it'd be useless. A house doesn't get obsolete in ten years, but software - which is much more complex than a house - can be obsolete in ten months.
Not to mention that I'd rather not be reinventing the wheel every six months.
Re: Why software sucks?
#50Earlier quoted context omitted.
What are the practical issues you're concerned about? Dev time? performance / reliability?
Dev time, you say. Well let me tell you a story. I am quite into 8-bit, I like buying micros from the 80s as junk and fixing them up. Recently, my old lady and I wanted a spreadsheet to track days off, vacations and so on. I could have done it on the quad-core, 8G Mac in Excel or online with Google Docs... But I actually did it in ViewSheet on a BBC Micro. So dev time, well the last THIRTY YEARS of dev time haven't g…
I would personally not put up with a spreadsheet where the GOTO cell function is rather awkardly hidden on function key number seven.