Pharo at Beta Nine(medium.com)
medium.com
Pharo at Beta Nine
https://medium.com/concerning-pharo/pharo-beta-nine-59ee972d321a
8 comments
Silly question, maybe I just can't find the correct keywords to search. Are there any Smalltalks that allow coding/interaction from a text-based console? Maybe line-oriented commands with $EDITOR used for coding? I've wanted to play with these languages for years, but as a blind developer, their inaccessible GUIs thwart me. I'm also a bit confused how they interact with VCSs. Perhaps the answer is obvious when you've played with these environments for a few minutes, but I can't even reach that point. :)
Historically, Smalltalk was used to explore the GUI design space, so a non-GUI Smalltalk is somewhere between anachronistic and oxymoronic.
GNU Smalltalk has an Emacs interface:
http://www.gnu.org/software/smalltalk/manual/html_node/Emacs...
I don't know how accessible Emacs is to you, but it should at least be textual.
GNU Smalltalk also has a REPL:
http://www.gnu.org/software/smalltalk/manual/html_node/Getti...
Now, how does a traditional Smalltalk interact with a VCS? Poorly. Smalltalk was all about image-based persistence, with textual source code not being the primary artifact. Philosophically, it was designed to be an environment, and take over the system from soup to nuts.
GNU Smalltalk, predictably, goes its own way, and allows people to load textual source code files from the command line. It also has a more complicated packaging system:
http://smalltalk.gnu.org/wiki/creating-and-distributing-pack...
GNU Smalltalk has an Emacs interface:
http://www.gnu.org/software/smalltalk/manual/html_node/Emacs...
I don't know how accessible Emacs is to you, but it should at least be textual.
GNU Smalltalk also has a REPL:
http://www.gnu.org/software/smalltalk/manual/html_node/Getti...
Now, how does a traditional Smalltalk interact with a VCS? Poorly. Smalltalk was all about image-based persistence, with textual source code not being the primary artifact. Philosophically, it was designed to be an environment, and take over the system from soup to nuts.
GNU Smalltalk, predictably, goes its own way, and allows people to load textual source code files from the command line. It also has a more complicated packaging system:
http://smalltalk.gnu.org/wiki/creating-and-distributing-pack...
Pharo (and others) can interact without many problems with any file-format VCS using "filetree" (an file based export source format).
There are many of us using it for projects more or less complex (one of them the Pharo VM: https://github.com/pharo-project/pharo-vm). So, while we can improve in that area, we are not agnostic :)
Now, you can do scripting with Pharo too, but using console to edit it is so alien for us that we cannot even understand why someone would want to drop a complete development environment (with some really nice tools), just to use a text editor...
Now, you can do scripting with Pharo too, but using console to edit it is so alien for us that we cannot even understand why someone would want to drop a complete development environment (with some really nice tools), just to use a text editor...
Because the text editor is the nicest development environment. It's been customized by me to my workflow, and your not understanding that says horrible things about how well you understand how programmers work.
Frankly, the fact you don't get this means I can't use your product. It promises to be painful to work in.
Frankly, the fact you don't get this means I can't use your product. It promises to be painful to work in.
My understanding is that GNU Smalltalk is text based. http://smalltalk.gnu.org/ I hope that helps.
Shampoo project (http://dmitrymatveev.co.uk/shampoo/) might be useful. It's an Emacs mode for remote Smalltalk development that support GNU Smalltalk and Pharo.
>The customer does not care what technology is used to build a product.
That is not universally true. For example, the American military used to require the use of Ada. This is no longer the case but I doubt they would buy software built with Pharo.
In the same way big corporations often insist on Java, or at least a JVM-based solution.
That is not universally true. For example, the American military used to require the use of Ada. This is no longer the case but I doubt they would buy software built with Pharo.
In the same way big corporations often insist on Java, or at least a JVM-based solution.
that's because they buy development, not products.
I've worked in some big corporations who enforced Java internally, but they do not care about products they also use (best example is office tools, but I've seen many "business oriented" products developed in other languages: i.e. first versions of rational suite -yes, I'm old- were made also in smalltalk and nobody ever cared about, etc. etc. etc.)
I see people here mentioned GNU Smalltalk. The last time Smalltalk was posted here, some more seasoned people talked me into looking at Smalltalk again.
Now, I am getting more and more into Emacs. I like SBCL a lot, and I have played with it more. But Smalltalk also has an appeal, with similar ideas in live persistence coding. However, I am more comfortable with GNU Smalltalk.
Problem is Pharo has the powerful CogVM. How performant is GNU Smalltalk in relation to Pharo. If I wanted to run the same Seaside infrastructure as these dudes (there is a fork of Seaside included in GNU Smalltalk from the start), would it collapse under loads Pharo's CogVM can handle?
This is just out of curiosity. Obviously this is armchair engineering 101, but I would be interested to know more about this. There is such little interest in Smalltalk at scale it is hard to find this info with limited searching.
Now, I am getting more and more into Emacs. I like SBCL a lot, and I have played with it more. But Smalltalk also has an appeal, with similar ideas in live persistence coding. However, I am more comfortable with GNU Smalltalk.
Problem is Pharo has the powerful CogVM. How performant is GNU Smalltalk in relation to Pharo. If I wanted to run the same Seaside infrastructure as these dudes (there is a fork of Seaside included in GNU Smalltalk from the start), would it collapse under loads Pharo's CogVM can handle?
This is just out of curiosity. Obviously this is armchair engineering 101, but I would be interested to know more about this. There is such little interest in Smalltalk at scale it is hard to find this info with limited searching.
Don't use Gnu Smalltalk, it is a huge disservice to Smalltalk. The main selling point of Pharo/Squeak is that it is a live interactive developing experience. You don't get that with GNU Smalltalk.
People could actually prefer the text editing compared to live interactive delopment. Smalltalk is good enough language to not need that to be interesting in itself.
GNU Smalltalk actually allows me to use a good development environment. Other Smalltalks apparently don't.
Does that really answer my question?
There is talk here of Shampoo, which allows Emacs to do many of the things you suggest within a textual environment like Emacs.
I understand you have your preference (and I know your name comes up with Pharo on the net; I have seen it before and I can tell you are active in the community, so I say this out of respect), but I just wanted to try something I am more comfortable with to ease my transition.
There is talk here of Shampoo, which allows Emacs to do many of the things you suggest within a textual environment like Emacs.
I understand you have your preference (and I know your name comes up with Pharo on the net; I have seen it before and I can tell you are active in the community, so I say this out of respect), but I just wanted to try something I am more comfortable with to ease my transition.
As much as I like live-coding languages/runtimes (lisp, smalltalk, goal, etc.), i've been hearing how the system admins, site reliability engineers, package maintainers, etc. would hate them because there is no reproducible environment for example. They much better restart the whole app, process, os, etc.
The key here is "would" hate them. In practice, running a Pharo app as a web service is actually infinitely easier to reproduce because of imaging. Try producing a running image of a Python or Ruby web app. And I say this a committed Python web developer. Package management sucks, which is why NixOS and Docker are trying to solve the issue, albeit in different ways.
quite the opposite: you can think on a pharo application as your own virtual system (think docker, but at the level of the development environment). For a sysadmin installing and running an app is as easy as saying:
curl get.pharo.org | bash
./pharo Pharo.image config URL PROJECT VERSION
./pharo Pharo.image http --start 8080
then they can reproduce last line as much as they want:
./pharo Pharo.image http --start 8081
./pharo Pharo.image http --start 8082
etc.
curl get.pharo.org | bash
./pharo Pharo.image config URL PROJECT VERSION
./pharo Pharo.image http --start 8080
then they can reproduce last line as much as they want:
./pharo Pharo.image http --start 8081
./pharo Pharo.image http --start 8082
etc.
I don't want to sound picky, but "curl get.pharo.org | bash" is not acceptable for production - First security, and second reproducability, also availability, but I see - this could've been an internally set (intranet) site where this would be accepted.
But my point was that if someone has started "./pharo Pharo.image .." on a production service and modified it live, then it'll be a problem (what if you haven't saved, or your changes were not propagated yet to the source version control system?) - also how this would propagate changes to other slave machines running it there too?
But it's pretty cool and advanced when developing the system. I'm now stuck a bit with Java/GWT, and I'm glad that there is SuperDevMode which incrementally compiles java->javascript (and few other things). Still its far away from Ctrl+X+E on your block in Lisp.
But my point was that if someone has started "./pharo Pharo.image .." on a production service and modified it live, then it'll be a problem (what if you haven't saved, or your changes were not propagated yet to the source version control system?) - also how this would propagate changes to other slave machines running it there too?
But it's pretty cool and advanced when developing the system. I'm now stuck a bit with Java/GWT, and I'm glad that there is SuperDevMode which incrementally compiles java->javascript (and few other things). Still its far away from Ctrl+X+E on your block in Lisp.
> curl get.pharo.org | bash
I know this is not the point of your argument. I agree with it in fact.
But there is no sysadmin in the world that I have met who would not wig out at that part. This is the difference between me, free-wheeling tinkerer and Linux enthusiast, and sysadmins who build infrastructure for verified systems. You are just proving their point.
I know this is not the point of your argument. I agree with it in fact.
But there is no sysadmin in the world that I have met who would not wig out at that part. This is the difference between me, free-wheeling tinkerer and Linux enthusiast, and sysadmins who build infrastructure for verified systems. You are just proving their point.
[deleted]
Can anybody here point me to some documentation on the Squeak/Cog/Pharo etc image file format? "read the source" is pretty useless when the source is scattered around various Monticello repositories, which never seem to work for me thanks to the Smalltalk community's epic linkrot.
If you want to give back to Pharo in a way that counts, fund improvements to the UI. The font rendering is bad right now and HiDPI screens are not even supported. This makes for a terrible first impression.
Pharo is an amazing environment and it is good to see companies deploying commercial web services using it. I mostly use Pharo for NLP.
edit: I just realized that the author of this article is the author of several Pharo libraries that I depend on. Thanks!