I'm somewhat new to programming, dabbled for years but never really got sufficiently motivated to make anything big. I'm having a look at making a Roguelike, and I'm struggling to see how you could avoid OOP entirely for this kind of thing and end up with something more elegant. If I represent a level as a 2D Array of Objects, any operation related to changing or checking states is piss simple, and I can do something similar with creatures/items, etc. I don't have to go nuts with inheritance since I can just have a base game object with x and y coordinates, then tile, item and creature objects that inherit from that with the parameters they need, then each individual type of these inheriting from those, which results in a linear inheritance structure that doesn't shit the place up and become impossible to debug.
How exactly would you approach this without OOP? Or is the constant screeching about OOP a self reinforcing shitflinging contest between Pajeets who abuse it and contrarian autists?
put the entire game state in an immutable array and keep passing it to itself in the main loop
Elijah Phillips
oh shit user I think ya dun figured out the mysteries of programming.
Zachary Kelly
OOP isn't all bad, there's no need to avoid it completely, especially if you use it lightly and don't go into crazy mountains of inheritance where it's impossible to control and reason about the data you have in hand.
Josiah Evans
just set up everthing to in structs and functions. single inheritance and like minimal overloading are nice but that's about it.
Luke Bell
I think that it depends on what you mean by OOP. Practically speaking, the only thing a language needs to allow for OOP is the ability to put functions inside structs. Putting functions in structs is not always bad. When OOP is taught in school, or when it is complained about on the internet, people are not, generally, referring to this simple concept. What they are talking about is the ideologies/methodologies of how to code "properly". While these ideas are sometimes useful, they're presented as the be all end and all way to write software, and end up being misused and abused.
Don't avoid writing classes or using inheritance, just use those tools where and when it makes sense to do so.
Kayden Lewis
Functional Programming Learn Haskell.
Colton Ramirez
Good C code uses OOP-like structures without the rigid barriers on what an object is. It's more natural once used to it. Intrusive datastructures are an example of something that feels very unnatural in OOP but are natural in C. I point anons at boost.intrusive as an example of how tortured that concept gets in C++. That doesn't make sense as the coordinates are implicit in where it's stored in your 2D array, but I'm going to ignore the dicks in your mouth and type this: struct point { int x, y;};struct object { struct point point; ...};struct object object;struct point *points[] = { (struct point *) &object };
Ryder Price
Functional, concatenative, minimal OOP. If you want to make a roguelike avoiding OO, look up ECS, the Entity Component System paradigm. Everything can be represented as flat arrays using ECS style programming.
Nathaniel Gutierrez
This doesn't look like ANSI C. Can you explain how that code works? From what I found C11 allows this kind of typecasting.
Nicholas Garcia
This is ANSI C, he can cast a struct object to a struct point because the point struct is the first element of the object struct, meaning that a pointer to an object struct also satisfies the memory layout requirements of a point struct. Since, each element of a struct is an offset from the pointer to the struct, you can see how selecting "y" is going to be something like: pointer to object + (element struct point p offset) + (element y offset)
When derefrencing. But, because the struct point p offset is zero, because it's the first element, the cast to a struct point works. You could also cast this to an int and it would just be a pointer to X.
Jayden Morris
OOP is not bad, specially when you don't abuse inheritance (you really don't want to do this; just use interfaces/mixins unless you really, REALLY need that inheritance, which you don't anyway). I am more accustomed to simple structs without associated functions, but I am going to admit there isn't much difference between placing functions somewhere else and placing them inside the object.
If you wanna do good OOP, simply remember these basics:
Leo Harris
Neat. Thanks.
Samuel Reed
What are you going about? Casting has always been in C. His trick works because the offsetof() the first field of a struct is guaranteed to be 0, but that's all.
Asher Torres
Swallow a revolver. There's never a good reason to couple data and behavior together. Go enjoy your pajeetscript and GTFO
Anthony Green
Pajeets are famous for mountains of inheritance, user.
Except clarity and ease of use. If you have say, a dictionary, there's all kinds of functions that are directly tied to it. It's much easier to do and remember "mydictionary.removeItem("foobar")" than "dictionaryRemoveItem(&mydictionary, "foobar")", especially because a decent editor will show you all the methods when you type that period.
Jonathan Anderson
Few people use OOP for inheritance, and when it is used its used sparingly. Just because C++ OOP supports inheritance doesn't mean you have to use it.
I assume you want each tile to be its own object? that's probably unnecessary. Assuming this will be something like C:DDA or DF it would be simpler to just have each tile be a struct containing a few variables (tile type, status, etc) and a vector which can be used to store information about any items or special objects which are on that tile. Since the code which deals with rendering/interacting/etc each tile info is going to be common it doesn't make much sense to make every tile have its own version of it. A 2D vector of the tile structs will make things easier since generating a new tile as the player explores is just a case of adding an element to the appropriate vector.
Jose Hughes
Stop using java faggot
Ethan Lee
Except you know, writing code that doesn't have you jump around everywhere to maintain.
Jack Jackson
C++ has horrible inheritance, avoid using it. Python's inheritance is much nicer.
Luke Anderson
I use Lua.
Oh shit this is perfect.
Oliver Jenkins
Have you tried opening almost any book on OOP.
Hudson Fisher
First of all, that's not an inheritance tree as some have said; it's a call stack. Secondly, you could deconstruct any piece of software in a similar manner if your were trying to shock people with its complexity. To be taken aback or "almost vomiting" means you don't understand contextualization, i.e. you are a no-coder.
Juan Brown
Back to /g/ pajeet
Robert Jones
Do you know how many callstacks were invoked between your computer and the webserver to make that post? You're like a nigger floating in the ocean who doesn't know what's under his own feet.
Ryder Mitchell
frames, that is
Jose Thomas
I'll accept your strawman if that callstack is between several computers and programs, and not part of a single program.
Aiden Hughes
Have a nice day, end-user.
Camden Wood
It's a call stack showing that over-abstraction is a cancer in the Java ecosystem. Look closely at the class and method names. It's a nightmare mix of excessive inheritance, callback spam, and AOP. That you don't recognize this is not usual complexity says something about your level of experience.
Matthew Butler
That's an editor problem not a problem that the OOP paradigm fixes. Additionally, if you can't remember the name of a pointer, then you shouldn't be developing software. Yeah, no.
Isn't that the guy making a game out of zero? Is he still going?
Noah Morgan
Yeah that's him. He has a pretty impressive resume too.
Eli Sanders
Imagine having so little mental capability that you can only imagine one very specific use case of any given programming paradgim.
Ayden Stewart
Imagine having so little mental capacity that you can't comprehend that the very foundational aspects of a programming paradigm are the exact reasons why it fails to accomplish what it claims to.
Kayden Diaz
Not an argument LARPer.
Nicholas Bailey
Did you know you can combine different paradgims? Because it sounds like you think using OOP means you have to structure literally everything with OOP.
Adrian Thompson
event orientated is the future my dude
Benjamin Nelson
Why avoid OOP if you are trying to model a bunch of objects? You don't have to rewrite the same code a million times either: a big use of inheritance is saying that A is kinda like B if you look at it the right way.
There are many good reasons to do so, especially for small projects in which there's a ton of single purpose code. For example, including an area() virtual function in the parent geometric_shape class and implementing it as needed in the derived classes.
Isaiah Morales
I like OOP on the high levels, where you mostly call the same methods and do the same things to different kinds of data. That's what OOP seems to excel at, processing different things the same way. When you start bringing in weird side-effects and very specific tacit ways to subvert the interfaces with extra methods that need to be called for some subclasses, need to explicitly left uncalled in others and called in specific orders others, that's when things start turning real fucky. Updating one class and later updating another shouldn't require a refresher on the ins and outs of seven overly generic layers to make sure something doesn't blow up half-way down because one convention has been perverted as a hack which introduced some edge cases. In Java land, once you bring in Spring and Hibernate, you now need to know all the ins and outs of all of those libraries to make sure you call everything the right way, because most of the wrong ways still work 95% of the time, only blow up on occasion, give stack traces that don't really give you the information you need and start causing performance problems much later down the line. Maybe when you try to run your program in a cluster or introduce a cache. Hopefully some pajeet has run into this problem before and you can see what suspicious incantation they got wrong.
The flexibility is very nice, but it requires a bit of discipline to make sure debugging doesn't turn into a nightmare. As long as you're mindful of that, it's pretty neat.
The talk is mostly based on paper [1] augmented by ideasfrom [2]. Because of its C heritage, C++ is both weaklytyped and weakly structured. Because of the basic designdecisions that were made in its object-oriented extensions,I claim that C++ is also weakly object-oriented. I willdiscuss several aspects and consequences of what I call theFundamental Defect: that objects do not carry inambiguoustype information at run time, in contrast to almost allother OO languages. The undisciplined handling of pointers(as in C) makes the problems worse. I will also mentionsome interesting problems of multiple inheritance, mostlypertaining to the distinction between "virtual" and"non-virtual" base classes (superclasses). Several otherfeatures and their problems will be mentioned, such as:reference types and argument passing, nested classes,storage classes and garbage collection, overloading,assignment and copying, templates (genericity) andexceptions.The worst disadvantage of C++ at the moment is political:accepting C++ as the standard OO language de facto tends tokill other existing languages, and stifle the development ofa new generation of essentially better OO languages.Ample time will be left for questions and discussion afterthe lecture. That allows us to look at some details thatreally interest the audience. Also, many of my opinions arecontroversial, and I do not expect all listeners to acceptthem quietly.References:----------[1] Markku Sakkinen, "The Darker Side of C++ Revisited",which appeared in Structured Programming, Vol. 13 No. 4(1992).[2] Markku Sakkinen, "A Critique of the InheritancePrinciples of C++", in Computing Systems, Vol. 5 No. 1(1992).
Jayden Rogers
i learned how to program from an event orientated language. it makes me sad to do non event driven design stuff. whats the best language to do event driven design? I did event driven design with vb and vb is really trash.
Juan Green
Open classes are fucking stupid and extremely slow. There is nothing of value in lisp. Figure that out.
Parker Adams
The whole thread about OOP and nobody mentions Yegor. You people are all pleb.
It's not an inheritance tree. It's a stack trace, nigger. And there's nothing wrong with it.
Alexander Young
javascript
Alexander Gutierrez
Every language which has reactive extensions will suffice, a language which enables actor model will do even better. Akka is the best.
Jaxson Campbell
What a douchebag.
Was there some particular article that was supposed to be relevant to this conversation, or did you just want to share the random musings of a self-important Slav?
Carson Ross
It's perfectly acceptable for a stack based VM. It's how the thing works.
Man, if you ever look at Chromium's source code, 'friend' keyword is used excessively.
Brody Baker
How's the weather in Mumbai?
Isaac Hughes
Have you taken the OOP pill?
Daniel Ortiz
Modern software sucks because devs are lazy and normies are the target customers. OOP isn't a magic pill that cures cancer.
Jordan Richardson
< Gerald Sussman on why MIT stopped teaching Scheme for introductory CS and switched to Python
I don't really have a problem with OOP: you just have to be careful. You create an object when you have something that A) has internal state that depends on the implementation, and B) you want everyone to treat the same independent of implementation. OP has a classic example of why to use OOP. Until he starts doing wildly strange things with his world, OOP will serve his map well.
Asher Miller
Those are well-designed abstractions. There's absolutely nothing wrong with it.
Aaron Mitchell
If you don't recognize what's wrong with it, you're the kind of person that led to Java being pigeonholed through mountains of layers only manageable by large corporations with code mills. Seek help.
structs with function pointers that take pointers to a "this" struct. Man I wish someone simplified this somehow.
Jack Turner
OOP is solution to problem that has been already fixed by programmers who know what they are doing At best its do get more normies to do it but it still fails even there
Brandon Reyes
Look up `apecs` and `ecstasy` on Hackage. Some blog reasonablypolymorphic is the writer for `ecstasy` gives their rationale for some of the core design decisions. It might get you into type-level programming, insofar that you can have the compiler help you lint broken invariants.
James Miller
OOP was a mistake.
Kayden Collins
That sounds like an advertisement of typeclasses, or at least denotational semantics. Also written about in reasonablypolymorphic's blog
If we relegate to object to a record, or GADT, then we have some manner of getting A, or getting B. (link related) parsonsmatt.org/2016/07/14/rank_n_classy_limited_effects.html In which case, there is motivation for parameterising in terms of the desired implementation, but also treating in spite of the implementation.
Jonathan Moore
Holy FUCK this guy is just inches away from discovering typeclasses.
Ayden Rivera
Typeclasses are just interfaces for functional faggots, aren't they? Do they provide anything more?
They are a basic form of type level programming. They form partial/open type functions which can return a record of methods. What this can be use for is dealing with is tracking a type's membership to a constraint as well as a limited form of constraint implication, in addition to being parametric over objects/implementations. This can do something as basic as prove that a type is more than what you think it is, like with the Functor-Applicative-Monad hierarchy, or, how Traversable implies Foldable and Applicative. In the extreme, in terms of data, it can be used to automate capability/authentication checking. (Something that Kmett has actually implemented) But more importantly to people is the fact that it gives a total assurance of membership of a type in a parametric function without losing sight of what that type is, and not losing sight of what other instance that type has.
While it can be said to be an interface, a typeclass is an interface parametric of types not objects, it's also a constructive proof mechanism. It's 100% what Casey was talking about but doesn't seem to know about.
This shit is so far up its own ass. Like , too. Can't they just give a simple example of some code that is improved by this feature with a before/after conversion? Rather than talk endlessly about nothing? That's how features in actually useful languages are sold rather than ramble like a crazy person about traversable applicative monads and their constructive proof mechanisms. The Haskell community is a joke.
I'm tired of python skids and web developers thinking they understand how compilers work.
Joseph Smith
Destitute poverty pajeet
Judeo-Aryan high IQ alliance
None of the shit you said except maybe "inherit" is specific to OOP.
You could do exactly what you said in Haskell. More idiomatically you would probably have something like
data Object = Item | Creature | ... data GameState = GameState (Map Coordinate Object) ...
Robert Lopez
Probably shouldn't waste my time on this but I'm retarded, so here goes:
* GHC eliminates explicit dictionary passing in 99.9% of cases except weird cases like where you use ExistentialQuantification or when the inliner heuristics see a huge code size benefit
* GHC doesn't actually desugar typeclasses to this. You can look at the generated core for yourself; you don't have to take my word for it. SPJ is just giving a simplified explanation. It wouldn't even make sense for GHC to do this anymore because you can't represent e.g. TypeFamilies with this construction
* Just because something is semantically reducible to a different concept doesn't mean that using it is the same as using the simpler concept
* The interesting part of using typeclasses is what you can offload to the type-level constraint solver system, which is basically a prolog dialect. It is absolutely not interesting what the typeclasses are compiled down to, but you are wrong about even that
Eli Sanchez
How do Haskell devs know any better when they have no code to compile?
Jeremiah Lopez
I can't tell if this is supposed to make fun of Haskell in some weird way or supposed to be a complement towards haskell for being extremely concise and expressive.
Brayden Hall
Difficulties understanding the subtleties of human language seems highly correlated with use of Haskell. Strange.
Michael Clark
It would help if you were capable of writing above a 3rd grade level, pajeet.
This might just do to being a newbie at haskell but: I feel like this isn't true. Comparator is just a constraint on the type that a can be. It's not like an extra argument.
Samuel Evans
I think Zig does that with normal methods, though I'm not sure if it works with function pointers. If you put a doTheThing function into a struct, it becomes a namespaced function that can be called with object.doTheThing() and sends pointer to object into it.
That's the kind of thing I'd love to have in C. Probably 90% of all my functions are for operating on a particular struct. Right now I'm working on a GUI system, and it's nothing but gui_addNode, gui_resize, node_setStyle, node_move etc etc. The only function that doesn't operate either on the GUI or a Node in it is the one that creates a new GUI.
Ayden Sanchez
Explain what's wrong with it.
Jackson Jenkins
It's too reliant on the jit behaving, and I bet it doesn't use cpu caches worth a shit either.
Joseph Jackson
You could literally represent the level as a 2D array of anything. Why does it have to be objects? I'm writing a 2D platformer game myself and I had to choose how everything is stored at the bit level to have the amount of players and objects with physics I'm trying to support.
OOP in any way anyone uses it today doesn't solve any problem period. At best it gives you abstract data types, which you can do much better with ML. Literally 99% of OOP use cases is just so you can write cow.moo(), which is utterly meaningless to the point where you might as well just call 0x43256712 or moo(cow) or gcow=cow; moo(). It's almost as if OOP was designed by autists to trick themselves into thinking the English words they type out do what they have in their heads. In fact that would explain the entire state of the software industry.
Josiah Bell
OOP doesn't exist for any other reason than to make it conceptually easier to write code that doesn't spaghettify in inter-references.
Connor Ross
Why does it have to be an array?
Benjamin Taylor
You forgot the point where not a single abstraction in Java (SE, EE, Spring, etc) is worth a shit.
