Object oriented programming in Python be like:
-
Sorry, I'm too Rust-pilled for this OOP nonsense
pub fn new() -> Self { Self::self().self.unwrap() }
Reminds me of java
I have
Toolkit toolkit = Toolkit.getDefaultToolkit();
seared into my brain. Then there were the bean factories… -
nah, I'm never complaining about
self
in Python after having tried thethis
andthat
nonsense in JS.oh, you're using a named function instead of an arrow fn? Guess what,
this
is not what it used to be anymore.Wait there's a "that"???
-
that's because anyone who develops oop in Python is mentally ill.
Python is a scripting language, not to be confused with an actual programming language. Like everything else in development over the last decade, newbs are just shoehorning whatever is hot into the language because nobody is stopping them.
C/C++ are just scripting languages that have to become OS+arch -specific byte-code before execution.
-
Explicit vs implicit. Ive always liked it being explicit like that. It's better than magic keywords in say ruby.
Personally the "spaces are code" gets on my nerves for the same reason. It's implicit to the language so you just have to remember.
Am I not YAMLy enough for your YAML club?
-
that's because anyone who develops oop in Python is mentally ill.
Python is a scripting language, not to be confused with an actual programming language. Like everything else in development over the last decade, newbs are just shoehorning whatever is hot into the language because nobody is stopping them.
oop hasn't been "hot" for 20 years.
-
Wait there's a "that"???
Only if you define it.
const that = this
-
Am I not YAMLy enough for your YAML club?
Heh yeah yaml is another one.
-
Only if you define it.
const that = this
I remember that a long time ago. Oh god
-
C/C++ are just scripting languages that have to become OS+arch -specific byte-code before execution.
c and c++ require compilation to run though. Python does not. it runs through an interpreter. thus it's a scripting language.
same can be said for node, ruby, and other interpreted languages.
the problem with Python specifically is that it can't define itself as more one than the other. this makes developing in it messy and difficult because it refuses to adopt one over the other and fails to standardize. that's why we get little idiosyncrasies like the self referencing OOP in Python. it's been shoved into the language without any real concern for maintainability or longevity in the language and is only meant to fit into every crack and crevasse, like a putty(or shit).
it took almost two decades for them to implement a switch/case that doesn't even work like 99% of all languages because it was an afterthought. when devs complained through official channels they were told to pound sand.
Python is a hammer in a screw driven world. You can nail those screws in to solve your problems, but you'll never get them back out.
Python doesn't deserve half of the praise it gets because they continue to piss on developers and have the audacity to tell them it's rain. not only that, the corporate interests (google) are pulling financial support of the language for the "new thing".
my hope is that Python gets the same treatment that the Python community gave to devs.
-
c and c++ require compilation to run though. Python does not. it runs through an interpreter. thus it's a scripting language.
same can be said for node, ruby, and other interpreted languages.
the problem with Python specifically is that it can't define itself as more one than the other. this makes developing in it messy and difficult because it refuses to adopt one over the other and fails to standardize. that's why we get little idiosyncrasies like the self referencing OOP in Python. it's been shoved into the language without any real concern for maintainability or longevity in the language and is only meant to fit into every crack and crevasse, like a putty(or shit).
it took almost two decades for them to implement a switch/case that doesn't even work like 99% of all languages because it was an afterthought. when devs complained through official channels they were told to pound sand.
Python is a hammer in a screw driven world. You can nail those screws in to solve your problems, but you'll never get them back out.
Python doesn't deserve half of the praise it gets because they continue to piss on developers and have the audacity to tell them it's rain. not only that, the corporate interests (google) are pulling financial support of the language for the "new thing".
my hope is that Python gets the same treatment that the Python community gave to devs.
Python is compiled at "runtime" to a similar OS+arch byte-code minus ELF headers that Linux binaries typically have from gcc.
My point was it's a stupid distinction and worthless when the other points about poor implementations of common language frameworks are plenty on their own is all, and it's needlessly snobbish.
As far as class variable reference however I wish more languages self-referenced. In my eyes it makes it far clearer at a given line of code glance as to where the hell a value came from as opposed to just by name. I feel a keyword like
self::variableName
, or maybe more aptly&self
as a pointer to reference in C++ would be very clear, like Rust does, which is very much, by the original definition, a programming language instead of scripting. Even Java, which is definitely not a scripting language though is still run inside a virtual machine, usesthis
. I don't personally like the term versusself
, but eh.Though if you want a hammer in a screw-driven world look no further than Electron. I think it puts anyone else's even purposeful attempts at such to shame.
-
nah, I'm never complaining about
self
in Python after having tried thethis
andthat
nonsense in JS.oh, you're using a named function instead of an arrow fn? Guess what,
this
is not what it used to be anymore.As a non-programmer who's occasionally dabbled with wxPython, I've entangled myself with self.parent.parent and their childs/siblings more than once. At that stage I know my project is done.
-
oop hasn't been "hot" for 20 years.
Might not be hot, but it is sticky.
-
Wait there's a "that"???
wrote on last edited by [email protected]it's common practice as a workaround to save
this
when changing contexts, sincethis
may change under you, in callbacks and such -
that's because anyone who develops oop in Python is mentally ill.
Python is a scripting language, not to be confused with an actual programming language. Like everything else in development over the last decade, newbs are just shoehorning whatever is hot into the language because nobody is stopping them.
You're right in that OOP feels very shoehorned in with Python. But not every project has a Linus Torvalds to publicly humiliate horrible ideas and implementations.
-
Reminds me of java
I have
Toolkit toolkit = Toolkit.getDefaultToolkit();
seared into my brain. Then there were the bean factories…At least with Rust, there is a specific, defensible goal for why it does that.
Java is just over designed. All of
java.io
reads like somebody's Object Orientated Programming 101 final project, and they'd get a B- for it. Lots of things where you can see how they're abstracting things, but there's no thought at all in bringing it together in a tidy way. -
that's because anyone who develops oop in Python is mentally ill.
Python is a scripting language, not to be confused with an actual programming language. Like everything else in development over the last decade, newbs are just shoehorning whatever is hot into the language because nobody is stopping them.
What 2003 forum thread did this comment crawl out of?
-
At least with Rust, there is a specific, defensible goal for why it does that.
Java is just over designed. All of
java.io
reads like somebody's Object Orientated Programming 101 final project, and they'd get a B- for it. Lots of things where you can see how they're abstracting things, but there's no thought at all in bringing it together in a tidy way.Not like C# is all that much better. So much garbage in the fundamentals just because it was done that way at the start and "they can't change it now". The best example is the IList interface.
Theoretically this interface exposes both index-based access and collection-like modifications and as such would be perfect in a function if you need those two features on a type. In reality you can't use it as a function parameter because half the official types implementing IList aren't modifiable and throw a runtime error. E.g Arrays
-
Sorry, I'm too Rust-pilled for this OOP nonsense
pub fn new() -> Self { Self::self().self.unwrap() }
Even regular Rust code is more "exciting" than Python in this regard, since you have a choice between
self
,&self
, and&mut self
. And occasionallymut self
,&'a self
, and evenself: Box<Self>
. All of which offer different semantics depending on what exactly you're trying to do. -
I remember that a long time ago. Oh god
I remember this too... what a nightmare.
-
nah, I'm never complaining about
self
in Python after having tried thethis
andthat
nonsense in JS.oh, you're using a named function instead of an arrow fn? Guess what,
this
is not what it used to be anymore.Oh, you assigned a method to a variable before calling it? Congratulations,
this
is nowundefined
.