31–40 of 41 posts
If you really want to, there's also the `join` command, which has been part of the standard unix toolset for longer than many of us have been alive.
> a performant join that avoids the hassle of SQL tables. Hm, a hassle is not always the same hassle for everyone. Personally, I like SQL and I enjoy the power it can leverage on all kind of data. As others wrote, working with sqlite for local data processing is a tool I do not want to miss, besides all of the great Unix coreutils and its (mostly GNU) ecosystem.
I wasn't aware, but some developers do seem to be allergic to SQL at all cost and would go to great lengths to avoid it just because.
Earlier quoted context omitted.
People that do proper ETL don't use python
Real programmers use butterflies. https://xkcd.com/378/
I have done some similar, simpler data wrangling with xsv ( https://github.com/BurntSushi/xsv ) and jq. It could process my 800M rows in a couple of minutes (plus the time to read it out from the database =)
I‘d rather just use DuckDB and write a few SQLs, and be done. This can be done in the terminal as well.
I have done some similar, simpler data wrangling with xsv ( https://github.com/BurntSushi/xsv ) and jq. It could process my 800M rows in a couple of minutes (plus the time to read it out from the database =)
Earlier quoted context omitted.
Real programmers use butterflies. https://xkcd.com/378/
Now I wonder if Raku developers chose the mascot thanks to this particular XKCD: https://en.m.wikipedia.org/wiki/File:Camelia.svg
Wait, you guys aren't copy and pasting every CSV by hand into an Excel spreadsheet?
Please don’t do this for actual work you share with other people. There’s a good reason why pandas exists.
People that do proper ETL don't use python
More composable than SQL. Have plenty of utility functions wrapped up (which are far easier than stored procedures) in libraries. The code is far easier to step through with a debugger (due to the composability).
