Live data from Hacker News

Software Disenchantment (2018)

tonsky.me

151–160 of 504 posts

Re: Software Disenchantment (2018)

#151

Earlier quoted context omitted.

I'm suggesting that you take an existing system and build up a corpus of request/response pairs. Then you use the LSTM to build a prediction model so that given a request it will tell you that the current production system will produce the following sql statement and this http response. Once the LSTM's output is indistinguishable from your current production system , for all use cases, then you replace the production…

What if your app has literally any mutable state? Registering accounts, posting comments, etc. Also I'll bet you that your neural net is > 100x slower than straight line code.

Mutable state in the sense of database writes would be part of the network's output and just passed on to a regular db. Mutable state in the sense of variables that the application code uses while processing a request? Well LSTM networks can track state like that.

For session based variables? Not sure, either it all becomes stateless and the code has to read everything from storage for each reqeuest .... or maybe the lstm is able to model something like an entire user session and remember the stuff that the original app would have put in the session.

That Andrej Karpathy article that I linked to two comments above ... he pointed out, in a different blog post, that regular neural networks can approximate any pure function. Recurrent neural networks like the LSTM can approximate any computer program. It is because they can propagate state from step to step that allows them to do this.

As far as it being 100X slower, well at a certain point I will be willing to take your money :)

Re: Software Disenchantment (2018)

#152
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.

That's how we get deliberately slow pages, articles split over multiple page loads, image slideshows and deliberately slow pages (because time spent on your site is time not spent on the competing websites).

On the other hand we have pages like HN, paid for(?) using other means and built to be perfectly usable and fast. Or some CSEs where revenue comes from affiliates and CPC fees instead of ads, so they try to keep things fast too. Then we have news sites with paywalls and hopefully some day better engineered UI to read those news.

People should just vote with their pockets for a better user experience, IMO.

Re: Software Disenchantment (2018)

#153
post #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…

This is very much a social and political problem. Will be interesting to see if us technical folks can solve it.

Re: Software Disenchantment (2018)

#154
post #30
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…

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

I never liked this view. 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.

> they probably blame their 4G signal for it

Sad thing is, enough companies thinking like this and the incentive to improve on 4G itself evaporates, because "almost nothing can work fast enough to make use of these optimizations anyway".

Re: Software Disenchantment (2018)

#155
As a dinosaur who has been programming for >30 years, it shocks me how bloated many modern programs are. The installers for my own products are around 20MB and most of that is Qt libraries. But 100s of MB seems to be standard now. The Airbnb app on my iPhone is 210 MB. I understand that if you are shipping a 3d game with maps, textures, sound etc, but not for a mobile phone app.

Re: Software Disenchantment (2018)

#156
post #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…

I'll take this opportunity to appreciate C# in VS as a counterexample to the article. Fast as hell (sub-second compile times for a moderately large project on my 2011 vintage 2500k), extremely stable, productive, and aesthetically pleasing. So, thanks.

Re: Software Disenchantment (2018)

#158
post #62

> You’ve probably heard this mantra: “Programmer time is more expensive than computer time.” What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time. The argument is incomplete. The correct question (to maintain the analogy) is: "Would you buy a car if it eats 1000 li…

But in your example, your only describing one specific task (n=1). The issue is that time accumulates non linearly as the number of tasks increase. i.e the petrol stations must be able to supply enough petrol to all customers that drive the most inefficient car.

The culture of "developer time is most important", makes overall system performance someone else's problem, because "my program is fast enough when I measure it off the wall clock". But who's responsible to fix overall system performance, and how can they fix it? I think a lot of people would just upgrade their RAM, CPU or IO to solve the issue (create more petrol stations), rather than asking vendors to change the programming language, or to be more conservative on RAM.

And because there's costs to switching language stacks, people will stick to writing in the language they are comfortable in, so critical business systems get written in slow languages.

Re: Software Disenchantment (2018)

#159
The analogy to cars misses where they are in their life cycle. When cars were evolving at a faster pace, and gas was relatively cheaper, they did get something like 5-10% efficiency, particularly when you correct for the level of emissions produced.

Gas car technology matured, gas got more expensive, and cars got more efficient. Moore's Law isn't going to go on forever. We are hitting limits in battery life. Software will tend to get more efficient over time.

Re: Software Disenchantment (2018)

#160

It's not just the problem with large and slow today. There are also these dark patterns everywhere special in Android. Even local thing do not work, if there is a network connection, but connections for ex. to Google are not allowed. For ex. the standard Android "Photos" App does not always show you the newest pictures, if the network blocks Google. Also you can't share something to another App if you have a network…

This. I know that today we get so many software for free, but I see so many good opportunities spoiled by the fact that someone from marketing told the developer to hamper interoperability or usability to push some other product or feature that when you don't have it, it's so refreshing. Remembering my browser of choice. Ability to save some place in google maps without letting it have all my location, always, local only functions, accept : always/not now, click here for extra features, ... we could save so many bytes or cpu cycles or UI missteps...
Post reply on HN