/tech/ - Technology★

put the entire game state in an immutable array and keep passing it to itself in the main loop

>>967984 (OP)

>I can just have a base game object with x and y coordinates

>then everything inherits from it

oh shit anon I think ya dun figured out the mysteries of programming.

>>967984 (OP)

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.

just set up everthing to in structs and functions. single inheritance and like minimal overloading are nice but that's about it.

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.

Functional Programming

Learn Haskell.

>>967984 (OP)

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++.

>a level as a 2D Array of Objects

>a base game object with x and y coordinates

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 };

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.

>>968006

This doesn't look like ANSI C. Can you explain how that code works? From what I found C11 allows this kind of typecasting.

>>968014

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.

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:

>GETTERS AND SETTERS ARE FOR PUSSIES

>DECENT LANGUAGES HAVE ACCESSORS ANYWAY

>DON'T FALL FOR THE POINTCUT MEME

>DON'T FALL FOR THE SINGLETON MEME: STATIC CLASS OR BUST

>DON'T INHERIT YOU FUCKING FAGGOT. DECENT LANGUAGES HAVE MIXINS ANYWAY

>TYPES JUST MEANS "CLASSES OF OBJECTS WITH ASSOCIATED LEGAL OPERATIONS". ACT LIKE IT FUCKING MEANS THAT

>>968019

Neat. Thanks.

>>968014

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.

>>967990

Swallow a revolver. There's never a good reason to couple data and behavior together.

Go enjoy your pajeetscript and GTFO

>>968031

>>I said OOP was shit and called it pajeet tier

>Pajeets are famous for mountains of inheritance, anon.

Yes. Obviously.

>>968052

Perfect.

>>968052

>>968031

Holy fuck.

>>968027

>There's never a good reason to couple data and behavior together

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.

>>967984 (OP)

>I don't have to go nuts with inheritance

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.

>If I represent a level as a 2D Array of Objects

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.

>>968006

>It's more natural once used to it.

<proceededs to look at all the 'natural' and 'elegant' OOP C code in the Linux kernel

>>968031

>>968052

I nearly just vomited.

Stop using java faggot

>>968027

Except you know, writing code that doesn't have you jump around everywhere to maintain.

>>968127

C++ has horrible inheritance, avoid using it. Python's inheritance is much nicer.

>>968131

>java

I use Lua.

>>968013

>ECS

Oh shit this is perfect.

>>968127

>Few people use OOP for inheritance

Have you tried opening almost any book on OOP.

>>968052

>illustration of software layers

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.

>>968186

>that call stack is acceptable

Back to /g/ pajeet

>>968187

>no-coding this hard

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.

>>968188

>callstacks

frames, that is

>>968188

I'll accept your strawman if that callstack is between several computers and programs, and not part of a single program.

>>968190

>reifying the board dogmas into an arbitrary criterion to pretend his point of view is cohesive

Have a nice day, end-user.

>>968186

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.

>>968297

>>968296

Isn't that the guy making a game out of zero? Is he still going?

>>968301

Yeah that's him. He has a pretty impressive resume too.

>>968296

>Unnecessary OOP spaghetti that results in huge classes

Imagine having so little mental capability that you can only imagine one very specific use case of any given programming paradgim.

>>968340

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.

>>968296

>Yeah, no

Not an argument LARPer.

>>968350

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.

event orientated is the future my dude

>and I'm struggling to see how you could avoid OOP entirely for this kind of thing and end up with something more elegant.

Why avoid OOP if you are trying to model a bunch of objects?

>I don't have to go nuts with inheritance

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.

>>968027

>There's never a good reason to couple data and behavior together.

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.

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.

>>968397

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 alternative to OOP is better OOP.

http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html

https://en.wikipedia.org/wiki/Common_Lisp_Object_System

>Classes can have multiple superclasses, a list of slots (member variables in C++/Java parlance) and a special metaclass. Slots can be allocated by class (all instances of a class share the slot) or by instance. Each slot has a name and the value of a slot can be accessed by that name using the function slot-value. Additionally special generic functions can be defined to write or read values of slots. Each slot in a CLOS class must have a unique name.

>CLOS is a multiple dispatch system. This means that methods can be specialized upon any or all of their required arguments. Most OO languages are single-dispatch, meaning that methods are only specialized on the first argument. Another unusual feature is that methods do not "belong" to classes; classes do not provide a namespace for generic functions or methods. Methods are defined separately from classes, and they have no special access (e.g. "this", "self", or "protected") to class slots.

>CLOS is dynamic, meaning that not only the contents, but also the structure of its objects can be modified at runtime. CLOS supports changing class definitions on-the-fly (even when instances of the class in question already exist) as well as changing the class membership of a given instance through the change-class operator. CLOS also allows one to add, redefine and remove methods at runtime. The Circle-Ellipse Problem is readily solved in CLOS, and most OOP design patterns either disappear or are qualitatively simpler.[2]

The talk is mostly based on paper [1] augmented by ideas
from [2].  Because of its C heritage, C++ is both weakly
typed and weakly structured.  Because of the basic design
decisions that were made in its object-oriented extensions,
I claim that C++ is also weakly object-oriented.  I will
discuss several aspects and consequences of what I call the
Fundamental Defect: that objects do not carry inambiguous
type information at run time, in contrast to almost all
other OO languages.  The undisciplined handling of pointers
(as in C) makes the problems worse.  I will also mention
some interesting problems of multiple inheritance, mostly
pertaining to the distinction between "virtual" and
"non-virtual" base classes (superclasses).  Several other
features 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) and
exceptions.

The worst disadvantage of C++ at the moment is political:
accepting C++ as the standard OO language de facto tends to
kill other existing languages, and stifle the development of
a new generation of essentially better OO languages.

Ample time will be left for questions and discussion after
the lecture.  That allows us to look at some details that
really interest the audience.  Also, many of my opinions are
controversial, and I do not expect all listeners to accept
them 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 Inheritance
Principles of C++", in Computing Systems, Vol. 5 No. 1
(1992).

>>968443

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.

>>968446

Open classes are fucking stupid and extremely slow. There is nothing of value in lisp. Figure that out.

The whole thread about OOP and nobody mentions Yegor.

You people are all pleb.

https://www.yegor256.com/

>>968031

It's not an inheritance tree. It's a stack trace, nigger.

And there's nothing wrong with it.

>>968451

javascript

>>968451

Every language which has reactive extensions will suffice, a language which enables actor model will do even better. Akka is the best.

>>968473

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?

>>968187

It's perfectly acceptable for a stack based VM. It's how the thing works.

>>968506

Man, if you ever look at Chromium's source code, 'friend' keyword is used excessively.

>>968475

How's the weather in Mumbai?

>if OOP is so bad how come all major modern software uses it

>some time later

>how come all major modern software sucks

Have you taken the OOP pill?

>>968554

>>if OOP is so bad how come all major modern software uses it

>>how come all major modern software sucks

Modern software sucks because devs are lazy and normies are the target customers. OOP isn't a magic pill that cures cancer.

>>968031

> When we conceived of scheme in the 1970’s, programming was a very different exercise than it is now. Then, what generaly happened was a programmer would think for a really long time, and then write just a little bit of code, and in practical terms, programming involved assembling many very small pieces into a larger whole that had aggregate (did he say ‘emergent’?) behaviour. It was a much simpler time.

> Critically, this is the world for which scheme was originally designed. Building larger programs out of a group of very small, understandable pieces is what things like recursion and functional programming are built for.

> The world isn’t like that anymore. At some point along the way (he may have referred to the 1990’s specifically), the systems that were being built and the libraries and components that one had available to build systems were so large, that it was impossible for any one programmer to be aware of all of the individual pieces, never mind understand them. For example, the engineer that designs a chip, which now have hundreds of pins generally doesn’t talk to the fellow who’s building a mobile phone user interface.

> The fundamental difference is that programming today is all about doing science on the parts you have to work with. That means looking at reams and reams of man pages and determining that POSIX does this thing, but Windows does this other thing, and patching together the disparate parts to make a usable whole.

< 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.

>>968240

Those are well-designed abstractions. There's absolutely nothing wrong with it.

>>968618

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.

>>968484

Not an argument.

http://eolang.org

structs with function pointers that take pointers to a "this" struct.

Man I wish someone simplified this somehow.

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

>>968138

> ECS

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.

>non-OOP C code

>can tell what functions operate on your data via simple tab completion

>foo_data_create, foo_data_destroy, foo_data_write, etc.

>OOP C++ code

>extremely sophisticated code analysis IDEs required to tell what methods exist on a derived object

>all open sores variants of this are shitty and barely usable

>OOP doesn't let you do anything you weren't already doing in C

OOP was a mistake.

>>968506

That sounds like an advertisement of typeclasses, or at least denotational semantics. Also written about in reasonablypolymorphic's blog

>>968446

> Lets reinvent constrained parametric polymorphism, and higher-order constraints?

>>968594

If we relegate to object to a record, or GADT, then we have some manner of getting A, or getting B.

(link related) http://www.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.

>>968297

Holy FUCK this guy is just inches away from discovering typeclasses.

Typeclasses are just interfaces for functional faggots, aren't they? Do they provide anything more?

>>968991

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.

https://www.youtube.com/watch?v=hIZxTQP1ifo

>>969001

> That's how features in actually useful languages

Sorry bud we are not all web developers like you.

>>969003

>screenshots pajeet not getting it

Everything in Haskell compiles down to a very simple IR a few constructors you retard. The entire fucking language is sugar.

>>969003

> Pajeet not understanding how something works but making enthusiastic claims anyway

Imagine my cock

>>969008

> Explain yourselves immediately.

Every feature of the language is sugar

https://www.youtube.com/watch?v=uR_VzYxvbxg

>he knew a lot more

Yes pajeet knows more Java.

I'm tired of python skids and web developers thinking they understand how compilers work.

> OOP

Destitute poverty pajeet

> Functional

Judeo-Aryan high IQ alliance

> How exactly would you approach this without OOP?

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 <item details> | Creature <creature details> | ...

data GameState = GameState (Map Coordinate Object) ...

>>969008

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

>>969010

>I'm tired of python skids and web developers thinking they understand how compilers work.

How do Haskell devs know any better when they have no code to compile?

>>969016

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.

>>969018

Difficulties understanding the subtleties of human language seems highly correlated with use of Haskell. Strange.

>>969019

It would help if you were capable of writing above a 3rd grade level, pajeet.

>>969020

Pajeet should be capitalized, LARPer.

>>968992

This might just do to being a newbie at haskell but:

>When the caller uses this function, it implicitly passes the Comparator

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.

>>968953

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.

>>968704

Explain what's wrong with it.

>>969073

It's too reliant on the jit behaving, and I bet it doesn't use cpu caches worth a shit either.

>>967984 (OP)

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.

>>968558

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.

>>969388

OOP doesn't exist for any other reason than to make it conceptually easier to write code that doesn't spaghettify in inter-references.

>>969388

>Why does it have to be objects?

Why does it have to be an array?

>>968186

You forgot the point where not a single abstraction in Java (SE, EE, Spring, etc) is worth a shit.