Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go and Rust – objects without class

lwn.net

Post reply on HN
Print view View original

21–30 of 60 posts

Re: Go and Rust – objects without class

#21

Post by PommeDeTerre »

pjmlp wrote: post #6
evincarofautumn wrote: post #5

The value of Go and Rust, I think, is that they are object-oriented languages that try to avoid conflating classes with types. 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. The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially th…

The problem I see, is that the average programmers are only aware of the OO models popularized by C++, Java and friends, while there are quite many to choose from. This is one reason why so many have problems with prototype inheritance in JavaScript, which is also not the only language having it. I find positive that so many OO models exist to choose from.

Not all tools are equal, however.

The class-based OO approach of C++ has proven to be practical for real-world software development. The same goes for the approaches taken by Java and C#, for example. While they can be abused, these approaches generally provide a usable balance between conceptual comprehensibility, consistency, modularity, code sharing/reuse, and the ability to model a variety of realistic domains.

The same can't be said of JavaScript's prototype-based OO. It's not that people have trouble understanding it; they know it perfectly well. It's just that, when being used to write real-world software, it is nowhere near as convenient and practical as class-based OO.

This is largely why we see so much effort go toward faking class-based OO within so many different JavaScript libraries and applications. JavaScript doesn't natively (yet) provide the tooling that developers need (class-based OO), so they're forced to try to implement it themselves using what JavaScript does offer. And the results usually are quite horrid. The fact that Self, Io and other prototype-based languages never really took off is similarly related, I suspect.

Choice between different OO models isn't a bad thing. But when it comes to real-world software development, where there are clients, deadlines, and money to be made, developers need tools that work. Class-based OO has proven itself as a useful tool. Prototype-based OO has been more of a hindrance than a benefit, on the other hand.

Re: Go and Rust – objects without class

#22

Post by discreteevent »

From a high level programming in Go looks to me to be very like programming with Microsoft's COM. It's interface oriented, no inheritance. You could say that this is the purest form of OO if you take Alan Kay's viewpoint that the emphasis should be on the messages and not the object. In COM you have QueryInterface and in Go you have interface matching and casting. QueryInterface or an interface cast is like a hinge between dynamic and static typing. You get great flexibility but still preserve your abstractions in that you never depend on an implementation. Of course you can do this in, say, java by using instanceof to match against an interface but the difference with COM and Go is that it is a primary mechanism and so the code written in the language tends to use this pattern a lot. i.e. It's encouraged.

See this example from Russ Cox:

https://groups.google.com/forum/#!msg/golang- nuts/Rj5t1h_ztxI/Fgs6HfLqMHAJ

Re: Go and Rust – objects without class

#23

Post by drivebyacct2 »

strmpnk wrote: post #3
metajack wrote: post #2

This is a good article, although I'm not sure its appropriate to post a subscriber link.

It seems like it's allowed explicitly by LWN: "The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!"

Wow, that's a damn good/smart policy of them, makes me want to get a subscription.

Re: Go and Rust – objects without class

#24

Post by fauigerzigerk »

mseepgood wrote: post #19
fauigerzigerk wrote: post #15

Earlier quoted context omitted.

I think this points to a seperate issue as well: Often times we have a choice to express the same thing through types or through state. As the influence of functional languages grows, we tend to choose types more often. It wouldn't be surprising to have a ReadOnlyFile type and a ReadWriteFile type. This can easily be justified because an individual file object doesn't need to change its read/write property after it h…

> As the influence of functional languages grows, we tend to choose types more often. FP does not imply static types. See Lisp and its dialects. Don't confuse the Haskell way of doing things with FP in general.

My point isn't a formal one but rather an observation about software design trends.

More imporantly though, what FP does in both its dynamically and statically typed incarnations is to prefer (and sometimes enforce) immutability.

Immutable objects support a much more type centered view of the world. Theoretically, you could have something like a VehicleAtFullSpeed type (dynamic or static) because the speed attribute of an individual object never changes.

Re: Go and Rust – objects without class

#25

Post by tambourine_man »

PommeDeTerre wrote: post #21
pjmlp wrote: post #6

Earlier quoted context omitted.

The problem I see, is that the average programmers are only aware of the OO models popularized by C++, Java and friends, while there are quite many to choose from. This is one reason why so many have problems with prototype inheritance in JavaScript, which is also not the only language having it. I find positive that so many OO models exist to choose from.

Not all tools are equal, however. The class-based OO approach of C++ has proven to be practical for real-world software development. The same goes for the approaches taken by Java and C#, for example. While they can be abused, these approaches generally provide a usable balance between conceptual comprehensibility, consistency, modularity, code sharing/reuse, and the ability to model a variety of realistic domains. T…

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.

Re: Go and Rust – objects without class

#26

Post by justincormack »

drothlis wrote: post #20
strmpnk wrote: post #3

Earlier quoted context omitted.

It seems like it's allowed explicitly by LWN: "The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!"

"Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared." -- https://lwn.net/op/FAQ.lwn#slinks

It is probably preferable to the free link being posted a week later as it makes people aware of the subscription.

Re: Go and Rust – objects without class

#27

Post by drothlis »

drivebyacct2 wrote: post #23
strmpnk wrote: post #3

Earlier quoted context omitted.

It seems like it's allowed explicitly by LWN: "The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!"

Wow, that's a damn good/smart policy of them, makes me want to get a subscription.

All articles are also available free of cost one week after the initial publication.

Re: Go and Rust – objects without class

#28

Post by PommeDeTerre »

tambourine_man wrote: post #25
PommeDeTerre wrote: post #21

Earlier quoted context omitted.

Not all tools are equal, however. The class-based OO approach of C++ has proven to be practical for real-world software development. The same goes for the approaches taken by Java and C#, for example. While they can be abused, these approaches generally provide a usable balance between conceptual comprehensibility, consistency, modularity, code sharing/reuse, and the ability to model a variety of realistic domains. T…

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.

I think that you've missed the fact that we're discussing OO techniques and approaches here, rather than the overall usability of JavaScript.

The software I mentioned includes JavaScript written in exchange for money, for clients, facing deadlines, in addition to open source JavaScript projects that may not face such constraints.

In such code, we often see prototype-based OO not living up to the hype, and not being suitable for real-world work. Due to these failings, we see many, many developers resort to implementing some limited subset or variant of class-based OO using the functionality that JavaScript does offer. The fact that we see this going on time and time again, involving many different developers, all across the world, over the course of many years should tell us something. I think that "something" is that class-based OO is inherently superior to prototype-based OO for the types of problems typically encountered when developing practical software.

Besides, C is the widest-deployed platform in the world. Add in C++, and their share of the market is absolutely huge. Basically every JavaScript implementation today is implemented using one or both of them. The major browsers embedding those JavaScript implementations are implemented in one or both. The operating systems the browsers are running on are implemented in one or both. The servers they're accessing are running operating systems, web servers, database servers, programming language implementations and applications written in C and/or C++. All of this is linked together using various networking devices running code written in C or C++. So every single line of JavaScript code that's executed depends on a stunningly huge amount of C and C++ code also being executed.

Re: Go and Rust – objects without class

#29

Post by klibertp »

PommeDeTerre wrote: post #28
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.

I think that you've missed the fact that we're discussing OO techniques and approaches here, rather than the overall usability of JavaScript. The software I mentioned includes JavaScript written in exchange for money, for clients, facing deadlines, in addition to open source JavaScript projects that may not face such constraints. In such code, we often see prototype-based OO not living up to the hype, and not being s…

I will omit language war you both (parent and grandparent) seem to like waging and I'll go straight to the point.

Which is that OO based on prototypes is strictly more powerful than popular class based ones. Which is proven by the very fact you mention: people are writing class-based OO implementations in JavaScript with easy, one can create such an implementation in under 100 LOC. So if you think that "superiority" is determined by expressive power, then (popular) class based OO sucks balls in this comparison :)

I'm including the 'popular' qualification because thinking about class based object orientation in terms of C++ and Java is rather limited. If take a look at Smalltalk you'll see wonders like #become:. Ruby has implemented substantial subset of what Smalltalk provides and Python, although through really ugly hacks, is still able to replicate prototype-ness of JS.

This hints us to the real problem I think you missed, I mean age old difference between static and dynamic typing. Things like Google's Closure Compiler seem to suggest that static typing is desirable in the large projects. And while JITing can alleviate most of the performance problems, maintenance still remains to be a pain in the ass. This same thing applies to class and prototype based OO - while more expressive for the most part, prototypes are not as maintenance friendly as classes are. All sorts of tools, when working with classes, can provide you autocompletion, for example - it's much, much harder with prototypes, which can change at any moment.

So, to summarize, I think you blame the right thing but for incorrect reason. Prototype based OO is "better" than class based in terms of expressiveness, but "worse" in terms of maintenance (for now at least). As everything, both techniques have a place in programming and it's just stupid to bash one or the other.

Re: Go and Rust – objects without class

#30

Post by Jach »

mixedbit wrote: post #12

I've been recently watching Structure and Interpretation of Computer programs, where it is demonstrated that first class functions and assignment operator with nested scope are enough to implement object oriented system. The simplest example given is a Counter object. Translated from Lisp to Javascript it goes like this: function make_counter() { var val = 0; function get() { return val; } function inc() { val += 1;…

From http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

Post reply on HN