103 karma · joined July 22, 2022
Simple type systems can also offer equivalent safety with less flexibility. What make Haskell seem more safe is more the functional part combined with type safety. Functional programming eliminates out of order errors where imperative procedure were done in the wrong order.
Statistically more errors are caught by python runtime then an equivalent type checked c++ program simply because the python user interface fails hard and fast with a clear error message. C++ on the other doesn't do this at all. The symptoms of the error are often not related to the cause. Python is safer then C++. And this dichotomy causes insight to emerge. Why did python beat c++?
In this case the type checker is irrelevant. Python is better because of clear and deterministic errors and hard and fast failures. If this is exemplary of the dichotomy between c++ and python and if type checkers are irrelevant in this dichotomy it points to the possibility that type checking isn't truly what makes a language easier to use and safer.
The current paradigm is rust and Haskell are great because of type checking. This is an illusion. I initially thought this was well.
Imagine a type checker that worked like c++. Non deterministic errors and obscure error messages. Sure your program can't compile but you are suffering from much of the same problems, it's just everything is moved to compile time.
It's not about type checking. It's all about traceability. This is the key.
>there is less determinism with Python
You don't understand the meaning of the word determinism. Python is almost 100 percent deterministic. The same program run anywhere with an error will produce the same error message at the same location all the time. That is determinism. Type checking and unit testing does not correlate with this at all.
This is not the case with c++.
So that makes your statement contradictory. You think type checkers are important but you think python works because of garbage collection.
Either way I'm not talking about the implementation of the language. I'm talking about the user interface. Why is one user interface better than the other?
I bet you if c++ has sane error messages and was able to deliver the exact location of seg faults nobody would be complaining about it as much. (There's an implementation cost to this but I am not talking about this)
Even an ugly ass language like golang is loved simply because the user interface is straight forward. You don't get non deterministic errors or unclear messages.
Much of the fervor around dynamically typed languages in the past was driven largely by the dichotomy between c++ and other dynamically typed languages.
Nowadays it's more obvious what the differentiator was. But the point im making here is that type checking is NOT the key differentiator here.
Why does 100,000 lines of code of python tend to be safer and more manageable then 100,000 lines of C++ despite the fact that python has no type checker and C++ has a relatively advanced type checker?
Why do startups choose a python web stack over a C++ web stack?
I don't think it's "self-evident." I think there's something more nuanced going on here. Hear me out. I think type systems are GREAT. I think python type hints and typescripts are the way forward. HOWEVER, the paradox is real.
Think about it this way. If you have errors in your program, does it matter that much if those errors are caught during runtime or compile time? An error in compile time is caught sooner rather then later but either way it's caught. YOU are protected regardless.
So basically compile time type checking just makes some of the errors get caught earlier which is a slight benefit but not a KEY differentiator. I mean we all run our code and test it anyways despite whether the system is typed or not so the programmer usually finds most of these errors anyways.
So what was it that makes python easier to use then C++?
Traceability and determinism. Errors are easily reproduced, languages that always display the same symptoms from certain errors and in turn deliver error messages that are clear and are readable. These are really the key factors. C++ on top of non-deterministic segfaults, astonishingly even has compile time messages that can confuse users even further.
What many people didn't realize was that C++ was hard DESPITE the type system, not because of it. This was soon rectified with type script which eventually caused a complete flip of opinion in the industry once javascript developers realized how much better it is.
The other question to this equation is why was python so easy to program for DESPITE not having a type checker (it has external type checks now, but I'm saying before this)?
The answer is deterministic errors and easy traceability. If you have an error that happens either at runtime or at compile time you want to easily know what the error is, where it came from, and why it occurred. Python makes it VERY easy to do this. Not all type checkers make this easy (see C++).
In actuality type checking is sort of sugar on top of it all imo. Rust is great. But really the key factor to make programming more productive is traceability. Type checking, while good is not the key factor here.
Think about it. Whether the error occurs at runtime or compile time is besides the point. Compile time adds a bit of additional safety, but really if an error exists, it will usually trigger at some point anyways.
The thing that is important is that when this error occurs whether compile time or runtime you need as much information about it as possible. That is the key differentiator.
That is why typeless python and typed rust, despite being opposites, are relatively easy to write complex code for when compared to something like C++.
3. Go compiles so fast it's not that far off from an interpreted language.
2. It's not as big of a scripting language but it's close enough such that I can see justification for it's usage.
1. Yeah but go can be installed pretty quickly from package managers on every linux distro out there.
Your lack of knowledge about this fact, however, is a symptom of intelligence.
Setters are not used in any other programming paradigm. Not in FP, not in C style programming... Any style of programming that strictly is not OOP does not use setters.
OOP is not formally agreed upon in academia there is no consensus. So your reliance on academia here is flawed. Use your own brain rather then blindly trusting others. You know about the replication crisis right? Science is found to be wrong over 50% of the time especially in fields like psychology. Don't be blind.
You don't even know who wrote the IEEE definition and who validated it. Second this isn't academic truth. This is just some arbitrary chosen standard chosen by industry. Not academic at all.
In mathematics, the ultimate logical form of academia there is a term for "interfaces". It's called categories, and there's a entire theoretical framework behind it called "Category Theory". This theory of "interfaces" goes beyond just OOP and category theory can be used to foundation-ally describe all of mathematics and function as a sort of replacement of set theory.
Don't worship authority for authorities sake. If the IEEE declared 1+1=3 would you believe it? Instead use your own brain. Do my arguments have merit? Does the IEEE definition seem inconsistent? Does my definition make logical sense? If you can think of these things on your own merits instead of blindly following the IEEE then you'll see that the definition of OOP is just something academia hasn't really thought about deeply from a theoretical and mathematical standpoint. OOP is more like a term that comes from applied engineering with very little theoretical foundation.
If you want some sort of authority I googled some authoritative talk about category theory explained to programmers: https://www.youtube.com/watch?v=JMP6gI5mLHc
I'm sure maybe you heard of haskell and category theory? Haskell is a purely functional language and it has huge connections with category theory. Basically Haskell IS the language of interfaces. It's entire type system is centered around categories or AKA "interfaces". It is the defacto language of interfaces much more-so then OOP languages like Java.
If you said haskell was OOP, people who love that language would vomit. Haskell is not OOP, but it has interfaces, so the obvious conclusion here is "interfaces" ARE not an OOP exclusive concept. It's therefore bad for a formal definitio of OOP.
So now the question is WHAT is it about OOP that makes it uniquely OOP. Or is it just a hodgepodge of random stuff and it will be forever a word that is muddy, inconsistent and poorly defined?
You should be asking the question in what way does OOP mutate state and what other programming paradigms don't? What described above is unique to the oop style.
In general when you write rust. Unless you love oop, in general the syntax isn't set up to promote you creating a graph of objects that mutate one another. Java promotes this style the most.
For rust the style the syntax promotes is movement of data through pipelines. The data can get manipulated as it moves through the pipeline.
For functional programming it's similar. You have pipelines, but nothing is being manipulated. Each segment of the pipe in this case takes an input and produces a new output without moving or changing anything.
Interfaces exist in functional languages as well. You need to search for the thing that is uniquely oop. Interfaces is not it. Clearly this is an inconsistency.
If IEEE defines interfaces as oop then it is also saying functional programming is oop. This doesn't mesh with our intuition of the meaning of these two terms.
There is a differentiator that is uniquely oop and uniquely functional and that is mutation via setters vs. immutability. Functional programs must be immutable, while oop allows for mutation via setters.
Some people like to roll with the notion that oop and functional are orthogonal concepts, this is an inconsistent notion. You have to realize that mutation via setters definitively makes the two concepts parallel and opposite. Functional cannot mutate.
If the industry ever truly mathematically formalized the term oop rather then relying on crude improvised guidelines via IEEE then mutation via setters is the formal definition of oop.
Everyone nowadays gets confused because lack of proper formalism. The think if they used a method like a getter or inheritance or a class, then they did oop. When this is the case, suddenly everything looks like oop. Suddenly oop is prevalent and the dominant paradigm and used everywhere.
I have object a and I have object b. A is similar to b. How do I define a in terms of b? That is inheritance. Functional languages can support this type of syntactic sugar. It is not exclusive to OOP.
A venn diagram.
The left is all other programming paradigms. The right is oop. Most of the oop stuff is in the intersection of these circles. What's to the right is encapsulated mutation. Getters and setters and variants of these two concepts. Mostly setters though.
All of oop is simply instantiated objects manipulating and communicating with each other with getters and setters. This is unique to oop. You can't even imitate this with a functional language.
But it shouldn't be functional vs. oop. You can avoid writing any getters and setters in your program and while you wouldn't be doing oop, you wouldn't be doing functional either.
mutate_function(a) is isomorphic to a.mutate_method(). The latter is oop the former is not. There is a design tradeoff here that's actually well known and named. I forgot what it was called though. But also note how I used mutate here in the names. It's because this property of mutation is the main differentiator that causes oop to be different.
If everything was immutable but you still used methods everywhere it wouldn't be uniquely oop. It would be functional as well. And if you think about it is the very property of mutation that allows objects to communicate and mutate one another which fits with our intuition of what oop is. That's why methods that mutate should formally define oop and what it actually is.
Interfaces are part of type theory. Generics so to say.
The unique thing about OOP is objects with mutating state that communicate with one another. This is really the only part of OOP that is uniquely OOP. All other things that are "OOP" like interfaces or object.method() notation are not intrinsic to oop.
Rust moves away from this paradigm I describe.
What I mean by OOP is the smallest unit of programming being an Object with mutating data. These objects are basically combinations of mutable data and methods tied together into entities. Imagine a graph of a bunch of mini-programs with mutating state, moving around, getting injected into one another and talking to one another. This is OOP.
This is opposed to another style of programming where data flows through pipelines from input to output rather then a bunch of entities messaging each other and changing each others state. Both Rust and Go are moving away from this OOP paradigm of programming by putting less emphasis on OOP based syntax.
I highly disagree. It is not "pointless semantics". To think everything in the world is some tool in a toolbox and nothing is truly ever bad and everything has a use is naive. Some things are good some things are bad and some things are OOP while other things are not.
Rust is not focusing on the OOP philosophy. Both GO and Rust are moving away from that style of abstraction in terms of philosophical goals. If you want to twist the language into OOP that's still possible and still your prerogative. But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists.
I'm not saying OOP is bad. I'm saying that this is the current status quo. My opinion on the OOP style was not mentioned at all.
China would not even bother with half the stuff they accomplished for space if it were not the existence of a competitive goal. The irony is what the US tried to do to contain them in actuality enabled them.
There's no doubt in my mind that part of what's driving China in not just the space race is the fact that they want to beat the US.
Sure, if this is what he means, then he is correct. But what he wrote is just "thinking" which is false.
>which is why I disagree with your statement that they are lying to themselves, ignoring the existential truth that we are always lying to ourselves.
It is a bit. The success of problem solving usually comes with only a mild dopamine hit. There are way more situations that create a greater surge of dopamine. Parent stated "thinking" was the most pleasurable thing ever which obviously not the case for people in general.
For example it's much more pleasurable to win a billion dollars or successfully bed the hottest girl in the club or to dominate everyone else in some competition. Clearly our biology is geared towards giving huge rushes of dopamine for situations that aren't exactly tied to "thinking" or strictly "problem solving". I find it hard to believe that the parent is completely unaware of this. He must know on some level. That's why I claim he's lying to himself.