4 ms·

I believe many posts here miss the core point. The article is talking about _liveness_, i.e. modifying the program while it is running. One example of this woul

I believe many posts here miss the core point. The article is talking about _liveness_, i.e. modifying the program while it is running. One example of this would be Squeak[1]. Another perhaps more relatable one is modifying your HTML5 app from the browser console. [1]: https://squeak.org/ https://squeak.org/

mhd 7y ago
Yes, it seems most of the posters are mostly familiar with the JS build … situation, where the last addendum of the post regarding multiple languages would apply anyway (as you're often building JS, HTML and CSS in one fell swoop). Modfiying web apps from the browser seems to be a rare case, interestingly. I think there were a forays[1] made in that direction, but the need for external tools to shoe-horn a half-shod module system onto JS was the final straw for that. Never mind the convenience of some nigh-essential language features (SCSS, ES6). [1]: https://www.amber-lang.net/ https://www.amber-lang.net/
dbmikus 7y ago
In Smalltalk, does anyone actually modify the production application live? I would think you'd want to modify the live application in devel, and then copy it over. At this point, you can either copy over the difference or just replace the whole production application. I'm not sure which would be faster. I don't think liveness is important for a production system. I prefer production to evolve in discrete chunks. Liveness makes sense for development. I suppose one other benefit of a live system is that you could deploy an update without without restarting the application. But at some level, you would be restarting part of the application, and you are just shifting the update logic from the networking layer to the function call layer or object layer or whatever minimal layer of swappable component you can deploy.
- Kinrany 7y ago
  I barely touched Smalltalk, but I think people value liveness as a feature for the user, not the developer. This is basically ultimate customization: you can change the source code of your local copy.
  - iainmerrick 7y ago
    I think blurring the distinction between users and programmers is a big part of the SmallTalk philosophy, yeah.
  - theamk 7y ago
    That sounds insane -- how do versions updates work then? One of the best parts of only allowing customization at well-defined points is that you can upgrade software and it is likely to keep working. Or is the Smalltalk idea that you never update your software?
    - Kinrany 7y ago
      You could integrate version control into the app and rebase the customizations onto the upstream changes. At worst the user would have to rewrite their code from time to time.
zelly 7y ago
It's most useful in design. Honestly it's not that useful otherwise and just kills attention span in my experience. Basically we went from doing design WYSIWYG-style to completely in markup languages and CSS. So hot reload bridges the gap.
7777fps 7y ago
Another example is running SQL commands directly against a live database, which is frequently given as advice of something that should never be done. So why should I get excited about the ability to live edit when it's held up as bad practice in one of the few areas it's possible.
cjfd 7y ago
There are other ways to get liveness, though. You could make it such that multiple instances of the program can run and make, e.g., sure that new logins go to the new one. Once the last login has disappeared from the old program it can be shut down. As many comments note, the proposal of this post seems a disaster regarding reliablity/predictability.

mhd 7y ago

Yes, it seems most of the posters are mostly familiar with the JS build … situation, where the last addendum of the post regarding multiple languages would apply anyway (as you're often building JS, HTML and CSS in one fell swoop). Modfiying web apps from the browser seems to be a rare case, interestingly. I think there were a forays[1] made in that direction, but the need for external tools to shoe-horn a half-shod module system onto JS was the final straw for that. Never mind the convenience of some nigh-essential language features (SCSS, ES6). [1]: https://www.amber-lang.net/ https://www.amber-lang.net/

dbmikus 7y ago

In Smalltalk, does anyone actually modify the production application live? I would think you'd want to modify the live application in devel, and then copy it over. At this point, you can either copy over the difference or just replace the whole production application. I'm not sure which would be faster. I don't think liveness is important for a production system. I prefer production to evolve in discrete chunks. Liveness makes sense for development. I suppose one other benefit of a live system is that you could deploy an update without without restarting the application. But at some level, you would be restarting part of the application, and you are just shifting the update logic from the networking layer to the function call layer or object layer or whatever minimal layer of swappable component you can deploy.

Kinrany 7y ago
I barely touched Smalltalk, but I think people value liveness as a feature for the user, not the developer. This is basically ultimate customization: you can change the source code of your local copy.
- iainmerrick 7y ago
  I think blurring the distinction between users and programmers is a big part of the SmallTalk philosophy, yeah.
- theamk 7y ago
  That sounds insane -- how do versions updates work then? One of the best parts of only allowing customization at well-defined points is that you can upgrade software and it is likely to keep working. Or is the Smalltalk idea that you never update your software?
  - Kinrany 7y ago
    You could integrate version control into the app and rebase the customizations onto the upstream changes. At worst the user would have to rewrite their code from time to time.

zelly 7y ago

It's most useful in design. Honestly it's not that useful otherwise and just kills attention span in my experience. Basically we went from doing design WYSIWYG-style to completely in markup languages and CSS. So hot reload bridges the gap.

7777fps 7y ago

Another example is running SQL commands directly against a live database, which is frequently given as advice of something that should never be done. So why should I get excited about the ability to live edit when it's held up as bad practice in one of the few areas it's possible.

cjfd 7y ago

There are other ways to get liveness, though. You could make it such that multiple instances of the program can run and make, e.g., sure that new logins go to the new one. Once the last login has disappeared from the old program it can be shut down. As many comments note, the proposal of this post seems a disaster regarding reliablity/predictability.