Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

91–100 of 504 posts

Re: Software Disenchantment (2018)

#91

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

>whereas the game has the goal to render a known, tested number of pre-downloaded assets in realtime.

Say hello to shaders.

Re: Software Disenchantment (2018)

#92

> Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. ... Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. > I can comfortably play games, watch 4K videos, but not scroll web pages? How is that ok? IMO the comparison should be buildings fine-tuned libraries (i.e. video decoding algorithms), modern applications citi…

>Go to any city center in Europe. Urban planning a century ago was much more elegant and elaborate taking into consideration the city as a whole.

Eh, no. Just a castle/wall, shops around in the main St's, a market in the middle, and expanding chaotically from that.

Re: Software Disenchantment (2018)

#93
When I was in school and first leaning about programming I assumed that code written in C or Java would eventually be ported to hand tuned assembler once enough people were using it. Then I got in to the industry and realized that we just keep adding layer after layer until we end up at the point this article talks about.

I remember once reading that IBM was going to implement an XML parser in assembler and people were like "Why? If speed is needed then you shouldn't use XML anyway." I thought that concern was invalid because these days XML ( or JSON ) is really non-negotiable in many scenarios.

One idea that I've been thinking about lately is some kind of neural network enabled compiler and/or optimizer. I have heard that in the javascript world they have something called the "tree shaking" algorithm where they run the test suite, remove dependencies that don't seem to be necessary and repeat until they are getting test failures. I'm thinking why not train a LSTM to take in http requests and generate the http response? Of course sometime the request would lead to some sql, which you could then execute and feed the results back into the LSTM until it output a http response. Then try using a smaller network until something like your registration flow, or a simple content management system was just a bunch of floating point numbers in some matrices saved off to disk.

Re: Software Disenchantment (2018)

#94

I agree with the overal sentiment, yet the examples could be better. > Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and…

>Text is very complicated. Does your 42-year-old Emacs support Unicode? And not just accents, but whole different scripts?

Emacs had MULE in late 90's. It was THE best Unicode editor because it supported lot of encodings. You could switch from iso8859 to UTF8 on the fly.

Re: Software Disenchantment (2018)

#95
post #67

Earlier quoted context omitted.

It's possible to both improve efficiency and maintain backwards compatibility.

Combining these two is only a non-issue with unlimited resources. Otherwise it's a tradeoff if you add constraints like cost, effort, time to market, and so on...

Windows does it. And despite that, versions like win 7 were pretty fast

Re: Software Disenchantment (2018)

#96
post #80
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…

What if the site has multiple revenue avenues, of which ads are just a part? What if the site's actually a part of the OS that I've already paid for, but which inexplicably has to be connected to the Internet and serving me ads for Candy Crush?

>What if the site has multiple revenue avenues, of which ads are just a part?

Well, in most cases this is not the case. Subscriptions don't work but for outlets with passionate niche audiences, or for upper income targeted "high class" outlets. Which leaves most of mainstream media outlets outside. Besides those outlets where ads are peripheral to the main income streams (niche fan supported, paywalled) usually have less ads to begin with.

>What if the site's actually a part of the OS that I've already paid for, but which inexplicably has to be connected to the Internet and serving me ads for Candy Crush?

Well, then it doesn't really need ads.

Re: Software Disenchantment (2018)

#97
post #90
post #72

> Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load/unload…

>Well, where's your word processor buddy? Try to write one to achieve those goals -- and offer what people want today, including syntax highlighting, linting, auto-completions, etc, and come back to us... Emacs could do that since 25 years ago, if not more.

Emacs never could, and still can't draw while processing input, and even needs occasional manual refresh. A badly written code (plugin, etc), a loaded loop, etc, can freeze emacs. So there's that...

And, Lisps aside, the kind of linting, auto-completion, understanding of syntax/AST, etc emacs could do 25 years ago is much easier compared to what devs expect today.

Re: Software Disenchantment (2018)

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

I might strengthen your argument even more and say it's largely a non-technical problem. We have had the tools necessary to build good software for a long time. As others have pointed out, I think a lot of this comes down to incentives and the fact that no one has demonstrated the tradeoff in a compelling way so far.

I find it really interesting that no one in the future of programming/coding community has been able to really articulate or demonstrate what an "ideal" version of software engineering would be like. What would the perfect project look like both socially and technically? What would I gain and what would I give up to have that? Can you demonstrate it beyond the handpicked examples you'll start with? We definitely didn't get there.

It's much harder to create a clear narrative around the social aspects of engineering, but it's not impossible - we weren't talking about agile 20 years ago. The question is can we come up with a complete system that resonates enough with people to actually push behavior change through? Solving that is very different than building the next great language or framework. It requires starting a movement and capturing a belief that the community has in some actionable form.

I've been thinking a lot about all of this since we closed down Eve. I've also been working on a few things. :)

Re: Software Disenchantment (2018)

#99
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 agree but apparently the number is not very big - computing is max 8% perhaps of electricity usage. But it still feels so wasteful, and also wasteful of people’s time.

Re: Software Disenchantment (2018)

#100
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.
Post reply on HN