3 ms·

"The problem with driving a car is that you lose almost all the skills you obtained by driving a horse carriage". Yes, the image interop part is a bit more dif

by groby_b 14y ago

"The problem with driving a car is that you lose almost all the skills you obtained by driving a horse carriage". Yes, the image interop part is a bit more difficult to solve. I'm not saying it's exactly like the switch from carriage to car, but I'm saying that some changes are worth losing existing skills

btilly 14y ago
Consider that image-based environments have been losing ground to file-system based ones for years. Consider also that core ideas that make image-based environments good can be separated from the image-based system and moved into non-image based systems. Two examples that I would give for Smalltalk are Ruby's borrowing of Smalltalks OO model, and various IDEs borrowing the idea of a refactoring browser. Borrowing the other way is much harder. For instance consider the distributed version control patterns that git enables. Image-based software development communities are sufficiently small and fragmented that they are unlikely to all duplicate the functionality of git. And because of the internal differences, they each would have to reinvent it. By contrast once git became available, it was immediately available for use with C++, Java, Python, JavaScript, Haskell... There are advantages to image-based environments, but do they outweigh the disadvantages? Before concluding that they do, you might want to re-read Worse Is Better.
- hermanhermitage 14y ago
  Good points. A possible approach is to consider the file system the image - consider a UI for managing a VM image and processes within that image. The difference is then essentially deciding what is the center of the system. The older image based language systems assume they are the center and all must pass through them - like a monolithic kernel. Perhaps what could be explored is more transparent integration between language runtimes and file system objects.
  - DeepDuh 14y ago
    I think you hit the nail on the head. Build systems like GNU Make pull information about the file system to find out what has been updated. All we basically have to do is to 1) move from an information pull to a push. (Sidenote: This is something that 'kind of' works in OSX GUI, although it seems to me that 10.7 has broken this functionality for certain usecases. E.g. I'm connected to my host mac with my linux vm through SSH and when I've updated a file from within that VM, the host Finder windows get updated automatically and Preview.app windows get updated when I click into them). 2) Extend the functionality to runtimes as well, i.e. enable hotloading like in the new Unreal engine.

by groby_b 14y ago

btilly 14y ago

Consider that image-based environments have been losing ground to file-system based ones for years. Consider also that core ideas that make image-based environments good can be separated from the image-based system and moved into non-image based systems. Two examples that I would give for Smalltalk are Ruby's borrowing of Smalltalks OO model, and various IDEs borrowing the idea of a refactoring browser. Borrowing the other way is much harder. For instance consider the distributed version control patterns that git enables. Image-based software development communities are sufficiently small and fragmented that they are unlikely to all duplicate the functionality of git. And because of the internal differences, they each would have to reinvent it. By contrast once git became available, it was immediately available for use with C++, Java, Python, JavaScript, Haskell... There are advantages to image-based environments, but do they outweigh the disadvantages? Before concluding that they do, you might want to re-read Worse Is Better.

hermanhermitage 14y ago
Good points. A possible approach is to consider the file system the image - consider a UI for managing a VM image and processes within that image. The difference is then essentially deciding what is the center of the system. The older image based language systems assume they are the center and all must pass through them - like a monolithic kernel. Perhaps what could be explored is more transparent integration between language runtimes and file system objects.
- DeepDuh 14y ago
  I think you hit the nail on the head. Build systems like GNU Make pull information about the file system to find out what has been updated. All we basically have to do is to 1) move from an information pull to a push. (Sidenote: This is something that 'kind of' works in OSX GUI, although it seems to me that 10.7 has broken this functionality for certain usecases. E.g. I'm connected to my host mac with my linux vm through SSH and when I've updated a file from within that VM, the host Finder windows get updated automatically and Preview.app windows get updated when I click into them). 2) Extend the functionality to runtimes as well, i.e. enable hotloading like in the new Unreal engine.