Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make the Type System Do the Work

nathan.ca

Post reply on HN
Print view View original

91–100 of 141 posts

Re: Make the Type System Do the Work

#91

Post by TorKlingberg »

chrisaycock wrote: post #23

This article uses inheritance in C++ to ensure the types line-up, but I have really taken a shine to algebraic data types for my firm's data feed handlers. Here is an example in C++11 that implements a market-data spec line-for-line. #pragma pack(push,1) struct Quote { char symbol[16]; uint16_t bid; uint32_t bidsize; uint16_t ask uint32_t asksize; }; static_assert(sizeof(Quote) == 28, "Quote size wrong"); struct Trad…

Just make sure your systems native endianness is the same as in the raw buffer.

Re: Make the Type System Do the Work

#93

Post by pdpi »

jeffdavis wrote: post #51

"'Dog is-a Mammal' ... actually fairly sound" I disagree in the context of OOP inheritance. (This example uses shapes, because the idea of mutating mammals gets a little strange.) Let's say you have a Circle class and an Ellipse class. A Circle inherits from an Ellipse, of course, because a Circle is-a Ellipse. By specializing as a Circle, we get extra reader methods such as getRadius(). Great. But what about mutator…

The short version here is "Inheritance must respect the Liskov Substitution Principle, and many seemingly obvious inheritance relationships don't".

Re: Make the Type System Do the Work

#94

Post by pointernil »

I often wonder how the "tool" named MONADS could help to deal with this quite old problem of what I call

meta-types or semantic types

(i'm sure there is a proper name for this; I'm not a cs/type-theory professional ;)

Time handling f.e. and often physical Units would quite often benefit from much stronger guaranties at compile and runtime. And no, OOP and it's tools are not sufficient to handle this... in theory maybe, not in day to day development.

We need to translate the core ideas of a monad into more a "mainstream" syntax and runtime env. to prevent the next incident of:

I'll just add the integer 365 to my certificate valid-date within our core cloud infrastructure code...

I'm not necessarily a MS fan, but would love to see how Anders Hejlsberg f.e. would tackle this kind of language-design challenge ;)

Re: Make the Type System Do the Work

#95

Post by pycassa »

tomlu wrote: post #49
eloff wrote: post #26

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.

It'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.

Haskell 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.

Re: Make the Type System Do the Work

#96

Post by SuddsMcDuff »

The best write up I ever heard for this approach (often called "primitive obsession" - http://sourcemaking.com/refactoring/primitive-obsession) was in Object Calisthenics, an essay by Jeff Bay in The Thoughtworks Anthology (http://www.amazon.co.uk/The-ThoughtWorks-Anthology-Technolog...):

"an int on its own is just a scalar, so it has no meaning. When a method takes an int as a parameter, the method name needs to do all of the work of expressing the intent. If the same method takes an Hour as a parameter, it’s much easier to see what’s going on. Small objects like this can make programs more maintainable, since it isn’t possible to pass a Year to a method that takes an Hour parameter. With a primitive variable the compiler can’t help you write semantically correct programs. With an object, even a small one, you are giving both the compiler and the programmer additional info about what the value is and why it is being used.

Small objects like Hour or Money also give us an obvious place to put behavior that would otherwise have been littered around other classes."

Re: Make the Type System Do the Work

#98

Post by ygra »

NigelTufnel wrote: post #92

Maybe it's just something I don't understand but I would go with Celsius everywhere with converting to Fahrenheit/Kelvin when showing/grabbing temperature to/from user.

The Celsius/Fahrenheit example isn't the best. Generally all examples based on units of measurement are probably flawed because sane systems can just standardise on SI and be done with it.

However, different coordinate systems that should never be mixed are useful to keep separate. At work we deal with maps and geographic information, so there are always at least three coordinate systems: Screen, projection and geographic coordinates. Having a type system that catches mistakes there would be so much nicer than just always passing P2D around and trying to never mix different ones.

Re: Make the Type System Do the Work

#99

Post by alipang »

dschiptsov wrote: post #97

Looks rather like a type-system abuse. btw, there is Haskell for that.)

He claims it's to make wrong code look wrong. He uses the type system in order to prevent bugs, how is that abuse? Is the type system only there for performance in your opinion, or what's your angle?

Re: Make the Type System Do the Work

#100

Post by eloff »

wvenable wrote: post #38
eloff wrote: post #26

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.

What 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 actuall…

Yes, 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.
Post reply on HN