News for hackers. Stuff that matters.
Re:Fast.ai and why Python is not the future of ML with Jerem... by cheriot on Tuesday September 08, 2020 @02:47AM (#24405802)
tldr;

Jeremy Howard says python will always be calling out to something else that's faster and more parallel. Writing fast python has too much cognitive overhead. He hopes Julia catches on because it's Julia all the way down.

Re:Fast.ai and why Python is not the future of ML with Jerem... by linkdd on Tuesday September 08, 2020 @03:28AM (#24406010)
I think that's one of the strength of Python:

- implement your work intensive logic with the adapted tools

- glue everything together with Python

Re:Fast.ai and why Python is not the future of ML with Jerem... by lmm on Tuesday September 08, 2020 @03:47AM (#24406115)
I used to think that until I found Scala. It's easier than writing Python - I can write pretty much the same thing as I would in Python, but I have a more complete IDE and I can ask it what the types of things are. I'd never want to use a Java/C++-style language for exploratory programming, but it turns out not all reasonable-performance languages are like that.
Re:Fast.ai and why Python is not the future of ML with Jerem... by gilbertmpanga12 on Tuesday September 08, 2020 @04:40AM (#24406427)
I think you're trying to oversell here, Scala is bloated with lots of paradigms and lots of features. It's pretty hard to know what to use. Python in most ML frameworks is just a frontend, other beefy stuff gets processed by c++ or c
Re:Fast.ai and why Python is not the future of ML with Jerem... by lmm on Tuesday September 08, 2020 @08:27PM (#24415290)
> Scala is bloated with lots of paradigms and lots of features. It's pretty hard to know what to use.

It's a flexible language, but I wouldn't say bloated - there actually aren't so many language-level features, but the features there are are very general. Some parts are simpler, e.g. in Python I struggle to remember which method you have to define to overload the * operator, whereas in Scala you just define a method called * . But I'd agree that there are a bunch of overcomplicated frameworks that can be pretty confusing - it's not always an easy language to get started with. But I stand by the statement that you can write Python-like code in it, at least once you know what you're doing.

> Python in most ML frameworks is just a frontend, other beefy stuff gets processed by c++ or c

Right, and that introduces a bunch of overhead and possibilities for weird errors - e.g. when you hit a bug in a library you pretty much have to learn how to debug C. In Python the benefits are worth it, but there's undeniably an overhead - if you could use the same language top-to-bottom but still have all the nice things Python gives you, that would be a much nicer way to work.

Re:Fast.ai and why Python is not the future of ML with Jerem... by fxtentacle on Tuesday September 08, 2020 @03:55AM (#24406145)
I actually do lots of exploration with C++ and ReSharper. There's excellent C++ libraries for everything these days. And cmake has made them easy to install.
Re:Fast.ai and why Python is not the future of ML with Jerem... by lmm on Tuesday September 08, 2020 @04:03AM (#24406194)
I really don't see it. No first-class REPL and REPLs/IDEs will always be limited due to the ecosystem relying on macros; no proper dependency manager and certainly nothing comparable to maven central/CPAN/etc. And the language is missing even the most basic support for sum types, making its type system painfully restrictive.
Re:Fast.ai and why Python is not the future of ML with Jerem... by pjmlp on Tuesday September 08, 2020 @05:17AM (#24406631)
conan and vcpkg are the proper dependency management.

Macros are less of an issue with modern IDEs, and that is hardly any different from any other language with macro support, including Scala.

Re:Fast.ai and why Python is not the future of ML with Jerem... by pjmlp on Tuesday September 08, 2020 @05:15AM (#24406619)
Except, there are several languages as dynamic as Python that don't need "adapted tools", because they also offer AOT/JIT compilers in the same package.
Re:Fast.ai and why Python is not the future of ML with Jerem... by tasubotadas on Tuesday September 08, 2020 @05:43AM (#24406783)
How many times you've tried glueing C++/C code with Python?

It's a pain in the ass, and there is no need to pretend that it's great just because Python sucks (performance wise).

Re:Fast.ai and why Python is not the future of ML with Jerem... by Nimitz14 on Tuesday September 08, 2020 @06:03AM (#24406893)
Ever heard of pybind11? It's easy as fuck.
Re:Fast.ai and why Python is not the future of ML with Jerem... by ummonk on Tuesday September 08, 2020 @06:24AM (#24406989)
How is that a strength? Why should you need to implement the work intensive logic in one language and glue it together in another?
Re:Fast.ai and why Python is not the future of ML with Jerem... by evgen on Tuesday September 08, 2020 @06:33AM (#24407043)
The standard reply to this that has been repeated over and over is that for 99.99999% of the people performing such a task they are not going to implement the work intensive logic, they are going to use a well-tested and well-supported library that is built and maintained by domain experts.
Re:Fast.ai and why Python is not the future of ML with Jerem... by pjmlp on Tuesday September 08, 2020 @07:58AM (#24407520)
Which can have bindings to every language in existence, thus diminishing even more the role of Python.
Re:Fast.ai and why Python is not the future of ML with Jerem... by evgen on Tuesday September 08, 2020 @11:01AM (#24409091)
Given the choice between using library bindings in Python and similar bindings in C++ or Java, the world has voted with their feet. When it comes to easy to use glue languages, Python won.
Re:Fast.ai and why Python is not the future of ML with Jerem... by pjmlp on Tuesday September 08, 2020 @04:04PM (#24412512)
Who said those are the only two options available?

Python seems to have won.

Re:Fast.ai and why Python is not the future of ML with Jerem... by 0x008 on Tuesday September 08, 2020 @01:38PM (#24410706)
Yes! People who compare python to Julia miss the point. Python is not really used as a programming language, Python is the new bash.
Re:Fast.ai and why Python is not the future of ML with Jerem... by pjmlp on Tuesday September 08, 2020 @04:06PM (#24412535)
Tcl did it first, look where it is now.

Alternatives abound.

Re:Fast.ai and why Python is not the future of ML with Jerem... by linkdd on Tuesday September 08, 2020 @09:03AM (#24407960)
Why would it diminish the role of Python ?

One of the strength of Python is its capacity to integrate with anything. We never said it was the only language with that strength.

With Python comes an ecosystem, another language another ecosystem. Choose the tool that fits your need.

Re:Fast.ai and why Python is not the future of ML with Jerem... by dklend122 on Tuesday September 08, 2020 @02:31PM (#24411354)
That's a function of the available tools, not of the opportunities to do so. Julia makes writing custom kernels easy.