--- Begin Message ---
> So what would be the alternative?
A centralized server (e.g. Cincom Public Repository, SqueakSource,
SmalltalkHub, SqueakSource 3). After that, all you need is a detailed
project/package/framework description. Google will index it.
The whole "GitHub adventure" was started on the premise that it would give
Pharo more visibility. I don't see how it differs from SqueakSource from a
visibility standpoint unless you specifically search for code only on GitHub.
Most people just google anyway!
Besides, Smalltalk code on GitHub leaves a very bad impression on newcomers. I
was recently told "I just gave up on Smalltalk when I saw 200+ files"... It
was too late. I told the poor guy it was just the way code was *stored* on
GitHub but in your dev environment, everything resides in the image... Too
late : I had lost him solely based on the impression that he was entering into
a code management nightmare worse than a thousand C header files!
In the current state of things, the whole Cuis/Pharo/Squeak world is a mess.
Newcomers looking for code end up having to pick between a myriad of links to
SqueakMap, catalogs, SqueakSource, SmalltalkHub, SS3, GitHub, sar files, mcz
files, fileOuts, etc.
Ever tried to do some database stuff with Squeak or Pharo? Just try to pick a
package that works! You'll find plenty of code on all platforms (SqueakSource,
SqueakMap, SS3, GitHub), many ports from one to the other and, in the end,
you'll have tried to load 8 packages without success...
Wouldn't it be nice to have a centralized server with Cuis, Pharo, Squeak
(and/or others such as VW, VAST, Dolphin) and share a common import/export
format (SIXX, Smalltalk Instance eXchange in XML, would be a good start and
would probably do a decent job) and have the capability to store *other files*
as well (such as config files, source code in other languages, SQL scripts,
etc).
Something with the functionalities/capabilities of Store (VW code management)
with code store in a portable format.
My 2 cents.
-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)
From: Norbert Hartl <[email protected]>
To: Pharo Dev <[email protected]>
Sent: Saturday, January 13, 2018 7:13 AM
Subject: Re: [Pharo-dev] Blame support P7
Am 13.01.2018 um 12:39 schrieb Eliot Miranda <[email protected]>:
Hi Stephan,
On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <[email protected]> wrote:
Eliot Miranda <[email protected]>
wrote:
Isn't it important to preserve the ability to exchange code
between Pharo,
Squeak and Cuis? Don't you care that the VM development is directly
affected by this? Is the VM and plugin support not important to Pharo?
Git support turns out to be much more work than we hoped and expected. Too
many library updates needed, support for different workflows and platforms,
switch to file per class. The Iceberg channel on Discord is one of the
busiest channels.
You don't say? One of Clément's themes in recent talks on VM performance is
that we, as a very small team, are able to develop such a sophisticated
optimizer because we use Smalltalk. We are hugely productive in the vm
simulator. People using Smalltalk, including the Pharo, Squeak and Cuis
dialects that constitute our community, report the same in many different
domains, notably Bloc, GT Toolkit and Rossal.
Then why on /earth/ would one stop using Smalltalk in /the most central part/
of the collaborative programming process, version control? This is a huge
blunder. Now a major part of the Pharo community's efforts goes into an
external component, upon which Pharo is entirely dependent, and slowly but
surely it is cutting itself off from its sibling communities. Iceberg is well
named. People rearranged the chairs on deck while the Titanic sank.
Can we agree that a class/method/… stops being smalltalk after it has been
serialized to text? If you can agree to this I don’t know what you are talking
about. We exchange the to-text-serializer monticello-backend with git-backend.
The rest (the important part) stays nearly the same. The exchange is necessary
because the possibilities of collaboration are limited when using monticello
only. So what would be the alternative?There are even a lot of people that
don’t like git (including me). But I like the collaboration model because that
can do what no smalltalk tool can do to my knowledge.
Or to turn your argument around. You are a small vm team and you have to be
small because I doubt with the current collaboration model you are able to
grow.
Norbert
Stepha
_,,,^..^,,,_ (phone)
--- End Message ---
