[squeak-dev] The Inbox: System-cmm.1059.mcz

Chris Muller ma.chris.m at gmail.com
Sat Apr 6 02:37:42 UTC 2019


Hi Jakob,

>> I also recognize a perception on your part of Squeak and its community
>> being like the group identified on the home-page of github.com:
>>
>>     "Built for developers"
>>
>> so hope you won't mind me reminding that the audience for Squeak goes
>> beyond that group.  Squeak should continue to cater to Users, because
>> they're not as tough as Developers.  As a developer, you can
>> appreciate a modular system capable of loading IDE plug-ins.
>
>
> I know that Squeak does not target developers only. But it *also* targets developers.

Of course, I believe I said that.

> I do not see the conflict in this case. Having a shortcut to install Metacello is nothing like twisting the concept of Morphic, turning your browser into a command line tool, or showing debugging annotations on every graphical widget, or something like that. It is not invasive. Neither are the refactoring tools. They extend the system browser, which is a developer's tool anyway.

Are you saying Metacello does not have its own browser and never will?

>> > These projects place a Metacello load script in their README files.
>>
>> I wasn't trying to change you if you have a special use-case or
>> preference for doing configuration that way.
>
> It is not a matter of my taste of writing install scripts. It is a matter of how people in general write install scripts (see below). We can procilaim the "correct" way to do that all day long, but it is meaningless if the rest of the world does not agree or does not comply.

This entire statement above is completely meaningless...   The "world"
does not "agree" on anything, nor is there any need to "agree" or
"comply" with anything w.r.t. what we're talking about.

>> > Yeah, projects that use Pharo or GemStone as their primary platform will be delighted to hear that they have to maintain a SqueakMap entry to give squeakers a chance to try their stuff. Not!
>>
>> Of course it's not mandatory, but I think you're kidding yourself if
>> you think Users (and even Developers) in 2019 will be delighted to
>> know they have to do a lot of research and work (hint:  a lot more
>> than 9 clicks) just to figure out how to try out your project.
>
> Well, the Smalltalk projects on GitHub that I came across typically have an "Installing" section at the top of their README, which is displayed on the project's front page on GitHub. This section often contains a snippet like the following:
>
>     Metacello new
>         baseline: 'NameOfTheProject';
>         repository: 'github://...';
>         load.
>
> That's easy enough to copy&paste and run and requires less than 9 interactions, *if* Metacello is available in the image already.

"Easy enough" means you've accepted a compromise.  You will never
achieve a high level of participation until its easier for newbie
developers.  But that's not my business, only Squeak's IDE...

> Some projects (typically those developed in Squeak) include the hint for Squeak that you first have to install the latest Metacello because it is not included in Squeak. Ideally every project would also include the Installer ensureRecentMetacello snippet.

Why don't they?   If they wish to support Squeak, then that's a
configuration error in those packages, full stop.

> But as a matter of fact, not all projects include these hints. Because they are built in Pharo and Pharo has the latest Metacello loaded already.  And if they don't use Squeak in the first place, you cannot tell them to go to the SqueakMap.

But Jakob, **they don't mention to find the Metacello pre-req on
Squeak's Do menu either**, right?  So, either way, newbies trying to
use your projects in Squeak are confused and lost.

Which is sad, because normally someone using Squeak knows about
SqueakMap, it's part of their main knowledge / training, because
SqueakMap is how projects are loaded in Squeak.

> On the other hand, we should not dismiss them or their projects just because they don't know or care enough about supporting Squeak. That would be a huge, arrogant mistake, IMHO.

I'm not sure why you feel dismissed when it's actually Squeak that's
being dismissed -- by omitting ensureMetacello at the top of your
project README's, and further by trying to compensate for this by
trampling Squeak's menu with your personal hack that confuses and
dilutes the hard work that went into making configuration in Squeak a
breeze for anyone; developer or user.

> If a Squeaker tries to maintain the SqueakMap entry for such a project, it is doomed to become stale sooner or later in my opinion.

As someone in Pharo-land, I don't expect you to understand SqueakMap
or the goals it solves, but just so you know, correctly defined
SqueakMap configurations _never_ get stale.

>> That's
>> what SqueakMap was designed to solve:  fixed configurations that
>> present the project, and work forever on a particular version.  It's
>> targeted to helping _others besides you_ configure their system so
>> they can evaluate your project's latest working version to decide if
>> they want to invest the time in setting up a dev configuration.  But
>> often others will capture load scripts and document them on SqueakMap
>> for themselves, you don't have to do it if you don't want.
>
>
> That's all nice and I see the benefit. You don't have to convince me. But the reality is that it places a burden on the project or entry maintainers.
> The devs have to step outside their repository to make their stuff more easily available. A third person that creates a SqueakMap entry assumes the responsibility to retest that project for every new release and update the entry. It might be simple, but it is not at all appealing for someone who only uses Squeak as a hobby (or not at all).

You made the argument above that "it is doomed to become stale" but
then above you say, "responsibility to test".  Which is it Jakob?

As I tried to explain above, neither.  Because if a project is worth
installing for someone else, THEY will do it.  If it isn't, they
won't.

In the meantime, I hope you'll close the gap in your configurations
with a "ensureMetacello" at the top of your README's.  You can easily
be inclusive of all platforms OOTB without hurting Pharo at all, if
you want to be.

Barring that, all I ask that we don't confuse how software
Installation is done in Squeak.


 - Chris


More information about the Squeak-dev mailing list