The abject failure of weak typing | Hacker News Reader

The abject failure of weak typing

techblog.realestate.com.au

61 pointszoomerang16 comments

I'd like to stress the point about wrapper types, which can even be usefully employed in C. Note that - in C - this is not typedef (which is mostly cosmetic), but rather wrapping primitives in otherwise empty structs. This has no runtime cost and has the tremendous benefit that you won't mix up the arguments to place_order(price_t, quantity_t) where you might to place_order(int price, int quantity).

I think what this planet needs is a comprehensive study of how different typing techniques and schools of thought would solve different classes of problems, because what I notice is that

1) definitions are hard, and don't mean much

2) there are many equivalences, and some idioms are conceptually very similar across different type systems, and are just not implemented the same way. For example, a it's a common hobby among FP weenies to show how most of the GoF design patterns are one-liners in their languages of choice.

3) the scope of many typing disciplines is not the same; for example, unityped languages work great for tasks of limited scope with lots of user interface components, functional is historically used to write nice algorithms, and OOP is an attempt at giving a distinct shape to software of very large scope (and it happens to be a pain in the ass when the scope isn't that large)

    def compare(a: Int, b: Int): Int

    This one has not only 232 possible results, but an incalculable (232)264 possible implementations. Even if we are generous and only allow the inputs to be 0 or 1, we still have 2128 implementations. If the only meaningful return values are -1, 0 and 1, indicating “less than”, “equal” or “greater than”, then why would we embed them like specks of dust in a big desert of undefined behaviour?

I don't agree with this. This is not a "big desert of undefined behaviour". The behaviour is defined along the entire spectrum of Integer values. "Less than" maps to all values <= -1, "equal" maps to 0, and "greater than" maps to all values >= 1. There's no undefined behaviour here.

Implicitness as a source of error (in general) seems to raise its ugly head over and over again.

This entire post seems to conflate "weak typing" with "dynamic typing". Both are terms that seem to have a lot of common definitions, but they're nevertheless distinct.

Weak typing usually implies a system where types get coerced easily:

    php -r "echo '4' + 4;"
    8

Dynamic typing, though, generally means that the type is associated with runtime values. It doesn't mean that the typing is necessarily weak:

    ruby -e "'4' + 4"
    -e:1:in `+': no implicit conversion of Fixnum into String (TypeError)
	from -e:1:in `<main>'

That's cool and all but I think that the point of the article is that the distinction is moot, because they just don't offer anything near the expressive power of algebraic typing.

"Weak" and "strong" are not well-defined terms, and you'll find different defs around the place.

I deliberately used "weak" in the title as a loose umbrella term for the sundry malpractices detailed below. The article is hopefully otherwise quite specific.

In particular, by "types", I always mean "static types" or "propositions". What you mean mean by "dynamic types", I call "tags"; they are not the topic of the article. These usages are standard, if not universally adhered to; I hope I made this clear in the article.

Unfortunately weak typing is still a very ill defined term and is somewhat misleading because it tends to carry a lot of implicit assumptions about which type coercions are expected. Implicit conversion between floating point and integral types for instance.

It's a well written version of, "our software design was sloppy and our programmers took shortcuts. Therefore language feature X is to blame."

  def findAddress(userId: String): String
  What does it do? Are you sure?

  Now lets look at another:

  def blah(foo: UserId): Address

What about

  def find_address_of_user( UserID )

or even better

  class User(Model):
     …
     address = our_models.AddressModel( … )

So you can use 'x = user.address' with no need to explicitly map between users and addresses because the mapping is part of your data structure?

In some scenarios, Hungarian notation might make sense:

  def user_address(user):

In Hungarian notation you explicitly state what kind of data is expected, so that you can easily determine if mistakes are being made in the code:

  billing_vcard = contact_vcard(customer.billing_contact)

as opposed to:

  display_vcard = contact_email(customer.billing_contact)

Of course, cue the irrational knee-jerk reaction to "Hungarian notation" by people who don't understand what it actually is.

  OO lore has it that pattern matching is evil, and that subtype-polymorphism is the answer to all questions.

Not the OOD that I've been taught. Polymorphism is a tool, and it is as much the answer to all questions as a screwdriver is the answer to all construction projects.

That the author of this piece has found various languages educational in presenting new ways of solving problems (with code smells, data model smells, or sloppy architecture) is the biggest take-home message for me: don't be a "Perl programmer" or a "Scala programmer". Be a software engineer, and make sure you are aware of all the available architecture rules, modelling guides and design patterns that have been developed over the years to make your job easier.

Perhaps I'm missing something due to having read through the article too quickly. Please educate me.

> Perhaps I'm missing something due to having read through the article too quickly. Please educate me.

The point I got out of this fine article is that we are under/misusing types.

Types encode logical propositions. The compiler, besides producing binary code, is also a proof checker. We should let it help us reason about the program instead of trying to do everything informally in our heads.

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

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.

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)

It is not as much feature X, but lack of feature X that's the problem in the article. Statical typing is a tool you should be using if it is suitable to your problems. The problem described is verifying there is no garbage in garbage out situation for your functions. Proposed solution is making compiler do the check instead of manually checking the codebase, writing more code known as TDD, enforcing conventions that are easily confusing... Common theme in these alternatives are necessity of extra tools and all associated effort. Compiler can be a perfectly servicable point of enforcement if types are used properly with possibly no extra cost.

My completely subjective opinion:

OOP is a valid way to write strongly typed code, but there are many useful and common situations that can be solved by some primitive feature found in any good functional language, where the OOP solution is verbose and counter-intuitive.

And that partly explains why so many people bypass the properly designed, strongly typed, object-oriented solution and write shitty code instead.

News flash!! Strong typing has benefits!

Reply on news.ycombinator.com