7 ms·

Pharo always looks cute, but does anyone here use it, even for toy stuff?

by zerr 7y ago

dgellow 7y ago
The website has a "Stories" section: http://pharo.org/success http://pharo.org/success Projects screenshots look way better than I expected.
armagon 7y ago
"The future is already here – it's just not evenly distributed." - William Gibson I did some work in Smalltalk (working on a mod of Scratch 1.4, which was written in Squeak Smalltalk from the turn of the century). Once you got used to it, it was amazing. The environment is lively, and you can debug into everything. The tech is great; it is just that the community of people who know it is relatively small. If you wanted to develop an open-source project in it, you may have a harder time finding other developers to help. On the other hand, if you wanted to make a cross-platform desktop application that doesn't look native (which, given the prevalence of Electron, doesn't seem to matter too much to people), this would be an excellent choice. I wish I could do more development with Pharo. I also think the web framework Seaside would be fun to work with. http://seaside.st/ http://seaside.st/ We just need to go back in time to twenty years or so and take a different fork ...
- fmakunbound 7y ago
  I also thoroughly enjoy Seaside. There's also https://iliadproject.github.io/ https://iliadproject.github.io/ for another approach.
  - lucas_membrane 7y ago
    Iliad says Latest commit 0be1977 on Jul 18, 2017. Seaside says last commit 24 August 2019. Any actively maintained web framework that will work with Pharo 8?
    - fmakunbound 7y ago
      The mailing list seems active. I think maybe development actually takes place in one of the older version control methods for Pharo.
    - blihp 7y ago
      That is considered active. The Smalltalk community is far smaller than other languages and web development is a small subset of that community. So you won't see nearly the frequency of commits of projects. Also, the major web frameworks are pretty stable these days so most of the action is in the integration of support for various client-side Javascript libraries. Those are often published as separate projects.
    - masukomi 7y ago
      keep in mind that smalltalk is freaking ancient and like most useful but freaking ancient things in unix, most of the stuff "just works" and doesn't need constant poking. Also, Smalltalk offers a much more transparent development environment. So, you're not writing code that goes into a black box and produces results. You can see what's going on in the box and make sure its doing it correctly. also, the Squeak by example book (i think Pharo by example is a fork of this) very quickly starts showing people how to write tests. So the mentality isn't "oh, yeah, i guess i could add tests" it's "oh hey, tests are part of making smalltalk code" so you've got that going for it too. combine those things with the smaller community, and thus a much more narrowly defined set of "needs" for a web framework and yeah, it doesn't get poked constantly. but that's ok.
- Allower 7y ago
  Seems fairly dead, the examples certainly don't work or are missing entirely.
- klez 7y ago
  > On the other hand, if you wanted to make a cross-platform desktop application that doesn't look native (which, given the prevalence of Electron, doesn't seem to matter too much to people), this would be an excellent choice. Yeah, as if people are going to install a whole virtual machine to run a chat application... Wait...
  - protomyth 7y ago
    Yep, it still amazes me how a lot of the criticisms of Smalltalk have been become the new, cool solution. Smalltalk on Electron would be an interesting answer.
    - armagon 7y ago
      That'd be funny. I'm sure you could do it with https://www.amber-lang.net/ https://www.amber-lang.net/ ;-)
      - ethagnawl 7y ago
        I have a short anecdote about Amber, which may or may not be widely known. Amber.js was the original name of Ember.js (so named after the style of beer one of its creators was drinking when they were searching for a name; if memory serves it was also the result of pulling bits and pieces out of SproutCore.js). When it came time to release the project, the authors of A/Ember were notified that they were encroaching on the name of a pre-existing project and changed it.
        masukomi 7y ago
        what bewildered me at the time was that they never did a google search for it before publicizing their chosen name. Or that maybe they did and said "screw it. who cares about smalltalk. we'll steal their name"
  - rbanffy 7y ago
    > Yeah, as if people are going to install a whole virtual machine to run a chat application... You can install an application that launches the VM with the desired image and the user will never know the app is running inside a Smalltalk VM.
- e12e 7y ago
  > if you wanted to make a cross-platform desktop application that doesn't look native I'll just mention that the announcement (which is now down) and the readme mentions spec2: > Spec 2 (preview) - UI building framework with multiple backends The announcement (main hn link) mentioned spec2 and native look together.
fmakunbound 7y ago
Yeah, I use it. It is a highly productive development environment. My daily work is Java, C#/.NET, Angular, React, but when I'm in deep in the zone, in Pharo, developing web applications, those other platforms and tools looks like monkeys throwing turds at each other.
fooblitzky 7y ago
I use it, mostly for toy stuff (work is 80% Java). Once you get used to it, Smalltalk is really the most amazing development environment. It's hard to describe how it feels to work with live objects - it's an incredible speed boost, because instead of grepping logs or stepping through code, you just interact with the objects directly, you can examine the state of instance variables, add new methods, or change code while the code is running. The feedback loop is so short, you get amazing productivity. There's a great video floating around somewhere of someone debugging an Asteroids game while the game is running. From what I've read, the downside is that working on larger programs in a team is challenging. It takes a lot more communication to keep the code base consistent and structured.
- coldtea 7y ago
  >From what I've read, the downside is that working on larger programs in a team is challenging. It takes a lot more communication to keep the code base consistent and structured. I don't think that's an inherent limitation of image based development -- just that the current systems don't offer facilities for syncing etc.
  - fmakunbound 7y ago
    Maybe grandpa already knows, but in Pharo's case, there is Iceberg. It's a Git interface that's included in default Pharo images that understands Pharo's packages, and so on. You can push your stuff to Github etc. and teams can work together that way. I've never worked in a team in a Pharo projects, but I imagine it works well somehow. There's ~75 contributors to the 8.0 release.
- arnsholt 7y ago
  I worked on a large legacy application (in production since 1996) implemented in Smalltalk for a couple of years. I don't feel we had any particular issues keeping the codebase consistent due to Smalltalk itself (there were some issues due to the Smalltalk system's version control system which was pretty terrible), but Smalltalk enabled us to implement new features in the application very smoothly, and debugging issues was simply a joy compared to other systems I've worked in. Finally, we could also fix bugs in the platform itself, which was quite useful since the vendor stopped supporting this particular Smalltalk compiler around 2000; I did a couple of small but quite important fixes like this while working on the project.
echelon 7y ago
I once interviewed a candidate who decided to use Pharo to solve my technical problem. It was an absolute joy to see not only a good approach, but such an interesting and alien language employed to solve it. He got the job. :)
- shobith 7y ago
  Was it an on-site interview? I’m curious how he was able to convince you to install the env.
  - echelon 7y ago
    Yeah, onsite. Remotes are harder in this respect. We give onsite candidates affordances to install any environment that makes them feel comfortable, or to allow them to bring their own machines. The interview machines get wiped on a regular cadence, so installing packages is no big deal. If candidates send us a list of the software they want beforehand, we usually try to set it up for them in advance. If not, it's fine for the schedule to run over a bit for them to tweak things as they like. Interviews are stressful enough. We want everything working in a candidate's favor so they can do their best.
    - shobith 7y ago
      Where do you work?? :D
- _pmf_ 7y ago
  > He got the job. I hope he's now writing CRUD apps in J2EE.
  - rbanffy 7y ago
    Why would you want that to anyone?
  - johnwheeler 7y ago
    EJB 1.0
bjoli 7y ago
Writing small web services in seaside has been like living in the distant future since something like 2006. JavaScript made a lot of strides towards making seaside less impressive in recent years, but as someone who hates frontend stuff I still vastly prefer it. Playing with it in 2006 was like using magic. Sure, it is not REST, but whenever I show it off to someone used to handling a lot of stuff client side they still have to pinch themselves :)
- seandenigris 7y ago
  Cool perspective! FYI there are also REST add-ons now (as well as other more minimal frameworks) for when REST is desired.
Zenchess 7y ago
I always use smalltalk when the problem would allow for it since I'm much more productive in smalltalk than anything else. It's great for certain random tasks - i.e. Want to set up a websocket server for some reason? Program it in smalltalk, test it interactively (literally debugging on execution errors, fixing and resuming execution until it works). If I'm writing a native windows app I'll go with dolphin smalltalk which imo is much nicer to work with and gives you a native gui. I have to say though pharo is getting better all the time and has an active community.
- nundah 7y ago
  Dolphin Smalltalk. Such an underrated tool. Productivity + Windows-native gui. Nothing else like it. The Pharo Spec/2 pales in comparison.
  - rbanffy 7y ago
    IF you are developing a Windows-only application.
    - nundah 7y ago
      Yup, and that is the reason I refused to look at it for so long. And then I went to work for a large corporate where Windows is mandated since forever and will be until eternity. And from my impression most businesses wont touch any other OS for use on desktops. You can of course use Wine/Wineskin and there are guides on how to get this done for Dolphin apps, but I just wont bother for my clients. Not one has ever mentioned compatibility with anything other than Windows 10.
      - rbanffy 7y ago
        > And from my impression most businesses wont touch any other OS for use on desktops. True, but more and more software is delivered using web-based technologies - from desktop apps like Slack to most SaaS offerings.
eitland 7y ago
It is not Pharo but I work with what is possibly (probably?) the largest group of smalltalk programmers in Norway.
blihp 7y ago
I've been using various Smalltalk dialects (Squeak/Cuis/Pharo) for over a decade. I've gone a bit off the deep end and use it for prototyping pretty much everywhere I can. Pharo would be the one Smalltalk environment I would not use for non-toy stuff because it has historically been so unstable. This is at least somewhat by design since the developers have always stated they didn't want to be constrained by backwards compatibility... and they have never let themselves be. It's a great environment for playing around with ideas, not for developing code you expect to work as is a few years from now without some (potentially serious) work. In fairness, all the Squeak dialects have this issue to varying degrees. It just seems to me that it's more extreme with Pharo.
- seandenigris 7y ago
  Due to Pharo/Smalltalk being not just a language, but a language/libraries/IDE, I think it's important to distinguish between API instability (which IHMO is better called evolution) vs. bugginess. API evolution is a core part of Pharo's mission. I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity.
  - alxndr 7y ago
    > I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity. Wow, any chance you've written about the upgrade process?
    - seandenigris 7y ago
      I don't exactly have a playbook. I generally just fix as I go. I try to install the project, fix any errors, run the test, fix the errors, etc. I can say that some version jumps have been almost no work and probably the max time I've spent is an hour to get everything working. It used to be a bit harder, but nowadays Pharo has automatic refactoring for deprecated methods, which helps...
nundah 7y ago
Me. It is my go-to tool to build everything/prototype. It is the most productive tool I know of to get things up and running. There is nothing like it. I also know Python, Lua and various Schemes, but they do not come close. Smalltalk presents the smallest barrier between idea and working code for me. Especially if with the "live in the debugger" type of development where you write a test and get the debugger to tell you the next step. Try it, you might like it.

Pharo always looks cute, but does anyone here use it, even for toy stuff?

by zerr 7y ago

Pharo always looks cute, but does anyone here use it, even for toy stuff?

The website has a "Stories" section: http://pharo.org/success http://pharo.org/success Projects screenshots look way better than I expected.

armagon 7y ago

"The future is already here – it's just not evenly distributed." - William Gibson I did some work in Smalltalk (working on a mod of Scratch 1.4, which was written in Squeak Smalltalk from the turn of the century). Once you got used to it, it was amazing. The environment is lively, and you can debug into everything. The tech is great; it is just that the community of people who know it is relatively small. If you wanted to develop an open-source project in it, you may have a harder time finding other developers to help. On the other hand, if you wanted to make a cross-platform desktop application that doesn't look native (which, given the prevalence of Electron, doesn't seem to matter too much to people), this would be an excellent choice. I wish I could do more development with Pharo. I also think the web framework Seaside would be fun to work with. http://seaside.st/ http://seaside.st/ We just need to go back in time to twenty years or so and take a different fork ...

fmakunbound 7y ago
I also thoroughly enjoy Seaside. There's also https://iliadproject.github.io/ https://iliadproject.github.io/ for another approach.
- lucas_membrane 7y ago
  Iliad says Latest commit 0be1977 on Jul 18, 2017. Seaside says last commit 24 August 2019. Any actively maintained web framework that will work with Pharo 8?
  - fmakunbound 7y ago
    The mailing list seems active. I think maybe development actually takes place in one of the older version control methods for Pharo.
  - blihp 7y ago
    That is considered active. The Smalltalk community is far smaller than other languages and web development is a small subset of that community. So you won't see nearly the frequency of commits of projects. Also, the major web frameworks are pretty stable these days so most of the action is in the integration of support for various client-side Javascript libraries. Those are often published as separate projects.
  - masukomi 7y ago
    keep in mind that smalltalk is freaking ancient and like most useful but freaking ancient things in unix, most of the stuff "just works" and doesn't need constant poking. Also, Smalltalk offers a much more transparent development environment. So, you're not writing code that goes into a black box and produces results. You can see what's going on in the box and make sure its doing it correctly. also, the Squeak by example book (i think Pharo by example is a fork of this) very quickly starts showing people how to write tests. So the mentality isn't "oh, yeah, i guess i could add tests" it's "oh hey, tests are part of making smalltalk code" so you've got that going for it too. combine those things with the smaller community, and thus a much more narrowly defined set of "needs" for a web framework and yeah, it doesn't get poked constantly. but that's ok.
Allower 7y ago
Seems fairly dead, the examples certainly don't work or are missing entirely.
klez 7y ago
> On the other hand, if you wanted to make a cross-platform desktop application that doesn't look native (which, given the prevalence of Electron, doesn't seem to matter too much to people), this would be an excellent choice. Yeah, as if people are going to install a whole virtual machine to run a chat application... Wait...
- protomyth 7y ago
  Yep, it still amazes me how a lot of the criticisms of Smalltalk have been become the new, cool solution. Smalltalk on Electron would be an interesting answer.
  - armagon 7y ago
    That'd be funny. I'm sure you could do it with https://www.amber-lang.net/ https://www.amber-lang.net/ ;-)
    - ethagnawl 7y ago
      I have a short anecdote about Amber, which may or may not be widely known. Amber.js was the original name of Ember.js (so named after the style of beer one of its creators was drinking when they were searching for a name; if memory serves it was also the result of pulling bits and pieces out of SproutCore.js). When it came time to release the project, the authors of A/Ember were notified that they were encroaching on the name of a pre-existing project and changed it.
      - masukomi 7y ago
        what bewildered me at the time was that they never did a google search for it before publicizing their chosen name. Or that maybe they did and said "screw it. who cares about smalltalk. we'll steal their name"
- rbanffy 7y ago
  > Yeah, as if people are going to install a whole virtual machine to run a chat application... You can install an application that launches the VM with the desired image and the user will never know the app is running inside a Smalltalk VM.
e12e 7y ago
> if you wanted to make a cross-platform desktop application that doesn't look native I'll just mention that the announcement (which is now down) and the readme mentions spec2: > Spec 2 (preview) - UI building framework with multiple backends The announcement (main hn link) mentioned spec2 and native look together.

fmakunbound 7y ago

Yeah, I use it. It is a highly productive development environment. My daily work is Java, C#/.NET, Angular, React, but when I'm in deep in the zone, in Pharo, developing web applications, those other platforms and tools looks like monkeys throwing turds at each other.

fooblitzky 7y ago

I use it, mostly for toy stuff (work is 80% Java). Once you get used to it, Smalltalk is really the most amazing development environment. It's hard to describe how it feels to work with live objects - it's an incredible speed boost, because instead of grepping logs or stepping through code, you just interact with the objects directly, you can examine the state of instance variables, add new methods, or change code while the code is running. The feedback loop is so short, you get amazing productivity. There's a great video floating around somewhere of someone debugging an Asteroids game while the game is running. From what I've read, the downside is that working on larger programs in a team is challenging. It takes a lot more communication to keep the code base consistent and structured.

coldtea 7y ago
>From what I've read, the downside is that working on larger programs in a team is challenging. It takes a lot more communication to keep the code base consistent and structured. I don't think that's an inherent limitation of image based development -- just that the current systems don't offer facilities for syncing etc.
- fmakunbound 7y ago
  Maybe grandpa already knows, but in Pharo's case, there is Iceberg. It's a Git interface that's included in default Pharo images that understands Pharo's packages, and so on. You can push your stuff to Github etc. and teams can work together that way. I've never worked in a team in a Pharo projects, but I imagine it works well somehow. There's ~75 contributors to the 8.0 release.
arnsholt 7y ago
I worked on a large legacy application (in production since 1996) implemented in Smalltalk for a couple of years. I don't feel we had any particular issues keeping the codebase consistent due to Smalltalk itself (there were some issues due to the Smalltalk system's version control system which was pretty terrible), but Smalltalk enabled us to implement new features in the application very smoothly, and debugging issues was simply a joy compared to other systems I've worked in. Finally, we could also fix bugs in the platform itself, which was quite useful since the vendor stopped supporting this particular Smalltalk compiler around 2000; I did a couple of small but quite important fixes like this while working on the project.

echelon 7y ago

I once interviewed a candidate who decided to use Pharo to solve my technical problem. It was an absolute joy to see not only a good approach, but such an interesting and alien language employed to solve it. He got the job. :)

shobith 7y ago
Was it an on-site interview? I’m curious how he was able to convince you to install the env.
- echelon 7y ago
  Yeah, onsite. Remotes are harder in this respect. We give onsite candidates affordances to install any environment that makes them feel comfortable, or to allow them to bring their own machines. The interview machines get wiped on a regular cadence, so installing packages is no big deal. If candidates send us a list of the software they want beforehand, we usually try to set it up for them in advance. If not, it's fine for the schedule to run over a bit for them to tweak things as they like. Interviews are stressful enough. We want everything working in a candidate's favor so they can do their best.
  - shobith 7y ago
    Where do you work?? :D
_pmf_ 7y ago
> He got the job. I hope he's now writing CRUD apps in J2EE.
- rbanffy 7y ago
  Why would you want that to anyone?
- johnwheeler 7y ago
  EJB 1.0

bjoli 7y ago

Writing small web services in seaside has been like living in the distant future since something like 2006. JavaScript made a lot of strides towards making seaside less impressive in recent years, but as someone who hates frontend stuff I still vastly prefer it. Playing with it in 2006 was like using magic. Sure, it is not REST, but whenever I show it off to someone used to handling a lot of stuff client side they still have to pinch themselves :)

seandenigris 7y ago
Cool perspective! FYI there are also REST add-ons now (as well as other more minimal frameworks) for when REST is desired.

Zenchess 7y ago

I always use smalltalk when the problem would allow for it since I'm much more productive in smalltalk than anything else. It's great for certain random tasks - i.e. Want to set up a websocket server for some reason? Program it in smalltalk, test it interactively (literally debugging on execution errors, fixing and resuming execution until it works). If I'm writing a native windows app I'll go with dolphin smalltalk which imo is much nicer to work with and gives you a native gui. I have to say though pharo is getting better all the time and has an active community.

nundah 7y ago
Dolphin Smalltalk. Such an underrated tool. Productivity + Windows-native gui. Nothing else like it. The Pharo Spec/2 pales in comparison.
- rbanffy 7y ago
  IF you are developing a Windows-only application.
  - nundah 7y ago
    Yup, and that is the reason I refused to look at it for so long. And then I went to work for a large corporate where Windows is mandated since forever and will be until eternity. And from my impression most businesses wont touch any other OS for use on desktops. You can of course use Wine/Wineskin and there are guides on how to get this done for Dolphin apps, but I just wont bother for my clients. Not one has ever mentioned compatibility with anything other than Windows 10.
    - rbanffy 7y ago
      > And from my impression most businesses wont touch any other OS for use on desktops. True, but more and more software is delivered using web-based technologies - from desktop apps like Slack to most SaaS offerings.

eitland 7y ago

It is not Pharo but I work with what is possibly (probably?) the largest group of smalltalk programmers in Norway.

blihp 7y ago

I've been using various Smalltalk dialects (Squeak/Cuis/Pharo) for over a decade. I've gone a bit off the deep end and use it for prototyping pretty much everywhere I can. Pharo would be the one Smalltalk environment I would not use for non-toy stuff because it has historically been so unstable. This is at least somewhat by design since the developers have always stated they didn't want to be constrained by backwards compatibility... and they have never let themselves be. It's a great environment for playing around with ideas, not for developing code you expect to work as is a few years from now without some (potentially serious) work. In fairness, all the Squeak dialects have this issue to varying degrees. It just seems to me that it's more extreme with Pharo.

seandenigris 7y ago
Due to Pharo/Smalltalk being not just a language, but a language/libraries/IDE, I think it's important to distinguish between API instability (which IHMO is better called evolution) vs. bugginess. API evolution is a core part of Pharo's mission. I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity.
- alxndr 7y ago
  > I've personally upgraded projects from Pharo 1.x all the way to Pharo 7 and have been very willing to trade a small amount of effort porting for big increases in productivity. Wow, any chance you've written about the upgrade process?
  - seandenigris 7y ago
    I don't exactly have a playbook. I generally just fix as I go. I try to install the project, fix any errors, run the test, fix the errors, etc. I can say that some version jumps have been almost no work and probably the max time I've spent is an hour to get everything working. It used to be a bit harder, but nowadays Pharo has automatic refactoring for deprecated methods, which helps...

nundah 7y ago

Me. It is my go-to tool to build everything/prototype. It is the most productive tool I know of to get things up and running. There is nothing like it. I also know Python, Lua and various Schemes, but they do not come close. Smalltalk presents the smallest barrier between idea and working code for me. Especially if with the "live in the debugger" type of development where you write a test and get the debugger to tell you the next step. Try it, you might like it.