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.

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

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

Monticello is Smalltalk's most common source code versioning system. It was developed several years ago and implemented in several Smalltalk dialects. Monticello lets you commit a new version, update to a new one, merge, diff, revert, etc. This is also how you can share code.

You can also share code via Smalltalk Hub.

I think those pictures are rather cool. Some of them blow me away!

Yes, it's just "a bunch of pictures." That's his gift to us.

The backstory about how hot-air balloons came to be Smalltalk's logo is interesting.

Managing large complex applications is always a major pain. There is no shortcut, no ideal solution. For all of its imperfections, class-based OOP is the best tool we have today to aid in this onerous task.

The popularity of class-based OOP is undeniable. People understand that there is no perfect solution. What would you use in its stead?

Excellent piece! The author makes a number of strong points about software engineering. I looked at some of his other articles at JavaScript Non Grata, and he consistently recommends using transpiled languages instead of JS, at least on the front end. On the back end, there are many solid alternatives to JS. (Unless you really, really want to use Node.js.)