4 ms·

User-facing applications or web services often deal with business logic. That is, logic that models real-life processes and entities, such as "Customer" or "Pur

by bsaul 9y ago

User-facing applications or web services often deal with business logic. That is, logic that models real-life processes and entities, such as "Customer" or "Purchase". In order to model those kind of processes you often need powerful modelling abilities (such as subclassing, or generic programming), which go really lacks. I don't have a proof of that just my personal experience, but i'd say Object Oriented Programming is the de-facto standard in "enterprise" software for that reason. The reason go fits the "technical layer" best, is that technical layer deals with things closer to the machine, so the number of different types you need to manipulate is much lower, and is for the most part of the language (it doesn't go further than numbers and strings). All of this is just my personal opinion of course. EDIT: i know composition (which go provides) and subclassing provide the same possibilities in term of modeling, in theory. However in practice, not beeing able to say things like "An Electric Car, is a kind of Car, which is a kind of Vehicle" may make things cumbersome. So is not being able to simply create a function such as "sortByMileage" that applies to all kinds of Vehicle (and just that), but remain type safe. To sum-up : relying on interfaces and composition only is IMHO not as powerful as having interface, composition, inheritance and generics (which most "enterprise" language have).

noselasd 9y ago
Note that you can certainly express "An Electric Car, is a kind of Car, which is a kind of Vehicle" in Go by using interfaces - albeit such kinds of relations are rarely needed in business logic in my experience.
- bsaul 9y ago
  You can indeed, but it makes you duplicate every implementation with its associated interface. As for this kind of relationship, i'd say it's fairly widespread. One proof is that even relationnal DB such as postgresql added table inheritance.
  - lucian1900 9y ago
    Table inheritance is merely an optimisation and rarely used.
    - bsaul 9y ago
      It's an optimisation against the OOP vs relational mismatch, but the fact that it's here proves that OOP subclassing is being used quite often (otherwise there wouldn't be any need to optimise for it, at least not by adding core features to pg).
  - jerf 9y ago
    "You can indeed, but it makes you duplicate every implementation with its associated interface." Only if A: composition can't do the job somehow and B: you can't use perfectly normal factoring tools to do the work. While I will tell you before anybody else complains that there is a non-zero percentage of the time that will happen, I will also tell you the average person who has never tried Go yet complains about its lack of generics anyhow will overestimate the amount of time that happens by a good order of magnitude or two.
    - bsaul 9y ago
      One remark (that may seem like a nitpick, but is in fact crucial) : composition doesn't say it "is a kind of", but rather "it has". It's the two most fundamental concept of any language : to be vs to have. Now it may or may not be just a philosophical difference and bring no practical consequences to a computer program, but at the minimum one can say it expresses two different concepts.
  - pjmlp 9y ago
    All major RDMS offer OOP at table level.
divan 9y ago
Yes, Go is unsuitable for writing this: https://twitter.com/philwinkle/status/688441014160355328/photo/1 https://twitter.com/philwinkle/status/688441014160355328/pho... But it perfectly allows you to model complex real-life processes, and in a way much better than traditional class-based OOP approach.
oelmekki 9y ago
Actually, not having inheritance is what I love the most about go. When I write ruby code, I keep wondering "where does this method come from?" and have to grep my codebase. "Composition over inheritance" is not a new trend, that was actually mentioned in first chapter of Gang of four's Design Patterns in 1995 [1]. In that regard, I feel like we mostly failed to ever use OOP properly (although, "fail" is probably too strong a word). I'm actually annoyed that embedded types exist in go because it re-introduces the same problem (but I have an easy fix for that: I don't use them). But really, what you're describing is a data structure problem. This can be solved without OOP, and structs are especially good at it. [1] https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2C_Chapter_1 https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2...
- jbarciauskas 9y ago
  Pattern matching interfaces also makes finding exactly what underlying object is being used in a given context difficult as well. With explicitly declared interfaces, you can easily find all implementations. With pattern matching it's a bit more complicated.
  - oelmekki 9y ago
    Yeah indeed, there's that too, although I'm glad we can't define methods on interfaces (using the interface as method receiver), so it quite reduces the complexity to just having to figure out the actual type, most often found just by inspecting the caller.
- criddell 9y ago
  > When I write ruby code, I keep wondering "where does this method come from?" and have to grep my codebase. Sounds like a shortcoming of your tools. I spend a lot of time in Visual Studio working on native C++ and even there I can ctrl-click on something and jump to the declaration or definition. I bet there's something even better for Ruby.
  - jrimbault 9y ago
red75prime 9y ago
> An Electric Car, is a kind of Car, which is a kind of Vehicle And then you have a hybrid car with a drilling attachment.

by bsaul 9y ago

noselasd 9y ago

Note that you can certainly express "An Electric Car, is a kind of Car, which is a kind of Vehicle" in Go by using interfaces - albeit such kinds of relations are rarely needed in business logic in my experience.

bsaul 9y ago
You can indeed, but it makes you duplicate every implementation with its associated interface. As for this kind of relationship, i'd say it's fairly widespread. One proof is that even relationnal DB such as postgresql added table inheritance.
- lucian1900 9y ago
  Table inheritance is merely an optimisation and rarely used.
  - bsaul 9y ago
    It's an optimisation against the OOP vs relational mismatch, but the fact that it's here proves that OOP subclassing is being used quite often (otherwise there wouldn't be any need to optimise for it, at least not by adding core features to pg).
- jerf 9y ago
  "You can indeed, but it makes you duplicate every implementation with its associated interface." Only if A: composition can't do the job somehow and B: you can't use perfectly normal factoring tools to do the work. While I will tell you before anybody else complains that there is a non-zero percentage of the time that will happen, I will also tell you the average person who has never tried Go yet complains about its lack of generics anyhow will overestimate the amount of time that happens by a good order of magnitude or two.
  - bsaul 9y ago
    One remark (that may seem like a nitpick, but is in fact crucial) : composition doesn't say it "is a kind of", but rather "it has". It's the two most fundamental concept of any language : to be vs to have. Now it may or may not be just a philosophical difference and bring no practical consequences to a computer program, but at the minimum one can say it expresses two different concepts.
- pjmlp 9y ago
  All major RDMS offer OOP at table level.

divan 9y ago

Yes, Go is unsuitable for writing this: https://twitter.com/philwinkle/status/688441014160355328/photo/1 https://twitter.com/philwinkle/status/688441014160355328/pho... But it perfectly allows you to model complex real-life processes, and in a way much better than traditional class-based OOP approach.

oelmekki 9y ago

Actually, not having inheritance is what I love the most about go. When I write ruby code, I keep wondering "where does this method come from?" and have to grep my codebase. "Composition over inheritance" is not a new trend, that was actually mentioned in first chapter of Gang of four's Design Patterns in 1995 [1]. In that regard, I feel like we mostly failed to ever use OOP properly (although, "fail" is probably too strong a word). I'm actually annoyed that embedded types exist in go because it re-introduces the same problem (but I have an easy fix for that: I don't use them). But really, what you're describing is a data structure problem. This can be solved without OOP, and structs are especially good at it. [1] https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2C_Chapter_1 https://en.wikipedia.org/wiki/Design_Patterns#Introduction.2...

jbarciauskas 9y ago
Pattern matching interfaces also makes finding exactly what underlying object is being used in a given context difficult as well. With explicitly declared interfaces, you can easily find all implementations. With pattern matching it's a bit more complicated.
- oelmekki 9y ago
  Yeah indeed, there's that too, although I'm glad we can't define methods on interfaces (using the interface as method receiver), so it quite reduces the complexity to just having to figure out the actual type, most often found just by inspecting the caller.
criddell 9y ago
> When I write ruby code, I keep wondering "where does this method come from?" and have to grep my codebase. Sounds like a shortcoming of your tools. I spend a lot of time in Visual Studio working on native C++ and even there I can ctrl-click on something and jump to the declaration or definition. I bet there's something even better for Ruby.
- jrimbault 9y ago

red75prime 9y ago

> An Electric Car, is a kind of Car, which is a kind of Vehicle And then you have a hybrid car with a drilling attachment.