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 at 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 at rowledge.org; http://www.rowledge.org/tim
> From C:\*.* to shining C:\*.*
>
>
>



-- 
AG5
Timorplein 37
1094 CC
Amsterdam

T  020  4630942
F  020  4630946

On Tue, Apr 24, 2018 at 9:11 PM, tim Rowledge <tim at 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 at rowledge.org; http://www.rowledge.org/tim
> From C:\*.* to shining C:\*.*
>
>
>



-- 
AG5 software GmbH
www.ag5.com
tel: 0049 (0)30 81828464
mobile: 0049 (0)178-2016515

----------------------------------------------------------------------------------
This message may contain information that is not intended for you. If
you are not the addressee or if this message was sent to you by
mistake, you are requested to inform the sender and delete the
message. Any unauthorised use or dissemination of this message  in
whole or in part is strictly prohibited.