>>25981
>"memory safety" and spamming bug statistics from 10 years ago.
It's more relevant than ever now that AI is finding vulnerabilities en masse.

>>25986
it's less relevant than ever now that AI is finding (and fixing) all the vulnerabilities

>>25987
>AI
>fixing
>it was real in my head
Maybe in the future.
Of course assuming AI models will stay open and they'll keep disclosing their findings.

>>25988

>>25985
>try to rephrase it

okay - a nothingburger, hehe. doesnt matter, objects are objects, i have no time for bikeshedding babble

>Inside every "fast" modern VM that uses technologies created/modernized on VM by Selfie

those arent technologies, those are some marketing word salad. "hidden classes" are only JS related and were described by runtime developer AFAIK.

real technology sounds like:

> string interning
> constant folding

>>25888
You are a heckin' valid rustdev

>>25942
>separate processes communicating with each other through messages
Yes, that's OOP, and that's much more than "using classes."

>>25886
OOP is ok when it’s within a super on-rails language/framework. where basically you’re filling in prebuilt/builtins with your app logic. randomly using OOP/classes in eg: a Node api is psychopath behavior

scala is fun because it removes most of the boiler plating of oop and has some functional stuff like currying and tail recursion. most of the time you are using the `case class` which creates something that behaves like a haskell adt.

>>25983
Until you realize that the "v1" object class doesn't just encapsulate the data { x, y, z }, it also represents a local displacement on a scenegraph represented as {parentNode, x, y, z }, which is being matrix transformed by parent rotation / scale nodes, and you didn't realize the ".add" method represents addition in local space not world space, so now your .add {0, 0, 10} just caused your character to explode off the map instead of making him jump up 10 units and you have no idea why.

Meanwhile your vec_add function you look at the code and see it's one line: return {v1.x + v2.x,... and you know it's a local transform so you look for a vec_displace or whatever the correct world-transform function is.

That's the problem with OOP turning all state into black boxes. Sometimes shit doesn't work as expected and you have no idea why because you thought it was better to hide the internals. But then you end up needing to look at the internals anyway, defeating the purpose.

>>25995
what are you on about

>>25891
/thread

I don't even know what OOP is. I know it means object oriented programming, but have no idea what that entails.

>>25991
I've never written a line of rust in my entire life
I use GNOME btw

>>25996
That

vec_add(v1, v2)

is not always just syntactic difference to

v1.add(v2)

because a member function might trigger a whole cascade of second-order effects (tree dirtying, event triggering, intermediate variable recalculations, ...) that you need to look into the black boxes to be sure of.

Meanwhile when your codebase only has pure functions, you are guaranteed to know that the effects of function calls are only those explicitly defined in the function.

>>26000
the function could still do all of that

>>25990
>okay - a nothingburger, hehe. doesnt matter, objects are objects, i have no time for bikeshedding babble
Still waiting for you to make a point

> those arent technologies, those are some marketing word salad
They indeed are "technologies". Self proved at that time that vms runtime were not intrinsically *that* slow and they could achieve comparable performances of optimized C (or at least in the same order of magnitude)

https://en.wikipedia.org/wiki/Self_(programming_language)

They are the technologies on top of which modern vm achieved fast runtime performance

>>26000
What a disingenuous piece of vomit. There's nothing stopping you from adding a socket in the v struct and doing retarded stuff. It will stay pure since it's passed as an argument.

>>26001
Not if it's pure

>>26003
>adding a socket in the v struct and doing retarded stuff. It will stay pure since it's passed as an argument.
If you're passing a socket and then "doing retarded stuff", then that was on you. The pure function just returned a value. Any "retarded stuff" that happened was because you used the return value to change the socket object itself.

Meanwhile, with OOP the member could be "doing retarded stuff" to the socket, and if the object's state is hidden as private variables (which is generally best practice), you have no way to stop it without refactoring the class.

Or, as is often the case, you're working with someone else's scene library and have no way to refactor it yourself to stop it from doing retarded stuff, so instead you're begging on GitHub to have them change it.

>>26000
>you need to look into the black boxes
you don't need to do that

>>25886
OOP will most likely trick you into making really bad architectural desitions. Having a simpler but flexible language will help you make faster software, and focus on the logic, instead of spending so much time fighting bad organisation. Having all these scopes is bad, and a beginner would benefit a lot by making most classes static. Looking back at my C# code, it is a hot mess, where avery file contains a class, and every class has a bunch of event bullshit to listen to other classes. It was a spiderweb where I was in little controll of how things worked together, and controlling the flow of the entire program, makes stuff a lot easier, for a solo dev

>>25886
>why does everyone hate OOP?
I don't. it's mostly hated by pseuds trying to bring attention to themselves.

>>26002
>They indeed are "technologies". Self proved at that time

okay okay, Self proved and Self was first, i asked the duck. i also recall there was a blog article of a dev who moved to Dart (or something) about hidden classes in JS, the text is copied to V8 site. also this one https://www.youtube.com/watch?v=hWhMKalEicY

...now i even recall he was a retard who was afraid of type assumptions.. but it is not related.

>make a point
okay, i start doubting hidden classes because they are hidden, read implicit, but explicit is better than implicit by the Zen. though my initial nothingburger stands strong.

>modern vm
bloated clusterfucks, ye, name any. they all cannot prove NOW (not at the time back back then when dinosaurs stompted the Earth) they are capable of doing programs, so programs are still compiled.

>>25963
>Every new object defined is a new node on a graph
So what? You can't eliminate complexity to the extent you seem to think but move it on another space

The function execution in functional languages create a dynamical graph that can explode to be very wide and deep

> there needs to be at least one delegate written to create a connection to another node.
not really, unless you also include a primitive Object type

Btw you should really make a distinction between OOP in theory and practical implementation, because they differs significantly. OOP in "entities that can receive/send messages and forward them" like smalltalk/pharo and self, and between statically and dynamically typed class based OOP

In the formers, the language is not meant to be just the language isolated, but it's the sum of language+environment: Objects are "living" entities that can be inspected and modified at runtime. Development is meant to be like the LISP's REPL interactive development but arguably in a more powerful and flexible fashion. Complexity is tamed by the fact that you basically live in a debugger while developing https://www.youtube.com/watch?v=xhPlUaXpCU4

In statically typed class based OOP languages, I argue that a significant amount of cruft comes the strong coupling of traits and instance-representation and from the class-instance implementation of OO: almost all creational pattern arise as a workaround to deal with the strictness/limitation imposed by classes (when the receiver doens't know in advance the type or family type of the object received. The structural and (especially) behavioral ones actually emerges from common sense

for dynamically typed languages like python I don't even know why they didn't go with prototype based OO implementation and left out the concept of class directly instead of making the extra-step of implementing class as an object for instance factory

>>26004
>Not if it's pure
tf does that even mean?

>>25912
yk you can encapsulate without classes right?
>Imagine writing a GUI App without classes
I've done this. It's actually much nicer.

>>25886
There's nothing wrong with OOP in principle, if you use it properly and aren't retarded with it, but it also makes it very easy to shoot yourself in the foot. You can however make nicely organized and easily extendable programs if you use it properly.

Professionally speaking you are very likely to encounter code that has been - unfortunately - written by retards and midwits and as such you will run across enormous OOP abominations almost certainly. Retards and midwits also tend to follow advice, so-called "best practices" and "design patterns" completely blindly, effectively based on dogma with no critical thinking involved and no consideration of advantages / disadvantages in the actual program being written. While these often-quoted best practices and design patterns do have legitimate uses and applications, when a dev turns his brain off and merely follows such things blindly the end-result is almost certainly going to be extreme complexity of the codebase for no actual benefit. This seems to happen VERY frequently and the result is always a clusterfuck.

>>26005
That's what every tard thinks and is always wrong.

>>26008
>okay, i start doubting hidden classes because they are hidden,
I don't understand what you mean by this. Hidden classes (which can be thought of "hidden objects") are just implementation details for runtime performance tuning on a different plane wrt the language semantics
It's just like doubting the endianess or the stack/register vm when talking about the python language or lua

prototype based OOP actually makes more sense than class based. If you want an object just create a object that can answer to some kind of messages. Classes gives you some more compile time guarantee as a compiler contracts and a little bit of free documentation in dynamically typed languages (which seems to treat classes more or less as a blueprint for an object). On the other hand they comes with a lot of downsides and the need of extra-language constructs (like "abstract", "interface", "package/namespace", etc...)

The paper "Organizing programs without classes" makes some good point on the benefits of classless OO implementation

https://bibliography.selflanguage.org/_static/organizing-programs.pdf

>>25971
No, he said OOP when properly tried is great.

OOP is alright. the problem is orthodox OOP which started running rampant in the 90s due to certain cancerous books. people started treating it as a religion, completely disregarding alternative paradigms.

>>26014
>prototype based OOP actually makes more sense than class based.

nope, a class is the base of an object. hiding it makes no good according to the Zen. classes are only bad in JS, because JS is prototype based, so classes are sugar over prototypes being sugar over hidden classes being sugar over C++ classes (for those V8/Chuckcha engines, excluding quickjs-like) - 's the definition of a clusterfuck.

>>26017
> nope, a class is the base of an object.
No, it's not. It's an object devote to a specific creational pattern of other objects

> hiding it makes no good according to the Zen.
You are not hiding anything. On the opposite, adding classes you are adding a layer on top of objects
> lasses are only bad in JS, because JS is prototype based,
Again, classes are not necessary for objects to exists
> so classes are sugar over prototypes being sugar over hidden classes being
incorrect, again.
https://en.wikipedia.org/wiki/Prototype-based_programming

>>26018
>devote to a specific creational pattern of other objects

nobody gets this mumble-jumble. class is a scheme, a map of an object. every object has it.

>adding classes
is inevitable, it will happen either statically by developer or dynamically by the runtime

>classes are not necessary
necessary. learn the craft, then argue.

>>26016
maybe it started off as a religion but it turned into a cult and now it's basically just cargo cult

>>26006
>OOP will most likely trick you into making really bad architectural desitions.
individual's skill issue blamed on the paradigm

>>25924
>OOP does not solve the problem of when to stop subdividing so you don't end up with shit interfaces that get in the way of refactoring or optimizing. OOP does not solve the problem of giving your objects an easy-to-use interface for your business-logic scripts. OOP does not solve the problem of making code more legible.
no paradigm will magically resolve design and architecture decisions - those are the programmer's competences

>OOP does not solve the problem of making your code easier to debug.
it literally does
state being in a small and closed scope means you need to instantiate only a very small part of the program at a time to test and debug. in most cases you don't even need to spin up the whole application and can run only that small piece of code
unless someone is very deliberately breaking encapsulation, the state is guaranteed to be free from modification from outside its declared scope
of course if you write crap code with state leaking everywhere you won't get this advantage

> OOP does not solve the problem of which bits of program state should be statically allocated, thread-allocated or dynamically allocated.
no paradigm does
it's an implementation detail not within the scope of the paradigm

>>26019
I accept your concession

>>26019
> nobody gets this mumble-jumble
It's actually pretty simple. A class is not necessary for the existence of an object

Class in language like python are actually objects used to implement the creational pattern of class-instance. In class based OOP you can implement prototype creational pattern and in prototype based language you can emulate the class-instance one

> is inevitable, it will happen either statically by developer or dynamically by the runtime
Again, classes are not fundamental to OOP, they are a language design choice. Objects can exist without the concept of class, in a theoretical formulation (most of formal objects specification are classeless like lambda calculus with records, Cardelli's Object calculus, Prototype calculi (the one implemented by self,io and js)), just as in informal definition as in
> an object is a semantic entity that has state, behavior, and identity.
> https://en.wikipedia.org/wiki/Object_(computer_science)


> it will happen either statically by developer
No it wont

> or dynamically by the runtime
Can be avoided. Again, the hidden class concept is introduces just because performance tuning, it's not necessary

>>26023
>class is not necessary

necessary

>in language like python

classes

>classes are not fundamental to OOP

fundamental to the implementation of objects that are fundamental to OOP.

>Objects can exist without the concept of class

only imaginary objects. real objects exist with a blueprint that is called a class.

>in a theoretical formulation

we are not in the school mr.Teacher, no monoidal calculilusator allowed. only craft and pragmatismus.

>Can be avoided. Again, the hidden class concept is introduces just because performance tuning, it's not necessary

ye, im waiting when your supreme runtime will prove your supreme theory, until then, its all academic

>>25886
everyone that programs long enough contracts (p)OOP sickness at some point
not everyone recovers

>>26024
You could've said right away that you were retarded

>>26024
https://bibliography.selflanguage.org/implementation.html
selflanguage.org

Quote (verbatim from the page’s abstract):
“To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information …”

---

To compensate for the absence of maps, our system uses implementation-level hyperontological schematics to transparently group objects cloned from the same prototype, providing data-type information in a way that’s visible to the machine but opaque to the programmer …

>>26027
To compensate for the absence of hyperontological schematics, our system uses implementation-level zygogastric memo-fog prismatograms—a kind of hyperphlogiston nebulo-architecture to transparently group objects cloned from the same prototype, providing data-type information in a way that’s visible to the machine but opaque to the programmer …

>>25890
do you think classes and oop are the same thing?

>>26016
if you actually read the book, it clearly says "we studied a bunch of IRL codebases and observed these commonalities" not "hurr durr write your code like this and buzz the newbs when they do an "anti pattern"".
that was (((consultants))).

>>26012
you are conflating java with oop.
java's retardation that everything must be an object is a huge reason why oop in practice is as bad as it is. java programmers, aka rajesh patel and his 300 million cousins, worship java because sun has a jeet founder, and bring that retardation everwhere they go, namely c++

>>26027
> To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information
types are not the same as classes nigger, they are different concepts

Storing information about a function ('a -> 'a) **type** does not define nor it is a class and doesn't involves classes in any place you cretin

You seems rather confused to the point you are trying to bend commonly consolidated terminology in order to be right

>>26027
I'm fairly sure it was already been established that Self implemented hidden classes under the hood for performance reasons (as stated in the link you posted) in this comment here >>25985 and you can infer it was not out of necessity by keep reading
> To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and **eliminating the apparent space overhead for prototype-based systems**

, so I don't understand how you could have thought that your comment was some kind of gotcha

Unlucky for you, you're a pathetic namefag so you can't play dumb and pretend you didn't know it already and we can see you keep collecting so many L in this thread

>>26026
>namefag is retarded
Say it ain't so

>>26032
who cares, my view dominates - reflects the reality, and your view is a loser's, wannabe a better view.

>>26033
>a pathetic namefag

nothing is as pathetic as hiding crappy theory by renaming "class" to "plass" or alike.

--
ive figured out classes are better though, opinion is forged.