
Sequential Consequences - omaranto
https://stuartsierra.com/2020/08/19/sequential-consequences
======
throwaway_pdp09
> 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.

~~~
heavenlyblue
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"

------
rjeli

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

~~~
gojomo
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?

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

------
golergka
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...](http://code.activestate.com/recipes/577992-memoize-generator/)

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

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

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

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

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

