undefined | Better HN

0 pointsmanicdee11y ago0 comments

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.

0 comments

loup-vaillant11y ago

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)

j / k navigate · click thread line to collapse