Programming thread

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
This video isn't like the others but it's some guy demonstrating live why OOP sucks. I haven't gotten experienced enough to take a side on OOP but even listening to what he was saying while I was driving sounds exactly why everytime I try to understand OOP it just seems to make everything super complicated for no reason.
https://youtube.com/watch?v=C90H3ZueZMM
No idea who this fella is but the mouth noises at the start of the video really triggered me. Stop eating/chewing and making weird mouth noises on the mic, reeeeeee. But I'll give the video a watch.

Edit:
That was an interesting watch. I think I agree with this comment:
TL/DR Smart person does not equal great programmer. There is beauty in simplicity, and it's a skill on it's own. This has nothing to do with OOP, but 100% with overengineered code
I've only used OOP in C# myself and I don't think I've ever had issues understanding code in that context. On the other hand, I barely delved into C++ as a hobby and when I see templates and all kinds of C++ magic, it terrifies me.
 
Last edited:
This video isn't like the others but it's some guy demonstrating live why OOP sucks. I haven't gotten experienced enough to take a side on OOP but even listening to what he was saying while I was driving sounds exactly why everytime I try to understand OOP it just seems to make everything super complicated for no reason.
https://youtube.com/watch?v=C90H3ZueZMM
OOP is a niggerlicious concept i agree :)
 
I have a very simple problem I haven't found a solution for and don't really want to bother writing myself.

Is there a way to take HTML, Typescript and SCSS and roll it up into a single file, encoding any images as base64? I just want to make a very simple website and serve it as a single, static file, but all of the options I've been able to find can't take an html file as an entry point, and I don't care for JSX/React/Angular/whatever other garbage. I just want my website with my scripts and for it to be downloadable into a single file.
 
I have a very simple problem I haven't found a solution for and don't really want to bother writing myself.

Is there a way to take HTML, Typescript and SCSS and roll it up into a single file, encoding any images as base64? I just want to make a very simple website and serve it as a single, static file, but all of the options I've been able to find can't take an html file as an entry point, and I don't care for JSX/React/Angular/whatever other garbage. I just want my website with my scripts and for it to be downloadable into a single file.
Webpack is probs the best option.

 
Thank you. I've spent a few wasted hours trying to find this specific type of thing, but all of the ones I was able to find were deprecated or not maintained or troonware or etc.

I hate open source software.
Tbf, I havent checked if/how well it works for your usecase. But that package seems to be for exactly what you need.
 
Flipped through a few pages of SICP instead of doing some work related reading today. Maybe I've been doing this for long enough that my ability to relate to newbies is deteriorating, but IMO it's eminently readable and makes you reason about how computer programs work right off the bat. Stuff like easing students into thinking about order in which the elements of a compound statement are evaluated and TCO have me smiling to myself internally. Introducing cond before if is especially wise. Got me wanting to write a my next few one-off scripts with Racket.

Reminds me of a guy I used to know who was adamant that everyone needs to start in Java because working with a shit ass language and environment is educational and he had to learn it in school. That mindset is how you get slop coders who need to write a 3000 line Java Spring app for shit you could do pretty easily with a few dozen lines in your favorite scripting lang or even Go or something. LinkedIn says he works for some consulting firm now; guess that means he fixed his BO problem :biggrin:
 
Reminds me of a guy I used to know who was adamant that everyone needs to start in Java because working with a shit ass language and environment is educational and he had to learn it in school. That mindset is how you get slop coders who need to write a 3000 line Java Spring app for shit you could do pretty easily with a few dozen lines in your favorite scripting lang or even Go or something.
Fuck that. OOP is like the worst way to learn to program. Literally any other paradigm is better.
 
oop isn't all that bad if you keep your inheritance hierarchies shallow and don't overuse design patterns for their own sake

you can write oop code without having everything devolve into
>ConnectionControllerFactory (extends ResourceControllerFactory (extends GenericControlElementFactory))
 
oop isn't all that bad if you keep your inheritance hierarchies shallow and don't overuse design patterns for their own sake
People who bitch about how tarded OOP codebases are never had to deal with shitty procedural codebases where some random global variable changes some other behavior in completely different function. At least when it comes to OOP, it will usually be somewhere in inheritance hierarchy.
Or with 1000 lines long functions that repeat half of each other, so any changes have to be made everywhere.

Unfortunately there is no magic paradigm.
 
oop isn't all that bad if you keep your inheritance hierarchies shallow and don't overuse design patterns for their own sake
Agreed. As long as it's just used to make interfaces or structured data types that have their mutator functions closely attached to the data, it is a decent way to keep large software projects modular.
 
OOP can suck ass but it's not that cancerous. Like anything else, it has its applications, like IIRC GUI development that it was originally used for. It's just that functional or "vanilla" imperative* programs are pretty solid for most cases.

*I hear that Smalltalk's approach is very different to any remotely mainstream language that supports OO, but I haven't ever touched Smalltalk. Racket/Scheme and Haskell are the most obscure languages I've written any real amount of code in.
 
There is a reason why I specified it being the worst paradigm for learning. Because inevitably people will think in DEEP hierachies that try to model the world instead of actually fucking solving the problem.

If you go from FP -> OOP or IP -> OOP you will produce much better OOP code than someone who started with OOP from the very beginning.
 
OOP is a niggerlicious concept i agree :)
The criticism of OOP, I think, can be summarized as saying that inheritance hierarchies force you to design and impliment your program from the top down, and the difficulty in modifying that hierarchy means you have to get it right the first time or effectively start over. Getting it wrong means introducing barriers in the middle of your program that you then have to try and get around on a case-by-case basis.
The traditional concept of OOP was that you’d base your inheritance directly on whatever concepts you were trying to model, so you wouldn’t need to do any design and the hierarchy would fall out of the problem description. The problem is that this doesn’t really work except in the simplest cases.
Modern OOP languages have features for multiple inheritance or composition or other models that diminish these problems. The age of big OOP pushing strict single inheritance and sprawling hierarchies ended in academia in the 90s, and petered out in industry a couple decades later. Now is the time of composition and shallow hierarchies, if any at all.

*I hear that Smalltalk's approach is very different to any remotely mainstream language that supports OO, but I haven't ever touched Smalltalk. Racket/Scheme and Haskell are the most obscure languages I've written any real amount of code in.
Smalltalk’s OOP gets a lot of milage out of the fact that it is dynamically typed. Whenever you do a method call on an object, the runtime looks at the type of the object and checks the name of the method to see if it can find a matching method in the type, if it can’t find anything, it looks to the parent classes until it either fails or finds a method. This means that, theoretically, two types with completely different inheritance hierarchies can be used interchangably, as long as their method signatures are the same.
Go’s interface model is largely an attempt to apply this paradigm to a statically typed language. I believe Rust’s trait system is also based around this kind of concept.
 
Last edited:
The criticism of OOP, I think, can be summarized as saying that inheritance hierarchies force you to design and impliment your program from the top down, and the difficulty in modifying that hierarchy means you have to get it right the first time or effectively start over. Getting it wrong means introducing barriers in the middle of your program that you then have to try and get around on a case-by-case basis.
The traditional concept of OOP was that you’d base your inheritance directly on whatever concepts you were trying to model, so you wouldn’t need to do any design and the hierarchy would fall out of the problem description. The problem is that this doesn’t really work except in the simplest cases.
Modern OOP languages have features for multiple inheritance or composition or other models that diminish these problems. The age of big OOP pushing strict single inheritance and sprawling hierarchies ended in academia in the 90s, and petered out in industry a couple decades later. Now is the time of composition and shallow hierarchies, if any at all.
Thankfully the industry is moving away from inheritance for sharing functionality and towards composition. Nowadays I mostly use OOP hierachies for interfaces + maybe one or two levels of base class (mostly for standard functionality). Otherwise I often just have the object store an instance of one of the classes it needs and defer most calls to that, if appropriate.

Sure it's a bit more boilerplate, but the DX is just magnitudes better.
 
There is a reason why I specified it being the worst paradigm for learning. Because inevitably people will think in DEEP hierachies
But whose fault is that? Maybe our universities shouldn't teach OOP introductory courses with retarded real-world analogues like Animal -> Mammal -> Cat inheritance. Beginners can understandably have no intuitive understanding of how these concepts are supposed to map onto the structure of the actual problems they are solving with computation.
 
Biggest part of the problem may simply be that it's not possible for working with Java to be a remotely pleasant experience. If you run into a non-technical person who's learning Java from scratch, not because "CS degree means I make a million bucks a year playing ping pong at Google" but because they need to for work or something, they always get hung up on everything about classes, public vs. private vs. protected, the difference between primitives and objects, and on and on. For a sufficiently motivated learner, it's a ton of extra information to ingest, and trying to memorize all these facts about Java (since that's what it is, you don't have the context to understand why access modifiers like public and private exist) that's time not spent on programming.

Python and JS support OOP (whatever the fuck is going on there with prototypes and ES6 and all, I hardly touch it and don't plan on touching it any more), but it's much simpler to get a noob up and running with either of them.
 
Back
Top Bottom