3 ms·

> Not sure what "an ideal environment" even means, but shells have tons of very nice features. If you haven't, I would encourage you to try Pharo. It's a Small

> Not sure what "an ideal environment" even means, but shells have tons of very nice features. If you haven't, I would encourage you to try Pharo. It's a Smalltalk dialect but you program through what feels like an operating system. The richness in interactivity and feedback is unparalleled. This is what I would consider an "ideal environment." Shells are useful tools, they wouldn't have the ubiquity they do if that weren't true. That being said, there's definitely more interesting and powerful paradigms out there for interacting with an operating system at a lower level.

theamk 3y ago
My years doing hardware development and driver programming in college taught me about the evils and endless frustration of invisible, un-resettable state. "Why did my driver worked the first time but exactly same code fails now? Which of hundreds of hardware registers did I forget to reset _this time_?" Same thoughts appear when I look at Smalltalks... Ok, I can edit any function or variable, including a system one; and the changes would be saved automatically in opaque persistent "image". So if you mess a system function, your whole system is unusable and you have restore from snapshot; and even something as simple as a program which continuously pops up message boxes can make system unusable (and again, require restoring from snapshots). It's like Windows 98 but with no reboot option!
- hresvelgr 3y ago
  I don't see how this would be any different from messing around with a Linux system and slinging off `sudo this` and `sudo that` here and there. Though you do pose a very good point. I've always maintained that version control is not something that should be just for managing software projects. I think it should be a core system feature and potentially a feature of programming languages as well. If backwards compatibility is needed, you should be able to import a module from a particular revision so you can actually delete old code without the nasty ramifications from doing so.
  - theamk 3y ago
    The key is a filesystem, which is giving you a lot of help with disaster recovery. We are so used to it we take it for granted, but those features are real and are are not present in all environments: - Filesystem is distinct from memory, you need explicit action to write to it. This allows programs (or entire systems) to crash and be restarted, in which case all volatile state will be rolled back to (hopefully) good one. This even helps with long-term problems -- for example one of my computers right now has broken VPN that will likely fix itself upon restart. Still, I am hesitant to restart, and I am safely using that very machine to write code, because I am pretty sure that fixing my VPN problems will not damage my code files. - If you working on "foo", the most people will have a directory like ~/project/foo, and all related files will be in that location, and this location has no system files. As long as you keep using common practices, each of your project is easy to separate from other projects or from system files. - You can copy the files any number of times, and because of the directories, the copies will not interfere with the original. If I copy ~/project/foo to ~/project/foo.old, there is no chance that my project in ~/project/foo will suddenly pick up a SomeClass from ~/project/foo.old. - Even if you completely killed your system so that it no longer boots, you can still take the filesystem and mount it on the working system and get your user files off. This is as simple as booting from rescue USB stick, or removing the disk from one PC and putting it into another. And seeing folder structure lets you easily say "this is ~/projects on external drive, this is ~/projects on this machine, and this is how I copy files from one place to another". (There are exceptions to this, nothing will safe you from "rm -rf /" or "dd of=/dev/sda", but most of the system damage is not that blunt) Many of those seem like obvious things that every computer has, but they are not - image based systems, and their approximations (like cellphones, especially older once like Symbian) are missing them.
manofmanysmiles 3y ago
Thank you for pointing out Pharo! My mind is blown, and I can’t sleep!

theamk 3y ago

My years doing hardware development and driver programming in college taught me about the evils and endless frustration of invisible, un-resettable state. "Why did my driver worked the first time but exactly same code fails now? Which of hundreds of hardware registers did I forget to reset _this time_?" Same thoughts appear when I look at Smalltalks... Ok, I can edit any function or variable, including a system one; and the changes would be saved automatically in opaque persistent "image". So if you mess a system function, your whole system is unusable and you have restore from snapshot; and even something as simple as a program which continuously pops up message boxes can make system unusable (and again, require restoring from snapshots). It's like Windows 98 but with no reboot option!

hresvelgr 3y ago
I don't see how this would be any different from messing around with a Linux system and slinging off `sudo this` and `sudo that` here and there. Though you do pose a very good point. I've always maintained that version control is not something that should be just for managing software projects. I think it should be a core system feature and potentially a feature of programming languages as well. If backwards compatibility is needed, you should be able to import a module from a particular revision so you can actually delete old code without the nasty ramifications from doing so.
- theamk 3y ago
  The key is a filesystem, which is giving you a lot of help with disaster recovery. We are so used to it we take it for granted, but those features are real and are are not present in all environments: - Filesystem is distinct from memory, you need explicit action to write to it. This allows programs (or entire systems) to crash and be restarted, in which case all volatile state will be rolled back to (hopefully) good one. This even helps with long-term problems -- for example one of my computers right now has broken VPN that will likely fix itself upon restart. Still, I am hesitant to restart, and I am safely using that very machine to write code, because I am pretty sure that fixing my VPN problems will not damage my code files. - If you working on "foo", the most people will have a directory like ~/project/foo, and all related files will be in that location, and this location has no system files. As long as you keep using common practices, each of your project is easy to separate from other projects or from system files. - You can copy the files any number of times, and because of the directories, the copies will not interfere with the original. If I copy ~/project/foo to ~/project/foo.old, there is no chance that my project in ~/project/foo will suddenly pick up a SomeClass from ~/project/foo.old. - Even if you completely killed your system so that it no longer boots, you can still take the filesystem and mount it on the working system and get your user files off. This is as simple as booting from rescue USB stick, or removing the disk from one PC and putting it into another. And seeing folder structure lets you easily say "this is ~/projects on external drive, this is ~/projects on this machine, and this is how I copy files from one place to another". (There are exceptions to this, nothing will safe you from "rm -rf /" or "dd of=/dev/sda", but most of the system damage is not that blunt) Many of those seem like obvious things that every computer has, but they are not - image based systems, and their approximations (like cellphones, especially older once like Symbian) are missing them.

manofmanysmiles 3y ago

Thank you for pointing out Pharo! My mind is blown, and I can’t sleep!