Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

451–460 of 504 posts

Re: Software Disenchantment (2018)

#451
post #394

From a Reddit comment: > While I do share the general sentiment, I do feel the need to point out that this exact page, a blog entry consisting mostly of just text, is also half the size of Windows 95 on my computer and includes 6MB of javascript, which is more code than there was in Linux 1.0. Linux at that point already contained drivers for various network interface controllers, hard drives, tape drives, disk drive…

Since this Reddit comment was made, the Twitter iframe responsible for the megabytes of JavaScript has been replaced by a tag. The only JavaScript left on the page is Google Analytics, which is way less than 6MB.

And this really wasn't the author's fault—it's completely logical that if your story contains a tweet, you should attempt to embed it in the way Twitter recommends.

This is Twitter, not some random framework!

Re: Software Disenchantment (2018)

#452
In addition to the costs of developing good foundational code, I think revenue is becoming a driver for slower-than-necessary software.

An increasing number of providers (for example databases) charge per server, per core, or another hardware-usage metric. The more hardware, the more revenue for them as they make about 90% margin for every new machine. There is a high incentive to get users to need more machines on their "managed cloud".

Vendors could try to improve their software so it requires twice as little CPU. But why bother since this would result in 2x cost in revenue? It makes more sense to focus on horizontal scalability than on core efficiency so users can keep on adding machines to their cluster over time.

If software is running at 1% of the maximum performance as suggested in the article, a 1% improvement could reduce costs by 50%. But I think none of the existing vendors will ever make the move as it conflicts against their own interest.

Re: Software Disenchantment (2018)

#453
post #232

Earlier quoted context omitted.

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.

It really depends.

I've worked with a Preact SPA where the time to initial render was faster than the HAML templates it replaced.

But then, again, that was an outlier. If your target is speed, traditional SSR or static pages are the best bet, anyway.

Re: Software Disenchantment (2018)

#454

Earlier quoted context omitted.

"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?

You can still end up with the jarring flash. Say you delay 100ms--if the action takes 120ms, you have the same problem.

Re: Software Disenchantment (2018)

#455

Earlier quoted context omitted.

UI is hard because you're using a hyper text language with fewer features than were the standard in the 60s. Then with styling on top of that, then with a scripting language on top of that. Reading Computer Lib/Dream Machine over the holidays and I wonder where it all went so wrong.

Free markets hate good software. "Good" meaning secure, stable, and boring. On both ends. Software developers hate boring software for pragmatic HR-driven career reasons and because devs are apes and apes are faddish and like the shiny new thing. And commercial hegemony tends to go to the companies that slap something together with duct tape and bubble gum and rush it out the door. So you get clusterfucks like Unix w…

That brings to mind one common computer scientest fallacy - that elegence is an end to itself. It may share some properties which make it practical but unfortunately it is not in practice.

Recursive solutions are more elegant but you still use a stack and while loop to not smash the stack.

Re: Software Disenchantment (2018)

#456
post #212

Earlier quoted context omitted.

It's just the underlying model that is similar, but React is pretty good at abstracting all that (unlike Win32). When it comes to developer experience I'd say that React and company are ahead of most desktop UI technologies, and has inspired others (Flutter, SwiftUI).

So where's the RAD React tooling? Is that a thing yet?

Apparently there's React Studio, BuilderX and tools like Sketch2React and Figma to React. Ionic Studio will probably support React in a close future (maybe it already supports).

Re: Software Disenchantment (2018)

#457

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…

That's an important comment and made me think that nobody here has mentioned climate change (where human lives are/will be affected, literally). There is an emerging movement toward low-carbon, low-tech, sustainable web design, but it's still very much fringe. To make it mainstream, we all need to work on coming up with better economic incentives.

Re: Software Disenchantment (2018)

#458
post #362

Earlier quoted context omitted.

> "Even worse, try using an OS running in a VM for an extended period of time..." I actually do this for development and it works really well. Ubuntu Linux VM in VMware Fusion on a Macbook Pro with MacOS. Power consumption was found to be better than running Linux natively. (I'm guessing something about switching between the two GPUs, but who knows.) GPU acceleration works fine; the Linux desktop animations, window f…

What year MBP is this? I tried running Ubuntu on Virtual Box on my mid 2014 MBP with 16GB ram, but that was anything but smooth. I ended up dual booting my T460s instead. But perhaps the answer is VMware Fusion instead then.

It's a late 2013 MBP, 16GB RAM.

I've only given Linux 6GB RAM at the moment, and it's working out fine. Currently running Ubuntu 19.10.

I picked VMware Fusion originally because it was reported to have good-ish support for GPU emulation that was compatible with Linux desktops at the time. Without it, graphics can be a bit clunky. With it, it feels smooth enough for me, as a desktop.

My browser is Firefox on the Mac side, but dev web servers all on the Linux side.

The VM networking is fine, but I use a separate "private" network (for dev networking) from the "NAT" network (outgoing connections from Linux to internet), so Wifi IP address changes in the latter don't disrupt active connections of the former.

My editor is Emacs GUI on the Mac side (so it integrates with the native Mac GUI - Cmd-CV cut and paste etc, better scrolling), although I can call up Emacs sessions from Linux easily, and for TypeScript, dev language servers etc., Emacs is able to run them remotely as appropriate.

Smoothness over SSH from iTerm is a different thing from graphical desktop smoothness.

When doing graphics work (e.g. Inkscape/GIMP/ImageMagick), or remote access to Windows servers using Remmina for VNC/RDP, I use the Linux desktop.

But mostly I do dev work in Linux over SSH from iTerm. I don't think I've ever noticed any smoothness issues with that, except when VMware networking crashes due to SMB/NFS loops that I shouldn't let happen :-)

Re: Software Disenchantment (2018)

#459
post #362

Earlier quoted context omitted.

What year MBP is this? I tried running Ubuntu on Virtual Box on my mid 2014 MBP with 16GB ram, but that was anything but smooth. I ended up dual booting my T460s instead. But perhaps the answer is VMware Fusion instead then.

The answer is I/O latency. Having your VM stored inside a file on a slow filesystem is bad. Having a separate lvm volume (on linux)/zvols (with zfs)/partition/disk is much more performant.

I store my Linux VM disk inside a file on a Mac filesystem (HFS+, the old one), and I haven't noticed any significant human-noticable I/O latency issues when using it. The Linux VM disk is formatted as ext4.

That's about human-scale experience, rather than measured latency. It won't be as fast as native, but it seems adequate for my use, even when grepping thousands of files, unpacking archives, etc, and I haven't noticed any significant stalling or pauses. It's encrypted too (by MacOS).

(That's in contrast to host-guest file access over the virtual network, which definitely has performance issues. But ext4 on the VM disk seems to work well.)

The VM is my main daily work "machine", and I'm a heavy user, so I'd notice if I/O latency was affecting use.

I'm sure it helps that the Mac has a fast SSD though.

(In contrast, on servers I use LVM a lot, in conjunction with MD-RAID and LUKS encryption.)

Re: Software Disenchantment (2018)

#460

Earlier quoted context omitted.

Except that it also happens with internal software, where there's no separation between developers and end-users. It's second-system effect writ large. "We'll rewrite this old, outdated software and add plenty of bells and whistles! This time will be different, we'll finally be doing it right."

See, to me, internal software may be the one place where "developer time" really is more valuable (depending on the size of the organization), because you're developing for far fewer uses. One second times five million users is almost two months. One second times five thousand users is less than 90 minutes.

^ Bad typo, I meant to say "you're developing for far fewer users."
Post reply on HN