Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

301–310 of 504 posts

Re: Software Disenchantment (2018)

#301
post #112

Well complaining about it does not change anything. Support the projects that you believe will help with these problems with $ and things might actually change.

> Well complaining about it does not change anything

The twelve steps program may be controversial, but I think the first step, 'admitting you have a problem', is generally the first step of any productive approach to problem solving.

Re: Software Disenchantment (2018)

#302
post #20

> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. If bas…

I think objections like this may be put in terms of measurable cost-benefits but they often come down to the feeling of wasted time and effort involved in writing, reading and understanding garbage software.

Moreover, the same cost-equation that produces software that is much less efficient than it could be produces software that might be usable for it's purpose (barely) but is much more ugly, confusing, and buggy than it needs to be.

That equation is add the needed features, sell the software first, get lock in, milk it 'till it dies and move on. That's equation is locally cost-efficient. Locally, that wins and that produces the world we see every day.

Maybe, the lack of craftsmanship, the lack of doing one's activity well, is simply inevitable. Or maybe the race to the bottom is going to kill us - see the Boeing 737 Max as perhaps food for thought (not that software as such was to blame there but the quality issue was there).

Re: Software Disenchantment (2018)

#303

Earlier quoted context omitted.

RTFA: >And build times? Nobody thinks compiler that works minutes or even hours is a problem. What happened to “programmer’s time is more important”? Almost all compilers, pre- and post-processors add significant, sometimes disastrous time tax to your build without providing proportionally substantial benefits.

FWIW, I did RTFA (top to bottom) before commenting. I chose to reply to some parts of the article and not others, especially the parts I felt were particularly hyperbolic. Anecdotally, in my career I've never had to compile something myself that took longer than a few minutes (but maybe if you work on the Linux kernel or some other big project, you have; or maybe I've just been lucky to mainly use toolchains that avo…

Then you're being disingenuous in picking a quarter of the quote.

>You’ve probably heard this mantra: “Programmer time is more expensive than computer time.” What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time.

The point is that we are wasting all the resources at every scale. We are supposedly burning computer cycles because developer time is more important. Yet we are also burning developer time with compiling, or testing for interpreted languages, at a rate that is starting to approach the batch processing days.

Re: Software Disenchantment (2018)

#304
post #43

I was in Rome recently, and google maps were basically unusable on EDGE (dsepite pre-downloading the area before the trip). We'd wait a minute (or more) for a timetable of a bus stop and a route of the bus to be show on the map. Try planning a route in an unfamiliar area with this slow an UI when you are standing outside and there's no place to sit and rest, and you need to click around on a bunch of stops just to se…

Why were you using EDGE if there’s dense 4G coverage in Rome ?

Should the answer to that question even matter? Even a 56k modem should be more than sufficient to fetch a few measely bus schedules.

Re: Software Disenchantment (2018)

#305
I love that he linked this page in the article:

https://docs.gitlab.com/ee/administration/operations/unicorn...

because I've had to deal with that a bit. N.B. the last sentence here:

One other thing that stands out in the log snippet above, taken from GitLab.com, is that ‘worker 4’ was serving requests for only 23 seconds. This is a normal value for our current GitLab.com setup and traffic.

Re: Software Disenchantment (2018)

#306
Whenever I see a rant that is a blanket "all is bullshit" list of complaints, I check if there are any actionable proposed solutions. Author gave none, so I dismiss all this with a flick of my hand.

Re: Software Disenchantment (2018)

#307

Earlier quoted context omitted.

Sure: If you can optimize the software that runs on many millions of computers then you can have a huge impact. If you run those computers yourself you can even save money. But the vast majority of software is one-off stuff. It makes no sense to optimize it for performance instead of features, development time, correctness, ease of use, etc.

> But the vast majority of software is one-off stuff. Is it now? I can't think of any example, except a few tools we use internally in a project. Everything else I use, or I see anyone else using, has an userbase of many thousands to millions, and a lot of that is used in context of work - which means a good chunk of the userbase is sitting in front of that software day in, day out.

It'd be interesting to know, say, what percentage of software developers work on programs that have less than a million users.

I wouldn't be at all surprised if it's the majority. For every big-ticket software offering there's going to at least be things the user never interacts with, like a build system and a test suite and a bug tracking system and whatever else. And there's just so much software everywhere, most of which we never see. Every small business has its little web site. Who knows how much software there is powering this or that device or process at random factories, laboratories, and offices.

The Debian popularity contest looks like it has a big long tail of relatively unpopular packages [1]. It looks like the app store has 2 million apps, only 2857 (.14%) have more than a million dollars of annual revenue. These are of course incomplete and flawed and do not really directly address the question. I don't really know how to research this in a thorough way.

[1] https://popcon.debian.org/by_inst [2] https://expandedramblings.com/index.php/itunes-app-store-sta...

Re: Software Disenchantment (2018)

#308
post #88

Earlier quoted context omitted.

He hints at Electron in the end, but I think the real blame lies on React which has become standard in the past five years. Nobody has any fucking idea what’s going on in their react projects . I work with incredibly bright people and not a single one can explain accurately what happens when you press a button. On the way to solving UI consistency it actually made it impossible for anyone to reason about what’s happe…

Yes both appear to be a disaster. Vuejs is a bit better imo but i'm generally holding out for the next thing.

... which is https://svelte.dev

Re: Software Disenchantment (2018)

#310
Large socio economic factors are at play.

It depresses me to no end too, but i am surprised in the least.

There were tiny groups trying to go frugal and solid. Remember suckless ? I forgot other names, there's also alan kay vpri project with ometa.

Maybe we should make a frugalconf. Everything 25fps on a rpi zero

Post reply on HN