4 ms·

As much as I like live-coding languages/runtimes (lisp, smalltalk, goal, etc.), i've been hearing how the system admins, site reliability engineers, package mai

by malkia 11y ago

As much as I like live-coding languages/runtimes (lisp, smalltalk, goal, etc.), i've been hearing how the system admins, site reliability engineers, package maintainers, etc. would hate them because there is no reproducible environment for example. They much better restart the whole app, process, os, etc.

secstate 11y ago
The key here is "would" hate them. In practice, running a Pharo app as a web service is actually infinitely easier to reproduce because of imaging. Try producing a running image of a Python or Ruby web app. And I say this a committed Python web developer. Package management sucks, which is why NixOS and Docker are trying to solve the issue, albeit in different ways.
estebanlor 11y ago
quite the opposite: you can think on a pharo application as your own virtual system (think docker, but at the level of the development environment). For a sysadmin installing and running an app is as easy as saying: curl get.pharo.org | bash ./pharo Pharo.image config URL PROJECT VERSION ./pharo Pharo.image http --start 8080 then they can reproduce last line as much as they want: ./pharo Pharo.image http --start 8081 ./pharo Pharo.image http --start 8082 etc.
- 616c 11y ago
  > curl get.pharo.org | bash I know this is not the point of your argument. I agree with it in fact. But there is no sysadmin in the world that I have met who would not wig out at that part. This is the difference between me, free-wheeling tinkerer and Linux enthusiast, and sysadmins who build infrastructure for verified systems. You are just proving their point.
- malkia 11y ago
  I don't want to sound picky, but "curl get.pharo.org | bash" is not acceptable for production - First security, and second reproducability, also availability, but I see - this could've been an internally set (intranet) site where this would be accepted. But my point was that if someone has started "./pharo Pharo.image .." on a production service and modified it live, then it'll be a problem (what if you haven't saved, or your changes were not propagated yet to the source version control system?) - also how this would propagate changes to other slave machines running it there too? But it's pretty cool and advanced when developing the system. I'm now stuck a bit with Java/GWT, and I'm glad that there is SuperDevMode which incrementally compiles java->javascript (and few other things). Still its far away from Ctrl+X+E on your block in Lisp.

by malkia 11y ago

secstate 11y ago

The key here is "would" hate them. In practice, running a Pharo app as a web service is actually infinitely easier to reproduce because of imaging. Try producing a running image of a Python or Ruby web app. And I say this a committed Python web developer. Package management sucks, which is why NixOS and Docker are trying to solve the issue, albeit in different ways.

estebanlor 11y ago

quite the opposite: you can think on a pharo application as your own virtual system (think docker, but at the level of the development environment). For a sysadmin installing and running an app is as easy as saying: curl get.pharo.org | bash ./pharo Pharo.image config URL PROJECT VERSION ./pharo Pharo.image http --start 8080 then they can reproduce last line as much as they want: ./pharo Pharo.image http --start 8081 ./pharo Pharo.image http --start 8082 etc.

616c 11y ago
> curl get.pharo.org | bash I know this is not the point of your argument. I agree with it in fact. But there is no sysadmin in the world that I have met who would not wig out at that part. This is the difference between me, free-wheeling tinkerer and Linux enthusiast, and sysadmins who build infrastructure for verified systems. You are just proving their point.
malkia 11y ago
I don't want to sound picky, but "curl get.pharo.org | bash" is not acceptable for production - First security, and second reproducability, also availability, but I see - this could've been an internally set (intranet) site where this would be accepted. But my point was that if someone has started "./pharo Pharo.image .." on a production service and modified it live, then it'll be a problem (what if you haven't saved, or your changes were not propagated yet to the source version control system?) - also how this would propagate changes to other slave machines running it there too? But it's pretty cool and advanced when developing the system. I'm now stuck a bit with Java/GWT, and I'm glad that there is SuperDevMode which incrementally compiles java->javascript (and few other things). Still its far away from Ctrl+X+E on your block in Lisp.