3 ms·

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, S

by lukego 5y ago

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 comments make it sound like you guys might not know what you are missing.

ChrisRackauckas 5y ago
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 solves the mentioned world age issue so I don't see what the fuss is all about? I don't see how offering a solution is dismissive?
- medo-bear 5y ago
  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
  - ChrisRackauckas 5y ago
    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.
    - medo-bear 5y ago
      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
      - lukego 5y ago
        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...
        ChrisRackauckas 5y ago
        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 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.

by lukego 5y ago

ChrisRackauckas 5y ago

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 solves the mentioned world age issue so I don't see what the fuss is all about? I don't see how offering a solution is dismissive?

medo-bear 5y ago
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
- ChrisRackauckas 5y ago
  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.
  - medo-bear 5y ago
    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
    - lukego 5y ago
      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...
      - ChrisRackauckas 5y ago
        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 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.