Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

dev-discuss.pytorch.org

Post reply on HN
Print view View original

181–190 of 291 posts

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#181

Post by pjmlp »

hjtkfkfmr wrote: post #65
geofft wrote: post #15

> Julia says: > A language must compile to efficient code, and we will add restrictions to the language (type stability) to make sure this is possible. > A language must allow post facto extensibility (multiple dispatch), and we will organize the ecosystem around JIT compilation to make this possible. > The combination of these two features gives you a system that has dynamic language level flexibility (because you h…

For once it's impossible to work in Java without an IDE and without creating a project. But you can just write a simple 20 line Python script to do some data mangling, no project with 30 IDE files required.

Between 1996 and 1999 there were hardly any IDEs available for Java outside Windows, and Forte was Solaris only.

Visual J++, Visual Cafe and JBuilder were the main ones but not everyone was eager to buy them, while the JDK was free beer.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#182

Post by pilooch »

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK.

But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python.

Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it'll be needed for performance, forever.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#183

Post by joconde »

mbeex wrote: post #179
joconde wrote: post #172

Earlier quoted context omitted.

I'm not completely sure that you aren't joking. Maybe for a mathematician the latter would be "very readable"?

Indeed it is (slight improvements not excluded). I would love to be able to write things like M T A (w/o the HTML rubbish seen here - flavour of the same problem) for two matrices directly as code (can Julia do that?). Instead, I've been forced to learn row and column precedence in OpenGL, DirectX, Numpy, and whatever, paying attention to it in endless constructs. Even after 25 years in the business, it's still a pai…

What about everything that isn't yet represented by widely-adopted mathematical notation? I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase. The advantage of English words is that everyone knows them.

Edit for details: `Σλ∀φ` is a chore to read for me. These letters only make sense if I've absorbed the author's notation beforehand, like in a math proof. I parse the snake case version instantly, because my brain is trained for that. And I understand it much more quickly, because it says exactly what the function does in the way I would represent it in memory.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#184

Post by jimsimmons »

Tsarbomb wrote: post #27
noitpmeder wrote: post #9

Earlier quoted context omitted.

What do you think the major drawbacks are? Speed would be the top of my list, but most projects to not need anything more than what python can currently pump out.

Aside from speed, one thing that really eats at me is that it makes any sort of functional programming overly verbose, unfun, and just not very idiomatic. Also the the vast majority of python programmers simply don't understand the best practices in their own ecosystem. I was recently writing code using Reactor/RxJava in Java 11 w/ Lombok. I don't think I've ever been so productive or lead a team as productive as whe…

Never seen Python described as verbose. Rx has libraries in Python libraries. If you think scientific programmers give a damn about build systems you don’t know what you’re talking about

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#185

Post by anothernewdude »

pilooch wrote: post #182

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK. But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python. Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it'll be neede…

If Julia had wanted to be taken seriously then it shouldn't have dropped the ball at the very first hurdle by having 1-based array indexing.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#186

Post by dunefox »

anothernewdude wrote: post #185
pilooch wrote: post #182

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK. But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python. Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it'll be neede…

If Julia had wanted to be taken seriously then it shouldn't have dropped the ball at the very first hurdle by having 1-based array indexing.

This is such a non-issue and I'm tired of reading a version of this comment in any thread where Julia is mentioned.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#187

Post by dunefox »

rg111 wrote: post #143
stabbles wrote: post #2

What stage of Julia denial is this?

With the slightest hint arising that Julia would be the future of ML and DL, I learned it. But, then what? I could not use it anywhere I worked. The ecosystem was lacking. Julia is good, but for what exactly? People involved with Julia are always big with words, but when will I see it in use somewhere?

The ecosystem is a superset of Pythons: https://github.com/JuliaPy/PyCall.jl

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#188

Post by goerz »

joconde wrote: post #183
mbeex wrote: post #179

Earlier quoted context omitted.

Indeed it is (slight improvements not excluded). I would love to be able to write things like M T A (w/o the HTML rubbish seen here - flavour of the same problem) for two matrices directly as code (can Julia do that?). Instead, I've been forced to learn row and column precedence in OpenGL, DirectX, Numpy, and whatever, paying attention to it in endless constructs. Even after 25 years in the business, it's still a pai…

What about everything that isn't yet represented by widely-adopted mathematical notation? I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase. The advantage of English words is that everyone knows them. Edit for details: `Σλ∀φ` is a chore to read for me. These letters only make sense if I've absorbed the author's notation beforehand, like in a math proof.…

We’re talking in a context of scientific software here.

> I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase.

You have to do that anyway, because you’ll have to connect the code you’re working on with the scientific paper describing it. When the code uses variable names too far removed from the mathematical symbols, you have to do make two steps: figure out how the words connect to symbols and then figure out the symbols. This will be especially difficult for the mathematician/scientist without a strong coding background: they’ll have much less friction reading code that matches the symbolic notation and Greek letters that they’re used to.

> The advantage of English words is that everyone knows them.

Not when it comes to “math” words.

> `Σλ∀φ` is a chore to read for me.

Right, but that’s because you have a different background. For me, `Σλ∀φ` is much easier to read and understand. More importantly, a symbolic notation is much denser, which allows to parse long expression that would be very hard to understand if they were written out in words.

Again, this is for the very specific context of highly mathematical/scientific software that Julia excels at and is primarily used for. In a more general context (when the software isn’t a direct representation of a scientific paper), I’m 100% on board with good, descriptive variable names

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#189

Post by freemint »

anothernewdude wrote: post #185
pilooch wrote: post #182

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK. But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python. Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it'll be neede…

If Julia had wanted to be taken seriously then it shouldn't have dropped the ball at the very first hurdle by having 1-based array indexing.

This is a total non issue as indexing is an operation that is subject to multiple dispatch. For a humorous example see https://github.com/giordano/StarWarsArrays.jl

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#190

Post by freemint »

longemen3000 wrote: post #125
de6u99er wrote: post #89

Earlier quoted context omitted.

I think Python is great for exploration and method development, while I would prefer something more efficient like Julia for production systems. On the other hand, Julia requires compilation while Python allows open-heart surgery on the production system (for the masochists among us). I personally don't like Python that much because every library does things differently and sometimes it feels like learning a complete…

Just to be clear Julia is "AOT-JIT", that means that the methods are compiled when used the first time. With Revise.jl (a package for interactive development) you can make a fully interactive Julia process, rewriting things on the fly, while benefiting from fast code

Running Revise in production sounds unwise (sorry for the pun).

Also you can very much not redefine functions on the fly due to world age (assuming the caller doesn't pay for invoke-latest).

Post reply on HN