6 ms·

Go and Rust – objects without class (2013)

105 points by Immortalin 11y ago

tambourine_man 11y ago
Javascript's influence? If so, the circle is now complete, as we are about to get classes in ES6
- cmrdporcupine 11y ago
  Classlessness in OO systems was around a long time before JS was even conceived of. I recommend this book: http://www.amazon.com/s?search-alias=stripbooks&field-isbn=9814021253 http://www.amazon.com/s?search-alias=stripbooks&field-isbn=9... "Prototype-Based Programming: Concepts, Languages and ApplicationsMay 14, 1999 by James Noble and Antero Taivalsaari" The first OO language I learned was the embedded programming language of LambdaMOO ("MOO"), which was used to extend the virtual world. It was prototype based, with a single delegate called the parent subbing in. It still had inheritance, but a different kind.
  - tambourine_man 11y ago
    Classlessness in OO systems was around a long time before JS was even conceived of. Oh I know that. It's just that being the most popular programing language in the world helps setting trends, even when you don't invent them.
    - cmrdporcupine 11y ago
      I find it unfortunate that lack of classes is seen as some chief defect of JS. It's actually one of the things I like about it. Messed up scoping rules, and bizarre type coercions, yes, ugly. But the object system I think is nice.
      - aikah 11y ago
        Well , not anymore since ES2015 has classes,class inheritance,super and co. Prototypical inheritance is bizarre, verbose and dangerous.
        masklinn 11y ago
        ES2015 doesn't have classes, it has a class statement which desugars to prototypal inheritance. And as Self demonstrated long before Javascript even existed, prototypal inheritance is neither bizarre nor verbose let alone dangerous. As with most other things, Javascript just has a completely mangled version of it for (I can only assume) original implementation simplicity.
        cmrdporcupine 11y ago
        Yes I find it very unfortunate that 99% of people's exposure to 'prototype inheritance' is JS's rather inelegant form of it. Though like many things with JS if you are disciplined it can be used elegantly.
        deleted 11y ago
        [deleted]
- gsnedders 11y ago
  And Smalltalk's on JS. ES6 classes are just syntax on prototypes, they don't actually change the underlying object model.
segmondy 11y ago
Lisp's CLOS has defclass for class defintions, but not your typical class that encapsulates data and code. You can do just fine with defstruct and make good use of CLOS. There are very few things that are new under the sun. :-]
- lispm 11y ago
  DEFSTRCUT uses inheritance, too. single.
ryanolsonx 11y ago
It's refreshing to write software with these languages and not having to deal with standard OO.
- aikah 11y ago
  > Both Rust and Go add some new and interesting ideas which, like languages before them, will initially attract programmers, but will ultimately earn both languages their share of derision, just as there are plenty of detractors for C++ and Java today.
  - _sh 11y ago
    "There are only two kinds of languages: the ones people complain about and the ones nobody uses" --Bjarne Stroustrup
    - thomasz 11y ago
      That's a bad cop out. There are widely used languages like c# and python that cause very little whining.
      - dcsommer 11y ago
        Define "very little"...
        choudanu4 11y ago
        Language feature-wise, I think python 3 has very little complained about it. The chief complaints about python I hear are anything to do with packaging software and multi threading the second of which will hopefully be fixed by 3.7. Obviously, the 2 to 3 debacle is a constant source of grief, but I don't think that necessarily fits in with the subject at hand: language features that people contest over.
ryanolsonx 11y ago
It's refreshing to write software with these languages and not having to deal with standard OO.
cmrdporcupine 11y ago
Smalltalk-72 (well, Smalltalk before Smalltalk-76) did not have inheritance. And I believe Alan Kay is on record indicating he felt that inheritance in Smalltalk had often been misapplied or not well understood, and spoke well of Self and other experiments with classless object models. If we're in the "OO" world, and need something analogous to inheritance, I'd rather have an object system with tools for explicit delegation over a system which tries to conflate delegation of behaviour with subtyping. IMHO this is one of the greatest uglinesses of Java (C++ has it too but it's not used much these days.)
- chimeracoder 11y ago
  Yes, Alan Kay was very clear that he does not believe inheritance to be a key part of object-oriented programming. > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them. For context, he said this in 2003, at the height of Java's popularity.
  - cmrdporcupine 11y ago
    Yeah I also seem to remember him saying (maybe on a Squeak mailing list or somewhere else... many moons ago when I followed this kind of thing) that Smalltalk 72 was his personal favourite Smalltalk.
    - e12e 11y ago
      Reminds me of Newspeak: "Why is it called Newspeak? In Orwell's novel 1984, Newspeak was a language that grew smaller over time. Unlike the case of natural languages, for a programming language this is actually a good thing. It is an ideal we strive for - a shrinkable language." http://www.newspeaklanguage.org/ http://www.newspeaklanguage.org/
  - JulianMorrison 11y ago
    Erlang probably also counts.
Animats 11y ago
Structure embedding is not inheritance. It's just structures as first class types. This becomes clear as soon as you create a structure that contains two strings.
steveklabnik 11y ago
Being from 2013, this is speaking about Ancient Rust, but after giving this a quick re-read, it still seems up to date, with maybe minor syntax and idiom issues. We _will_ be adding some sort of thing kind of like inheritance to Rust. https://github.com/rust-lang/rfcs/issues/349 https://github.com/rust-lang/rfcs/issues/349 is the RFC issue, and it outlines: * cheap field access from internal methods; * cheap dynamic dispatch of methods; * cheap downcasting; * thin pointers; * sharing of fields and methods between definitions; * safe, i.e., doesn't require a bunch of transmutes or other unsafe code to be usable; * syntactically lightweight or implicit upcasting; * calling functions through smartpointers, e.g. fn foo(JSRef<T>, ...); * static dispatch of methods. That being said, we don't expect this to ever be the primary method of modeling in Rust. It's just that sometimes, you do have something which is legitimately represented by inheritance or something like it.
- wrl 11y ago
  Is there any schedule for when that'll be worked on? It's a big thing I'm waiting on for porting some UI toolkit work to Rust.
  - doomrobo 11y ago
    Unfortunately, almost nothing "in the pipeline" has any kind of schedule attached to it. The best you might get is a partial ordering on the priority of features.
  - steveklabnik 11y ago
    Everyone is working on HIR/MIR at the moment, because it will enable a lot of different kinds of work to happen in parallel after it lands. The stage it's in is "Niko has a draft RFC that he hasn't published yet." Then there will be discussion, and then implementation.
    - heinrich5991 11y ago
      What's HIR/MIR?
realharo 11y ago
>If this restriction were to be encoded in the type system, GtkMenuShell would not be a true subtype of GtkContainer as it cannot be used in every place that a GtkContainer could be used — specifically it cannot be the target of gtk_container_add(myButton). This is easily solvable by making the Container be a generic class "Container of <T extends Widget>". If the language supports such things of course, so not really talking about GTK specifically here. Then a Container<MenuItem> is not a subtype of Container<Widget> (so you're not violating LSP), yet you can still write code that operates on all kinds of containers without giving up any compile-time type checking. I agree with a lot of the other things in the article, just this was not a particularly good example, because it's more about the shortcomings of a specific language than the shortcomings of subtype polymorphism in general.

105 points by Immortalin 11y ago

tambourine_man 11y ago

Javascript's influence? If so, the circle is now complete, as we are about to get classes in ES6

cmrdporcupine 11y ago
Classlessness in OO systems was around a long time before JS was even conceived of. I recommend this book: http://www.amazon.com/s?search-alias=stripbooks&field-isbn=9814021253 http://www.amazon.com/s?search-alias=stripbooks&field-isbn=9... "Prototype-Based Programming: Concepts, Languages and ApplicationsMay 14, 1999 by James Noble and Antero Taivalsaari" The first OO language I learned was the embedded programming language of LambdaMOO ("MOO"), which was used to extend the virtual world. It was prototype based, with a single delegate called the parent subbing in. It still had inheritance, but a different kind.
- tambourine_man 11y ago
  Classlessness in OO systems was around a long time before JS was even conceived of. Oh I know that. It's just that being the most popular programing language in the world helps setting trends, even when you don't invent them.
  - cmrdporcupine 11y ago
    I find it unfortunate that lack of classes is seen as some chief defect of JS. It's actually one of the things I like about it. Messed up scoping rules, and bizarre type coercions, yes, ugly. But the object system I think is nice.
    - aikah 11y ago
      Well , not anymore since ES2015 has classes,class inheritance,super and co. Prototypical inheritance is bizarre, verbose and dangerous.
      - masklinn 11y ago
        ES2015 doesn't have classes, it has a class statement which desugars to prototypal inheritance. And as Self demonstrated long before Javascript even existed, prototypal inheritance is neither bizarre nor verbose let alone dangerous. As with most other things, Javascript just has a completely mangled version of it for (I can only assume) original implementation simplicity.
        cmrdporcupine 11y ago
        Yes I find it very unfortunate that 99% of people's exposure to 'prototype inheritance' is JS's rather inelegant form of it. Though like many things with JS if you are disciplined it can be used elegantly.
        deleted 11y ago
        [deleted]
gsnedders 11y ago
And Smalltalk's on JS. ES6 classes are just syntax on prototypes, they don't actually change the underlying object model.

segmondy 11y ago

Lisp's CLOS has defclass for class defintions, but not your typical class that encapsulates data and code. You can do just fine with defstruct and make good use of CLOS. There are very few things that are new under the sun. :-]

lispm 11y ago
DEFSTRCUT uses inheritance, too. single.

ryanolsonx 11y ago

It's refreshing to write software with these languages and not having to deal with standard OO.

aikah 11y ago
> Both Rust and Go add some new and interesting ideas which, like languages before them, will initially attract programmers, but will ultimately earn both languages their share of derision, just as there are plenty of detractors for C++ and Java today.
- _sh 11y ago
  "There are only two kinds of languages: the ones people complain about and the ones nobody uses" --Bjarne Stroustrup
  - thomasz 11y ago
    That's a bad cop out. There are widely used languages like c# and python that cause very little whining.
    - dcsommer 11y ago
      Define "very little"...
      - choudanu4 11y ago
        Language feature-wise, I think python 3 has very little complained about it. The chief complaints about python I hear are anything to do with packaging software and multi threading the second of which will hopefully be fixed by 3.7. Obviously, the 2 to 3 debacle is a constant source of grief, but I don't think that necessarily fits in with the subject at hand: language features that people contest over.

ryanolsonx 11y ago

It's refreshing to write software with these languages and not having to deal with standard OO.

cmrdporcupine 11y ago

Smalltalk-72 (well, Smalltalk before Smalltalk-76) did not have inheritance. And I believe Alan Kay is on record indicating he felt that inheritance in Smalltalk had often been misapplied or not well understood, and spoke well of Self and other experiments with classless object models. If we're in the "OO" world, and need something analogous to inheritance, I'd rather have an object system with tools for explicit delegation over a system which tries to conflate delegation of behaviour with subtyping. IMHO this is one of the greatest uglinesses of Java (C++ has it too but it's not used much these days.)

chimeracoder 11y ago
Yes, Alan Kay was very clear that he does not believe inheritance to be a key part of object-oriented programming. > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them. For context, he said this in 2003, at the height of Java's popularity.
- cmrdporcupine 11y ago
  Yeah I also seem to remember him saying (maybe on a Squeak mailing list or somewhere else... many moons ago when I followed this kind of thing) that Smalltalk 72 was his personal favourite Smalltalk.
  - e12e 11y ago
    Reminds me of Newspeak: "Why is it called Newspeak? In Orwell's novel 1984, Newspeak was a language that grew smaller over time. Unlike the case of natural languages, for a programming language this is actually a good thing. It is an ideal we strive for - a shrinkable language." http://www.newspeaklanguage.org/ http://www.newspeaklanguage.org/
- JulianMorrison 11y ago
  Erlang probably also counts.

Animats 11y ago

Structure embedding is not inheritance. It's just structures as first class types. This becomes clear as soon as you create a structure that contains two strings.

steveklabnik 11y ago

Being from 2013, this is speaking about Ancient Rust, but after giving this a quick re-read, it still seems up to date, with maybe minor syntax and idiom issues. We _will_ be adding some sort of thing kind of like inheritance to Rust. https://github.com/rust-lang/rfcs/issues/349 https://github.com/rust-lang/rfcs/issues/349 is the RFC issue, and it outlines: * cheap field access from internal methods; * cheap dynamic dispatch of methods; * cheap downcasting; * thin pointers; * sharing of fields and methods between definitions; * safe, i.e., doesn't require a bunch of transmutes or other unsafe code to be usable; * syntactically lightweight or implicit upcasting; * calling functions through smartpointers, e.g. fn foo(JSRef<T>, ...); * static dispatch of methods. That being said, we don't expect this to ever be the primary method of modeling in Rust. It's just that sometimes, you do have something which is legitimately represented by inheritance or something like it.

wrl 11y ago
Is there any schedule for when that'll be worked on? It's a big thing I'm waiting on for porting some UI toolkit work to Rust.
- doomrobo 11y ago
  Unfortunately, almost nothing "in the pipeline" has any kind of schedule attached to it. The best you might get is a partial ordering on the priority of features.
- steveklabnik 11y ago
  Everyone is working on HIR/MIR at the moment, because it will enable a lot of different kinds of work to happen in parallel after it lands. The stage it's in is "Niko has a draft RFC that he hasn't published yet." Then there will be discussion, and then implementation.
  - heinrich5991 11y ago
    What's HIR/MIR?

realharo 11y ago

>If this restriction were to be encoded in the type system, GtkMenuShell would not be a true subtype of GtkContainer as it cannot be used in every place that a GtkContainer could be used — specifically it cannot be the target of gtk_container_add(myButton). This is easily solvable by making the Container be a generic class "Container of <T extends Widget>". If the language supports such things of course, so not really talking about GTK specifically here. Then a Container<MenuItem> is not a subtype of Container<Widget> (so you're not violating LSP), yet you can still write code that operates on all kinds of containers without giving up any compile-time type checking. I agree with a lot of the other things in the article, just this was not a particularly good example, because it's more about the shortcomings of a specific language than the shortcomings of subtype polymorphism in general.