Why Slower Computers Were Faster
Вставка
- Опубліковано 14 сер 2020
- In this video I discuss why computers were faster when they were slower, because with high end hardware, soy devs aren't going to do the low level work that used to be mandatory for developing applications.
₿💰💵💲Help Support the Channel by Donating Crypto💲💵💰₿
Bitcoin
3MMKHXPQrGHEsmdHaAGD59FWhKFGeUsAxV
Ethereum
0xeA4DA3F9BAb091Eb86921CA6E41712438f4E5079
Litecoin
MBfrxLJMuw26hbVi2MjCVDFkkExz8rYvUF
Dash
Xh9PXPEy5RoLJgFDGYCDjrbXdjshMaYerz
Zcash
t1aWtU5SBpxuUWBSwDKy4gTkT2T1ZwtFvrr
Chainlink
0x0f7f21D267d2C9dbae17fd8c20012eFEA3678F14
Bitcoin Cash
qz2st00dtu9e79zrq5wshsgaxsjw299n7c69th8ryp
Etherum Classic
0xeA641e59913960f578ad39A6B4d02051A5556BfC
USD Coin
0x0B045f743A693b225630862a3464B52fefE79FdB
Subscribe to my UA-cam channel goo.gl/9U10Wz
and be sure to click that notification bell so you know when new videos are released. - Наука та технологія
Yes I need 5 GB of node modules on my static blog, what made you ask?
That's the exact reason why I'm creating my static site generator in C++. At worst it'll be in 100 Megabytes, if I code it badly but won't be as aggravating as what you've said about Node modules.
@peter schwarz I used Win 10 and I understand your point, JS isn't the one to be blamed here but soydevs who would just add a ton of dependencies in the name of convenience for something minial where coding that one self would've been a better solution.
use pnpm it helps a little bit
Oh god. That was painful to read. Such an abomination of an idea.
Fecking blogs don’t even need JS. Like, at all. Jekyll exists for a goddamn reason. If any field in tech needs a turn-around to decrease bloat, it’s webdev. Assholes making shit use of everyone’s networks. Fibre doesn’t grow on trees, dammit.
@Epic Doggerino Not at all! Just that you should only need to use half of that drive's space.
Did you get those muscles by writing in C?
That's the Chad way. 10 years of enlightenment with C development💪
No, by using musl instead of glibc.
you just know he frequents /fit/
@@johnyoutube4073 Based on nothing. Just based.
No, you learn to not be a soydev by getting those muscles, then you learn C.
This video plays in my head whenever a tiny 2D game takes up 3GB of storage because Unity.
Fuck unity. Seriously. I have yet to see a unity game that doesn't run like shit compared to what it does.
@@SuperObamaladen FOSS alternative angel is godot :D
Use godot
not everyone who wants to make a game wants to put in the development time to make their own engine, I think it's good to have the freedom of design that tools like Unity provide. You can always write your game in assembly if you want to
@@SuperObamaladenAvelog's Mouse Simulator. I unironically use it to test the 3D acceleration on any android device I come across.
"Software slows down faster than hardware speeds up," called Wirth's law, and coined by Nicklaus Wirth, Swiss computer scientist who developed Pascal as well as other programming languages. In his 1995 article "A Plea for Lean Software"
I downloaded the article after I read this comment. It was such a good read
LOL--Wirth's law. It's just the Jevon's paradox.
Lol, while OP says people not using C is the reason for bad software, Wirth says people using C is the reason for bad software.
Have to say, I agree more with Wirth :D C is horrible. Use Rust where you can.
@@aheendwhz1 Rust isn't the answer. I predicted they would have the problems they are now having back when Rust came out. The problem is they are trying to solve issues without fully understanding the cause of the problem. There's a whole host of reasons why you get bugs with software in C, but the Rust team think it's only a few things they focus on. Funnily enough, these have been addressed already with languages like Ada (even Pascal addressed some). But hey rent seekers gonna rent seek
@@telesniper2 I don't think it was Rust's intention to eliminate all bugs, but just the ones they knew they could solve (memory and type related ones).
What are the problems they currently have? Which of their problems are addressed in Ada or Pascal? (Are they also addressed in Oberon, which Wirth suggests as a replacement for C?)
The things that were done to make old games possible are pretty damn insane.
There’s a channel called “Coding Secrets”. The optimization shown there is tasty.
Yes take a look at a recent video talking about how Resident evil 2 (a 1.2 GB game normally) was put on a 64 MB cartridge for the N64 back in the day. Granted most of this is likely due to crazy compression, but still it is super advanced stuff.
And the stuff that developers can get away with in today's games is even more insane
@dustboxednorth 60gb++ game size for 5 hour long gameplay
@dustboxednorth Pretty sure most of the size comes from the art assets. Look at the binaries and those are going to be pretty small as you suggested, but the data size isn't in the code. The vast majority of the size is going to come from all of the textures that get used. Even the models are pretty small if the file format they are stored in isn't bloated.
The answer is: Electron did not exist.
Can we just nuke electron
One day the OS will just be a thin wrapper over a web browser
@@gum8191 Chrome OS?
I know it's a joke, but Electron is just one step of many that have occured over time. First there was machine code, then there was assembler, then higher level languages, then even higher level languages, then librararies, then dependencies, then redistributables and APIs, then engines, etc. things have continually gotten more bloated.
@@MsHojat that's right. The problem is that everybody uses Electron to write apps so simple that they could have been done with Qt for the same amount of time. They would use 5-6x less RAM and CPU. Skype, Discord, Gitter, Spotify - these clients use up to 1 Gb of RAM altogether. Have you seen their GUI? It is very simple.. Maybe not Spotify, but others definetly.
C is still taught in electrical engineering though. EE bois still keeping the flame alive programming for 1kb flash microcontrollers running on 8MHz
You know it! The developer time hunting down random bugs is hell though... It does teach you to really break down the process to be as simple as possible, but not any simpler. Can't do micro-python here!
I very, very vividly remember hunting down a wireless transmission bug spending basically an entire day right before the assignment was due fixing it. I also didn't know that literally everybody else ran into something similar and almost nobody actually finished the assignment. It was a major lol moment for me.
Fast forward to now, I probably couldn't write a hello world program in C without looking some things up. It's all python and javascript now.
this is the way. I'm an embedded software engineer and while in general I think everyone would benefit from better code, there's usually not a need for it. And that's a good thing, because access to education and resources to learn are huge barriers of entry for most people. Use what's available. If you can climb, climb, but don't feel bad if you can't.
we learnt assembly during my electronics course
I did CE and EE also, but at my university even computer science students were required to take a course in assembly and C. So it's definitely being taught still, but whether those people are competent in C is a completely different story.
Actually Gold, Silver and Crystal had pretty much double the content of Red, Blue and Yellow. It had the entire world and all of the trainers and gyms of the first games thrown in as a part of the postgame in addition to its new stuff.
The devs of Gold, Silver and Crystal during development were having a lot of trouble with storage space and were unable to fit the base game on the cartridge, and after Satoru Iwata stepped in and helped them out the data compression was so good that they were able to fit in the entire world of the last game in addition to the base game, lol
That just proves his point even more lol. They had to bring in the legacy developer that could write good code
@@Tinfoiltomcat Important to note that a lot of the filesize probably wasn't taken up by code at all. Much of it was likely taken up by images and sound files. That's been my experience, but I'm not sure if it holds true in this case.
Exactly a modern dev wouldn't even bother to compress stuff. "The Garbage Collector will handle it."
@@fauxio5063 More beautiful elegance. There are about 40 sound effects for pokemon roars. They then mix, match, and adjust them to made 151. ua-cam.com/video/gDLpbFXnpeY/v-deo.html
"Black Luke Smith complains about his pokemon emulation folder getting bigger".
Black Luke xd Boomer rant time yeahh. When is he going to take his camera for a walk/drive?
Black Luke Smith rants in the dorm.
I'm waiting for the woods saga
"black"
It's a deepfake. We must not make assumptions about his looks.
audio says greybeard, video disagrees
It's nice to see some muscle in the IT community
he literally looks like chad
@@Maebbie I think you mean Tyrone 😅
Cute anime girl, will use it as my profile picture,
One push up per file compiled and uses Gentoo, i guess.
I've always thought he'd look like a ginger guy with glasses
To back up what you said, I'm the ONLY person in my company that has ever written a program in assembly. I remember on the PS1 having to store fields in a Bit field to fit everything into save data. Now, "let's give them a 10 GB update because we don't care"
Imagine how powerful computers would be if old school guys were squeezing every last bit of performance out of these new machines.
I write in asm too for fun (6502 atm) but really I don't think modern scope games would really even be possible if you wrote everything like those old days. You need to pick the right battles and find a good balance.
Rollercoaster tycoon was written in assembly
As a developer myself (who also likes low level stuff) i have to take some issue with whats said here.
Most performance heavy Software like Videogames and Server Applications are still written in c++ explicityl for the performance benefits and possibilities for optimization.
But size is by far not everything and not often of the most concern. For example if you are working on a huge project like a game engine it is very difficult to keep an overview over the thousands of files and classes in there. Developers may sacrifice some controll over memory management and use programming languages that simplify code so that it becomes more readable, extendable and maintainable. That is something very important because if your code base is huge you may forget how some things work when you revisit them to fix bugs or add features.
Optimized and low level code is extremely hard to read and understand. So it can slow down the development enormously if your code is obfuscated and hard to understand. And develompent time costs a lot of money.
So at some level of complexity you usually rather write high level code and let the compiler figure out the optimization by itself. Acutally trying to optimize your code better than a sophisticated modern compiler is very difficult. In most cases you choose a balance between readablity and performance by generally writing simple code and then optimizing at the performance critical locations afterwards.
Also another reason for more memory usage is performance increases. Many data structures are either optimal for performance i.e. reading/accessing data or inserting/deleting data or offer more space efficiency. Faster data structures and algorithms usually need some memory overhead to acomplish this benefit. On a modern system even a triple A videogame has more than enough ram to maybe rather use 30% more memory and in exchange achieve a significant performance increase. Nowadays the bottleneck is more on processing power than memory (ram and drive). So development style changed accordingly.
Also wich Language you use also depends on the application. There is no one style fits all solution.
Every language has its cases where its more usefull than the alternatives.
Generally i agree that some systems are getting really bloated nowadays like all that unnessecary crap thats on your phone or windows. But that doesnt mean every developer just doesnt give a shit anymore and doesnt know how to code.
I agree with your take. Performance is always on my mind during development, but less so, than maintainability.
About focus on web development - it is done because supporting myriads of platforms natively in form of app is too expensive.
Honestly was going to write the same thing. The older games back in the day also had smaller teams. Nowadays, as the demand for graphics, open world, and no loading screens evolves, it's simply impossible for hundreds of humans to foresee everything with their code in a financially feasible way. If we developers had the time to make everything super optimized (also ignoring the fact that your code/idea might get scrapped next week) we would all be writing in assembly. Bloat is real, but as with many things there is more nuance.
Yeah! And this also very much applies to smaller software and games - Optimization won’t have any (compared to the amout people have) significant effect on storage anyways so why should I sacrifice other things for unnecessary optimization?
(I know that some of this was already in the original comment, just what I’m thinking)
We can't forget to mention that using object oriented programming inherently forces bloat yet dominates the industry atm even in companies that use languages such as c++ which were not designed around that paradigm
@@Ho1yhe11 Honest question, if oop is bad what is the alternative? Functional and procedural programming are not perfect either
"You've got soy devs who aren't taking the time -- they don't even touch C" That slayed me.
Same here. Soy dev
facts
How dear he. Python BE here
Also who cares about c if I have rust and zig
All these soy Devs won't even touch machine code
"Millennial rants about his pokemon games getting heavier".
Well built millennial
@@jerf5038 jep. A well built.
@@Aemilindore Unlike those new pokemon games
@@LowIiet Quentin
they were talking about him...
millenial? hahaha , us millenials had cutting edge software running on windows xp that trumps current memory bloated skriptkiddie trash your using on a daily basis . 81we are running on pentium processors.you gen z'ers rocking ur intel i9's and your 600gb dexicated ram's, what a shame you have all that computer power and you cant get half the stuff done that we could . sure your games of your gen look pretty but your getting sold unfinished betas😂 or unmemorable games. and your actually buying the stuff..... ahh how much simpler it was back in the day😂 *cough*[ windows 10 is a trash os] *cough*
I used C as my language of choice during my computer graphics and compilers classes. Must say that while I did learn a lot and fell in love with the language, it was not good for the heart. I had to learn to code really fast to keep up with my peers and had to dedicate A LOT of my free time to really get things done. Do i regret it? Yes. Would I do it again? Definitely not. That year was really stressful, yet I continued because I tried to proof to myself I could do it. Barely managed a passing grade at the end. Machines and Software were created to make our lives easier, devs included, If its really about performance and optimization, you gotta look at the bigger picture, optimize your life, maybe instead of learning C, I could have used that time to hit the gym and get chad arms like mr outlaw.
The thing is that schools and unis don't care if you really understand what you had to learn or if you acquired the skills that you should have. That's why learning C might've looked for you like unnecessary struggle and effort, but imho it's just the system that's totally fucked up XD
well i consider easy to code>Performence and try to made something that best of both world, well its still early though since due to my school that now had more exam since i was Literally in my Last year of High school soo cant dedicate my time to do some coding again like how i do back in 1st and 2nd grade
@@piotropoka227 They are reflections of the market. It's how code is made by big businesses that creates this problem, not how universities teach it.
it doesn't matter anyway
@@ekki1993 I'm not sure which big businesses you're talking about. I understand that small or open source companies need to have wide and deep knowledge in order to compete with already existing products, but it doesn't mean that job in company like Google or Apple is easy either. I'm not sure how it is about Facebook or Netflix, though from what I know it's not as unpleasant as people think. Maybe Microsoft is something you were talking about, since Windows is... let's just say it's inferior to Linux XDDD
Correction: From my experience with game dev, the vast majority of storage space is taken up by data (video, textures, sound files, models, roughly in that order) and NOT code.
Code has it's own issues sure, but it would be silly not to use up as much of that storage space as possible if you're dealing with cartridges - you don't have to nurf the art as much if you're under, just don't go over.
Another thing I've noticed with older games is the artists had to be a lot more technically minded to fit within the hardware limitations. For example, on older computers it was only possible to display 2 colors within an 8x8 field of pixels, so the artists had to design their art to keep differently colored elements from crossing those 8x8 tiles. Or, structuring sprites so that parts could be swapped out (also 8x8 tiles) without needing a whole new sprite. Or having level designers that can exploit symmetry to save space.
Modern game artists tend to not think this way - they work without limits in a sculpting program and then bring it down under a certain polygon budget. In a team of 7 artists I worked with, only one really seemed to have a talent for thinking in terms of using textures extremely efficiently (e.g. clever reuse of textures for repeated elements).
All that data can actually be compressed quite a bit, but that required compression/decompression algorithms which can make things a bit slower.
I'm skeptical that the bloat comes from code though, at least in games. John Carmack once noted that the ENTIRE Doom 1 game could fit into a single texture on Doom 3. The main growth in games comes from assets.
true texture files of new games are huge ;-)
This
ARK is a perfect example of terrible game coding
@@saltananda3227 true
@@vasopel and absolutely needless
As a geek myself and a pharmacist for profession, I really laughed at the Mental Outlaw explanation and people here ranting about languages, when they fail to see the bigger picture (which people working in other areas such as healthcare do see), which is: the human factor.
Companies want to have replaceable people and need things as standardized as possible so, at a moment notice, they can fire a coder and hire a new one without losing too much productivity. I know because the same happens at clinics and pharmacies with pharmacy technicians and even pharmacists.
When you factor the costs of having an extremely optimized code that takes time to develop (which is expensive) versus having a bloated app that can be written in practically no time at all, giving you an advantage over your competitor (in other fields than IT), you choose the bloated app with the "soycoder" because it is cheap and saves you money.
Bloated code also needs the least time in training a new guy to maintain it if the "soycoder" goes rogue and/or violates some bullshit NDA.
Heck, at the pharmacy where I used to work, they still use a DB and client software WRITTEN IN THE 90s IN VISUAL FOXPRO!!! It's slow, poorly (if anything) optimized, clunky, and only works in 32-bit mode. HOWEVER, its still used because the guy who maintains it still works at the company and now is too expensive to fire, and also because using a newer solution would require to re-train about 500 pharmacists and lose sales (something these pharmacy chain stores will NEVER do).
TL;DR: Code is not the issue. Time vs money & user-training vs money is.
So what your telling me is the problem is that we have an entire economic system (capitalism) that isn’t just bad morally, but positively holds back the development of humanity, because profit is still its primary aim?
Got it.
That's a way to put it. The cost of soycoder's abstractions
@Deborah Hearne it depends. If a good programmer charges $10K per-month for good code and mantaining it, vs another guy that charges $2k per-month for bloated code that gives the enterprise a solution fast, damn all the rest, then that company will choose the $2k guy, simply because of money and costs.
I've seen it way too many times in my life and in different fields (healthcare, distribution, retail, government, etc) to know that companies outside the IT realm don't really care about code and only about the solution and how much it costs them.
Dev here. The pharmacist man speaks the truth.
Gotta fully modularize your company!
One reason for using high level languages and frameworks from the business point of view is that it allows for a larger pool of developers to write working code and speeds up development by allowing one to not micromanage certain details that might not be relevant. I certainly agree with the predicament that having no knowledge of bedrock languages and technologies like C is not a good thing, however just bashing high level ones is not the way to go
Bashing high level ones IS the way to go. Because eventually, for later generations of devs, even the toy languages that people use these days will be too "difficult". Which they might then try to compensate with better hardware. This is not sustainable.
You're defending big business chasing quick money over a healthier digital ecosystem. They don't care about you or their programmers, but in the 90s they were forced to care, the limitations didn't allow them to cut corners.
@@lucv2234 Not at all, if the program is run a hundred times on a billion computers e.g. Windows the soydev trash code will burden enough people to compensate for the devs having a bed of roses as they ruin their software. Not to mention the cost of hardware being used to compensate for the incompetence.
You also don't need a new proprietary app to do the exact same thing the previous 20 apps did.
I program machines for a living and that remembers me of some thing I see when changing the software on machines that are from the 90s.
Back then controllers had some kbytes of memory for the code, some of them haven’t had storage at all, they just saved the code in ram and had a battery so they don’t loose it when there is a black out. (So pretty puny Controllers you get the idea) when they had non volatile memory it was flash memory which was really expensive back then.
I often stumble upon things in that old code where I wonder why they heck they did it that way because I certainly would do it differently.
For example:
In the Assembly Language you can program those controllers the usual way to increment an integer is to load it from memory into one of the to AKKU registers of the CPU, load a 1 into the other register, add them together and transfer the value into memory again.
So four instructions.
But instead you can save two instructions on even numbers. Because on even numbers the last bit in the integer is always 0. so you can just increment by changing the last bit into a 1. to do that you can just change the bit in memory into a 1. for this you only need two lines of code, one that loads a true into a special register for the results of logical operations and one that loads that into the memory location of that last bit of the integer.
In reality the processor needs to do more , but since those processors are CISC you only need those two lines of code. Since speed is not as important in machinery as saving storage was, it was worth doing that.
But there is a problem with that approach and this is also the reason why I think you are not right when you say we should go back to working this way.
And the reason is code maintainability and code reuseability.
Code that’s written with those hardware hacks is really hard to read and hard to unterstand. I often end up breaking my head over some things where people came up with some crazy hack and didn’t do things the usual expected way in order so save a few lines of code.
With that kind of code you need a single genius to write it, and it can often only be maintained properly by that genius. But even a geniuses day is only 24 hours long and the number of geniuses in the world is limited, which ultimately means you would end up with fewer software that can to fewer things.
Software development became easier over the last decades, to a point where people don’t need to be genius to write software, being a bit smart it enough today. And of course this means not every piece of code is going to be extremely optimized and perfect, but the alternative is not having software at all in most cases.
Dude, you hit the nail on the head. Especially your last paragraph. Having any software is better than having no software, and maintainability wins over writing hacky C code. Bravo!
Good read. Interesting point you got with easier software engineering creating lower barriers to entry for people, which in turn makes software more abundant!
I had a professor who spent his 80's and 90's optimizing assembly code generated by gcc as his job.
Sounds like a shit way to die
@@Yarin5879 he probably contributed to what we have and still use today. we dream that our hard work and passion will live on.
I don't really think Pokemon got super bloated until X and Y. I mean look at Black and White, all the pokemon had full animations for the battle sprites with 649 unique Pokemon, and a much higher quality soundfont than Diamond and Pearl. Sword and Shield were just awful though, they were 10 GB with unnecessary repeating assets and less than 500 unique Pokemon in the game (and the 3D models were mostly lifted from the 3DS games).
Also you should look up the story of why Gold and Silver had the bonus Kanto region. The dev team was having trouble even fitting Johto onto the cartridge with all the new Pokemon, and Satoru Iwata actually came up with a compression algorithm that could work on the Gameboy Color and allow for significantly more content. Pretty much a masterpiece of gaming optimization.
Just a bad example. The gameboy was an 8 bit (Z80 like) CPU while the gameboy advance was a 32 bit ARM (using thumb 16 bit code) CPU. The instruction and data width contributed to the code bloat.
@@cbot3400 my thoughts exactly
it's because of iwata
From all the automated tools available, I wonder if modern programmers are mentally programmed to expect assets to be automatically optimized. It is my personal belief that every game dev team needs someone do that as one of their primary tasks
Actual game dev here, a LOT of people forget that most of the size from a game comes from textures and/or music and not code. Back in the day you where sending commands to a audio chip directly, these days you're essentially playing high fidelity music files though a music player. Sure a lot of that can be more optimized in file size but that more often than not comes at the cost of CPU usages. I'm willing to bet that Sword and Shield uses higher definition textures (probably downsampled from some master set, seeing as modeling, texturing and animating 600+ creatures is expensive for every generation) and higher fidelity audio then sun and moon or X and Y.
Even black and white really just had ~6 frames of animation or so for all pokemon but thanks to image manipulation made it look like MUCH more animation where happening.
Pokemon in general is rather poor example to name seeing as they are pretty efficient with their file sizes. Certainly less so than the used to be, but pretty much every time that is done to increase quality. (if that quality is significantly noticeable for the average consumer however is questionable). And of course they aren't limited anymore with their file size.
There's something essential you aren't taking into account when it comes to companies and devs choosing more inneficient languages/frameworks instead of low-level solutions like C or C++:
COST.
If it's 10x faster to write something that hogs memory in python then why would companies pay someone that much more and have their product/features out later when they can get away with the inneficiency of relying on brute force hardware to run the code in an 'acceptable' time?
Ouside that you're spot on.
ok write something in Python to get it out of the door quick, why don't they try to optimize it after that? why stop? and why not (after getting some revenue from those initial versions) actually pay people some more money to write a good update? (preferably in C) , that way the costumer will be happier! why not?
@@vasopel Because when the program is done and working, you can blame performance issues on users' devices.
@@Shotblur ;-)
people who can code in languages like python and javascript are cheap and easily available
and making big projects in languages like C is a pain
also, the fact that doing everything in C forcefully will take much more time
the company will have to develop new ways to do it which will take much more time
@@vasopel It just came back to me an info when I read your comment, DOOM 2016 is 60gb and Seriko is 12Gb, I saw that when downloading them, note Sekiro is from 2019 and has way superior graphics and a way more campaign time and content in general, but DOOM is 5x it's size
This happened to the music industry as well. A lot of music tech cooperates are becoming less innovative and focus on selling snake oil products, softwares and plugins for music producers who just want to start. At the end of the day, the scene is bloated as the result. People really like spoon feed products, services or programs rather than learning the basic fundamental and work with the limitation. Believe me, Limitation brings the most creativity. It’s the most beautiful thing, a person can do. It’s beyond art.
>"Hey .. Android is open source - Let's modify it to suit my needs. Sure it'll be fun."
>Literally requires 400GB disk space
Me when first using Android: "Hey, it's based on Linux, let me switch to root user and modify the system..." Not so easy, kid. Not so easy. Complete garbage.
I have to say: I managed to live without a "smart" phone up until 2019, and I only got one because companies that I provide labor for were bothering me about it. I never imagine that in "the future" companies would stop using a simple email client in favor of a proprietary bloated messaging app that REQUIRES me to use it on a specific device, that DOES NOT work on computers. This is "the future" we are living in.
@@FeelingShred it is pretty easy tho, I have been using my rooted phone like that, I am running full fledged arch Linux in a chroot (because android is not GNU and doesn't have standard file paths)
@@destiny_02 Isn't termux enough for most use cases? It has OpenSSH as well
@@destiny_02 I can't root my phone, there's no support :((
(LG K41S)
@@Perseagatuna actually there is, many people have already done it
"You cannot write naughty words like blacklist or whitelist" OMG XD
it's funny cause it's true, it's also sad because it's true
inb4 someone puts "niggalist" and "crackerlist" into their code to spite the snowflakes
@@fenn_fren I'm going to do this
I wonder how they would feel about the value: 0xFU. That is a perfectly valid integer value in C and C++.
Blocklist and allowlist are better terms because they're more descriptive of what is actually happening
2:40 you actually did get double the content. You got to play on two regions, so they fit the old version and the sequel into 1mb cartridge, and gave it color. Pretty impressive
I actually spit my coffee out at the “soy dev” comment. I’ve never heard that phrase before.
While I can respect your opinion (and I myself have seen a TON of devs who just don’t bother to look into how things work), in the end of the day higher level languages help speed up development exponentially.
When working on a product, time to market is king. If I work on my passion project, I can take my time and optimize, but if I’m writing code for a company who wants the code deployed by a specific date, I won’t bother optimizing every little thing. To be clear, every dev I know still optimizes, but we don’t go down to the C or assembly level to check optimization. The optimization goes as far as checking the Big O and memory usage of an algorithm. Anything else is frankly a waste of time when I could be working on another ticket instead. It’s not lazy for a lot of devs, it’s the fact that it’s just not worth our time.
That being said, I’m not necessarily disagreeing with anything said in the video, it’s almost 100% correct. I’m just justifying why people code in higher level languages and maybe giving you some incite on how devs think about efficiency.
Spot on. GTAV rolled out a patch last year to fix the horrifically slow multiplayer loading times due to multiple n^2 algorithms running one after the other to check and sync I shit you not online content inventories (things like shops, items, special events, etc...) in the form of a json bundle. Replacing them with nlogn algorithms sped up loading times by 70%.
C is a high level language according to Dennis Ritchie.
Carmageddon 2: a fully 3D game with hundreds of 3D pedestrians per map, mesh deformities with car collisions (not to mention pretty good car physics for the time), and perhaps thousands of physics objects per level, ran on a 166MHz Pentium with 16MB of system RAM and 2-4MB of VRAM
Compare that to AAA games today lol
@@seronymus compare with the same resolution :P
@@ganjamangaaiaaai9396 it could run in 1024x768. Modern games can't do the same on the same hardware.
@@ganjamangaaiaaai9396 I used to play it at 1600x1200 on a Pentium 3 with a Voodoo 3. Not even 1GHz CPU, not even 1GB of memory and that graphics card sucked for anything other than the Quake 3 and Unreal games.
The C programming language was actually invented in 1972 by one of the original Unix-Chads, Dennis Ritchie, as a critical response to the limitations imposed by the B programming language. Out of his rants against B, C was born, which in turn allowed Dennis Ritchie and his co-Chad, Ken Thompson (who invented B, ha), to create a reimplementation of the Unix kernel.
@ Tiny C was pretty good on an 8-bit processor. What really differentiated UNIX on the 386 was demand-paged virtual memory. The earlier x86 systems had support for swapping, but not demand-page virtual memory. AT&T Unix, for a long time, did not support demand-paged virtual memory, but BSD did. This is one reason (not all the reasons) why a lot of commercial Unix systems from Sun, DEC, and HP went with the BSD base.
@ First of all, I did not say that demand paged architecture was great for C. I said it was great for Unix, and there is a big difference. It was demand-paged virtual memory that allowed for the "virtual" linear address space without requiring that amount of physical RAM to be in the machine, making the larger address spaces more practical.
Secondly, while 64KB address spaces and bank switching are not great by anyone's standard, the PDP-11 also used them and supported dozens of simultaneous users on one machine with Unix, particularly when a PDP-11/70 filled out wish 4MB of RAM. DEC also had eleven different operating systems on that platform for many different job mixes. RT-11 for real time, RSX-11 for soft realtime/timesharing, RSTS/E for education, a couple of different unix systems, IAS, MUMPS and many more:
en.wikipedia.org/wiki/PDP-11#From_Digital
specialized operating systems to try and utilize the impossibly slow machines with the impossibly small memories of the day.
Yes, individual processes were limited to a 16-bit address space, but we were also dealing with 10MB Winchester hard disk drives, Ethernet at 1Mbit/second and RAM at 10,000 USD per megabyte. RAM in those days (as you know) was typically measured in KB, not MB or GB.
Yes, assembly was used a lot, but typically for small, tight loops where speed was of the utmost, or as you point out, for other efficiencies. This was also because compiler optimization was a black art. There was the trade off of getting your program to compile fast or getting it to compile fast code. Early "C" compilers from the GNU project would generate code 30% slower than VAX-C from DEC on the same machine. Over time the optimizations got better on GNU, but a compiler focused on one architecture would probably be able to get 1-2% faster code than a general purpose compiler....and that is not the main issue with "C" compilers anyway. Even today there are about 1400 files in a stock Debian distribution that have assembly code in them, mostly due to legacy reasons, that do not have any fallback "C" code. I participated in a porting project recently and that is what we found.
I cede that Microsoft and Windows made the 386 popular, but one of the reasons is that the "Unix companies" (Sun, DEC, IBM, HP, Cray, Unisys, Wang) already had their own processors (or used processors from companies like Motorola) that Unix could support because it relied less on assembly language. And you pointed out that the 386 was expensive, and even more expensive if you wanted floating point. While Unix did not need floating point, it was heavily used in the scientific/engineering space where floating point had greater use, and these other architectures already had either built-in floating point or floating point accelerators.
Finally I do not believe that jumping large amounts of address space requires an interrupt even in 16-bit architectures. Typically this was done with "indirect pointers", where the instruction address mode would point to a word that held the address you wanted. Therefore a jump might take an extra cycle or two to fetch that address, but the data load would then be done. Using an interrupt, as you mentioned, would be very, very expensive in time and overhead. Of course different architectures implemented this different ways which is why assembly language was even harder for portability.
So I think it's time for D!
@@a_p_vox it already exists
Can't wait for D programmimg language to launch!!!
Hi, firmware engineer here who has always loved C/C++, Assembly, Rust, etc... Just wanted to say I avoided learning "full stack" development i.e. becoming a script kiddie framework dev because I thought it was boring and devoid of creativity.
And here I am years later having to learn full stack development because that's where the money is in remote work this decade.
I do agree with the optimising code being done to a much greater extent back in the day. I think it was john carmack of ID software that said something about having limitations allowed you to come up with more genius and elegant solutions to fit within those limits, quoting his time developing the original doom games. (could be wrong about who said this, just my memory of it)
but faster?? say that to my old win95/98 family computer that started drawing X's over every window when the air temperature got too hot outside. I guess it depends on what era and what application. maybe dedicated console or handsets like you mentioned which had software catered for it sure, but actual older desktop computers, like late 90s era? no way dude, faster? I remember starting my PC and trying to double click the browser without waiting for it to finish booting up (letting it sit for a whole minute on the desktop) and be able to walk away and grab my sandwich from the kitchen and come back and still see the window first open on the screen, the HDD making its loading noise the entire time. what the heck was it loading all that time? it's just netscape!! now unless you meant EARLY 90s stuff like before windows 95, things like the amiga, commodore 64 etc, then sure maybe. they never really had this issue of waiting and waiting for something you did seconds ago (or sometimes even minutes ago) to complete, but you also couldn't do even 10% of the stuff you could later so it stands to reason. late 90s was probably absolutely the worst time for bloat and computer slowdowns as you describe in the video, even my dad goes on about his memories of this particular period about once a year in a big rant, but it certainly got a little bit better into the 2000s and CERTAINLY has gotten even better after 2010. you would outright struggle to replicate how slow those PCs were even with the worst of the worst new hardware being made nowadays running average modern code.
THANK YOU. I think he's looking at a lot of this through rose tinted glasses or something of the sort. We can do more with what we have now than ever before as far as PCs go. The late 90s was indeed abysmally slow, that's pretty much when I got my first personal computer, and that was hell.
It all comes down to HDDs. They were blessing (storage space) and a curse (speed and especially access times) in one.
Like I tried to run Windows 10 on a 2004 100GB drive and it simply couldn't as it was pegged at 100% almost all the times. While a laptop HDD from 2012 at measly 5400RPM blazed through everything
Computers are faster, but many applications are slower now. We had the same functionality on machines that were a thousand times slower, and things that take a second now were instant then. Some modern software, especially AAA games, are heavily optimized, but a lot of modern code is super bloated, and that slows the whole system down, and kills the battery.
Slack basically bundles an entire copy of Chrome, and uses large web libraries, and mountains of Node modules. It's fucking massive. It would be relatively simple (for professional application developers) to implement Slack as a small, well-optimized, native application. Given that many people have programs like Slack open all the time, the performance of those applications disproportionately affects the general performance of modern personal computers.
Simply put, every line of code mattered.
I've been blaming javacript for at least a decade, have not been proven wrong so far.
Amazing they haven't at least gone for the head of the serpent and optimized Javascript itself by now
There's some (in fact quite a lot) of videos on UA-cam by a channel called Molly Rocket, where a dev talks about how much slower software has gotten. Most devs just aren't aware of the hardware or what it's capable of and don't measure their software, so they just have no idea how slow it is.
Drake techtips
I remember a quote from a friend of mine about making firmware on the Arduino UNO "I love developing on an Arduino because it is so low on resources that you really need to think to run really complex firmware"
When play vanilla wow on a private server with a original 2006 client i can play it maxed out at 240 fps on my cheap laptop but if i try to play the official wow classic that blizzard re released i need to put it on low with a terrible resolution and i only get 50 fps they did not really change the graphics apart from optional things that i turn off anyway they just use the new engine that is bloated.
They use not the Vanilla engine, integration, qol changes, and many many more things happened since 2006. It just takes a bit more and CPU. But yeah, could be lighter
Not to mention that the limit for how many players can appear on the screen at the same time, or in the same region (bare in mind: it's supposed to be an MMO game) has not increased since 2004. As soon as you have 40+ people spawning at the same area the game starts to lag. Just look at AQ40 test videos
Languages that can do more with less code have a place in modern software. Doing everything with c would slow down production and in some cases leave room for more safety risks.
Just discovered this guy today and have watched atleast 20 of his videos so far. I love how knowledgeable he is about each topic, is straight to the point, and isn't afraid to trigger some people in each video. One of my new favorite UA-camr's. Keep making more bad ass content man!
I never really thought about how games being 100gb now is completely necessary if they just took the time to condense them. But instead they just fork the burden over to consumers to get more storage space
Honestly with the pump and dump development culture at game studios it seems hard not to
Partially this is triggered by necessity of quick asset streaming. Bigger games simply compress their data less to be able to load assets from storage quicker. And considering that current gen consoles and majority of PCs still use HDDs big games start to make more sense.
The only reason it doesn't make sense for a third party app to take care of this on the consumer side is that the game will check the integrity later and redownload the bloated version. I tried with running UPX on executables and actually compressing container files that are in a normally compressed container type. The resulting games mostly worked like normal. But integrity checks triggered downloads to undo the effort.
Not only AAA+ games, but this also happened with me when I started learning how to edit and modify some Doom mods that I was having a few problems with (bare in mind: gzdoom is coded in C++... not a coincidence for its performance problems...) But back to the story: I found this one Doom mod where the author included OGG ambience and music sound files all encoded in 48 kHz and 320kbps. Totally unnecessary bloat. I re-packaged the mod with 32000 Hz sound files at 40kbps average bitrate (q0 argument ~40kbps in stereo) and reduced the final package size to 20% of original. Inside other mod file, I found texture files for water splash (the bits of water that appear when you jump on water surfaces) that were 256x256 in size, again totally unnecessary. 512x512 for smoke textures, and so on... No wonder some of these mods run like crap.
No limitations in hardware breeds lazy people.
Oh, they’re 100gb + Due to uncompressed multi-language audio.
Delete all the audio files from your game that aren’t English and watch that install size shrink by 50%+
I look forward to when Mental outlaw's beard grows along with his wisdom in the linux arts.
The hardware industry love this, of course. Although really new hardware should be released biannualy or every 3 years to reduce e-waste and not force developers to re-do code and driver compatibility every years, but rather give them time to better exploit what is available.
Hey MO.
I have a question on the soydev topic.
Not a dev or programmer by trade, but an economist, so anyone able to answer this from the technical side is appreciated.
If the cost of storage is now so low (and adjusted to inflation, it's ludicrously cheap compared to before) that the extra storage costs less than the frankly expensive manhours of devtime to make files smaller with less bloat, why bother?
I understand the desire to optimize for storage, but if the manhour cost doesn't justify the peanuts on storage, why bother? Isn't it just technology in service of convenience by this point?
Thanks.
You're exactly right. Storage is dirt cheap nowadays, so it isn't worth the money for a developer to optimize games to save a few GB in storage space when multi-terabyte drives are the norm.
Writing beautiful code is becoming a lost art. If you slack off as a software dev just because you have better hardware, you disregard the labor of the people who built the better hardware. Just because someone else is working harder, you don't get to slack off. Though money is a necessity, but I hope most of us are sensible enough to not totally disregard humanity.
this classical rant about developers nowadays just always being lazy its actually a lazy argument to trash people you dont agree with
lots of factors play a part, some of them as logical as seeing that a pocket calculator ''its faster'' than booting on your smarthphone and opening the app
but this guy reaaaaaally wants you to think certain people on certain side of the political spectrum are hurting your PCs performance XD
@@localboxcrox not using the technologies people worked so hard to create would be disregarding them
were would we be if the developers of old would have been shamed in to using the abacus because its more artsy of something
It's not necessarily storage in terms of hard drives getting cheap that makes that economically feasible. It's developer time that's the expensive thing, so minimising that is a huge priority. This is why things like Python are so popular, because you can have a novice whip up some solution to a problem in it _fast_ and it'll be reasonably workable. Processing power is cheap, so if it's too slow, just rent another cloud VM and run it twice at the same time.
The problem with that is that we've been being able to throw more processing at a problem for so long now that we don't have many greybeards. There are very few people in the industry who are complete geniuses who know the craft inside and out and can use the best language for the job for anything at an expert level, and this lack of experts is KILLING the next generation of programmers. The younguns can't learn from the masters, and we end up with everything being an electron app, everyone importing everything, and everything getting slower and shitter.
While I think you are absolutely correct about modern software bloat, I have to disagree about Pokémon being bloated, at least to the DS era. Satoru Iwata actually helped create some compression algorithms which allowed the games to fit into the cartridge. He saved large parts of the game from being cut.
A better example of bloat is on 3DS:
There’s X/Y, fairly heftier games than anything in the DS era. Albeit also understandable (3D models, better-looking scenarios and BGM, user customization and a more complex console with stereoscopic features on demand). Fast forward to 2016 and you have a game with nearly the same features (excluding stereoscope) for double the size. The reason? Quicker load times on ALL cutscenes of the game (for ALL the scenarios) causing multiple instances of Lillie models. Also, doesn’t help their way of loading into memory is questionable at best. All for quite possibly an uglier game overall (honestly, 7th gen aesthetic sucks).
Gen IV still could have used more optimization though, the performance was notably worse in overworlds and wild encounters. Gen V improved a lot in this regard
Gen iv save times 👀😖
Looking back at this comment, are you sure you're not talking about Gen II? I know Iwata helped in getting Kanto to fit in Gold and Silver
@@NicholasNRG he helped every game all the way up to gen 5 when he bit the bullet
Always when I only hear your voice I think of you like a nerdy white dude even tho I know you are a jacked bearded brown dude
me too
It's a deep fake, look at the background. Pay attention to the light switch.
@@user-cx3xi2nt1f wtf
@@user-cx3xi2nt1f why does he do this?
it’s not a deep fake lmao
This is insanely true in web dev as well, lots of sites are being coded with 200 javascript components on the first page instead of just using a dropdown. And half of the buttons lead to near duplicate content. For a dentist's website or whatever. Then the site is slow and the people who spent thousands on the site end up just spending more money to host it. Or worse, refactor it.
The big problem I see is that prototyping is now deemed OK to be the final product because computers have grown so much in power and space that they can absorb the massive added inefficiency and still be "good enough," but the bigger problem is that this has been taken to an extreme through the Electron framework. Most of the most popular software nowadays is Electron: Discord, Skype, even more niche tools like LosslessCut which is literally an Electron GUI wrapper around ffmpeg...all of them run their own separate instance of a complete web server and Chromium client combined core. It makes it super easy to run the same code on the website plus "apps" on all platforms, but it's a massively wasteful resource sink.
Optimization, in development like within all aspects of life, should become the most popular hobby for everybody. Corporate optimization of profits, where saving a buck gets multiplied as a cost of perhaps 1 cent for millions of people, in the end becoming insanely costly. But hey, at it made the corporation and it's owners more money.
The size of the pokemon binaries got larger in no small part because of the transition from the 8-bit architecture used on the GB/GBC to the 32-bit architecture of the GBA. Additionally, the resolution of the screen increased as well, going from 160x144 to 240x160, and color support was much, much better on the GBA than the GB. Obviously there was more than a quadrupling in going from 8-bit to 32-bit, but there were also fewer bugs in the later generations. Gen I is notorious for the amount of bugs induced by the way it was programmed.
The size of the pokemon games were not a mistake, but working within the constraints given and giving weight to whatever was the most pressing concern. If you can ship sooner with a larger binary, that's good for business.
As someone new to this field and decided to learn c++ as their first language I couldn't be happier. I am still not where I want to be but I am trying to build a solid foundation, I have a bunch of fun and i usually go as far as rewriting a bunch of std library stuff just to make sure I understand how everything works. I have enormous respect for those who paved the way and would one day love to learn assembly, but before that I want to be confident in c/c++, learn rust, probably C# and some webdev html,css, jscript.
While I always appreciate fast, lean software, the actual point of software development has *never* just been to produce the fastest possible code.
The reason we program is to create things that solve problems. There are constraints as to what you can create though, based on the resources that you have, like the how much money, processing power, and time you have available. The point is that you have to make trade-offs between these things.
Because computers have gotten so much more powerful, it no longer makes economical sense to spend huge amounts of time and money on optimizing code to run as fast as possible, especially when factoring in long-term reliability and maintainability now that in most cases processing power is *far* less of a constraint. Back in the old days, they optimized and were clever because they needed to so that they could do what they wanted. And now that in most cases we don't have to, why should we? Why should we spend so much time and energy on something that usually isn't a problem?
The point to take away is *not* to purposefully write slow code, but to *optimize where it counts,* whether that ends up being for time and money, or if you really do need code that runs as fast as possible. Don't be afraid to use whatever language works for *you* and *your* use-case, because not everything has to be written in C.
It's especially important to make expandible code in the age of user feedback and constant development.
programs don't run in a vacuum though
you're pissing on your customers by doing things this way
sure not every thing is written in C, but programmers are a commodity now and easily replaced. hell Google searches have made anyone a coder now with copy/paste and you don't need to know jack.
Would love to see some Fitness Outlaw in the future!
You dont get it. This is a deepfake. Outlaw's true form is a 300lb 5'2" blue eyes blond hair white skin Aryan.
@@migkillerphantom he's really good at this. He must be using DeepFakeLab
You asked and he delivered
I just yesterday recovered and repaired my old laptop and out of curiosity used it as a main machine for a day. It has two gigs of ram, intel core duo and some basic but nevertheless discrete Radeon and windows xp installed on the good old 5400-rpm hdd. Overall: feels as fast as 3700x/16gb/nvme - no user input lag, no floating mouse on the ice on drugs and the only thing that is taking time - copying files. Now i got mixed feelings about the progress )
I never studied XP that much as an operating system, but one of the reasons why copying a file might take a long time is that FAT file systems on Microsoft operating systems used to be synchronous writes, whereas Unix (and Linux) systems used large buffers in memory.
The upside of the synchronous writes was that you typically did not have your whole file structure damaged when the power went off, requiring a "file system check" (fsck(8)) to protect the structure of your file system. The downside was that your disk accesses were slower....a lot slower.
This is why "Mom&Pop" would not bother to shutdown their PC properly with an MS system, they would just hit the power switch.
You do that on an older Unix system and the sys admin (and all the other users) would kill you.
Modern day Unix (and Linux) systems still use the buffers, but they also use log-based file systems that write metadata out to the disk, then every once in a while flush all of the data in the buffer out at once (but in an ordered write that causes a smooth flow of the disk head across the disk) called a "sync", then erases the log file and starts over again. This means that the most you lose in a power failure is whatever was in the program's memory, and that is handled by program specific log files when the program starts up again.
Did you just use a 3700x as a comparison for speed 😡
Good old “5400 RPM” 🤮 please clone this disk to an SSD
@@ssunii7891 i had it in my own build at that time, so yeah, comparison was real
@@harbinger465 overclocked 12900k>
It's really a question of productivity over efficiency. Languages like solidity necessarily cut bloat, but (in most cases) the time you spend optimizing is time better spent on other projects.
Excellent video, dude. I just found this channel and it’s quickly becoming one of my favorites.
Honestly it's always like you vs the whole world, cause most of the people doesn't really give a shit until it's too late.
It certainly feels like that sometimes but we can't ever stop making noise about these things, either it's videos or youtube comments, plant the seeds in people's heads
@@FeelingShred I agree with you.
This type of fight happens in other fields too. There are people in my country that think corona is fake and even go as far as to purposefully doing the opposite of the guidelines.
That's like the equivalent of removing anti-virus software and downloading a bunch of stuff from piratebay frontpage because "virusses don't exist". Except in this latter case they only screw themselves if they are wrong.
In the case of a real-world pandemic if they were wrong they would be highering the chance of infecting family, friends, others and themselves with a potentially deadly dissease.
Endlessly spams "DEVELOPERS!"
- Steve Ballmer
I LOVE THIS COMPANY!
I see you are of pc user of culture as well
YEEEAAAAAAAHHHH!!!!!!
DEVELOPERS! DEVELOPERS! DEVELOPERS!
I recently discovered your channel and you are by far my favorite UA-camr. Keep it up 👍
Wow, this is such a great channel. Insane how nobody really does this kind of content really
I especially remember when you would double click on an icon software and it would open instantly. Now its such a hassle.
Oh, dude, same.
When I started playing around in Xcode, (Apple’s IDE for Apple apps) I noticed that a compiled app with very little code and assets took up less than 5 MBs.
That really got me thinking about what the actual world these people are shoving in these 100+ MB apps. And I’m talking about apps like UA-cam, Uber, Walmart, etc. Surely these people are shoving in bloated libraries, because there’s no multimedia assets that would reasonably require that much storage that I could find just by navigating the app in a lot of these 100+ MB apps. I can understand if it contained like several multimedia files and that’s why it was 100+ MB, but the apps like the ones I mentioned before don’t seem to contain any large multimedia files (or large amounts of multimedia files) that would explain the large app size.
It’s really a disservice to end users who may be stuck on lower storage capacity devices or want more apps and stuff on their device because their app contains huge bloated libraries that aren’t very optimized. And my guess is that these libraries are actually advertising libraries used to track users and invade their privacy. In fact, I wouldn’t even be surprised if multiple apps used the same bloated libraries, and users are unknowingly installing multiple copies of the same bloated libraries, eating up precious storage space that could’ve been used for something actually useful.
Just some food for thought.
In last paragraph what you are describing is DLL hell (simplest example is Microsoft visual C redistributable dll (or something like that) that often exists in 5-10 different versions)
@andrew342003 I heard about imitating usefulness before, in different context though. Where I heard it, it was about customers preffering expensive product to cheap one even if two products are same (different profit margins for seller)
Last time I was going through Unreal Engine source code, the largest part of the engine was a third party library (PhysX from Nvidia) and it took up 8.4GB of storage in source form. After compiling the source three was 80GB in size and 24GB of was PhysX binaries plus debugging symbols . Actually most of the storage was taken up by third party libraries and the engine its self was around 4% percent of the storage.
meanwhile even a statically linked hello-world program written in C fits in a single data block on disk.
"It’s really a disservice to end users who may be stuck on lower storage capacity devices"
I swear, a huge problem in software development is the people writing the software forget, or have never experienced, what it's like to be on a slow internet connection, or have a bargain-basement device. I'm pretty sure when it comes to that kind of bloat, it's not even that they don't care, it's that they don't know any better. Web devs are _by far_ the most guilty of this. Just because they've got 1Gbit connections at work, or faster, doesn't mean bandwidth grows on trees, dammit.
I was very surprised when i saw your background and heard you reverb. Was then expecting crapy content. But i was SHOCKED by the quality and accuracy of your discours. I know that this video is from mid-2020, but i will now checkout the rest of your content because you are very interesting. Congratulation, sir.
absolutely love your videos bro. thank you for doing this channel
«Companies want their teams to look like the United Nations»
Russians, who actually write good code, are not represented in 99% of companies lmao
Thanks a lot for your vids!
I find it very funny that everytime i look for some compression tool the maker(s) are always russian, middlestern or chinese, never ever a soyfiend.
@@J0derVIVIVI The highest quality tedious work is done by someone who has nothing more exciting to even think about let alone do. Unless along with its development comes its automation.
Russians are great in that.
@@J0derVIVIVI if I'm not mistaken 7zip was coded by a Russian
We got nice hard science preparation, old soviet professors had really high skill. There was a post on russian reddit where university students took a stroll in the university stoeage, checking all the old ugly science stuff that even today is extremely expensive and advanced af. Imagine people that trained people that designed that.
You forgot to mention the security concerns. Old software like pokemon red/blue were designed to run alone in the Gameboy, a machine with no networking, no operating system and only physical DRM. Today's software need to be safe in terms of memory allocation, resource sharing and secret handling. That's why companies migrated from C to managed (Java, C#) or interpreted (Python, JS in some sort. JS is a mess) languages, because the cost of finding a buffer overrun or a mishandled pointer in an app where just too big and the risk of someone exploiting it too high.
but most of the soy code you'll see still sucks
That was a very very good explanation and answered this question I had in my head for a few years now.
"Its not the car that's going slower, its the road that's getting steeper"
Imagine the beautiful games that we would have today if the devs would care to extract the most of the hardware like the old days
You would have no games. The first generation Pokemon games took thirty people five years to develop, now you could use modern bloatware to make a better game (or, to be objective, a game with more content and finer graphics) alone in a month. Software development speed matters more than software execution speed.
I bet you could run GTA V smoothly on 1gb ram. If God programmed it...
@@hexagonist23 god programming gta 5 is way too funny to me
@@rzul Development time is about the same, 30 people would be the size of an indie studio now. 100 people would be around the minimum for a AAA game that is purely PvP nearing the end of it's lifespan, for singleplayer experiences or newer PvP only games the dev count is often between 300 and 500. For 30 people to create a game pushing hardware limitations in 5 years to 300+ people creating a bloated game in 1, it's clear that they could be doing better. Yes, modern tech does allow you to create a project quicker, but no, that has not actually been taken advantage of by AAA studios.
Speaking of which, they could have take advantage of ps3 hardware but they didnt because its hard.
Thank you for saying that out loud.
I thought about the same topic many times now and it's basically true.
True, our computers and current consoles are beefy as hell but what do you have from that if your official Discord client on its own uses 1GB of RAM or so and web browsers easily grow in size over minutes because web devs and browser devs forgot how to optimize for shit?
Yes, it's nitpicking but having better optimized software in turn allows you to go for cheaper computers or even used ones much easier.
Discord ticks me off to no end but it's pretty much unavoidable if you're not a fanatic hermit committed to decentralized apps and such (and your friends too).
@@seronymus My RL friends actually do not use Discord, however, as I treat it as modern IRC it ticks me off just how bloated the official client behaves sometimes.
Speaking of that, I tried to contact the support yesterday because the Linux version doesn't run without hardware acceleration unless I start it with the parameters --no-sandbox
After submission, they now replied my actions are against ToS and thus ended the conversation.
F.
I remember the first hard drive I bought. It was a 491 mb drive that cost me exactly $491. It was an insane deal at the time. One of our computer labs at WKU had 30 computers and only one of them had a hard drive. It was a 30mb hard drive, and you had to have a written permission slip from a department member.
Man....you just speak to my heart....it's such a relief to be not alone
Fun fact: try running Skype or Spotify on an older tablet computer (Dell Venues come to mind) and you'll have a surprise: the UI and the core packages have been bloated to such an extent, they simply become borderline unusable. Why do you need an 8GB RAM, 4-threaded CPU to run Spotify or Skype? The technology hasn't changed that much in terms of video encoding or audio streaming and playback. You would assume that developers want to try and make them as widely available as possible. No, it's the soy-dev drama unfolding. Zero optimization, zero care about hardware resource usage or power consumption.
That's because it enables you to have a single codebase for all platforms since they run on web browsers, hence delegating the platform-specific responsibility to the browser.
And though it's unreasonable for such simple applications to demand so much resources, it's also true that most people and the majority of the customers of the business do have powerful enough PCs. If their customer demographic couldn't run these web apps, they would've optimised their apps, these are big companies.
We developers keep fighting b/w each other and trying to degrade the "soydevs", rather we should look at the root of the problem which is the company and the business. Developing the apps faster is more important and making them in a simple language so that a simple developer with an average salary demand can pick up the codebase faster is more important than the application itself being fast. C'mon, you look old enough that you should've realised this. This ain't gonna change
@@VivekYadav-ds8oz you're the reason why planned obsolescence exists in computer hardware. As an engineer, I see no reason not to develop your software, let's say, on C++. Fully optimized, platform-agnostic. Can be compiled and run on any platform you can think of, from i386, ARM and other more esotherical. But hey, profit comes from selling and shilling, as we all know. There's no excuse to create Mammoth-lilke unoptimized codebases, apart from laziness and apathy towards the consumer. Do you need high-level languages? Sure, just make sure they're able to run efficiently and smart on the large majority of hardware. I still don't think you need a 4-core CPU clocked at 2.5GHz or more to run Spotify. Apart from decoding music files, downloading artwork, and displaying a fluid UI, what are those major requirements that lead to such a staggering system requirement?
My thoughts exactly!
I think one of the many reasons developers move to higher and higher levels of abstraction, creating more and more layers of bloat is due to the fact that some of the lower level languages (initially, and still today) failed at providing logical interfaces for Devs to use.
E.g.: (from a cpp hobbyist):
- the late introduction of constexpr
- lack of simple endian detection
- forward declarations (more trouble than they are worth imo)
- include guards. (Why isn't this auto?)
- having unnamespaced functions from the C library
- std::move sometimes not doing anything
- reinterpret_cast only casting pointers but not other same size data types.
- the list goes on and on.
That being said, there is a place for things like python. Just being able to quickly slap together some single use code (e.g.: a script to invoke ytdl on any specific video with pre configured options) is really helpful, but reliance on these languages for heavy programs is terrible.
Also the current state of the web is trash to program for and trash in performance.
The current state of our tech is directly related to the economics of the marketplace, and as you can tell that's currently buggy as fuckk. Not to mention that the state of the marketplace is related to the state, which is basically displaying the BSOD at the moment.
I was modifing the dissasembly of pokemon red, and the ASM was really neat and well put together.
There's no money in optimisation. Why would I spend an extra 100 hours of my life for a 20% performance increase when the client doesn't care they just want all the features and they want them yesterday.
So much of my professional life is spent churning out code quickly and making sure it doesn't have any obvious bugs worrying about performance is a luxury
After 4 years on i3 and 3 on rxvt, I finally switched to st and dwm in July of 2020. It's so satisfying!
I yet have to switch from i3 to dwm (and from Arch to Gentoo, for that matter). But moving from urxvt to st was one of the most rewarding experiences ever in my Linux computing.
My University has a C and Assembly course and holy hell is C amazing
I remember running UA-cam on XP with Pentium and 2 GB RAM is smooth as butter, but now even load a web is a journey itself
ngl in general it's harder to keep things optimised when there's no real limit, and in my case with 3D modelling I sometimes accidentally go too far with polygonal detail instead of textures. Generally it's easier to forget about optimisation when there's no serious impact of not optimising anything.
I agree about the diversity non-sense, but I'd consider also "time to market" and "planned obsolescense".
The market is saturated, but companies still need to sell stuff to justify their value
One thing I'd like to add is that as a Jr. Dev, I've been adding on a lot of things which the company has convention for already. If I try and change something, or go against the convention, my fellow developers would never approve, and would seriously tell me that despite my code being better in some way, that it is always better to simply follow what other people have already done.
Whilst I agree with most things said in this video, I have to disagree with some points.
First I think glorifying low level languages is wrong. They have their applications just lile high level langauges have. As you stated low level languages have performace benefits compared to high level languages. That beeing said, modern complier optimization is narrowing that gap.
Also low level languages expose you to a much higher risk of memory leaks and the like, which can kill the performance benefits otherwise had by using them.
And lastly I disagree with the statement that desktop applications are the way to go. For cases where performace really matters, yes. For most applications the benefits of having complete control over the deployment of the software outweigh the performace penalty incurred. Also web applications mostly have less resources per instance than client applications. Furthermore the use of frameworks makse sense from a security standpoint in a lot of cases (I wouldn't trust myself to implement DOM sanatization for example).
Thanks for the knowledge Jason Tatum
I think that the popularity that "bloated" languages have got has way more to do with productivity and deployment speed than just laziness. Programming in C forces you to be efficient because you have to do everything yourself. That's a bad idea when you have a schedule.
You also have to be absolutely crazy to think Java programmers are lazy. Java is not an easy language at all.
Java compared to c is easy
@@henefein9939 exactly! That's why you'd be stupid to choose C for a safe and robust server side application on a tight schedule. Glad we're on the same page.
Java is also a language that runs pretty fast, though that's mostly based on the heavy runtime optimizations in modern JVM versions.
Cursed avatar
@@maruseron but most new apps never ever use any C or C++ even and have garbage code. just a small portion of C or other fast language would be sufficient. also don't even get me started on the apps that were outsourced to pajeets
I think you're missing the reason behind the new era languages a bit so let me share something from webdev perspective.
Since the hardware cost is not the issue now, and your users can afford it, the code maintenance became the biggest factor in software development. If a big corporation needs three c developers that would deliver same feature as one python dev using some bloated yet functional libraries, they decide that 0.2 ms of extra speed is not that valuable to pay triple for it. You're claiming that non-bloated code is value in itself which, no matter how much you'd like to, it isn't for many. Python and TypeScript are mature languages that can deliver and deploy much faster than any assembly and C/C++ code.
Moreover "Soydev languages" have very good standardisation and are nearly always easy to read. Python forces that by using whitespaces instead curly braces and ts/js enforces it by tools like Babel, linting, editorconfig or prettier. Try that with 20 different C++ devs which developed different code style over the years, use different compilers and C++ versions etc.
i agree. its so much faster and cheaper to produce and test new features on javascript as opposed to C. Because it is easier, it is cheaper and easier to find javascript developers. This guy is only looking at this subject superficially.
But c isn’t just a tiny bit faster, it’s a lot faster, I made a simple synthetic benchmark computing the exact same floating point value 1 billion times (which is a best case scenario for javascript because of JIT optimizations working on repeated code), and C finished in 1.8 seconds compared to 3.3 seconds for javascript on the latest (non-stable) node. This is already an almost 2x slowdown, if you’re a company paying for aws, that literarily translates to double the cost. As for standardization, Rust is great in this department, and is just as fast as C, C++ is also fairly well standardized and everyone mostly only uses one of three compilers now (clang, gcc, and mscc), compiler specific code is also discouraged. For code style tooling, there are plenty of tools for formatting every language, including C, one of which you mentioned specifically: editorconfig. As for different programmers having different code styles, that’s always going to be true, and doesn’t really have anything to do with indentation sizes, tabs v spaces, multiline comment type, etc.
As for javascript/python being easier, that’s mostly due to garbage collection, which Golang has, and it has only a slight performance loss due to it (see Discord’s switching to rust from Go post for a real life example of the speed). Personally, I also understand that if you’ve learned with javascript, any other language is going to be less intuitive, for me it’s Lua (another scripting language), but the more time I spend writing C or C++ code, the more it feels intuitive to have to remember to delete things when they are last used. As for pointers, they exist in all modern languages behind the scenes anyway, you just have to think about them more in C/C++/Rust/Go, and the syntax really doesn’t get in your way whence your used to it. Overall, my point is that after you learn these faster languages it’s not any more slow to use them.
The other problem with javascript is that it was originally designed to be used to do only simple things, which is why it is such a mess today, and not a good language in general (this doesn’t apply to other scripting languages like Python or Lua). Finally I need to mention game studios which have go use C++ for it’s performance, and don’t suffer at all due to it, (Jonathan Blow talks about this a lot, if your interested, he’s a really good speaker and has made 2 great and successful indie games).
@@veda-powered as I mentioned at the begining - from webdev perspective. There's no doubt about speed of c++ but in certain use cases like web development it's more likely you're waiting for some API to respond than for code execution in js/python. These languages does the job done (of course with strong support from c++ in terms of some libraries like nodejs or IO operations) and you won't notice performance issues for what they're designed.
Now try to do a simple machine learning using pure python vs c++. Or try to write the web API using c# and C++. These comparisons are not about you can't do that in c/c++ but about it's toolset and work hours to delivery.
It didn't even crossed my mint to say that js/python/bash are perfect languages to write games or do any close hardware operations because they aren't. They are what they are, a cheap tool for few use cases and shouldn't be treated better or worse than any backend language.
Contempt My point with game dev wasn’t that anyone was saying it should move away from faster languages, but rather that there are tons of developers who prototype in C++ with no issue. Secondly, I’ve written several basic web servers in Golang and it is not any harder then in python or javascript (I’ve also written a few webservers in those languages)
The other thing to consider is that your choice is not just either bash or assembly, but there is a huge range of programming languages in between, I’ll give a list here: The slowest languages are bash, python, Lua and javascript, of these bash is almost never even considered because it’s actually just a command line shell with a few flow control things thrown in like if or for. Slightly faster are the bytecode languages, specifically C# and Java, which are both just as easy to use the only difference being that you have to compile them first. For second fastest there’s Golang, which is fully compiled making it almost as fast as C in a lot of circumstances. Then theres Rust, C, C++ and D all of which are slightly faster then Golang because of the garbage collection in Golang. You could easily develop a web service in any of these languages, (except for bash, and I haven’t personally used D). Someone I know actually made a simple web server with some logic in Rust while learning it in about a week. Assembly is never used anymore because it’s almost impossible to make a large-scale project run faster then if it was written in C using assembly. As for machine learning, python can’t actually do it, in fact your cpu is rarely used for that, instead a library shunts off all the necessary data to the gpu, so for a task like this the programming language really doesn’t matter. The only difference is that C/C++ libraries usually give you much more control over the internals. And yes, being bottlenecked by io is a possibility, but if you have 100,000 concurrent users, and each one just has to be sent back a static page (a different one each, so none are cached), most of the time would be io, but there will still be a significant amount of cpu usage because of the sheer number of users, and using a faster language could still probably lower the number of aws instances you need.
Even if it was exactly the same speed though, I don’t see why anyone would want to use javascript, it’s just a worse designed language then something like golang, rust, or even C# or python.
@@veda-powered all I am saying is these are still used languages not because people want to write slower or bad software but because of scale. Developers are cheaper, and easier to hire. There are mature frameworks which works quite well, which cause development to be easier and quicker. Which means you can sell your enterprise product cheaper than competition and business model makes it super easy to deploy and support.
It is industry standard to use js to write frontend because browsers do support js and unless webassembly change that (which I hope it soon will) were stuck with JavaScript. Js actually would be very good language, if they wouldn't try to support old browsers and maintain all this historical mess backwards. Latest ECMAScripts are going in the right direction but progress goes a little bit too slow.
When it comes to python it is super easy to write scripts and use it as between platforms scripting language even in some DevOps jobs. There are many use cases you do want to have a script instead of binary, especially if you do very small changes or your users have to personalize them for their use on different machines and systems.
As long as speed is not your main concern but rather saving money and delivery I understand companies that do use python or other scripting languages. You're just to focused on your own industry to see that. When it comes to rust or Go, I think it will take some time to popularize those languages around the industry to be treated other than c++ safer/cleaner replacements to make real impact on areas such as webdev. Honestly I never heard of any backend API written entirely in c, go nor rust. Sometimes it's components but that's it. Maybe that's just my info bubble and bias.
Im still kind of choosing my career future. I am currently learning a variety of IT-related stuff in highschool (from programming, web design, assembling pc's, network configuration, database administration etc.) but im yet to choose a specific path yet.
Do you think C++ could be a viable career choice in this day? i already learned a bit of it, but i honestly dont know..
It might be better to write in C++, but would employers actually want that kind of programmer, or just continue to develop web apps
This is so true. I teamed up with another programmer to write a Bejeweled clone for the Atari 2600 in assembly language. It is a fully complete game, with multiple one-player and two-player game modes, and has full support for NTSC/PAL/SECAM displays, and sound effects. The game is 2Kib in size (this includes the entire "OS", if you want to call it that, startup, user input, display output, RNG, etc.)
For a project like this to be any good, efficiency is a must. Nowadays, with limitless memory and storage space, coders think the sky's the limit, but yet somehow manage to come up with solutions that are slower than ancient solutions running on ancient hardware.
This also applies to the web, and in that case the problem is actually much worse, in my opinion. Just about everyone has access to a medium speced system these days, but when it comes to internet access, unless you live in a major city, you have one, maybe two choices, neither of which can handle the overdone-javascript-full-screen-eye-candy-scrolling-image-advertising bloat that is today's internet.
When the menu in your site lags on a 1000usd computer
6:05 "C is barely taught in college, academia these days"
In Indian universities, we're only taught C. Earlier, schools also only taught C++, but later on they switched to python. My batch (2017 grads) was the first one in my school taught python)
@Squeeky Ceiling Fan hey same here too!
very underrated channel especially for the actually original and valuable content and topics
nice overview, keep it up! Btw. I use i3 because it makes me productive. I put up with configuring some suckless utils and it's just a horrible experience, knowing C doesn't make it any better. I like simplicity, but file-based configuration is the way to go IMO.
Exactly, I do like the suckless tools, and I'm a programmer, but having to download the source, download all of the customization patches I want, fix the makefile, and recompile is always a hassle. It would be nice if they could provide a user friendly script for automating this stuff.
Games are good examples. Some old games require 64mb ram and 200mhz, then they are remastered, they look the same, just runs on windows 10 and sudenly game looking like 1997 games require 2gb ram and 2ghz and 1gb vram...whyyyy?
It's mining crypto behind the scenes
often is a sign of a poor port job, that instead of retooling the engine proper, just placed a layer of emulation ot make the old engine run on modern hardware.
Slow and steady wins the race. Jeb 2024.
Love you man. Just found out your video by accident. Can't more agree
vs 2010: fast asf
vs 2022: awh givme a second to process ur keypress
While the points are mostly good ones, I disagree that we should only code in C or other low level languages.
In todays industry the pros of interpreted or other highlevel languages usually majorly outweight the cons. We agreeably live in the golden age of fast hardware anywhere. It enabled the industry to get far more software. The focus today is how they can develop stable systems fast, scalable und complex without sacreficing tons of development time. Most major project simply wouldn't be possible since coding them in C. They would either:
- be extremely prone to attacks (not even experts write perfect C all the time)
- Take ages to develop
- Be extremly complex because of missing abstractions
- There would be far fewer people to find building those projects
- Onboarding new people into a project would take longer because of more code for the same concepts
While other quite low level languages like C++ (especially when following best practices) have enabled more complex and stable, yet fast programs, even there it's still hard to scale. For that reason, garbage collected languages how ruled for many things as the classical problems are solved with it. Many see garbage collection as an evolution for most cases over C/C++ (and for most programs this is true).
Most interpreted languages also have the benefit of being cross plaform and cross architecture by default (the web is also basicially kinda that). That alone is helping the industry a lot in providing more software faster.
The programmers of the earlier days, still have their areas today for e.g. highly optimized algorithms, embedded systems, or other systems programming. I think that most of these programmers would even be bored to write web apps all day.
One other thing that came along with hardware, was also that it often isn't a problem of needing more computing power, but managing IO (Storage, Network, ...) more efficiently to get a lot more performance. Creating a async platform purely in C or C++ would be nightmare to get the code right (no dataraces, dangling pointers, ...). Case in point would be Firefox. People from mozilla started rust, so those C++ experts could write fearless multithreaded code to improve the performance without risking security holes. Rust is a nice middle ground between really performant C-Like code and the memory safety guarantees that historicially only garbage collected languages could provide.
I agree that:
- Many developers don't even know the speed implications because they don't ever need to write speciialized high speed algorithms anymore
- Making inefficient systems is a lot easier since the difference between slow and slower often doesn't stand out
- Knowing lower level languages, having worked with embeeded systems or knowing how the systems of the past worked with few resources is beneficial even for their "High level work"
- And many more of the "developers don't know how to do it right" things
On the other hand, having the opportunities to create far more complex and abstract architectures quickly and easily is hughely important. Today a programmer isn't just the one who could make the best game or demo on a C64. It's the people who can do the "quick, dirty" and often repetitve work to create complex architectures/webapps or user experiences in a few months that would take C experts years to do with the same degree of stability and features.
The recent boom in async programming in all kinds of languages already gives good performance benefits when used properly, even if it often splits programming ecosystems in two (why would the industry do it with that drawback then)?
--
I hope this text didn't choke anybody. I love extremly optimized, fast and elegant code as anybody else. But there has to be a blance and one has to agree that even the soydev programmers (as long as they don't screw up or constantly create security holes even in languages that try to prevent that) have their place and our software ecosystem would be a gallery of extremly good but few programs without them. They drive innovation as well.
Of all the comments I’ve read here your impressed me the most. Fall of 2021 I started learning Python because I knew it was “beginner friendly” programming language. As I’ve researched the topic of programming languages I realised the difference between a high and low level languages.
This video made me feel bad because although I’m still learning and not a developer, the languages I’ve chosen to learn - Python and JavaScript - are not at the same level of efficiency as C/C++ and according to the info in the video I would be contributing to bloating software.
From your comment I make the assumption that you have a lot of experience. May I ask you what would you do if you were in my place and had to learn to code in 2022? Where would you start? How would you go about it? What would you do differently? Where do you see potential to do great work?
I apologise if I made the wrong assumption and wasted your time. I just want to do good quality work. I would be glad to hear back from you on the topic and get answers to my questions.
@@stefanstoilov541 Bless you, I have minimal Python skill but I gave up and want to learn C
@@stefanstoilov541 C is a high level language. Also, JS is objectively harmful. It was only meant to be a temporary industry solution and even it's own creator admits it was a mistake.
@@alternateperson6600 Language levels are relative. C is a lower level language than most languages used today. Why argue semantics?
Also, an appeal to the creator's authority is not enough. How is JS objectively harmful? What would you use instead, and can you prove that your solution would be commercially viable and produce as much software and accessibility as JS has been able to?
PS: This is coming from someone who hates JS, though I also hate making UI's in general.
@@son_guhun >Language levels are relative
Perhaps, but the very own words of Dennis Ritchie and Brian Kernighan aren't. C is a high level language with low level features, that's what they said. Other languages not having as much (if any) low level features as C doesn't negate the fact that C is primarily a high level language, as it's creators intended. If we must alter a definition due to present and future circumstances, that definition is not particularly useful and thus we shouldn't designate languages by level at all; otherwise, C is a perfectly valid high level language.
>How is JS objectively harmful?
Terrible semantics, terrible syntax, and it's insecure. Need I say more?
>What would you use instead, and can you prove that your solution would be commercially viable and produce as much software and accessibility as JS has been able to?
We should instead ask ourselves if JS is even needed. I can only think of a few scenarios where JS is actually applicable, like online transactions; yet JS is everywhere, even though most of the web would function fine without it. Why is that? I think soydevery is a more pressing matter than a JS replacament. While that wouldn't completely erradicate JS, it would greatly mitigate it's usage. Soydevs infesting the webdev scene and competent devs coerced to comply with harmful industrial standards by their employers are the only significant factor for the wide adoption of JS.
Are you trying to redo all of Luke Smith episodes
Yeah but with less cringe arch shilling
Luke's stuff is a reference implementation.
But with more badassery
First time seeing him and I definitely didn’t expect him to look like that
I completely agree with you. As a Unity developer of 7 years i regret every moment of learning C#, it just compiles it down to C++ anyway, could have just as easily been C++