Disagree. In the future, that'll be `npm install ml-cat` followed by `MLCat = require('ml-cat'); MLCat.isCat(image)`
It might not be npm, but something like that is probably inevitable.
The reason it seems so unlikely is because the tooling isn't there yet. No one even agrees how ML code should look, let alone how libs should be distributed to end users. But I saw the transformation for JS in 2008.
the range of problems you can solve with ML/AI is simply too wide for there to be fully-canned solutions for everything. Sure, there will be canned solutions for _some_ things - maybe even for cat detection, because it's fun so why not.
But, a library that uses AI to optimize the production of your business' flux capacitors? Ain't gonna happen, you need to build that yourself. To have a library/product that solves problems using AI, you need a "language" to describe the problem (like you can e.g. use SQL to describe any data query you may have). But describing problems is notoriously hard - accurately & precisely describing the problem is very often just as hard as solving it.
Mm, it's a bit like arguing that "the range of text editor customization is simply too wide for there to be fully-canned solutions for everything." Meanwhile, elisp wiki go brr.
I think ML solutions will increasingly take the form of an elisp script rather than a python library, but it'll take a little while to get there.
> it's a bit like arguing that "the range of text editor customization is simply too wide for there to be fully-canned solutions for everything."
But the the range of editor customization really isn't that wide. That's exactly what I'm arguing, that ML/AI is more like "math" than like "editor customization".
It might not be npm, but something like that is probably inevitable.
The reason it seems so unlikely is because the tooling isn't there yet. No one even agrees how ML code should look, let alone how libs should be distributed to end users. But I saw the transformation for JS in 2008.