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.
PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
281–290 of 291 posts
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#282Earlier 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.
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)
#283Earlier 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…
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)
#284Earlier 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
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#285Earlier 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.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#286Earlier 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
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)
#287Earlier 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…
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)
#288Earlier 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…
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#289Earlier 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.
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)
#290Earlier quoted context omitted.
A notebook doesn't make for a line-of-business web app.
And the two other links?