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

441–450 of 504 posts

Re: Software Disenchantment (2018)

#441

Post by megous »

xchaotic wrote: post #71
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…

Why were you using EDGE if there’s dense 4G coverage in Rome ?

Didn't enable it, because 3G is usually fine. But there was lack of 3G in many places.

Re: Software Disenchantment (2018)

#442

Post by cryptica »

From the JavaScript ecosystem, I'm frustrated by Babel's popularity. Whenever I discuss it with developers, everyone agrees that it's not worth it, and yet people still use it! It's as if we have no choice in the matter!

The whole point of Babel was to allow us to use the latest JavaScript syntax so that we wouldn't have to update our own source code when the new syntax finally became broadly supported by browsers and other engines.

IMO, the Babel project is a failure because:

- Babel itself is always being upgraded to support newer ECMAScript syntax, so people still need to upgrade their own code whether they use Babel or not. The only benefit is that using Babel allows you to use these features before other people.

- Instead of just worrying about how JavaScript syntax changes affect your code, with Babel, you also need to worry about how Babel upgrades will affect your code. The babel plugin dependencies often change and break over time (even if you don't change your own code) and you always have to support both ecosystems.

So when you consider the big picture, Babel doesn't save you from having to upgrade your own code (as per its original promise). When you evaluate the pros and cons, the cons greatly outnumber the pros:

Pros:

- You get to use the newest language features before other people.

Cons:

- You need to maintain your code for compatibility with two ecosystems instead of just one. Keeping up with both ECMAScript + Babel is a lot of work. I would even argue that staying up to date with Babel is more work because dependencies keep changing underneath your project.

- It forces you to use a build step so you lose the benefits/iteration speed that an interpreted language brings to your development flow.

- Adds a lot of bloat and unnecessary, hard-to-describe dependencies to your project which can open up security vulnerabilities and make your code more opaque and brittle.

Re: Software Disenchantment (2018)

#443

Post by Izkata »

> A 16GB Android phone was perfectly fine 3 years ago. Today, with Android 8.1, it’s barely usable because each app has become at least twice as big for no apparent reason. There are no additional features. They are not faster or more optimized. They don’t look different. They just…grow?

I jumped straight from Android 2 to Android 8 development and was surprised myself, so did some investigation and have half an answer. The author is actually wrong here, on both looking different and additional functionality. However, the bloat is still far larger than it needs to be.

All the bloat comes from the AppCompat modules, which all the docs recommend to the point of it apparently being required if you don't know better.

AppCompat is for both supporting differing APIs and creating a consistent look and feel across different Android versions. Each Android version has its own visual design, which Google decided was a bad thing, opting to use AppCompat so the most recent designs (and in some regards design functionality like coloring the selection handles) were used in older versions of Android.

To do this however, it includes a crap-ton of images. The build scripts are supposed to remove the unused ones, but even with maximum trimming enabled it can only remove somewhere around 10%. There are hardcoded inclusion rules for some of the AppCompat java code, that no one's found a way to override, which in turn reference the images - so they get kept a well, even if your app never uses them.

As for differing APIs, notifications have changed massively over the years. The interface is so different you do actually need the AppCompat subset for notifications to target different Android versions (and that can be used separately from the rest of AppCompat), but there also have been a huge number of new features added to notifications - such as delay settings, shortcuts, icons, even full-on fancy designs, that didn't exist early on.

I'm calling this only half an answer because there's no apparent reason for some of the notification API changes, and the build scripts/AppCompat can certainly be significantly improved to remove more cruft. I have a sneaking suspicion that it's not done because this is low-hanging fruit for handing over signing keys to Google for their "optimized" builds...

Re: Software Disenchantment (2018)

#444

Post by gonational »

ratww wrote: post #266
gonational wrote: post #236

Earlier quoted context omitted.

That’s funny; I’m always debating my brother, talking about how earbuds sound much better than even high-end monitors, largely because of the surrounding environment (or lack thereof, when earbuds are in). When I make music I have to do the opposite; take my earbuds out and listen to the music over my car stereo or via my MacBook Pro speakers, to make sure it doesn’t sound good only through earbuds.

Hah, I have nice studio monitors since forever, but I also make music with Earbuds. I like them, but I've found that they make a bit too conscious about the sound, so I have to be extra careful. The isolation emphasizes noise and frequencies that the monitors don't, and that will be masked in the full mix. It used to lead me to a rabbit hole of noise-gating and EQs.

Interesting; I could totally see myself going down the same rabbit hole, or the opposite, thinking that a certain faint sound will be great, but when I play it in my car later it's completely unnoticeable.

Re: Software Disenchantment (2018)

#445

Post by thatfrenchguy »

ljm wrote: post #30
rogerdb wrote: post #20

> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "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. If bas…

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).

Re: Software Disenchantment (2018)

#446

Post by skohan »

yibg wrote: post #349
iamwil wrote: 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…

The stuff I write I don't think is that bloated, but like most things these days the stuff I write pulls in a bunch of dependencies which in turn pulls in their own dependencies. The result, pretty bloated software. Writing performant, clean, pure software is super appealing as a developer, so why don't I do something about the bloated software I write? I think a big part of it is it's hard to see the direct benefit…

I think part of it is knowing how to use libraries. It's actually a good thing to make use of well-tested implementations a lot of time rather than re-inventing the wheel: for instance it would be crazy to implement your own cryptography functions, or your own networking stack in most cases. Libraries are good when they can encapsulate a very well-defined set of functionality behind a well-defined interface. Even better if that interface is arrived at through a standards process.

To me, where libraries get a bit more questionable is when they exist in the realm of pure abstraction, or when they try to own the flow of control or provide the structure around which your program should hang. For instance, with something like Ruby on Rails, it sometimes feels like you are trying to undo what the framework has assumed you need so that you can get the functionality you want. A good library should be something you build on top of, not something you carve your implementation out of.

Re: Software Disenchantment (2018)

#447

Post by skohan »

debt wrote: post #338
d23 wrote: post #276

Performance is one thing, but I'm really just struck by how often I run into things that are completely broken or barely working for extended periods of time. As I write this, I've been trying to get my Amazon seller account reactivated for more than a year, because their reactivation process is just... broken. Clicking any of the buttons, including the ones to contact customer support just take you back to the same…

"...how often I run into things that are completely broken..." That's because the shotgun approach(sick 40 developers on a single problem idc how they dole out the workload) works well for most low stakes, non-safety-critical software. So like a reactivation portal for your Amazon seller account is very low stakes. But Boeing treating the 737-MAX the same way, would be(and was) a very bad idea. Because that low-stake…

I think it's also a problem with the culture of a lot of software practices. There's a tendency to naval-gaze around topics like TDD and code review to make sure you're doing Software Development(tm) effectively, without a lot of attention to the actual product or user experience. In other words, code quality over product quality.

Re: Software Disenchantment (2018)

#448

Post by theandrewbailey »

nearbuy wrote: post #378
jancsika wrote: post #11

> How is that ok? Probably because a browser like FF has the goal to load and display arbitrary dynamic content in realtime like a reddit infinite scroll with various 4k videos and ad bullshit, whereas the game has the goal to render a known, tested number of pre-downloaded assets in realtime. Also on shitty pages the goal is different-- load a bunch of arbitrary adware programs and content that the user doesn't want…

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.

Re: Software Disenchantment (2018)

#449

Post by swah »

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…

Can you expand? You actually convinced other folks to stop using React and go back to writing DOM-manipulating VanillaJS?

Re: Software Disenchantment (2018)

#450

Post by tjpnz »

ryanbrunner wrote: post #440
ratww wrote: 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.

In a previous life I did back office development for ecommerce. We had two applications, one RoR monolith and a "modern" JavaScript Meteor SPA. The SPA was actually developed to replace the equivalent functionality in the RoR application but we ended up killing it and sticking with what we had. Depending on what you're trying to accomplish server side rendering is just as good, if not better than the latest and greatest in client side rendering.
Post reply on HN