
Can This Man Spark a Renaissance for the Smalltalk Programming Language? - nathanjames
https://thenewstack.io/can-man-spark-renaissance-smalltalk-programming-language/
======
theamk
> Once inured to the clumsy use of files and folders and lifeless, non-dynamic
> programming methods, once they grow emotionally and intellectually attached
> to their file-based tools and infrastructure, they are incapable of
> appreciating any other way to do things.

What bugs me about smalltalk advocacy is the complete dismissal of the
existing files-based tools. Even the simple version control for the personal
use (log, diff and revert) is worth keeping the files for. And I cannot
imagine how would I do multi-user version control, code reviews, sharing
libraries between projects if all I have is a single "image".

~~~
horrido
Being shackled to existing file-based tools holds you back from improving the
software development process. In the past several decades, we've seen
incremental improvements but nothing really earth-shattering. Do you really
believe we'll still be using file-based tools for software development 50 or
100 years from now? Smalltalk is the future of software development created 45
years in the past. See [https://medium.com/smalltalk-talk/smalltalk-and-the-
future-o...](https://medium.com/smalltalk-talk/smalltalk-and-the-future-of-
the-software-industry-3f69cac13e5a).

~~~
theamk
Well, don't speak about abstract 'shackles', show me the improved process! I
am especially interested in version control and collaboration. IMHO, existing
file-based tools have had quite a few advances on this front:

* Tests are now common and considered a good thing. A new contributor can write code without worrying about breaking rarely-used functionality.

* Many languages have package managers. Using latest third-party library is now simple

* We have great deployment mechanisms -- one-command deployments are common, containers and version pinning help reproducibility.

* Some languages come with support for interactive REPL -- you can evaluate arbitrary commands inside running processes.

* Many languages support static checking -- a lot of errors could be caught even if the code is never exercised

* Many languages need no compilation at all -- just edit the file and run it

What can smalltalk offer? Obviously it has great REPL. Anything else? What is
the cool new 'software development process' feature that you are referring to?

For example, I have found exactly one sentence about version control and
sharing in the article you have linked: "We may even see Pharo 7, which
promises a Git-integration tool called Iceberg for source code version
control." . Is this what you wanted to show me? Because my takeaway is that
the only way to work on Smalltalk software as a team is to use file-based
tools (git). I see no improvements in software development process here.

The other commenter mentioned Monticello and Smalltalk Hub. Ok, this looks
like a decent version control system. It is interesting how without files, you
have to add a prefix to a name of every class and tag each function which you
want checked in. Still, I could not find which features it has that git does
not.

~~~
nathanjames
The improved process is not in how it can emulate the way you've done things
for decades with file-based tools. It's in the conceptual nature of
programming, as well-explained by Bret Victor:
[https://youtu.be/8pTEmbeENF4](https://youtu.be/8pTEmbeENF4)

\- Software development using files and folders is absolutely antediluvian.
Smalltalk does everything in a universe of objects; source code is organized
_spatially_ rather than in long reams residing in text files.

\- Live coding and debugging _done right_ is an enormous and unparalleled
productivity booster.

\- Persisting execution state is extremely convenient for maintaining
continuity, and hence the high velocity of development.

Governments and enterprises have long used Smalltalk to write massive
applications in large team environments _using Smalltalk 's own tooling_ for
collaboration and version control. There's no question that historically
Smalltalk has not played well with the outside (file-based) world, and this
has been a major point of contention.

If you insist on using Git and similar tools with Smalltalk, then yes, this is
problematic. The point is, if you view software development from only one
perspective, you deny any possibility of improving the process in other ways
that can lead to dramatically improved productivity, accelerated development,
and lowered cognitive stress.

~~~
theamk
Sorry, I am at work right now and don't have time to watch videos. Can you
tell me more about "Smalltalk's own tooling for collaboration and version
control"? Are you referring to Monticello? I am not insisting on git, but
Monticello seems pretty limited in term of collaboration. I see commit, diff,
checkout, and remote pull/push.

Specifically, let's imagine this scenario: we have team of tens of programmers
working on a project. A new team member joins and accidentally breaks the code
in non-obvious way. He pushes the code to main repository. Next time, everyone
else checks out the latest version of the code and starts having weird
problems. If you had 20 people on team, and they each wasted 2 hours because
the code was broken, well, you just wasted a week of programmer time. How do
you prevent it?

In file-based word, the answer is tests and CI. What is the smalltalk way? And
please do not say "It's in the conceptual nature of programming" \-- if the
scenario makes no sense in the smalltalk world (maybe you are not supposed to
have 20 people working on the same project?) please say this.

~~~
nathanjames
Pharo Smalltalk, in particular, when it comes to VCS, it's very similar to git
actually. It uses source code files, it distributes them via zip files, it
works locally instead of centralized, it supports merges, etc.

Pharo works well also with usual VCS because it can export code into source
code files.

The image plays no role in VCS whatsoever because VCS is about code, not data,
and image is mostly about live data and less about live code.

So any tool will and does work with Pharo outside the image. Problem arises
with a majority of people that prefer to stay in the image; in that case you
gain more control because you have more Pharo code to play with, but you lose
a lot of power because we are a small community not able to compete with
behemoth projects like git.

Another interesting thing which Pharo does emphasize is remote debugging:
though not a Pharo monopoly by a long shot, we do have several libraries that
can achieve this, and because the image format retains live state and live
code execution, it's easy to resolve issues.

Besides the image format, the Fuel format has the advantage of storing only a
fraction of the image. You can email this or share it via git or Dropbox. Like
an image, a Fuel file is a binary file and, like the image, it can store live
state and live code execution. This way, you can isolate live bugs and share
them with your team, each one in its own Fuel file.

STON is also another alternative format which feels familiar for those that
have worked with JSON.

So you see, you get the best of both worlds. You have the fantastic Smalltalk
image, and you have ways to deal with the file-based world.

