Go and Rust – objects without class • Hacker News Board

Re: Go and Rust – objects without class

#51

Post by evincarofautumn » Sat, May 04, 2013, 10:22 PM UTC

cpeterso wrote: post #42

evincarofautumn wrote: post #40

Earlier quoted context omitted.

I was a bit backward with my language. What I was trying to get at is that many OO languages encourage you to add fields in derived classes. This makes the derived class a supertype, being a larger set that fully includes the set of its parent class. You’re adding elements to a product type. But this often breaks substitutability, so to conflate class inheritance (a useful concept) with subtyping (another useful conc…

When a derived type add new fields, it is restricting the type's range, not expanding the base type's capabilities.

Range and capability are separate concepts. That’s what I’m getting at—conflating them is problematic, not least because it’s trying to statically specify dynamic behaviour.

Here’s a simple example. A 2D vector (x:ℝ × y:ℝ) is a subtype of a 3D vector (x:ℝ × y:ℝ × z:ℝ). The range of the 3D vector includes that of the 2D one, but there is no sane way to make one a subclass of the other, due to differences in behaviour—magnitude, for instance.

Re: Go and Rust – objects without class

#52

Post by PommeDeTerre » Sat, May 04, 2013, 10:22 PM UTC

munificent wrote: post #36

tambourine_man wrote: post #25

Earlier quoted context omitted.

Real world software, as you say, with money, clients and deadlines, is written in JavaScript all the time. It's not like it is a toy language or academic research project. It's the widest deployed platform in the world.

> Real world software, as you say, with money, clients and deadlines, is written in JavaScript all the time. That says a lot about the lack of alternatives for code that must run in a browser and next to nothing about the merits of prototypes. I have the fortune to work with a bunch of people that worked on Self, or worked with people that did. Many of them told me that after all of that experience, the conclusion th…

It's encouraging to see such functionality at least being proposed for JavaScript. While it doesn't do much to fix many of the other inherent problems that the language is riddled with, it does at least show some small degree of sensibility going forward.

Re: Go and Rust – objects without class

#53

Post by evincarofautumn » Sat, May 04, 2013, 10:29 PM UTC

PommeDeTerre wrote: post #48

SeanDav wrote: post #46

Earlier quoted context omitted.

You are doing a lot of hand waving, with very little backup. Where are your credible sources that class based OO is so much better than prototype based OO? Personally I find prototype based OO very powerful and easy to use, but you won't catch me saying it is "better" in any way than class based OO. Once again, where is your proof?

Decades of personal experience dealing with many large-scale, real-world software systems written by many different developers, using many programming languages offering a variety of OO approaches. With such experience comes the realization that there are big differences between the different approaches. Some are seriously inferior to others. Some generally aren't better or worse than others. Some are obviously bette…

I have worked with a relatively large JavaScript system (about 20k lines) and found that the vast majority of maintainability problems had to do with dynamic typing and late binding, not prototypal inheritance. This could be a feature of different codebases making different use of the language.

Re: Go and Rust – objects without class

#54

Post by noblethrasher » Sat, May 04, 2013, 10:58 PM UTC

usea wrote: post #45

I've been developing medium-to-large projects in mostly C# over the past two years. One thing about my style that has changed over that course of time is that I almost never use inheritance anymore. When I was in school, it was my primary tool for code reuse, but now I find it conflates solutions to different problems, as well as hampering readability. My style now is small classes with a few, small methods each and…

Same here. I used to look for places to use inheritance but now only inherit from abstract classes, seal everything else by default, and mark all of my fields readonly.

Re: Go and Rust – objects without class

#55

Post by pcwalton » Sat, May 04, 2013, 11:16 PM UTC

PommeDeTerre wrote: post #44

pcwalton wrote: post #41

Earlier quoted context omitted.

You keep showing up in unrelated threads talking about how JavaScript is terrible, even when it isn't remotely relevant to the topic at hand. Case in point: the models of Rust and Go have nothing to do with prototype-based OO. Typeclasses as Rust uses are in fact about as far as you can get from prototype-based OO: they are less dynamic, not more dynamic. There is no virtual dispatch involved at all. Neither Rust nor…

Patrick, please notice that I replied to pjmlp's comment, which specifically mentioned JavaScript and its prototype-based OO. While the article may be about Rust and Go, some of the discussion here may naturally go beyond the article's content.

Apologies, I didn't notice that pjmlp posted about JS.

Re: Go and Rust – objects without class

#56

Post by SeanDav » Sun, May 05, 2013, 2:33 AM UTC

PommeDeTerre wrote: post #48

SeanDav wrote: post #46

Earlier quoted context omitted.

You are doing a lot of hand waving, with very little backup. Where are your credible sources that class based OO is so much better than prototype based OO? Personally I find prototype based OO very powerful and easy to use, but you won't catch me saying it is "better" in any way than class based OO. Once again, where is your proof?

Decades of personal experience dealing with many large-scale, real-world software systems written by many different developers, using many programming languages offering a variety of OO approaches. With such experience comes the realization that there are big differences between the different approaches. Some are seriously inferior to others. Some generally aren't better or worse than others. Some are obviously bette…

Right, so that was your opinion. Nothing wrong with having an opinion but on HN we try to back our opinions with real world data, otherwise it becomes just a case of he-said, she-said.

Have you ever considered that the suitability or otherwise of Javascript for huge projects might be attributed to other aspects of the language, rather than prototype based OO?

Re: Go and Rust – objects without class

#57

Post by PommeDeTerre » Sun, May 05, 2013, 11:13 AM UTC

SeanDav wrote: post #56

PommeDeTerre wrote: post #48

Earlier quoted context omitted.

Decades of personal experience dealing with many large-scale, real-world software systems written by many different developers, using many programming languages offering a variety of OO approaches. With such experience comes the realization that there are big differences between the different approaches. Some are seriously inferior to others. Some generally aren't better or worse than others. Some are obviously bette…

Right, so that was your opinion. Nothing wrong with having an opinion but on HN we try to back our opinions with real world data, otherwise it becomes just a case of he-said, she-said. Have you ever considered that the suitability or otherwise of Javascript for huge projects might be attributed to other aspects of the language, rather than prototype based OO?

No, it's more than just my opinion. I'm merely stating the facts that exist regardless of my personal preferences or beliefs. I can't provide you with pretty graphs or tables of data to back this up, but the effects are very real and easily observed by those who have experienced similar situations.

JavaScript has many, many, many other problems aside from its use of prototype-based OO. It is a truly awful language is almost every respect. But the problems caused by its broken OO system are very obvious, and the impact they have on the maintainability of JavaScript software are extremely real. Its prototype-based OO is responsible for an entire family of its issues.

Re: Go and Rust – objects without class

#58

Post by StefanKarpinski » Sun, May 05, 2013, 1:39 PM UTC

vanderZwan wrote: post #13

pat_punnu wrote: post #9

Earlier quoted context omitted.

"If you think of a type as a set of possible values" You can't do that! You fall foul of Russell's paradox - sets as types simply don't work!

Elaborate please?

As a consequence/means of avoiding Russel's paradox, the standard axiomatization of set theory (ZFC), doesn't allow sets to contain themselves (so no set of all sets). Thus, if types are sets of values, and types are values, you've got a problem since the type of types seems to be a set that contains itself. Of course, I think this just means that well-founded set theories like ZFC are a poor choice for modeling type systems for languages with first-class types. There are set theories that allow sets to contain themselves [http://en.wikipedia.org/wiki/Non-well-founded_set_theory]. Such set theories don't replace ZFC, but rather extend it, adding "hypersets", which are the sets that contain themselves – the well-founded sets behave as usual.

Re: Go and Rust – objects without class

#59

Post by munificent » Thu, May 16, 2013, 12:23 AM UTC

evincarofautumn wrote: post #40

munificent wrote: post #35

Earlier quoted context omitted.

> If you think of a type as a set of possible values, then a subclass is actually a supertype—a superset of the possible values of its parent class—and likewise a superclass is a subtype. You have this exactly backwards. A subclass is a subtype. A superclass is a supertype. Let's say you have superclass A and derive subclass B from it. In the universe of all possible values, some will be A but not B (they will either…

I was a bit backward with my language. What I was trying to get at is that many OO languages encourage you to add fields in derived classes. This makes the derived class a supertype, being a larger set that fully includes the set of its parent class. You’re adding elements to a product type. But this often breaks substitutability, so to conflate class inheritance (a useful concept) with subtyping (another useful conc…

> This makes the derived class a supertype, being a larger set that fully includes the set of its parent class.

This is not how "supertype" is typically defined in the literature. I'm not sure what "set of its parent class" means, but I believe the way to look at this is to consider the universe of all possible objects.

In that universe, you will have some objects that are instances of the derived class. Each of those is also an instance of the base class. You may also have instances of the base class that are not instances of the derived class (they may be straight instances of the base, or be instances of some other sibling derived class).

That means the set of instances of the base class completely includes the set of instances of the derived class (since every derived is also a base). Hence, the base class is a supertype. Conversely, since the set of instances of the derived class may not include some instances of the base class, it is a subtype.

> You’re adding elements to a product type.

I don't think you can cleanly map classes to tuple types. Consider a derived class that adds no fields. In that case, it's not an identical type to its base class, but it would be an identical product type.

Re: Go and Rust – objects without class

#60

Post by munificent » Thu, May 16, 2013, 12:33 AM UTC

evincarofautumn wrote: post #51

cpeterso wrote: post #42

Earlier quoted context omitted.

When a derived type add new fields, it is restricting the type's range, not expanding the base type's capabilities.

Range and capability are separate concepts. That’s what I’m getting at—conflating them is problematic, not least because it’s trying to statically specify dynamic behaviour. Here’s a simple example. A 2D vector (x:ℝ × y:ℝ) is a subtype of a 3D vector (x:ℝ × y:ℝ × z:ℝ). The range of the 3D vector includes that of the 2D one, but there is no sane way to make one a subclass of the other, due to differences in behaviour—…

> Here’s a simple example. A 2D vector (x:ℝ × y:ℝ) is a subtype of a 3D vector (x:ℝ × y:ℝ × z:ℝ).

Again, I think that's backwards. Every 3D vector is also a 2D vector if you ignore its z coordinate, so 3D vectors are a subtype of 2D vectors (assuming some type system that has subtyping between tuples of fewer fields).

You could implement this by having 3D vector subclass 2D, but as you note that's fraught with peril. But that's because substitutability requires meaningful semantic behavior and not just matching signatures. Just because two objects can both "foo" doesn't mean they are substitutable in a pragmatic sense. They have to do the appropriate thing when you foo them.