5 ms·

Phratch: A port of Scratch on Pharo

32 points by mr_tyzic 12y ago

AceJohnny2 12y ago
Can someone give me a TL;DR on what Pharo is? It's website is infuriatingly vague. It seems to be a visual programming environment based on a language related to Smalltalk? In which case, it's similar to Scratch, and in which case what's the point of porting Scratch to it? Edit: ah, the old Pharo website (accessible through the link at the top), puts front an center "Pharo is a clean, innovative, open-source Smalltalk-inspired environment". OK then. Good job on redesign that loses primary information. /rant
- AceJohnny2 12y ago
  Extra rant: I love the idea of Smalltalk and of reactive environment/IDE (projects like excellent Lighttable try to emulate it), however in the case of Scratch and Pharo this comes at the cost of bootstrapping. You're doing the Bender thing: "fuck your OS and tools, I'll create my own OS and tools! With Blackjack! And hookers!". As a result, it discards all the tools and facilities we've built and are familiar with. I'm using a tiling window manager and I love it. Why should I discard that entirely that to use Pharo's own inferior window manager? I've invested much pain and effort into learning Emacs. Can I bring over no skills from there to your environment? Essentially, the transition cost to these Smalltalk environments (be it Scratch, Croquet, or Pharo) is too high to ever gain critical mass. And that's a shame. Considering how regularly this situation is repeated, I have to ask if it's something inherent to Smalltalk? Or its legacy?
  - taejo 12y ago
    It's not inherent: GNU Smalltalk is "just" another programming language for your Unixy (or Windows) system. From their FAQ: Compared to other Smalltalk implementations, GNU Smalltalk is very different in one aspect: it is pragmatically designed to be a tool rather than an environment. It has a CLI, loads programs from the OS filesystem, etc.
    - vertex-four 12y ago
      Then you miss out on all the awesome reactive IDE stuff.
  - astrobe_ 12y ago
    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?
  - vfclists 12y ago
    You got it wrong actually. Smalltalk is not supposed to integrate with everything. It is everything which is supposed to become Smalltalk based, the desktop/working space, the GUI and the IDE, right down to the OS and the kernel. Smalltalk was not designed to be a programming language. It was intended to be the whole system. I think those developers who are treating and developing Smalltalk only as a programming language and a development environment have got it wrong, although it is the pragmatic thing to do. People who are ignorant of Smalltalk simply don't understand how backward contemporary computing its, relative to the way it should be now, 30 - 40 years after the first implementations. After it emerged, the industry majors simply diverted it way from the original vision of its developers, which was focused on exploring and developing for personal use either recreational or work related, and turned it a development tool costing thousands of dollars. My own interpretation is that the industry majors stifled it, masking the process as bad business and marketing decisions. I mean what could be possibly have been wrong with Smalltalk when the IBM's first Java implementations and IDEs were built with Smalltalk, and Sun bought out the company which developed one the fastest Smalltalk implementations to put their developers into creating Java? I think the current problem with open source Smalltalk is that the developers are spread among different implementations. It would be better if there was one vision and one implementation that they all focused on.
    - seanmcdirmid 12y ago
      > It is everything which is supposed to become Smalltalk based, the desktop/working space, the GUI and the IDE, right down to the OS and the kernel. Correct. This is a strength and a weakness. I was enamored to Smalltalk early on (back in 95 when I learned it in a course) for this very reason. But then the Internet was happening, the world of computing became a lot more heterogeneous, and the idea of a mostly uniform world of computing mostly faded away. > I mean what could be possibly have been wrong with Smalltalk when the IBM's first Java implementations and IDEs were built with Smalltalk It was handy after IBM's acquisition of OTI. > Sun bought out the company which developed one the fastest Smalltalk implementations to put their developers into creating Java? This is inaccurate. Animorphic was bought out for its compiler technology to improve Java; Java was already invented at that point. > It would be better if there was one vision and one implementation that they all focused on. Developers are moving on to new things. There is Dart of course (if we are talking about developers of smalltalk), and Kay's VPRI which are attempting to develop the next best thing.
- vfclists 12y ago
  Pharo is a fork/clean-up of Squeak with a developer oriented focus. Some of the Pharo developers want to distance it from the Smalltalk name/association which they believe may be holding it back. There is/has been a long heated mailing list thread on it. http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-td4756805.html http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-td...

32 points by mr_tyzic 12y ago

Can someone give me a TL;DR on what Pharo is? It's website is infuriatingly vague. It seems to be a visual programming environment based on a language related to Smalltalk? In which case, it's similar to Scratch, and in which case what's the point of porting Scratch to it? Edit: ah, the old Pharo website (accessible through the link at the top), puts front an center "Pharo is a clean, innovative, open-source Smalltalk-inspired environment". OK then. Good job on redesign that loses primary information. /rant

AceJohnny2 12y ago
Extra rant: I love the idea of Smalltalk and of reactive environment/IDE (projects like excellent Lighttable try to emulate it), however in the case of Scratch and Pharo this comes at the cost of bootstrapping. You're doing the Bender thing: "fuck your OS and tools, I'll create my own OS and tools! With Blackjack! And hookers!". As a result, it discards all the tools and facilities we've built and are familiar with. I'm using a tiling window manager and I love it. Why should I discard that entirely that to use Pharo's own inferior window manager? I've invested much pain and effort into learning Emacs. Can I bring over no skills from there to your environment? Essentially, the transition cost to these Smalltalk environments (be it Scratch, Croquet, or Pharo) is too high to ever gain critical mass. And that's a shame. Considering how regularly this situation is repeated, I have to ask if it's something inherent to Smalltalk? Or its legacy?
- taejo 12y ago
  It's not inherent: GNU Smalltalk is "just" another programming language for your Unixy (or Windows) system. From their FAQ: Compared to other Smalltalk implementations, GNU Smalltalk is very different in one aspect: it is pragmatically designed to be a tool rather than an environment. It has a CLI, loads programs from the OS filesystem, etc.
  - vertex-four 12y ago
    Then you miss out on all the awesome reactive IDE stuff.
- astrobe_ 12y ago
  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?
- vfclists 12y ago
  You got it wrong actually. Smalltalk is not supposed to integrate with everything. It is everything which is supposed to become Smalltalk based, the desktop/working space, the GUI and the IDE, right down to the OS and the kernel. Smalltalk was not designed to be a programming language. It was intended to be the whole system. I think those developers who are treating and developing Smalltalk only as a programming language and a development environment have got it wrong, although it is the pragmatic thing to do. People who are ignorant of Smalltalk simply don't understand how backward contemporary computing its, relative to the way it should be now, 30 - 40 years after the first implementations. After it emerged, the industry majors simply diverted it way from the original vision of its developers, which was focused on exploring and developing for personal use either recreational or work related, and turned it a development tool costing thousands of dollars. My own interpretation is that the industry majors stifled it, masking the process as bad business and marketing decisions. I mean what could be possibly have been wrong with Smalltalk when the IBM's first Java implementations and IDEs were built with Smalltalk, and Sun bought out the company which developed one the fastest Smalltalk implementations to put their developers into creating Java? I think the current problem with open source Smalltalk is that the developers are spread among different implementations. It would be better if there was one vision and one implementation that they all focused on.
  - seanmcdirmid 12y ago
    > It is everything which is supposed to become Smalltalk based, the desktop/working space, the GUI and the IDE, right down to the OS and the kernel. Correct. This is a strength and a weakness. I was enamored to Smalltalk early on (back in 95 when I learned it in a course) for this very reason. But then the Internet was happening, the world of computing became a lot more heterogeneous, and the idea of a mostly uniform world of computing mostly faded away. > I mean what could be possibly have been wrong with Smalltalk when the IBM's first Java implementations and IDEs were built with Smalltalk It was handy after IBM's acquisition of OTI. > Sun bought out the company which developed one the fastest Smalltalk implementations to put their developers into creating Java? This is inaccurate. Animorphic was bought out for its compiler technology to improve Java; Java was already invented at that point. > It would be better if there was one vision and one implementation that they all focused on. Developers are moving on to new things. There is Dart of course (if we are talking about developers of smalltalk), and Kay's VPRI which are attempting to develop the next best thing.
vfclists 12y ago
Pharo is a fork/clean-up of Squeak with a developer oriented focus. Some of the Pharo developers want to distance it from the Smalltalk name/association which they believe may be holding it back. There is/has been a long heated mailing list thread on it. http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-td4756805.html http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-td...