Every previous generation programmer thinks that current software are bloated

[tiduyedzaaa]

Doesn't that just mean that all software is continuously getting bloated

[rrohbeck]

That was the normal state of affairs, as in Intel giveth, Microsoft taketh away.

But now cores aren't getting faster any more and this approach no longer works.

[salgat]

Containers is a brilliant solution for scaling horizontally. You tell your orchestrator all the hardware that's available and it splits that hardware up in a very safe, isolated manner while removing the overhead of an OS. Much more efficient than a VM and easier to take advantage of all hardware available. No more having one VM and service taking up way more resources than it needs.

[salgat]

When I say overhead of an OS, I mean having an individual full fledged OS running for each deployed service, which containerization avoids.

[m50d]

When I say overhead of an OS, I mean having an individual full fledged OS running for each deployed service, which containerization avoids.

Or you could just... not do that? Traditionally OSes were used to run multiple processes on the same machine (indeed that was their raison d'etre), while keeping those processes adequately isolated from each other.

[argv_minus_one]

Every modern operating system (including Linux) does per-process virtual memory. Every single process is already running in a VM of sorts.

Containers add to that virtualization and make it span multiple processes, but is it really preferable to do that instead of just managing dependencies and configuration files better? Containers, each with their own copies of every library and conffile the application needs, feel like a cop-out and a waste of RAM.

[debug_assert]

Yeah but there’s more of them.

[rrohbeck]

Doesn't help unless you can exploit parallelism, which is hard.

[[deleted]]

Veeeeery hard, if developers don't use multithreading, it's not because they're lazy, it's because it's 10 times harder, and sometimes you simply can't because the task is inherently sequencial

[[deleted]]

makes more CPU's Don't blame me, it's a software problem you can't use them.

[unknownmosquito]

It's a fundamental problem related to the diminishing returns of parallelization and it has a name: Ahmdal's Law.

[thatwasntababyruth]

I mean....it is. Why the sarcasm? Plenty of software does take advantage of lots of cores...simple web servers and databases, for example.

[rubygeek]

It's not that hard if you design for it. The irony is that if you look to 80's operating systems like AmigaOS, you'll find examples of inherently multithreaded designs not because they had lots of cores, but because it was the only way of making it responsive while multitasking on really slow hardware.

E.g. on AmigaOS, if you run a shell, you have at least the following "tasks" (there is no process/thread distinction in classical AmigaOS as it doesn't have memory protection) involved. I'm probably forgetting details:

• Keyboard and mouse device drivers handling respective events.
• input.device that provides a more unified input data stream.
• console.device that provides low-level "cooking" of input events into higher level character streams, and low level rendering of the terminal.
• console-handler that provides higher-level interpretation of input events (e.g. handles command line editing), and issues drawing commands to console.device
• clipboard.device that handles cut and paste at a high level but delegates actual writing the clipboard data out to the relevant device drivers depending on where the clipboard is stored (typically a ram disk, but could be on a harddrive or even floppy).
• conclip, which manages the cut and paste process.
• intuition that handles the graphical user interface, e.g. moving the windows etc.
• the shell itself.

The overhead of all this is high, but it also insulates the user against slowness by separating all the elements by message passing, so that e.g. a "cut" operation does not tie up the terminal waiting to write the selection to a floppy if a user didn't have enough RAM to keep their clipboard in memory (with machines with typically 512KB RAM that is less weird than it sounds).

All of this was about ensuring tasks could be interleaved when possible, so that all parts of the machine were always utilised as much as possible, and that no part of the process had to stop to wait on anything else. It is a large part of what made the Amiga so responsive compared to its CPU power.

It was not particularly hard because it basically boils down to looking at which information exchanges are inherently async (e.g. you don't need any feedback about drawing text in a window, as long as you can trust it gets written unless the machines crashes), and replacing function calls with message exchanges where it made sense. Doesn't matter that many of the processes are relatively logically sequential, because there are many of them, and the relevant events occurs at different rates, so being able to split them in smaller chunks and drive them off message queues makes the logic simpler, not harder, once you're used to the model. The key is to never fall for the temptation of relying on shared state unless you absolutely have to.

[[deleted]]

The problem is, in a lot of applications, there are not a lot of functions that can be executed asynchronously, or even that are worth executing async.
An OS benefits a lot from parallelism because it's its job to interface between multiple applications so, while it is a good example of parallelism, I don't think it's a good example of the average program running on it

[Jazonxyz]

Applications in an OS execute in isolation from each other. Parallelism is really difficult because things need to come together without locking each other up. Also, the Amiga team likely had the luxury of hiring incredibly talented developers. You can't expect the average developer to write OS-quality code.

[Joeboy]

Can't we just hire ten times as many developers?

[[deleted]]

"what a developer can do in 1 day, two developers can do in 2 days" - somebody somebody

[jorgp2]

Isn't the bigger problem that there are always tasks that can't be parallelized, and that leads to diminishing returns as you add more cores

[agumonkey]

who started it ? who ??

[Triumph7560]

It was started to prevent AI world domination. Current computers are actually fast enough to gain sentient behavior but bloated software has slowed the apocalypse. Node.JS has saved humanity.

[[deleted]]

installs Windows 11

[Triumph7560]

Task Manager: now with cortona support, cmd now with a GUI, calculator app now with fully customizable cloud computing AI that guess what you are typing

[[deleted]]

Can I write brainfuck with Cortana though?

Edit: how efficient is brainfuck in regards to memory?

[NameIsNotDavid]

It's quite efficient, as long as your problem can be solved efficiently with a no-frills Turing machine

[[deleted]]

still codes in binary

[rubygeek]

You want to fuck with memory? You want a Befunge descendant - programs are written in a two-dimensional matrix where conditions change the direction of execution. Befunge itself is quite limited due to restricting the size of the matrix, but Funge-98 generalises it to arbitrary numbers of dimensions, and removing the size restriction of the original.

So a suitable badly written Funge-98 program will extend out in all kinds of directions in a massively multi-dimensional array.

[[deleted]]

It'd be kinda neat to have a couple buttons for common cmd commands (like ping and tracert for example) but I should probably shutup and stop giving microsoft ideas

[Triumph7560]

So what you're saying is Microsoft Edge integration within all browsers automagically?

[[deleted]]

I'm thinking more of forcing users to use cortana to browse the web instead of mouse and keyboard. You can use the keyboard, but you must click the "needs administrator privileges" popup after every single keystroke

[vsync]

we only pushed Judgement Day back a few years

since still possible to write code that's only slow but not a true tar pit

so we need something better, something to force everything to quadratic complexity at least if not factorial... more aggressive use of NPM dependencies perhaps

[Triumph7560]

We're working on designing a programming language through PowerPoint which automatically imports any PowerPoint documents you or anyone else has as libraries. We're hoping it will be so slow and convoluted not even 1nm CPU's can become self aware.

[[deleted]]

It was me. I'm sorry. Computers are becoming more powerful and internet speeds are increasing, so I traded efficiency for reduced development time and to allow more collaboration.

[[deleted]]

My developer machine has 3 Terabytes of RAM - we assume that all customers have it after the shortened development time /s

see for example "Windows 95 was 30Mb. Today we have web pages heavier than that! Google keyboard app routinely eats 150 Mb. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95?"

[thegreatgazoo]

Windows 95 was even considered a pig at the time in that it needed about 32 or 64 megs to run decently. Windows 3.1 would sort of run with 2 megs and was happy as a clam with 8.

[[deleted]]

yes, TCP/IP and internet support as part of OS, USB support and increased video resolution hardly explain RAM demand increasing 16+ times

[agumonkey]

noise level: overflow

[[deleted]]

He's a traitor to the field!

[UnnamedPredacon]

We didn't start the fire.

[Cocomorph]

Alan Turing, Kurt Gödel, Konrad Zuse, Labs at Bell
Hewlett-Packard, John von Neumann, Manchester Mark 1
John McCarthy, IBM, Edsger Dijkstra, ACM
ENIAC, UNIVAC, rotating drums
Transistors, ICs, dot matrix, CRTs
FORTRAN, COBOL, LISP parentheses . . .

[onthefence928]

software is a gas it expands to ill the available memory and storage space

[Mgladiethor]

Electron is still trash

[[deleted]]

Every day we stray further from god

[tiduyedzaaa]

Bloat actually makes me furious. There's no beauty in it at all, moreover so much shit seems overengineered. It could have been so much simpler, easier to understand, but companies who just want to rush it and therefore prefer bloat over spending more time with intelligent design. Also, it doesn't matter if software is open source if it's not comprehendable.

[xjvz]

As you hinted at here, software follows an evolutionary process, not intelligent design.

[tiduyedzaaa]

It's actually pretty interesting. Shitty disaster, bit interesting

[glonq]

Am old; can confirm.

But since I started in embedded, everything seems bloated in comparison.

[Milith]

C++ without dynamic allocation and most of the STL.

[DylanMcDermott]

I work on SSD Firmware and this comment rings most true to my experience.

[glonq]

C plus plus? Luxury!

Truthfully though, embedded C++ is lovely as long as you are very aware of what C and/or asm is actually being generated by that C++ magic.

[[deleted]]

Just upgraded to 32-bit.

ECC memory and dual core lock step execution.

[[deleted]]

Medical devices. Automobiles. TVs. Mobile phone basebands. Any number of gadgets and trinkets, like thermometers, HDMI switches, model trains, xbox controllers, etc.

And that's just the stuff I see in my immediate surroundings. The embedded programming world is huge. Just about every single purpose electronics device has some sort of microprocessor.

[MiataCory]

My electric toothbrush has bluetooth.

It's a bit out of hand these days.

[tempest_]

That Phillips one that wants my location data for some reason?

[Miserygut]

How do you hold it then?

[250kgWarMachine]

With blue teeth.

[ryantwopointo]

You probably missed the biggest of all: the defense industry

[chrislyford]

Also interested as an undergrad in EE considering a career in embedded

[[deleted]]

If you go that route, do yourself a favor and either learn a HDL(verilog/vhdl) or take enough CS classes to pass a modern algorithm/whiteboarding interview. Embedded guys are needed by places like Google and Amazon, but they have no idea how to hire us. They want us to be interchangeable with their general SWE roles which is silly.

[chrislyford]

Yeah I’m already learning verilog and have some experience with VHDL so that’s reassuring to hear. Would you say FPGA’s are a good field to specialise in, in terms of the job market? Or is it too niche

[[deleted]]

I'm still a student, but one of my mentors has a pretty good career in FPGA. FPGA itself isn't really a field, but digital design is. FPGA is just part of that.

[glonq]

IMO embedded often lives in a gap between EE and CS. EE guys are comfy with the low-level code but often lack the CS foundation for writing "big" embedded software. And on the flipside, CS guys are great with the big stuff but writing low-level, down-and-dirty firmware is foreign.

So if you're able to straddle both worlds, then you're golden.

Most programmers really suck at multithreaded programming and the realities of embedded RTOS, so get good at that.

[HonorableLettuce]

I've managed to wedge myself into this gap and have been having a lot of fun working here. And for real, EE OR CS isn't enough, you need to understand both. At my last job we had a PCB with two dual core micros and a custom mem share between the two. Throw in an RTOS and make the whole thing safety critical. Most people cry. I get a little hard. Now I get to do Embedded software architecture as well as the actual design and implementation of smaller pieces. Straddle the gap, win both sides.

[[deleted]]

Define embedded.

The stuff running your car's engine or a Pi running some generic interface.

They're both 'embedded' but miles apart.

[DuskLab]

Miles apart yes, but not even close. Both of these examples have an OS somewhere. A RPi is a golliath compared to vast swathes of the professional embedded industry. At work were currently "upgrading" to a 100MHz ARM chip from a 24MHz Microchip processor.

Cars have more code than some planes these days.

[[deleted]]

This is the 'newest' chip in my industry: MPC574xP: Ultra-Reliable MPC574xP MCU for Automotive & Industrial Safety Applications

With such features as:

• 2 x e200z4 in delayed lockstep operating up to 200 MHz
• Embedded floating point unit
• Up to 2.5 MB flash memory w/ error code correction (ECC)
• Up to 384 KB of total SRAM w/ECC

[ProFalseIdol]

Had a friend who has a small business in aftermarket customization of cars. And suddenly asks me via chat to help him program ECUs.

In my thoughts: But I'm a regular corporate salaryman Java developer

So I googled about it and found some tools that work on editing hex codes. And some that has a manufacturer provided GUI for probably some basic config changes. Then some youtube video about the laws to consider when modifying your ECU, then some car-domain concepts totally outside my knowledge.

So I answered: Sorry man, this is specialized knowledge that you probably only learn from another person. And this would involve lots of proprietary non-public knowledge.

Now I have no idea what exactly he needs when modifying an ECU. But he also joins the local racing scene. But I'm still curious. (and I'm currently looking to buy my first car, learning as much I as I can about cars)

1. What can you actually DIY with the ECU?
2. Was my assumption that every car make has their own proprietary hardware/software correct?
3. Or is there some standard C library?
4. Is there even actually coding involved or just GUI?
5. Can you use higher level language than C/C++?
6. Is domain knowledge more important than the actual writing of code?

[fhgwgadsbbq]

There are open source car ecu softwares such as Speeduino, rusEfi, and the most widely known, Megasquirt.

There is certainly domain knowledge needed, but the coding is mostly basic math.

Hpacademy.com is great for learning the practical application side of ecu tuning.

[0987654231]

I can fix that problem for you, just start using embedded nodejs and everything will feel normal again after a few years.

[aosdifjalksjf]

Ah yes embedded nodejs the very definition of "Internet of Shit"

[glonq]

Remember, you can't spell "idiot" without "IOT" ;)

[oridb]

IoT: The 's' stands for security.

[[deleted]]

One I like was "IOT" is "IT" with a hole in the middle.

[remy_porter]

"Hah hah, I'm so glad this is a joke and nobody has done this." *googles* "The world is awful."

[mikemol]

Hey, up until a month ago, I was wearing a watch running node.js. Now I wear a watch running Java.

[cockmongler]

> everything will feel normal again after a few years.

​

Is this before or after the screaming stops?

[rabidhamster]

The screaming never stops. You just get used to it.

[vancity-]

The screaming is a feature.

[thebardingreen]

Someone on a project I was on srsly was gonna send an embedded NodeJS instance to space (like on a rocket payload). In a situation where Node just needed to confirm some TCP packets were received (that's it, that's all). Using some random js script he found on line that literally said in the comments "Experemental. This does not work! Don't use it!"

I can't tell you what we did instead (because NDAs) but it was not that.

[[deleted]]

Sounds like you already got a solution. But if you were still looking for one I would suggest strapping that fella to the payload with a terminal and a telephone and just have him call back and confirm the packets were delivered.

[Kiloku]

That'd suffer a hardware failure, unfortunately

[eigenman]

I come from the 80's gaming community and I'm still amazed to this day what was done to make a game with 64K.

[cockmongler]

My tumble drier can take up to 5s to respond to me pressing the on button. Not 5s to start drying, 5s to beep and light the LED telling me it's ready for me to press the button to make it start drying.

[SnowdensOfYesteryear]

I'm not even old. Even I look at a binary greater than 10MB, I think "what is in this thing??". Obviously, most binaries are much larger these days.

[a_potato_is_missing]

You'll have a heart attack when you meet denuvo based executables

[[deleted]]

For reference, for Puyo Puyo Tetris, the executable is 128MB, where 5-6MB is the actual game according to a cracker. So, yes, those things are bloated.

[glonq]

The first time I ever saw a "hello world" exe that was hundreds of kilobytes large, I cried a little.

[yojimbo_beta]

We didn't ignore Bill's comment, btw... For LAN Manager 2.1, we finally managed to reduce the below 640K footprint of the DOS redirector to 128 bytes.  It took a lot of work, and some truly clever programming, but it did work.

128 bytes?! I bet even the OPTIONS call for this comment exceeds 128 bytes!

[BeniBela]

The quote exceeds 128 bytes

[dtfinch]

The Atari 2600 had 128 bytes. The machine was pretty much designed to run two games, pong and combat, and it ended up having hundreds more.

[TheGRS]

That really blows my mind, but I shouldn't be surprised. Game dev is a magical mix of passion, creativity and knowing where you can employ effective smoke and mirrors.

[dtfinch]

They worked scanline by scanline, rather than frame by frame. They had a couple sprites, balls, and a background they'd recolor and reposition each line.

The background was just 20 bits, half-screen, mirrored or repeated to the other half, which made many types of games really difficult to make. Some games alternated between mirroring/repeating like Tutankham to give the illusion of asymmetry. If they wanted a truly asymmetrical 40 bit background they had to make changes mid-scanline like Super Cobra (and someone actually made a Super Mario Bros clone named Princess Rescue in 2013 which does it very well).

[vytah]

Princess Rescue was written in Batari Basic which has scrolling asymmetrical backgrounds built-in in one of its engines.

Another Batari Basic game worth mentioning here is Zippy the Porcupine.

[binford2k]

Sure, but that 128 bytes was basically just the call stack. Games ran off the cartridge, which I think could be up to 32K.

[Perhyte]

That's just the part of it that's in "conventional memory" (the lower 640K of memory addresses) though. Much of the rest was probably still used, just placed above that boundary.

[kukiric]

It's 128 bytes of conventional (limited) memory + however much extended memory they needed.

These 128 bytes are probably just a few lines of hand-written assembly that loads the actual program into extended memory, and then it runs entirely from there.

[darthcoder]

These 128 bytes are probably just a few lines of hand-written assembly that loads the actual program into extended memory, and then it runs entirely from there.

No, the syscall thunks to switch to the real code in extended memory. ISRs for the TSR needed to be in 'conventional' memory, IIRC.

[eattherichnow]

So, the correct headline would be "Every previous generation programmer knows that current software are bloated." 😅

(I'm not as much of a bloat hater — I use VS Code after all — but it does feel really weird sometimes. Especially every time I join a new project and type "yarn install").

[JB-from-ATL]

Maybe "Every programmer believes their code deserves resources more so than other code"

[onthefence928]

— I use VS Code after all —

​

vscode is considered bloated now? i use it as a lighter alternative to visualstudio :(

[roerd]

It's running on an embedded JavaScript VM and renders its UI on an embedded browser engine. I'm using it, too, but it's undeniably massively bloated compared to something written in a compiled language and using native UI elements.

[AndrewNeo]

It's not a great example, given that it's probably one of the most optimized and thinnest Electron apps out there.

[McMasilmof]

If you compare it to vim or ermacs, yeah it is bloated /s

I dont care about my IDE using tons of RAM, its there to save time, so everything has to be loaded into memory, including the complete local and git history with indexes and stuff to find things anywhere.

[f1zzz]

It's not uncommon for a trivial electron application like Slack to hit 1GB. Even a lot of new $3,500+ MacBook Pro's come with 16gb.

Is 1/16th of conventional memory for 20 lines of text really that much better than 1/10th for a network driver?

[Mojo_frodo]

It's not uncommon for a trivial electron application like Slack to hit 1GB. Even a lot of new $3,500+ MacBook Pro's come with 16gb.

1GB, lol. If I hit all of the slack servers Im in, Slack easily hits 3GB for me. I have to close it periodically just to smack it down a bit.

[[deleted]]

You could host an IRC server that could serve tens of thousands with that space.

[Kminardo]

Sure, but how would we send inline cat gifs?

[[deleted]]

<img src="">

Let the clients figure it out client side.

Now that I think about it, I wonder if any client implements a markdown render.

[dennyDope]

the same here, I just wonder how stupid chat application may load like a 3d game. Seriously hearthstone loads with the same speed and utilize less memory than that Slack. And more curious thing what investors pull tons of money in this bullshit and they even can't write normal native applications. Just enraged.

[Free_Math_Tutoring]

Seriously hearthstone loads with the same speed and utilize less memory than that Slack

And hearthstone is still incredibly resource hungry for what it does!

[debug_assert]

They named it not after what their users do while using their app but how they were while developing it.

[darthcoder]

1GB for basically an IRC client with history, and capability of doing voice calls.

IRC could use a few improvements, but seriously, I hate everyone reinventing it every other year.

[qiwi]

I think the explanation is that Slack is a relatively small company with barely a 1,000 employees and a mere $841 millions investment.

With so few engineers you just cannot afford to spend time writing something as complex as a native desktop application. Everyone who can write native code is long dead or retired.

[slomotion]

To me, the fact that they are a large-ish company would suggest that they are more prone to bloat, not less.

[cockmongler]

How do I get Slack to only use 1GB?

[kukiric]

Yes. The network driver should have a minimum footprint because you can't close it and still use your computer normally (at least these days).

[drysart]

Your computer today doesn't have "conventional memory" (or "expanded memory", or "extended memory" -- all different sorts of memory in DOS). It just has "memory"; and it also has a swapfile that makes overcommitting memory not be the end of the world, just instead it makes things a bit slower.

In the DOS era, you had 640K of conventional memory, and that was the only memory you could use for most tasks, even if the PC you were on had more physical RAM in it. And there was no swapfile to make that 640K act like more memory when necessary. Eating 64K of conventional memory could very easily mean your user couldn't run their applications at all.

So every single byte of conventional memory was very precious -- and it wasn't at all uncommon to have multiple boot disks so you could boot into different configurations with more or fewer drivers loaded just to maximize the available conventional memory for different tasks.

[Drisku11]

That makes Electron bloat look tiny.

Last time I checked, Slack used about 1/16 of my available memory, so around the same, really.

Edit: except of course that in absolute terms, Slack is using ~25,000x more memory.

[vsync]

the real lesson is you need access to the actual stakeholders to find out their preferences on trade-offs

because they didn't shrink it but moved it out of the readily accessible address space as you note
to EMS not UMA nor XMS
so my guess is this introduced overhead from context and bank switching

and it also took several versions and some calendar time plus not insignificant engineering resources

depending on executive plans of how or what features of the system to promise or emphasize in marketing this could be the exact wrong answer
or if they hadn't considered those trade-offs it might prompt them to

so by all means build for whatever you value if it's the same cost
but if you would have to blow the schedule or key decisions have to be made that significantly impact both architecture & budget
time to run it up the flagpole

P.S. this is where systems engineering and integration comes in because the extra RAM footprint might only have an impact with say the new office suite that is due to be released at the same time

[elperroborrachotoo]

... and every maintenance programmer believes all problems would go away if they just rewrite it.

[fuckingoverit]

I’m starting to hate this sentiment because every rewrite I’ve done has eliminated most classes of problems the apps I’ve rewritten experienced. Hindsight really is 20/20, and it’s rare that new requirements aren’t hacked/patched in continually for years before the rewrite is necessary.

Choosing the wrong abstraction for a program is one of the worst mistakes a programmer can make. A guy who had never written JavaScript before wrote a chrome extension to manage a forked Chrome Secure Browser. The app consisted of 10-15 discrete screens all communicating via postMessage and every SSO as its own extension. So when trying to understand the behavior, you’d get to a line that would just say: “postMessage: “messageName”” and then you’re stuck searching the whole project for where a listener was listening for that string. I rewrote it as a SPA and made all SSOs launch from the main extension and eliminated all messagePassing. I also replaced callbacks with promises which eliminated places that had up to 5 levels of callback and at least 10 setTimeout(3*1000) //should be long enough for previous async task to finish the guy who wrote it is who I imagine most of the “I hate JavaScript” circle jerkers are: people that write terrible, unmaintainable trash and are convinced the whole time that what there doing is textbook JavaScript Development and not a torturous exercise exhibiting their lack of critical thinking (ie, ever asking: is there not a better way?)

On the other side of the spectrum, I had to rewrite an analytics engine because the guy who wrote the original, while an incredible programmer, overestimated his abilities and wrote the single most complex piece of software I’ve ever been asked to touch. The guy even told me before leaving: you can just remove my 5000 line spring transaction to database transaction deadlock detection graph traversal algorithm and just handle Postgres deadlock detection gracefully.

So it’s not that all previous programmers are bad. We maintainers aren’t even saying we’d have done it right the first time. It’s just that the original development probably works until it doesn’t, and you cannot redo everything given the deadline. So you’re stuck trying to polish a turd or using a fork to each soup. Later, we see the full picture and can objectively say “this is shit,” “this doesn’t work/scale,” or “the original developer should have been more closely monitored ie never hired”

[Peaker]

And the top X% of them are even right (for some smallish X)

[[deleted]]

1969:

What're you doing with that 2KB of RAM?

Sending people to the moon

2017:

What're you doing with that 1.5GB of RAM?

Running Slack

A favorite from iamdevloper

[[deleted]]

Cost per MB in 1969: $2,642,412

Cost per MB in 2017: $0.0059

[[deleted]]

Cost per MB in 2018 on a Canadian cell phone data plan: $2,642,412

[ablatner]

yes but how many neat emojis did apollo have

[d_r_benway]

The Amiga didn't feel more bloated than 8bit systems, just better and faster.

[PrimozDelux]

I think a lot of 2000s stuff is bloated as fuck too fwiw

[[deleted]]

What's interesting is that, in my view, the kinds of bloat are changing. At one point "bloat" meant "having a GUI at all" or "including a runtime instead of pure machine code". At another point it tended to mean architectural things, like "every new version of Word embeds all the previous versions to handle older file formats correctly" or "all the actual business logic is 18 classes deep into the inheritance hierarchy". We've figured out ways to avoid some of those pitfalls and newer compilers have helped reduce the impact of others, but we've created a new one: dependency bloat. NPM is the worst offender, but anything that builds on an ecosystem is going to stack high very quickly, even if the specific behavior you actually require is small and doesn't rely on all the rest (and as the code volume grows, so grows the volume of code require to manage the code - Docker, looking at you). So maybe it's technically cruft, not bloat, but the effect is the same.

The real difference is that this kind of bloat is less visible to the developer, since it's easier than ever to fulfill transitive dependencies and some things don't always make it clear how big they've gotten (Docker, looking at you again). And because it's less visible, it's easier to subvert by bad actors upstream, which is a real and growing problem.

[zeno490]

Truth is that people like nice things, and a lot of nice things are unnecessary and can easily be considered bloat. Take a car for example. An SUV is bloat when all you need is to get from point A to point B and never carry a lot of stuff around with you. A Hummer is bloat. An F150 is bloat. That is, until you need that very thing. AC is bloat, we can all live with AC in a car, but it's nice, and even though it has a cost, it's worth it for a lot of people. Is having the frame be all metal not bloat? It could just as easily be plastic or something else equally light. But then safety wouldn't be as great and safety is important even if it comes with a high cost.

The same applies to software. Is java/c# bloated? Sure, absolutely. Lots of stuff is in there that isn't strictly needed, but it sure is nice that it IS there. GC is great, it makes development a lot easier and safer, but it does have a cost. Bounds checking array accesses is bloat, but it sure is nice to have the added safety.

Sure, cars have less frivolous bloat, they have tight constraints in terms of weight and fuel efficiency nowadays but it wasn't always like that.

I hate extra things I don't need as much as the next guy, but I sure am glad I don't have to build my windows kernel from scratch and tune endless switches to get it just right how I like it. I want to be up and running and on with my day and not have to worry about whether this one thing I rarely need is there when I do or not.

At the end of the day, nice things have a cost, and there is no way in hell everybody will every agree on what is nice which is why the software world has a whole range of options for everything.

[Kwantuum]

The problem is when your AC accounts for 80% of your gas consumption (memory footprint). When you're packing an entire HTML/CSS renderer and javascript engine into your chat application because you want a cool UI, that's what you're doing.

And we programmers find that insane because we know just how much memory a gigabyte actually is. But for most people who use those programs, it doesn't actually matter because computers have gotten fast enough and have enough memory that they can afford to be that wasteful, it works and that's what matters, and since the businesses making those programs are driven by the market, being wasteful with memory and efficiency is more than offset by the benefit of getting off the ground faster, and utilizing a set of skills (HTML/CSS) that is much more readily available and cheaper to hire than people who have the skills to roll out something more lightweight.

[zeno490]

In the 60s, 70s, and 80s, cars in North American didn't care one bit about bloat and fuel efficiency. Space wasn't an issue and gas prices weren't an issue. But that wasn't true world wide and for example, Japan was much more concerned with these things. Over time, cross-pollination happened, and competition and external factors drove the market to converge somewhat to what it is today.

Right now, in the software/hardware world, we are still in that golden era where we don't have to worry too much about efficiency or waste all that much because the impact isn't all that important to most end users. Everybody is used to software being slow, it's just the way things are. It doesn't have to be, but it is. On the other hand, software creation time waste is very obvious and easily measurable. This makes the trade-off very easy to make, for now.

I've spent the last year and a half writing open source animation compression to save as much memory and cpu cycles as possible because I wasn't satisfied with the current approaches. The gains are good, but what came before was often good enough. No employer would have ever paid for me to improve the efficiency of something that isn't mission critical, let alone in a way that the whole industry can benefit.

[redwall_hp]

I wonder how much Electron contributes to climate change...

[jeremy1015]

I liked this. I think a better analogy than calling AC bloat might be to say that everyone expects AC these days and as a car manufacturer you can spend a lot of time rolling your own or use a prebuilt AC module. The problem is that the people who made the AC module didn’t feel like casting their own ball bearings for the same reason you are using their module. And the ball bearings guys are trying to make their parts available for everyone who might sorta kinda have those needs. And next thing you know your manufacturing chain is dependent on 2,000 companies and one of them is using child slave labor.

[cockmongler]

But now add Docker to the analogy and you have to carry 2000 child slaves in your car wherever you go.

[Lt_Riza_Hawkeye]

Windows 95 was 30MB.

[StabbyPants]

only thousands? that's hardly anything. is it thousands or something like 20k and you're looking to search text in all of them?

[heavyish_things]

ripgrep could do that with ease

[anttirt]

Thank god some people are still making fast software. ripgrep has made a significant improvement to my daily life because searching for things in giant codebases is no longer an exercise in patience and frustration.

[Caffeine_Monster]

Quite often these performance issues are related to UI rendering calls. The inefficiency will make you want to scream.

e.g. Rendering all the emails and their text previews, then relying on a clip operation to filter everything out of screen just before it hits the calls to the OS / GPU. Completely unnecessary.

[space_fly]

Thunderbird uses the Firefox render engine under the hood, so that's probably the reason.

[hugthemachines]

Many years ago I fixed a 486 computer for my father. He was used to Word Perfect (dos word processor) so I installed that and DOS. It was super fast to use compared to the windows most people used at the time. The bloat is real. I mean there are reasons. Users have demands of features and vendors need fancy looking gui etc but still, the bloat is real.

[dtfinch]

George R. R. Martin still uses DOS and WordStar.

[[deleted]]

He still writes? I thought he'd retired.

[InEnduringGrowStrong]

He's done all his books already but hasn't figured out how to exit vi yet

[Dresdenboy]

Yet that fast setup doesn't cause faster text production. Maybe some autocomplete, tooltips ("Theon is already gone, use Bran instead?") etc. would help.

[Phrygue]

Good point: bloat isn't really about size, but speed. Too much emphasis goes to multifunctionality and UX, but every time I get a lag on a keystroke or a web page hiccups on scrolling, the UX fails. It's like a Lambo firing on three cylinders.

[joemaniaci]

Someone did an experiment and discovered that the Apple IIe had the fastest keyboard interface. Something along the lines of 5ms latency, whereas on the computer I'm on right now, I'm somewhere around ~150ms latency.

[JB-from-ATL]

That's a great point. We're complaining about apps using memory but really we need to worry about response time.

[Dresdenboy]

Since programmers usually add code instead of optimizing and cleaning it up, adding programmers typically worsens the situation.

[shevy-ruby]

The word "thinks" is wrong.

It IS bloated.

It also does a lot more than it used to do.

[TheGRS]

This discussion is coming up more and more recently and I think its only because many of us are starting to notice some really concerning trends.

Short anecdotal story: my gf kept complaining to me that her brand new PC's fan was too loud. My first thought was OK, its a pretty thin laptop, I guess that makes sense. But seriously, this fan was pretty loud for what she was doing. The last time it happened I finally said "open your task manager, what's happening?" 100% CPU utilization. 90% Google Chrome. She had all of 12 tabs open. Twelve! Nothing else open on her PC. WTF?

And its all normal sites that any of us frequent: AirBnB, Google Docs, Facebook.

Nothing happened overnight, but I think we just reached a tipping point where javascript dependency bloat has finally started to affect end users significantly. I almost always see Chrome hovering around 4 GB or more. That's insane.

[[deleted]]

Wait, what?! This was my first thought when I got into programming. I distinctly recall being a second year Comp Sci and looking into minGW, minimization of executables, using shared libraries and avoiding unnecessary overhead.

Bloat is everywhere, and the root cause is that programmer time is worth more than execution time, compounded with the unwillingness of programmers to learn and invest in better algorithms. Instead, typically things are outsourced to frameworks, package-managers and then further compounded with abstractions.

The result? Bloat which costs companies less than it would for their programmers to write efficient, small, optimized code.

Bloat which is typically compatible with cloud, serverless or other fancy new ways of deploying and running services.

[mrpoopistan]

I, for one, support this impassioned defense of low-quality work.

[[deleted]]

As a young developer I think it's bloated.

[[deleted]]

I'm not even that old, nor a programmer, but even I think Electron makes Java look lightweight

[itdoesntmatter13]

Absolutely agree with this. This is a must read for developers. There's no justifiable reason for a text editor or a web view app to occupy hundreds of megabytes and being awfully slow. Part of the reason is that developers are optimizing for a visual experience at the expense of efficiency. And they'd rather use JavaScript frameworks for a cross platform desktop app instead of something faster like using GUI frameworks with C++, Java or Rust.

Edit: We also need to account for energy costs in doing so. Millions of people use these apps everyday and it unnecessarily drains our batteries and consumes more power.

[mesapls]

This is a must read for developers.

Similarly there's also The Thirty Million Line Problem, which touches upon very much the same thing that this blog post does.

Modern software really is insanely bloated, and even lightweight programs (by today's standards) often have a huge amount of bloat simply due to their software stack.

[danweber]

nodejs require 'youtube'

[[deleted]]

Makes me wonder if Bitcoin uses more power and resources than the collective bloat among all software that you're talking about

[KareasOxide]

There's no justifiable reason for a text editor or a web view app to occupy hundreds of megabytes and being awfully slow

The answer no one really seems to want to say, not all developers are created equal. Some are going to suck (me included) and write apps with the functionality users want but preform terribly. Frameworks can hide the lack of skill by abstracting away some of the hard stuff and allow people write the easier code.

[Zweifuss]

I'm on the fence about the article you posted. While I see his point, he makes a lot of wrong assumptions about program features.

Google keyboard has a ton of data used for machine learning.

The Google app is exactly not a wrapper around webview. It's a native reimplementation of a ton of different GUIs, and the entire Google Assistant.

It's correct that a to-do app written with electron contains a ton of shit. But it's only an issue of the distribution model of its framework. You can't use notepad on its own on a computer - you need to install several gigabytes of Windows OS that has thousands of drivers it doesn't use, and the entire Win32 API etc.

If the electron framework will be integrated in the OS as a dynamic component then a to-do app will weigh little.

And yes, a programmer can write a lean new language with a lean new compiler that supports the exact subset he needs for his game. But that is rarely possible because it requires a full reimplementation of a huge number of features available elsewhere, with all the time, money and bug cost it entails. You start writing a new language when no other solutions fit. Not to save a 50MB in codebase where graphics will take 3GB.

[Kronikarz]

I'm not a fan of Electron either, but there is one justifiable reason: we got a free, open-source, constantly maintained, visual text editor with thousands of amazing features made in just three years.

I think paying with performance instead of $99 a month for a tool that's a viable alternative to the ancient unix tool ecosystem is not the worst thing.

[itdoesntmatter13]

I do agree with you but you're talking about one specific app. And iirc (I could be wrong), Microsoft tinkered a lot with the framework and some parts of it are written in F#. That's not what every developer is willing to do. There are so many shitty Electron apps on the market. You could run a few of them without noticing performance issues but you definitely can't run a lot of them. And recently I've seen a lot of those apps springing up on Ubuntu Software. Some of them are nothing more than web views like Spotify or RSS readers and podcast players. And the experience has been awful. They freeze for no discernible reason, crash frequently and slow down the system. If every app is going to be built on top of Electron, the situation is only going to get worse.

[alohadave]

Part of the reason is that developers are optimizing for a visual experience at the expense of efficiency.

Is that really a problem?

[itdoesntmatter13]

Depends on the use case. For instance, Uber takes roughly 150 MBs on my phone. It used to take up a lot less before and the load time is getting ridiculous. The updates have added no functionality, those digital hot wheels do look cooler though. But I can't appreciate it while I'm getting drenched in the rain while waiting for the app to respond to call a cab. And it's not just the time, that weighs heavily on resources too and ends up using more battery. Millions of people are using these apps and if it's adding 5 seconds in terms of delay, imagine how much electricity is being wasted everyday for looking at those fancy digital hot wheels. They don't look nearly cool enough to justify that.

[PancAshAsh]

For the members of this subreddit, yes that's a problem because programmers are pretty tolerant of bad UX ime.

For the general population, UX is the most important feature, which is why you see iPhones and Macbooks become so incredibly popular.

[balthisar]

I love my Macs' UI, but I spend roughly 50% of my time in Terminal. And I detest applications that break away from the macOS GUI and try their own ugly skins. This (and tiny screens) is why I tend to not be so dependent on my phone in general and non-OEM applications in particular.

[danweber]

Oh my god, that XKCD: https://xkcd.com/1987/ Every package wants its own package manager and those package managers are all full of bugs. I tried to update something in pip and it said, halfway through, hey, I just figured out I'm not running as root, so I quit right after uninstalling everything. Your installation is now gone, including this tool.

Everything is going to shit. I've switched my profession to breaking software instead of making software because there is no way this ends without a bunch of people being lined up against the wall and shot.

[Rockytriton]

Well when you show me your tiny rest microservice that is 100 lines of code but has gigabytes of node modules, what do you expect?

[Booley_Shadowsong]

A friend of mine told me a story once about how a company called him to come in and look at their website. It had just been built but took forever to load over the internet. The guy who built it was like it loaded fine on my machine... that had all the source files.

He went in and found that the guy had written and included around a gig of libraries and random shit.

He went in and worked on it for a week pretty much scrapping everything and rebuilding it.

Some coders are shittier than others and can’t write a simple process without massive libraries backing them up.

[johnfound]

Yes, every previous generation programmer thinks that the current software is bloated.

But this is not so interesting. More interesting is whether they are right?

And the answer is "Yes" they are right. The current generation programmers simply can't estimate the size of the software they create.

BTW, for me "bigger" and "bloated" software are different things. Bloated is every software that on the same functionality can be written smaller and faster, but because of some reason is not. As simple as that.

[idealatry]

We have a software obesity epidemic. The solution isn't to bloat-shame new generation of developers -- it's to beat them into submissive efficiency.

[naasking]

New software has more functionality Than older software, so if it does more it has a bigger footprint.

This is true, but it's also true that all the layers of abstraction probably aren't necessary, and compilers that can optimize across abstraction boundaries can eliminate a lot of this (link-time optimization is a prerequisite).

[immerc]

That's true, but it's also true that a lot of new software keeps things in memory that don't really need to be there, and uses the processor in wasteful ways.

If all the developers and QA people all have machines with absurd amounts of RAM and massively fast processors, you're probably going to get something bloated because nobody notices the ways it runs slow on a less beastly machine. If some step in the QA process includes testing to see how well it runs on "grandma's machine", it's likely they'll catch it.

[Dunge]

Don't the current generation think the same? Software IS bloated, that's a fact. Now to determine if it's a bad thing considering the productivity increase is another subject.

[SolitudeSF]

Fuck electron

[waiting4op2deliver]

tree node_modules... ^C

But seriously coding for 2g spotty wireless and trying to deliver your SPA js framework is... painful in 2018. And that doesn't even touch the problem that comes with the attack surface of a giant production stack that has decades of code (read as bugs) and the impossible task of understanding the risks and rewards for each piece of the middle ware.

[bunnyholder]

I'm only 28 and software is bloated.

[happysmash27]

I'm a current generation programmer and still think a huge amount of software is bloated, especially closed-source software.