[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

>>> Well, if you consider a merge to be harakiri - then I agree it sounds
>>> frightening :)
>>
>> If my work can not be ported after the merge, it is harakiri indeed
>> (at least for me).
>
> Why would it not portable? Are you using features that are totally
> unavailable in Pharo?


oh yes. well I don't know about "totally" unavailable, but I do try to
maintain my code for as many images as possible and I can't get it to
load in Pharo for non-trivial reasons that I currently don't even want
to investigate any further. remember that Pharo explicitely does not
attempt to keep backward compatibility, and it shows.

my codebase for muO is huge. I mean, huge. just download the archive in
SqueakMap and see what's there, you'll have a better idea about what I'm
talking about.

this is why I am at times speaking up on this list about backward
compatibility: I would like (some) people to realize that, besides being
a fun and toyish experimental programming environment very much open to
improvement and radical change, Squeak is also a serious development
platform upon which, year after year (I think I began with 2.7), actual
work has been implemented that would be damaged or stuck in a dead-end
if drastic changes with no concern about non-theoretical backward
compatibility were to happen.


Stef

> Ok. So the Squeak objective for you might be something like: "Evolve
> mildly the current Squeak functionality. Fix bugs. Keep APIs
> compatibility.".

no, I'm not that conservative. better "evolve the current Squeak
functionality, discuss possible show-stoppers publicly before
implementing them so that existing projects can surf across major changes"

Squeak is dynamic enough for this to be possible, and not even difficult
IMO.

Stef

2009/6/28 Göran Krampe <[hidden email]>:
> Hi!

Hi Göran!

> Not sure what you mean there.

Squeak is hardly approachable to newcomers (either seasoned
programmers or simple new ones). Gaining popularity explicitly means
to have newcomers. It's not possible if they can't understand what's
going on.

> Personally I like the colors. I also don't equal "normal" with
> "professional". But such is taste!

We could certainly debate on tastes but it's perfectly fine that you
like the current colour scheme. However, you're not alone using Squeak
and we have to consider other tastes.

I just mean something approachable (normal look-and-feel), where
people will feel comfortable from the day they start using Squeak
through every other following days.

A professional look-and-feel is probably more about simplicity and
usability. It doesn't need to have colours by truck load. Something
that one can spend countless hours looking at without eyes popping out
of their sockets. And it's about everything... for example, Squeak has
these childish window buttons and so on... it's NOT that cool, far
from being trendy. Why would we get stubborn to keep such things? It
looks like a toy, Squeak sometimes feels like a toy. When I squeeze
Squeak, it squeaks. Just saying... =)

And, unless some of us are graphic designers, why not just focus on
something simple, usable and approachable? That's definitively not out
of reach.

> Note that talking about what we "need" and what other people "want" is not
> really that fruitful. We get what we *do*, or in other words - if someone
> feels it is important enough to spend time on it - it will get done. Noone
> works on something because *someone else* told him to.

It seems to me that we are crying for direction as a community. Squeak
seems to be lost. Consequently, need, want, do, etc... it's just not
happening. Don't get me wrong, but it's just that you make it sounds
like everything can be done without a plan. And some of the things we
could want requires a lot of work hours and man power. It's not going
to happen overnight.

>> requirements of my distributors, which makes it overly challenging for
>> me to consider Squeak as our platform of development.
>
> Elaborate?

Please, Igor and I have talked a little bit about this. He will
certainly bring that on board's table. Anyway, Göran, I hope to be
able to share a complete list at later time. I am not done reviewing
the requirements. It's also challenging to know the status of projects
in Squeak and what has to be done.


Squeak has a killer app named Seaside.
Ruby has a killer app named Ruby On Rails.
Both are web frameworks, which kills which?

It doesn't really matter. It's not even about merits. Ruby is still
more approachable language and better documented. And I find it almost
amusing to have a killer app for the web, when one of the strength of
Squeak is multimedia. No, no, I am not trying to flame war here...
just trying to expose few things in order that we can openly discuss
about them.

Whether you agree or not, Squeak doesn't seem to gain in popularity
and people are flocking out to other forks. That means Squeak is doing
something wrong. Wrong enough to overcome all the "done right". =)

Regards,
Ian

--
http://mecenia.blogspot.com/

> When I squeeze
> Squeak, it squeaks.

this must be why I love it

Em 28-06-2009 07:23, Göran Krampe escreveu:

(...)
Possibly true, but Smalltalk, Squeak, Etoys and even Croquet have been around for quite some time now - and we haven't seen any real explosion yet. Croquet was meant to "explode" but hasn't. So I am not holding my breath for "the day Squeak gets popular" :)

I guess there are several issues when "explosion" (in the sense of wide acceptance & popularity) is a target for a project. I'll enumerate some of them that came to my mind:

1. There must be a consensus about what the project is. Meaning: what is squeak? The VM? The VM plus basic image? The VM plus what? Same to croquet and pharo and cuis and...
   
2. At least for the core things belonging to the project, naming conventions and style must be standard.
3. The set of features must be enough to cover the proposed capabilities. I explain: if the proposal is to have an usable general purpose programming environment, then the core features must include file manipulation, network communication, interface with foreign languages, access to system calls, access to devices, etc... And these features must be standard. And these features must be stable.
   
4. There must be documentation (in written form). Documentation must be standardized. Hopping users keep browsing code and figuring out how it work is just not reasonable for something wanted to be widely accepted.
5. At some point in time, "corporate support" becomes necessary. Much of what was put in topics 1 to 4 demands intensive, "semi-skilled" hardworking. Few people engaged in development of new ideas will stop to write manuals or to find a damned error or to put everything "in the standard style". Someone must be hired to do the boring tasks. Besides, as we must have learned from Java and several other real life examples, marketing is necessary: someone must do the press job... someone must print "Squeak for Dummies" books... someone must create courses. Someone must show people "how cool our stuff is". But corporate support won't appear before items 1-5 are accomplished. At a point squeak had a sort of corporate support from Apple and Disney. It was lost.
   

(...)
Take XFree86 vs XOrg for example. The history there is complicated but the fact remains - XOrg started, added lots of "cool features" quickly while XFree86 stood still, then when the developers started heavily voting with their feet the distros also switched and XFree86 was dead before it even hit the floor.

There are mainly two aspects here that tells me that the above "bad future of XFree86" is more likely to happen than the "good future of Open/Net/FreeBSD":

- Pharo may "sound" like it has a different agenda than Squeak.org but IMO the large majority of Squeak.org developers share the Pharo agenda. Thus the differentiation is not there. Most people will just pick the one with the most momentum, and that is Pharo.

- Squeak.org is standing still. Sure, there are things being done by some people, no doubt about that. But perception is *everything* and from the outside it seems to be standing still. Even the squeak-dev list is quieting down and that is a bad sign.

IMHO Squeak.org "stillness" is happening because a point was reached when boring work is necessary. IMHO the board should be looking for corporate support in order to have resources to support the "boring work". As an example: some years ago there was momentum for the use of squeak at schools. Some governments endorsed the idea. But things don't go ahead if you don't have "internationalization" (meaning: basic school students are not polyglots and most of them won't speak English). Also poor support for UTF-8 didn't help (well looking for UnicodeInputSupport-jlrr.1.cs lost in some discussion list is not what I would call intuitive). Besides, there are still some really basic issues regarding to bugs and behavioral excentricities... Some boring work should have been done to assert these issues.

So although I share your basic view of cross pollinating forks being a "Good Thing" and something we should embrace (see OLPC, Squeakland, Croquet etc etc) such forks need to have a specific goal.

IMHO Pharo is not such a fork, Pharo is still very much "generic" as is Squeak.org. Pharo is more like "Squeak.org going agile" or "Smalltalk, with less talk" :). And thus it resembles XOrg much, much more than OpenBSD.

Again, a key issue is that perhaps there is just not enough people to support splitting projects. Again, IMHO that is one the issues that complicated the life of croquet. Not to mention that much of croquet related to 3D optimization and acceleration in cross platform environment...

(...)
Oh, and a final note:

But what if Squeak.org is abandoned and everyone moves to Pharo, what is so bad about letting that happen? It is NOT bad. But I think we could do it in a smoother way and actually turn this into something *positive*. The merge could be turned into a real BOOST to Squeak/Pharo.

If everybody goes to Pharo it won't necessarily be a problem. The problem will be if key people stand in one side or the other.

regards, Göran

regards,

Casimiro

>
> Squeak doesn't have a set of objectives and an agenda that is
> meaningful for developers.
Yes it does.

Keith

I like your ideas, Casimiro. And a lot of boring work, as you would
call, but I call it maintenance, has to be done. Internationalization
is among the point that prevents me to use Squeak.

There are also a lot of messy things in the official image combined
with the poor documentation, makes it challenging for new programmers;
as far as commercial support goes, one consideration is to hire people
that might not have experience with Squeak and has to learn... then
the training turns out to be expensive and long for a language known
to be simple and self documenting.

Ian.

--
http://mecenia.blogspot.com/

On Sun, 28 Jun 2009 19:05:30 +0200, Ian Trudel wrote:

> I like your ideas, Casimiro. And a lot of boring work, as you would
> call, but I call it maintenance, has to be done. Internationalization
> is among the point that prevents me to use Squeak.

Ian, would it be possible you send me a list of what things _you_ need for  
internationalization. That would be very interesting in a current project.

Or, if you like, just post here (and if it was already posted then  
where/what).

TIA.

/Klaus

> There are also a lot of messy things in the official image combined
> with the poor documentation, makes it challenging for new programmers;
> as far as commercial support goes, one consideration is to hire people
> that might not have experience with Squeak and has to learn... then
> the training turns out to be expensive and long for a language known
> to be simple and self documenting.
>
> Ian.
>

--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

2009/6/28 Klaus D. Witzel <[hidden email]>:
> On Sun, 28 Jun 2009 19:05:30 +0200, Ian Trudel wrote:
>
>> I like your ideas, Casimiro. And a lot of boring work, as you would
>> call, but I call it maintenance, has to be done. Internationalization
>> is among the point that prevents me to use Squeak.
>
> Ian, would it be possible you send me a list of what things _you_ need for
> internationalization. That would be very interesting in a current project.

For Seaside #leadingChar is a PITA because there is no way of knowing
the language of the content the user entered. And it's a rampant
layering violation. And it probably contributes to WideStrings being
so slow. And it's not portable. And ....

And don't get me "but we need it for fonts". The only way to get nice
fonts in Squeak is to avoid it and do it in C with char*.

Cheers
Philippe

2009/6/28 Klaus D. Witzel <[hidden email]>:
> On Sun, 28 Jun 2009 19:05:30 +0200, Ian Trudel wrote:
>
>> I like your ideas, Casimiro. And a lot of boring work, as you would
>> call, but I call it maintenance, has to be done. Internationalization
>> is among the point that prevents me to use Squeak.
>
> Ian, would it be possible you send me a list of what things _you_ need for
> internationalization. That would be very interesting in a current project.

Oh, I forgot the usual things. Unicode normalization, collators, date,
number and currency formatting, unicode regexes.

Basically what ICU does.

Cheers
Philippe

Hi!

Casimiro de Almeida Barreto wrote:
Note that *I* don't really care for any "explosion". I was merely saying
that waiting for it to happen in order to gain something from it - is
probably foolish :)

[SNIP of 1-5]

Note: I don't agree with that list, but I get your point.

> IMHO Squeak.org "stillness" is happening because a point was reached
> when boring work is necessary. IMHO the board should be looking for

Nah, how come Pharo is doing all those things then?? I don't agree.

> corporate support in order to have resources to support the "boring
> work". As an example: some years ago there was momentum for the use of

I generally do not agree with those that think "corporate support" or
"paid work" is the solution. Sorry, I just don't.

I just want a Squeak that I can use and help improve and that has a
reasonable commit process, some nice goals and a reasonable leadership. :)

I don't want a company deciding what happens with Squeak. Definitely not.

> Again, a key issue is that perhaps there is just not enough people to
> support splitting projects. Again, IMHO that is one the issues that
> complicated the life of croquet. Not to mention that much of croquet
> related to 3D optimization and acceleration in cross platform
> environment...

That I can agree with - we are quite few.

>> Oh, and a final note:
>>
>> But what if Squeak.org is abandoned and everyone moves to Pharo, what
>> is so bad about letting that happen? It is NOT bad. But I think we
>> could do it in a smoother way and actually turn this into something
>> *positive*. The merge could be turned into a real BOOST to Squeak/Pharo.
> If everybody goes to Pharo it won't necessarily be a problem. The
> problem will be if key people stand in one side or the other.

Right... So I didn't disagree with *everything* you wrote :)

regards, Göran

On Sunday 28 Jun 2009 9:02:05 pm Ian Trudel wrote:
> Squeak is stuck in some time warp, where the surrounding world is on
> stand still. It should however consider that we are living in 2009 and
> have needs of 2009. We need a different usability, developer tools and
> we have different goals. For example, Squeak hardly support the
> requirements of my distributors, which makes it overly challenging for
> me to consider Squeak as our platform of development
Squeak was created by researchers as a platform for programmers to build
purely object-based systems around a portable compact Smalltalk kernel. 3.6
and 3.8 showed what is possible along this direction. To me it looks like it
has served its original purpose well. It was not intended to be a industrial
strength deployment platform. It has no modularity, supportability,
scalability etc. That gap is to be filled by downstream projects like Etoys,
Seaside, Sophie, Croquet and others.

What Squeak lacks is a clear enunciation of its value proposition. The opening
para of squeak.org is too general and leaves gaps. A short para that crisply
answers all the following questions:

   what is it primarily? - a programming environment, runtime, a kernel, a
research workbench for virtual machines?
   who is the intended audience? researchers? industrial programmers? advanced
programmers?
 what is the primary purpose? prototyping? demos? test beds?
  what are its nearest competitive technology? Java? Flash?
  What is uniquely different (and much better) from these?

Such a para will serve to set expectations early and clearly. As Smalltalk and
its ideas propagate through the universe, we will encounter audience whose
needs are not served by the current proposition. If Pharo aims to cater to
such  audience why should it not develop into a mutant strain? Why should it
be backward compatible with Squeak?

Subbu

2009/6/28 Göran Krampe <[hidden email]>:

> I just want a Squeak that I can use and help improve and that has a
> reasonable commit process, some nice goals and a reasonable leadership. :)

Amen.

> I generally do not agree with those that think "corporate support" or "paid
> work" is the solution. Sorry, I just don't.
>
> I don't want a company deciding what happens with Squeak. Definitely not.
>

Göran, I do understand your concern about this. We should remember
that there is no ultimate solution. I think his idea was rather about
integrating this as part of a solution. Nothing to do with "a company
deciding on Squeak". Furthermore, ignoring companies and commercial
activities is also not a solution at all.

There is a huge difference between offering support to companies (and
asking support from them) and having them running Squeak Oversight
Board. I think we all agree the latter is undesirable and should not
happen.

Ian.

--
http://mecenia.blogspot.com/

On 28-Jun-09, at 3:23 AM, Göran Krampe wrote:

> IMHO Pharo is not such a fork, Pharo is still very much "generic" as  
> is Squeak.org. Pharo is more like "Squeak.org going agile" or  
> "Smalltalk, with less talk" :). And thus it resembles XOrg much,  
> much more than OpenBSD.

One aspect of Pharo's practical streak that hasn't been mentioned yet  
is the willingness to abandon compatibility with Etoys - something the  
Squeak.org community has been unwilling to do. What's really silly  
about this situation is that the actual users of Etoys forked some  
time ago, and almost nobody actually uses Etoys in Squeak.

IMHO, Squeak.org needs to either recommit to Etoys and education as  
its primary mission, or break compatibility and become a general  
Smalltalk platform for a variety of applications. This suggests a  
merger with either Squeakland or Pharo, but even without merging,  
Squeak.org can get its mojo back if it chooses an identity.

-Colin

On Sun, 28 Jun 2009 19:35:45 +0200, Philippe Marschall wrote:

Don't get me wrong now: I know you're talking about your framework, can  
you point me to more specific locations (release/version, class name,  
method name) or so?

> Basically what ICU does.

Assume that some other project has something new (in a recent .image on a  
Squeak VM).

How can your stuff be tested with it? Would it be necessary to refactor  
your app, or can a project man like me do this and that, test this and  
that (!) ?

> Cheers
> Philippe


--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

Keith Hodges wrote:
>> Squeak doesn't have a set of objectives and an agenda that is
>> meaningful for developers.
>>    
> Yes it does.
>
> Keit

Ok. So, what does that set of objectives and agenda say about:
- Backwards compatiblity
- Removal (or not) of stuff
- Addition (or not) of stuff
- Modularity
- Any concrete statement (about the software, not the process!) so
people can know what to expect
?

When was it approved by the community or the elected leadership?

Was there a decision process involving the community?

Where can I read it?

Cheers,
Juan Vuletich

Colin Putney wrote:
Amen.

Cheers,
Juan Vuletich

>>>>> "Colin" == Colin Putney <[hidden email]> writes:

Colin> IMHO, Squeak.org needs to either recommit to Etoys and education as its
Colin> primary mission, or break compatibility and become a general Smalltalk
Colin> platform for a variety of applications. This suggests a merger with
Colin> either Squeakland or Pharo, but even without merging, Squeak.org can
Colin> get its mojo back if it chooses an identity.

At this point, I'd be leaning back towards squeak central reintegrating Pharo,
given that Etoys already forked.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On Sun, 28 Jun 2009 19:28:50 +0200, Philippe Marschall wrote:

...
> And don't get me "but we need it for fonts". The only way to get nice
> fonts in Squeak is to avoid it and do it in C with char*.

Can you see the attached (?) : a platform font, displaying #('Basic Latin'  
'Cyrillic'), using standard Squeak libs and VM, its Smalltalk code  
loadable into Cuis, Pharo and Squeak.

No line of C nor char*, other than what is already in the VM and its  
plugins (and currently _nothing_ optimized).

?

> Cheers
> Philippe
>


--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

On 28.06.2009, at 20:53, Randal L. Schwartz wrote:


Even disregarding what the Pharo people would think about the idea,  
doesn't that argument go both ways? As in "given that Pharo already  
forked, Etoys can now be reintegrated to Squeak"?

- Bert -