3 ms·

I completely disagree with you. I don't know whether the "square of the number of feature" claim is true, but we have certainly made our system huge for no rea

I completely disagree with you. I don't know whether the "square of the number of feature" claim is true, but we have certainly made our system huge for no reason—besides perhaps making it more convenient for programmers. I go to http://artelabonline.com/home/ http://artelabonline.com/home/ every once in a while—which will crash if many people click on this because there are only 128MB of RAM—which I built in 2009. With the worse PHP one can think of, no CDN, etc., it's lightning fast. Websites nowadays are over 10MB, and most of that crap are JavaScript libraries and frameworks. Most apps I use daily are Electron apps, which contain a whole copy of a browser even though I already have one installed, and routinely take up 700MB of RAM to show me an app that is actually a web page. I believe that the problem is that programmers are doing things for themselves, and not users—which is eventually who will use the product. Electron is a great example. That, mixed with this idea that a little control panel for a client who has to check 10-20 orders for his store should be built with the same framework used by the most visited website in the world.

alkonaut 9y ago
> completely disagree with you. Well I was being perhaps a bit deliberately controversial > for no reason—besides perhaps making it more convenient for programmers That's a massive and excellent reason to make a system consume more resources. In fact I think it's probably the main reason programs do! If new feature X can be done in 1 man-week and consume Y resources, it's entirely possible that it can be done in such a way that it consumes just 1/4 of those resources. That might take 10 man-weeks (and/or much better devs). So you don't, because users generally aren't willing to pay for that. Basically only a few very niche products do this (game engines, embedded, ...). Basically, the economics of adding feature X was such that if it can't use a huge amount of resources, the buyer can't afford it. So it uses a lot of resources, becaue the buyer wanted the feature. > I believe that the problem is that programmers are doing things for themselves, and not users—which is eventually who will use the product. Electron is a great example. This is partyly true. Electron (and similar) is an excellent example of the economics above. I also can't believe how someone can write a chat client that uses 1Gb of ram in any universe. But the economics were such that JS developers, unfortunately were easy to come by, and a browser engine with DOM (of all things) was the best way to get a cross platform UI running with these developers. So the arrival of Slack was really just like any other feature. Someone wanted a cross platform shiny group chat application, and they wanted it now and not in 10 years, and they wanted it to cost reasonably little. The answer to that, unfortunately, was "ok but it'll cost you two cpu cores and a gig of ram". Was it just for the developers? well, partly. But indirectly it's for the users who weren't going to PAY for C++ devs to write slick and lean native versions of this software Bottom line: every user has a limited amount of money and a limited amount of computer resources. When given a choice, my experience is that users are much more willing to pay with more resources and less money, than vice versa. The important thing to remember is that the two are connected - a program that takes less resources is more expensive.
- jaclaz 9y ago
  Don't forget what I call "technological supremacy" bias: https://news.ycombinator.com/item?id=14902333 https://news.ycombinator.com/item?id=14902333
  - alkonaut 9y ago
    Of course, and having system requirements is obviously a good thing. While it's obviously a fact that devs have more powerful machines than their users, I'd argue that the tolerance for performance is MUCH lower among devs. When my IDE does a GC pause for 5 seconds I go insane. Yet I have users that use the software I write, and somehow insist on using enormous datasets in it (much more than we would have imagined) meaning completely ridiculous delays (minutes if not more). When I ask if it doesn't drive them crazy, they say "no, because in the past thus job took a week with pen and pencil" or "the old program didn't have this feature at all, so of course a minute wait is OK in the new program!". A developer would never say that about the new shiny feature in their IDE or similar "yeah I like the new go-to-symbol even though it takes 15 seconds..." (and it might SAVE us time still, compared to doing it the old way). But we'd complain like crazy. So our technological supremacy bites us some times too.

alkonaut 9y ago

> completely disagree with you. Well I was being perhaps a bit deliberately controversial > for no reason—besides perhaps making it more convenient for programmers That's a massive and excellent reason to make a system consume more resources. In fact I think it's probably the main reason programs do! If new feature X can be done in 1 man-week and consume Y resources, it's entirely possible that it can be done in such a way that it consumes just 1/4 of those resources. That might take 10 man-weeks (and/or much better devs). So you don't, because users generally aren't willing to pay for that. Basically only a few very niche products do this (game engines, embedded, ...). Basically, the economics of adding feature X was such that if it can't use a huge amount of resources, the buyer can't afford it. So it uses a lot of resources, becaue the buyer wanted the feature. > I believe that the problem is that programmers are doing things for themselves, and not users—which is eventually who will use the product. Electron is a great example. This is partyly true. Electron (and similar) is an excellent example of the economics above. I also can't believe how someone can write a chat client that uses 1Gb of ram in any universe. But the economics were such that JS developers, unfortunately were easy to come by, and a browser engine with DOM (of all things) was the best way to get a cross platform UI running with these developers. So the arrival of Slack was really just like any other feature. Someone wanted a cross platform shiny group chat application, and they wanted it now and not in 10 years, and they wanted it to cost reasonably little. The answer to that, unfortunately, was "ok but it'll cost you two cpu cores and a gig of ram". Was it just for the developers? well, partly. But indirectly it's for the users who weren't going to PAY for C++ devs to write slick and lean native versions of this software Bottom line: every user has a limited amount of money and a limited amount of computer resources. When given a choice, my experience is that users are much more willing to pay with more resources and less money, than vice versa. The important thing to remember is that the two are connected - a program that takes less resources is more expensive.

jaclaz 9y ago
Don't forget what I call "technological supremacy" bias: https://news.ycombinator.com/item?id=14902333 https://news.ycombinator.com/item?id=14902333
- alkonaut 9y ago
  Of course, and having system requirements is obviously a good thing. While it's obviously a fact that devs have more powerful machines than their users, I'd argue that the tolerance for performance is MUCH lower among devs. When my IDE does a GC pause for 5 seconds I go insane. Yet I have users that use the software I write, and somehow insist on using enormous datasets in it (much more than we would have imagined) meaning completely ridiculous delays (minutes if not more). When I ask if it doesn't drive them crazy, they say "no, because in the past thus job took a week with pen and pencil" or "the old program didn't have this feature at all, so of course a minute wait is OK in the new program!". A developer would never say that about the new shiny feature in their IDE or similar "yeah I like the new go-to-symbol even though it takes 15 seconds..." (and it might SAVE us time still, compared to doing it the old way). But we'd complain like crazy. So our technological supremacy bites us some times too.