The abject failure of weak typing

Re:The abject failure of weak typing by kenbot on Wednesday May 28, 2014 @06:06AM (#7809154)

Hi Manicdee! The point is that with any unityped representation you can come up with, the name tells you nothing certain; any conclusions you think you can draw from it are pixie-dust and moonshine. Even with nonsense names, the argument and return types give you solid proof not only about what the method does, but importantly what it _doesn't_ do.

There's no criticism implied of my colleagues at all -- I'm as culpable as anyone. The point is though, we can make big improvements with types, without paying a big cost.

You must have had good OOD teachers: http://c2.com/cgi/wiki?CaseStatementsConsideredHarmful http://c2.com/cgi/wiki?SwitchStatementsSmell

Cheers

[ Parent | on HN ]

Re:The abject failure of weak typing by manicdee on Wednesday May 28, 2014 @06:04PM (#7813267)

My apologies, I didn't intend to suggest that laziness and sloppiness were attributes of the programmers, but evils imposed by time pressure.

Do I fight management to get the two weeks I'll need to write feature X correctly, or just take the obvious shortcuts to get it done in 1 week?

Of course my laziness shows through because I haven't been in management's ear for long enough beforehand that they decided to give me one week without consulting with me ;)

I display this "lack of bottom-up management" failure mode consistently, I'm more interested in writing code :\

As for my OOD teachers, I've had mountains of bad Perl and PHP code to wade through, and the benefit of Stack Overflow and the Django Project to guide my thinking on the matter.

Type systems do provide some compiler-level assistance in the march towards coherent, well designed software, but they won't solve problems like

  def position_sprite( top_left: point, sprite: sprite)

When you provide the top_left of the wrong element (e.g.: confusing the top left of the drawing space with the top left of the window or display area.

[ Parent | on HN ]

Re:The abject failure of weak typing by loup-vaillant on Thursday May 29, 2014 @04:39AM (#7815321)

I believe phantom type should help with your example. At it's most naive, you need a type for the points in window space, and a second type for the points in drawing space. If you give the sprite a window_point, it will complain about only accepting drawing_points. Now such errors are confined to a conversion function.

With phantom types, a the Point "type" would be a function of types to types. It helps when some operation work on all kinds of points: they can be polymorphic with respect to the additional type.

  data Point a = Point Int Int

  draw_sprite  :: Point Drawing -> sprite -> Io ()
  draw_button  :: Point Window  -> sprite -> Io ()

  translate_point :: Point a -> Point b -> Point a
  translate_point (Point x y) (Point xt yt) =
      Point (x + xt) (y + yt)

[ Parent | on HN ]