Touché.
The last thing I learned was TypeScript and the Playwright framework for automation and testing. I learned it because I found it a sound, useful, and innovative new technology.
In the past 27 years, I have seen lots of fancy whiz-bang technologies come and go. At the launch, during the early adoption phase of the technology it seems like, "THIS is IT! The next BIG THING. It's going to be super popular." Then, it runs into problems. and quietly fizzles out.
Use discernment.
@ownlifeful I felt bad about my post and deleted it slightly before your gracious response.
@ownlifeful Certainly most new programming languages and tools have limited, if any, advantages over the existing alternatives, and often have fatal flaws. And both Perl and Java are still occasionally the best available alternative. In 95% or more cases, though, Python is a better replacement for Perl for me, and Kotlin looks like a similarly better replacement for Java to me, though the improvement looks to be larger. Python is 31 years old and Kotlin is 11 years old, so they probably won't fizzle out next year.
Rust, Zig, Nim, C#, Javascript, TypeScript, Go, Lua, Clojure, Elixir, Scala, Scheme, Haskell, etc., are sometimes better alternatives to Perl or Java, but none of them have the same nearly-across-the-board advantages over their respective languages that Python and Kotlin do.
And of course none of this is relevant if what you need to do is dive into an existing Perl or Java codebase to make a small change. I fixed a couple of critical bugs in a Perl codebase dating to the 90s last month; even though I hadn't touched the code in years, only took me a few minutes, and I expect it'll be good for several more years now.
@radehi
I have to agree with your call on Python. List comprehensions make Python much more concise than Perl's map. Perl's strength is text processing, so you would think that it would be a great language for Machine Learning, but Python is way ahead in the ML game.
@ownlifeful @radehi It’s mostly because #Google favors #Python and shipped an API for #Tensorflow on day one. But Tensorflow’s core runtime is C++, and a couple of months ago @zmughal released a #Perl wrapper for the #C API: https://metacpan.org/dist/AI-TensorFlow-Libtensorflow/view/lib/AI/TensorFlow/Libtensorflow/Manual/CAPI.pod
Tutorial with #PDL, the Perl Data Language: https://metacpan.org/dist/AI-TensorFlow-Libtensorflow/view/lib/AI/TensorFlow/Libtensorflow/Manual/InferenceUsingTFHubMobileNetV2Model.pod
Zaki notes: “Future work will provide an API for more convenient wrappers which will provide an option to either copy or share the same data (if possible).”
@mjgardner @ownlifeful @zmughal I don't think is *mostly* because Google favors Python. PyTorch and SciPy favor Python, too, for example. Perl is still okay but PDL has never caught up to NumPy.
@radehi @mjgardner @ownlifeful
Yeah, PDL hasn't hit similar levels of adoption. This is despite the PDL architecture being quite good and much more consistent in how it handles broadcasting operations.
I'm hoping to change that by writing more toolboxes, but also just letting people access the data-in-memory straight out of other runtimes (NumPy, Octave, Julia, R) as PDL ndarrays.
@zmughal @mjgardner @ownlifeful Is interesting! How is PDL's broadcasting model more consistent?
@zmughal @mjgardner @ownlifeful This writeup is wonderful! Thank you!
@radehi @mjgardner @ownlifeful
This <http://notes.secretsauce.net/notes/2016/05/17_numpysane-a-more-reasonable-numpy.html> covers a lot of the cases.
Generalised ufuncs are a core part of the PDL::PP language meaning that every function by default does broadcasting and does it the same way: e.g., <https://gist.github.com/zmughal/fd79961a166d653a7316aef2f010a1a2>. No need for something like `numpy.vectorize` as all functions already broadcast every matching args' dims in C.
Probably not as important as the other points, but PDL doesn't have a limit to the number of dimensions (no `MAX_DIMS`).