[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


Janitor acceptance emails will be sent out over the coming weeks. Make sure to check your spam folder!


[Advertise on 4chan]


File: self-logo.png (20 KB, 494x229)
20 KB PNG
were classes a mistake or "classes considered harmful" in the context of OOP?

Self and Io are (were) prototype based OO programming language that implement the idea that for "object oriented" languages you just need, surprise, objects that send and respond to messages

The result is
- having no need for blueprints for objects: no need for abstact, concrete, interface, namespace extralingual specification
- lot of design patterns become unneeded due to flexibility of classes objects
- you can still have structured organization

> LISP AND SYMBOLIC COMPUTATION: An International Journal, 4, 3, 1991
> Organizing Programs Without Classes*
https://bibliography.selflanguage.org/_static/organizing-programs.pdf

https://selflanguage.org/
https://iolanguage.org/
>>
File: io-faq.png (95 KB, 885x494)
95 KB PNG
>>
Classes are fine. Just use them when needed and don't use them when not.
>>
>>109091508
I don't get it. The only definition of an object which I know is that it is an instance of a class; I don't see how it can work without classes. Show an example of "prototype-based" programming maybe.
>>
>>109092297

> LISP AND SYMBOLIC COMPUTATION: An International Journal, 4, 3, 1991
> Organizing Programs Without Classes*
https://bibliography.selflanguage.org/_static/organizing-programs.pdf
>>
>>109092297
You've never used JavaScript?
>>
File: faq-javascript.png (95 KB, 844x494)
95 KB PNG
>>109092246
You are making the equivalence classes==objects, which is the whole point that prototype based OOP languages try to confute


>>109092297
> The only definition of an object which I know is that it is an instance of a class;
The definition of pure OOP language is among the line "self-contained entity that stores state and behavior together and interacts with other objects through message passing."

The question is: "if you need an object why are you defining a class?"
The answer is that you can achieve everything you can with class-based


>Show an example of "prototype-based" programming maybe
The best way to start is reading the paper "Organizing Programs Without Classes" linked in the thread
Then read the Self's morph UI

The most modern prototype OOP language is, sadly, javascript. But Self and Io are pure object oriented languages and this make a substantial difference in the end
>>
>>109091508
Nobody gives a fuck about having a "true" OO language, just like nobody gives a fuck about purity
>>
>>109092440
>just like nobody gives a fuck about purity
purity comes with added values, which is extremely interesting
Making
>>
XOScript also works like this
>>
>>109092672
Yes, but xo is dinamycally scoped
>>
>>109092297
>The only definition of an object which I know is that it is an instance of a class
see >>109092404
A object is roughly a struct (c) or dict (python).
>>
>>109091508
>were classes a mistake or "classes considered harmful" in the context of OOP?
great question, let's see...

Does Lisp (CLOS) has classes?
Yes, it has.

Thus, classes = good.
>>
>>109091508
>objects that send and respond to messages
This kind OOP-apologism is ridiculous. The admit that 90% of what OOP brought to programming was a horrible mistake, but they attempt to apologize and save OOP by claiming "Actually true OOP is about message passing!"

No, the definition of OOP is needlessly making everything a object or if possible, class, and needlessly doing everything through polymorphism. And inheritance is recommended by OOP.

As for message passing, it's posed as this mythical fix to modern OOP but actually it's nothing more than a function calling convention + encapsulation. Which like most things in OOP (arguably except inheritance, that's almost never a good thing), is useful in some cases and not others, with the procedural approach usually being the best.

The message passing style, over the method call style, offers nothing other than funny "Object does not understand Y!" runtime messages. But the strict encapsulation leads to retardation like get() and set() on every property. Typical OOP bloat.
>>
>>109093339
This is a classless vs class based OOP thread, not about OOP model in general you mouth breathing retard
>>
>>109091508
>no need for abstact, concrete, interface, namespace extralingual specification
no need for comprehensibility or establishing correctness either
>>
>>109093731
Only for a small kind of compile time guarantees, but that just boils down to the old dynamic vs static typing arguments

Regarding comprehensibility, it's not an inherent property of a specific language. I'd argue that class based language due the limitation of having to specify blueprint requires more complex hierarchy/relation modelling (lot of the design patterns like factory, builder, decorator, ...), something that vanish completely on pure prototype object based languages because the objects are more flexible

In the end, just use good names

If you really need guarantees of that kind of correctness you might skip directly to type driven programming languages like Idris, f* or even Haskell
>>
>>109093339
>The admit that 90% of what OOP brought to programming was a horrible mistake
What? Who? Where?

> No, the definition of OOP is needlessly making everything a object
Why needlessly? It's just a way to model some kind of "unit" of computation. Why are objects needless and functions not?

> And inheritance is recommended by OOP.
Yeah? inheritance is a form of code sharing

> As for message passing, it's posed as this mythical fix to modern OOP but actually it's nothing more than a function calling convention + encapsulation.
That wouldn't make it different from method calling

Like before, this kinda boils down to arguments about pros and cons of message passing protocols compared to RPC for distributed systems. Like in distributed systems, message passing has the advantage of a more loosely coupled interface between the client (object sender) and server (object receiver) allowing you to have more flexibility in exchanging the actors

> The message passing style, over the method call style, offers nothing other than funny "Object does not understand Y!" runtime messages
The message style passing is actually fundamental in that it's resolved at runtime. Because in pure OOP languages objects are "alive" and you can change their behavior at runtime allowing you to do develop programs interactively (something like the LISPs interactive development capabilities, tho arguably less powerful wrt smalltalk/self)

The message passing allows also object to deal with unknown messages like you said: they can be propagated to other objects until an object in the chain can actually answer to the message)
>>
Bump
>>
>>109093329
self object system is cleaner than CLOS
>>
>>109091508
>https://iolanguage.org/
Disgusting website.
>>
>>109092246
> muh "just use them when needed"

you're describing literally every tool in existence, congrats on the nothingburger take
>>
>>109092404
> never had to. sounds like a win desu.
>>
>Real OOP has never been tried! Look at those two toy languages, they are real OOP! Oh, I gotta go back to refactoring Java enterprise monolith, some day I will try real OOP.
>>
the problem with oop and functional fags is they live in their ivory tower. They want to write tools for programmers but they don't know what programmers do because they don't actually program themselves.
>>
>>109091508
JavaScript is based on prototypes. Yet no one develops it as prototype-based anymore.
>>
>>109095302
How so? It's black/grey text on white bg
>>
File: matz.jpg (50 KB, 300x451)
50 KB JPG
learn Ruby
>>
>>109091508
who cares? the llm will write whatever anyways
>>
>>109097304
Disregard Ruby, learn Elixir.
>>
>>109096491
Because class-based OOP won the popularity contest, also thanks to academia

See >>109092297 , this is your average fresh out of college/university CS person

They are taught class based OOP, maybe through java and possibly python, then design pattern and ds/algo course
>>
>>109093339
>the definition of OOP is needlessly making everything a object or if possible, class
first, your definition is already negatively biased
second, your definition has clear signals you don't even understand the paradigm you're trying to criticize

>And inheritance is recommended by OOP.
OOP doesn't "recommend" anything, it's not an entity with such capability
only people using OOP can "recommend" things, and for the last 20 years or so, the actual recommendation is Composition over Inheritance
>>
>>109091508
>having no need for blueprints for objects
isn't the prototype a blueprint?
also classes being "blueprints" isn't a very accurate definition, even if commonly used

>lot of design patterns become unneeded due to flexibility of classes objects
name the design patterns that are supposedly needed because of OOP having classes
>>
>>109099548
Kinda but not really. You actually clone objects

Take the example of polygon in the paper linked. The general suggestion for organizing classless object programs is to have separate objects, one representing the shared behavior (ie Traits) and one object for instance representations

The trait object can be compared to an abstract class but in this case you have real, instantiated object that it's shared across objects of the same "class" in a way that resembles object composition. You don't define the blueprint for intratype sharing of behavior, you create a trait object that is shared

So you don't define the blueprint of the object with classes, the organization emerges as a result of the relationships
between objects and how they are decomposed

So you achieved the same thing you did with just objects without the need for any extra-language specification
>>
>>109099548
>name the design patterns that are supposedly needed because of OOP having classes
In strict class based object oriented languages like java, the very concept design pattern arises to deal with programs organization with classes

Namely factory-es, builder or any creational pattern that delegates the creation of objects expected by a client or need the creation of families of related objects. The others tend to be either absorbed by the language itself or becoming less strict

The situation is mitigated by modern class based dynamic language like python and Ruby. But the question is why at that point forcing you to create a class instead of directly an object
>>
>>109100223
>In strict class based object oriented languages like java, the very concept design pattern arises to deal with programs organization with classes
that's just wrong
the "very concept" of design patterns are documented solutions to repeatable problems. there's nothing in design patterns' definition that says they require classes, or even OOP

>Namely factory-es, builder or any creational pattern that delegates the creation of objects expected by a client or need the creation of families of related objects.
you failed to make clear why classes make those specific patterns "needed" - you can create objects without any of those

also, the Prototype is itself a creational design pattern. it doesn't matter if it's implemented using classes or is built into the language
same with a for-each loop - it's just syntax sugar for an Iterator pattern (which doesn't go away just because the language has a built-in wrapper for it)

>The others tend to be either absorbed by the language itself or becoming less strict
so? a design pattern doesn't vanish just because it becomes a language feature

>But the question is why at that point forcing you to create a class instead of directly an object
the angle of this question is retarded, it makes it seem like person who asked it doesn't really know what a class is to begin with

>>109100153
so you're making the language have less definitions at the cost of more ambiguous and complex definitions it does still have

no sale
>>
>>109100851
>that's just wrong
>the "very concept" of design patterns are documented solutions to repeatable problems.
I meant the most common notion of design patterns, I thought it was clear

>there's nothing in design patterns' definition that says they require classes
Basically all the creational a pattern comes from fighting the static class typing


>you failed to make clear why classes make those specific patterns "needed" -
Seems pretty clear to me, you are just playing retard at this point

See abstract factory. Not needed in class dynamic typed language not in prototype based

>also, the Prototype is itself a creational design pattern.
Not when it's coupled in the foundation of a language (considering it's the only way to create an object)

Would you call the class-instance dynamic in common OOP languages a "creational pattern"? Although it's technically right you're just playing with semantics

>the angle of this question is retarded, it makes it seem like person who asked it doesn't really know what a class is to begin with
Not really, you are just affected from baby duck syndrome

Let's say you can do task X and you have two way of doing it
- with only A
- with A and B

What would be the more sensible question? I'm pretty confident the most sensible one would the one questioning the usefulness of an additional concept that doesn't add any value
>so you're making the language have less definitions

It needs less concept to achieve the same goal

> at the cost of more ambiguous and complex definitions it does still have
What are you even talking about


>No sale
I'm not selling anything retard. Just read the paper linked in the thread, it's just 20 pages
>>
>>109101009
>Not when it's coupled in the foundation of a language (considering it's the only way to create an object)
you don't get to pretend a pattern is not there just because you want only one specific pattern to be forced over the whole problem category, or that you don't like the concept of design patterns altogether

>Not really, you are just affected from baby duck syndrome
projection

>Let's say you can do task X and you have two way of doing it
>- with only A
>- with A and B
this only clarifies you're a retard that doesn't understand classes to begin with
>>
>>109091508
good dsl
>>
>>109100223
>Namely factory-es, builder or any creational pattern that delegates the creation of objects expected by a client or need the creation of families of related objects.
>>109100153
>You actually clone objects
>The trait object can be compared to an abstract class but in this case you have real, instantiated object that it's shared across objects of the same "class" in a way that resembles object composition. You don't define the blueprint for intratype sharing of behavior, you create a trait object that is shared
>So you don't define the blueprint of the object with classes, the organization emerges as a result of the relationships
> between objects and how they are decomposed
>So you achieved the same thing you did with just objects without the need for any extra-language specification
This is just design patterns. In fact, something like a builder is actually more native to the purist message passing OOP than the class definition OOP
>>
>>109101265
>you don't get to pretend a pattern is not there just because you want only one specific pattern to be forced over the whole problem category,
So do you consider class-instance a creational pattern in common OOP languages? While technically correct it just sounds like arguing for the sake of it

The whole object system is based upon the prototype model
>this only clarifies you're a retard that doesn't understand classes to begin with
I don't know, it's just basic reasoning
You need to justify the existence of additional concrete by arguing about its necessity or at least some usefulness derived by it and not the other way around

The paper linked shows you can organize programs objects without class and have the same expressiveness as you would have with class without the need for them
>>
>>109101543
>builder is actually more native to the purist message passing OOP than the class definition OOP
It's actually the opposite. You don't need builder in a classless OOP language
>>
>>109091508
>>109092172
>>109092418
Quick look, not reading the link, sounds like runtime memes that makes shit slow for little gain. Might as well just go dynamic typing and abuse that to solve everything. Though ofc that leads to unmaintanable crap and hence isn't used in real projects.

The fact that nobody except >>109100153 even bothered to explain what this mystical "true" oop is means it's retarded bullshit. Like how monads are just a private API object you have to pass everywhere to ensure nobody writes to IO unless given permission. Or how Actors are just a design pattern which you can easily emulate. Or AOP is just macros that add before/after steps to a function. Or a million other memes you can easily do yourself without needing an entire language for it...
>>
>>109101671
>Quick look, not reading the link,
> Skipping the document explaining the problem
Surely your opinion must be based on solid grounds, then.

>what this mystical "true" oop
Nobody mentioned "true OOP" nowhere you LLM-brain fried retard. The point is that OOP can be done without the need of extra language specification like class, just objects and that that lead to (arguably) a more expressive way for program organization

>Or a million other memes you can easily do yourself without needing an entire language for it...
I guess you are for a treat then since the point is that you also don't need classes
>>
>>109101568
>So do you consider class-instance a creational pattern in common OOP languages?
non-sequitur question

>You need to justify the existence of additional concrete by arguing about its necessity or at least some usefulness derived by it and not the other way around
more retarded reasoning and more admittance you don't even know what classes are
you and your paper fail to demonstrate any benefits other than "there's no classes", which - at best - is an emotional argument intended for people scared of or confused by the concept of classes

>The paper linked shows you can organize programs objects without class and have the same expressiveness as you would have with class without the need for them
the paper only showed the most basic entity not actually used in any practical program

>>109101671
>"true" oop
strawman
>>
>>109103237
>non-sequitur question
Are you sure you know what non-sequitur actually means?

>more retarded reasoning and more admittance you don't even know what classes are
Tell me what a class is in the context of OOP
>you and your paper fail to demonstrate any benefits other than "there's no classes
Are you actually retarded?
>the paper only showed the most basic entity not actually used in any practical program
Yeah, that's how papers on this kind of subject works
They take for granted that the reader has the intellectual capacity to inductively extend the concepts explained in the paper to more complex problems.
But prototype based OOP is not something born yesterday anon

Ever heard of JavaScript?
>>
>>109101578
Yes, you do
Builder pattern is a type of a factory pattern. Factories exists for creating complex objects that may be made from a wide set of possible components, for delaying that creation, and for passing partial elements needed for that object.
The whole point is that you collect parts to make something and centralize the logic for verifying you have what you need and actually creating that thing, and you tie the two
In class-based OOP you can simply define a static class for every valid set of things needed to make you final object, then give each of those classes method to perform the construction. Since you can't create an object of the factory class with one of it's fields missing, the class definition ensures all the needed parts are present. Unless it's shit like java where everything is nullable and you still need to check it
In prototype-based OOP there is no static manifest for creating a valid object. So to have an object responsible for creating another object that's NOT just that object you clone (yes, that is a valid requirement) you pass messages to it with the parts to make it "have this" "and this" "and that" "okay now make it for me" - that's quintessentially the builder pattern
>inb4 no you don't need factories
Yes you do. The alternative is embedding complex object creation logic in every user that needs to do it
>>
>>109092172
>every X is a Y
is there a name for this mental illness where people try to shove every single concept available through a single abstraction?
>everything is a file
>everything is an object
>everything is a message
>>
>>109091508
Some things lend themselves very well to domain classes, like records in a database.

Some things do NOT lend themselves to object orientation. I abhor the day Jews decided that "The RequestHandler has to .handle(request)" was going to be the path forward for a myriad of subhuman chinks and pajeets who feel like they need to prove how smart they are for no fucking reason by using the most retarded design patterns possible.
>>
>>109104118
> Yes, you do
No you don't

Why would you need a builder in a language that naturally supports incremental object creation and extension ?

You can just do
Prototype -> clone -> customized instance

Remember that object are not static entities like in class-based OOP, you create an object when you need it, you don't define it because you may need an instance later

The idea is that you would do
  
PizzaBase := Object clone (
tomato := true
eat := method(
writeln("eat", self))
)

# later in the code you need a pizza with anchovies
PizzaAnchovies := PizzaBase clone

# later in the code after you computed how many anchovies you want in the pizza

PizzaAnchovies numberOfAnchovies := 4

# later in the code you want your pizza with anchoives object to have also cheese

PizzaAnchovies cheese := true



You don't need a builder at all. the prototype inheritance is a generalized builder

> Yes you do.
Again, you don't
As a rule of thumb, the creational design patterns are all "workarounds" around the strictness of class based object construction
Since the receiver of an object doesn't need to know in advance the **class** of an object you don't need abstract object/concrete object machinery
>>
prototypical inheritance is in javascript and everybody hates it so much they introduced regular classes. get with the times
>>
>>109104746
see >>109098655
>>
>>109104281
Orthogonality or more broadly monoism
>>
>>109104776
exactly, it lost. move on
>>
>>109104810
Maybe (((You))) lost and need to move on
>>
Bundling data with behavior is a mistake. Data oriented design is the future.
>>
>>109104281
>there a name for this mental illness
consistent/orthogonal/uniform good design

If everything has the same uniform interface it means that you just have to know that to work with the whole system

In "everything is a file" OSes (the Plan 9 EIF, not the half assed Unix one) every resource responds to the same messages, it being a real file, a process, a device, a connection, a state of a process, a component of a window,...etc...

They all have a file interface: open(), read(), write(), close()

In non uniform resource representation systems instead, you have to know a different API for any different resource
It's cool, isn't it?
>>
>>109105123
Not really, DOD is just needed for optimization of memory access and throughput. But it sucks asses for modelling and maintainability

The future will be type oriented programming with a special focus on algorithms validation from code generated by AIs
>>
>>109105297
You just described why DOD is the future. Maintainability will be solved, no reason to write less performant code. There won't even be a "language".
>>
>>109105310
>Maintainability will be solved, no reason to write less performant code
The reason to have type driven programs is that they are easier to validate with a theorem prover
The role of a developer will be checking model correctness of code generated by Ai

DOD is relagated as technique for tuning hot procedures. Assuming we will have the same computer architecture answer have today in the time being

Correctness almost always beats performance in applications
>>
>>109104281
>is there a name for this mental illness where people try to shove every single concept available through a single abstraction?
Being a basedman
>>
>>109104718
nigger you not only don't know what classes are, you also don't know what builders are for or how they work
>>
>>109106311
Will you eventually answer the actual point instead of acting like a woman?
>>
>>109106311
So?
>>
>>109105213
>They all have a file interface: open(), read(), write(), close()
>
>In non uniform resource representation systems instead, you have to know a different API for any different resource
>It's cool, isn't it?
No, it's not "cool". You still need to memorize and more importantly parse all the data that comes out of these imaginary "files". Except now you're trying to represent non-data streams in data stream format.
If you can write something to a file and then read back completely different data, then congrats, you've just shoved a non-stream abstraction onto a stream and you should kill yourself.
Just call an API and get the fucking data. It's not that hard.
>>
>>109107715
>You still need to memorize and more importantly parse all the data that comes out of these imaginary "files"
That's not inherent to uniform resource representation, ouput response either comply to a standard schema of response and you solved the problem or you have to do the same thing by calling the appropriate unique API

The EIF (or any other EIX) uniform the calling API

> Just call an API and get the fucking data. It's not that hard.
It's not hard, it's incredibly stupid not exploiting the possibility of uniform resource representation
>>
>>109107763
That's not how it works. Whenever you have many different kinds of data you need to memorize the format of the data. Even if you wrap the data in some shitty container format like JSON you still need to memorize the schema, the key names and the format of the values.
On Shitnux if you want to query information about a process you have to open a fake text file and parse the text inside to get the information you want. On Windows you just call an API and you get everything neatly formatted in a struct which you can directly read out of without having to parse text.
Maybe not everything is a file, huh?
>>
>>109107715
> Whenever you have many different kinds of data you need to memorize the format of the data.
Just like what happens anyway?

> . Even if you wrap the data in some shitty container format like JSON you still need to memorize the schema, the key names and the format of the values.

You know you can use libraries written upon the read/write/close interface?

> On Windows you just call an API and you get everything neatly formatted in a struct
You can do the same in unix. nobody is forcing you to access resources directly with read()
But still, you have to memorize all the different API for the different resources type

> Maybe not everything is a file, huh?
But everything can have a file interface. On the other hand, a "real" file is not something real, it's just an abstraction, you know
>>
>>109107836
>You know you can use libraries written upon the read/write/close interface?
And for what benefit? Why do open/read/write/close (which is 4 API calls complete with error checking) plus additional data parsing when you can just call 1 API and get everything you need in a struct?
>But everything can have a file interface.
Not everything *should* have a file interface, though. You can come up with all kinds of equally retarded "everything is a X" abstractions. Imagine a system where everything is a pointer. The entire disk is mapped into virtual memory and you allocate disk space in the same way you allocate memory. Sounds genius right? But it doesn't work in real life because the performance would suck (TLB and page table bloat) and you'd have issues with reallocation and copying data.
>On the other hand, a "real" file is not something real, it's just an abstraction, you know
All real files behave in the same way: persistent storage for arbitrary data. That's what a file is. When you create imaginary files whose content is made up on the fly, where if you write to it and then read immediately afterwards you get a different result, then you've just created a shitty API for no reason.
There is a certain elegance in things like /dev/zero, /dev/urandom and /dev/null, I will admit. Being able to access storage devices /dev/sdX makes some sense as well. But using files as a replacement for a proper API makes no sense and is simply inferior to calling a normal syscall.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.