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

471–480 of 504 posts

Re: Software Disenchantment (2018)

#471

Post by somatic »

enlyth wrote: post #395
somatic wrote: post #337

Earlier quoted context omitted.

jQuery: 88KB, standard everywhere, one entity responsible for all of it, people know what it is and what it does, if it breaks you know what went wrong and who to blame. Literally anything built with NPM: megabytes? tens of megabytes? in size, totally inscrutable, code being pulled in from hundreds of megabytes of code in tens of thousands of packages from hundreds or thousands of people of unknown (and unknowable) c…

That's a problem with the npm ecosystem. React is just so, so much nicer to work with. It's easy to be dismissive if you've never had to develop UIs with jQuery and didn't experience yourself the transition to React which is a million times better in terms of developer experience. I feel like people that don't build UIs themselves think of them too much in a completely functional way as in "it's just buttons and form…

Yes, you're absolutely right: React itself is great. But React is part of the NPM ecosystem; try using one without the other.

And then if you're still feeling cocky try finding someone else who uses one without the other.

Re: Software Disenchantment (2018)

#472

Post by somatic »

Nasrudith wrote: post #455
somatic wrote: post #340

Earlier quoted context omitted.

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.

Scheme is properly tail-recursive and has been around since 1975. Most (all?) Common Lisp implementations have proper tail recursion. Clojure has tail call optimization for simple cases and only if you explicitly ask for it, but it gets you most of the way there most of the time.

So there are reasons to prefer more imperative languages and their systems, but stack-smashing isn't one of them.

Re: Software Disenchantment (2018)

#473

Post by MaxBarraclough »

golergka wrote: post #273
anilakar wrote: post #127

An unpopular but effective short-term solution: Developers ought to use five year old hardware for development and testing tasks. FWIW, my work laptop and mobile phone are both 2015 models and I feel they're completely adequate for running all the software I've written.

I was so proud in 2014 that our development team managed to pull a 60 FPS on iPhone 4. Built our own UI framework (before Unity rebuilt theirs), pulled images from network, assembled and updated sprite atlases at runtime and even created our own text rendering - all of it, in order to get 60 frames per second on 4 year old phone. And most likely, it still does, in 2020. Since then, I've never worked in a team that wo…

So the official toolkit wasn't capable of 60fps?

Re: Software Disenchantment (2018)

#474

Post by ljm »

icebraining wrote: post #437
danenania wrote: post #402

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?

This doesn't work well in apps but games do incredible things to hide that state; and it's partially a consequence of avoiding a patent on minigames inside loading screens.

e.g. back in the 90s with Resi 1, the loading screen was hidden by a slow and tense animation of a door opening. It totally fit the atmosphere.

Plenty of games add an elevator or a scripted vehicle ride, or some ridiculous door locking mechanism that serves the same purpose without breaking immersion, especially as those faux-loading screens can be dynamic.

It's pretty much the exact same technique used in cinema when a director wants to stitch multiple takes into a single shot (e.g. that episode in True Detective; that other one in Mr Robot; all of Birdman).

Re: Software Disenchantment (2018)

#475

Post by ljm »

thatfrenchguy wrote: post #445
ljm wrote: post #30

Earlier quoted context omitted.

I have to be careful about what I describe, but I don't think people care about speed or performance at all when it comes to tech, and it makes me sad. 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. At my current place of emplo…

Everywhere but the US uses l/100km (which is a much better metric than MPG).

It's still used in the UK too, in our hybrid metric/imperial setup.

Re: Software Disenchantment (2018)

#476

Post by wffurr »

>> That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply.

If I think back to my engineering school days, the definition of "engineering" for my classmates in civil and electrical engineering was to look up well defined procedures and calculations from a book and apply them. No deep understanding required to design a bridge that didn't fall down or a circuit that didn't overheat.

What's the equivalent for software? Design patterns were a bust. SICP is for cultists. It's a huge void. There is hardly any such discipline as "software engineering" yet.

Re: Software Disenchantment (2018)

#477

Post by tanseydavid »

This is extremely well-worded and gets right-to-the-point. This is so refreshing in contrast to the constant attempts to explain why software is so slow, bloated and especially unreliable.

An explanation of "why" does not explain "why this is acceptable".

Re: Software Disenchantment (2018)

#478

Post by nearbuy »

theandrewbailey wrote: post #448
nearbuy wrote: post #378

Earlier quoted context omitted.

I'm both a web developer and a game developer, and this comparison doesn't ring true at all. Games usually have tons of arbitrary dynamic content to display in realtime. Minecraft will load about 9 million blocks around your character plus handle mobs, pathfinding, lighting, etc. Reddit infinite scroll loads a sequence of text, images, and videos. Multiplayer games have such tight latency and bandwidth targets that g…

> As a web developer, sending an 8 KB JSON response is no problem. That's nice and light. In a networked action game, that's absurd. It depends on what that 8 KB is doing. If that 8 KB is a chat message, that's way too big. On the other hand, I've never seen an 8 KB game patch.

This doesn't really relate to my point. The blog post asked why is it that we can handle games (fancy 3D simulations, sometimes with hundreds of players and millions of objects) at a smooth 60 fps but not scrolling a web page. The parent comment suggested that it's easier to render games smoothly because you know the content in advance. I'm suggesting that software gets optimized (by necessity) until it works well enough. If some website had to display a million elements, the devs would either optimize it until it could do so, or the project would get scrapped.

When I talk about sending 8 KB in a "networked action game", I'm referring to the update packets sent to and from clients in something like Fortnite or Counter-Strike, not a game patch. I'm not trying to make a competition for who uses the least bandwidth (which a 60 GB game would lose just on the initial download). I'm trying to illustrate that games don't run faster than some website because it's inherently easier to make games run fast, but rather that developers, by necessity, optimize games until they run fast (or in this example, until they reduce network lag enough).

I'm not sure why a chat app would tack on something like 7.5 KB of overhead on a chat message, but I wouldn't be surprised if there's a chat app out there that does so. Users won't notice the extra couple milliseconds (especially so because they don't know exactly when the other person hit send). A 3 character Discord message is close to 1 KB including the headers. The same message over UDP in a game might be under 20 bytes, including the UDP header (games could also use TCP for chat - text chat isn't going to strain anything). So I'd say the overhead of a Discord message is still an order of magnitude or two bigger than it could be. Which is perfectly fine; we can afford 1 KB of overhead on a modern connection. It's optimized as much as it needs to be.

Re: Software Disenchantment (2018)

#479

Post by ptx »

jeffmcmahan wrote: post #222
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 completely agree, here. React has replaced the DOM, and it's pretty fast, pretty efficient when you understand its limitations... but when you start rendering to the canvas or creating SVG animation from within react code, everything is utterly destroyed. Performance is 1/1000 of what the platform provides. I have completely stopped using frameworks in my day-to-day, and moved my company to a simple pattern for upd…

Maybe React has the advantage as the project grows? From what I understand it batches updates from all the different components on the page, avoiding unnecessary reflows that might easily creep in when you do things the old-fashioned way.

Re: Software Disenchantment (2018)

#480

Post by ptx »

Sharlin wrote: post #406
mynegation wrote: post #136

Earlier quoted context omitted.

What is better? Jquery? It comes with its own can of worms and React designers had solid reasoning to migrate away from immediate DOM modification. In general UI is hard. Nice features like compositing, variable width fonts, reflow etc come with the underlying mechanisms that are pretty complicated and once something behaves different to the expectations it might be hard to understand why.

To an extent, UI was solved in 1991 by Visual Basic. Yes, complex state management is not the best in a purely event-based programming model. Yes, you didn’t get a powerful document layout engine seamlessly integrated to the UI. Yes, theming your components was more difficult. And so on. But… if the alternative is what we have now? I’m not sure.

One big disadvantage with Visual Basic (and similar visual form designers) is that you can't put the result in version control and diff or merge it in any meaningful way.
Post reply on HN