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

Software disenchantment

tonsky.me

Post reply on HN
Print view View original

11–20 of 98 posts

Re: Software disenchantment

#11

Post by xg15 »

almostarockstar wrote: post #9

It's an interesting game we are playing. Take websites as an example. We have to build websites using CSS and HTML and JS because that is what works in browsers. But browsers have to build DOMs, layout engines and JS engines this way because that's the way we write code. It's nobody's fault. It's evolution with a bad fitness function. We need a new start. A new paradigm.

No, there were some deliberate design decisions. E.g., there was an attempt at a new start: XHTML 2. This got boycotted by browser vendors out of a mix of politics and business priorities.

Instead they went with HTML 5, which generally sees scripting as the core to make non-trivial web applications and also explicitly encourages JS libraries and frameworks.

So I don't think it's surprising that today, pages are piles of scripts on top of scripts.

Re: Software disenchantment

#13

Post by sebastianconcpt »

To capitalize current programmers know how with those expectations of performance would require a radical shift in hardware. It would demand hardware that is optimally designed for multi-paradigm high level languages.

Ironically, that was what the Burroughs 5000 was: https://www.smecc.org/The%20Architecture%20%20of%20the%20Bur...

"The Burroughs B5000 was designed from the start to support high level languages (HLLs), specifically ALGOL and COBOL. The initial features supporting this were the hardware-managed stack, the descriptor, and segmentation. A redesign of this system, the B6000, extended the concept by moving the tag bits to their own field, external to the 48-bit data word. The instruction set was also revised and extended, and has remained essentially unchanged ever since. HLLs are supported by hardware that allows virtual memory, multiprocessing, fast context switching and procedure invocation, memory protection, and code sharing."

Emulator project: http://retro-b5500.blogspot.com

Re: Software disenchantment

#15

Post by expertentipp »

udba wrote: post #3

I agree with the author. Often I find it refreshing to step away from the absurdity of software development and go work on my car. Working on your car exposes you to the fruits of a bona fide engineering process: objects that are carefully designed, work reliably, and are made with serviceability in mind. They aren't just slapped together and thrown out the door like (100-epsilon)% of software out there.

I would prefer not to touch the turbines attached to downsized 1L 120HP engine, software update only at authorized shops cost north of 150 EUR, the entertainment system had access to youtube initially but was cut off after 12 months, the LED system of headlights was likely someone’s PhD dissertation. Car industry is the eqivalent of web front-end in the software world, except one is unable to just shut down the browser.

Re: Software disenchantment

#16

Post by hadrien01 »

alcio wrote: post #5

> Recently our industry’s lack of care for efficiency, simplicity, and excellence started really getting to me, to the point of me getting depressed by my own career and the IT in general. Loading this website resulted in 5.3MB being downloaded over 42 requests.

I have only 2.8MB on my computer with the adblocker (the website has Google Analytics and a Twitter widget), mostly images. Fonts/Text/CSS: 120KB. And the website works perfectly without Javascript.

Re: Software disenchantment

#17

Post by pknopf »

sebastianconcpt wrote: post #13

To capitalize current programmers know how with those expectations of performance would require a radical shift in hardware. It would demand hardware that is optimally designed for multi-paradigm high level languages. Ironically, that was what the Burroughs 5000 was: https://www.smecc.org/The%20Architecture%20%20of%20the%20Bur... "The Burroughs B5000 was designed from the start to support high level languages (HLLs),…

People are focusing too much on the "performance" aspect of the article.

The "Programming is the same mess" section is what really resonates with me, specifically this:

> And dependencies? People easily add overengineered “full package solutions” to solve the simplest problems without considering their costs. And those dependencies bring other dependencies. You end up with a tree that is something in between of horror story (OMG so big and full of conflicts) and comedy (there’s no reason we include these, yet here they are):

Re: Software disenchantment

#18

Post by pknopf »

jaclaz wrote: post #6
udba wrote: post #3

I agree with the author. Often I find it refreshing to step away from the absurdity of software development and go work on my car. Working on your car exposes you to the fruits of a bona fide engineering process: objects that are carefully designed, work reliably, and are made with serviceability in mind. They aren't just slapped together and thrown out the door like (100-epsilon)% of software out there.

I see you have an oldish car ...

But it doesn't break down and require constant maintenance as the parts it uses become obsolete and need constant updating.

I'm just trying to get from A to B, not fly to Mars.

Re: Software disenchantment

#19

Post by throwaway080383 »

hyperpallium wrote: post #2

People won't pay for efficiency. People buy solutions to their problems (features), not efficiency. If it needs to be efficient, it will be (the games example). The death of Moore's Law may rejuvenate efficient software. BTW If you use old unix tools on a phone, it's super fast (in a terminal emulator like http://termux.com ). Sadly, the idea of abstractions enabling you to think better (like Alan Kay's point of view…

Just a few months ago, a very senior engineer on my team made this same observation about Moore's Law after I lamented that bit twiddling tricks and knowledge of obscure algorithmic speedups don't often end up being useful in practice.
Post reply on HN