Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

431–440 of 504 posts

Re: Software Disenchantment (2018)

#431

Earlier quoted context omitted.

Or the car could just be very efficient. Gasoline has a lot of energy. Transporting a person 100km on 34MJ/l * 0.05l =1.71MJ doesn't sound as impossible as you make it seem.

Trains transports at 0.41 MJ/t·km. If the person weights 0.1t it would take a train packed full of people 41MJ per person to transport them 100km, or a bit more than one litre of gasoline. I don't think it is possible to go significantly below that without transporting them on mag rails or vacuum pipes. Secondly we talked about 0.005l cars, not 0.05l, so it would be a few hundreds times more efficient than train tran…

Bicycles are probably a bit more efficient than trains.

Re: Software Disenchantment (2018)

#433
post #8

I agree it's all slower and sucks. But I don't think it's solely a technical problem. 1/ What didn't seem to get mentioned was the speed to market. It's far worse to build the right thing no one wants, than to build the crappy thing that some people want a lot. As a result, it makes sense for people to leverage electron--but it has consequences for users down the line. 2/ Because we deal with orders of magnitude with…

It's not a technical problem at all. It's an economy problem.

Re: Software Disenchantment (2018)

#434

Long ago I watched a documentary about the early Apple days, when management was encouraging their developers to reduce boot times by 10 seconds. The argument was that 10 seconds multiplied by the number of boot sequences would result in saving many human lives worth of time. Edit: found a link with the same story: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt The software world needs more of this kind…

If the cost of that boot time was somehow materialized upstream - e.g. if companies that produced OSes had to pay for the compute resources they used, rather than the consumer paying for the compute - then economics would solve the problem.

As it is, software can largely free ride on consumer resources.

Re: Software Disenchantment (2018)

#435
post #178

Long ago I watched a documentary about the early Apple days, when management was encouraging their developers to reduce boot times by 10 seconds. The argument was that 10 seconds multiplied by the number of boot sequences would result in saving many human lives worth of time. Edit: found a link with the same story: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt The software world needs more of this kind…

I wish more companies thought like this in general. I often think about the nature of the work I'm doing as a developer and wonder if it's making society better off as a whole. The answer is usually a resounding no.

They could think like this if it became part of their cost structure. There's no reason for them to think like this other than in terms of profit & loss.

Re: Software Disenchantment (2018)

#436

Earlier quoted context omitted.

So why is it persistently, perniciously and stubbornly insistent in refusing to spell 'naughty' words like 'duck'?

What's the problem again? I just typed "duck" by swiping. If you mean the "i" variant, be informed that swear words are blocked unless a preference is set.

They mean the "f" variant.

Re: Software Disenchantment (2018)

#437

Earlier quoted context omitted.

> In fact, there are so many occasions where the optimisation is so good that the end user doesn't believe that anything happened. So you have to deliberately introduce delay because a computer has to feel like it thinks the same way you do. I never liked this view. I can't think of a single legitimate use case that couldn't be solved better than by hiding your true capabilities, and thus wasting people's time. > the…

"I can't think of a single legitimate use case that couldn't be solved better than by hiding your true capabilities, and thus wasting people's time." Consider a loading spinner with a line of copy that explains what's happening. Say it's for an action that can take anywhere from 20 milliseconds to several seconds, based on a combination of factors that are hard to predict beforehand. At the low end, showing the spinn…

Wouldn't it be better to delay the appearance of the spinner, so it doesn't show at all for those fast operations?

Re: Software Disenchantment (2018)

#438
>> Build systems are inherently unreliable and periodically require full clean

What frustrates me above all else is the trend of compile-to-javascript languages. IMO interpreted languages are great, of course some performance was sacrificed to get there - I think that was a fair trade-off because saving the developer from having to build the project is a HUGE advantage when developing (at least for my particular development flow)... So when I see people throwing away that massive advantage by adding an unnecessary compile step in order to get slightly better syntax or static typing (e.g. CoffeeScript or TypeScript), I find it deeply disturbing. Static typing can be a useful feature, but is it worth adding a compile step? Not by a long shot.

And the idea of transpiling a language into an interpreted language is just ridiculous in principle. We had an army of very smart people who invested a huge amount of time and effort into making efficient interpreters for certain languages but all that work is thrown away as soon as you add a build step.

And the stunning thing is that it's actually possible (easy even) to create excellent software with clean code without a build step (I've done it many times) but these simple, clean approaches are never popular. People want to use the complex approach that introduces a ton of new problems, delays and compatibility issues.

Re: Software Disenchantment (2018)

#440
post #232

Earlier quoted context omitted.

The big problem is this, if we related this back to software it would mean the software being delivered in 10-15 years, rather than in 6 months. Kind of a big downside...

That's the old Ruby on Rails argument. In that specific case it only made sense when there were no similar frameworks for faster languages, but that's hardly the case today.

Ironically though, I'd be willing to bet that end-user performance on most traditional server-side-rendered apps using the "heavyweight" RoR framework is far better than the latest and greatest SPA approach.
Post reply on HN