(untitled)

>OOP is like kicking dead whales down the beach agree or disagree? I agree. I find C++ OOP (and OOP in general) quite confussing and ugly (conceptually and in C++). I was programming a project in C++ with OOP, but using it was so uncomfortable. I was looking at my code and it doesn't seem to make sense. I tried to do the same thing in C with structs and pointers and it was really nice. I can understand what I'm actually doing, adding or removing things are easier, like the same way to correct errors.(USER WAS WARNED FOR THIS POST, You should always elaborate on your opinions rather than just spilling the soykaf.)

I like OOP. I find it allows writing abstractions in an easy way. I hate templates/generics though. They seem cool when you write them, but they are terrible when trying to understand someone else's code.

I have a love/hate relationship with OOP. It can really help with writing modular code, and it's the most widely adopted way of doing so in practice, so in that sense I begrudgingly accept it, while still sharing all of the standard reasons to dislike it. I prefer languages that encourage you not to go overboard with the OOP stuff, but give you the option for when you need it. Rust's trait system is pleasant to use, coming from C++ land, I think it's supposed to be inspired by the ML way of doing things rather than the Java/smalltalk way.

This type of thread again? Isn't the last one even still going? Also, >I hate OO because my ADT language isn't good You've never done any OO programming. Neither C or it ++ have processing protection. It has no late-binding, let alone the environment encaosulation needed for actual *message* passing. You don't know what you're talking about, and neither does any of the entertainers on twitter you probably got the idea for this thread from. I don't even particularly like OO; mostly-pure Lisp's my drug of choice, but more than anything else in CS the "debate" around this is a farce. You've bought a knock-off and decided to criticize the name brand's manufacturing when it predictably starts falling apart at the seams. Why? What about this behavior is at all reasonable?

>>39122 I'm not well-versed when it comes to paradigms or even just programming, but what's a language that has the features you're talking about?

>>39122 >OOP is message passing So Erlang and Elexir are true OOP languages? Or could it be that it doesn't actually matter that Alan Key changed his mind on some things. And what ultimately got implemented has been a specter beyond his control for a long time now which yielded us those travesties that are C++ and Java and what Uncle Bob says about it is funnily enough closer to the reality of the coder monkeys who have no choice but to use it and adhere to the four pillars of abstraction, encapsulation, polymorphism and inheritance and has little to do with what essentially is the actor model under a different name. Either way I agree this thread was superfluous while I also agree with OP that the ergonomics have been lacking in these kinds of languages but it is what is being used today since it allows for enough modularity. And that's important for enterprise cubicle fields. But good thing then that we got more alternatives now that try to be more multi paradigm like Javascript and Kotlin, so this generation's wagies don't need to suffer through callback hell as the older of us did. Was it all worth it? Maybe.

>>39124 >OOP is message passing You're right, of course. There seems to be a split between the message-passing described by Kay, that lives on in Erlang, Elixir etc. as well as libraries that implement the actor model in other languages. OTOH, there are languages like C++ that have gone in the complete other direction. As a proud wagie, the way I see it is that if you give people the tools to make unintelligible garbage, they will. Think classes with multiple inheritance 5+ layers deep. Trying to understand the behavior of such code, even when you have all the source is almost impossible. My experience is that people use member variables (instance variables) as global variables. This is bad for the same reasons that globals are generally considered bad - state "appears" from previous invocations of other functions, without a clear path of data through function parameters. Combine this with inheritance, multiple inheritance and nothing makes sense any more. Sometimes even the IDE (MSVS) gives up completely...I won't even mention recursive functions with static locals. Another way to use OO in C++ is through interfaces aka abstract classes. This is the only way that makes sense to me. You define a set of methods that can be implemented, and then other classes can call the methods on objects that implement the interface via dynamic dispatch. Simple to understand, and super-great for isolating different parts of an application/library to test. Are either of these message passing aka "true OO"? Not really. Maybe we should make a distinction in terminology between message passing aka the actor model, and "OO" as implemented by C++, Java etc. which is really a thin wrapper around dynamic dispatch, structs, functions, and visibility - something completely different. It's almost like certain languages grabbed onto something new and called it "OO" without understanding the definition - similar to how Java and Javascript are not at all related, or how "electric vehicles" are just cars...

Isn’t OO just a good abstraction to represent windows and their controls? I have the impression it just got adopted because it made sense to program desktop computer interfaces, and everything else is just a side effect.

>>39122 I never thought people would try to gatekeep object orientation. >>39134 The main goal of C++ and Java style OOP is that it is easy to write modular code. All you have to do is implement an abstract base class / interface and you can plug it in to existing code with only a small performance penalty. It's definitely not the only way to achieve this, but it has been quite successful.

>>39124 >Or could it be that it doesn't actually matter that Alan Key changed his mind on some things. Before I spend the time to dig into the rest of this, can you br specific about what you're referring to? What did Kay change his mind on, and hopefully also when? >>39123 I'll be sure to get into this in my response. >>39137 >I never thought people would try to gatekeep knowing what you're talking about. Yes. Welcome to /lambda/. That's what we do here. If you don't like it, you know where the door is.

>>39117 The fundamental nature of Object-Oriented Programming is expressed in the way it tends to be used. Namely, when we look at "the industry", we see a lot of Java and C# code. When we look at the open-source side of things, we see a whole lot less Java and C# code. Ergo, we must determine that there is something about Java and C# which appeals to for-profit enterprises in a way that some programming language like C does not. There are a few parts of this, obviously, and some minor cases like "garbage-collected language is easier" appear, but I find these insufficient to explain the difference. My personal theory is that Java and C# are languages whose fundamental nature enable the programmers who use them to be managed easier. Interfaces, Classes, etc have their *utility* in C++, but their *necessity* in Java inherently forces a level of separability which ~may~ otherwise be absent in languages which don't force it down your throat. In short: OOP was a corporate meme because it let managers split the problem between their code-monkeys.

>>39160 I agree. Speaking from experience OOP succeeded because it's well suited to a top-down design where a project manager creates a UML diagram describing a program, and a team of codemonkeys under him servilely implement that diagram.

>>39165 It's pretty funny, when you think about the fact that the *programming language* chosen relates to the management strategy, but I've heard that you can reorganize the structure of a program simply by changing the organization of the teams working on it, so ¯\_(ツ)_/¯

>>39122 came here to post this. it's a damn travesty what people came to associate OOP with in the 90s/2000s thanks to the success of Java and C++ and their bastardization of OOP. Alan Kay himself has on various occasions ripped into C++ for how soykafty it is, and it's what we have to thank for OOP becoming popular, in a cruel twist of irony. I haven't used Smalltalk much myself but Common Lisp is my language of choice and CLOS is a joy to work with in my experience. the MOP even more so makes OOP an incredibly powerful and useful tool in CL and it's the kind of thing that you wouldn't have outside of OOP.

>>39145 >If you don't like it, you know where the door is. I wouldn't say I don't like it, it's just a little silly.

>>39122 Wow, you're so sophisticated and knowledgeable.

OOP made sense for 3 seconds when i was looking for a higher level way of programming than x86 assembly. then i just realized its wrong, FP languages like ML work much better. or even any 90s imperative lang. OOP doesnt solve any real problem other than modelling "cat extends animal "which indeed applies to no real use case. exceptions are also an invalid way of programming, on par with just returning numbers like in C.

>>39186 Learn to step away from the ML kool-aid and read about smalltalk or write some lisp and understand the principles behind CLOS

>>39186 Repeating myself from the old thread again: >The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened. (Also worth remembering that Kay created OO to mimic not zoology, where disparate organisms are abstracted into non-organism taxonomies, but biology, where for example the twenty-odd various distinct tissues in your body share the exact same base "code" and are differentiated from it in a much more late-bound fashion. When was the last time you saw a so-called OO language accomplish that?) >>39188 I actually disagree with this attitude, as well. ML isn't kool-aid in itself, it's just been taken too far. The family of mathematical thought around it that leads to it and Haskell's favoring of types and categories is still be very useful for things like optimizing compilation, parallelizing transformations, and guardrailing interop with foreign modules/systems. Lisp already uses some of these, and if we had the resources it could take even greater advantage of them, so we should study it even if it's not ultimately the right thing. A proper new Lisp standard, imo, would provide things like ML and Prolog as services to the programmer like how CLOS provides the MOP, so when they are convenient they can be layered onto your existing lisp codebase, which is the right thing for building an environment to integrate such different systems in.

>>39190 >so when they are convenient they can be layered onto your existing lisp codebase I think it makes more sense to do the inverse. The majority of code that you write is easier to express with a type system, it's only rarely that untyped code is used. I much prefer the approach of the likes of C#, where code is typed by default and you can fall back to the untyped Object if you need it. The only point of issue I could see with this is stuff like the numeric tower, but Haskell manages to solve that relatively easily.

>>39169 Curious, in what circles do you exist where gatekeeping knowing what you're talking about, doesn't happen? Seems like it exists everywhere... The quickest way to get the correct answer to something is to spout the wrong answer confidently in a public forum.

>>39197 It's silly to gatekeep the notion of object orientation.

>>39198 Is there a particular reason why you responded to that user by flatly repeating yourself instead of answering his question?

>>39124 does anyone actually use Kotlin?

>>39218 have you ever seen an Android app written in the last 5 years?

>>39204 I was under the impression that maybe they hadn't read the post properly the first time, which lead to their asking that question. If they had understood my post correctly they would not have asked if there is some place where gate keeping does not happen, because I did not imply that such a place exists. I intentionally ignored the implied jab because I think it's childish.

> Between 1969 and 1971, she hosted a seminar on her work in epistemology with some dozen philosophers, mathematicians and physicists. The abstractions Rand proposed to represent knowledge in her work, and the relations among those abstractions stand, as noted above, in an exact one-to-one relatioship to those of OOP as developed by Kay between 1971 and 1976. Their architectures of abstraction for the representation of knowledge are identical; the only differences, apart from ontology, are in labels.

>>39117 Imo the way Go handles this with most things being structs that have functions which mutate them is a better way to go about it In reality most things in CRUD should be immutable objects/structs with immutable functions that handle data transformation as it's piped from API to API and from DB to DB Interfaces and composition are still very useful but I think inheritance is rarely useful and is often taught/used in a counterproductive manner Then again I'm just a junior dev so maybe I have no idea

FP is cool until you realize you need to do an IO operation, then you are fuarrrked. You need "gonads" for that. Wtf is a gonad

>>39542 Haskell is not the only functional language. Most functional languages I've used handle the problem more-or-less the same way most imperative languages do.

Look, the baseline is that OOP shouldn't be forced upon the user in any language. It should be *one of* the options when writing a program but shouldn't be the *only* option. In addition, OOP is quite useful sometimes for large programs and abstracting code. Done poorly, and it can be a pain the ass to read, though.

>>39300 Will coding in Java turn me into John Galt?

>>39582 Java is notoriously verbose and repetitive so... >Who is AbstractFactoryFactoryFactory?

>>39145 >>39124 >>39123 >Before I spend the time to dig into the rest of this, can you br specific about what you're referring to? What did Kay change his mind on, and hopefully also when? Regardless of whether it's because this user realized they don't know what they're talking about or just lost interest, for completeness I don't want to just leave what was going to be my response hanging, so here it is: >So Erlang and Elexir are true OOP languages? Insofar as a language built to manage distributed telecom protocols instead of personal computing can be, yes, it is. Which is to say that Erlang's missing a lot of the "library" resources you want to build the systems that give OO its power, but the BEAM is plenty capable of giving you exactly what you want to implement them exactly as you'd want them if you put in the time. This is, by the way, a very common midwit-level interjection I see all the time in OO arguments; you've heard of Erlang and know that it's been called "message-oriented", so you think it must be a useful counterpoint to a description of messaging in Smalltalk, but never looked into it enough to discover that Joe Armstrong originally designed Erlang as a Smalltalk variant so he could work faster on Ericsson's big iron than his Tektronix Smalltalk Machine would let him. You're letting your summarized narrative of computing distort the reality in front of you because you won't take the time to double-check. >Or could it be that it doesn't actually matter that Alan Key changed his mind on [OOP is message passing]. Same here. There's no actual evidence that PARC-era OO was independent of message-passing, it's just a polite fiction programmers on the wrong end of a procedural disaster use to console themselves. It's almost always just asserted without support, and the few attempts at actually justifying it I've seen are all either self-evidently nonsense or a lazy excercise in question-begging, and sometimes both. The reality is that the PARC team specified all the way back in the 1981 BYTE magazine article that an object-oriented system was to be composed of complete virtual computation devices fully separated at runtime and interacting only through messages, they just didn't shout it from the rooftops out of the assumption that no competent computer scientist would bother trying to frankenstein together a shared-data simulacrum without the part that obviously distinguished it into being worth doing or not. Eventually the minicomputer wunderkin would make sure to prove them wrong, though. Regardless, it's unclear exactly how to make the argument that Kay must be blamed for baiting-and-switching the hook of programming everyone got caught on at some point before his work took off outside his lab. >And what ultimately got implemented has been a specter beyond his control for a long time now which yielded us those travesties that are C++ and Java and what Uncle Bob says about it is funnily enough closer to the reality of the coder monkeys who have no choice but to use it and adhere to the four pillars of abstraction, encapsulation, polymorphism and inheritance and has little to do with what essentially is the actor model under a different name. Okay? I'd be happy to let bygones be bygones and move on by starting fresh if this was the attitude the C weenies wanted too, but this stil isn't the world we live in. This is exactly what OP started out the thread by doing, and what I was responding to in the first place. For some reason it's the Smalltalk evangelists' fault C++ doesn't live up to the hype of the real thing, and the former-Smalltalk programmers who started the programming patterns method's fault that implementing the power of an OO system piecemeal on top of a weaker substrate isn't as resilient as the original article, instead of putting the blame on the incorrect implementation in the first place. To repeat, what about this behavior is at all reasonable? Why are we blaming the inventor of a language that had a fully-reflective execution environment and reified call stack for callback nonsense, except as a sidestepping excuse for our own failings? I don't see how there can be another possibility. >I'm not well-versed when it comes to paradigms or even just programming, but what's a language that has the features you're talking about? There are several options, but honestly you should just learn Smalltalk, despite its death. It's not even my first choice, again I'm a Lisper and partial to the MOP macro system for injecting a little OO when I feel like I need it amidst mostly functional code, but Smalltalk is probably ideal to learn OO because there's nothing else in your way. It's got every type of system you need, and none you don't, to avoid complicating the process. Plus it's old enough that a lot of the resources are considered historical artifacts and publicly available as pdfs and such, so you never need to worry about sidestepping things like drm or licensing. If you're completely new to the concept of a difference between procedures and objects, this is a good pre-dive introduction that will walk you back down the path from the EADT system to olde-style datatypes, then up to functions and distributed systems, and ending at Smaltalk-style true objects with interpreters and capabilities: https://www.youtube.com/watch?v=AG3KuqDbmhM And here's a longer lecture from Kay on the possibilities and benefits that come from building your OO language the right way: https://www.youtube.com/watch?v=QjJaFG63Hlo After that you should be able to just pick up whatever manuals or books look most helpful, since you already know how to program.

>>39118 that's interesting. i like generics, but i find OOP to be unsuited for most problems. i myself prefer a haskell or rust like type system with algebraic data types and typeclasses>>39118

>>39190 It's interesting to see Julia here. It has no OO support on purpose, but it has more polymorphism than any language I've ever used due to what they call "multiple dispatch" or dispatching functions based on parameter type. >The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski | JuliaCon 2019 https://www.youtube.com/watch?v=kc9HwsxE1OY - In practice, it feels very flexible. - Things that were previously awkward to model stop being awkward.

I personally like OOP, I hate inheritance. I think the best OOP language is Go, which is not quite an OOP language at all. But it uses the same struct/pointer mechanism of C, with a little of syntax sugar, and it has interfaces for more complex dependency injection stuff. I like that

>>39526 I’m a senior dev and I agree w you

>>39117 OOP is useful to model some real problems in a good way, GUIs for example or game entities. The problem is that most ppl think of OOP as in C++ or Java and these languages were endorsed by the industry to made programmers more easily replaceable.

>>39656 >OOP is useful to model some real problems in a good way, Ah yes, a mythical elusive "some area somewhere where OOP is actually good choice"

>>39647 >I think the best OOP language is Go Which is not an OOP language which proves that OOP is actually good when you remove the OOP part from OOP

>>39657 Have you heard of GUIs?

>>39657 Anything business related Anything that's a simulation (not a mathematical simulation, like a simulation-heavy game, and pretty much every game ever made nowadays is OOP) Anything involving big data processing (Apache Hadoop, et al. basically runs the entire internet) Anything with a GUI Any project involving dozens, or hundreds of programmers over a long time, not just you and your 3 buddies Anything where it's desirable to be able to quickly teach new hires (as OOP is inherently easier to understand, and all OOP really is is a way to organize and compartmentalize your code) Aka....Everywhere except where you find people soykaftalking OOP online, who usually worship a man who's claim to fame is creating a type of EBay, saying it's all because of lisp that made his startup "better", completely ignoring that it's in the dustbin of history and completely forgotten by now

Corporations wanted to produce more code cheap, OOP was made to wrangle cheap codemonkeys into producing usable code with all its safety concepts. That's why smarter individuals hate it - against their interest. Its more work that only serves to undermine the value of a clean coder.

>>39678 OOP was made by a dude in academia few decades before it went mainstream among pointy haired dudes from Dilbert comic strips >>39659 Yes, there is zero reason to use OOP for them

>>39683 languages like java & c# were developed by a corp to their own needs, do you think your dude had control?

OO is nice, once you learn more about it Check out this video showing off Glamorous Toolkit: https://www.youtube.com/watch?v=escpKlrVgfE Object Orientation PDF: https://pomf2.lain.la/f/3xpqmzlu.pdf >>39658 I'd find it odd to call bad erlang good. I agree it isn't an OO language. >>39657 OO is nicer for compilers than say an ML type system. Objects compose a lot better than ADT's it basically boils down to the PDF linked in this post. Namely ADT's are good for when you have a closed world of things, and Objects corresponding to an open world. these both have their places and usecases. >>39676 I wouldn't cite game devs, they desperately recreate c like languages and crave hot reloading but never do anything about it. > Anything where it's desirable to be able to quickly teach new hires (as OOP is inherently easier to understand, and all OOP really is is a way to organize and compartmentalize your code) I don't think OO is inherently easily understood, esp with the horrid version of """OO""" that is used these days. I found it very unintuitive, it took me having to learn smalltalk and embrace CLOS to really see the simplicity of OO. Java, C#, C++, etc are all horribly complex and are against the spirit of OO. >>39678 Cited needed on OOP, checkout the video linked in this post talking about smalltalk

>>39688 >I wouldn't cite game devs, they desperately recreate c like languages and crave hot reloading but never do anything about it. There's only Jai and Odin and the closest colleagues of the creators (Jonathan Blow and "Ginger Bill" respectively) of those languages are firmly C-only or C-style C++-only (e.g. Sean T. Barrett, Ryan Flaherty, Ryan Fleury, Casey Muratori, Fabian Giesen, Jorge Vino Rodriguez, Shawn McGrath). So it's a bit misleading to say they all want to leave C. You can see for example Ryan Flaherty on Twitter arguing and evangelizing C and shιtting on Rust and other languages every week, it's pretty funny: https://twitter.com/rflaherty71/status/1807988671603245253 https://twitter.com/rflaherty71/status/1808606794178072777 https://twitter.com/rflaherty71/status/1814720205676859646

Object inheritance is stupid but Interfaces are not. In haskell interfaces are called type classes and they let a function take any Type a, but guarantee that that type has the class '''Ord''', which means you can order any values of that type. Using only the fact that Type a has the ''property'' '''Ord''', lets us build '''Sets''' and '''Maps''' that operate in O(log n) so it's quite a powerful but super generic concept.

>>39689 I think you are misunderstanding the point, staying with C/C++ is the same behavior. They make brand new systems in game engines that try to get around the deficiencies of their choices. Further they seem very reluctant to actually think about what languages and environments can do for them even though they make brand new environments for game developers (the engine). The general sentiment is that game devs put up and enjoy the soykaf that they eat. And yeah soykafting on rust is always funny, and well deserved. >>39690 Why is inheritance stupid? Is it a presentation issue for you? Inheritance and late binding have their use and area design consideration. If you are confused on how late binding may make things confusing, is this because you are tied to a text model for your code? I personally found inheritance very confusing in Java due to where code is located, however once you move into code being stored in a structured way, the class that inherits another class, can list those methods together and then all of the sudden, the confusion goes away. Always remember that subclassing is not subtyping.

>>39684 both are not 1st and not even 3rd or 4th OOP languages

>>39683 >Yes, there is zero reason to use OOP for them It takes a special kind of arrogance to not only completely ignore the most common approach to doing something, but also assume that everyone doing it was just being stupid and put no thought or reason into their decision.

>>39691 if you do " for(b in a) b.method() " you jumping multiple pointers with random access, if you use visitor pattern " for(b in a) method(b) " you already halfway out of OOP because you only need to externalize all methods and standardize your data model to arrive in C land where you have methods using pure structs free of class overhead. Its what games did to get the best performance. Though i dont believe modern AAA devs bother with good performance anymore. Modern way is frame interpolation&upscaling creating a blurry 120fps image worse than 2010 games and the avg moron will still happily eat it up while people complaining get to fight with bots screaming just upgrade lol. So instead of working hard on optimizing the meta seems to be get stock unity/ue5 slap on some stock assets and push it out with 50% of budget going into marketing to make sure they fomo buy. >>39692 Java is what most people learned OOP with in university. So its what OOP means to them

>>39694 I assume you are the game engine guy, or are you the anti-inheritance guy? Either way, when you say >if you do " for(b in a) b.method() " you jumping multiple pointers with random access This is not generally true. This is dependent on the object model, and what optimizations a compiler can do. For example `defunctionalization` is something that is typically done on functional languages, but here you can defunctionalize methods by making turning polymoprhic method calls to first-order dispatch functions. Much like you showed in: > for(b in a) method(b) I believe the Utena VM does this, however it varies among object systems. Further lots of optimizations can be had if you know the type information and can effectively compile away any non megamorphic calls. Around 1.8% of calls sites are megamorphic (at least for what was tested in [1])[1]. On terms of dispatch, what is nice about decent object systems is that they let you change semantics of the object system to fit your performance metrics. For example we could implement a metaobject that invokes heavy use of optimization, or perhaps even have the metaobject change the semantic, so that when we allocate an object it gets added not to GC space like most things, but allocated in a region that you can de-allocate in O(1). A practical example game developers like jon blow likes to use is the struct of array (SoA) vs Array of Structs (AoS). using the meta object system, you could implement this as a meta object and now when you want to allocate an array of objects in your structs (AoS), you could instead have the meta object change the allocation so behind the scenes it's really an SoA (Objects with Arrays messages). By embracing good object systems you can tweak how dispatch works all the way down to allocation, and the objects would look the same from the user's POV. Either way my point is that the Object system need not have a negative impact on how your dispatch works, nor how your allocation patterns can be had. Further good compilation techniques is really what you are after and making them reliable which is something we can do. A bonus paper: https://www.researchgate.net/publication/373113914_Experience_Report_Kandria_-A_Game_in_Common_Lisp Overall this paper didn't find the overhead of CLOS too bad (note SBCL while fast, is still horribly dated and slow in ways which we with 40+ years of fore-site can do better. SBCL was out before SSA even existed). [1] https://hal.science/hal-01883380/document

>>39696 Wasn't either of the previous guys. Just a guy who read older c/c++ game design books and decided to write down what he remembers. The idea was if you use polymorphism with different functions and just let each object call its respective function your compiler wont merge the functions into a single function. It will flip between them and if the functions are large you will also not keep them in memory but reload on every call. Writing a visitor yourself ensures its a singular function that doesn't need to be swapped. So visitor ensured you dont risk loading functions on top of parameters in cache each call. Next objects have class metadata so higher foot print. Pure function + struct array is the smallest footprint possible which makes it more likely to avoid cache misses and simple sequential array read allows prefetch to do its job best. Things might have changed but that was the thought process the authors presented. Having large classes also adds overhead. Object methods get loaded in case they get used when compiler cant tell if they never get used. That's why they preferred to make their own over using standard lib. Some of the old advice is outdated for certain. One example is std::vector<> in c++ used to be bad because it would double memory whenever it hit the limit so it would eat memory crazy once it got larger and remain 49% unused worst case. They changed that a few years ago and so "avoid vector like pest" isnt relevant anymore. Whats bugging me on personal lvl is i find debugging with objects encapsulating data harder than simple data models since its obfuscating data in debugger. Methods also often don't do what they insinuate. I.E. when i do a[20] i know i can access a[19] while vector.reserve(20) doesnt allow immediate use of vector[19] , they call it an array but it runs like a glorified list that needs sequential writing all fields to access end.

>>39698 Yeah I caught the gist of what you were arguing, I was mentioning that compilation techniques can solve this problem so you don't have to defunctionalize by hand, which what you showed was. > One example is std::vector<> in c++ used to be bad because it would double memory whenever it hit the limit so it would eat memory crazy once it got larger and remain 49% unused worst case. They changed that a few years ago and so "avoid vector like pest" isnt relevant anymore. Yeah... C++ isn't great, I wouldn't argue much is good about C++ > Whats bugging me on personal lvl is i find debugging with objects encapsulating data harder than simple data models since its obfuscating data in debugger. Methods also often don't do what they insinuate. I.E. when i do a[20] i know i can access a[19] while vector.reserve(20) doesnt allow immediate use of vector[19] , they call it an array but it runs like a glorified list that needs sequential writing all fields to access end. I think this depends heavily on your language, in a language like smalltalk you have custom inspectors and views. There are no private methods in smalltalk btw I posted this video back in >>39688 but: https://www.youtube.com/watch?v=escpKlrVgfE check out some of the tooling in GT, you can just define yourself better debugging tooling if need be, the heritage of OO (not the bastardized version in C++) is that of trying to give tools to help you do your job. I know when I'm in the inspector in GT it feels nice, I have graphs of my objects live, even if I have a bug in my code, I get partial graphs for the parts that did run nicely, meaning I get a lot faster at detecting problems deep into my system as it's explained nicely.

>>39676 >OOP's great unless you're a lisper He lacks the critical information!

>>39700 lisp is just a less readable python

>>39701 >python is just a less readable lisp There, fixed it for you. Heck, even C is more readable than Python. Using significant white spaces as block delineating is the worse idea since NULL.

>>39701 tell me you've never wrote lisp without saying you've never written lisp

>>39711 why would i write in a language that has 0 jobs

>>39712 sorry for assuming you're not a code monkey glitterboy who doesn't actually care about programming. https://news.ycombinator.com is that way

>>39710 the readability of a language is subordinate to its application python is more readable in the context of its most common applications. lisp is more readable in the context of its most common applications. good luck having your coworker debugging your API shim or data science solution you so Epically wrote in lisp

>>39714 how does it feel when javascript is a more popular lisp than lisp is

>>39712 Many reasons. The principle one is that it makes you a better programmer. All programming languages describe the same mathematical and logical concepts, they just do so differently. Looking at things from another angle gives you a much deeper understanding of what you're doing beyond the quirks of any particular language. Speaking from experience, learning Smalltalk, Haskell and Lisp made me significantly better at Python, Java, and C. >>39719 Calling Javascript a more popular Lisp than Lisp is like calling C++ a more popular Algol than Algol; it tells me that you know very little about programming beyond what's absolutely necessary to cludge together webshit. Outside of very basic things like garbage collection and dynamic typing that have diffused their way into a million different languages, Javascript owes very little to Lisp that is distinctly Lisp. Python owes even less.

>>39720 its a well known fact that almost everything good about lisp has been slowly incorporated into other languages over time such as that the reasons to use lisp actually diminish over time, such that it's mostly to do things like this: https://aphyr.com/posts/342-typing-the-technical-interview is this person a better programmer than me? obviously. is this probably one of the most beautiful ways of solving the n-queens problem ever? also obvious. but nobody needs to know how to do this. knowing how to do this might make you enlightened, but it doesn't make you good at building anything. there's programming as art, and there's programming as craft. good craftsmanship can be art, but a good craftsman doesn't deliberately seek 'art'. this is why nobody who actually wants to build something elaborate and grand will bother learning a language like haskell and lisp, much like how all the branches of mathematics that can be more categorized as "art" than "theory" or "science" are broadly ignored by all except those who choose to indulge in them. one day FP users will have to learn their lesson as well

>>39721 >this is why nobody who actually wants to build something elaborate and grand will bother learning a language like haskell and lisp, much like how all the branches of mathematics that can be more categorized as "art" than "theory" or "science" are broadly ignored by all except those who choose to indulge in them. one day FP users will have to learn their lesson as well https://youtu.be/1PhArSujR_A?si=S4OQp2CnPTxmVxtd Has John Carmack's built not built things that can be described as "elaborate and grand"?

>>39728 >over the last 3 years quake was made in pure c and doesnt use a single 'struct' because of hardware performance constraints at the time. i dont think he's going to make quake 2: 2 just because he learned how to make copies of everything to further ruin performance instead of just mutating state like a normal person

>>39729 >quake was made in pure c and doesnt use a single 'struct' because of hardware performance constraints at the time. no, check the header files

>>39729 The point is that he, a practical programmer who has done important things, thinks it worthwhile to learn Haskell, and functional programming more broadly. Being a good programmer is not merely an abstract academic pursuit; it allows you to write better software. As an aside, I think it's funny that there's so many people that want to retvrn to C, when C itself was adopted for the same reason even higher level languages would be not long after; hardware going up in power and down in cost. Writing games in anything but Assembly was very rare until the rise of 16-bit hardware, and even after 16-bit machines became the norm, it was still extremely common to see games written in straight Assembly, or otherwise containing significant chunks of it. It took all the way until the early-2000s for C to fully replace Assembly as "the language you use for performance-critical code", because before that point it really wasn't; it was the thing you used for high-level logic that only needed to be "fast enough". Modern C-zealots sneering at anything with bounds checking or a garbage collector is hypocritical in a way that almost none of them are aware of, but I find fuarrrking infuriating.

>>39117 OOP makes sense in the context of Smalltalk, which isn't just a programming language but also a full-fledged programing environment. When you're programming by adding to and modifying what is for all intents and purposes a mini operating-system, it makes sense to think of everything as an object that can send and receive messages (method calls). You're not working with components of a singular, monolithic program; you're working with a bunch of self-contained mini-programs that interact with each-other as part of a larger system. Outside of this context, it really doesn't make any sense. In a more traditional, linear, distributed-as-a-binary program, functional and/or procedural code is going to be a lot clearer to read and a lot easier to write.

>>40073 This is largely the basis of microservice architectures as well, which is itself inherently object oriented. And just like microservices, OOP is also a relatively niche use case design pattern that has exploded in popularity because "everybody does it". An object pattern makes sense when you need to pass messages across a system, not write a single application. This is why GUI systems are largely OO, as an example. The hate OOP gets is mostly due to its ubiquity in my opinion, it's just another tool that any competent programmer should be able to understand and know when to apply, and when not to.

>>39526 >>39654 Yeah I moved to golang after working on a fuarrrked C++ legacy codebase for like 5 years. The complexity that arises from running wild with Inheritance and Polymorphism and the thing::thing::thing<thing>::thing(thing().thing(thing()))) style code and incomprehensible compiler errors it generates is just impossible to work with. Every line in the codebase was doing like 7 type conversions just to do soykaf like convert between two types of messages or logs or some simple data structure. Absolute insanity. Abandoning the OOP model (and c++) *as it was popularly conceived of* in the books I read and the courses I took has brought peace and sanity to my life. I'm sure the big brains know many times when OOP is super useful, but the way the average dev is using it does way more harm than good.

>>39736 >Modern C-zealots sneering at anything with bounds checking or a garbage collector is hypocritical Every "security" feature is a limitation that makes life harder for some legit user, separation of code & data being the first case. What you exhibit is the usual case of you don't need it so you don't feel the limitation and think others complaining must be crazy.

>>40086 I'm aware of the limitations of the tools I use. I'm also aware of the benefits. Good C is slower than good handwritten Assembly. However, that speed loss is generally negligible compared to the massive gains you get in productivity and portability. Likewise, Go's mandatory garbage collection makes it a heavier, which in practice means less efficient, language than C. But not having to worry about memory leaks knocks out an entire class of errors before you've even written a single line of code. There's always going to be tradeoffs. An ideological programmer thinks that you should always make the same tradeoff in every situation, because he cares more about programming than programs. The practical programmer, the guy who actually wants to Get Shit Done, is going to look at the problem, and then chose whatever tool is going to get out a usable product in a reasonable timeframe.

>>40087 I wasnt commenting on speed. I was specifically commenting on productivity. Large projects prefer safety because finding bugs becomes a huge undertaking. Tiny projects dont suffer the same issue and safety limiting how you write code is a bigger productivity killer than the bug prevention benefits it gives.

>>40090 I guess we're in agreement, you just articulated your point in a very strange way.