Finally someone with brains

I would argue it's the modern houses that leak and last nowhere near as long as the old more primitive ones. Case in point... I have windows software I wrote 25 years ago. It still runs today. Try that with today's tools. Another cracker feature... Real time remote debugging that was 1997

I agree and I think a lot of the "lost productivity" is actually being wasted due to tech companies becoming too big and the bureaucracy associated with it. It literally was the same with mechanical engineering companies before. Some people build a product in a small environment and once it becomes a global success a lot of additional people are needed to simply manage everything (also the technical side) and those people again need new processes with new internal stuff and so on. Additionally, a lot of "lost productivity" actually is not lost but being spent on scalability and usability. Simply looking at it from the number of features implemented per employee/time is pretty stupid when Facebook started out with a few thousand users that would post once per day compared to the millions of users and corporations that use Twitter nowadays with multiple messages and videos being posted daily. Apps and Websites have evolved a lot in terms of usability the majority of users are not interested anymore in spending hours on grey or black and white forum web pages that only support text with a terrible search function. Comparing the pure functionality of some mercedes a decade after it was invented to one now is basically the same. Both cars drive and get you somewhere but the comfort/usability of the two products are something completely different.

I mostly agree. But I'm a bit skeptical about the last point as well. Programmers may not be losing that much productivity at all. The charts that were shown in the video were labelled "number of employees" not "number of engineers." Maybe that includes help desk people and marketers and whatever. If someone has more convincing statistics, I would take a look.

@@ahdog8 It surely does include all of those as well.

This was one of the contention points when a bunch of VHDL files on AMD cpus was leaked on the internet. The amount of people which understand hardware at component level like that wouldn't even have interest in those. They're already employed in well paid positions, as hardware designers are a very finite number of professionals these days. The dellusion that you know hardware at component level is very high amongst older programmers simply because they know lower level languages.

@@BrunodeSouzaLino Well, they also know old systems where that assumption, knowing what the machine did at the lowest level, held true. And we see the consequences of people losing this ability every day - that why we get stuff like electron or similarly bloated stuff that requires hundreds of megabytes in memory and assets to do the simplest thing possible. And the fact that people seem to be okay with that and just shrug it off like nothing.

@@lucemiserlohn There's two things Electron is good at: - Cross platform apps - Developing time Writing and maintaining cross platform native apps requires a lot of time and effort and it's an uphill battle with systems like Linux distros, where it is impossible to cater to every single case or set of apps each user has installed.

@@BrunodeSouzaLino I never said electron is not useful in certain cases; it's just bloated and painfully slow, both aspects which I personally do not want to deal with, neither on the developer side nor the user side.

there's a good usenix talk on this subject and OSDI, specifically that the "operating system" barely has any control over most of the hardware. most of the hardware communication happens via ad-hoc black-box firmwares written by who-knows-what company, with absolutely no cache coherence compared to the OS

the limitations also exist for a reason. you do not want a bug in a program to wipe your disk or fry your cpu for example

hiding complexity in for example interfaces is increasing productivity. I don`t think the number of components programmers keep track of has changed. It`s just that instead of pointers and a list addresses in ram we use containers, instead of writing 10th thousand lines of code we use for example network stacks. The level of components we use implements a very abstract function for us so within the limits of our brain we can design ever-enlarging systems.

statically linking opens another can of worms. You need to keep track of the security issues of the libraries you use. If you use a dynamically linked library and that library has a bug, you replace the library. If the programs are statically linked, you have to keep track of the libraries that each program uses, then you have to recompile all affected programs and redistribute them. Secondly the admin can't even tell anymore which programs are vulnerable and must rely on the diligence of the programmer. He has to check if any of the programs he wrote in the past uses a vulnerable library, recompile it and redistribute it.

Complexity is the source of most problems. I use templates in C++ not to introduce more complexity, but flexibility. You have to very careful about that abstraction most likely increases your distance from the actual problem u wanted to solve in the first place. And regarding speed the optimized version is most likely a very specific solution and not a general one.

@@LC-hd5dc A bug to fry the cpu... wow

So you're saying that most of them are data pseudo-analysts/pseudo-engineers?

As well he did a mistake somehow thinking that first Unix made in 3 weeks was sign of productivity. The complexity of that Unix was so low, modern programmers would have probably finish it in 1 week I suspect.

@@amotriuc Only when they can dump in a dozen heavy frameworks to do the actual job.

I think that's half right. Developers just have more features to develop these days. But if all those features were useful and worthwhile then you could say that developer productivity was as high or higher than it used to be! The problem is in a lot of software, even a lot of games, but I'm more thinking of other software, only some of the modern features are useful and a lot of them are just pointless. Often people work hard at producing stuff that doesn't even need to exist, either by being misguided or not very bright, or deliberately, for money! Or spend time learning and using complex tools and processes where something simpler would work better.

The "sea of technologies/frameworks/libraries/tools to get anything done" is likely a main reason productivity is slow in the long-term. They give you a quick and dirty solution for prototypes but they make maintainability a pain and instead of learning what your code is actually doing, you're spending time learning arbitrary made-up pipelines and functions, trying to dig up what the black box libraries actually do under the hood - and when they're actually open source you find out that they're impossibly complex and will take a very long time to understand. But it doesn't have to be that way. It's because of modern software dogma of turning everything into modules, singular generalized objects and overreaching pipelines.

long story short, you can fix something until it breaks. why I have zero faith in tech long term. ha ha suckers

​@@stuart6478you have zero faith in tech, yet you are using it daily? You have faith in it then 😉

"need" is an interesting choice of word here.

With teams you end up with a larger range of project scale that can be produced, but at the same time you end up giving each person on the team less stuff to do overall, ruining their productivity.

Yeah, everyone in management needs to read Deep Work. The amount of consecutive hours you can work with no distractions is the largest factor in someone's productivity, and most companies won't even let you ignore slack for 15 minutes.

@@La0bouchere Someone pin this comment.

Someone please abolish standup meetings, retros and estimation sessions 😥

it's almost like entropy exists

Yup. This is if one of the Four Yorkshiremen was allowed to give a TED talk.

What are the relative years of experience here? Perspective?

this is Blow's whole vibe now. he programs all his games from scratch, even going so far as to write his own language. there is nothing in his games that remotely require that. he is the epitome of thinking he's the smartest one in the room

he has turned into a gross boomer just like Elon, and it is tragic as both had so much to offer. and i say that as a fellow old programmer

@@Raxfyr He's just what a painter is to digital art but for programming instead. Like, not everyone needs to be smashing prompts into a generative model or using digital painting software. Hand-painted artwork is still in demand and so are handcrafted games. It's not because you don't appreciate something that nobody else does. Get your head out of your ass a little

also it's ridiculous to imply that the world would be more productive if every programmer produced a new operating system every 3 weeks. we already have too many of the infernal things and this was something he himself was complaining about in this talk.

Einstein was a thief

The guy wrote a small regex engine with a handful of lines of code. The guy can write a program, trust me.

Did Oracle App tell you that?

Helps both of them are of the same generation (Terry Davis and Jonathan Blow), they are really productive people. I remember Terry Davis multiple rants regarding the English or Humanity people getting involved in programming and often doing things that are affront to computers and talked about how important it is to program the way the computer wants it to be done.

@@NicholasStabile you mean the way God wants it to be done

@@NicholasStabile what stream is that

@@tx7300But that goes without saying- they are the same thing.

Using the right abstractions should make basic things take less time, not more... no? I was in a similar situation (debating approaches eating up time), but I think "patterns/refactoring bad" is a red herring. For us, features took a long time in part because the code was fragile, full of cycles, and so inconsistent it might be considered abstract art. :P A more fundamental problem was that no one on the team (including me) had the expertise to say, "I've done something like this before, here's what I've seen go wrong ... I recommend approach X for reasons Y and Z," so that we could just get to it. That's how I learned expertise means a lot more than job titles; if no one has done the reps, we're always in uncharted territory. It also takes trust for that to work, and trust is earned. If we _didn't_ spend time on design, new code was fragile, hard to read, hard to debug, and exacerbated tech debt. If we _did_ spend time on design, it would take weeks to get to something that was _ok_, but it would have taken even longer to get to the 'right' (sustainable) solution. We didn't have any underlying goals/non-functional requirements to justify which refactorings were worth the time (e.g., "component X must be fault tolerant because it's the foundation for mission critical functionality Y", or "components A through F run

Damn bro, you must be at Cisco

@@user-sj3fp2xq2m it's a company that has a monopoly over data centres in the country I live. They don't have to try.

That sounds like an absolutely awful company to work for

Just one more abstraction bro, it will abstract away all the other bad ones, bro plz just one more

Exactly.

That becomes a big hit.Often for the year. With sales in the tens of millions. for puzzle games. That are built by a small team not an immense AAA studio. As craft and not a template. That works when released rather than getting released expecting to bring it to a working state with updates and patching via the internet...

Exactly, he has to port to each os which probably takes a lot longer. He also doesn't use unreal engine, he's not building yet another fps.

the car thing is not really comparable i think, its just an old invention what got to business and drives humanity so badly, destroys earth ecosystem,, 4 wheels do the same over a century, the software things are really stupid to think about, i think its just a good hobby or a thing what you are exited about and goo to deal with it, its like music, should not be taken this complex anyway the real jobs are about survival and material things, building house, agriculture, but after all everything is being with a problem too, you cant except from the nature what you want exactly, somewhere, something, going to crash and you have to solve it somehow, or leave it and go on to the next thing

@@RegiJatekokMagazin I really don't get any of your points :D

@@Peter_Lynch I want more information about that, why you didnt get it, so we can make a point :)

someone is working on their excuse to keep their job.

Sir do you know of the Longhouse? If not some there are some great articles, namely (google) "What is the Longhouse?" - for the more cultural take that goes hand in hand with what you said.

Fuck that shit honestly. Tryna save time and money by "saving software" is pure fucking folly. Especially with AI's these days. Everything is gonna need to be rewritten fully. Thats just unavoidable. Its less painfull though cus we got fucking AI. Its so braindead tryna modularize code and all, only for it to not even remotely matter cus of how much work u gotta put in to integrate it.

Yes, managers need to explain to C-level why they get salary, so they generate features like crazies. Their approach is usually quantity over quality

It's quite common these days in all industries. Make new product with barely any need , product managers exaggerate what market wants or where market is headed just so you can sell something new. Re-inventing of the coke bottle but with software. Maybe its different at the top tech companies but a majority of software engineering seems to fall under this.

@@yalslaus the "top" tech companies are worse because they have a dozen teams all duplicating work because they've ended up not communicating with each other

He is not blaming developers, at least I do not see it as blaming. He just states the fact that effectively most developers write almost no code. That's why I do not work as a programmer anymore - too many meetings, too much unproductive talking, no programming assignments. If you like coding, do not aim to be a corporate developer.

The dunning-kruger effect strikes again.

On big systems and when working with other people ... absolutely. In general. Absolutely not.

You don't even need to do pointer arithmetic yourself anymore. It's all handled by array indexing but people are still afraid of a fucking value holding a simple RAM address

The lot of time part echoes with me as a sysadmin - in my field productivity is also strongly linked to idle times. Since you're all-times split between daytoday and readiness to deal with outages and projects you need to spread buffers everywhere where your colleagues and you work on keeping their edge over the needs of the day to day. If you spend all time in agile standups, 1on1s or chasing your sprints fixing bugs you'll not be able to have that edge. Not be able to gain the distance from your current detail issue takes away the chance to coordinate with colleagues, and to idly spin ideas.

​@@pretzelboi64it's not really a ram address, but yeah

Sounds like a skill issue. But in all seriousness, this is just an easy copout. “Oh it’s too hard, oh I’ll make too many mistakes.” You’ll make mistakes regardless of if you use a low-level language or not, and especially if you don’t practice. By practicing using pointers, you’ll better understand how they work and eventually avoid making mistakes entirely. There’s also numerous memory management strategies, such as arenas, that simplify dynamic memory allocation quite a bit. Pointers are really not scary at all.

exactly, this guy is obsessed with a perverted interpretation of productivity and he's built quite a cult following around it too

The API is fine. It’s that developers today struggle to use them. Once upon a time, APIs were a great way for software engineers to communicate and share with each other. Today, it’s a skill unto itself that requires a 2 week training course. WHY?!? Can’t we just read the documentation and try it out? If it doesn’t work for us, don’t use it. But in practice, we first invest in a multi-week training course, then claim certification on “the thing” and then we have to use “the thing” because we’ve invested so much sunk cost into it. That’s bananas!

@@thewiirocks Many corporate APIs have restrictive aspects to them that are not there to solve or aid in solving an engineering problem, but instead to give a business leverage. In cases where you have no other option but to go through an API you are at the mercy of the author of the API, and if it doesn't expose what you need you've now got an artificial problem on your hands that adds an unnecessary complication/hindrance to your work.

@@thewiirocks The reason why a lot of software companies fail, they overextend everything

@@kleozane2781 Software companies fail for the same reasons that all companies fail. They are unable to provide a product desirable to the market at a price that is acceptable. Everything else is just noise and may or may not contribute to the failure of any one company.

@@thewiirocks Another point is outsorcing everything. The company I used to work at had this problem, they tried to outsorce everything.

You can literally use almost any modern software as example.

Port to other platforms and internationalization isn't development per se, it isn't creation of something. Yes your house needs some fixes here and there but you don't need to rebuild the whole house every time with architects and engineers involved.

@@alexisfrjp If Your house was fit for 5 people and now needs to house 5 million... You need more than making the kitchen a 1 mil times bigger.

Nope. The most valuable service the Big Tech companies provide is keeping those n00bs away from the rest of us. FANG-employment-seeking is a disease, fortunately they are self-isolating.

Do you work in a top ten tech company and have evidence of this? I do and this is most definitely not the case where I’m at.

Need to move to containerized microservices and CI/CD pipelines. Monolith codebases of intertwined dependencies are out, self-contained packages running in containers and communicating via messages is in. The development process has more overhead, storage/memory usage is much higher, and constant environment setup is a pain in the ass, but it solves the vastly bigger problem of fragile, interdependent monolith systems.

you have zero clue what you're talking about lol, are you even in the industry?

frankly it should just fall apart for the good of the world.

Here’s the thing. Imagine you want to make a fun puzzle game for a phone. Imagine how daunting it would be if step 1 was “write an operating system”. This is a wildly oversimplified understand of the systems we’re working on. Imagine you start a game on your phone with its own operating system. Your computer shuts down, and then boots you the game. Ok, let’s pause the game and check my email. Oh wait- hold on. I have to shut down my phone and boot up my email operating system. Abstraction is being able to use the efforts and expertise of others to enhance your work. Leave the OS engineering to the OS engineers. When you build a house, there are people that build the foundation, people that build the framing, people that put up the dry walls, and people that put on the roof. One person can do all of these things, but it’s much quicker for people that are specialized in specific things that do it every day to do that specific thing.

@@shableep It's quicker to delegate the labor to specialists but it results in a worse product. The best homes are built by one or a few people with a common vision and an understanding of ALL the systems involved. The reason software expires pretty much on arrival today is because of years and years of delegation compounded on top of each other. No single vision. Design by committee. Disposable garbage.

Basically how all Amiga games worked. It was very rare for a game to require Workbench. You just put the game disc in and it ran. So they basically all had their own min-os hardware routines written in assembly to do common tasks normally handled by an os these days.

Incredible that so many things came out by using Lisp. I remember learning it in college and the recursion was hard to grasp, but the mental models created helped so much in the long run. One of the projects was creating a SQL like interpreter, using some helper library. I think our team finished it in a weekend.

Large companies like large teams because people quit. If one or two devs quit on a large project, it's okay. All knowledge is not lost, but if one or two devs quit from a small team, you lose a ton of knowledge that can not be regained without dedication.

Managers also like large teams as it makes their resumes look good.

They try to achieve the same in the FPGA world with HLS... Promise? no need of hardware and low-level knowledge anymore. Good luck.

the real kicker is that even the OS doesn't have true hardware access. also the metric of "features per programmer" is the funniest metric i've heard of

Right!? Also, one of the main reasons civilization even exists in the first place is due to specialization of work. Now we're using that as a metric for the decline of civilization? I'm sorry. I'm not buying it after two measly graphs and one short video.

I don't think that's the point, Jack. The point is baked into all of this advancement is also un-necessary complexity that reduces the ability and increases amount of work needed to achieve certain results. Try to keep up buddy.

No. The problem is people fantasize about big corporations wanting innovation or even needing innovation. They don't. Most organizations want you to competently make an API call between their accounting system and their time card system. They want you to glue disparate systems together so that their business functions in a cohesive way. Showing an example of a grade computer science pioneer genius writing an operating system at Bell Labs, whose only goal, with to spend as much money as fast as possible on R&D to average developer applying critical thought on solving a normal business problem, makes this man look like king of the shmucks. He is Shmuck Man, comparing of things that don't make sense. If you're being paid to say.... develop a time keeping system and instead built an OS, you'd be fired. Because you don't work in the whimsical word of Bell Labs where every developer has full autonomy and an endless budget that doesn't need justified and you don't even need a relevant business problem to solve. You can just "Do Stuff". In the real world, with real businesses not in 1980, businesses have narrowly defined problems they need solved. They need some one to randomly poop out an operating system for funzies.

For real, I can't even open youtube on my old laptop

Necessary? For an operating system? Why exactly? The OS part of what you call the OS should be as small as humanly possible; everything else is a program running in userspace, and that includes the majority of what you listed there. The fallacy is that we think we need all that heavy ballast in the OS itself; and the better design angle is to get rid of it all and just treat it as ordinary software that can be run, but doesn't have to be run; that can be deployed, but doesn't have to be.

@@lucemiserlohn An operating system needs to be user friendly for the majority of people, the tech itself or concepts behind it don't matter for most people. They want something working straight out of the box with the most important features, that's why they pay for mac computers or windows and don't use linux. Companies adapt to what the average user or a niche wants, not the concepts. Also some things must be linked together, like user authority and reading or writing to files. If they were singular models/classes/functions, you would have a lot of boilerplate code, which could be ommited if the system had the dependancy of modules in mind, increasing the speed of the os, productivity of developers on that os and milestones per interval.

@@michaelatorn8380 That is not what an operating system is. That is a suite of software including an operating system hidden somewhere in there. Also, please define user friendly. I would argue that depends on which user you're asking whether it's friendly or not. Please also note that I did not say anything about users having to be technically minded. You can have an efficient, lean system and still not require the user to know the details about it. Also you assumption about Windows and Mac OS is wrong; people don't buy Windows or Mac OS on their own merits, but rather because it is what either comes pre-installed with their hardware, or because it's what they know from somewhere else or what other people tell them to use. For many, many people it boils down to either "does it run MS Office" or "does it run my games"; pretty much any other use case is irrelevant for the average Joe or Jane. The fact is that a lot of the technology that is en vogue today in the software world at large is problematic at best; we have those insanely fast machines and the software we use on them still manages to bring them down to a crawl. And that is the real shame in today's computing world.

You're completely missing the point, out of ego hurt. And it's understandable, since his examples and criticisms of 'modern programmers productivity' is ludacrisly stackhanovist. "If you can't invent an OS in 3 weeks then you're trash"... Yeah ok lol, F U.

@@michaelatorn8380 Visuals, design, security, " look pretty "; pretty its different for everyone, yes I do thank having nice UI, but sometimes it gets stupid, like an overdesign, If i bought windows I want to use windows, not mac, then why is W11 looking like mac? as I said, if i wanted a mac id buy a mac, get ur sh*t together and follow a philosophy

don't forget running the PR through 3 cycles of pointless revisions

Thats what happens when you let communists run shit. They have no concept of an ideal world without incessant state controll.

+Max Ratajczyk Most of the software are not touching anything near distributed system though, and they are made as if they are.

Distributed system is the correct Computer Science term. How many times Distributed system are rebranded ? RPC, CORBA, SOA, Microservices, REST, SOAP, EJB, DCOM .... By the time one generation of programmers figures problems and solutions and patterns, there is new generation of programmers that have to learn the same thing but with new name and the cycle goes on. Of-course programmers aren't productive because they spend time to learn new rebranded tools. And by the way, IBM is doing distributed systems since the 60's on OS and hardware level

his point is that we have created too much accidental complexity, that we are repeating ourselves solving that complexity with.. more accidental complexity

I statically link my programs. The only problem is if you make a program with a few gigs of assets and then does it really make sense to embeds all of those assets in your .exe ?

@@KANJICODER YES. That's why god made virtual memory. As in you stuck it in the binary, and its up to the OS as to how it wants to optimize loading its pages or not, or even shifting those pages to near line memory.

It's also about disk space.... If you've ever worked in a bigger projects, you'd know that a lot of libraries are linked dynamically for edge cases, as well as more support. In which case, if you link it statically the final executable can increase by tens of MiBs to even hundreds of MiBs of just bloat Now this might just be another problem in on itself where programmers dynamically link to everything they "might not need". If you've ever used gentoo linux, you'd know how much bloat most programs are, but just removing it is not really an option. The average user won't know how to configure the proper flags for their system, that's why those bloat are necessary.

@@jamhamtime1878 So for a $79 1tb SSD (Amazon prices), 100 mb is 0.0079 cents. Congradulations! You have saved about 1/100 of a cent.

@@scottfranco1962 for one program, now multiply that to how many programs do you have installed on your computer. I have around 22GB of shared objects/dynamic linked libraries. Sure a program won't use all of them at once, but that kind of redundancy is just a waste. You're just being that developer who refuses to optimize their code because it's 2022 and computers are fast anyway, just get a better computer.

You say you don't like managed languages but point out one of the main problems that led to their creation. If you want to decrease your chances of having a memory leak, you use a garbage collector or something like Rust (maybe C++ with clang-tidy, but that's not as comprehensive).

@@maleldil1 Just use RAII wrappers for everything "owning" and you'll never get a memory leak again.

Memory arenas and circular buffers are common solutions to memory management problems - you only do very few permanent memory allocations for each subsystem and then never worry about it again. If you program specialized batched functionality instead of generalized and atomized object-lifecycles then it gets a lot easier - because you can just step through the code and literally see what's going on without keeping track of complex blackbox states (and their possible synchronization requirements). Similarly, multithreading is often deemed very complex and costly but if you see "critical sections" as an inherent design mistake, then it becomes virtually a non-issue to manage.

To be honest, I would argue that the cyber security tools and machine learning tools for efficient data processing especially in the current energy shortage are extraordinarily lacking. An example would be the sheer amount of data vulnerabilities that have dramatically skyrocketed since 2 years ago targeting firms and government databases that hold private sensitive data. The modern tooling as constructed currently has introduced greater complexity, high processing consumption costs for data processing and inconsistent data integrity tools to tackle data management and aid data security at a higher development, business and user cost. The so called 99% that are not making indie games are consuming complex tooling that require ppl to have knowledge of not only programming high and low level fundamentals but systems engineering especially when your business that hires you values that you make the best decisions to not sabotage their products, services and customers. In the not so distant future with infrastructure technology projects been brought back, the only developers that will be favored in this market are going to be high skilled devs with those fundamentals that are apart of that minority since a lot of that technology will touch critical systems like medical device interfaces, private internal data security company tools, avionic engineering interfaces, etc. Even in not-so highly technical fields like making microservice full stack apps, my team and I had even worked with a lead engineer where we did a concrete cost/benefit analysis of how fiscal company resources where going to be redirected to a separate state project along with writing the algorithms to port millions of records to the more efficient health provider system and it ended up saving the company billions of dollars. Not to even mention, the current employer cut out some employees in this time period and only retained the teams whom had the development skills to not just code JS, Java or C# apps but can test models analytically and argue for the best possible business solution on improving systems. Most developers are just not productive only from the aspect that they do not have the ability to make the internal tools for their company to use to control their dev environment especially when it comes to highly sensitive user data that has high regulatory costs imposed for failure of securing that data from the application end to networking end.

@@georgeokello8620 I guess from your perspective, as you are clearly in a more senior position, that makes more sense why one might thing think developers are not productive. Thank you for elaborating. You make valid points but jonathan blow clearly is not arguing with that approach, he is basically indicating that developers are doing nothing these days. He also brought up that mis-directing graph of the growth of facebook employees over the past few years and compared that to how many new features have arrived at facebook, which is a terrible comparison considering facebook has so many other sub domains like Meta, Facebook dating, etc

That would be cool and all if security, privacy, and goals were actually achieved. If you look at the world right now, all of those things are not happening. Like, fucking kids will be holding big corporations at gun point and they need Daddy FBI to sort things out

He is talking nonsense to be honest. Ten years ago we couldn't have imagined what kind of sophisticated programs we're going to have, he is pointless. Programs are advancing, market is very demanding, competition is very high. You can't afford writing in assembly or C unless it's absolutely necessary. Point about Ken Thompson is utter bullshit, first Unix was pretty simple, and Thompson is one of the strongest engineers out there. Software development is in its current state is not at all caused by some accident. It's a very competitive market, no one can afford to build their own stuff from scratch (like web-frameworks, game engines, etc.), to learn memory management for 10 years. What Ken Thompson would do in 2 weeks modern Jr. Sw Engineer could import with one command or install in 10 seconds (talking about productivity). He just pulled it out of his ass.

uh, no offense but it seems that's why you are 'a non-programmer'

right? you don't need an installer. on windows, all an installer does is add registry keys and copy some binaries and maybe create a service. on linux, all an installer does is add some config files and copy some binaries and maybe create an init script... you get the idea

Exactly all installers rly do is copy the file to a certain directory and add like a shortcut. Even with something like a flatpak i can just take the binary move em some place else an run it just fine

It's true for single-host solutions in monolith architecture, but once you deal with microservices that have dependencies and which are distributed among multiple servers, then you absolutely need something that is essentially an installer to configure all services to work with each other and upgrade everything without turning installing into full time job.

@@Gnidel Instead of microservices, we should make nanoservices for our microservices. Then I heard it'll be even more flexible and I'm sure it won't have any bad consequences

You have no idea what the video was trying to say.

@@BaremetalBaron watched the vid and my career is software dev. I understood it and disagreed. Take two projects with roughly same amount of code and complexity. One can be easy to add features to and the other is painful and bug ridden. Why? Nothing to do with modern programming and everything to do with bottom tier engineers in over their head. Getting paid 150k salary doesn't make you a good engineer either.

​@@CarnesSurefire I agree that it's Jonathan's problem that he didn't communicate his points very well, not yours. There's a lot of OS complexity that has nothing to do with security, but of course it's not everything that's unnecessary. As far as I recall Jonathan's view, he basically wish that every game shipped with its own OS, like the old days, so there were no security issues. In my mind he basically does the very first thing he criticizes: he takes a warranted critique of modern software development and extrapolate it way too far - because all he wants is more control over the software he makes - and since he knows there's orders of magnitudes of waste and unnecessary complexity in modern software, he oversimplifies it.

Although Unix OS is widely used and is highly important, the initial release was not that complicated compared to modern standards of programming. Plenty of CS undergrads build OS’s or compilers for their own language. The number of cases you have to cover for these are actually quite small, even though they are so pervasive.

The original Unix wasn’t that complex. The creators also had the advantage of knowing how to actually build an OS going into it.

" Complex requirements create fields in which one can grow " Tell me what complex requirements ? Man on the Moon in 1969 that is the most complex requirement ever and it was success. Or you mean get all user data you can think of for better advertising ? Tell me, what is more complex, Man on the Moon or collecting user data ?

@@JosifovGjorgi Sorry for the lengthy answer, but I wanted to drive the example. Big or important does not mean complex. Flying to the moon is an amazing achievement, but modern requirments are much more than handling the hardware and reading from sensors, not an easy task, but much smaller set of requirments are needed. Let me give you an example, I want the user to enter any email after which we will send him an invitation after which he can set his PIN code if he is on mobile. We also want him when he clicks on the link from any phone to start the application and go to that certain page and set his PIN. If he is from the website then we want to show him another page. Once he has entered his pin code we want to enter his phone number and send him a SMS verification, after which his phone will be registered in the phones he is allowed to enter from. We also must have a dashboard from which to control him and check his documents, which he will either have to provide by email or from the mobile program. This is only the registration mind you. Now let's consider when he has slow or no internet, that he is using any size phone or any browser of any version, even older phones/browsers. After all, we need to display the user the right view of text and such so he can actually use the program. I don't know have you seen but on windows but if you don't set scaling then you will see that this is an issue. We also cannot make our SMS center from which to give out SMS, since that's also complex, tied to telephone providers and such, email is the same. So we must rely on third party solutions in order to make everything happen. We also need to host everything somewhere and we must ensure that once the program that we're hosting goes down, there is a backup, that there are constant data back-ups, since if we loose all of our client information it will be a huge problem. So what do we need so far? Front-end dev, back-end dev, sys-admin, sms-provider, email-provider, front-end framework, back-end framework, server or cloud. It's not that big as in the terms of flying a rocket, but it's much more complex in the relationships between different softwares that constantly communicate with each other which of course create specializations, because you can't know it all in depth. It's not as simple as Jonathar is presenting it. His game the witness took the same amount of time to develop as the apollo.

@@JosifovGjorgi Clearly it's collecting user data without ur users leaving

As your application grows, it gets significantly harder to maintain. Changing one small piece can have large effects on other parts of the system. KZfaq has actually added a lot of features, including 'Download', 'Clip' and 'Super Thanks' etc. for the end-user, and a lot of analytics tools for creators. They've also done a lot of experimental changes to layouts, removed the dislike counter display etc. Some features might seem extremely simple but implementing them at the tremendous scale KZfaq does has many other issues you need to deal with. If you think the 'like' button is just about storing a 'like' counter in the database, you're probably right, but it's not that simple. Every 'like' is going to be associated to the person who did the 'like' (you can view your list of liked videos), so it's possible they store the 'like' as an association between your profile and the video that you like... but if it's stored that way, how are you going to display the counter now? It's not just querying one value from the database, you now need to aggregate all the likes from all users every time the video page is visited (so that you can display that updated value to the visitor) - imagine having to search through all users' profiles, looking at whether they liked that video, and counting that as '1 like', adding all of that up and displaying that as a number on the video page every single time someone visits it. This is obviously incredibly inefficient though you get the most up to date like-count this way. KZfaq almost certainly stores and reads the 'like' counter directly for the page, and then periodically updates it based on aggregating the likes across users; this is why you don't see the like/view counter updating in real-time or changing every single time you refresh the page. Now what about providing notifications to the uploader about a video that was liked? How do you efficiently store data that's going to be queried by hundreds of millions of users everyday? Do you need a distributed in-memory cache to handle the like counter and write that value to the database much less frequently? What about when a video gets liked and unliked and liked again? What about the recommender systems that interact with a video's like count? Should a creator wake up to see 10,000-100,000 notifications on a video for all the likes and comments? Can you imagine maintaining a site that deals with 1 billion hours of video uploaded every day? There's a lot of engineering going on that you can't see to enable the site to run so smoothly at this scale.

KZfaq’s backend is solid. Frontend has always been a trade off between usability and aesthetics. KZfaq at this point seems to prefer aesthetics. Software quality hasn’t really gotten worse. People today don’t remember the reams of awful corporate GUIs and win32 apps built in the 90s and early 2000s. Apps that had the possibility to bluescreen your computer if they crashed (as opposed to just crashing the browser). I think people mostly remember the games. Specifically, the games that were good. Plenty of bad, buggy, and slow games were made in that era too.

It's the kind of people that write code like: if (x=0) then return (12); else if (x=13) then return (1); else return (x); Instead of: return (((x+11)%12)+1);

This is going to blow your mind, but: the world doesn't need any more hello world programs. No, really! It doesn't. The world needs, and people are prepared to pay money for, richer and more complex applications. And that's where UI frameworks come in, for which the stuff you call "unnecessary" has a purpose.

@@BittermanAndy This depends on the type of development you are doing. Maybe you work cloud based development where 10 extra HWND is necessary.

@@BittermanAndy Funny you say that while most big corpos are literally cutting features out of their apps on the daily. Everything is getting simpler, not more complex. KZfaq used to have full-blown customization for channels and now every single channel looks the same. MySpace allowed music and custom HTML/CSS for profiles, now Facebook, Instagram, TikTok, Reddit, and Twitter are all generic profile pages. You don't know what you're talking about. Like, at all

The market made a choice. You can still program in assembly if you want. Grab an Arduino starter kit. No abstraction at all if that's what you want. And the target market for the software you write is zero. Have fun.

A lot of the hidden work is required due to the accidental complexity the poorly written software has brought on.

A lot of it doesn't need to be built this way to begin with, however. We have entered an age of centralization. Decentralised alternatives could be safer (can't access millions of accounts with one hack), would be more efficient and less prone to walled garden problems arising.

Very true. Conway's law - team sizes introduce additional complexity by itself. His criticism is a massive oversimplification. Many of his claims are. But I think your counterclaim is a fallacy fallacy. Because *_a lot_* of time *is* wasted in dealing with unnecessary abstractions in modern software development. Dealing with arbitrary pipelines that shouldn't exist - out of the idea that it would be easier to use libraries and frameworks to get it working quickly. Modern software development lives in a fantasy land where everything is reusable, atomizable and generalizable. And managing states with synchronization requirements like constructors and destructors which introduces failure points everywhere that don't need to be there. Not to mention ignoring 3 to 4 orders of magnitude performance penalties of not caring how CPUs run your code, or treating "critical sections" of multithreading as necessary complexity rather than a design mistake. Or the fact that low-level languages are seen as hard when it's actually so much easier than most developers think, so long as you give up arbitrary object lifecycles. Memory arenas and circular buffers are way easier than most other memory management strategies - and way more efficient too. Instead, modern development keeps going deeper into the fantasy of abstracting away even more, and then being confused when barely understandable bugs happen and gets developers stuck for a week. Or that it can take a team of senior developers six months to implement customized sorting of Black Mirror. And when every developer adds that unnecessary complexity to their own work, then it multiplies with the minimum possible complexity that would happen with the team (and past team, if it's a historic application). So it's both, not either or.

… where many features get shutdown after data analysis, those arguments are not sound after looking at the whole picture