Hacker News Reader

Comment by e12e | Hacker News Reader

Well, I'm no super fan of go, but given the ideas they were working with, I think they ended up with a fair compromise. I mean, if you want Haskell (or ML), use that?

I think it is a question of how far you're willing to take generalization over how easy it is to come up with a reasonable concrete solution to a concrete problem.

See eg: https://groups.google.com/d/msg/golang-nuts/DLxFvfdRKBY/NDkW...

The c mindset of unions/structs coupled with functions doesn't contradict the idea of "chose the right data structures".

[edit: It appears others have made this point better while I was typing. The gist seems to be (to paraphrase another comment): (abstract) data types and types are not the same thing. types can help with the implementation of ADTs, but that's not really relevent to the 5th rule.]

View on HN

I don't get this:

"data types and types are not the same thing. types can help with the implementation of ADTs"

Can you please show me how can you implement a language (type system) feature without touching the compiler source?

I don't understand the question... an ADT is something like "a stack", where "a stack" is the collection of procedures that manipulate a stack, and have an interface that integrate with the type system. So a stack takes a type, and allows it to be pushed on, and popped off. Together these form an ADT. Now, if you have algebraic types, you might have an easier time implementing the stack ADT in a way that it can handle both text strings (push a string onto a stack) as well as numbers. Or you could just say that everything is a number: and "push by reference" -- so you can push a complex record to the stack -- but all the stack sees is an integer (a pointer to the record).

Type safety (checking that all integers pushed to the "record-of-type-library-card stack" are in fact valid pointers to valid library-card-records) can be helpful, but not needed to implement ADTs.

Am I close to clearing up what I was talking about above?

[edit: typo, also: you mis-quoted me, dropping the "abstract" in "abstract data type" -- which might be the source of the confusion?]

I think the parent comment is assuming ADT is short for "algebraic data types" and not "abstract data types", since the former is the subject of the rest of the thread. You used both long forms and the acronym without saying which you meant.

As to the meat of the discussion, algebraic data types imply that you can apply algebraic operators to types. Since this is traditionally a purely compile-time feature you can imagine why the parent comment is incredulous that you could implement this without language support.

Your specific statement, "data types and types are not the same thing," is particularly confusing. You are making assumptions that aren't warranted, for example that "data types" encompass both a compile-time type check and an interface allowing abstract operations, while "types" are simply static type guarantees on values. In fact, both terms can refer to either.

Fair enough, but I didn't say "data types and types are not the same thing", I said "(abstract) data types and types are not the same thing" (unless I did for a moment before a quick edit, but I don't think so).

Anyway, I think we've cleared up what I apparently didn't put very clearly in the first place: Algebraic Data Types can help with implementing Abstract Data Types, but one doesn't need the former for the latter -- and I suspect the data structures of "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." are indeed closer to using the right simple data structures along with the correct abstract data types -- so there's no direct contradiction between the 5th rule and Go not having (proper) Algebraic Types.

Reply on news.ycombinator.com