4 ms·

Why this and not Squeak/Pharo?

by praptak 14y ago

rjzzleep 14y ago
versioning, code collaboration, and as other people mentioned ecosystem off the top of my head.
- nextputall 14y ago
  What's wrong with monticello? Ecosystem is a valid point, but I don't see problems with collaboration and versioning
  - spooneybarger 14y ago
    Especially with the work that has gone into have a git backend for Monticello.
    - rjzzleep 14y ago
      well as i mentioned above the whole idea behind monticello goes hand in hand with the idea of having to program a/in a vm. you may like the vm/object structure more than a file based structure, but ymmv. not to mention that when we were evaluating squeak a year or so back git was nothing more than a half assed gsoc project. but even so, the fact that you can pipe anything into git one way or another doesn't change the fact that they are conceptually different, but if it does, feel free to correct me.
      - stcredzero 14y ago
        If anything, Monticello and many of the collaboration practices in Smalltalk were intellectual forerunners to git.
        rjzzleep 14y ago
        I thought the frontrunner to git was bitkeeper, which as all the other versioning systems grew out of the experiences from DVS, which i guess refers to what you said, but bitkeeper was built long before monticello. how does git backend for monticello work? does it turn objects into text so they can be versioned in git? if so that's exactly what dvs was doing for cvs.
        spooneybarger 14y ago
        see: http://www.stic.st/conferences/stic12/stic12-abstracts/practical-git-for-smalltalk/ http://www.stic.st/conferences/stic12/stic12-abstracts/pract...
      - igouy 14y ago
        Perhaps you are confusing vm and image?
- flyinRyan 14y ago
  Versioning actually tends to work better in Pharo/Squeak because once you have a version system dedicated to one language you're free to go ahead and understand the syntax of that language. I'm not sure how much of that they take advantage of today but there was talk several years ago of doing things like this.
  - rjzzleep 14y ago
    i think you might be referring to this: http://www.esug.org/wiki/pier/Conferences/2010/Talks/Monticello http://www.esug.org/wiki/pier/Conferences/2010/Talks/Montice... i haven't really watched monticello 2, but last I remember you're essentially merging packages in and out of your vm. it really depends on what your goals are, and I guess the old discussion of visual and non visual programming also applies a little bit to the vm, non vm smalltalk discussion. personally i like to avoid magic whenever i can
spooneybarger 14y ago
because we believe that being on jvm will be smalltalk to a wider audience and over time we can leverage the concurrency libraries, profiling libraries etc etc etc that the jvm has to offer and build a smalltalk for the future. we share the same goals as pharo, just a different idea of how to get there.
- praptak 14y ago
  Makes sense. Have you considered porting Squeak itself to JVM? This would get the JVM benefits, and the similar "take advantage of existing stuff" from the Smalltalk side. Just to be clear: I'm not in any way invested in Squeak or Pharo, just curious about your approach. Well, this and also perhaps a bit skeptical about implementing new stuff when similar stuff exists.
  - spooneybarger 14y ago
    I wrote tool that can export classes from pharo/squeak in the syntax that redline expects. My original idea with this was to aid people who want to develop in Pharo and deploy to redline. In order to make that happen, there would have to be a lot more work done. There have been several discussions about using that tool to export large chunks of pharo and using that as the basis for the redline class library. I personally have tended to resist that (and swayed many people) because it brings along with it a ton of cruft. That said, we all have full time jobs and I'm starting to think that it would be better to start with cruft and remove rather than starting clean and build up. Which side of that I fall on, really varies from day to day. I'm thinking of taking a chunk of pharo and seeing how hard an export of modify would be vs. doing the implementation from scratch. https://github.com/redline-smalltalk/redline-smalltalk/tree/master/extras/pharo/monticello-repo https://github.com/redline-smalltalk/redline-smalltalk/tree/...
  - cwp 14y ago
    Well, Dan Ingalls did something a like that. He implemented a Squeak VM in Java. It's six years old, and even then it didn't run a current Squeak image, but it works pretty well. Announcement here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102191.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-... JAR file here: http://weather-dimensions.com/Dan/SqueakOnJava.jar http://weather-dimensions.com/Dan/SqueakOnJava.jar

Why this and not Squeak/Pharo?

by praptak 14y ago

Why this and not Squeak/Pharo?

rjzzleep 14y ago

versioning, code collaboration, and as other people mentioned ecosystem off the top of my head.

nextputall 14y ago
What's wrong with monticello? Ecosystem is a valid point, but I don't see problems with collaboration and versioning
- spooneybarger 14y ago
  Especially with the work that has gone into have a git backend for Monticello.
  - rjzzleep 14y ago
    well as i mentioned above the whole idea behind monticello goes hand in hand with the idea of having to program a/in a vm. you may like the vm/object structure more than a file based structure, but ymmv. not to mention that when we were evaluating squeak a year or so back git was nothing more than a half assed gsoc project. but even so, the fact that you can pipe anything into git one way or another doesn't change the fact that they are conceptually different, but if it does, feel free to correct me.
    - stcredzero 14y ago
      If anything, Monticello and many of the collaboration practices in Smalltalk were intellectual forerunners to git.
      - rjzzleep 14y ago
        I thought the frontrunner to git was bitkeeper, which as all the other versioning systems grew out of the experiences from DVS, which i guess refers to what you said, but bitkeeper was built long before monticello. how does git backend for monticello work? does it turn objects into text so they can be versioned in git? if so that's exactly what dvs was doing for cvs.
        spooneybarger 14y ago
        see: http://www.stic.st/conferences/stic12/stic12-abstracts/practical-git-for-smalltalk/ http://www.stic.st/conferences/stic12/stic12-abstracts/pract...
    - igouy 14y ago
      Perhaps you are confusing vm and image?
flyinRyan 14y ago
Versioning actually tends to work better in Pharo/Squeak because once you have a version system dedicated to one language you're free to go ahead and understand the syntax of that language. I'm not sure how much of that they take advantage of today but there was talk several years ago of doing things like this.
- rjzzleep 14y ago
  i think you might be referring to this: http://www.esug.org/wiki/pier/Conferences/2010/Talks/Monticello http://www.esug.org/wiki/pier/Conferences/2010/Talks/Montice... i haven't really watched monticello 2, but last I remember you're essentially merging packages in and out of your vm. it really depends on what your goals are, and I guess the old discussion of visual and non visual programming also applies a little bit to the vm, non vm smalltalk discussion. personally i like to avoid magic whenever i can

spooneybarger 14y ago

because we believe that being on jvm will be smalltalk to a wider audience and over time we can leverage the concurrency libraries, profiling libraries etc etc etc that the jvm has to offer and build a smalltalk for the future. we share the same goals as pharo, just a different idea of how to get there.

praptak 14y ago
Makes sense. Have you considered porting Squeak itself to JVM? This would get the JVM benefits, and the similar "take advantage of existing stuff" from the Smalltalk side. Just to be clear: I'm not in any way invested in Squeak or Pharo, just curious about your approach. Well, this and also perhaps a bit skeptical about implementing new stuff when similar stuff exists.
- spooneybarger 14y ago
  I wrote tool that can export classes from pharo/squeak in the syntax that redline expects. My original idea with this was to aid people who want to develop in Pharo and deploy to redline. In order to make that happen, there would have to be a lot more work done. There have been several discussions about using that tool to export large chunks of pharo and using that as the basis for the redline class library. I personally have tended to resist that (and swayed many people) because it brings along with it a ton of cruft. That said, we all have full time jobs and I'm starting to think that it would be better to start with cruft and remove rather than starting clean and build up. Which side of that I fall on, really varies from day to day. I'm thinking of taking a chunk of pharo and seeing how hard an export of modify would be vs. doing the implementation from scratch. https://github.com/redline-smalltalk/redline-smalltalk/tree/master/extras/pharo/monticello-repo https://github.com/redline-smalltalk/redline-smalltalk/tree/...
- cwp 14y ago
  Well, Dan Ingalls did something a like that. He implemented a Squeak VM in Java. It's six years old, and even then it didn't run a current Squeak image, but it works pretty well. Announcement here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102191.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-... JAR file here: http://weather-dimensions.com/Dan/SqueakOnJava.jar http://weather-dimensions.com/Dan/SqueakOnJava.jar