7 ms·

It is very interesting to see in such projects how they expose the weakness of certain Java idioms. The mentioned JavaBeans getters and setters are obsolete pat

It is very interesting to see in such projects how they expose the weakness of certain Java idioms. The mentioned JavaBeans getters and setters are obsolete pattern, for which in most cases there’s no good reason to keep it in the code. Java ecosystem is probably the richest one on the design patterns, some of which receive „anti“ prefix over the years (e.g. self-contained singleton). At the same time new languages explore and verify the ideas and coding styles that might be worth to borrow and make mainstream. Porting exercise can be such source of new best practices pushing us to rethink what is worth keeping and what is pointless overengineering.

deleted 8y ago
[deleted]
jaabe 8y ago
I was struck by the lack of inheritance in go, that to me is brilliant. I’ve worked with C# for a decade, and I’ve yet to see a use of inheritance that wouldn’t have been easier to maintain in the long run without using inheritance. We’ve limited our own useage to override methods in the standard library, but even then it’s often used to implement things that are really just terrible practices. Like adding search functions for AD extension fields or increasing the timeout in one of the older web clients.
- codenesium 8y ago
  I'm also a c# dev but with less experience. Could you elaborate? Does the mean you copy paste shared code to all of the derived classes? I think I know why you say it's a maintenance nightmare because you start off with a method or properties that make sense in all of the derived classes but overtime the classes become less cohearant and start to develope warts and it would have been easier to modify the duplicated code.
  - scanr 8y ago
    It’s more that there are other ways to reuse code. Search for “composition over inheritance” in your favourite search engine for more information.
  - jaabe 8y ago
    I think you formulate it nicely. Sometimes the things it made sense to share stop making sense. Something that means rework, sometimes you end up with a parent method which is overridden in every child, possibly because each override was spread out over a long time period and no one bothered to look outside the child. Inheritance makes sense with interfaces in C# but for the rest I think composition is just a better way of sharing.
  - apta 8y ago
    Watch out for hype that golang authors and supporters claim without properly backing it up, there's quite a bit of it. There are other languages that have better support for composition, while still maintaining support for inheritance (e.g. Kotlin). Inheritance has its uses, as evident by the fact that Rust is considering adding support for inheritance (e.g. writing GUIs).
    - steveklabnik 8y ago
      I’m not sure what you mean by “rust is considering adding support for inheritance”; as far as I know that’s not true. Did I forget something? Do you have a link to the proposal?
      - apta 8y ago
        I came across it a while ago, I think it was mentioned by pcwalton or someone if I'm not mistaken, specifically citing writing GUI code as a rationale. That being said, Rust (and Java, Kotlin, Scala, C#, etc) have default interface method implementations which might alleviate some of the need for full blown inheritance, unlike golang's interfaces.
- dralley 8y ago
  Sounds like you would find the Trait system in Rust very interesting. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f0392c8bacf1b8919d70daddb6f6557e https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - skybrian 8y ago
    Traits are okay in principle but, as a Rust beginner, the huge number of trait implementations make browsing the api docs overwhelming. For example, the list of implementations for String don't even fit on the screen at once. [1] It seems very repetitive and I wish there were an easier way to get an overview of what functionality is available and find the right method to call. [1] https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html
    - Inityx 8y ago
      It's not a great solution, but I've found it beneficial to lean heavily on the Rust docs search bar when looking for specific behavior. It's very fast, and fuzzy enough that it finds what I'm looking for most of the time.
- tybit 8y ago
  Embedding does seem like one of the decisions Go got very right. Many languages (thinking c#, Java, c++) say they promote composition over inheritance but yet make inheritance so mmuch easier to use.
  - nathanaldensr 8y ago
    Indeed! This has always mystified me. Why is it so easy to implement what is now considered to be an anti-pattern (inheritance) when it's so boilerplate and annoying to implement composition? Why does C# not have language support for delegating members? Why do I have to buy and use ReSharper just to generate all that boilerplate? It's a constant battle talking to "just get it done" developers about why inheritance is bad.
    - danmaz74 8y ago
      Inheritance is an anti-pattern for some. Not for others (eg me).
      - collyw 8y ago
        As with everything it depends how its used.
    - pjmlp 8y ago
      Inheritance is only considered an anti-pattern by some. Since the 90's, any good CS book about OOP paradigms had discussions about is-a and has-a and how to make the best use of each, depending on the desired application architecture. The thing is, such books usually aren't taught on bootcamps.
      - jaabe 8y ago
        Inheritance isn’t an anti-pattern in academia. I do part time work as an examiners for CS students, and I see their car/animal examples everywhere in introductionary courses. When we have interns, they’ll sometimes build things with inheritance. So it’s certainly still a thing. I’ve yet to see a real world use of it, where you wouldn’t have been better of not using it though. My real world is the relatively boring world of enterprise public sector software, however, and maybe I’m simply oblivious to where inheritance might be worthwhile.
- deleted 8y ago
  [deleted]
jillesvangurp 8y ago
Yes indeed. Porting code is also a great way to learn a language. And you learn a lot about idioms and patterns on both sides. Go innovated quite a bit in terms of simplicity. However, they also did a few things that they are now trying to fix like having generics and exceptions. Lack of overloading is something that I miss in other languages as well. E.g. in Javascript you often end up with these type checks to sort of fake things. These often get added defensively because the lack of typing just causes people to call things with the wrong types and it is common for that kind of code to not be noticed (fixed a few such issues when introducing typescript recently). A lot of stuff in Java is just because (by now) it has a lot of history and baggage. JavaBeans were kind of cool back in the late nineties but mostly it's a really annoying convention by now. The notion of accessors is not obsolete but unfortunately was not part of the language design when they created Java. Since Java has reflection, they came up with naming conventions that allow code to inspect object instances and do things with properties based on naming conventions. This has been key to a lot of the Java enterprise stuff that happened after this. And it also facilitated creating UI builders that came with IDEs like jbuilder, netbeans, visual cafe, etc. when having a UI builder was still a base requirement for an IDE. Eclipse sort of broke that tradition by not including one (initially). These days UI builders are basically very uncommon; which makes javascript frontend work particularly tedious and repetitive. Because there are no conventions, no typing, and quite often no meaningful test coverage in JS, it is basically impossible to deal with that in a UI tool. So, accessors matter and are not obsolete at all. Most modern languages have more elegant ways to do essentially the same type of accessor mechanisms in the language. And also languages like Smalltalk had this (as well as UI building tools, refactoring, and a lot of other stuff that is still science fiction in the javascript world). If you look at Kotlin, they fixed this while retaining the ability to expose code back to Java. For example kotlin has properties with accessors that you can optionally override. Normally you just type val foo="bar" and you have a string property with an inferred type of String. The setters/getters generated under the hood and used automatically when you assign or use the variable. If you want you can customise the accessors or use something called delegated properties that e.g. turn a property getter into a function or use lazy intialization. Once compiled, a java class that uses that code would see the normal setters and getters as if it was a normal Java class. Likewise when accessing Java code from Kotlin you use java properties as if they were normal kotlin properties (i.e. without using setFoo(foo)/getFoo()). This makes Kotlin a really nice way of using legacy Java code.
mbfg 8y ago
if the verbosity of javabeans bothers you, you can just use the lombok compiler extension to get similar concepts to what Go provides.
- snowe2010 8y ago
  ugh, don't use lombok. it's terrible in so many ways. Either switch to kotlin or use the AutoValue or Immutables libraries.
  - mbfg 8y ago
    can you iterate the terribleness?
    - theshrike79 8y ago
      Lombok brings huge amounts of unnecessary magic to the codebase. A new coder diving in to the code will need to either know all the Lombok annotations by heart or look up what every single one of them does. Also it makes debugging kinda crappy for the same reason.
      - mbfg 8y ago
        huge? pretty trivial.. the point of a javabean is you don't need to understand anything. As for annotations, it's not like developers don't need to know a crapton of other annotations as well. It's just the way it is, so a few more aren't a big deal. If you need to debug java beans, you are doing something wrong. you can also delombok if you ever get tired of it, and now your back to manual. I personally don't use lombok, as i'm not offended by the verbosity, given that ides since forever have done all the work, but if it's something you are bothered by, well. that. If an argument is that javabeans are the wrong pattern to use, that's a different argument, and unrelated to lombok.
- ivan_gammel 8y ago
  Lombok is a syntactic sugar for bad design decisions: there should not exist operation like setName - either there’s additional semantics deserving a method with a descriptive name, or the class is just a structure with writable state. I also agree with the comment about unnecessary magic.

deleted 8y ago

[deleted]

jaabe 8y ago

I was struck by the lack of inheritance in go, that to me is brilliant. I’ve worked with C# for a decade, and I’ve yet to see a use of inheritance that wouldn’t have been easier to maintain in the long run without using inheritance. We’ve limited our own useage to override methods in the standard library, but even then it’s often used to implement things that are really just terrible practices. Like adding search functions for AD extension fields or increasing the timeout in one of the older web clients.

codenesium 8y ago
I'm also a c# dev but with less experience. Could you elaborate? Does the mean you copy paste shared code to all of the derived classes? I think I know why you say it's a maintenance nightmare because you start off with a method or properties that make sense in all of the derived classes but overtime the classes become less cohearant and start to develope warts and it would have been easier to modify the duplicated code.
- scanr 8y ago
  It’s more that there are other ways to reuse code. Search for “composition over inheritance” in your favourite search engine for more information.
- jaabe 8y ago
  I think you formulate it nicely. Sometimes the things it made sense to share stop making sense. Something that means rework, sometimes you end up with a parent method which is overridden in every child, possibly because each override was spread out over a long time period and no one bothered to look outside the child. Inheritance makes sense with interfaces in C# but for the rest I think composition is just a better way of sharing.
- apta 8y ago
  Watch out for hype that golang authors and supporters claim without properly backing it up, there's quite a bit of it. There are other languages that have better support for composition, while still maintaining support for inheritance (e.g. Kotlin). Inheritance has its uses, as evident by the fact that Rust is considering adding support for inheritance (e.g. writing GUIs).
  - steveklabnik 8y ago
    I’m not sure what you mean by “rust is considering adding support for inheritance”; as far as I know that’s not true. Did I forget something? Do you have a link to the proposal?
    - apta 8y ago
      I came across it a while ago, I think it was mentioned by pcwalton or someone if I'm not mistaken, specifically citing writing GUI code as a rationale. That being said, Rust (and Java, Kotlin, Scala, C#, etc) have default interface method implementations which might alleviate some of the need for full blown inheritance, unlike golang's interfaces.
dralley 8y ago
Sounds like you would find the Trait system in Rust very interesting. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f0392c8bacf1b8919d70daddb6f6557e https://play.rust-lang.org/?version=stable&mode=debug&editio...
- skybrian 8y ago
  Traits are okay in principle but, as a Rust beginner, the huge number of trait implementations make browsing the api docs overwhelming. For example, the list of implementations for String don't even fit on the screen at once. [1] It seems very repetitive and I wish there were an easier way to get an overview of what functionality is available and find the right method to call. [1] https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html
  - Inityx 8y ago
    It's not a great solution, but I've found it beneficial to lean heavily on the Rust docs search bar when looking for specific behavior. It's very fast, and fuzzy enough that it finds what I'm looking for most of the time.
tybit 8y ago
Embedding does seem like one of the decisions Go got very right. Many languages (thinking c#, Java, c++) say they promote composition over inheritance but yet make inheritance so mmuch easier to use.
- nathanaldensr 8y ago
  Indeed! This has always mystified me. Why is it so easy to implement what is now considered to be an anti-pattern (inheritance) when it's so boilerplate and annoying to implement composition? Why does C# not have language support for delegating members? Why do I have to buy and use ReSharper just to generate all that boilerplate? It's a constant battle talking to "just get it done" developers about why inheritance is bad.
  - danmaz74 8y ago
    Inheritance is an anti-pattern for some. Not for others (eg me).
    - collyw 8y ago
      As with everything it depends how its used.
  - pjmlp 8y ago
    Inheritance is only considered an anti-pattern by some. Since the 90's, any good CS book about OOP paradigms had discussions about is-a and has-a and how to make the best use of each, depending on the desired application architecture. The thing is, such books usually aren't taught on bootcamps.
    - jaabe 8y ago
      Inheritance isn’t an anti-pattern in academia. I do part time work as an examiners for CS students, and I see their car/animal examples everywhere in introductionary courses. When we have interns, they’ll sometimes build things with inheritance. So it’s certainly still a thing. I’ve yet to see a real world use of it, where you wouldn’t have been better of not using it though. My real world is the relatively boring world of enterprise public sector software, however, and maybe I’m simply oblivious to where inheritance might be worthwhile.
deleted 8y ago
[deleted]

jillesvangurp 8y ago

Yes indeed. Porting code is also a great way to learn a language. And you learn a lot about idioms and patterns on both sides. Go innovated quite a bit in terms of simplicity. However, they also did a few things that they are now trying to fix like having generics and exceptions. Lack of overloading is something that I miss in other languages as well. E.g. in Javascript you often end up with these type checks to sort of fake things. These often get added defensively because the lack of typing just causes people to call things with the wrong types and it is common for that kind of code to not be noticed (fixed a few such issues when introducing typescript recently). A lot of stuff in Java is just because (by now) it has a lot of history and baggage. JavaBeans were kind of cool back in the late nineties but mostly it's a really annoying convention by now. The notion of accessors is not obsolete but unfortunately was not part of the language design when they created Java. Since Java has reflection, they came up with naming conventions that allow code to inspect object instances and do things with properties based on naming conventions. This has been key to a lot of the Java enterprise stuff that happened after this. And it also facilitated creating UI builders that came with IDEs like jbuilder, netbeans, visual cafe, etc. when having a UI builder was still a base requirement for an IDE. Eclipse sort of broke that tradition by not including one (initially). These days UI builders are basically very uncommon; which makes javascript frontend work particularly tedious and repetitive. Because there are no conventions, no typing, and quite often no meaningful test coverage in JS, it is basically impossible to deal with that in a UI tool. So, accessors matter and are not obsolete at all. Most modern languages have more elegant ways to do essentially the same type of accessor mechanisms in the language. And also languages like Smalltalk had this (as well as UI building tools, refactoring, and a lot of other stuff that is still science fiction in the javascript world). If you look at Kotlin, they fixed this while retaining the ability to expose code back to Java. For example kotlin has properties with accessors that you can optionally override. Normally you just type val foo="bar" and you have a string property with an inferred type of String. The setters/getters generated under the hood and used automatically when you assign or use the variable. If you want you can customise the accessors or use something called delegated properties that e.g. turn a property getter into a function or use lazy intialization. Once compiled, a java class that uses that code would see the normal setters and getters as if it was a normal Java class. Likewise when accessing Java code from Kotlin you use java properties as if they were normal kotlin properties (i.e. without using setFoo(foo)/getFoo()). This makes Kotlin a really nice way of using legacy Java code.

mbfg 8y ago

if the verbosity of javabeans bothers you, you can just use the lombok compiler extension to get similar concepts to what Go provides.

snowe2010 8y ago
ugh, don't use lombok. it's terrible in so many ways. Either switch to kotlin or use the AutoValue or Immutables libraries.
- mbfg 8y ago
  can you iterate the terribleness?
  - theshrike79 8y ago
    Lombok brings huge amounts of unnecessary magic to the codebase. A new coder diving in to the code will need to either know all the Lombok annotations by heart or look up what every single one of them does. Also it makes debugging kinda crappy for the same reason.
    - mbfg 8y ago
      huge? pretty trivial.. the point of a javabean is you don't need to understand anything. As for annotations, it's not like developers don't need to know a crapton of other annotations as well. It's just the way it is, so a few more aren't a big deal. If you need to debug java beans, you are doing something wrong. you can also delombok if you ever get tired of it, and now your back to manual. I personally don't use lombok, as i'm not offended by the verbosity, given that ides since forever have done all the work, but if it's something you are bothered by, well. that. If an argument is that javabeans are the wrong pattern to use, that's a different argument, and unrelated to lombok.
ivan_gammel 8y ago
Lombok is a syntactic sugar for bad design decisions: there should not exist operation like setName - either there’s additional semantics deserving a method with a descriptive name, or the class is just a structure with writable state. I also agree with the comment about unnecessary magic.