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

271–280 of 291 posts

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

#271

Post by Daishiman »

amkkma wrote: post #265
Daishiman wrote: post #259

Earlier quoted context omitted.

But Julia doesn't have a good story for anything else besides that. You can take a Python web server process, have a request call a task that uses NumPy and OpenCV and scikit-learn, get that back, and you're done, all in the same language. Julia's community does not seem to have aspirations beyond high-performance math code, which is great for its use, but I'm not going to learn Julia just for that when I can impleme…

That's just not true. https://github.com/GenieFramework/Genie.jl https://github.com/JuliaWeb/HTTP.jl https://www.youtube.com/watch?v=xsxJt4prFG4 And with upcoming improvements to binary size and structured concurrency (it already does go-like lightweight threads) it will get even better.

A notebook doesn't make for a line-of-business web app.

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

#272

Post by d0mine »

adsharma wrote: post #254

I'm surprised that no one brought up using a subset of python with an emphasis on static typing, efficiency and transpilation can give you both the ecosystem and the efficiency.

There is Cython--it is a superset of Python. https://cython.org/

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

#273

Post by adsharma »

d0mine wrote: post #272
adsharma wrote: post #254

I'm surprised that no one brought up using a subset of python with an emphasis on static typing, efficiency and transpilation can give you both the ecosystem and the efficiency.

There is Cython--it is a superset of Python. https://cython.org/

I'm aware of it, but prefer a subset accepted by static type checkers over a superset.

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

#274

Post by dnautics »

dragonwriter wrote: post #228
dnautics wrote: post #103

Earlier quoted context omitted.

Do you have absolute control over the hiring of every person you work with? Not all of us do.

> Do you have absolute control over the hiring of every person you work with? That's...a complete topic switch and irrelevant. The discussion I was responding to is about the challenges facing whoever does have control.

Well considering I made the initial statement, no, it's not. A company I used to work for once hired exclusively from the must-have-Python-experience pool (not my decision) and the cto fawned over how well he solved this "well-known-leetcode problem", and he utterly failed my problem, which tests for actually useful competency... of course he was hired -- and turned out to be a complete lemon. I remember that hiring round distinctly, everyone we interviewed for that position (n~10) was competent for the leetcode problem but never did basic things in my interview like "write tests", "don't try to make a complicated algorithm", etc, even when told explicitly to do/ not to do those things.

Outside of that I interviewed several of my friends (I know them from a non-programming context, so I don't know their competency) who were predominantly python devs, and completely noped out of them for the same reasons (and these were my friends).

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

#275

Post by TheRealKing »

fault1 wrote: post #239
anothernewdude wrote: post #185

Earlier quoted context omitted.

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.

Julia (and Fortran) have a concept called offset arrays where you can basically start on any sort of index: https://github.com/JuliaArrays/OffsetArrays.jl IMHO, one of the biggest advantages of Julia _is_ arrays.

Julia does not have offset arrays. There is an external Julia package that can mimic Fortran's intrinsic behavior (arbitrary start index).

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

#276

Post by TheRealKing »

chaxor wrote: post #155
Tarq0n wrote: post #130

Earlier quoted context omitted.

I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.

I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.

So, one-letter English labels were deemed bad coding-style for decades, but suddenly one-letter Greek labels are good because some X-language (Julia) supports it. Seriously? How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.

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

#277

Post by TheRealKing »

goerz wrote: post #188
joconde wrote: post #183

Earlier quoted context omitted.

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…

How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.

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

#278

Post by medo-bear »

ChrisRackauckas wrote: post #266
lukego wrote: post #264

Earlier quoted context omitted.

This is a binary view of development-verses-production. I appreciate languages that treat this as a continuum and let me make my own trade-offs. Common Lisp, Smalltalk, and Erlang all treat the process as running indefinitely. This gives those languages a certain something special. I was hoping to find the same thing in Julia. It's not there. It seems like a significant missed opportunity to me. These dismissive comm…

We legally cannot do things like say live code change the production system underlying the analysis of ongoing clinical trials without going through the whole software development lifecycle required by the FDA (I.e. the Pumas example again), so even if it did exist all a lot of the production systems we're running legally couldn't use it. But also, you can do it with Revise+RuntimeGeneratedFunctions, obviously that s…

but you can adhere to legal requirements and go through all the code and test reviews and still have live update capability. i don't see why they are exclusive. moreover, there are scenarios where taking the system off-line for an update would cause a critical failure

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

#279

Post by fault1 »

TheRealKing wrote: post #275
fault1 wrote: post #239

Earlier quoted context omitted.

Julia (and Fortran) have a concept called offset arrays where you can basically start on any sort of index: https://github.com/JuliaArrays/OffsetArrays.jl IMHO, one of the biggest advantages of Julia _is_ arrays.

Julia does not have offset arrays. There is an external Julia package that can mimic Fortran's intrinsic behavior (arbitrary start index).

julia's package manager is quite modern (and very well designed relative to the mess that is either C++ or python, no experience in modern fortran for me), so something being external or in the core language is not as important as it is with other languages. this is also the same model as in for example, Rust or Javascript.

in fact, it appears to me that they intentionally made the core language with fewer amounts of intrinsics relative to other languages.

Many of the packages in JuliaArrays/ might as well as be in the core language, especially things like StaticArrays: https://github.com/orgs/JuliaArrays/repositories

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

#280

Post by fault1 »

TheRealKing wrote: post #276
chaxor wrote: post #155

Earlier quoted context omitted.

I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.

So, one-letter English labels were deemed bad coding-style for decades, but suddenly one-letter Greek labels are good because some X-language (Julia) supports it. Seriously? How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.

well, you can always program in wenyan: https://github.com/wenyan-lang/wenyan

But seriously, it's 2021. We are no longer slave to ASCII, or even English.

Most of the newer math oriented langs have heavy use of unicode (julia, agda, lean, etc).

Post reply on HN