Sequential Consequences | Hacker News Reader

Sequential Consequences

stuartsierra.com

32 pointsomaranto10 comments

> There comes a point in a programming career — at least one as peripatetic as mine — at which learning a new programming language barely registers as an obstacle

weeell, maybe. I'm relearning a language I haven't touched for years, and while I can apply the high-level stuff to it (I know what an object is, how to declare a class is almost universal, functional stuff is same but renamed, generics are fine) I keep tripping over the small stuff. So yes, "off you go", but rather slowly.

The author thinks that "picking up" a language is just learning the syntax and then goes on to prove that actually learning the language is all about knowing of these "quirks" they don't know how to deal with and thus whine that "it is so much better in X"

  things, also_things = itertools.tee(things)
  next(things), list(also_things)
  => (0, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

Nice, idiomatically!

But if the original `things` is gigabytes in size and streamed from elsewhere, isn't it queueing those all up, as they're read from `also_things`, in case they're ever read from new `things` - even if they're not?

Oops, you’re right. more-itertools has `peekable`, that’s probably the most readable

May be I don't know Python that well, but in any language that has generators, wouldn't it be pretty straightforward to create a generic memoizator that would cache items of provided generator after they are requested at least once? Nothing would stop you from implementing __getitem__() on it, and the initial version of Python code would still work.

Update: googled up memoizator that almost imlements exactly what I'm talking about: http://code.activestate.com/recipes/577992-memoize-generator...

Just add __getitem__() to it that would access __cache, and you're done.

Of course C# (and friends) has the similar problem using LINQ -- referencing what looks like the same thing, but possibly re-creating the underlying lazy IEnumerable each time. To fix this you typically do a .ToList() but that materializes the whole thing which you may not want.

F# has Seq.Cache so the the seq stays lazy but only remembers what has come in the "past", mimicking the Clojure behavior if you want to opt-in -- I'm not sure there's a corresponding BCL fn yet for C#.

I've actually gotten this question in a google interview before: https://leetcode.com/problems/peeking-iterator/

“I found learning a new language was easy” Proceeds to explain why a language that was designed to be easy to learn, is easy to learn.

I prefer the Python behavior here. Otherwise I'd always been uncertain about how much of the iterator has been held in memory.

Reply on news.ycombinator.com