Linked by Thom Holwerda on Mon 11th Feb 2013 22:59 UTC
General Development "I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.
Thread beginning with comment 552413
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[12]: My thoughts on Go
by Alfman on Thu 14th Feb 2013 03:01 UTC in reply to "RE[11]: My thoughts on Go"
Alfman
Member since:
2011-01-28

satsujinka,

He's got a valid point though, there is a difference between explicit intent and inferred intent. Which you prefer is a matter of opinion. It's similar to the difference between loosely typed languages and strongly typed ones. Some of us might prefer loose typing with inferred conversions, others prefer explicitly strong typing. Regardless of your personal preference, can you see why others would have a different preference?

Interestingly just as go has both strong and loose typing, I wonder if it could also have both strong and loose interfacing. This way if it's explicitly specified, the compiler will enforce the interface or error out. And if it isn't specified it could infer a matching interface. Seems like that could be feasible to me.

Edited 2013-02-14 03:02 UTC

Reply Parent Score: 4

RE[13]: My thoughts on Go
by satsujinka on Thu 14th Feb 2013 18:53 in reply to "RE[12]: My thoughts on Go"
satsujinka Member since:
2010-03-11

Um... I haven't given any personal preferences. I'm just defending Go because someone has to in order for a debate to occur.

On the note of optional interface implementation. Is that really very different from just adding a comment? Sure the compiler does stuff (like tell you that you need method X) but you'd run into issues anyways if you tried to use an object that didn't actually support the interface. And I'm pretty sure the error message would still make it clear what the problem is (object Y is not a Z.)

Reply Parent Score: 2

RE[14]: My thoughts on Go
by Alfman on Thu 14th Feb 2013 19:47 in reply to "RE[13]: My thoughts on Go"
Alfman Member since:
2011-01-28

satsujinka,

"Um... I haven't given any personal preferences. I'm just defending Go because someone has to in order for a debate to occur."

So you are playing devil's advocate then? I certainly didn't get that impression, but ok.


"On the note of optional interface implementation. Is that really very different from just adding a comment?"

It's very different. It's like adding a comment to say the variable is a double precision float point versus an explicit declaration of a variable as double floating point which the compiler can enforce. In contract based team programing, it's often beneficial to *explicitly* declare the intention of a class to implement something and have the compiler strictly enforce it. Comments are not meaningful in contract based programming.


"Sure the compiler does stuff (like tell you that you need method X) but you'd run into issues anyways if you tried to use an object that didn't actually support the interface. And I'm pretty sure the error message would still make it clear what the problem is (object Y is not a Z.)"


It's logically better to throw the error at the point where the class is defined rather than where the object of a class gets used. You might think this is nitpicking, but in contract based programming it can be significant because the interface provider and consumers might be different developers from different companies in different timezones. For the consumer to get the interface implementation error when the provider is the one that needs to fix it is not helpful.

Of course you can blame the provider for not testing it (dang it why didn't the comment work?), but keep in mind that languages with explicit interface declarations have built in test cases for this such that the producer will get an error during compilation.

Edit: I wouldn't go as far as to say everyone needs explicit interfaces. In small/home projects, it probably wouldn't come up as often, but for large enterprise projects with hundreds of classes and code paths belonging to rarely used corner cases, it's probably best for developers to be able to explicitly state their intention - especially since they come and go over the course of the project. I think adding optional support for them would be a very good idea to please people of both crowds.

Edited 2013-02-14 20:03 UTC

Reply Parent Score: 2