7 ms·
Did anyone else recoil in horror at how a simple function is turned into a type hierarchy? This is everything that's wrong with Java to me. Classes are all fine
by eloff 13y ago
Did anyone else recoil in horror at how a simple function is turned into a type hierarchy? This is everything that's wrong with Java to me. Classes are all fine and well, but don't take it to extremes. Maybe the examples were just too trivial, but it really is a far greater evil than just using well named variables and a simple conversion function.
- zastrowm 13y agoI think the examples are just too trivial (or in this case, aren't extended to a greater library). Where they really come in handy is if you're using the types all over the place. If I were to create a Degrees class (with Celsius and Fahrenheit) just for representing it in a UI, I'd call it crazy. But if I'm doing conversions all over the place or creating a library for others to use, I would think the plumbing is worth it. Of course, that's true for most "plumbing" in code.
- eps 13y agoIf you are "doing conversions all over the place", you are looking at a fundamentally flawed code design that costs you performance. Ensuring consistency of coversions here is like painting a house whose roof's on fire. C/F example is synthetic, but it doesn't make it any good - if you are operating with data that can be expressed in different units, then pick a single unit, stick with it throught the code and convert only when displaying (or passing to external party code).
- deleted 13y ago[deleted]
- pdpi 13y agoOr perhaps you're integrating a large number of systems, each with its own conventions.
- wvenable 13y agoWhat is missing the rest of the program that could be using temperature hundreds of times scattered throughout the calculations and UI. A small type hierarchy provides type safety for all that other code and is certainly less prone to errors than well named variables and simple conversion functions. The example is bit too trivial as the hierarchy doesn't provide much value. I would assume the base class would actually provide some useful functionality that isn't in this example or it could be eliminated entirely.
- eloff 13y agoYes, if it is a major part of what the program does it could be justified. But often I see this kind of craziness for things used only a couple times.
- cmbaus 13y agoyes.
- hdevalence 13y agoYour problem isn't with expressive type systems, it's with languages whose type systems are not sufficiently expressive, though. Well-named variables are interpreted and checked by the programmer; well-expressed type constraints are interpreted and checked by the compiler. Guess which one makes fewer mistakes?
- eloff 13y agoYes, I'm happy to offload as much as possible to the compiler as long as it doesn't involve hundreds of lines of unnecessary classes and interfaces. That's just wrong.
- tomlu 13y agoIt's nice how in Go you can alias a type to int, yet it is its own distinct type with compile time checks and explicit conversions. Definitely takes away all the boilerplate.
- pjmlp 13y ago> Definitely takes away all the boilerplate. Until you need to write generic code. Then it is casts everywhere and boilerplate to satisfy interfaces.
- dkuntz2 13y agoIf you need generics why are you writing in Go?
- pjmlp 13y agoI am not, left the language ecosystem before the 1.0 release. Might consider it again if a customer requires me to use it, otherwise I am happier with other more modern languages.
- drbawb 13y ago>... and boilerplate to satisfy the interfaces. Go actually provides facilities for embedding types which helps remove some of the unnecessary boilerplate from satisfying an interface.[1] Through embedding you can leverage the implementation of an existing type to satisfy an interface w/o writing methods to dispatch to that underlying type. [1]: http://golang.org/doc/effective_go.html#embedding http://golang.org/doc/effective_go.html#embedding
- pjmlp 13y agoI used Go quite a lot until version 1.0 got released. You are not explaining nothing new to me.
- pycassa 13y agoHaskell has both. You can have type synonyms that are not distinct to the original type according to the compiler and new types that are distinct to the original that doesn't even 'inherit' all the type classes of the original type. You have to specifically instantiate all the type classes you need.
- Nilzor 13y agono. This was an example to illustrate a point. Use your imagination to find real uses of this approach. And what's wrong with type hierarchies anyway?