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

281–290 of 291 posts

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

#281
post #265

Earlier quoted context omitted.

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.

And the two other links?

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

#282
post #188

Earlier quoted context omitted.

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.

If that’s what’s most appropriate for the field you’re working in, sure, why not?

Of course it will limit who will be able to interact with your project, which can be a good thing or a bad thing. For the math-unicode in numerical software, you may not even want someone without at least a minimal math background (enough to understand Greek letters and math symbols) working on the code. Likewise, a project that’s inherently Chinese, where it doesn’t make sense for the users/developers not to know Chinese, should feel absolutely free to use Chinese symbols in their source code.

On the other hand, if you do it gratuitously, you just unnecessarily limit collaboration. I’m ok with that, too, personally: it’s your own foot you’re shooting.

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

#283
post #282

Earlier quoted context omitted.

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

If that’s what’s most appropriate for the field you’re working in, sure, why not? Of course it will limit who will be able to interact with your project, which can be a good thing or a bad thing. For the math-unicode in numerical software, you may not even want someone without at least a minimal math background (enough to understand Greek letters and math symbols) working on the code. Likewise, a project that’s inher…

I also don't see Chinese symbols as fundamentally different from non-english ASCII. It's pretty common for Physics bachelor students to show still naming their variables and write comments in e.g. German (my teaching background). I'll push them to kick that habit pretty quickly and switch to English, but this is no different from them still writing the bachelor thesis in German and then switching to English for the master and PhD: there's nothing really wrong with it, but you won't have any reach within the scientific community if your work is not in English.

There's really nothing wrong with beginners starting out in their own language. Why shouldn't a 14 year old Chinese kid write their first programs using Chinese characters as identifiers? I'd much rather have a language support full Unicode they way Julia does than to force everyone into ASCII.

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

#284

Earlier quoted context omitted.

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

Okay, so then use RuntimeGeneratedFunctions+Revise. Done. Julia can do it, but having a setup so that people can do instant review of changes on the live production system is still a little bizarre and I wouldn't do it even though we could.

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

#285

Earlier quoted context omitted.

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

Okay, so then use RuntimeGeneratedFunctions+Revise. Done. Julia can do it, but having a setup so that people can do instant review of changes on the live production system is still a little bizarre and I wouldn't do it even though we could.

i was just explaining luke's point. i think he was hoping that julia would do more to enable interactive development a la common lisp/smalltalk

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

#286

Earlier quoted context omitted.

Okay, so then use RuntimeGeneratedFunctions+Revise. Done. Julia can do it, but having a setup so that people can do instant review of changes on the live production system is still a little bizarre and I wouldn't do it even though we could.

i was just explaining luke's point. i think he was hoping that julia would do more to enable interactive development a la common lisp/smalltalk

Yeah. This forum doesn't seem like the best place to have the discussion, alas. Maybe the corner of a room at JuliaCon with a few Lisp refugees one day :).

Coming from a Lisp background Julia fits like a glove in the beginning but some aspects, like the inability to redefine structs, I just crash into like a brick wall. It makes it hard to imagine writing (say) a Blender/Paraview type of application in Julia.

I suppose that Julia is heavily influenced by Scheme and Dylan but not especially by Common Lisp (or Smalltalk) where the idea of being unable to redefine types at runtime is jarring.

I wonder if Julia advocates would do better to just acknowledge that this point of view exists, even if experience with Julia might change it over time, rather than dismissing it (yes, very much so) as empty "fuss." But there aren't that many Lisp/Smalltalk hackers in the world so you can probably afford to alienate them if you want to...

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

#287
post #286

Earlier quoted context omitted.

i was just explaining luke's point. i think he was hoping that julia would do more to enable interactive development a la common lisp/smalltalk

Yeah. This forum doesn't seem like the best place to have the discussion, alas. Maybe the corner of a room at JuliaCon with a few Lisp refugees one day :). Coming from a Lisp background Julia fits like a glove in the beginning but some aspects, like the inability to redefine structs, I just crash into like a brick wall. It makes it hard to imagine writing (say) a Blender/Paraview type of application in Julia. I suppo…

It's acknowledged. The full redefinition of any function in any context was solved by RuntimeGeneratedFunctions and we use it extensively throughout SciML, ModelingToolkit, Pumas, etc. so it's fair to say struct redefinitions are the only thing left. That said, "struct redefinitions" are done all of the time in many contexts: if you know you may need to do this, you can just use a named tuple which acts just like an anonymous type and obeys dispatch on a named form that you can then hijack at runtime. With smart engineering then you can be redefining everything on the fly, and we do this through MTK quite regularly. That said, it would be nice to do the last feat of full redefinition of non-anonymous structs, and the latest proposal for how to do struct redefinition is https://github.com/JuliaLang/julia/issues/40399. So we both built and provided solutions for how to do it, showed how to do it in libraries, tutorials, videos, etc. How is that not acknowledging the point of view and doing something about it?

You might want to try and acknowledge the other point of view where I note that, hey, we did make this work but it was a smaller deal then we thought because we legally cannot employ it in many production contexts. We're still going to work out a few details for fun and ease of debugging, but given that we have extensively looked into and thought deeply about the whole issue, we have noticed that the last little bits are less useful than we had thought (at least in the contexts and applications I have been discussing, like clinical trial analysis). That doesn't mean we won't finish the last pieces, but given how much of it you can already do and how many teaching materials show how to do work around the issues in any real-world context, and how little of a real-world application the last few bits have, it shouldn't be surprising that the last pieces haven't been a huge priority. So instead of looking narrowly at one factor, I encourage you to take a more global view.

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

#288
post #286

Earlier quoted context omitted.

Yeah. This forum doesn't seem like the best place to have the discussion, alas. Maybe the corner of a room at JuliaCon with a few Lisp refugees one day :). Coming from a Lisp background Julia fits like a glove in the beginning but some aspects, like the inability to redefine structs, I just crash into like a brick wall. It makes it hard to imagine writing (say) a Blender/Paraview type of application in Julia. I suppo…

It's acknowledged. The full redefinition of any function in any context was solved by RuntimeGeneratedFunctions and we use it extensively throughout SciML, ModelingToolkit, Pumas, etc. so it's fair to say struct redefinitions are the only thing left. That said, "struct redefinitions" are done all of the time in many contexts: if you know you may need to do this, you can just use a named tuple which acts just like an…

I'll concede that there seems to be a lot of work done on this in Julia that I'm not aware of. Thank you for the references, I'll check them out and then gladly concede the rest the next time this topic comes up.

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

#289
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.

One-letter variables aren't always bad coding style. Some single letters are meaningful. It's conventional to use 'i' for an array iterator, for instance - or i and j for two dimensional iteration. x,y, and z are cartesian coordinates. It would be downright perverse not to call the base of the natural logarithm 'e'.

And so it is with greek letters. Many of them carry intrinsic meaning, or a loose collection of related meanings - they effectively are labels. It's not that people want to write dense and impenetrable code, it's that they would rather write μ than coefficient_of_friction because that is its proper name and how it appears in formulas and textbooks.

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

#290
post #281

Earlier quoted context omitted.

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

And the two other links?

I don't know why I didn't see them. I read through the docs with Genie; it seems to be about where Django was 12 years ago as far as feature development goes. Enough to be very productive for some use cases, not sufficiently productive to consider it a step up from the existing tech that's out there.
Post reply on HN