3 ms·

The whole point of environments like Pharo is to integrate everything in a single, consitent entity: Emacs knows nothing about your windows manager, your window

The whole point of environments like Pharo is to integrate everything in a single, consitent entity: Emacs knows nothing about your windows manager, your windows manager knows nothing about your Emacs. You can make them cooperate at the cost of learning two languages, and maybe at the cost of making them communicate with the lowest common denominator, ASCII text - which is incredibly inefficient and brittle. Also at the cost of duplication, when you use Emacs (or Vi) and tmux/screen (all of them manage windows). In Pharo, the window manager and the text editor are written in the same language, and making them cooperate is a matter of sending messages, which are function calls and binary data. The text editor is an object that is reused multiple times in the system, and I wouldn't be surprised if the WM could be used to manage windows inside windows. In other words, the efforts you put in Pharo are much more easily leveraged than those you put in multiple tools. The downside, of course, is that you have much less choices than with Linux ecosystem.

AceJohnny2 12y ago
I understand the benefits of such an integrated environment, however I'm just not ready to accept the deal of "leave all your earthly possessions behind to join us in paradise" that these environments demand. As I understand it, these environments are self-contained, in a "separate universe" kind of way. No thanks, I want my apps and services to be deployable to the rest of the world, and I want (some of) the rest of the world's apps to be usable in my environment, which isn't the case here. Sure, Pharo et. al. running in their own kind of VM alongside the rest of the OS is a compromise to address this very problem[1], but like I said in my previous comment, after seeing Scratch, Croquet, and now Pharo rise up and then fizzle in the wider world I ask: what's the point? Where does it fit in today's development world? Is the goal to build a new, clean but segregated OS/environment entirely separate from the existing ecosystem, or is it to provide a development environment that can be used to create applications that are deployable to existing platforms? If it's the former, I raise my beer, say good luck and on your way. If it's the latter, you've got my interest. The NextStep platform died because it was the former. Luckily it had two important legacies: it was used to create the first World Wide Web server and client. The server was a network application that could interface with the rest of the world. Then NextStep died. It was then resuscitated when it reverse-acquired MacOS and leveraged that platform to transition to MacOSX, thanks to the vision of one singularly-driven man and tens of millions of dollars. What's Pharo's path? [1] if the Smalltalk environments run in a VM inside a widespread OS, I wonder if there have been any modern effort in the opposite direction, to have a Smalltalk environment run on bare hardware?
- agumonkey 12y ago
  Makes me think about the conceptual split between OS and languages, and how much it's needed. About bare metal language hosting, http://www.openmirage.org/ http://www.openmirage.org/ comes to mind, sure it's not smalltalk or even a lispos but that's still a big step in bare metal abstraction running.

AceJohnny2 12y ago

I understand the benefits of such an integrated environment, however I'm just not ready to accept the deal of "leave all your earthly possessions behind to join us in paradise" that these environments demand. As I understand it, these environments are self-contained, in a "separate universe" kind of way. No thanks, I want my apps and services to be deployable to the rest of the world, and I want (some of) the rest of the world's apps to be usable in my environment, which isn't the case here. Sure, Pharo et. al. running in their own kind of VM alongside the rest of the OS is a compromise to address this very problem[1], but like I said in my previous comment, after seeing Scratch, Croquet, and now Pharo rise up and then fizzle in the wider world I ask: what's the point? Where does it fit in today's development world? Is the goal to build a new, clean but segregated OS/environment entirely separate from the existing ecosystem, or is it to provide a development environment that can be used to create applications that are deployable to existing platforms? If it's the former, I raise my beer, say good luck and on your way. If it's the latter, you've got my interest. The NextStep platform died because it was the former. Luckily it had two important legacies: it was used to create the first World Wide Web server and client. The server was a network application that could interface with the rest of the world. Then NextStep died. It was then resuscitated when it reverse-acquired MacOS and leveraged that platform to transition to MacOSX, thanks to the vision of one singularly-driven man and tens of millions of dollars. What's Pharo's path? [1] if the Smalltalk environments run in a VM inside a widespread OS, I wonder if there have been any modern effort in the opposite direction, to have a Smalltalk environment run on bare hardware?

agumonkey 12y ago
Makes me think about the conceptual split between OS and languages, and how much it's needed. About bare metal language hosting, http://www.openmirage.org/ http://www.openmirage.org/ comes to mind, sure it's not smalltalk or even a lispos but that's still a big step in bare metal abstraction running.