Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

101–110 of 504 posts

Re: Software Disenchantment (2018)

#101
post #59
post #35

One thing nobody seems to mention is the environmental cost of inefficient software. All those wasted CPU cycles consume electricity. A single laptop or phone on it's own is insignificant, but there are billions of them. Combine that with the energy wasted shovelling unnecessary crap around the internet, and it adds up to a big CO2 problem that nobody talks about.

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

Re: Software Disenchantment (2018)

#102
post #47
post #35

One thing nobody seems to mention is the environmental cost of inefficient software. All those wasted CPU cycles consume electricity. A single laptop or phone on it's own is insignificant, but there are billions of them. Combine that with the energy wasted shovelling unnecessary crap around the internet, and it adds up to a big CO2 problem that nobody talks about.

I hear that argument very frequently and I don’t buy it. Think about all the gas that is saved because people don’t have to drive to the library, all the plane trips saved by video conferencing, all the photo film, all the sheets of paper in file cabinets, all the letters being sent as emails, all the mail order catalogues, ... you get the idea. Does anybody know of a comprehensive study on this?

> Think about all the gas that is saved because people don’t have to drive to the library....

You're right that computers have saved huge amounts of energy compared with the things you mention. My point here was that even more could be saved with a bit of thought about efficiency in programming.

Re: Software Disenchantment (2018)

#103
post #75
post #50

I agree with this. I think we need a guild. We need licensed software engineers. Not every programmer needs to be one, just like not every engineer needs to be licensed, but there needs to be a licensed engineer on every team. And, of course, sometimes there doesn't need to be. But I sure wish there was the option. And hell, bring back apprenticeships and mentoring with the guild. There is so much we could learn from…

While the apprenticeship model is a good one and can work in software, I would be wary of such an effort considering how rapidly software evolves. Guilds work well for technologies that are fairly stable and require years of practice and study to get right (metal working, carpentry, plumbing, surgery etc.), while with software you could specialize in languages and frameworks that become obsolete in the order of decad…

While software engineering is growing and evolving, there's also a lot of cyclical fads that we should look past. Sure, there is the framework du jour, but the fundamentals of computer science and software engineering grow far slower.

Mastery of frameworks is NOT mastery of our craft. They are useful tools that can come and go. But the underlying principles are what should concern is.

To that point, none of your examples of stable disciplines are static. New surgical tools, techniques, and technology are constantly produced and surgeons must learn to lay down their old ones and adapt. Metalworking, carpentry, plumbing all need to learn about new materials developed and code changes.

All of those things are like frameworks.

Re: Software Disenchantment (2018)

#104

A related article in a similar spirit from 4 years ago: https://news.ycombinator.com/item?id=8679471 I can comfortably play games, watch 4K videos, but not scroll web pages? I think this is one of the more important points that the article tries to get across, although it's implicit: while the peak of what's possible with computing has improved, the average hasn't --- and may have gotten worse. This is the point that…

I agree that the peak is pulling away from the average, and most of us want the average performance of applications to lift. We have to throw aside facile "Good Enoughism" and genuinely respect the time of our users.

Where I differ a bit from your take: Languages and platforms that target high performance are providing application developers an elevated performance ceiling that allows them the luxury to use CPU capacity as they see fit. Application developers using high-performance platforms may then elect to make their application high-performance as well, yielding a truly high-performance final product, or they may elect to be spendthrifts with CPU time, yielding something middling on performance. And yes, a truly wasteful developer can indeed make even a high-performance platform yield something low-performance.

What benchmarks and the resulting friendly competitiveness help us avoid is a different and worse scenario. When we select a language or platform with a very low performance ceiling, application developers continuously struggle for performance wins. The high water mark for performance starts out low, as illustrated by how much time is spent in order to accomplish trivial tasks (e.g., displaying "hello world"). Then further CPU capacity is lost as we add functionality, as more cycles are wasted with each additional call to the framework's or platform's libraries. When we select a low-performance platform, we have eliminated even the possibility of yielding a high-performance final product. And that, in my opinion, illustrates the underlying problem: not considering performance at key junctures in your product's definition, such as when selecting platform and framework, has an unshakeable performance impact on your application, thereby pulling the average downward, keeping those peaks as exceptions rather than the rule.

Re: Software Disenchantment (2018)

#105
post #48
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…

> These days, I think most users will lose more time and be more frustrated by poor UI design, accidental inputs, etc. than any performance characteristics of the software they use. I’m willing to bet that a significant percentage of my accidental inputs are due to UI latency.

Don’t get me started with all the impressive rotating zooming in Google Maps every time you accidentally brush the screen.

The usage story requires you to switch to turn-by-turn, and there’s no way to have bird eye map following your location along route (unless you just choose some zoom level and manually recenter every so often.)

It’s awful, distracting and frankly a waste of time... just to show a bit of animation every time I accidentally fail to register a drag...

Damn Ui

Re: Software Disenchantment (2018)

#106
post #76

IMO the article is painting a really negative picture about the state of technology. Any profession with large enough practitioners will create tons of crappy stuff; with most professions that crap is just not discoverable. e.g. if you're a crappy carpenter, only your city or neighborhood can see your shitty work. But if you make a crappy website or app, anyone in the world can see and use it.

He talks about major companies though

Re: Software Disenchantment (2018)

#107
Energy (or more accurately power) is a scarce resource. If it's not being spent to keep the organization or individual going, then it could be argued that the energy is wasted. As it requires functioning organizations to acquire more energy and so on.

All systems - biological, physical, meta-physical are built on layers that once deep enough are pretty well cemented in. Hindsight is 20/20 and though we know if the foundations were different things would be better - they won't actually change until the energy gain exceeds the energy cost of uprooting everything to make the change.

Just saying this problem isn't exclusive to software, but also laryngeal nerves in giraffes, x86, and Esperanto.

Re: Software Disenchantment (2018)

#108
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…

Google Maps is just horrible on mobile when you aren't on Wifi. I'd like to wireshark it some day to figure out just how many different web requests it is making.

You don't need wireshark - open dev console and observe that any map operation (drag/zoom/draw and anything else) requires an api request to gmaps.

You can contrast that with mapbox which seems to have been designed upfront with offline mode in mind.

Re: Software Disenchantment (2018)

#109
post #78

> And then there’s bloat. Web apps could open up to 10 times faster if you just simply blocked all ads. Google begs everyone to stop shooting themselves in the foot with the AMP initiative—a technology solution to a problem that doesn’t need any technology, just a little bit of common sense. If you remove bloat, the web becomes crazy fast. How smart do you have to be to understand that? If you "simply blocked all ads…

> If you "simply blocked all ads" the people making the pages wouldn't have the income which they maintain the pages with.

One upon a time, adverts were just cross-linked GIF images. No iframes, no Flash, no javascript, no cookies, just images. Easy for rendering engines to show, no need to call script interpreters or to add boatloads of rubbish into the DOM. No real performance hit beyond downloading the image initially.

I would quite happily return to that world.

Re: Software Disenchantment (2018)

#110

What are you up to these days Chris? And the obligatory question, what is your take on the article/why post? I piled standout quotes below. I think a big takeaway from the intersection of Bret Victor, Alan Kay, Jim Hollan and the ink&switch folks and your work is that the right dynamic interface can be the "place we live in" on the computer. Victor shows a history of interactive direct manipulation interfaces, live e…

I'm working on tools/interfaces at Relational AI, which is doing really cool work in the declarative languages space. It was started by several of the folks whose papers were foundational to Eve. :)

I agree with the post, though as others have pointed out, it doesn't really dive into the fact that this problem is systemic and would require a shift in incentive structure.

I think the last quote you have is one of the most important missing pieces for making a meaningful change in this space. A lot of people want something better, but right now, as a community, I don't think we really know what that is. What is the complete story for an ideal version of software development? And by that I don't mean idealized examples, I mean the ideal version of the real process we have to go through. What does perfect look like in the world of changing requirements, shifting teams, legacy systems, crappy APIs, and insufficient budgets? If we could show that - not the simple examples we had for Eve, but something that addresses the raw reality of engineering - I think it would just be a matter of beating the drum.

Post reply on HN