9 ms·
"Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structure
by friendly_chap 12y ago
"Rule 5. 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."
Quite ironic coming from the creator of Go. Algebraic data types, anyone?
- tptacek 12y agoOh, interesting. It's the middlebrow dismissal. I thought it had become an endangered species, but here it is, stepping right out into a crowded thread and trying to take out Rob Pike of all people. Good show! https://news.ycombinator.com/item?id=4692598#up_4693920 https://news.ycombinator.com/item?id=4692598#up_4693920
- sampsonjs 12y agoIt's too bad The Master has departed, I'm going to miss his words being quoted to "settle any possible HN argument" in the words of this great comment: https://news.ycombinator.com/item?id=1716028 https://news.ycombinator.com/item?id=1716028. Also going to miss all the pearl clutching about "this comment/thread is horrible", okay maybe not. I assume work was never finished on the Lisp AI that would block comments he disagrees with, any of the mods still working on that?
- deleted 12y ago[deleted]
- anon1385 12y agoOf course pg hates the "middle brow" dismissal. Part of his schtick is Malcolm Gladwell style 'intellectual porn' essays that ignore facts and complexity to paint an aesthetically pleasing (but false) narrative to people who are not subject experts. At this stage I'm not sure if PG does it deliberately like Gladwell admitted doing. I'm willing to give him the benefit of the doubt and say he does it inadvertently by writing about topics where he has no knowledge of previous study, coupled with a large ego born of being rich and constantly surrounded by sycophants trying to get funding. The middle brow dismissal is apt/damaging in these situations because it saves everybody a lot of time by quickly demonstrating that the author ignored those pesky real world facts and complexities that spoilt the ideological narrative.
- robert_tweed 12y agoI don't think you've fully understood Rob's point. Go is pretty good at creating machine-friendly data structures.
- friendly_chap 12y agoMachines are cheap. Developers are not. I would rather optimise for the latter. Edit: since when having ADTs are so taxing for the machines? I did a quick search and I found no source saying they are expensive to implement.
- seanmcdirmid 12y agoMachines have a cost, developers have a cost. One must optimize for both costs, and assuming machines or developers were free compared to the other would be very stupid. There are many problems that require some efficiency to solve effectively, especially in pike's field of systems.
- friendly_chap 12y agoAnd who else is in a similar field? 3% of all programmers? In that case, fine. But most people I see raving about Go can afford the performance hit any time (if there is any). PS: Coding go is my day job.
- seanmcdirmid 12y agoThe systems community is quite large, consisting of probably around 30-50% of the dev jobs in companies like microsoft, Google, Facebook, Apple. Go was designed as a system's language, I think it just eventually went in a different direction when people realized it would never match C++ or even Java in performance.
- burntsushi 12y agoRE Java: It's pretty dang close: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
- ithkuil 12y agoI don't see the irony. Data structures and data types are two different axis. You can argue that advanced language constructs will make it easier to write correct code to implement data structures, but it's not a magic bullet. The Go authors argue that a simple programming language with loops, pointers and arrays is all you need to implement any data structure you need. I find this a good example of a data structure for which I see little or no benefit in being modeled as an ADTs: http://research.swtch.com/sparse http://research.swtch.com/sparse Even simple things like doubly linked lists are complicated with ADTs. On the other hand I don't know about good examples of ADTs used outside of the context of functional programming, do you have some pointers?
- friendly_chap 12y ago"You can argue that advanced language constructs will make it easier to write correct code to implement data structures, but it's not a magic bullet." There is nothing advanced about ADTs. "The Go authors argue that a simple programming language with loops, pointers and arrays is all you need to implement any data structure you need." It's all about increasing the level of abstraction. There is a reason we don't code in assembly anymore. Of course machine code is all you need to implement any data structure, but how convenient is it? "I find this a good example of a data structure for which I see little or no benefit in being modeled as an ADTs:" So you found a single counterexample which (according to you) would not benefit from ADTs. " On the other hand I don't know about good examples of ADTs used outside of the context of functional programming, do you have some pointers?" I dislike pointers (a necessary evil if you have mutation I guess...), but here is one example: data Gender = Male | Female vs type Gender int; const ( Male Gender = iota; Female ) Combine the first with pattern matching and you find yourself in awesomenessland (ie. code becomes readable, type safe).
- mseepgood 12y ago> It's all about increasing the level of abstraction. Rules of abstraction: https://pbs.twimg.com/media/BqkVxmrCUAEZSTZ.jpg https://pbs.twimg.com/media/BqkVxmrCUAEZSTZ.jpg
- e12e 12y agoWell, 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/NDkWSduRPagJ 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.]
- friendly_chap 12y agoI 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?
- e12e 12y agoI 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?]
- hatmatrix 12y agoWhat about lisp, where the data structure is almost always a list?
- Grue3 12y agoWhat lisp? Common Lisp has plenty of data structures, including memory-efficient ones.