Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

Post reply on HN
Print view View original

191–200 of 504 posts

Re: Software Disenchantment (2018)

#191

Post by ipodopt »

jiofih wrote: post #88
buboard wrote: post #68

He has a nice follow up which gets to the reasons why https://tonsky.me/blog/good-times-weak-men/ Another take: rewrites and rehashes tend to be bad because they are not exciting for programmers. Everything you re about to write is predictable, nothing looks Clearly better and it just feels forced. First versions of anything are exciting, the possibilities are endless, and even if the choices along the path are subop…

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…

Flutter is a very good bet IMO. It uses Dart was designed from the ground up to be a solid front end language instead of building on top of JS. The underlying architecture of flutter is clearly articulated and error messages are informative. Still seems a bit slow and bloated in some aspects but it is getting better every day and I think their top down control of the stack is going to let them trim it all the way down.

Re: Software Disenchantment (2018)

#192

Post by TeMPOraL »

makapuf wrote: post #172
macjohnmcc wrote: post #39

Earlier quoted context omitted.

Most developers I have known want to work on the new great new thing. They don't want to spend a great deal of time on the project either. Forget about them wanting to dedicate time to software maintenance. Not sexy enough.

Ok but why ? And what can we do to improve things? Promote maintenance, but I think one of the issues is that you can show something new, it's much more difficult to show that something could have changed (failure, difficulty to grow), but didn't.

To the extent it's in your power as a developer and a team member, don't tolerate low-performance code from yourself or your co-workers.

In my experience, a lot of performance problems boil down to really stupid problems, like simple code using the wrong data structure out of convenience (e.g. linked lists instead of arrays for lots of randomly-accessed data), or structured in a bad way (e.g. allocating a lot of small pieces of memory all the time). Often times, there are cheap performance wins to be had if you occasionally run the product through a profiler and spend couple of hours fixing the most pressing issue that shows up. Couple of hours isn't much; there's enough slack in the development process to find those hours every month or two, without slowing down your regular work.

Re: Software Disenchantment (2018)

#193

Post by zamadatix »

_trampeltier wrote: post #164
hermitcrab wrote: post #155

As a dinosaur who has been programming for >30 years, it shocks me how bloated many modern programs are. The installers for my own products are around 20MB and most of that is Qt libraries. But 100s of MB seems to be standard now. The Airbnb app on my iPhone is 210 MB. I understand that if you are shipping a 3d game with maps, textures, sound etc, but not for a mobile phone app.

The sound driver on my ZBook at work does need almost 500MB Ram. No idea what is in there .. maybe HP has these days not just keyloggers included in the drivers, maybe the have screengrabbers too.

Probably 1 MB for the actual driver and 499 MB for the Electron GUI to interface with it.

Re: Software Disenchantment (2018)

#194

Post by buboard »

TeMPOraL wrote: post #186
jiofih wrote: 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…

I think my favourite fact(oid) to point out here would be that the React model is essentially the same thing as the good ol' Windows GUI model. The good ol' 1980s Windows, though perhaps slightly more convenient for developers. See [0]. I think it's good to keep that in mind as a reference point. -- https://www.bitquabit.com/post/the-more-things-change/

if webdev is going to go through all the iterations of GUI development ... oh boy , there are decades of frameworks ahead

Re: Software Disenchantment (2018)

#195

Post by AgentOrange1234 »

rogerdb wrote: post #86
thanhhaimai wrote: post #45

Earlier quoted context omitted.

> "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. I'll prioritize the 0.005L per 100km car for sure. That means the car can be driven for all its expected lifetime (500k km) in a single tank of gas, fill…

This is definitely an interesting take on the car analogy so thanks for posting it! I don't know that I agree 100% (I think I could 'settle' for a car that needed be be fueled once or twice a year if it came with some other noticeable benefits), but it is definitely worth remembering that sometimes an apparently small nudge in performance can enable big improvements. Miniaturization of electronics (including batterie…

> sometimes an apparently small nudge in performance can enable big improvements

In this thought experiment we are talking about a 2 orders magnitude improvement - hardly a small nudge!

Re: Software Disenchantment (2018)

#196

Post by itqwertz »

...And someone just made their first million with some buggy PHP app. Perfectionism is the enemy of progress. In the end, software is categorized into two types: software that people bitch about and software no one uses.

Re: Software Disenchantment (2018)

#197

Post by ashton314 »

megous wrote: 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…

I was traveling in Europe for a few months and I didn't care to change my phone plan so I was stuck with 2G speeds the entire time. It gave me a profound appreciation for web applications that load the minimal amount of code/resources/whatnot to display. HN really shines here. :)

Re: Software Disenchantment (2018)

#198

Post by TeMPOraL »

neilalexander wrote: post #187
city41 wrote: post #58

This article really resonates with me. But my biggest complaint is everything is _so_ buggy! I won't name any names, but I find many major pieces of software from large, well known companies are just riddled with bugs. I also feel like you almost need to be a programmer to think of workarounds "hmm, ok, so clearly it's in a bad state. If I had coded this, what boundaries would likely cause a complete refresh?" My wif…

I'll gladly name names. Apple have totally forgotten how to test and assure software against what appear to be even stupid bugs. macOS Catalina has been fraught with issues ranging from the minor to the ridiculous. Clearly nobody even bothered to test whether the Touch Bar "Spaces" mode on the MacBook Pro 16" actually works properly before shipping the thing. Software updates sometimes just stop downloading midway th…

> My question is who is testing this stuff?

Telemetry.

Companies seem to be increasingly preferring to use invasive telemetry and automated crash reports in lieu of actual in-house testing, and they use that same telemetry to also prioritize work. I have a strong suspicion that this is a significant contributing factor to the absurdities and general user-hostility of modern products.

Re: Software Disenchantment (2018)

#200

Post by TeMPOraL »

buboard wrote: post #101
sildur wrote: post #59

Earlier quoted context omitted.

You are going to have a heart attack if you check the energy consumption of bitcoin.

Then again , you could embed those as space heaters, or cooking machines, since they dont need portability

But there's no point, because all those heaters aren't going to beat ASIC farms near cheap electricity sources anyway.

(Do individuals really bother mining bitcoin these days anyway?)

Post reply on HN