People won't pay for efficiency. People buy solutions to their problems (features), not efficiency.
If it needs to be efficient, it will be (the games example).
The death of Moore's Law may rejuvenate efficient software.
BTW If you use old unix tools on a phone, it's super fast (in a terminal emulator like http://termux.com).
Sadly, the idea of abstractions enabling you to think better (like Alan Kay's point of view is worth 80 IQ points and maybe Jobs' bicycle for the mind) doesn't seem to work, at least for software abstractions. It's far more work than can be justified - more appropriate for pure research (which is instead preoccupied things like esoteric type systems with nice mathematical properties).
Just a few months ago, a very senior engineer on my team made this same observation about Moore's Law after I lamented that bit twiddling tricks and knowledge of obscure algorithmic speedups don't often end up being useful in practice.
The only sane reason that AirBnb or Uber are worth as much is that they promise to be more efficient than traditional companies. SO the 'market' pays for efficiently and a lot of digital revolution has been all about making existing processes slightly more efficient (Amazon online shopping experience vs physically going to the different shops etc)
So the market definitely value the efficiency where the cost of developing that efficiency does not outweigh the benefits.
Typing speed and cursor refresh are not limiting factors for programmers so there's diminishing return in making text editors refresh >120hz. Simple business logic and OP can lament as much as he wants to but we have limited resources, mostly time and that time is usually better spent writing business logic than optimising text editor for the 100th time.
I agree with the author.
Often I find it refreshing to step away from the absurdity of software development and go work on my car.
Working on your car exposes you to the fruits of a bona fide engineering process: objects that are carefully designed, work reliably, and are made with serviceability in mind.
They aren't just slapped together and thrown out the door like (100-epsilon)% of software out there.
I would prefer not to touch the turbines attached to downsized 1L 120HP engine, software update only at authorized shops cost north of 150 EUR, the entertainment system had access to youtube initially but was cut off after 12 months, the LED system of headlights was likely someone’s PhD dissertation. Car industry is the eqivalent of web front-end in the software world, except one is unable to just shut down the browser.
I agree with your sentiment, the car industry in its current state is getting pretty ugly.
I choose to avoid these trends entirely, and I'm happy to keep driving my 2.4L naturally aspirated, 5 speed manual, touchscreen-less shitbox until it dies.
Parts are still cheap and it's easy to work on.
> Recently our industry’s lack of care for efficiency, simplicity, and excellence started really getting to me, to the point of me getting depressed by my own career and the IT in general.
Loading this website resulted in 5.3MB being downloaded over 42 requests.
I have only 2.8MB on my computer with the adblocker (the website has Google Analytics and a Twitter widget), mostly images. Fonts/Text/CSS: 120KB. And the website works perfectly without Javascript.
I have a theory that we're not caring as much about performance and good software because we don't have to, because Moore's Law has led to machines that are fast enough to run our crappy and hastily written code with acceptable performance so the majority of users do not really care about it running more efficient.
In the past, when computing resources were constrained we had to care about performance just so we could release software that worked good enough so people actually wanted to use it.
How do we get people to care about performance and efficiency in software? I don't know.
> I have a theory that we're not caring as much about performance and good software because we don't have to, because Moore's Law has led to machines that are fast enough to run our crappy and hastily written code with acceptable performance so the majority of users do not really care about it running more efficient.
Depends what you define as "acceptable" and as "users caring". The bloat does have actual consequences, like slow websites and greatly inflated bandwidth costs (which has direct consequences for users on metered connections).
I've heard complaints from completely non-technical friends how frustrating it is to work with slow, unstable software. But of course they can't identify more detailed causes because they don't know the technical details (or are interested in them).
Likewise, they can't stop using the software because they need it to do their job. So I think there is not much else they could do to indicate they "really cared".
I spend a significant portion of my work-week defending my employment - inputting time cards, updating JIRA tickets with "time spent", attending status meetings... all in the name of "efficiency". And on some level, I understand - nobody wants a Dilbert-esque Wally type wasting space. Yet the corporate attempts at maximum efficiency fail more horrifically than you would be able to imagine anything failing. Not only does the time spent proving that you weren't wasting time waste time itself, it's also so trivially gameable that the people who thrive are the ones who are MOST effective at being silently inefficient.
> I have a theory that we're not caring as much about performance and good software because we don't have to, because Moore's Law has led to machines that are fast enough to run our crappy and hastily written code with acceptable performance so the majority of users do not really care about it running more efficient.
I've always said that the lack of performance concerns is not a technology problem, this is a business and a societal problem. Hell, this might just be the first massively-distributed "tragedy of the commons" problem.
tl;dr- companies don't have to directly pay for client-side computing resources, so those companies which offload costs onto the client most efficiently have a competitive advantage. (Also, I kinda veered into talking about mobile computing later on here, and diverged into UX a little bit as well, but IMO performance is absolutely a part of the user experience so it's worth considering the two together.)
If I'm developing a piece of software that's not going to run on software I'm personally paying for, the only degree to which I have to optimize for performance is the point at which performance problems completely outweigh the usefulness of the app's features. You can get away with this for a long time with few repercussions- even longer if you can lock them into the software via "dark features".
The problem is, this leaves little space for companies who want to make highly-performant software, because it's still much easier to sell users on what a product does rather than how it does it... so you often can't afford to optimize for performance, because your competitor is going to gobble up user resources and wow them with shiny new features while you're still "boring" them with the "same-old, same-old". (This isn't how I personally feel, but you see my point.)
In a strange way, it's similar to the problem of designing great UX- the more your user has to use your software, the less you have to worry about making it convenient to use your software. You have successfully externalized the cost of dealing with it to your users.
Web applications themselves are a good example of this- companies with any sort of load absolutely do have to pay a non-trivial cost for each byte coming out of a datacenter or stored in an edge cache. The client's local cache is really the only "free" part of the whole process, so if you can get the client to store your entire app in cache, you can save a ton of actual real-world dollars in CPU cycles (not generating so much HTML/CSS/JS) and networking costs (not transferring so much HTML/CSS/JS) and caching costs (not storing so much HTML/CSS/JS in-house). If you're a startup trying to capture a chunk of a market, and you're only concerned about expanding your customer base, you're absolutely going to do that, whether it's ultimately good for customers or not.
I do think however, there are a couple factors which are changing for the better. First, Moore's Law is slowing down, and a lot of hardware optimizations these days seem to be revolving around getting the same performance using less power, rather than more performance for the same amount of power. Same with storage- application software can't continue bloating forever, we're starting to hit physical limitations.
Secondly, consumers are becoming more technology-literate, and with that literacy, are starting to understand the relationship between performance and features.
Thirdly, OS and device manufacturers are starting to experiment with tightly integrating common services into the system. For instance, NFC payments on mobile, or "iMessage-like" services. This is a bit of a double-edged sword, because OS and device manufacturers are also trying to lock you into their services, but they also have to be more serious about pe...
Take websites as an example. We have to build websites using CSS and HTML and JS because that is what works in browsers. But browsers have to build DOMs, layout engines and JS engines this way because that's the way we write code. It's nobody's fault. It's evolution with a bad fitness function.
No, there were some deliberate design decisions. E.g., there was an attempt at a new start: XHTML 2. This got boycotted by browser vendors out of a mix of politics and business priorities.
Instead they went with HTML 5, which generally sees scripting as the core to make non-trivial web applications and also explicitly encourages JS libraries and frameworks.
So I don't think it's surprising that today, pages are piles of scripts on top of scripts.
In a sense AMP is the answer, produce less by having explicit limits while not throwing all tooling out. While AMP is somewhat more technically complex it's much simpler when you consider what it disallows.
However technology/solution is only tool, real problem is in the domain of users, how to make useful systems, how to make users care, technology is irrelevant for most of us.
So in a sense, web browsers are a bit to promiscuous. Website builders would have more incentive to properly engineer their websites if browsers were pickier. One issue with that is that it is the websites visitors who are most likely to see the errors and not the designer of the site.
To capitalize current programmers know how with those expectations of performance would require a radical shift in hardware. It would demand hardware that is optimally designed for multi-paradigm high level languages.
"The Burroughs B5000 was designed from the start to support high level languages (HLLs), specifically ALGOL and COBOL. The initial features supporting this were the hardware-managed stack, the descriptor, and segmentation. A redesign of this system, the B6000, extended the concept by moving the tag bits to their own field, external to the 48-bit data word. The instruction set was also revised and extended, and has remained essentially unchanged ever since. HLLs are supported by hardware that allows virtual memory, multiprocessing, fast context switching and procedure invocation, memory protection, and code sharing."
People are focusing too much on the "performance" aspect of the article.
The "Programming is the same mess" section is what really resonates with me, specifically this:
> And dependencies? People easily add overengineered “full package solutions” to solve the simplest problems without considering their costs. And those dependencies bring other dependencies. You end up with a tree that is something in between of horror story (OMG so big and full of conflicts) and comedy (there’s no reason we include these, yet here they are):
Software hasn't been getting worse -- it always sucked. It used to be fast and small because there was no other option.
Also:
> @jckarter: A DOS program can be made to run unmodified on
> pretty much any computer made since the 80s. A JavaScript
> app might break with tomorrow’s Chrome update
LOL, DOS programs were crazy nonportable. They usually can only be run in VMs these days. Comparing it favorably to the most stable and portable API (the js ecosystem is another story, but the browser APIS are super-stable and never break) in the history of software is hilarious. I mean, all the flaws of DOS programs are totally reasonable given their constraints, but the comparison gets this totally backwards.
I agree that something is out of whack. In-house plane-jane CRUD development used to be pretty simple and quick in the 90's. One could focus on the domain analysis side instead of micromanage tech. The IDE products had glitches, but got better every release, including deployment. The Web bleeped it all to heck and back, and nobody seems interested in promoting the standards to fix it. We toss in JavaScript gizmos to attempt to improve the UI to desktop standards, but these gizmos are clunky and browser-version-sensitive. Maybe the desktop era tools were artistically ugly, but much easier to develop and maintain. PHB's seem more swayed by UI eye-candy than practicality. It's great job security, but hugely wasteful. Our industry needs some deep soul-searching.
I think this is what pisses me off the most. The frontend is a complete clusterfuck, but the serverside is almost as bad. Everything is just half-assed and you end up spending most of your time fighting the tech. The worst thing is people who have drunk the Kool-Aid and just stare you, uncomprehending, when you complain that lunatics are running the asylum and the only way to win is to not play. Or at best agree but have ended up silently accepting the situation as a coping mechanism of some sort, like people in abusive relationships. "It's not that bad, there are good moments too, and besides, I'd have nowhere to go anyway."
I think I'm done with the tech industry. 98% of the sort of programming people actually pay you for is about as pleasant as a root canal. I'm currently on a sick leave and seriously entertaining the idea of changing careers to something entirely different. Like gardening.
> I think I'm done with the tech industry. 98% of the sort of programming people actually pay you for is about as pleasant as a root canal. I'm currently on a sick leave and seriously entertaining the idea of changing careers to something entirely different. Like gardening.
More than a decade of professional software development later, I'm having very similar thoughts.
I now spend 1/4 of my work week fighting dependency hell (after just about each addition of a new package by any other developer on the project), another 1/4 figuring out how the "latest and greatest" tool of the week is best used to do something that would normally take me 5 minutes to do custom (god forbid, not the C-word!), and the remaining half is spent maybe doing actual work. So incredibly frustrating that I've just about had it.
I've grown to loathe and hate that which I used to adore.
Software is hard. I blame it in Moore's law, in the sense that computers have gotten more capable but we programmers have not. Its like the brain can only hold so much before it gets overrun, and we reached that point several years ago. Working with large programs is very difficult, even for the best architected ones. And of course we can't expect all software to be the best software.
The result of these big programs is people blindly using modules created by others, built on top of ever more modules. In theory this is good though. It is specialization. But we haven't done a good job of it. I think if we want to make software easier to write (and as a result better) the place to start is on the process of programming with more specialized pieces, be it a better module system or domain specific features in the programming language. I think it comes down to managing the complexity some a person can better view the big picture.
Well, if you take the analogy of the car, that today is working quite efficient and hassle free, that, I would argue, is in large part due to regulation and bureaucracy. Something that the Internet and computing does not have at the moment.
That word has some negative connotations, but I do not think that is fair, considering the cars, or the airplanes, history. We assume that the car we purchase has seat belts and catalytic converters which will prevent lots of injuries and effects on the climate and living things. These are mandated by laws in many places, and that is a good thing, because we can worry about the entertainment system, service deals, colour and style and still get a car that meets certain "basic" requirements. I say "basic" as they can be quite advanced, we would hardly buy a car without ABS or a crash rating today.
Computer programs and websites do not have to meet any regulations and they therefore easily succumb to bloat, because there is no one being blamed for them being unusable, which is broad, but a website over, say, 1MB is quite large. Plenty are wasting CPU cycles to render and compute, which might not be as polluting as exhaust from a car, but it is polluting and stealing time.
Early cars had to change oil very often or have it refilled, because it leaked in to the combustion chamber or gasses leaked out. This causes emissions to be quite hostile, which is bad because it affects the environment and living beings respiratory systems, among other things. We then got laws regulating this and manufacturers were keen to improve the performance of the engines. Today there are 1,6 liter, four cylinder engines that work well pulling loads and still manage to have a good fuel economy when driven under average conditions.
Another thing is that customers got fed up with steel wheels and rubber tires that blew out all the time and the wheels on our transports improved as well, but that took some years to happen, the Internet and personal computers are still quite young and immature, there is still time for it all to mature quite a bit, and this article is a good step on the way towards that in my opinion.
UX is maybe not as simple to regulate as cars and their emissions and safety standards but I would say that we should not be all to opposed to some more requirements or maybe even laws regarding how we operate computers and programs in some respects and let the market, users that is, dictate what is desired in other areas. We might like to think that the internet is the wild west, so to say, but this has led to some mighty bloat and headaches for all involved, as this article shines a light on.
And much like software, there are many of us who get nostalgic about the days when automobiles just worked, and were knowable, not inscrutable piles of nonsense.
Yeah, about that, it's a bit like when people complain about phones just working previously.
Cars did not used to have AC, be all that stylish and comfortable, they lacked finesse.
Cars today are way more complex with a lot of features and things, which means that they are harder to build, use and maintain, same thing with software and phones.
A website today does more than just show text and images in a certain layout.
It's a trade off between easy to set up, maintain, use and having a lot of nice features.
yeah, wellcome to the club. i am making software for 30 years, and... IMHO, although last 10 years might have been worst, in terms of bloat and inefficiency and dont-cares-ness, it's not just that. That's a result.. It's more like IT industry as such is trying to grow for the sake of growing. At any price. Much like a lot of other industries and/or institutions, trying to exist for the sake of existing.
And they will.. as long as there are users of.. "Each train has its passengers, the saying goes."
> Windows 10 takes 30 minutes to update. What could it possibly be doing for that long?
Backing up the old Windows folder, decompressing (I guess downloadable updates use something very efficient in terms of compression like lzma), and probably some sleep() — I guess the update being slower makes users feel like it's something substantial.
> Android system with no apps takes almost 6 Gb
That "System" figure is the size of all partitions that aren't data. Quite a lot of that is literally wasted space.
Nice try. It's everyone's wish that somebody makes efficient software for them. But when it comes to themselves, they just lump some random components together that seem to do the job and call it a day.
1) some of these complaints are invalid: yes Linux kill a "random" process when there is no more memory available, but except in 'static' configuration where everything has a known size, what's the alternative?
You can have a misbehaving application use lots of memory but it's a normal application whose memory allocation fail, what do you do?
2) this bloat isn't new: I remember being amazed by BeOS responsiveness compared to Windows or Linux but now I spend 80% of my time in a webbrowser and I doubt WebKit is going to be faster on Haiku than it is on other OSs..
1) Don’t promise memory you don’t have. On windows VirtualAlloc will fail if it doesn’t have enough page file space to satisfy the request. This allows the application to do something smarter than with the false promise it gets from mmap.
2) Really depends. Applications spend a lot of time in syscalls.
Yup, pretty sure that "overcommit" should never have been the default option (although it is quite easy to disable, comparatively few people know that it even happens).
1) it doesn't really solve the issue except if you can allocate everything you need at startup: if you need more memory but someone else had a bug which used all the memory you also have a problem..
You may have caches or other optional buffers you can free. Or you may choose to save or do some other action to save user data. It doesn't solve the fact you don't have memory, but it does let you at least do something about it.
I share the sentiment, but I also appreciate the truth.
> Text editors! What can be simpler? On each keystroke, all you have to do is update tiny rectangular region and modern text editors can’t do that in 16ms.
I use text editors with syntax highlighting. Also IDEs with completion, error highlighting, etc. Assuming we are talking about those, updating a rectangular region is not "all you have to do". (Though it is the only thing that has to be done synchronously.)
> Windows 10 takes 30 minutes to update. What could it possibly be doing for that long? That much time is enough to fully format my SSD drive, download a fresh build and install it like 5 times in a row.
You can format an SSD, download a multi-gig image and install it in under 6 minutes?
> The whole webpage/SQL database architecture is built on a premise (hope, even) that nobody will touch your data while you look at the rendered webpage.
What?
> Ever seen this dialogue “which version to keep?” I mean, bar today is so low that your users would be happy to at least have a window like that.
I'm failing to see the problem with that dialog. It's hardly new. Vim:
WARNING: The file has been changed since reading!!!
Do you really want to write to it (y/n)?
> Nobody thinks compiler that works minutes or even hours is a problem.
Everyone thinks that a problem. It's the reason that memory-bloating scripting languages the author is shitting over have become so popular.
> We put virtual machines inside Linux, and then we put Docker inside virtual machines, simply because nobody was able to clean up the mess that most programs, languages and their environment produce.
Huh? When will you put virtual machines inside Linux and then Docker inside those virtual machines. (Maybe a Docker dev testing against different kernel versions?)
> Linux kills random processes by design.
It can kill processes (configurable). But AFAIK it doesn't do it randomly.
> Programs can’t work for years without reboots anymore.
Anymore? Really? I reboot my Windows computer one-tenth as often as twenty years ago.
---
Well, there might be problems, but as least the author is not overgeneralizing, right?
> Nobody understands anything at this point. Neither they want to.
> What’s worse, nobody has time to stop and figure out what happened.
> Nothing stops us from making build process reliable, predictable and 100% reproducible. Just nobody thinks its important.
> We’re stuck in local optima and nobody wants to move out.
> You can format an SSD, download a multi-gig image and install it in under 6 minutes?
5 minutes to download 4 Gb at 100 Mbit/s, 0,5 min to write 4 Gb at 1Gbps
> I'm failing to see the problem with that dialog. It's hardly new.
It’s always been a problem. Trouble is, you want work from both versions combined, not to select one and destroy another
> Everyone thinks that a problem.
Yet new languages (e.g. Rust) are still developed with terribly slow compilers
> It can kill processes (configurable). But AFAIK it doesn't do it randomly.
Well, I meant randomly in a sense that you can hardly predict or control what will happen. Of course it’s a determenistic algorithm, but engineers treat it as a black box.
> Anymore? Really? I reboot my Windows computer one-tenth as often as twenty years ago.
By "install it", I thought you meant install Windows, which takes for longer than 30 seconds. It's not a straight byte copy. For one, part of the install process compiles code for your variation of CPU architecture.
> It’s always been a problem.
In fact, it's less of a problem now than it was 15 years ago. Google Docs, Office 365.
> Yet new languages (e.g. Rust) are still developed with terribly slow compilers
Slow compilers (Rust, TypeScript, Scala, Haskell) almost universally have complex type inference.
Languages with limited type inference (Go, Java) have fast compilers.
It's really a matter of choice of language design, rather than compiler implementation.
> Well, I meant randomly in a sense that you can hardly predict or control what will happen.
This is like complaining search engine results are random because they are complex. Does it really matter?
> By "install it", I thought you meant install Windows, which takes for longer than 30 seconds. It's not a straight byte copy. For one, part of the install process compiles code for your variation of CPU architecture.
That was my point. It does something very slow but unnecessary. If you could install it by straight copy, it would be way faster. And there’re no reasons why it can’t be straight copy (or really fast unzip & compile).
> Google Docs, Office 365
Google Docs disables offline mode by defaults. It only works as long as everyone are almost on the same page. It’s a step forward, yes. I wish using those algorithms was as easy as writing LAMP apps
> Usually my battery dies.
Doesn’t mean it has to reboot. It’s just an implementation design of current OSes. See Phantom OS
To me, the problem is that you are made to choose that one set of changes must be lost. A better design would be (1) save, (2) revert to original, (3) accept other change version instead, or (4) put me into a diff/merge process so I can control which changes (from both sources) are to be posted.
I think I first read this rant in a 1997 article by Dr Peter Cochrane, former Head of Research and Chief Technologist of British Telecom [1]:
"In the past few years I have watched generations of word processors, spreadsheets, and graphics packs transcend the useful and user friendly, to become fiendishly complex - from auto-spelling checks that irritatingly pop on to the screen as you type, to the graphics-by-questionnaire that realise the wrong format in five easy stages.
Application changes of this type beggar belief. Not only do they consume vast amounts of storage, they reconfigure commands, change names and locations, present a vast range of never to be used (or discovered) options that just confuse users. [..]
It can only be that commercial considerations prevent us having a cut down and basic set of applications that are backward, forward and sideways compatible. Writing a letter, book, business case or report does not demand the capabilities of an entire publishing industry." - "How to upgrade your stress" - http://archive.cochrane.org.uk/opinion/archive/telegraph/199...
That was written on a 36Mhz laptop with 20MB RAM and 0.5GB disk space.
Within weeks, he wrote "My recent computer hardware upgrade, and simultaneous software downgrade, has resulted in huge performance improvements. More or less all delays between hand, screen, and eye have been removed. Applications open instantaneously once booted up and files save in a second." - in "Beyond Biology" - http://archive.cochrane.org.uk/opinion/archive/telegraph/199...
And then he goes on to tear apart tonsky's argument about aircraft and cars: "If we could manipulate the space in materials we could perhaps reduce the weight of an aircraft by 90%, suggests Peter Cochrane [..]" - "There's nothing to the Universe" - http://archive.cochrane.org.uk/opinion/archive/telegraph/199...
I think sometimes we, as programmers, are too worried about our own experience coding than about the final product and its quality. And some of that might have been caused by terrible deadlines imposed by PjMs or "Architechts".
This is extremely hyperbolic, and I'm sure you know this. Here's how you set a variable in React:
const foo = 1;
What you're doing in your complicated sample is not _just_ setting a variable, you're also exposing it to a KVO subscription system that you could never represent succinctly in ASM.
What's sad is how programmers communicate programming concepts right now, with quick digs and hot takes and zero actual critical thought to what is being compared. I'm disappointed that you're spreading FUD in your internal talks.
Yes, still its a way to set a value. And don't be so sure you can't make an entry in a KVO subscription system in asm - of course at bottom that's exactly what's happening.
I'm disappointed at the zero-attempt-to-understand-the-point digs made on hacker news (like the one I'm responding to). The point is, how is multi-layered abstraction an unalloyed good? Its heavy, slow, complicated to author and explain, and not doing all that much of value.
Yes, it's an apple to oranges comparison, but the point is more why are we using an orange when an apple will suffice?
The real question is, is all that really needed?
We keep building abstraction layers on top of abstraction layers when often times, there is already tried and proven solution that works and is much simpler.
I've been doing some experimenting creating a single page application (SPA) without a web framework and turns out you can get 90% of what React offers with a tiny amount of code.
I just use plain javascript objects to store data and wrap it in a function that will trigger re-rendering the VDOM / repaint.
And even if we do need that additional layer of abstraction we can always make it appear simpler and provide a cleaner interface to the programmer. A Proxy object setter could be used to eliminate the boilerplate of State.update.
Good abstractions simplify the problem by creating a mental paradigm that is closer to the problem domain. Poor abstractions do the opposite, they take away what is needed to solve the problem and create additional steps that are not really germane to the problem.
Many abstractions are well intentioned, but after we toss layer on top of layer, we often get so far removed from the problem domain, we have to ask ourselves if it is not simpler to just build up another set of abstractions that allow us to get closer to the problem domain (i.e., "First Principles").
97 comments
[ 2.6 ms ] story [ 164 ms ] threadIf it needs to be efficient, it will be (the games example).
The death of Moore's Law may rejuvenate efficient software.
BTW If you use old unix tools on a phone, it's super fast (in a terminal emulator like http://termux.com).
Sadly, the idea of abstractions enabling you to think better (like Alan Kay's point of view is worth 80 IQ points and maybe Jobs' bicycle for the mind) doesn't seem to work, at least for software abstractions. It's far more work than can be justified - more appropriate for pure research (which is instead preoccupied things like esoteric type systems with nice mathematical properties).
Of course it is fast, software designed for a PDP-11 running on a pocket Cray.
Yeeah, no. Definitely a no.
>People won't pay for efficiency. People buy solutions to their problems (features), not efficiency.
Not wrong. Businesses pay for efficiency.
I'm just trying to get from A to B, not fly to Mars.
I choose to avoid these trends entirely, and I'm happy to keep driving my 2.4L naturally aspirated, 5 speed manual, touchscreen-less shitbox until it dies. Parts are still cheap and it's easy to work on.
Loading this website resulted in 5.3MB being downloaded over 42 requests.
The base html is fairly lightweight. ;)
He didn't say he didn't use software; he wishes they were lighter.
I have a theory that we're not caring as much about performance and good software because we don't have to, because Moore's Law has led to machines that are fast enough to run our crappy and hastily written code with acceptable performance so the majority of users do not really care about it running more efficient.
In the past, when computing resources were constrained we had to care about performance just so we could release software that worked good enough so people actually wanted to use it.
How do we get people to care about performance and efficiency in software? I don't know.
Depends what you define as "acceptable" and as "users caring". The bloat does have actual consequences, like slow websites and greatly inflated bandwidth costs (which has direct consequences for users on metered connections).
I've heard complaints from completely non-technical friends how frustrating it is to work with slow, unstable software. But of course they can't identify more detailed causes because they don't know the technical details (or are interested in them).
Likewise, they can't stop using the software because they need it to do their job. So I think there is not much else they could do to indicate they "really cared".
I've always said that the lack of performance concerns is not a technology problem, this is a business and a societal problem. Hell, this might just be the first massively-distributed "tragedy of the commons" problem.
tl;dr- companies don't have to directly pay for client-side computing resources, so those companies which offload costs onto the client most efficiently have a competitive advantage. (Also, I kinda veered into talking about mobile computing later on here, and diverged into UX a little bit as well, but IMO performance is absolutely a part of the user experience so it's worth considering the two together.)
If I'm developing a piece of software that's not going to run on software I'm personally paying for, the only degree to which I have to optimize for performance is the point at which performance problems completely outweigh the usefulness of the app's features. You can get away with this for a long time with few repercussions- even longer if you can lock them into the software via "dark features".
The problem is, this leaves little space for companies who want to make highly-performant software, because it's still much easier to sell users on what a product does rather than how it does it... so you often can't afford to optimize for performance, because your competitor is going to gobble up user resources and wow them with shiny new features while you're still "boring" them with the "same-old, same-old". (This isn't how I personally feel, but you see my point.)
In a strange way, it's similar to the problem of designing great UX- the more your user has to use your software, the less you have to worry about making it convenient to use your software. You have successfully externalized the cost of dealing with it to your users.
Web applications themselves are a good example of this- companies with any sort of load absolutely do have to pay a non-trivial cost for each byte coming out of a datacenter or stored in an edge cache. The client's local cache is really the only "free" part of the whole process, so if you can get the client to store your entire app in cache, you can save a ton of actual real-world dollars in CPU cycles (not generating so much HTML/CSS/JS) and networking costs (not transferring so much HTML/CSS/JS) and caching costs (not storing so much HTML/CSS/JS in-house). If you're a startup trying to capture a chunk of a market, and you're only concerned about expanding your customer base, you're absolutely going to do that, whether it's ultimately good for customers or not.
I do think however, there are a couple factors which are changing for the better. First, Moore's Law is slowing down, and a lot of hardware optimizations these days seem to be revolving around getting the same performance using less power, rather than more performance for the same amount of power. Same with storage- application software can't continue bloating forever, we're starting to hit physical limitations.
Secondly, consumers are becoming more technology-literate, and with that literacy, are starting to understand the relationship between performance and features.
Thirdly, OS and device manufacturers are starting to experiment with tightly integrating common services into the system. For instance, NFC payments on mobile, or "iMessage-like" services. This is a bit of a double-edged sword, because OS and device manufacturers are also trying to lock you into their services, but they also have to be more serious about pe...
Take websites as an example. We have to build websites using CSS and HTML and JS because that is what works in browsers. But browsers have to build DOMs, layout engines and JS engines this way because that's the way we write code. It's nobody's fault. It's evolution with a bad fitness function.
We need a new start. A new paradigm.
Instead they went with HTML 5, which generally sees scripting as the core to make non-trivial web applications and also explicitly encourages JS libraries and frameworks.
So I don't think it's surprising that today, pages are piles of scripts on top of scripts.
However technology/solution is only tool, real problem is in the domain of users, how to make useful systems, how to make users care, technology is irrelevant for most of us.
Ironically, that was what the Burroughs 5000 was: https://www.smecc.org/The%20Architecture%20%20of%20the%20Bur...
"The Burroughs B5000 was designed from the start to support high level languages (HLLs), specifically ALGOL and COBOL. The initial features supporting this were the hardware-managed stack, the descriptor, and segmentation. A redesign of this system, the B6000, extended the concept by moving the tag bits to their own field, external to the 48-bit data word. The instruction set was also revised and extended, and has remained essentially unchanged ever since. HLLs are supported by hardware that allows virtual memory, multiprocessing, fast context switching and procedure invocation, memory protection, and code sharing."
Emulator project: http://retro-b5500.blogspot.com
The "Programming is the same mess" section is what really resonates with me, specifically this:
> And dependencies? People easily add overengineered “full package solutions” to solve the simplest problems without considering their costs. And those dependencies bring other dependencies. You end up with a tree that is something in between of horror story (OMG so big and full of conflicts) and comedy (there’s no reason we include these, yet here they are):
A calf walked home as good calves should...
https://m.poets.org/poetsorg/poem/calf-path
https://en.wikipedia.org/wiki/Path_dependence
Also:
> @jckarter: A DOS program can be made to run unmodified on > pretty much any computer made since the 80s. A JavaScript > app might break with tomorrow’s Chrome update
LOL, DOS programs were crazy nonportable. They usually can only be run in VMs these days. Comparing it favorably to the most stable and portable API (the js ecosystem is another story, but the browser APIS are super-stable and never break) in the history of software is hilarious. I mean, all the flaws of DOS programs are totally reasonable given their constraints, but the comparison gets this totally backwards.
Agreed! doesn't anyone know how to write vanilla JavaScript anymore?
relevant: http://vanilla-js.com/
I think I'm done with the tech industry. 98% of the sort of programming people actually pay you for is about as pleasant as a root canal. I'm currently on a sick leave and seriously entertaining the idea of changing careers to something entirely different. Like gardening.
More than a decade of professional software development later, I'm having very similar thoughts.
I now spend 1/4 of my work week fighting dependency hell (after just about each addition of a new package by any other developer on the project), another 1/4 figuring out how the "latest and greatest" tool of the week is best used to do something that would normally take me 5 minutes to do custom (god forbid, not the C-word!), and the remaining half is spent maybe doing actual work. So incredibly frustrating that I've just about had it.
I've grown to loathe and hate that which I used to adore.
The result of these big programs is people blindly using modules created by others, built on top of ever more modules. In theory this is good though. It is specialization. But we haven't done a good job of it. I think if we want to make software easier to write (and as a result better) the place to start is on the process of programming with more specialized pieces, be it a better module system or domain specific features in the programming language. I think it comes down to managing the complexity some a person can better view the big picture.
To the author: I'm with you. Recently rebuilt my website and blog as an experiment in efficiency.
That word has some negative connotations, but I do not think that is fair, considering the cars, or the airplanes, history. We assume that the car we purchase has seat belts and catalytic converters which will prevent lots of injuries and effects on the climate and living things. These are mandated by laws in many places, and that is a good thing, because we can worry about the entertainment system, service deals, colour and style and still get a car that meets certain "basic" requirements. I say "basic" as they can be quite advanced, we would hardly buy a car without ABS or a crash rating today.
Computer programs and websites do not have to meet any regulations and they therefore easily succumb to bloat, because there is no one being blamed for them being unusable, which is broad, but a website over, say, 1MB is quite large. Plenty are wasting CPU cycles to render and compute, which might not be as polluting as exhaust from a car, but it is polluting and stealing time.
Early cars had to change oil very often or have it refilled, because it leaked in to the combustion chamber or gasses leaked out. This causes emissions to be quite hostile, which is bad because it affects the environment and living beings respiratory systems, among other things. We then got laws regulating this and manufacturers were keen to improve the performance of the engines. Today there are 1,6 liter, four cylinder engines that work well pulling loads and still manage to have a good fuel economy when driven under average conditions.
Another thing is that customers got fed up with steel wheels and rubber tires that blew out all the time and the wheels on our transports improved as well, but that took some years to happen, the Internet and personal computers are still quite young and immature, there is still time for it all to mature quite a bit, and this article is a good step on the way towards that in my opinion.
UX is maybe not as simple to regulate as cars and their emissions and safety standards but I would say that we should not be all to opposed to some more requirements or maybe even laws regarding how we operate computers and programs in some respects and let the market, users that is, dictate what is desired in other areas. We might like to think that the internet is the wild west, so to say, but this has led to some mighty bloat and headaches for all involved, as this article shines a light on.
Cars did not used to have AC, be all that stylish and comfortable, they lacked finesse.
Cars today are way more complex with a lot of features and things, which means that they are harder to build, use and maintain, same thing with software and phones.
A website today does more than just show text and images in a certain layout.
It's a trade off between easy to set up, maintain, use and having a lot of nice features.
You've just described the purpose of literally every life form.
Backing up the old Windows folder, decompressing (I guess downloadable updates use something very efficient in terms of compression like lzma), and probably some sleep() — I guess the update being slower makes users feel like it's something substantial.
> Android system with no apps takes almost 6 Gb
That "System" figure is the size of all partitions that aren't data. Quite a lot of that is literally wasted space.
You can have a misbehaving application use lots of memory but it's a normal application whose memory allocation fail, what do you do?
2) this bloat isn't new: I remember being amazed by BeOS responsiveness compared to Windows or Linux but now I spend 80% of my time in a webbrowser and I doubt WebKit is going to be faster on Haiku than it is on other OSs..
2) Really depends. Applications spend a lot of time in syscalls.
> Text editors! What can be simpler? On each keystroke, all you have to do is update tiny rectangular region and modern text editors can’t do that in 16ms.
I use text editors with syntax highlighting. Also IDEs with completion, error highlighting, etc. Assuming we are talking about those, updating a rectangular region is not "all you have to do". (Though it is the only thing that has to be done synchronously.)
> Windows 10 takes 30 minutes to update. What could it possibly be doing for that long? That much time is enough to fully format my SSD drive, download a fresh build and install it like 5 times in a row.
You can format an SSD, download a multi-gig image and install it in under 6 minutes?
> The whole webpage/SQL database architecture is built on a premise (hope, even) that nobody will touch your data while you look at the rendered webpage.
What?
> Ever seen this dialogue “which version to keep?” I mean, bar today is so low that your users would be happy to at least have a window like that.
I'm failing to see the problem with that dialog. It's hardly new. Vim:
> Nobody thinks compiler that works minutes or even hours is a problem.Everyone thinks that a problem. It's the reason that memory-bloating scripting languages the author is shitting over have become so popular.
> We put virtual machines inside Linux, and then we put Docker inside virtual machines, simply because nobody was able to clean up the mess that most programs, languages and their environment produce.
Huh? When will you put virtual machines inside Linux and then Docker inside those virtual machines. (Maybe a Docker dev testing against different kernel versions?)
> Linux kills random processes by design.
It can kill processes (configurable). But AFAIK it doesn't do it randomly.
> Programs can’t work for years without reboots anymore.
Anymore? Really? I reboot my Windows computer one-tenth as often as twenty years ago.
---
Well, there might be problems, but as least the author is not overgeneralizing, right?
> Nobody understands anything at this point. Neither they want to.
> What’s worse, nobody has time to stop and figure out what happened.
> Nothing stops us from making build process reliable, predictable and 100% reproducible. Just nobody thinks its important.
> We’re stuck in local optima and nobody wants to move out.
5 minutes to download 4 Gb at 100 Mbit/s, 0,5 min to write 4 Gb at 1Gbps
> I'm failing to see the problem with that dialog. It's hardly new.
It’s always been a problem. Trouble is, you want work from both versions combined, not to select one and destroy another
> Everyone thinks that a problem.
Yet new languages (e.g. Rust) are still developed with terribly slow compilers
> It can kill processes (configurable). But AFAIK it doesn't do it randomly.
Well, I meant randomly in a sense that you can hardly predict or control what will happen. Of course it’s a determenistic algorithm, but engineers treat it as a black box.
> Anymore? Really? I reboot my Windows computer one-tenth as often as twenty years ago.
Why do you need to reboot at all?
By "install it", I thought you meant install Windows, which takes for longer than 30 seconds. It's not a straight byte copy. For one, part of the install process compiles code for your variation of CPU architecture.
> It’s always been a problem.
In fact, it's less of a problem now than it was 15 years ago. Google Docs, Office 365.
> Yet new languages (e.g. Rust) are still developed with terribly slow compilers
Slow compilers (Rust, TypeScript, Scala, Haskell) almost universally have complex type inference.
Languages with limited type inference (Go, Java) have fast compilers.
It's really a matter of choice of language design, rather than compiler implementation.
> Well, I meant randomly in a sense that you can hardly predict or control what will happen.
This is like complaining search engine results are random because they are complex. Does it really matter?
> Why do you need to reboot at all?
Usually my battery dies.
That was my point. It does something very slow but unnecessary. If you could install it by straight copy, it would be way faster. And there’re no reasons why it can’t be straight copy (or really fast unzip & compile).
> Google Docs, Office 365
Google Docs disables offline mode by defaults. It only works as long as everyone are almost on the same page. It’s a step forward, yes. I wish using those algorithms was as easy as writing LAMP apps
> Usually my battery dies.
Doesn’t mean it has to reboot. It’s just an implementation design of current OSes. See Phantom OS
"In the past few years I have watched generations of word processors, spreadsheets, and graphics packs transcend the useful and user friendly, to become fiendishly complex - from auto-spelling checks that irritatingly pop on to the screen as you type, to the graphics-by-questionnaire that realise the wrong format in five easy stages.
Application changes of this type beggar belief. Not only do they consume vast amounts of storage, they reconfigure commands, change names and locations, present a vast range of never to be used (or discovered) options that just confuse users. [..]
It can only be that commercial considerations prevent us having a cut down and basic set of applications that are backward, forward and sideways compatible. Writing a letter, book, business case or report does not demand the capabilities of an entire publishing industry." - "How to upgrade your stress" - http://archive.cochrane.org.uk/opinion/archive/telegraph/199...
That was written on a 36Mhz laptop with 20MB RAM and 0.5GB disk space.
Within weeks, he wrote "My recent computer hardware upgrade, and simultaneous software downgrade, has resulted in huge performance improvements. More or less all delays between hand, screen, and eye have been removed. Applications open instantaneously once booted up and files save in a second." - in "Beyond Biology" - http://archive.cochrane.org.uk/opinion/archive/telegraph/199...
And then he goes on to tear apart tonsky's argument about aircraft and cars: "If we could manipulate the space in materials we could perhaps reduce the weight of an aircraft by 90%, suggests Peter Cochrane [..]" - "There's nothing to the Universe" - http://archive.cochrane.org.uk/opinion/archive/telegraph/199...
[1] http://www.cochrane.org.uk/bio/
How we used to set a variable in assembly language:
How we do it in React / Redux I don't understand how people don't see something is horribly wrong.const foo = 1;
What you're doing in your complicated sample is not _just_ setting a variable, you're also exposing it to a KVO subscription system that you could never represent succinctly in ASM.
What's sad is how programmers communicate programming concepts right now, with quick digs and hot takes and zero actual critical thought to what is being compared. I'm disappointed that you're spreading FUD in your internal talks.
I'm disappointed at the zero-attempt-to-understand-the-point digs made on hacker news (like the one I'm responding to). The point is, how is multi-layered abstraction an unalloyed good? Its heavy, slow, complicated to author and explain, and not doing all that much of value.
The real question is, is all that really needed?
We keep building abstraction layers on top of abstraction layers when often times, there is already tried and proven solution that works and is much simpler.
I've been doing some experimenting creating a single page application (SPA) without a web framework and turns out you can get 90% of what React offers with a tiny amount of code.
https://github.com/brennancheung/volgenic/blob/master/13-IDE...
My current iteration is just to do a:
I just use plain javascript objects to store data and wrap it in a function that will trigger re-rendering the VDOM / repaint.And even if we do need that additional layer of abstraction we can always make it appear simpler and provide a cleaner interface to the programmer. A Proxy object setter could be used to eliminate the boilerplate of State.update.
Good abstractions simplify the problem by creating a mental paradigm that is closer to the problem domain. Poor abstractions do the opposite, they take away what is needed to solve the problem and create additional steps that are not really germane to the problem.
Many abstractions are well intentioned, but after we toss layer on top of layer, we often get so far removed from the problem domain, we have to ask ourselves if it is not simpler to just build up another set of abstractions that allow us to get closer to the problem domain (i.e., "First Principles").