Hacker News Reader

Your argument, unfortunately, doesn't really work, because for instance, in Haskell,

    data RGB = RGB Word8 Word8 Word8

The point made here has nothing to do with weak typing. It just so happens his example sort of implies that he might be using it, since the author rather likes Erlang and that appears to be the syntax he reaches for, but the entire article applies without loss to strongly-typed languages as well. (Of which Haskell is merely a convenient example. Even more conventional manifest typing, as in C, works well enough here.) If you want to declare that you have a map of Booglies to Wangdoodles, it's trivial, but you're still using off-the-shelf maps and not bashing together trees yourself.

In this case, Word8 applies nicely, but I'd like to point out that the argument doesn't fly either when something isn't nicely mapped to a type. E.g. (not checked):

    module Temperature (
      TempCelsius
      tempCelsius
    ) where

    newtype TempCelsius = TempCelsius Double

    absoluteMinimum :: Double
    absoluteMinimum = -273.15

    tempCelsius :: Double -> Maybe TempCelsius
    tempCelsius t
      | t < absoluteMinimum = Nothing
      | otherwise           = Just $ TempCelsius t

In other words, by hiding the constructor, you can control all access to a datatype. You could do the same with opaque pointers in C, etc.

> But what happens when get a tuple from somewhere containing {289, 345, -1}? Or god forbid {200, "Monkeyspit", {}}!

You just move type check to runtime and use some kind of contracts... but what does it have in common with OOP? It's closer to classic dynamic vs. static typing argument and as someone pointed out OO type systems are mostly inferior to Haskell's. The point being - it's not relevant here.

> However, not using strictly defined self-contained data types for a large project is also recipe for confusion and pain.

Not using well defined data types for in a widely exposed interface in a large project is suboptimal.

Overly formalizing data types for entities of limited scope is suboptimal on small and large projects.

We need to be careful about adding unnecessary weight to large projects, because it costs more there.

> in many languages arrays are objects, dictionaries are objects, and tuples are objects

I am not aware of a canonical definition of object. One thing that is commonly included is the idea that objects have identity. So "two" arrays with the same values are distinguished in the object world. This is not what people mean if they create an RGB from an array (or dictionary).

"...but I think he fails to recognize that the opposite is also true"

I don't think that is the case at all. In fact, it is specifically implied in the sentence that you chose to quote. Why is the top reply to every HN story always so darn contrarian and nit-picky (in this case, not even validly so)? Why can't it just once be "Yep, you nailed it." (or something insightful)

> Why can't it just once be "Yep, you nailed it."

Insubstantial praise isn't really worthwhile unless invited. If it's invited, it'll be through comments on the article itself, not on an aggregator like HN.

I don't disagree with your overall point: the nitpicking is nearly as worthless: but if you don't have anything substantial to say, it isn't worth saying anything. Just upvote and move on.

I think it comes down to discipline. We're using javascript (on both frontend and backend) which is not very strict, but we don't have that many "wtf is that kind of object doing here?" moments, and none after tests pass.

As jerf and danieldk point out, your concern is "I want static typing", and has nothing to do with OOP.

Static typing is one way of accomplishing something similar but it's neither necessary nor sufficient. Sure you can define an RGB value as three 8-bit bytes and get something that's valid all of the time. But that's a contrived example because RGB color is defined in terms of bytes! What about every other piece of data in your application?

In simplest terms, OOP combines opaque data structures with the operations performed on them. This should, if done correctly, prevent a whole lot of different kinds of easy to make mistakes. It also helps simplify and organize code.

>What about every other piece of data in your application?

I create a type for it? Why do you think RGB being bytes makes it special? Bools aren't bytes, but I can't pass anything other than True and False for a Bool.

>OOP combines opaque data structures with the operations performed on them.

That does nothing to prevent errors. Having the operations require the correct types does prevent errors on the other hand, regardless of whether or not the operations and data are put into an "object" together or not.

> Why do you think RGB being bytes makes it special? Bools aren't bytes...

Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation).

How would you handle a real complex type like Customer or Order or Window or Button?

> That does nothing to prevent errors.

Yes, it does. It's effectively the DRY principle -- you can't repeat the data manipulation code throughout the codebase. OOP formalizes some of the best practices for procedural programming.

>Bools are special too because the compiler handles ensuring that they are true and false (and you don't even get to choose to representation).

No they aren't. You are assuming every language is as shitty as Java. This is not the case. There is nothing special about Bool, it is a normal ADT:

    Bool = True | False

>How would you handle a real complex type like Customer or Order or Window or Button?

Defining a type for it, just like anything else? I don't understand what is confusing you here. Do you normally just keep your Customers or Orders as a hash table of string:string or something? Even in OO languages, you create a type for them, it just happens that the only way you can create types in most OO languages is making classes.

>Yes, it does. It's effectively the DRY principle -- you can't repeat the data manipulation code throughout the codebase

Yes you can, there is absolutely nothing stopping you from making a dozen different doThingToCustomer functions/methods scattered across a dozen different classes. I am amazed that you are seriously suggesting that the problem OOP solves is people accidentally writing the same function multiple times, when that was never a problem, and OOP doesn't do anything to address it. And how on earth does this bizarre notion address the class of errors you were complaining about, which are type errors?

> You are assuming every language is as shitty as Java.

Perhaps. Java, C#, C++, PHP, Python, Ruby, etc.

> Yes you can, there is absolutely nothing stopping you from making a dozen different doThingToCustomer functions/methods scattered across a dozen different classes.

If Customer is a class, it's pretty difficult to doThingToCustomer() that the Customer itself doesn't allow.

> And how on earth does this bizarre notion address the class of errors you were complaining about, which are type errors?

Just as I said above, it's difficult to alter the contents of an object in a way that an object doesn't allow. In "pure" Alan Kay style OOP an object is something that responds to messages. In loose languages like Python you can reach into an object and mess with it but that is discouraged.

>If Customer is a class, it's pretty difficult to doThingToCustomer() that the Customer itself doesn't allow.

That applies just as much to functional programming as it does to object oriented programming. If you don't want people to mess with the internals, then don't export them.