Rob Pike’s Rules of Programming (1989) • Hacker News Board

Re: Rob Pike’s Rules of Programming (1989)

#61

Post by seanmcdirmid » Sat, Sep 16, 2017, 9:13 PM UTC

DamonHD wrote: post #54

seanmcdirmid wrote: post #50

Earlier quoted context omitted.

One could easily implement a hash set with an array, the reverse is not true at all. From the outside, arrays are extremely flexible, powerful, and complex constructs; a set, even a hash set, is not. If it is easy to procure a set (as a hash set), then sets should be used when they could be used instead of arrays (unless there are performance concerns to using sets). In languages that do not include batteries (e.g. C…

I'm probably missing something, but eg awk implements its 'arrays' at least logically with something like a hash set, and indeed hash sets can be great for (say) sparse arrays. Lots of low-level data structures can be implemented in terms of one another, and which makes sense depends on circumstance.

Low level doesn't mean simple. In this case, arrays provide a lot of flexibility with manual indexing. They are a low level hammer that can do anything.

Sets are much more restricted, they don't have manual indexing, they don't garaunteed iteration ordering without special semantics, they don't do as much as arrays even if they might be implemented with arrays.

Then why use an array when you only need a set and an array would be overkill?

Re: Rob Pike’s Rules of Programming (1989)

#62

Post by smegel » Sat, Sep 16, 2017, 9:13 PM UTC

khedoros1 wrote: post #42

smegel wrote: post #36

Earlier quoted context omitted.

How is writing code that loops over a list simpler than calling: things.Get("key") ?

Your "Get" method hides complexity. It could be that it loops over a list, or that it hashes to find the bin, then loops over the list of items in the bin, or any of other dozens of other possible implementations. So the next question is "What's the implementation of the Get(key) method?" Or maybe "Why aren't you using your language's library methods to loop over that list?"

Why are you even asking the question if profiling hasn't determined a performance problem in that bit of code?

Re: Rob Pike’s Rules of Programming (1989)

#63

Post by smegel » Sat, Sep 16, 2017, 9:15 PM UTC

rdiddly wrote: post #53

smegel wrote: post #36

Earlier quoted context omitted.

How is writing code that loops over a list simpler than calling: things.Get("key") ?

In terms of programmer time/effort, using .Get() is simpler. In terms of program speed/optimization, the answer depends on how .Get() is implemented.

Writing simple programs that meets requirements should be your goal.

Premature optimization is the root of all evil.

Re: Rob Pike’s Rules of Programming (1989)

#64

Post by [deleted] » Sat, Sep 16, 2017, 9:30 PM UTC

BatFastard wrote: post #22

saagarjha wrote: post #3

> If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Therin lies the rub: it’s hard to choose data structures.

Its easy to choose data structures, its hard to choose a good flexible data structure.

[deleted]

Re: Rob Pike’s Rules of Programming (1989)

#65

Post by cutler » Sat, Sep 16, 2017, 9:34 PM UTC

fergazen wrote: post #6

These are not "Rules of Programming", but are excellent "Guidelines for Performance". Having 30yrs under my belt I have come to all the same conclusions as Rob Pike over my years, so these are very deserving of some serious contemplation for those with In my current job we have lots of large and often 'sparsely populated' objects which means basically you can never count on any of the properties you were hoping would…

".. in the modern world", "... younger generation". Maybe you're just getting old? If "OOP had it right all along" there wouldn't be a revival of interest in FP. OOP encourages mutable state and the bigger your programme the harder it is to keep track of it. Rampant mutable state also makes concurrency difficult and concurrency is now more important than it was due to multi-core hardware.

Re: Rob Pike’s Rules of Programming (1989)

#66

Post by mhh__ » Sat, Sep 16, 2017, 9:36 PM UTC

whack wrote: post #27

Rule 6: Every well-intentioned rule will be bastardized and used to justify horrible code. Foo: "Hey, this 10000-element collection, which we do repeated lookups on... why are we using a list and not a HashSet?" Bar: "Because lists are so much simpler than a HashSet. Let's just KISS" Foo: "But... doing repeated lookups on a 10k sized list is so much slower than just using a HashSet!" Bar: "Oh really? Have you profile…

Or just abstract over both of them? For some cases that would make transitioning between the two, and profiling them, very easy.

Re: Rob Pike’s Rules of Programming (1989)

#67

Post by maxpert » Sat, Sep 16, 2017, 9:38 PM UTC

> 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.

OMG, this is so so true! I have seen people writing complicated/fancy algorithms to do simple stuff, and 2 years later they don't even know how did they do it!

Re: Rob Pike’s Rules of Programming (1989)

#68

Post by alexnewman » Sat, Sep 16, 2017, 9:39 PM UTC

Honestly the more I learn about Pike the less I have respect for him. He surely has coded with some of the best but I wonder where he has led us. I appreciate the goals of go but see everything I worry about doubling up: ``` - Everything wrong about c, for instance polymorphism in go is... - Not understanding ownership leads to a lack of design in terms of ownership - without a better sense of types people's thinking is not explicit and careful enough ```

Re: Rob Pike’s Rules of Programming (1989)

#69

Post by winterlight » Sat, Sep 16, 2017, 9:45 PM UTC

smegel wrote: post #60

winterlight wrote: post #48

Earlier quoted context omitted.

The interface is the same. For example, in C# you have an interface Collection, which offers a lookup method, and which both HashSet and Lists implement. The point of the OP is that among different implementations for the same interface, choose the simplest one unless you have empirical evidence that compels you to do otherwise.

> which offers a lookup method, and which both HashSet and Lists implement How does a List map values to key? How does it even represent them?

The lookup method just checks whether an element exists in a collection or not. List and HashSet implement non-indexable collections, which have no notion of key. The Collection interface is very thin, and it's mostly used when you need to keep track of a set of elements. E.g. storing the nodes already visited in a dfs.

Re: Rob Pike’s Rules of Programming (1989)

#70

Post by [deleted] » Sat, Sep 16, 2017, 9:46 PM UTC

seanmcdirmid wrote: post #50

Sniffnoy wrote: post #30

Earlier quoted context omitted.

A set , the abstract interface, is simpler conceptually than a list. A hash set, the particular implementation of a set, is more complex.

One could easily implement a hash set with an array, the reverse is not true at all. From the outside, arrays are extremely flexible, powerful, and complex constructs; a set, even a hash set, is not. If it is easy to procure a set (as a hash set), then sets should be used when they could be used instead of arrays (unless there are performance concerns to using sets). In languages that do not include batteries (e.g. C…

[deleted]