4 ms·
>this is not the problem we need to tackle right now I mean, it's clearly not the problem _you_ need to tackle right now, but it's a real problem that other pe
by AussieWog93 6y ago
>this is not the problem we need to tackle right now
I mean, it's clearly not the problem _you_ need to tackle right now, but it's a real problem that other people need to tackle.
There are still people hand-rolling broken CSV parsers, manually re-implementing basic STL containers and other stupid "lightness" even when it doesn't make sense. This is not an academic discussion.
- romwell 6y agoIs the perceived "lightness" an issue there, or good old NIH syndrome? 'cause a handrolled CSV parser vs. a third party one is often not a lightness issue; you're using a library either way, and your own library is not necessarily lighter. The article was not even talking about that. The "lightness" approach in your examples would be sticking to arrays instead of using containers, or using Java serialization back when it was introduced (language feature, no extra weight!) instead writing to CSV, which requires a parser. I feel like you are taking about a different problem here, and the problem TFA addresses is indeed academic. (Edit: the author of the article shies away from giving example. The only example -- in-house gettext alternatives -- was definitely not a lightness concern where I've seen it; consider that i18n framework in Android isn't simply gettext for reasons that have nothing to do with TFA)