
Pharo at Beta Nine - andrewl
https://medium.com/concerning-pharo/pharo-beta-nine-59ee972d321a
======
mark_l_watson
Nice applications using Pharo Smalltalk!

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!

------
ndarilek
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. :)

~~~
cbd1984
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...](http://www.gnu.org/software/smalltalk/manual/html_node/Emacs.html)

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...](http://www.gnu.org/software/smalltalk/manual/html_node/Getting-
started.html#Getting-started)

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...](http://smalltalk.gnu.org/wiki/creating-and-distributing-packages)

~~~
estebanlor
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](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...

~~~
cbd1984
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.

------
copx
>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.

~~~
estebanlor
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.)

------
616c
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.

~~~
PuercoPop
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.

~~~
616c
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.

------
malkia
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.

~~~
estebanlor
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.

~~~
malkia
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.

------
Sophistifunk
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.

------
latiera
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.

