Since newbies are always listening, I'll just mention something a lot of
people here (including Greg) already know. :)
Something like `file->lines` is a handy convenience, when you know the
file size won't break your system, and/or you're not writing reusable or
long-lived code.
Good practice for important and reusable code often means doing this
serial file processing as iteration (or folds) over the input port, and
processing as you go, rather than sucking an entire file into memory first.
Not all line-based file-processing tasks are serial like this, but I'd
guess that most are (or, even if you have to do some non-serial
processing, it can usually be done in a more space-efficient way than
representing the entire file in memory).
It's good to get comfortable with this. You don't see it only in simple
line-oriented file processing, but that's a good playground for
learning. Many software frameworks at the moment obscure computational
time and space factors (and often hide massive loads of crud piled atop
crud atop crud, especially in in client-side Web frameworks). But your
Racket programs are one environment in which you can often still have a
pretty good idea of what's going on, and grow as a programmer. If any
newbies are not convinced, I'll just say "big data" here, as one
buzzwordy example. :) When, for example, we suddenly need to invent a
way to decompose big data processing to use specialized compute
clusters, that's a job for someone who can understand things, not
someone who spent all their time only learning how to cargo-cult their
way through someone else's crappy Web frameworks. :)
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
