We wanted multi-tasking OSes, so that we could start one program without having to exit the previous one first. That made the OS a lot bigger.
Eventually, we got web browsers. Then Netscape added caching, and browsers got faster and less frustrating, but also bigger. And then they added multiple tabs, and that was more convenient, but it took more memory.
And they kept adding media types... and unicode support... and...
We used to write code in text editors. Well, a good IDE takes a lot more space, but it's easier to use.
In short: We kept finding things that the computer could do for us, so that we wouldn't have to do them ourselves, or do it more conveniently, or do something at all that we couldn't do before. The price of that was that we're dragging around the code to do all those things. By now, it's a rather large amount to drag around...
This is all very true, but I feel like we (as users) haven't really gained proportionally compared to the increase in computing power and storage.
For example IDEs: Visual Studio in 2017 is certainly better than Visual Studio in 1997, but do those advancements really justify the exponential growth in hardware requirements?
How'd we get so little usable functionality increase for such a massive increase in size/complexity?
Would you get twice as much from your car if you install 2x more powerful engine? Would a 2x more powerful weapon win you 2x more wars? Would 2x better medicine technologies allow you to live 2x longer?
My exact thoughts. What the heck is VS doing? No IDE should require the amount of resources it does to where it is almost unusable on any computer > 5 years old (assuming said computer wasn't overpowered to start with).
Yes, they do. Computers are cheap; humans are expensive. In an average application (including IDEs), most CPU time is spent idling waiting for user input. Most memory is idle unless you have something like superfetch caching stuff ahead of time for you. If the new features make users faster, they're decidedly worth it.
Fundamentally, modern systems are much more usable - in every sense of the word. Modern IDEs are more accessible to screen readers, more localizable to foreign languages including things like right-to-left languages, do more automatic syntax highlighting, error checking, test running, and other things that save developer cycles, and on and on. Each of these makes the program considerably more efficient.
Personally I get grumpy when modern IDEs make me wait on them. I don't care that much about CPU/RAM usage until the computer starts wasting my time while I'm trying to work. That's sadly very common these days even on relatively beefy hardware.
So I agree with you that computer time is cheap and user time is not, but I think we could optimise better for user time.
> Fundamentally, modern systems are much more usable...
I just don't buy this premise. _Some_ systems are more usable. But take a look at Microsoft Excel from circa 1995-2000, which came with a big thick textbook of documentation, explaining what every single menu item did. Every single menu item was written in natural language and it told you what it would do. Professionals used (and still use) Excel, crafting workflows around the organization of the UI. It's a tool that is used by actual people to accomplish actual tasks.
Now look at Google Sheets. It has about 1/10th the functionality of Microsoft Excel (hell--it can't even do proper scatter plots with multiple data series) and its UI is an undiscoverable piece of crap because half of it is in _iconese_--a strange language of symbols that are not standardized across applications, confusing and ironically archaic depictions of telephones, arrows, sheets of paper, floppy disks. The program is written in a pictographic language that must be deciphered before being used. Software doesn't even speak our natural languages anymore...we have to learn _their_ language first...and every application has its own and that language changes every six months. Worse, all those funky pictograms are buttons that perform irrevocable actions. They don't even explain what they did or how to undo it...it makes users less likely to explore by experimentation.
...and there is no manual, there is no documentation. It will be all different in six months, with less functionality and bigger--different!--icons...takes more memory.
Google Sheets can be shared via a URL and anyone with a web browser can access it instantly. No need for Windows, no need for an Excel license, no need for a desktop computer. You cancollaborate in real-time too.
So you can share and collaborate...but the functionality to actually _create_, that's hopelessly oversimplified and undocumented. I think you are missing my fundamental point.
> For example IDEs: Visual Studio in 2017 is certainly better than Visual Studio in 1997
Is it? 97 might be a bit extreme, but the other day I opened an old project which was still on VS2010 and I was struck by how much faster 2010 was while still having nearly every VS feature that I wanted. They're slowing porting VS to .net and paying a huge performance penalty for that.
That's the type of example I've come across all too frequently. Software that's 5-10 years old, has all the same functionality, uses a fraction of the resources, and is often "better" in several ways.
Older versions of Android Facebook seem massively faster and use a fraction of the RAM while providing (nearly?) the same functions and features.
I think this is the tragedy of the commons. Computers are getting better. Each team says in its heart "We can be a bit wasteful while providing feature X." When aggregated the whole thing is slower.
I think your comment is closest to reality. I believe it was incremental and deliberate, but the key piece that is missing from your assessment is that we (the royal "we") haven't given a lot of attention to correcting any poor choices. I think you are right when you say that hardware improvements helped encourage devs to give more tasks to the machine like encoding, caching, etc. However, it also became less important to revisit the underlying pieces on top of which we added these new features. It eventually became this dirty snowball rolling downhill that was built from layers of whatever was in the way as well as anything we could throw at it.
For example, the web might be filled with redundant and bloated software, but the real problem is that the browser has become the nexus of virtualization, isolation, security, etc. for almost everyone from the causal user to hardcore admins and for every piece of software from frameworks/utilities to full-blown SAPs. It's like we have all reached a common understanding for what comprises a "good" application, but then we lazily decided to just implement these things inside another app. I mean, webassembly is great an all, but is it wise?
I don't think it's about IPC or RAM or (n+1) framework layers that each include "efficient list functions". I think it about the incremental, deliberate, and fallacy-laden decisions that assign more value to "new" than to "improved".
Note NASA controlled the moon missions with an IBM 360/95 that had something like 5 MB of RAM, 1GB of disk, and about 6 million instructions per second.
Today an internet-controlled light switch runs Linux and has vastly larger specifications. Connecting to WiFi is more complex than sending astronauts to the moon!
> Note NASA controlled the moon missions with an IBM 360/95 that had something like 5 MB of RAM, 1GB of disk, and about 6 million instructions per second.
And an army of technicians available around the clock to keep it working. Whereas your IoT light 'just works' and isn't expected to require any support at all.
There are two possible conclusion to that : the first is that we suck at programming. The second is that what we think is easier to do (today's programs vs controlling moon mission) is actually not.
Maybe a lot of what those computers were doing were just raw computations, much like a DSP, to control trajectories, and nothing more. Something like a big calculators, with some networking capabilities to receive and send a few sets of instructions.
I do often wonder wth is going on with bloat. I can understand a videogame which has huge amounts of media might be large. But business apps?! It doesn't make sense.
I think it makes absolute sense (in overall terms), hardware capabilities at a fixed price scaled exponentially while the costs of producing software went up mostly linearly, or to put it another way.
I have a 5 minute mp3 that takes more space than my first hard drive had and some icons on my desktop that take more space than my first computer had RAM.
Whether that will continue to hold I don't know, mobile has certainly pushed certain parts back towards caring about efficiency (though more because it impacts battery life).
If you remove a constraint people stop caring about that constraint.
The old school geek in me laments it sometimes but spending twice as long on developing something to save half the memory when the development time costs thousands of dollars and twice as much RAM costs a couple of hundred seems..unwise.
As much perhaps not, quite a lot still though but I simply don't care anymore.
I copied 153Gb of data onto my laptop earlier over my fiber connection because the project I'm working on needs it and I couldn't be bothered to go find the external drive with it on in the storage closet in the 2nd bedroom.
I can buy 500GB of really fast m2 SSD for 153 quid (approximately 30p per GB) or terabytes of storage for 153 quid.
I got a new thinkpad a few weeks ago, I specced it with 16GB on one slot because I fully intend to upgrade to 32GB fairly soon with virtualisation I can bump up against 16GB, Let that sink in, My time is so precious (to me on my machines and my employer on theirs) that I'm happy to virtualise entire operating systems and allocate billions of bytes of memory and storage to save some of it.
Hardware is absurdly cheap and I can't really see that changing for a while, from a systemic point of view it's ridiculously more efficient to spend a lot of money in a few places (Intel, Samsung, IBM etc) than to spend a lot of money in every place.
Every time Intel puts out a processor that is 10% faster at the same price everyone elses software just got 10% faster for free* (*where free = the price of the new processor).
There just isn't a market incentive (financial or otherwise) to rollback bloat, if there where it would be a competitive advantage and everyone would be doing it, that they aren't shows that it isn't.
I suspect a lot of the reason why Linux installs stayed so relatively lean was because for a long time most people had CD burners not DVD burners, once those where common install ISO's blew right past 650Mb, I think Fedora 26's was 1.3Gb, I didn't really pay any attention.
So, even without Moore's law, it's better to improve percentage efficiencies at a few highly leveraged points, rather than at every point. A percentage improvement in the processor, gives improvement for all customers, and for all layers of their stack, all parts of their software, every line of code: OS, DB, language, stdlibs, third-party libraries, in-house libraries, yesterday's code, code you're writing write now.
I unpack that so much to show how much benefit it gives, and that, perhaps even a tiny percentage benefit... 1%? 0.1? 0.001? etc? ... might still be a win...
In any case, that is irrelevant as 14nm and ipc are pretty much maxed out, and from this point on, this is it. Unless CPUs move away from silicone, this is as fast as it gets (save for adding cores to the problem).
Yes and no, I built a Ryzen 1700 desktop for work, that processor cost about the same as the K i5 I bought a few years ago (adjusting for the pound cratering).
On multithreaded workloads that I care about its not just a little faster, it's a lot faster.
There is still a lot of fruit to be had in that direction I think and that's before you consider the other areas left for performance improvement.
Of course for some workloads/people they are already butting up against a different cost/benefit and they do care about ekeing every cycle out the processor but for me it hardly matters.
My desktop at work runs a development version of our main system faster under vagrant than it runs in production since I've got more RAM and a machine with twice as many cores.
:) I'm in the same boat. Built a 1700x with 32gb for my home workstation.
Feels lot faster than the 4670k it replaced.
I suspect most of that is the ddr4 + another 4 cores + nvme , rather than IPC gains.
I like the direction the CPUs moved, although after 7nm in few years, they'll have to redesign a lot more than CPUs to get anything substantial out of it.
I'm being a little bit ridiculous, but most people I know run it overnight. I did an install recently and several hours was correct for the IDE + data science pack. Put another way, I could install Haskell, Python, Ruby, Perl, Free Pascal, Dyalog APL, Nim, Elixir, Julia, and a few more with time to spare. Granted, the data science pack in VS comes with R and Anaconda Python, but still it is insanely big by almost any standard. I think at that point it's time to take a step back and evaluate modern programming practices (after I uninstall a bunch of junk ;)).
Could a .NET expert break it down for me why VS takes the size and memory it does. I know why VS Code needs 150 MB of RAM (JavaScript), but VS should be written in C++ right?
Maybe they've improved it since I last used it (was two or three years ago now). But you say reinstalled? Is it possible it only reinstalled the VS-proper components and not all of the dependencies that the first-time install pulls in?
It used to take many hours to install if you were installing it from a CD, DVD, or spinny HDD onto a spinny HDD. The last time I had to install it, I did it from and to an SSD, and including patches and extensions it took about half an hour.
The main culprit was extracting and copying all of the small source files that come with it.
Installing big c++ libraries also takes a long time sometimes, for example when decompressing Boost onto your drive. Lots of little files that need to be written.
> Whether that will continue to hold I don't know, mobile has certainly pushed certain parts back towards caring about efficiency (though more because it impacts battery life).
Has it? Try using a low end phone with something like 8GB of internal storage, mobile apps are ridiculously slow and bloated. It's to the point where I haven't looked in the play store for years because I simply don't have enough room on my phone. That means the dev community has screwed itself over with wastefulness.
Given that my phone is broadly capable of doing the tasks of my laptop from 5 years ago and that it does it with half the RAM, a fraction of the processing power and a power budget of 3500mah for the entire day (something my laptop from 5 years ago would blow through in minutes if not seconds..) yes?
I think in some cases "improved" efficiency for mobile has actually harmed subjective performance, because it encourages trading latency for throughput. I care more about how fast software feels than how fast it benchmarks. Worst cast latency matters. I'd happily accept a thicker and heavier device if it meant I never had to wait for it.
To give one example, Xilinx ISE is 18GB installed. Seemingly everything carries around its own copy of everything. The output of a basic fdupes -r on my /opt/Xilinx is 114976 lines.
Software complexity increases exponentially with linear growth in features and polish. Occasionally someone takes the time to step back and rethink things, but generally you’re just adding another layer on top of the ancient ruins. Code archaeologist should be a job title in many organizations.
It's less than archaeology (where artifacts are embedded in soil) and more like geology (because everything is code, i.e. code is the soil). But yeah, I've had the same feeling when refactoring a decade-old application. You could really recognize the styles of different developers and eras in the same way that geologists recognize eras by looking at the type of stone deposited during that era.
"The first 90% took 2 weeks to finish. The second 90% also took 2 weeks to finish (and now your 99% done). The next 90% also takes two weeks to finish (99.9% done)..." Reapplied to another resource..."The first 90% consumes 1GB of RAM. To solve the next 90% of the problem, takes 1GB of additional RAM...
If you continue this trend, the problems solved in the incremental steps maybe used fractionally less often, but are probably also more complex and required a greater resource investments. Our software does a lot more, but the later developed parts are usually used left often and are more complex. Talking to the one and only ship headed to the moon when you don't particularly care who hears you is less difficult than securely purchasing things online over a WiFi connection. At the user experience level its just "thing A talks to thing B" but the later case has also had to solve n-th 90% issues of congestion and security and handshake and...
That being said, we rarely go back and see what in the earlier iterations are now based on false assumptions. So there probably is a fair amount of accumulated cruft with no clear detector for what is cruft and what is essential.
I don't agree necessarily with the first three items on your list.
In fact I think there is a sort of casual indifference to the first two that frequently borders on criminal neglect. Why bother with them when the "time to market" driver of methodology selects for the most easily replacable code?
Safety is also debatable and mostly accidental. Most of the languages that are fast and "easy" to develop in rest on a core of C or C++, and are really only as safe as that code. Safer, because there may be fewer foot guns, but not necessarily "safe."
> It is cheaper to develop a .Net app than a C app. Cheaper in Development and maintenance.
I think this is true but I disagree that it's inherently true. Slapping a UI together with c and GTK is pretty strait forward for instance, here is a todo list where I did just that (https://gitlab.com/flukus/gtk-todo/blob/master/main.c). It's not a big example, but building the UI and wiring the events was only 40 lines of code, it's the most straightforward way I've every built a UI. More complicated things like displaying data from a database are harder, but I think this comes down to the libraries/tooling, the .net community has invested much more time in improving these things than the c community.
> What we're losing in efficiency, we gain in code readability, maintainability, safety, time to market, etc.
I don't think we've exhausted our options to have both. We can build things like DSL's that transform data definitions into fast and safe c code for instance. Imagine instead of something like dapper/EF doing runtime reflection we could build equivalent tools that are just as easy to use but do the work at compile time. Or we could do it via rusts kickass compile time meta programming.
The problem with Delphi was Borland kind of killed the product by pushing it to enterprises with deep pockets and taking too much time to adapt to 64 bits and newer platforms.
Doing something for the first time, almost by definition, means one does not really know what one is doing and is going to do it somewhat wrong.
Hiring less skilled labor (cheap coder camps for example) to implement buzzword bingo solutions gets you into a place where all the software contains large chunks of it's substance coming from people doing it for the first time... and not 100% right.
As we never go back to fix the tech debt we end up building stills for the borked and less than great. When that structure topples over we start over with a new bingo sheet listing the hot new technologies that will fix our problems this time round for sure.
I'd think that a good fraction of the current language expansion is that the older languages are too complex and filled with broken. Green fields allow one to reimplement printf, feel great about it, and get rewarded as a luminary in the smaller pond.
.....
oh... and well the cynic in me would argue planed obsolescence at the gross level. No one buys the new stuff unless there's new stuff.
Software engineering reinvents everything every decade or so. People were complaining about it 20 years ago - I suspect they have from the beginning. Not only new languages, also new hardware and new platforms in general. Moore's law seemed to be the driver, but the constant growth means constant new people... unlike scientific paradigms, we needn't wait for old practitioners to die.
> Doing something for the first time, almost by definition, means one does not really know what one is doing and is going to do it somewhat wrong.
The Mythical Man-Month has a chapter on this titled "Prepare to throw one away". Brooks argues, that the program/OS/whatever you build the first time around should be considered a prototype. Then you reflect on what problems you encountered, what went well, and so on and use those insights to guide you when start over.
It seems like such an obvious idea, but Brooks wrote that almost 50 years ago, and it seems like only very few people listened. Primarily, I guess, because much software is already written under highly optimistic schedules - telling management and/or customers that you want to throw the thing out and start over is not going to make you popular.
That do it twice idea originally came from Royce's famous article in 1970 which lead people to claim he invented Waterfall (due to the diagram he started with). Reflecting on practices from leading teams in the 60's was that do the project once to learn everything, and then do it again and ship the second one. Worth reading.
On the other hand, we have the Second System Effect, about the dangers of throwing away the first version of Thing in favor of "Thing Done RIGHT This Time".
Typically as developers we let the software bloat until it hurts us directly. Since we are always using more and more powerful machines we are always going to let the bloat continue. If we get called on it we've got the slam-dunk in our back pocket: "Premature optimization is the root of all evil."
Older software was written in languages you had to manage the memory in C, C++, pascal etc, it requires more skilled developers (I'm told), simpler languages like javascript require less knowledge to write applications. The cost is though higher resource usage.
Exactly. Its ironic his post doesn't even show up until I allow js loaded from multiple domains just to show 4 pictures and a couple paragraphs of text. Sites like his are huge part of the problem.
FYI: I think you can still select blogger themes which don't require JS to render. Some people use them, including (perhaps just as ironically) the Google Developers Blog[0].
Though JavaScript is of course not mandatory, the mind set and incentives in which web specs have been created by browser vendors is bound to pile up complexity, in that developing a browser from scratch is considered infeasible (last one to try was Opera), and browser vendors are rather trying to turn existing browser code bases into universal runtimes for apps. Point in case: WASM, which I consider bloated and out of place in a web browser.
I suspect this is the inevitable price for the expanding scale of the software industry. Perhaps the problem isn't about depth, as in what a given piece of software can do, as much as breadth, as in how much software there is now and how many different things it can do collectively.
One cost of the increasing breadth in the industry is that if we want to have a lot more software then obviously it can't all be written by the same relatively small pool of expert programmers who wrote software in the early days. With more software being written by people with less skill and experience, many wasteful practices can creep in. That can include technical flaws, like using grossly inefficient data structures and algorithms. It can also include poor work practices, such as not habitually profiling before and after (possibly) optimising or lacking awareness of the cost of taking on technical debt.
Another cost of the increasing diversity in the software world is that to keep all that different software working together, we see ever more generalisations and layers of abstractions. We build whole networking stacks and hardware abstraction libraries, which in turn work with standardised protocols and architectures, when in days gone by we might have just invented a one-off communications protocol or coded directly to some specific hardware device's registers or memory-mapped data or ioctl interfaces.
There is surely an element of deliberately trading off run-time efficiency against ease of development, because we can afford to given more powerful hardware and because the consequences of easier development can be useful things like software being available earlier. However, just going by my own experience, I suspect this might be less of a contributory factor than the ones above, where the trade-off is more of an accident than a conscious decision.
Software went off the rails when Java decided to store all nested nonprimitive objects on the heap, and Sun thought this was an acceptable choice in a language marketed at general purpose app development.
I think it started when we went away from native compiled languages. Visual Studio 6 was in my opinion the best version in terms of responsiveness/functionality. After that, with .Net, Visual Studio started including more .Net code and become more and more slow over time. Over time, people slowly got used to their applications being slower and slower. Then the web came and people started writing apps in Javascript. The Javascript apps are not too bad compared to the .Net apps, so people did not notice. However, if you were comparing them to Pascal/C/CC++ apps, you would have noticed a big difference.
I don't think that interpreted languages is the problem since people were using Visual Basic since the Windows 3.0 days. There are some collections in archive.org for 16bit Windows shareware programs and games with hundreds of entries and like 2/3 of them are made in some version of VB.
Now, .NET and JVM might be a problem since those VMs tend to be resource hogs (after all both use GC methods that allocates tons of memory whereas something like Python or even classic VB use reference counting - even then there are languages that aren't using reference counting but some other method of GC and still are fast). But i don't think you should put all interpreted languages at the same box.
Also you should not put all GC languages in the same box, as many do allow for AOT compilation to native code and do support value types and GC-free memory allocation as well.
Heh, it finally happened on Hacker News too, people misunderstood what i wrote and downvoted me for it instead of trying to understand what i am talking about (yes i am annoyed with that, it is one thing to be misunderstood and another to be penalised for being misunderstood - especially on HN where messages fade out when downvoted).
So, first of all:
> Reference counting is GC.
How did you thought that i said otherwise when i clearly wrote "aren't using reference counting but some other method of GC" ("other method" here implying that reference counting is also GC)?
Moving on...
> Also you should not put all GC languages in the same box
I did not, as should have been obvious from the "after all both use GC methods that allocates tons of memory whereas something like Python or even classic VB use reference counting" where i compare two different methods of GC, one that uses a lot of memory and another that doesn't.
Now i get that making the previous misunderstanding would make this bit sound as if i was making a comparison between "GC" (Java, C#) and "non-GC" (Python, classic VB) - and please note that the quotes here are to show what one could think while having that misunderstanding, not what i really think, after all i already made it clear with the previous quote that i think that reference counting is a method for GC - however i do not think that it is my fault here, i gave examples and tried to make myself clear about what i mean. After some point i believe it is up to the reader to actually try and understand what i am talking about.
I think the rest of your message (the "as many do allow for AOT compilation to native code and do support value types and GC-free memory allocation as well.") is relying on the above misunderstandings, especially considering i didn't do what you describe, so i am ignoring it.
Now don't get me wrong, i am not attacking you or anything nor i believe you are wrong with the fact parts of your message ("reference counting is GC", "not all GC languages are the same"), it is just that the message doesn't have much to do with what i wrote.
While application software has become more bloated, Microsoft has done a fairly good job at keeping Windows necessary footprint down.
After Apple stopped supporting 32 bit x86 Macs years ago, I decided to put Windows 7 on my old 2006 era Core Duo 1.66ghz Mac Mini with 1.25GB of RAM. My parents still use it occasionally. It can still run an updated version of Chrome and Office - not at the same time of course - and it isn't painful.
My Plex Server is a 2008 era Core 2 Duo 2.66Ghz Dell business laptop with 4Gb of RAM.
I don't know how much drive space Windows 10 needs. But the Core 2 Duo with 4Gb of RAM I referenced is running Windows 10 and can transcode at least 2 streams at once. It's running the Plex Server and Plex Connect - a Python (?) web server that intercepts requests from the 3rd gen AppleTV to render a Plex client.
IMHO, there is no Software Engineering. There is only Computer Science. There is none of the discipline that comes from engineering, and only the messiness that comes from science. The heroes in software are Computer Scientists and everyone wants to be a Computer Scientist. No one wants to be a Software Engineer. It isn't even clear to me that Software Engineering exists in a clearly defined way. Maybe a manager or director imposes their will on a group somewhere and engineering is done.
And not even Computer Science, just Programming. Maybe here at HN there's a will to understand why the algos are like that, or when to choose a given data structure. But most workers in this industry are content with writing code, seeing it compile, and pass it to the next person in the chain.
Source: half assed personal opinion base in 10+ years experience
This is simply untrue. There _are_ people who want to be software engineers -- I'm one of them! The field is still young, but there are those of us who strive to apply the rigour seen in other engineering disciplines to the work in which we engage today. We seek to balance competing demands of quality, features, and schedule.
Though I get to produce programs when it makes sense, I spend a lot more time writing prose and communicating with others inside and outside the immediate engineering team in which I work. I also spend a lot of time chasing down problems in existing software; each new failure provides an opportunity to improve our overall practice. Mistakes can and will always happen; negligence must not.
To suggest that there isn't, or cannot be software engineering is maddeningly self-defeating.
Thanks Jason, enjoyed your thought-provoking post. I'm reminded of Parkinson's law that "work expands so as to fill the time available for its completion". It's as if the software bloats up to fill up the available hardware capacity.
From a fundamental level though, my hunch would be how modern development takes modularization / abstraction to a type of extreme. Imagine a popular Node.js module and how many dependencies it has and how many dependencies its dependencies have.
It's not hard to imagine a lot more computing power is required to handle this. But that's ok to decision makers, computing power is cheap. Saving developers time by using modularized developments brings more cost/profit benefits, like what Dan said.
PS: the link on Visual Studio. Oh wow, what fond nostalgic memories it brings me :)
Software was never on the rails. This whole industry has, AFAICT, been flying by the seat of its pants from Day 1 with whatever hacks get today's job done. For a while, that meant hacks to save space and time. Now... it doesn't.
I think the biggest culprits are abstraction layers. You use a framework that use js that use a VM in a browser that runs on an OS. The time when showing text was done by the application writing a few bytes in VRAM is long gone. Each layer has its internal buffers and plenty of features that you don't use but are still there because they are part of the API.
Another one is laziness : why bother with 1MB of RAM when we have 1GB available? Multiplied the number of layers, this becomes significant.
Related to laziness is the lack of compromise. A good example is idTech 5 game engine (Rage, Doom 2016). Each texture is unique, there is no tiling, even for large patches of dirt. As expected, it leads to huge sizes just to lift a few artistic constraints. But we can do it so why not?
Another one is the reliance on static or packaged libraries. As I said, software now use many layers, and effort was made so that common parts are not duplicated, for example by using system-wide dynamic libraries. Now these libraries are often packaged with the app, which alleviate compatibility issues but increase memory and storage usage.
There are other factors such as an increase in screen density (larger images), 64 bits architectures that make pointers twice bigger than their 32 bit counterparts, etc...
Yeah, it probably doesn't really help the situation when you build several layers of abstraction in an interpreted language that runs in a virtual space on a virtual machine using another abstraction layer running on virtual cores that go through complex OS layers that somehow eventually possibly map to real hardware.
> The time when showing text was done by the application writing a few bytes in VRAM is long gone.
Related: just went to a news site that had this absolutely gorgeous, readable font called "TiemposHeadline" for the headlines. That font was loaded through the @font-face interface of CSS, so that's probably somewhere in the ballpark of 1M.
That I so casually navigate to find the name of the font and how its getting loaded is due to devTools, which is tens of megs of storage space plus whatever chunk of memory it's eating.
I think examples like Doom are misleading. Those are essentially hand-compressed diamonds of software. Some of the resource-saving techniques used there are bona fide legends. It should come as no surprise that an increase in availability of RAM and storage space causes the software to accordion out to fill the available resources in return for ease-of-development.
That said, I'm all for software minimalism movements as long as the functionality and usability remains roughly the same.
just to set the record straight, idtech5 uses "megatextures" / sparse virtual texturing, which is actually a very clever performance enhancement - a low-resolution render of the scene is made to determine the needed mip levels for the visible textures, which are streamed from disk into an atlas texture. then there's a redirection texture that maps from the textures needed by models to the UVs of the correctly mip'd texture in the atlas. it's a great solution to disk and API latency in games. to call it bad because it's a big texture instead of 50 textures individually streamed from disk...it's not a lack of compromise. it's a great engineering solution, you dingus!
I don't think that megatextures are bad in fact I am kind of a fan of John Carmack and id software.
The rationale behind megatexture is that storage capacity increase exponentially but our perception doesn't. There is a limit to what our eyes can see. In fact for his future engines, John Carmack wanted to go even further and specify entire volumes in the same way (sparse voxel octrees).
And sure, the way megatexture is implemented is really clever, and yes it is for a good reason, but it doesn't change the fact that it makes some of the biggest games on the market (Doom is 78GB)
When I said no compromise, it is no compromise for the artists. The whole point of megatexture is to free them from having to deal with some engine limitation. They don't have to be clever and find ways to hide the fact that everything is made of tiles, they just draw. And yes, this is a good thing, but a good thing that costs many gigabytes.
I still find it amazing that DOOM was 2.5MB. A Google search page is ~20MB (16MB in DDG). And a Wikipedia page is ~19MB. (FF 55). This is crazy to me. That even simple things take so much space now. I know space is cheap, but this does feel bloated. And while these sizes might not be noticeable on a computer, it definitely is on a mobile connection. I had figured the advent of mobile would make optimization more appealing, but it seems to go in the other direction.
There is no way a google search is 20MB and a wiki page is 19MB. My tests shows a google page is around 1MB, and wiki pages obviously depends on weather or not the page is has many and large images. But the average page definitely isn't near 19MB that's for sure.
Although it's great for campfire stories I don't really see a problem. Resources are there to be used - the lesson from StarCraft is you don't horde resources to victory. I think most believe this as how many of us are writing unikernel OSs purposed built for our hand tuned assembly backends
Sticking with the Starcraft analogy: We're spending the resources constantly, and even increasing the size of our army to combat the constant onslaught of enemies. If we could basically decrease the price of our units, then wouldn't that be a benefit? You spend a boatload of time and resources on research, and gain on ongoing benefit from it.
Take this laptop: spinning platter drive and 4GB of RAM. I'd be happy if it could do more with the same hardware, and I think that's the core of what we're talking about.
You are all missing my point (or I did not make it clear) - the resources are there for you to burn in achieving your goals. You will never be able to deliver a product in competitive fashion compared to groups that are more willing to burn resources (with "reason") - the market simply doesn't pay for high efficiency on the desktop or in the browser
I've been teaching myself C, with the intention of learning how to write code for embedded applications where efficiency is key.
It seems to me that new languages prioritize quick iteration over effective machine operation. The easier a language is to write and interpret, the faster an outfit can churn out an application. The exponential computing power growth has been sufficient enough to absorb these collective "shortcuts". Thus, it is not being taken advantage of properly.
The CSCI/Engineering fields have become more of a gold rush than thoughtful trades. Boot camp management seeks profit, and trainees seek to quickly fill high paying jobs. It all culminates into this situation where code doesn't need to be clever and thought out - just created A.S.A.P to handle whatever trending niche market or "low-hanging fruit" there is. The work of these products get handled server side, where electrical costs for cooling is a fundamental expense.
I want to second Rust. I've been writing C for 5+ years and finally decided to give Rust a serious try... and I love it. I never ever thought I would say this, but I don't see myself going back to C (with minor exceptions)
I recall being excited the first time i learnt C. But after i learnt other programming languages, the defects of C started to appear clearly before my eyes. C++ is even worse (in terms of things that look like hastily designed)
Rust is comparably more coherent and elegantly designed.
I'm currently on a Mac and a PC. The Mac's CPU is at maybe 5% when I'm doing most things.
The PC is at 1%.
I'm using half the PC's memory and 3/4 of the Mac's.
These are no up to date, high memory or high performance machines.
Have a look at your own machine. Surely for most of us it's the same.
And that memory usage is mostly in one application - Chrome. The only bloat that hurts a bit now is web page bloat. And on a good connection this isn't an issue either.
It's also different on phones where application size and page size seems to matter more.
Chrome regularly uses about 10% of my RAM, but honestly Atom was the biggest offender, which is why I switched to Visual Studio. Also, games can be a huge CPU and RAM eater but it is almost always completely necessary.
Why did a bunch of open, unintelligent questions even get to the frontpage of HN? If this is the way one should think (ask questions we all on a low, unintelligent level agree are interesting) in order to become CTO, I will never get there...
330 comments
[ 5.0 ms ] story [ 224 ms ] threadWe wanted multi-tasking OSes, so that we could start one program without having to exit the previous one first. That made the OS a lot bigger.
Eventually, we got web browsers. Then Netscape added caching, and browsers got faster and less frustrating, but also bigger. And then they added multiple tabs, and that was more convenient, but it took more memory.
And they kept adding media types... and unicode support... and...
We used to write code in text editors. Well, a good IDE takes a lot more space, but it's easier to use.
In short: We kept finding things that the computer could do for us, so that we wouldn't have to do them ourselves, or do it more conveniently, or do something at all that we couldn't do before. The price of that was that we're dragging around the code to do all those things. By now, it's a rather large amount to drag around...
For example IDEs: Visual Studio in 2017 is certainly better than Visual Studio in 1997, but do those advancements really justify the exponential growth in hardware requirements?
How'd we get so little usable functionality increase for such a massive increase in size/complexity?
Fundamentally, modern systems are much more usable - in every sense of the word. Modern IDEs are more accessible to screen readers, more localizable to foreign languages including things like right-to-left languages, do more automatic syntax highlighting, error checking, test running, and other things that save developer cycles, and on and on. Each of these makes the program considerably more efficient.
So I agree with you that computer time is cheap and user time is not, but I think we could optimise better for user time.
I just don't buy this premise. _Some_ systems are more usable. But take a look at Microsoft Excel from circa 1995-2000, which came with a big thick textbook of documentation, explaining what every single menu item did. Every single menu item was written in natural language and it told you what it would do. Professionals used (and still use) Excel, crafting workflows around the organization of the UI. It's a tool that is used by actual people to accomplish actual tasks.
Now look at Google Sheets. It has about 1/10th the functionality of Microsoft Excel (hell--it can't even do proper scatter plots with multiple data series) and its UI is an undiscoverable piece of crap because half of it is in _iconese_--a strange language of symbols that are not standardized across applications, confusing and ironically archaic depictions of telephones, arrows, sheets of paper, floppy disks. The program is written in a pictographic language that must be deciphered before being used. Software doesn't even speak our natural languages anymore...we have to learn _their_ language first...and every application has its own and that language changes every six months. Worse, all those funky pictograms are buttons that perform irrevocable actions. They don't even explain what they did or how to undo it...it makes users less likely to explore by experimentation.
...and there is no manual, there is no documentation. It will be all different in six months, with less functionality and bigger--different!--icons...takes more memory.
We are regressing.
Hey but those animations are spiffy.
/rant
Is it? 97 might be a bit extreme, but the other day I opened an old project which was still on VS2010 and I was struck by how much faster 2010 was while still having nearly every VS feature that I wanted. They're slowing porting VS to .net and paying a huge performance penalty for that.
Older versions of Android Facebook seem massively faster and use a fraction of the RAM while providing (nearly?) the same functions and features.
For example, the web might be filled with redundant and bloated software, but the real problem is that the browser has become the nexus of virtualization, isolation, security, etc. for almost everyone from the causal user to hardcore admins and for every piece of software from frameworks/utilities to full-blown SAPs. It's like we have all reached a common understanding for what comprises a "good" application, but then we lazily decided to just implement these things inside another app. I mean, webassembly is great an all, but is it wise?
I don't think it's about IPC or RAM or (n+1) framework layers that each include "efficient list functions". I think it about the incremental, deliberate, and fallacy-laden decisions that assign more value to "new" than to "improved".
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Note NASA controlled the moon missions with an IBM 360/95 that had something like 5 MB of RAM, 1GB of disk, and about 6 million instructions per second.
Today an internet-controlled light switch runs Linux and has vastly larger specifications. Connecting to WiFi is more complex than sending astronauts to the moon!
And an army of technicians available around the clock to keep it working. Whereas your IoT light 'just works' and isn't expected to require any support at all.
As for the high complexity of IoT things, I don't think the extra complexity helps reliability, security, etc.
Maybe a lot of what those computers were doing were just raw computations, much like a DSP, to control trajectories, and nothing more. Something like a big calculators, with some networking capabilities to receive and send a few sets of instructions.
I have a 5 minute mp3 that takes more space than my first hard drive had and some icons on my desktop that take more space than my first computer had RAM.
Whether that will continue to hold I don't know, mobile has certainly pushed certain parts back towards caring about efficiency (though more because it impacts battery life).
If you remove a constraint people stop caring about that constraint.
The old school geek in me laments it sometimes but spending twice as long on developing something to save half the memory when the development time costs thousands of dollars and twice as much RAM costs a couple of hundred seems..unwise.
I copied 153Gb of data onto my laptop earlier over my fiber connection because the project I'm working on needs it and I couldn't be bothered to go find the external drive with it on in the storage closet in the 2nd bedroom.
I can buy 500GB of really fast m2 SSD for 153 quid (approximately 30p per GB) or terabytes of storage for 153 quid.
I got a new thinkpad a few weeks ago, I specced it with 16GB on one slot because I fully intend to upgrade to 32GB fairly soon with virtualisation I can bump up against 16GB, Let that sink in, My time is so precious (to me on my machines and my employer on theirs) that I'm happy to virtualise entire operating systems and allocate billions of bytes of memory and storage to save some of it.
Hardware is absurdly cheap and I can't really see that changing for a while, from a systemic point of view it's ridiculously more efficient to spend a lot of money in a few places (Intel, Samsung, IBM etc) than to spend a lot of money in every place.
Every time Intel puts out a processor that is 10% faster at the same price everyone elses software just got 10% faster for free* (*where free = the price of the new processor).
There just isn't a market incentive (financial or otherwise) to rollback bloat, if there where it would be a competitive advantage and everyone would be doing it, that they aren't shows that it isn't.
I suspect a lot of the reason why Linux installs stayed so relatively lean was because for a long time most people had CD burners not DVD burners, once those where common install ISO's blew right past 650Mb, I think Fedora 26's was 1.3Gb, I didn't really pay any attention.
In any case, that is irrelevant as 14nm and ipc are pretty much maxed out, and from this point on, this is it. Unless CPUs move away from silicone, this is as fast as it gets (save for adding cores to the problem).
On multithreaded workloads that I care about its not just a little faster, it's a lot faster.
There is still a lot of fruit to be had in that direction I think and that's before you consider the other areas left for performance improvement.
Of course for some workloads/people they are already butting up against a different cost/benefit and they do care about ekeing every cycle out the processor but for me it hardly matters.
My desktop at work runs a development version of our main system faster under vagrant than it runs in production since I've got more RAM and a machine with twice as many cores.
It's a strange market when that happens..
Feels lot faster than the 4670k it replaced.
I suspect most of that is the ddr4 + another 4 cores + nvme , rather than IPC gains.
I like the direction the CPUs moved, although after 7nm in few years, they'll have to redesign a lot more than CPUs to get anything substantial out of it.
We'll see, exciting times otherwise.
Could a .NET expert break it down for me why VS takes the size and memory it does. I know why VS Code needs 150 MB of RAM (JavaScript), but VS should be written in C++ right?
The main culprit was extracting and copying all of the small source files that come with it.
Has it? Try using a low end phone with something like 8GB of internal storage, mobile apps are ridiculously slow and bloated. It's to the point where I haven't looked in the play store for years because I simply don't have enough room on my phone. That means the dev community has screwed itself over with wastefulness.
When you look at the Android SDK you have to wonder if it's even possible to have a different outcome.
"The first 90% took 2 weeks to finish. The second 90% also took 2 weeks to finish (and now your 99% done). The next 90% also takes two weeks to finish (99.9% done)..." Reapplied to another resource..."The first 90% consumes 1GB of RAM. To solve the next 90% of the problem, takes 1GB of additional RAM...
If you continue this trend, the problems solved in the incremental steps maybe used fractionally less often, but are probably also more complex and required a greater resource investments. Our software does a lot more, but the later developed parts are usually used left often and are more complex. Talking to the one and only ship headed to the moon when you don't particularly care who hears you is less difficult than securely purchasing things online over a WiFi connection. At the user experience level its just "thing A talks to thing B" but the later case has also had to solve n-th 90% issues of congestion and security and handshake and...
That being said, we rarely go back and see what in the earlier iterations are now based on false assumptions. So there probably is a fair amount of accumulated cruft with no clear detector for what is cruft and what is essential.
It is cheaper to develop a .Net app than a C app. Cheaper in Development and maintenance.
It is cheaper to not care about efficient data management, or indexed data structure.
What we're losing in efficiency, we gain in code readability, maintainability, safety, time to market, etc.
In fact I think there is a sort of casual indifference to the first two that frequently borders on criminal neglect. Why bother with them when the "time to market" driver of methodology selects for the most easily replacable code?
Safety is also debatable and mostly accidental. Most of the languages that are fast and "easy" to develop in rest on a core of C or C++, and are really only as safe as that code. Safer, because there may be fewer foot guns, but not necessarily "safe."
But I'd definitely be interested in any studies that have tried to measure these over long time periods.
I think this is true but I disagree that it's inherently true. Slapping a UI together with c and GTK is pretty strait forward for instance, here is a todo list where I did just that (https://gitlab.com/flukus/gtk-todo/blob/master/main.c). It's not a big example, but building the UI and wiring the events was only 40 lines of code, it's the most straightforward way I've every built a UI. More complicated things like displaying data from a database are harder, but I think this comes down to the libraries/tooling, the .net community has invested much more time in improving these things than the c community.
> What we're losing in efficiency, we gain in code readability, maintainability, safety, time to market, etc.
I don't think we've exhausted our options to have both. We can build things like DSL's that transform data definitions into fast and safe c code for instance. Imagine instead of something like dapper/EF doing runtime reflection we could build equivalent tools that are just as easy to use but do the work at compile time. Or we could do it via rusts kickass compile time meta programming.
https://www.devexpress.com/Products/NET/Controls/WPF/
Also are you sure your C app will have a high score on clang and gcc sanitizers?
However, if you pick .NET vs Delphi you will see is easier to develop UI apps (and general apps) in Delphi than .NET.
Even today.
The exception is web apps, and web apps is another big problem that "normalize" bad architecture, bad language and bad ways to solve everything.
The language itself is still quite ok.
If wanna take a look for your self you can install Lazarus (http://www.lazarus-ide.org/, discussed https://news.ycombinator.com/item?id=14973706) a close clone of Delphi (version 7).
Or download the free edition (modern):
https://www.embarcadero.com/products/delphi/starter/promotio...
Tech Debt is rewarded.
Doing something for the first time, almost by definition, means one does not really know what one is doing and is going to do it somewhat wrong.
Hiring less skilled labor (cheap coder camps for example) to implement buzzword bingo solutions gets you into a place where all the software contains large chunks of it's substance coming from people doing it for the first time... and not 100% right.
As we never go back to fix the tech debt we end up building stills for the borked and less than great. When that structure topples over we start over with a new bingo sheet listing the hot new technologies that will fix our problems this time round for sure.
I'd think that a good fraction of the current language expansion is that the older languages are too complex and filled with broken. Green fields allow one to reimplement printf, feel great about it, and get rewarded as a luminary in the smaller pond.
.....
oh... and well the cynic in me would argue planed obsolescence at the gross level. No one buys the new stuff unless there's new stuff.
BTW is "stills" a typo for something? (shims?)
The Mythical Man-Month has a chapter on this titled "Prepare to throw one away". Brooks argues, that the program/OS/whatever you build the first time around should be considered a prototype. Then you reflect on what problems you encountered, what went well, and so on and use those insights to guide you when start over.
It seems like such an obvious idea, but Brooks wrote that almost 50 years ago, and it seems like only very few people listened. Primarily, I guess, because much software is already written under highly optimistic schedules - telling management and/or customers that you want to throw the thing out and start over is not going to make you popular.
http://archive.is/fJ7nu
The unfortunate thing is that Blogger started out being fairly light and clean -- at least it was back when I migrated to it.
At least static site generators are coming back into fashion. I've always considered them a better solution for media/news/blog type sites.
[0]: https://developers.googleblog.com/
One cost of the increasing breadth in the industry is that if we want to have a lot more software then obviously it can't all be written by the same relatively small pool of expert programmers who wrote software in the early days. With more software being written by people with less skill and experience, many wasteful practices can creep in. That can include technical flaws, like using grossly inefficient data structures and algorithms. It can also include poor work practices, such as not habitually profiling before and after (possibly) optimising or lacking awareness of the cost of taking on technical debt.
Another cost of the increasing diversity in the software world is that to keep all that different software working together, we see ever more generalisations and layers of abstractions. We build whole networking stacks and hardware abstraction libraries, which in turn work with standardised protocols and architectures, when in days gone by we might have just invented a one-off communications protocol or coded directly to some specific hardware device's registers or memory-mapped data or ioctl interfaces.
There is surely an element of deliberately trading off run-time efficiency against ease of development, because we can afford to given more powerful hardware and because the consequences of easier development can be useful things like software being available earlier. However, just going by my own experience, I suspect this might be less of a contributory factor than the ones above, where the trade-off is more of an accident than a conscious decision.
Now, .NET and JVM might be a problem since those VMs tend to be resource hogs (after all both use GC methods that allocates tons of memory whereas something like Python or even classic VB use reference counting - even then there are languages that aren't using reference counting but some other method of GC and still are fast). But i don't think you should put all interpreted languages at the same box.
Also you should not put all GC languages in the same box, as many do allow for AOT compilation to native code and do support value types and GC-free memory allocation as well.
So, first of all:
> Reference counting is GC.
How did you thought that i said otherwise when i clearly wrote "aren't using reference counting but some other method of GC" ("other method" here implying that reference counting is also GC)?
Moving on...
> Also you should not put all GC languages in the same box
I did not, as should have been obvious from the "after all both use GC methods that allocates tons of memory whereas something like Python or even classic VB use reference counting" where i compare two different methods of GC, one that uses a lot of memory and another that doesn't.
Now i get that making the previous misunderstanding would make this bit sound as if i was making a comparison between "GC" (Java, C#) and "non-GC" (Python, classic VB) - and please note that the quotes here are to show what one could think while having that misunderstanding, not what i really think, after all i already made it clear with the previous quote that i think that reference counting is a method for GC - however i do not think that it is my fault here, i gave examples and tried to make myself clear about what i mean. After some point i believe it is up to the reader to actually try and understand what i am talking about.
I think the rest of your message (the "as many do allow for AOT compilation to native code and do support value types and GC-free memory allocation as well.") is relying on the above misunderstandings, especially considering i didn't do what you describe, so i am ignoring it.
Now don't get me wrong, i am not attacking you or anything nor i believe you are wrong with the fact parts of your message ("reference counting is GC", "not all GC languages are the same"), it is just that the message doesn't have much to do with what i wrote.
AOT to native code via NGEN, or JITed on load.
The only .NET variant from Microsoft that wasn't compiled to native code before execution, was .NET Micro Framework.
After Apple stopped supporting 32 bit x86 Macs years ago, I decided to put Windows 7 on my old 2006 era Core Duo 1.66ghz Mac Mini with 1.25GB of RAM. My parents still use it occasionally. It can still run an updated version of Chrome and Office - not at the same time of course - and it isn't painful.
My Plex Server is a 2008 era Core 2 Duo 2.66Ghz Dell business laptop with 4Gb of RAM.
Source: half assed personal opinion base in 10+ years experience
Though I get to produce programs when it makes sense, I spend a lot more time writing prose and communicating with others inside and outside the immediate engineering team in which I work. I also spend a lot of time chasing down problems in existing software; each new failure provides an opportunity to improve our overall practice. Mistakes can and will always happen; negligence must not.
To suggest that there isn't, or cannot be software engineering is maddeningly self-defeating.
From a fundamental level though, my hunch would be how modern development takes modularization / abstraction to a type of extreme. Imagine a popular Node.js module and how many dependencies it has and how many dependencies its dependencies have.
It's not hard to imagine a lot more computing power is required to handle this. But that's ok to decision makers, computing power is cheap. Saving developers time by using modularized developments brings more cost/profit benefits, like what Dan said.
PS: the link on Visual Studio. Oh wow, what fond nostalgic memories it brings me :)
I think the biggest culprits are abstraction layers. You use a framework that use js that use a VM in a browser that runs on an OS. The time when showing text was done by the application writing a few bytes in VRAM is long gone. Each layer has its internal buffers and plenty of features that you don't use but are still there because they are part of the API.
Another one is laziness : why bother with 1MB of RAM when we have 1GB available? Multiplied the number of layers, this becomes significant.
Related to laziness is the lack of compromise. A good example is idTech 5 game engine (Rage, Doom 2016). Each texture is unique, there is no tiling, even for large patches of dirt. As expected, it leads to huge sizes just to lift a few artistic constraints. But we can do it so why not?
Another one is the reliance on static or packaged libraries. As I said, software now use many layers, and effort was made so that common parts are not duplicated, for example by using system-wide dynamic libraries. Now these libraries are often packaged with the app, which alleviate compatibility issues but increase memory and storage usage.
There are other factors such as an increase in screen density (larger images), 64 bits architectures that make pointers twice bigger than their 32 bit counterparts, etc...
Yeah, it probably doesn't really help the situation when you build several layers of abstraction in an interpreted language that runs in a virtual space on a virtual machine using another abstraction layer running on virtual cores that go through complex OS layers that somehow eventually possibly map to real hardware.
Related: just went to a news site that had this absolutely gorgeous, readable font called "TiemposHeadline" for the headlines. That font was loaded through the @font-face interface of CSS, so that's probably somewhere in the ballpark of 1M.
That I so casually navigate to find the name of the font and how its getting loaded is due to devTools, which is tens of megs of storage space plus whatever chunk of memory it's eating.
I think examples like Doom are misleading. Those are essentially hand-compressed diamonds of software. Some of the resource-saving techniques used there are bona fide legends. It should come as no surprise that an increase in availability of RAM and storage space causes the software to accordion out to fill the available resources in return for ease-of-development.
That said, I'm all for software minimalism movements as long as the functionality and usability remains roughly the same.
The rationale behind megatexture is that storage capacity increase exponentially but our perception doesn't. There is a limit to what our eyes can see. In fact for his future engines, John Carmack wanted to go even further and specify entire volumes in the same way (sparse voxel octrees).
And sure, the way megatexture is implemented is really clever, and yes it is for a good reason, but it doesn't change the fact that it makes some of the biggest games on the market (Doom is 78GB)
When I said no compromise, it is no compromise for the artists. The whole point of megatexture is to free them from having to deal with some engine limitation. They don't have to be clever and find ways to hide the fact that everything is made of tiles, they just draw. And yes, this is a good thing, but a good thing that costs many gigabytes.
https://news.ycombinator.com/item?id=14904127
Take this laptop: spinning platter drive and 4GB of RAM. I'd be happy if it could do more with the same hardware, and I think that's the core of what we're talking about.
StarCraft analogy is far removed from real life user and business cases, all of which pay for the hardware with real money and time.
It seems to me that new languages prioritize quick iteration over effective machine operation. The easier a language is to write and interpret, the faster an outfit can churn out an application. The exponential computing power growth has been sufficient enough to absorb these collective "shortcuts". Thus, it is not being taken advantage of properly.
The CSCI/Engineering fields have become more of a gold rush than thoughtful trades. Boot camp management seeks profit, and trainees seek to quickly fill high paying jobs. It all culminates into this situation where code doesn't need to be clever and thought out - just created A.S.A.P to handle whatever trending niche market or "low-hanging fruit" there is. The work of these products get handled server side, where electrical costs for cooling is a fundamental expense.
Rust is comparably more coherent and elegantly designed.
I'm currently on a Mac and a PC. The Mac's CPU is at maybe 5% when I'm doing most things.
The PC is at 1%.
I'm using half the PC's memory and 3/4 of the Mac's.
These are no up to date, high memory or high performance machines.
Have a look at your own machine. Surely for most of us it's the same.
And that memory usage is mostly in one application - Chrome. The only bloat that hurts a bit now is web page bloat. And on a good connection this isn't an issue either.
It's also different on phones where application size and page size seems to matter more.
So, why are you using Blogger instead of emacs/vi/notepad to write a static HTML page?
Apparently the author seems to think that all that bloat DOES give him something, no?
//The Engineer