100% agree. One of the most fun things in software engineering is weighing the complexity of your solution to the inherent complexity of the problem at hand.

I wish you could explain that to the devs I work with. I’m self-taught and have been programming for far longer than they have, and tend to approach programming in a logical and creative way. While they will analyse and follow every theory under the sun before writing a single line of code. It’s overkill.

Abstraction is a tool not a law. It increases the number of components in the system so can easily increase complexity. So to offset that you better make sure it decreases the complexity of preexisting components.

Too much abstraction is also a maintenance nightmare. Much easier to introduce abstractions than removing them.

I think that depends on if you are making a video game, or running a nuclear reactor. In some cases, every single problem must be accounted for, or the consequences of failure will be too dire.

A sane system makes things emerge from down to top, not the opposite. It's when you take the abstractions BS taught in web dev class and apply everywhere you can that things get out of hand, exactly what John talks about here.

Yeah react is crazy complicated, I don’t do a lot of front end so jQuery feels like the Swiss Army knife that gets jobs done so I don’t fully understand why front end devs hate so hard on it now

If you went back in time and tried to tell any engineer anywhere that the best way to update a presentation layer was to maintain a complete copy of a tree of arbitrary complexity and diff the entire thing every single time any piece of data changed they would probably punch you.

Exactly!!

The problem is that the client "might want 6 pages in a year or two. Or maybe even 7 pages". React/Angular/Vue work well for building large complex web applications. The workflow is consistent, though slow. However, with small projects that will remain small, just writing out html and javascript is way faster. When I was learning Angular, it took me about 3 hours to build a single page app that updated a list of people's names. 3 hours, flipping back and forth between two different guides. It would've taken me about 15 minutes using just javascript.

"More than a half, maybe as much as two-thirds of my life as a writer is rewriting. I wouldn’t say I have a talent that’s special. It strikes me that I have an unusual kind of stamina." -- John Irving

The worst thing you can do when writing software, is to think about optimizations before you even started. Your supposed to make a shitty product first, and then optimize it as you go along. Iteratively.

I had more or less a similar experience.

What other ways?

What were you writing, Haskell?

@@TheRiptideRaptor Yea this comment makes me very curious too, I cannot imagine an industry where pseudo Category Theory is the default. I would honestly love working in such an industry because my main complaint with modern programming is having to copy+paste and write the same code in 20 different ways, having to update the code itself and recompile any time there's new content, having to put the same data structure with slight variations in 20 different places and write the same algorithms 20 different times accounting for the slight variances. The lack of metaprogramming in most languages, along with the fact that most don't treat code as data, is the primary turn off of modern programming for me. A good Lisp and a mental model using Category Theory is the ultimate setup in my eyes

C++ is a lot of category theory. Not on a level with Haskell but still.

Didn't you mean the opposite? Refactoring is better right?

he meat that you are supposed to RE-factor something after you already have a version of it, not "factor" it upfront

The problem is that companies don’t like employees spending a lot of time on refactoring if it works. It’s a modern day engineering business issue as well

@@chadkrause6574 Don't mention it then if you can. Just do it. It should make you faster in the long run if done correctly

We are metafactoring.

A somewhat baffling and concerning motto....

There is no coding without abstractions.

My professor said either way is good. Define the concrete first then the abstraction or vice versa. But 9 times out of 10 the "right way" is just whatever your team does.

I feel like the first time without abstraction is good, then second time you keep going, third time, then a little bit later you end up with 12 UI list which are all pretty much the same but different, and refactoring is deemed too complicated and don't go in the way of making juicy features that the management is only willing to alocate time for, then no abstraction is done, and the whole software is clunky and inconsistent, a well as the BA definition of it. to do an "abstract" list ellement before building the first listy list listing stuff in the UI would have saved the bloat

Richard Hammond would prolly say the same shit.

What do you mean by in-band? Also, I don't think it's a problem to model the problem before trying to solve it. It's when you try to model and preplan every solution to every edgecase you program might run into over the course of it's lifetime, which is what alot of the dogmatic approaches to programming attempt to do.

The word you may be looking for is “wise”.

It's a better way to be smart, intellect should be measured by ability to solve real problems, otherwise it's just people convincing each other they are intellectuals

@@SpeedfreakUK wise has an "ancient" connotation to me, like it has to be some old person, but i'm not a native english speaker so i may be wrong.

@@vladislavlagunoff4882 exactly !

@@hyperTorless Well at least some part of this is "ancient" or "timeless," depending on how much you like it :D

Typescript joins the chat

Yeah man, totally agree with you, when I started programming, I was crazy about the perfect abstractions, even before start coding, I was trying to figure out how to create abstractions and modules, and how to combine them all and etc. just to make the perfect code, it was so annoying and frustrating, but I pushed it further because I thought that this was the way good programmers did things, today what Jon says make perfect sense, today I have changed my approach to programming dramatically, I learned a lot from him and Casey about this.

@@paulomarcio3133 It's ok when you make a sand castle to use whatever tool you want. When building a skyscrapper, things are different.

@@ifeanyioraelosi7305 TS helped me break out of the tendency to waste time writing the framework for my program instead of writing the program. You can use classes if you want to, but it's much simpler to have related functions grouped in modules and plain types defined as you need them. As long as you don't overcomplicate things you can easily add features to what you've got. I have a TS project that I've been working on for a couple of years now, and sometimes I go for an extended period of time without working on it - but it's set up in such a straightforward way that I have no problem coming back to it and working on a feature.

@@ifeanyioraelosi7305 BS from Microsoft.

Is this still true if you want to be able to use libraries developed in the last ten years?

@@Pulchism You need to know your OOP sh*t to use the modern C++ libraries.

Not sure, you understood the issue. The point is not, that abstractions are always bad and that you should dive into it head first with no planning. Instead the point is, that these abstractions come at a cost and are not a purpose in their own right. This is often taught wrong in CS course, where people are told to mechanically apply concepts like OO and even I am sometimes tempted to use fancy new language like concepts in C++20 for the sake of it. Instead each such complexity comes at a cost. The question then becomes this: Do the benefits outweigh these costs? If it does on the other side, you can save a TON of time by going for a pattern like monoidal parsing or policy based design, early in the process.

@@breakprismatshell6270 Designing first is the way to compile everything together though. You got someone designing it and then telling others what to program. I understand you doing that on your personal projects well help you with your clarity but things have changed to where people work in teams and make structures.

@@zoneboy7091 I'm not sure this is proper english and I thought we were talking about your and mine own programs. But if that's what you meant: It's true that in most companies or FOSS projects you have a working base structure with feature-requests and bug-reports constantly poiring in. I see, why we do not want the bureaucracy of a design phase in such a context and instead prefer to just make the changes and call that agile whatever. But if you ever get the chance to participate in the creation of a completely new project from scratch professionally: I would try to persuade coworkers and uppers not to sprint our way to a" deliverable" demo in two weeks, that looks like it is functional, but actually is hardcoded to a very narrow set of inputs. Nothing good will come out of that. It will be a hot piling stream of garbage. At that early stage of a project any wrong decision you make can cost you 10x 100x 1000x later and there are a lot of opportunities to make wrong decision. So ideally what you would want is a proper design phase, where you for weeks discuss those decisions both both internally in the team and externally to stakeholders. Also you want to document those decisions. Then you implement this minimal working but scalable version of your software. And once it is done you can switch process and extend it with SCRUM for many years to come.

Yeeehaaaaw!

It works better or worse, depending on the problem domain. The power of a good programming language lies in making refactoring easy. Where programming languages fail to provide that, you can use abstraction to make it easier to shuffle stuff around later on.

sure, but you just don't need before you have something working in the first place

@@itellyouforfree7238 I'd rather spend a couple of hours writing abstraction than tens of hours to restructure my entire program

@@dimitar.bogdanov sure, we'll play with out toys in the meanwhile

You can make an application scalable without OO, but RAII types like smart pointers, atomics and data structure classes make your life much easier

@@dimitar.bogdanov your couple of hours will be spent writing the wrong abstraction, if you do it too soon.

I've been scrolling through the comments wondering why noone is mentioning tests. So thank you!

Tests first are more often than not a waste of time, and depends on people truly understanding the full scope of the problem they're solving. Or, alternatively - tests are written for things that aren't necessary. Tests written for bugs as they occur makes more sense - prevents people from accidentally recreating them, rather than trying to prevent every possible issue ahead of time (before knowing what they even may be!). Tests-first is another "this issue happens from time to time, so I'll use this overcomplicated mess as a silver-bullet to end it once and for all!"-kind of thing.

@@NukeCloudstalker I have to agree that tests certainly can be a rabbit hole. Especially, as you point out, when the people writing the code are not fully aware of the problem they are trying to solve. But I have to say, it depends on the context whether or not testing first is truly useful. If you are writing complex systems that interact emergently, then unitizing and writing tests for that is near impossible. Certainly, you'll want to write tests as bugs happen so that you can ensure the code does what is expected and does not regress. However- if in, say, a web application, you can define some business rules, for example "all users should get an email when they sign up" or "users with an admin role can access a dashboard"- then unit testing whilst writing the code becomes incredibly useful. It allows the code to be written in the simplest form that satisfies the business rules and prevents bad refactors. I don't think tests are a silver-bullet and they do add extra complexity to a codebase, but if done right I think they are well worth it.

@@kevinrobertandrews "But I have to say, it depends on the context whether or not testing first is truly useful." I'd be inclined to grant you that, if you could give me the metrics and reasoning for that usefulness - if not, I will oppose it on the face of it due to the sneaky truism that it is. You may as well have said "it depends on the context whether or not what I am saying is true" - a good way to give the appearance of a sound argument, without actually saying or arguing for anything, to be sure! But ultimately, it sounds more like the kind of thing someone would say to reduce tensions in some meeting on the corporate job, rather than to convey anything substantial. "It allows the code to be written in the simplest form that satisfies the business rules and prevents bad refactors.". And this wasn't allowed before? At the very least, you've got to say why and how exactly this practice in any way increases baseline "code simplicity", and by which metrics you've found this out - otherwise all those words are nothing but meaningless scribble, or in this case, pixels. I say this not to be disagreeable, but because I've encountered dimwits who think -no, INSIST! - that "no more than so and so many arguments in your functions, no more than so and so many lines in your functions" and so on, is simplicity - when it in fact contributed to a needlessly complex codebase where all sorts of ludicrous workarounds had to be engaged in, in order to meet those insane demands - only to then revel in making rulesets for how to structure that mess they called an "architecture", imposing even more crazed demands in so doing. Suffice to say, I quit that job. Even if you are right, and tests are useful "if done right" (another truism-like saying, define "right" for the love of all that is good!), then you've made no proper attempt at presenting a proper case for your beliefs! Pythagoras once said "Silence is better than unmeaning words". I really hope you'll take that to heart - I'm pushing on that point so strongly because it really is impossible for me to get anything out of your reply, other than "I see what you're saying, but I like tests". Your entire message could have been that, and I would have been just as wise for it. Which is tragic - because I'm sure you've got a wealth of experience and knowledge your drawing upon to be making your conclusion from - it is just nowhere to be found in your reply. That said, I would very much like to hear the why and how you think tests can help - there is a very good chance you'd impart me with knowledge I'd have to earn the hard way myself, or may never find, if you went ahead and explained those why's and how's.

@@NukeCloudstalker you're talking about a large batch of tests here, and the big batch is the problem not the test-before-implementation. Choose a requirement. Write a failing test for it. Fix the code to pass the test. Write down any arising requirements. Prioritise the backlog. Repeat.

Ikr. Its why I wanna go into embedded system as a CS major rn. It was so fucking easy to code C on my arduino back in grade 3. But the moment I tried running shit on my computer??? All hell breaks lose. Thats when I heard the term "soy-dev" bruh. I thought I was learning shit at first but bro holy fuck. All your learning to do, is working with the braindead faggot shit that was created by clowns that THINK their making life easier, when all their doing is just adding complexity.

Litterally I made my own computer out of TTL chips. The sheer amount of easily traceable logic in it was amazing. Then I realized how fucking needlessly complex modern day soyware engineering was bruh. Like really, you have all these yt channels talking about how migrating from one database to another is somehow "engineering". Like legit all your doing is just using one software product over another. If thats engineering, then downloading minecraft from the appstore is engineering.

If you look at the average functionality a full-stack app created today has (let's say, a modern website compared to one from 2004) you will realize why the abstcraction is needed in a lot of cases. As a web developer, i can build a simple static website with PHP, HTML and CSS in a matter of minutes, maybe also sprinkle in a bit of JS. But if i need it to have users and user login, the ability to change user passwords, to use 2FA, to have users submit content (like comments), even if it's something like a very rudimentary, simple blog, i am MUCH better served by going to a framework like Laravel or Codeigniter instead of doing the whole thing in pure PHP. It just saves a lot of time on maintainance, improves readability and allows easier scalibility and adding new features (and it might improve performance, depending on if i can make it better in pure-PHP or not, which most people can't). And that's just a blog. Don't even get me started on something like an e-shop, or hell, a more complex science app. I used to work at a company that had a legacy pure-PHP eshop, and making any change than just a simple content change to the HTML was a NIGHTMARE.

​@@honkhonk8009everything is complex if you need to work on it with lots of people. And you're plugged in to a enormous tech stack out of sheer necessity if you want to make somewhat reliable, scalable affordable software and not spend a decade replicating effort that a dozen giant teams already did previously. Sure a lot of it is simple data plumbing but someone has to do it and not mess it up. That's engineering just like your local highway ramp was engineered. It's not sexy and flashy and the civil engineer that did it would have probably preferred to build a sky scraper but he still does it because it pays the bills and someone needs to do it. And I hope he's being careful when changing concrete mixtures for whatever reason and thinks about it a little deeper.

@@honkhonk8009 LOL

Lol, everyone who disagrees with you has never had to modify code. Get out of here.

I more-or-less subscribe to this message and I've been modifying existing code for over 40 years.

@@donjindra You are obviously lying, Martin said you cannot have ever modified code.

@@amentco8445 What? Are you claiming to know I've never modified code? Please elaborate.

@@donjindra it was sarcasm. He was mocking the OP, not you.

The problem with OOP isn't the "object" part... it's the "oriented" part. Whatever you're doing you still need to bundle data together somehow (aka an "object" / struct / class etc.). The whole idea is that you want your data to be entirely separate from functionality. You don't want to architect systems and write functionality trying to mold it around this whole concept of an "object". Do you need to have multiple pieces of data, such as an unsigned integer and (maybe) a flat buffer and they are implicitly related to one another because, maybe, they both describe an entity in your program? Then you bundle them together in an "object" / struct / class etc. (however you want to call it). Next if you need to operate on said data, just write a function that takes in your data bundle as input and mutates said data. Whenever you're packing functionality into your data bundle, you're basically acting as if you'll only ever apply that functionality on one entity at a time... when in reality you want to apply functionality and mutate multiple data bundles at the same time. And at some point you'll find yourself needing that same functionality applied on other types of data bundles, so you go and make crazy things like creating inheritance trees, and maybe start implementing interfaces and virtual functions etc which wouldn't have been needed in the first place. In OOP there's also this silly concept of data having an initialization stage, when in reality data is just data... it doesn't have these kinds of concepts. Data only exist or it doesn't, and if it exists you can mutate it from one state to another. That's it. And, based on how memory gets shuffled around physically and how these physical systems were architected, you usually want a new piece of memory to represent zero. You have to remember that memory at a base level is just a contiguous flat block of addresses pointing to containers. Everything in memory is just a flat buffer, which you want filled with zeroes as an initial state (do not confound this with the RAII initialization stage I was previously alluding to). It doesn't matter what you call it (buffer / class / struct etc.) or how it looks in code.... it's all flat arrays all the way down. In OOP and RAII data and memory (which is essentially just a data container and not the data itself) are conflated and the act of getting access to storage is mixed in with the act of mutating data's initial state, while also not even taking into consideration the fact that data itself is used based on scopes within your program. You have data which has a permanent scope and exists for the entire duration of your program. Then you have a multitude of temporary scopes, such as data that only exists for one frame, or multiple frames, or one game level etc. You want to build storage that accommodates all of these scopes and allows you to clear multiple sets of data at the same time within the same scope. By introducing constructors/destructors and other RAII stuff you're basically saying that you don't care about those scopes... and basically kick the can down the road. And your compiler doesn't really know anything about the scope in which you want to use a piece of data (except for the braces in C/C++ which define a generalized stack-based scope so there's a way for the stack to be unwinded). Then you start introducing smart/weak/shared pointers, because of course you suddenly realize you ACTUALLY NEED data that lives for the entirety of a custom scope, but you're still in a stockholm syndrome relationship with OOP and RAII and still feel like you shouldn't have to deal with it for some reason... At which point now you have to introduce garbage collection and other sorts of weird systems that basically have to guess the scope of a piece of data and delete it accordingly.

Also way easier to maintain. Litterally all the stupid soydev shit comes from when people try to make it so you get more outta each line of code. Thats braindead asf. Id rather everything be verbose but highly consistent, so its easier to understand instantly.

@@honkhonk8009 The Keep It Simple Stupid (KISS) fits programming perfectly. Don't over compicate :) Particularly if you need to review your code 15 years later, as I have previously. You wander "what the hell was I thinking" :)

In fact, that's how the standard libraries work, and why they are hard to write--they have to be as minimal and as useful as possible.

Pretty common scenario, a lot of code doing nothing then implement some "design pattern" that in the end just cutting directly way of solving the problem to some kind of puzzle programming, a lot of jumps in the source that is just solving nothing.

30 is acceptable, as long as, even you said it, they do nothing :)

I've come across a Java codebase that has a class dedicated to solving the problem of whether an object within that application is anything at all. The class was called IsNotNull and it had one static method which checked, you guessed it, whether the argument given was not null. I'll leave the double negation to what it was, but this was production code used in - I kid you not - my country's election system. It was basically a glorified spreadsheet that sums local election results. In about 600 source files spread over dozens of directories they managed to solve two problems: summing up spreadsheets and printing out a report. Or actually, calling a system library for the latter.

@@jbird4478 this sounds like my country

That video paints a very one-sided picture. It brings up some valid points, but I'd take it with a grain of salt.

I agree and actually never got into any other low-level language than C. It makes no sense that we suddenly started to rethink everything around this framework when C could achieve everything we needed. I slowly abandoned programming when it became all about C++ and javascript. Sad!

@@hyperTorless C lacks some nice abstractions and tools that make procedural & functional programming easier (think abstract data types with generics) coding without GC is also a pretty huge pain.

@@mohamededrah7908 garbage collector and generics has nothing to do with OO

I know that it doesn't, I'm just saying that programming in C is harder because it lacks those quality of life features, you need to be more responsible and vigilant when you write code with manual memory management.

Most pieces of software developed by large teams are shit-shows. Most good software has either a small development team, or a set of small development teams working on more-or-less self-contained parts with highly-skilled benevolent dictators enforcing rules and doing the integration (like the Linux kernel.)

@@dfs-comedy A set of small development teams are just a large team lol

@@Jacob-mh3rp If they are relatively isolated and independent, then not really.

Can’t programmers in large teams read code?

@@ifstatementifstatement2704 seems like they cant lol

Rust is better, for me the best language I have ever worked with.

@@brentsteyn6671 I have seen a lot of good things about rust and it's high on my list of to dos, but first I must master apl

I mean yeah, java isn't great, but as someone who has a lot of experience in java, because of university, but also as someone who doesn't really subscribe to any specific design pattern, I can wholeheartedly say, that it is categorically not the language that you are working with, but rather how you use it. You can write procedural only code in Java, if you want, I'm not saying that, that's necessarily something anyone wants to, or should do, but what I am saying is that while yes, some languages give you more tools for specific applications or design patterns than others, you can really do whatever the fuck you want. If I need an object, to create a higher level of abstraction so that the code I'm writing is easier to follow along with - then I will. If I do not, I will not. I think that people take a very misguided approach to OO in general, where they try to model the world around them, when that's not what it is for! OO is for abstracting and organising, and not necessarily for modeling. Yes sometimes class hierarchies make sense, but they're not the be all and end all of programming. In fact, at my job currently we use C# for developing our backend for our various web based applications, and while I am not in love with all the boiler plate I have to sift through on a daily basis, there are some things about it that make sense. For example our most recent projects are very well organised and designed in a fairly, but not exclusively OO way. However the legacy systems are an absolute fucking shitshow. They're both OO, but the structure of one is terrible, the structure of the other is good. That's what makes the difference. Now you could argue, and you should, that you don't have any of this bullshit with procedural, which is true, but in large enough projects it may become somewhat difficult to handle, especially if there are multiple people working on the project at the same time, ESPECIALLY if they're not necessarily based in the same place, like the team in the company that I work for aren't. However the same principal applies, procedural design that is good, will be just as good, if not better than OO design. My point, then, is that it is not about what design pattern philosophy you subcribe to, but rather that good design is better than bad design, no matter what you initial approach is. So then, bearing this in mind, why does it even matter what design pattern is used if it is used in the correct way to create well structured and easy to understand software? Instead of going into the absolutely fucking moronic tech evangelism bullshit, as so many programmers do, why don't we just, idk, focus more on writing the actual code in ways that we, as individuals, or as teams feel that will serve the program and the end result in the best way? Whether or not I personally prefer Java, or any OO language for that matter, is a totally different discussion entirely. Personally my favourite language is Rust, because it feels good to use and I love the way the syntax looks, but not for any actual practical reason, other than I suppose performance.

​@@brentsteyn6671shill

DRY is good, but often times composition makes your code less coupled than inheritance.

It doesn't make programming easier. It's a cop out to justify writing sleazy code and not having to do the work to fix it. Code that is written in the sub classing bullshit style is hard to refactor and is downright impossible to optimize. Well, naturally, if you never optimize anything then you wouldn't notice that part. But there is styles of code out there that are both refactorable and optimizable at the same time, and it's not the OO bullshit.

No real usecase has ever been found

Hopefully you figured out how to kill some of those DLLs or make them static.

Had you inherited the OS modules and the games, or did you write them from scratch? Developing inherited code is much harder, because as we are developing code we build a mental model. We do not remember all the code we wrote, but the mental model helps us understand what the code does. When new people come, they do not have the mental model, they struggle, they become afraid to refactor and end up with 600 dlls

@@user-mc5tp5mv3v you're spot on with that. I can still remember more about a large c++ application I wrote 25 years ago because I wrote all of it than I can about most of what I've worked on since 2000. The OS modules were university Minix tasks. The 3d wireframe game was from scratch. No libraries. Some assembly, but mostly C. It was supposed to be network battle zone in 1993. The 3D part was finished and I was working on the networking when I got my first programming job.

Let me guess... meanwhile your corporate bosses want to have that button done in 5 minutes, no one respects you for your work, you waste your time in useless meetings rather than coding?

Chose the tools appropriate for the job instead of trying to apply complex tools to simple problems!

@@designator7402 Exactly. Chosing the wrong tool (specially a complex one) for a simple job is, in fact, adding one more problem to it. Complexity where it's needed!

You just need the right abstractions to build your code. Fortunately we don't live in the computer stone age and have internet, so we can benefit out of other people's work. Work that already has been done for you. I just wrote a program that translates chinese to english using AI. Try doing that in the 90s.

@@__BLOOD__ So, you made a wrapper that calls ChatGPT? Good for you, I guess.

He has a twitch and a youtube channel, these clips are taken from his twitch, the username is "j_blow".

I agree with you but I also believe programmers, ESPECIALLY beginners, should be encouraged in messing up and getting their hands dirty. There is no better teacher than failure.

His point is that this structure should be introduced as the code gets more complex. But people do it the other way around. They over-engineer the code right from the start. But granted, if you know how massive your code will be and you know what structure to follow, might as well implement it from the start.

The structure of modern apps is impossible to create before the needs arise. Imagine making modern Photoshop -with ai, 3d and other features - back in the 90s when Alone in the Dark was peak technology and ai was a fantasy. Or a very complex algorithm in a videogame at best. They would just be done with UML diagrams by now 😂

OTOH, large projects should be broken down into small projects. The complexity may be designed in, so to speak.

@@donjindra Isn't that what microservices tried to do?

@@gmodrules123456789 There is no silver bullet. But all large projects must be broken down into smaller, more easily managed components.

Agreed 100%.

@@donjindra Even in that case, having clear architecture and intuitive structure is still doing a lot of heavy lifting for putting it all together.

huh

What? This guy worked on Thief, Oddworld, Deus Ex, has 2 soon 4 games out, made a complete programming language he uses for his games, made the game engines for his games from the ground up (2D and 3D, both insanely optimized and pretty-looking)... What are you on about man?

You can't just do what you want when you are employed, unfortunately.

@@BarrySlisk so true

Imagine programming procedural PHP with file system based logic and thinking it is the be-all and end-all. Just a quick hint: PHP itself, meaning the interpreter/JIT-compiler is written in C and C++, as is the OS you are running it all on. There are simply problem domains far outside of what you ever had to deal with, that cannot be satisfactory dealt with your approach. PHP is in itself an abomination, although that is not the point here.

@@graealex I by no means think it's the be all and end all. Nor do I disagree with the fact it's a pretty average interpreter language. It was my first API.... My point was, it solved a real problem over 8 years ago, it got the job done, and it's still being used today. Would I use php today? No. I could very easily refactor it in another language. (Juice may not be worth the squeeze) Something else I always find interesting in the developer community, is some other developer's have an emotional need to be right about everything....Its not healthy. This is the mindset that leads to over engineering and architectural bloat. Double or even triple testing the same endpoint, without any real value added to the business or derived productivity gains.

@@scottydog9997 So, what's the relevance then? Real world problems have also been solved with BASIC and COBOL. Or by hand-punching paper tape.

@@graealex The relevance is it met the criteria of solving a problem without the complexities of using other people's frameworks, or OOP, only the language forced me to think in a certain way. Its a reasonable example of what the video is talking about.

@@scottydog9997 I'm pretty sure you could solve the same problems in languages that are even worse than PHP. And no, that wasn't the point of the video. The point was that certain patterns, mostly OOP, shouldn't be an end in itself, but only a carefully used tool in circumstances that ask for it. Don't get me wrong, I started out with PHP as well, but me not knowing about frameworks and patterns that would have made my job easier is different from actively deciding against them because they aren't the right tool for the job.

Well the real system I would build for that would probably be some variety of serverless, wherever possible, so everything is most naturally stateless functions distributed over my infrastructure. When I don't need to cook up an entire object heirachy from data every request, perhaps just to fetch a property and discard it, things are a bit simpler and perhaps faster. It's also a bit simpler to deal with hetrogenous forms of the same underlying data, since you should have less code to write for each layout (you are typing and validating your inputs, right?) But honestly, your point is that the real problems not this surface crap are overwhelmingly the majority of what's going to take your time, which is true in any non-perverse codebase.

> It has a database schema, an ORM-mapping layer... Stop right there. You're done. Get out.

@@rabbitcreative Well see, that's exactly what I'm saying. People love to criticize an approach, but they don't offer a viable alternative. Explain your approach to me.

@@SimonBuchanNz OOP allows you to organize complex functionality while deferring decisions and creating loosely coupled systems where better implementations can be substituted in the future. It is valuable to think of things as higher-level boxes of functionality with grouped methods rather than individual functions. Say for example, I need something that renders & manages a form. So I create an IForm interface, and it has RenderHeader(), RenderFields(), and RenderFooter(). I create a default base Form class which has an empty virtual RenderHeader() and RenderFooter(), and a default method RenderFields() that takes in an IList and calls Render() on each field. I can create a simple implementation and then substitute more complex implementations later. Somebody can come along later and create a new type of input field, and the rest of the codebase can accept it. This ability to manage complexity and change across a long lifecyle of a project, a project that may exist for decades for example, is what I see as the value of OOP. People say OOP sucks but they never articulate a better way to do and with examples and proof that their way is better.

@@kdietz65 Yes, but so does every other approach. The technical ability to abstract functionality is necessary for a programming language to be usable. In JavaScript I generally use a bag of methods returned from a factory function, which is basically identical to a class and constructor but doesn't suffer from JavaScript's weird class implementation, and let's you compose a lot easier. In Rust you have traits, which are basically interfaces that you can implement on other people's classes, but only in a way that won't break things; and encapsulation is at the module level and very flexible. It's way nicer than how more class-obsessed languages make you work. Ultimately it doesn't matter much. If you're familiar with your language and good design, anything works, really.

What exactly?

C++ is not synonymous with OOP, you don't need to throw it away. What you should throw away is the "Oriented" part of OOP.

@@Ignas_ agree

Templates are more so a part of Generic Programming than OOP. C++ doesn't really adhere to a single paradigm, it can be procedural, OO, generic, and these days it's also getting a lot more features for Functional Programming support. All these paradigms help in different areas, and should be learned and used accordingly.

“There is not just one right way”. So why all the theories on the best structure for an app?

@@ifstatementifstatement2704 We evolved to taxonomize, prune, breed, and perfect things. It's our agrarian legacy. It's an urge that gets hijacked to service another, more pressing impulse - namely, to self-promote. But it's all done reflexively, automatically. It's not examined. Stuff is often not about what it seems to be about. It's a bid for primacy in some niche of abstraction. A mindless will to power, and nothing besides.

We are not hardwired at all, take yourself as an example, you don't follow "the group". We have to use OOP because it's required for the job, they expect it and the code base in most companies is built around it. How this came to be is another story

OOP is about making code maintainable and understandable to other programmers. If you have not encountered maintenance issues, or do not work with other programmers, (or simply do not recognize either of these things) then you will not see the value.

you sound like the "mongo db is webscale!" guy lmao.

@@AlFredo-sx2yy funny, because I would have assumed that about the guy in the video

I will add that abstraction is an important tool for readability and maintainability as well.

But procedural looks just as good and is even more readable.

OOP is not a problem in itself, it's just a tool like everything else. Over-use of OOP is the problem.