6 ms·

Cool! I program for around 7 months in Pharo now at Yesplan [0]. We're hiring a devops engineer and a software engineer. While the Pharo website [1] avoids ment

Cool! I program for around 7 months in Pharo now at Yesplan [0]. We're hiring a devops engineer and a software engineer. While the Pharo website [1] avoids mentioning it, it's a Smalltalk descendant. What I like about Pharo: 1. Programming in the debugger makes things feel much quicker 2. Evaluating expressions inside your code editor makes programming feel much quicker 3. The ability to quickly browse classes and methods makes programming feel much quicker (e.g. I type Date somewhere, select it, press CMD+B and now I browse the Date class). Don't get me wrong, Pharo has downsides, especially when it comes to using it in production (IMO). With that said, the language feels fun to use! I definitely like it now as my first language for side projects as it is more graphical, more playful, and feels quicker for iterative development (e.g. when consuming APIs). It's why I wanted to learn it in the first place, it has shown me a different philosophy on how programmers interact with a programming language and IDE. [0] https://yesplan.be/en/vacancies https://yesplan.be/en/vacancies [1] https://pharo.org https://pharo.org

codesnik 4y ago
I always wondered, how do you deploy it? Are you able to use git or other VCS? Are there other developers working on the same image?
- melvinroest 4y ago
  I don't know much about deployment. In terms of version control, we use git. I find it a bit tricky though as there's a git repo inside the Pharo image, and then there's the file based git repo and they need to be kept in sync. I've gotten used to that though, but it's not ideal. Every developer has their own image. It's easy to set up an image (though I always need to check the company docs on how to exactly do it), but then you download your own image. These images can be different from each other as well, as only the code checked in to git is the same.
- deleted 4y ago
  [deleted]
- 0x445442 4y ago
  The image is just an in memory representation of the code. At any point one can export the code representation in the image to an external text file in a number of different formats. These external text files can be version controlled with Git or any other VCS. In turn the the text files can be imported into an image as well. I never worked with Smalltalk professionally but I imagine deployment works in a very similar way to the deployment pipelines you might be used to. Start with a base image, import code pulled from the VCS repo, start the image, run some test verifications and copy the image to its designated virtual insurance host.
  - codesnik 4y ago
    it's not only a code, it's a also current _state_ of the system, no? some kind of root/singleton objects, their instance variables, etc. I mean, for a web application most state should be in a database, but this takes some discipline. And importing updated code to a live system sounds like a black magic. What happens while it's still in progress? Or does one have to start a new process, like we do in other frameworks? Erlang has live updates, but I imagine live update in smalltalk works very differently. So many questions!
    - 0x445442 4y ago
      Yeah, the entire state can be saved off. I was just trying to limit the context of the reply to code WRT VCS. > I mean, for a web application most state should be in a database, but this takes some discipline. This state could also reside in an image and Smalltalk has solutions like GemStone and Magma (OODBMS) solutions. > And importing updated code to a live system sounds like a black magic. Yeah, I don't think for most use cases this would be done. A new image would be built and deployed with the relevant code changes applied.
    - folmar 4y ago
      The short answer is: just try it, you are in for a lot of fun and puzzles. If you have Windows nearby I would recommend Dolphin Smalltalk due to a great system browser. > it's not only a code, it's a also current _state_ of the system There is no difference in Smalltalk. The code includes all the created instances with current field values. > updated code to a live system From the user point of view everything is simple, yet the simplicity is the advantage of the compiler, not the user. If you update the code the instances that you upgrade run the new code, and if you don't upgrade the old objects they run the old code.
- sebastianconcpt 4y ago
  The way I like to deploy a Smalltalk backend service is when developers have their cloned git repos and follow gitflow, one new directory for a new branch, so they can: 1. Build a local image intended to help with 1 branch (branched out of fresh cloned develop). 2. Add changes, unit and system tests for TDD/regression defense/coverage. 3. Commit and push code to share with the teammates. 4. Open PR to develop when ready/PR's approved 5. Eventually merge develop into master and version bump for release 6. The PRs running CI/CD pipelines with the full battery of tests and 7. The final docker image that devops can consume at will for deployment under their load balancer or whatever architecture they had setup. In this style, images generated by work on bugfix or feature branches are optionally disposable after its PR. The dev can choose to archive or not.
O_H_E 4y ago
Hi, do you think you guys would be open to hiring an 8 months paid internship?
noSyncCloud 4y ago
Interesting, thanks. It does mention the Smalltalk influence on the cheat sheet [0], interestingly enough. 0. http://files.pharo.org/media/pharoCheatSheet.pdf http://files.pharo.org/media/pharoCheatSheet.pdf
thedracle 4y ago
AFAIK Pharo is a fork of Squeak, which is much more open about it being a smalltalk programming system implementation. https://squeak.org/ https://squeak.org/
- Qem 4y ago
  Sometimes Pharo is criticized for not displaying more prominently its Smalltalk roots on its site and promotional materials. IMHO, I think the Pharo team has good reason to do so. So far it is mostly compatible with Squeak, but breaking backward compatibility is left on the table as a possibility in the future. So they applied the lesson Perl folks had to learn the hard way, until they perceived it was better to recognize Perl6 as a new language and rename it to Raku. When developing new things, calling them by old names sets expectations and causes people to make lots of implicit assumptions.
  - pjmlp 4y ago
    One example would be support for traits, that original Smalltalk (thus Squeak) never adopted other than the original discussion on the matter.

codesnik 4y ago

I always wondered, how do you deploy it? Are you able to use git or other VCS? Are there other developers working on the same image?

melvinroest 4y ago
I don't know much about deployment. In terms of version control, we use git. I find it a bit tricky though as there's a git repo inside the Pharo image, and then there's the file based git repo and they need to be kept in sync. I've gotten used to that though, but it's not ideal. Every developer has their own image. It's easy to set up an image (though I always need to check the company docs on how to exactly do it), but then you download your own image. These images can be different from each other as well, as only the code checked in to git is the same.
deleted 4y ago
[deleted]
0x445442 4y ago
The image is just an in memory representation of the code. At any point one can export the code representation in the image to an external text file in a number of different formats. These external text files can be version controlled with Git or any other VCS. In turn the the text files can be imported into an image as well. I never worked with Smalltalk professionally but I imagine deployment works in a very similar way to the deployment pipelines you might be used to. Start with a base image, import code pulled from the VCS repo, start the image, run some test verifications and copy the image to its designated virtual insurance host.
- codesnik 4y ago
  it's not only a code, it's a also current _state_ of the system, no? some kind of root/singleton objects, their instance variables, etc. I mean, for a web application most state should be in a database, but this takes some discipline. And importing updated code to a live system sounds like a black magic. What happens while it's still in progress? Or does one have to start a new process, like we do in other frameworks? Erlang has live updates, but I imagine live update in smalltalk works very differently. So many questions!
  - 0x445442 4y ago
    Yeah, the entire state can be saved off. I was just trying to limit the context of the reply to code WRT VCS. > I mean, for a web application most state should be in a database, but this takes some discipline. This state could also reside in an image and Smalltalk has solutions like GemStone and Magma (OODBMS) solutions. > And importing updated code to a live system sounds like a black magic. Yeah, I don't think for most use cases this would be done. A new image would be built and deployed with the relevant code changes applied.
  - folmar 4y ago
    The short answer is: just try it, you are in for a lot of fun and puzzles. If you have Windows nearby I would recommend Dolphin Smalltalk due to a great system browser. > it's not only a code, it's a also current _state_ of the system There is no difference in Smalltalk. The code includes all the created instances with current field values. > updated code to a live system From the user point of view everything is simple, yet the simplicity is the advantage of the compiler, not the user. If you update the code the instances that you upgrade run the new code, and if you don't upgrade the old objects they run the old code.
sebastianconcpt 4y ago
The way I like to deploy a Smalltalk backend service is when developers have their cloned git repos and follow gitflow, one new directory for a new branch, so they can: 1. Build a local image intended to help with 1 branch (branched out of fresh cloned develop). 2. Add changes, unit and system tests for TDD/regression defense/coverage. 3. Commit and push code to share with the teammates. 4. Open PR to develop when ready/PR's approved 5. Eventually merge develop into master and version bump for release 6. The PRs running CI/CD pipelines with the full battery of tests and 7. The final docker image that devops can consume at will for deployment under their load balancer or whatever architecture they had setup. In this style, images generated by work on bugfix or feature branches are optionally disposable after its PR. The dev can choose to archive or not.

O_H_E 4y ago

Hi, do you think you guys would be open to hiring an 8 months paid internship?

noSyncCloud 4y ago

Interesting, thanks. It does mention the Smalltalk influence on the cheat sheet [0], interestingly enough. 0. http://files.pharo.org/media/pharoCheatSheet.pdf http://files.pharo.org/media/pharoCheatSheet.pdf

thedracle 4y ago

AFAIK Pharo is a fork of Squeak, which is much more open about it being a smalltalk programming system implementation. https://squeak.org/ https://squeak.org/

Qem 4y ago
Sometimes Pharo is criticized for not displaying more prominently its Smalltalk roots on its site and promotional materials. IMHO, I think the Pharo team has good reason to do so. So far it is mostly compatible with Squeak, but breaking backward compatibility is left on the table as a possibility in the future. So they applied the lesson Perl folks had to learn the hard way, until they perceived it was better to recognize Perl6 as a new language and rename it to Raku. When developing new things, calling them by old names sets expectations and causes people to make lots of implicit assumptions.
- pjmlp 4y ago
  One example would be support for traits, that original Smalltalk (thus Squeak) never adopted other than the original discussion on the matter.