3 ms·

I'm sorry, but this whole comment section is in some collective psychosis from 2010. You don't need to mangle variable names or create custom types (and then th

by geokon 5y ago

I'm sorry, but this whole comment section is in some collective psychosis from 2010. You don't need to mangle variable names or create custom types (and then the insane machinery to have them all interact properly) Have none of you ever refactored code..? Or all of your writing C? Your library should just expose an interface/protocol signature. Program to interfaces. Anything that is passed in should just implement the protocol. The sleep function should not be aware or care about the input type AT ALL. All it requires is the input to implement an "as-milliseconds()" function that returns a millisecond value. You can then change any internal representation as your requirements change

qayxc 5y ago
> Have none of you ever refactored code..? Or all of your writing C? You seem to ignore the much broader context here: the article wasn't just about code. It included configuration files and HTTP requests. It's also worth noting that depending on the language in question and the usage pattern of the function/method, using interfaces or protocols can cause considerable overhead when simply using a proper descriptive name is free.
ReleaseCandidat 5y ago
> [...] create custom types (and then the insane machinery to have them all interact properly) That's an argument against languages with type-systems that make this a PITA, not against the idea itself.
pif 5y ago
> You don't need to ... create custom types > > All it requires is the input to implement an "as-milliseconds()" function A.k.a. custom type!
flohofwoe 5y ago
That's also a custom type. But for libraries, custom types for everything in interface definitions are problematic. Let's say you use library A which has some functions that take a time delta, and another library B, that also has functions which take time deltas. Now both library would define their own time delta type, and you have two types for time deltas in your application and most likely need to add an additional 'meta time delta type' which can be converted to the library specific time deltas types. This will explode very quickly into lots of boilerplate code and is a good reason to use 'primitive types' in interfaces. If you replace 'time delta' with 'strings' then the problem becomes more apparent. Each library defining its own string type would be a mess.
- geokon 5y ago
  If you are working with a crappy language then that's probably true. But it doesn't have to be a lot of boilerplate and it can be local in scope. In Clojure it's a one-liner. (extend-protocol libA/stringable myLib/InputThing as-string [x] (myLib/to-string x) ) (libA/some-func (myLib/make-a-thing)) And sure it can just be doing something as simple as returning an internal value directly or calling some common stringifying method. You do have a good point that you may have redundant stringifying protocols across libraries - which sucks. > This will explode very quickly into lots of boilerplate code and is a good reason to use 'primitive types' in interfaces. I feel you were so close and missed :) The natural conclusion would be to have primitive interfaces - not primitive types. This way libraries only need to agree to adhere to an interface (and not an implementation)
- deleted 5y ago
  [deleted]
gpderetta 5y ago
premature abstraction is the root of all evil.
thrwyoilarticle 5y ago
'Why do at build time what you could do with bugs at runtime'?

by geokon 5y ago

qayxc 5y ago

> Have none of you ever refactored code..? Or all of your writing C? You seem to ignore the much broader context here: the article wasn't just about code. It included configuration files and HTTP requests. It's also worth noting that depending on the language in question and the usage pattern of the function/method, using interfaces or protocols can cause considerable overhead when simply using a proper descriptive name is free.

ReleaseCandidat 5y ago

> [...] create custom types (and then the insane machinery to have them all interact properly) That's an argument against languages with type-systems that make this a PITA, not against the idea itself.

pif 5y ago

> You don't need to ... create custom types > > All it requires is the input to implement an "as-milliseconds()" function A.k.a. custom type!

flohofwoe 5y ago

That's also a custom type. But for libraries, custom types for everything in interface definitions are problematic. Let's say you use library A which has some functions that take a time delta, and another library B, that also has functions which take time deltas. Now both library would define their own time delta type, and you have two types for time deltas in your application and most likely need to add an additional 'meta time delta type' which can be converted to the library specific time deltas types. This will explode very quickly into lots of boilerplate code and is a good reason to use 'primitive types' in interfaces. If you replace 'time delta' with 'strings' then the problem becomes more apparent. Each library defining its own string type would be a mess.

geokon 5y ago
If you are working with a crappy language then that's probably true. But it doesn't have to be a lot of boilerplate and it can be local in scope. In Clojure it's a one-liner. (extend-protocol libA/stringable myLib/InputThing as-string [x] (myLib/to-string x) ) (libA/some-func (myLib/make-a-thing)) And sure it can just be doing something as simple as returning an internal value directly or calling some common stringifying method. You do have a good point that you may have redundant stringifying protocols across libraries - which sucks. > This will explode very quickly into lots of boilerplate code and is a good reason to use 'primitive types' in interfaces. I feel you were so close and missed :) The natural conclusion would be to have primitive interfaces - not primitive types. This way libraries only need to agree to adhere to an interface (and not an implementation)
deleted 5y ago
[deleted]

gpderetta 5y ago

premature abstraction is the root of all evil.

thrwyoilarticle 5y ago

'Why do at build time what you could do with bugs at runtime'?