top | item 26120067

(no title)

ddragon | 5 years ago

If they weren't already-made in Julia yes (and a library didn't do the work of composing it and presenting as a monolith, since pretty much all large frameworks like Flux and DiffEq are also made this way). Although you're maybe trying to imply that everything that anyone needs is already made in python, I occasionally end up finding small issues between my use case and what's immediately available and I have to twist my problem into a stitch of "kinda what I need" pieces (like having to change my problem into a vectorization problem, a long chain of corrections using pandas to fit an interface and then some weird logic to transform the table into a CSV in memory to use postgres' COPY or UPSERT because pandas to_sql is not flexible enough and iterating and inserting is too slow). Sure I always achieve the result using already-made stuff, but the glue logic ends up taking more time and honestly ends up quite hard to maintain for other people (or even myself after a few months) after all it isn't my algorithm logic but some adhoc puzzle I just solved.

In Julia, if the DataFrame library is missing something I can just loop like an array and have a method that works just as well as if the library provided it, the CSV, DB and table processing libraries all use the same conventions so if library "A" solves my issue I'm not forced to use the same library "A" serialization method. Basically instead of twisting the logic to what I'm given, I just fill in the blanks. Sure Julia has way more blanks, but Julia also has half of the age of some of the Python's library I use, it's more about the maturity of the community than anything to do with the design choices of the language and I can only hope it gets better and better with time.

discuss

order

No comments yet.