Hi all,

First note: My Squeak contribution is very limited (/can be rounded to zero), so I'm actually not allowed to criticize:)

Q-What do you use Squeak for?

Used it since it became available in 1996. At that time, afaik, it was the only open source Smalltalk distribution and it was great, especially while enjoying Smalltalk books as "Inside Smalltalk" and the "Smalltalk-80 series", Design Patterns (Gamma e.d.) and Smalltalk's best practice patterns (Kent Beck). Used it professionally around 1998-2000, when we tried to build & commercialize some multimedia "sharing/editing" tool for children. Long story short: this failed. Not because of technical reasons, we were just young and naive. Currently, I'm only using it sporadically for small hobby projects and e.g. to learn from graphics/music/network libraries.

Q-If you don't use Squeak, why not?

Lack of source code management / package configuration mgmt / modularity / stability / speed (at least that was the state in 2000).

Q-If you used Squeak in the past and don't now, what pulled you away?

Again, lack of source code management / package configuration mgmt / stability / modularity / speed.

We (ag5.com) are currently working with around 10 developers. Working with a group of developers wasn't well supported in Squeak. So we moved to VisualWorks around 2001. At that time we also moved our company's product focus to corporate planning systems. So Squeak's multi-media features became less valuable for us. (And eventually, we also changed our company's name from Cosmocows to AG5).

Q-What does Squeak lack that you think might make you use it for 'regular' development?

Not sure what is the exact current state and how squeak progressed in the areas I mentioned above. But, over the years, there seem to have been several interesting initiatives like Newspeak (e.g. modularity with inner class concept) or related research projects from HPI Potsdam. But I've no practical experience with these initiatives, only from reading papers and/or a bit of playing.

Q-What things are too hard or annoying to do?

Again: source code management / package configuration mgmt / modularity / stability / speed.

Some initiatives in this area seem to have failed, e.g. Squeak had several Namespace implementation initiatives, none made it into real production, afaik. Integrating with Source code management systems like Git, while keeping the power of the Smalltalk image concept, seems to be hard too.

But others initiatives seem to have success, e.g. the opensmalltalk-vm. Even a success in 2 ways: the improved collaboration infrastructure (git/travis) and, of course, the VM performance itself. In some benchmarks, it should even outperform VW, but VW's virtual machine performance is, for us, fast enough (/not the performance bottleneck). MIT's Scratch has also been a success for Squeak in this area: an infrastructure where 1000s of children can share their projects; view & load & try & review projects from some open repository and it all seems to work. (ps. without that I knew, even my daughter started to use it during some school event in Berlin this year. And when she came home, she showed me her work online: a pink horse jumping over hay bales. Amazing.) Something like this is not possible for general Smalltalk programmers, whatever st distribution, and certainly not between the different st distributions.

Testing framework SUnit is probably the most successful Smalltalk code in history. (successful in the sense of having succeeders/followers). Still using it almost daily, and it helps to stabilize and share our code. (when I want to understand code from others, I often start reading their test cases).

With Monticello and Metacello I've no real practical experience, no opinion. Played with it a few years back, but at that time it was still immature. Nowadays it seems to be used a lot, so probably as good as VW's store for source code mgmt.

Q-What would you like to be able to use Squeak for?

To develop and run the server part of our web-based "Business" products. Our 2 products: an online ERP system for Dutch Fire-departments and a Skills management system for Manufactures, are continuously developed & integrated & deployed and run by a multidisciplinary team of developers, designers, operators and business analysts.

However, I don't see how a switch to Squeak could (financially) pay off. And maybe even more important, most of my (younger) colleagues are enthusiastic python/javascript/swift programmers, they are not hooked on Smalltalk as I do.

====

Not really answering one of the questions above, but some general thoughts about our tools landscape and if/where Squeak could fit in:

VisualWorks is still more practical for us than Squeak. It offers a pretty stable & fast core, their 64bit VM is running stable in production for us for several years now (we host 200+ images), and their source code management system "Store" is more or less working for us (we tuned it to our needs). We do not use much of Cincom's "add-on libraries" e.g. we don't use their ORM/Glorp nor any of their web server/frameworks nor tools the UI painter. We do not need their customer support often, but when we need them, they always are very helpful and able to fix bugs.

Currently, half of our developers are programming in other languages than Smalltalk, especially for the client-side of our product. Web-client stuff with Javascript/HTML/CSS, native apps with Java & Swift. For all kind of system administration automation, we use Python (including Amazon's AWS scripting).

We also work with freelance interaction & visual designers; they are familiar with HTML/CSS/Js and it is much more efficient when developers and designers have some common tooling.

In the past, we used a "Model-Driven Design" (MDD) approach. Which meant, in Smalltalk, we "described a high-level domain model", and from this model, all other system parts/layers were automatically generated (including parts in other programming languages). A few years back we moved away from this strategy to develop directly in those other languages, to get higher product quality, especially in the "User eXperience" part. At the cost of Smalltalk and of programming productivity.

For me personally, Squeak is "good enough", it's fun and a source of inspiration. But for a company with several developers working on a product with "web- and app clients", Squeak needs better source code management (/git), package configuration mgmt and modularity, so it can better embed into the multi-language workflow of our team of developers, designers. But this "management overhead" would probably make it less attractive for personal hobby use. A dilemma the community should solve:)

To repeat my first note: My Squeak contribution is very limited (/can be rounded to zero), so I'm actually not allowed to criticize. Here a complete overview of my limited contributions: - Every year I vote in the board elections. That is another thing I very much like about Squeak: the community is democratic, and the yearly elected board seems to be a team of smart and friendly people. - and I like to attend the yearly Squeak e.V. Treffen (/meeting) at HPI in Potsdam Germany, to give a short presentation of our Smalltalk usage and especially to see others present their interesting Smalltalk related (research) projects. - writing this email.

greetings and keep up the good work!

Mathieu van Echtelt

On Tue, Apr 24, 2018 at 9:11 PM, tim Rowledge tim@rowledge.org wrote:

Well, we had about 30 replies on this so far and I'd love to read more. Who else can tell us fun stuff?

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim From C:*.* to shining C:*.*