Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
deltasevennine
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
13 ms
·
61.
▲
by
deltasevennine
4y ago
Hindley mindler allows for flexibility in your types and this high abstraction and usability in code. The full abstraction of categories allows for beautiful and efficient use of logic and code but it's not safety per se. Simple type
62.
▲
by
deltasevennine
4y ago
I know it happens "all the time" but these runtime errors happen fast and quick. You catch most of these issues while testing your program. Statistically more errors are caught by python runtime then an equivalent type checked c++
63.
▲
by
deltasevennine
4y ago
Your argument makes no sense. I say the type checker is not the key differentiator then you say for python the key differentiator is the garbage collector. So that makes your statement contradictory. You think type checkers are important bu
64.
▲
by
deltasevennine
4y ago
Paradoxes don't exist in reality. It's a figure of speech based on something that was perceived as a paradox. This much is obvious. Much of the fervor around dynamically typed languages in the past was driven largely by the dichot
65.
▲
by
deltasevennine
4y ago
But there's a paradox. 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 star
66.
▲
by
deltasevennine
4y ago
Types got a bad wrap because of C++. There was a strange dichotomy between languages like python/javascript and C++. If type systems were so good why was it easier to program with javascript and python then with C++? People got confuse
67.
▲
by
deltasevennine
4y ago
4. Type hints make python readable, but with as with most scripts people avoid type hints. This makes python actually less readable then go. Additionally python syntax allows for some very convoluted patterns. This is less the case for go.
68.
▲
by
deltasevennine
4y ago
Suffering is a function of familiarity with the language and the intelligence of the user. Go is good enough such that if you had familiarity with both python and go, usage of either is justifiable in terms of expressiveness and ease of use
69.
▲
by
deltasevennine
4y ago
Naw. Youre thinking inheritance. That's not what it is. Inheritance can be used in FP. It's not uniquely OOP at all. The only thing uniquely OOP is the concept of setters. It's fundamental and isn't some side concept eit
70.
▲
by
deltasevennine
4y ago
The language authors agree with me. Your slides don't prove anything, it's just explaining the relationship not the origin. I'm not pulling this out of my ass. Your comment is also just fucking rude. Please stop.
71.
▲
by
deltasevennine
4y ago
type classes ARE interfaces and they ARE categories. You can say the the programming methodology is influenced from OOP using this concept. But as a taxonomy the naming is improper. Categories is the most rigorously defined vocabulary for t
72.
▲
by
deltasevennine
4y ago
> I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet. You don't even know who wrote the IEEE definition and who validated it. Second th
73.
▲
by
deltasevennine
4y ago
Rust is not geared towards oop. But it can be bent to do that. 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
74.
▲
by
deltasevennine
4y ago
That literature is wrong. Interfaces exist outside of of oop. Saying it's oop is like saying addition is oop because you used it in your programs. Interfaces exist in functional languages as well. You need to search for the thing that
75.
▲
by
deltasevennine
4y ago
Inheritance is not oop. If you think about it inheritance is syntactic sugar around definitions of objects. Not really a programming style because it doesn't change the structure of your program in terms of state and logic. These are s
76.
▲
by
deltasevennine
4y ago
It can be done. But you don't compare it to rust. You compare it to programming paradigms. This is because rust can be bent to support oop along with almost every language out there. So what you imagine is this: A venn diagram. The lef
77.
▲
by
deltasevennine
4y ago
But he's saying the style is bad. Therefore new languages don't support it, well. What do you have to say to that rather then reiterating what everyone knows that OOP is a style of programming.
78.
▲
by
deltasevennine
4y ago
Interfaces are not oop. 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
79.
▲
by
deltasevennine
4y ago
That's the same as a deeply nested data structure. A product type. It's not exclusively an OOP concept but it could be to someone who hasn't really delineated the concept of what OOP is. What I mean by OOP is the smallest uni
80.
▲
by
deltasevennine
4y ago
You can twist any language to be OOP if you want. However rust is not primarily focused towards that type of abstraction. Java and C++ are focused towards it. I highly disagree. It is not "pointless semantics". To think everything
81.
▲
by
deltasevennine
4y ago
In terms of zero cost abstractions, yes. In terms of OOP. No.
82.
▲
by
deltasevennine
4y ago
Exactly. High performance applications with zero cost abstractions are required to truly be a successor. Go or Java will never replace C++ for high performance applications like Game engines. Rust might replace it though.
83.
▲
by
deltasevennine
4y ago
well you're wrong. My statement was categorically true. And if you follow the thread I reveal highly informative knowledge about it all. Your comment here is the one that is a casual dismissal and completely incorrect blanket generaliz
84.
▲
by
deltasevennine
4y ago
All competition is wasted effort. Perfect collaboration always wins. But competition is what motivates humans, and unfortunately this inefficient way of working is what drives humanity forward. China would not even bother with half the stuf
85.
▲
by
deltasevennine
4y ago
You fail to see the magnitude of what occurred to china. Yes there's a market for cheap knock offs. But there's also the fact that how almost 90% of Americas manufacturing know-how has moved to china.
86.
▲
by
deltasevennine
4y ago
Have you seen what China has become in the past 2 decades? The technological growth and development is unlike anything ever seen in the history of mankind. Not only are you wrong. You are gravely wrong. The likelihood of China surpassing th
87.
▲
by
deltasevennine
4y ago
Yeah I agree. But competition breeds advancement. It has roots from capitalism all the way down to natural selection and survival of the fittest. It works. There's no doubt in my mind that part of what's driving China in not just
88.
▲
by
deltasevennine
4y ago
Unlikely. This is more economic rivalry then actual worry that China is going to suddenly flip.
89.
▲
by
deltasevennine
4y ago
>And thinking->problem solving->success is a plausible path to get there 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 state
90.
▲
by
deltasevennine
4y ago
It sort of is a trick, yet it isn't: I elucidate what's going on here: https://news.ycombinator.com/item?id=33430120
More ›