Igor I think that this is too early. Let us deliver something first and see. I want to see what we can really do. Can we create a community of doers? Can we create wealth and a cool community? Then some people can see how we can merge and if this makes sense

Stef

...

...

2. Take some decisive action and "merge" the two in some *smart* way

beneficial to both. Impossible? I hope not.

3. Just kill off squeak.org. A mercy kill :). Then people could move

over to Pharo without having to think about it - there is no other "Squeak".

Eh, well, my analysis is probably full of silly holes here. Looking at the above, 1 and 3 feels less nice. So how could a "merge" look that would be attractive to *both* camps? I call the theoretical merged project Phreak below (but I am not proposing name changes etc, but I need a name to use in the text).

Pharo characteristics:

• A small "benevolent dictator" board. Lots of action, less talk.
• Has a very clear stated "direction".
• Has a website using CMSBox.
• Uses Google code for issue tracker and wiki.
• Has Mailman mailinglists and downloads at gforge.inria.fr (I think)

Squeak.org org characteristics:

• Has an elected SOB, an election process and a Team model. The

jury is still out I think, we seem to have lots of trouble "getting shit done".

• Has very little stated "direction" at the moment.
• Has a website using Swazoo.
• Uses Mantis, Swiki, file archive and Mailman on a community paid

Hetzner server.

Now... why would Squeak.org want to merge with Pharo?

Pros: Get momentum back. 1 + 1 = 2. A revitalization. Very important!

Cons: The SOB & Team model would probably have to be dropped. The work made since Pharo forked may or may not be a "lost cause", that depends on if Phreak is interested in utilizing that work. Other cons?

...and Pharo?

Pros: An influx of developers. A much stronger position as Phreak would be Squeak + Pharo. No "compatibility" to worry about, Squeak is out of the picture.

Cons: Some people in Pharo may perceive such a merge as dangerous since they might be afraid that certain aspects of Squeak.org (that Pharo was created in order to escape from) is coming back "knocking on the door".

I personally don't think there is such a danger if Phreak simply adopts the simple organisation of Pharo (with board and all) BUT... since it would make the Pharo community much *larger* the effects of that growth need to be taken into account. But Pharo should not fear growth, because that would be an odd position.

How could a merge be done practically? I really don't know :). And I must stop typing now, this post is waaaaay to long anyway and I have probably stepped on too many toes already.

Hello Goran. You are definitely didn't stepped on any of my toes/toys. And i would certainly sacrifice my SOB membership (if this is a sacrifice), to see things moving & progressing as fast as they do in Pharo. As many others, i eagier to see the squeak/pharo/phreak shining - make it cool & modern software. The rest of things is barely bothering me.

What i like in Pharo, that they make decisions on strictly technical basis - no politics. If code is good - it candidate to be included. If code stinks - its a candidate to be excluded. Simple concept :)

For anyone, interested in my opinion: i would put a huge +1 for a merge on a Pharoer's conditions.

...

regards, Göran

---

Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

---

Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi!

(still cross posting, hope you don't mind)

Gary Dunn wrote:

I am new here and not really qualified to comment on this issue. Please take my input as having good intentions. Specifically, I do not want to start a flame war over the pros and cons of various projects.

Nah, we don't do flame wars in the Squeak community. Well, not bad ones at least :)

There is much to learn from the history of the BSD community. (Disclaimer: I am a huge fan of FreeBSD.) The FreeBSD project began with the goal of creating an open-source OS for Intel i386 hardware that was as faithful as possible to BSD Unix. In time the developers were going in three directions. One group wanted high performance, a second wanted portability to every possible platform, and a third wanted high reliability and security. There were also the usual personality conflicts and differing opinions on how to manage the project. Eventually it forked, twice, giving us FreeBSD, OpenBSD, and NetBSD. Each has its own personality, its own strengths. The good news is they cross-pollinate each other.

Yeah, that would be a positive future. And I have in fact earlier strongly advocated the fact that we need to "live with forks" because we already have several of them (like Croquet, OLPC etc).

But see below...

[SNIP]

It looks to me like Pharo is a Smalltalk for building grown-up apps. Very much like the Smalltalk I began with, which produced apps with the look and feel of the host Microsoft Windows. I think there is a need for that. I take it Pharo is new, and as such it has been luring developers away from Squeak. The potential for good in this outweighs whatever the negative consequences may be, because, like the BSDs, the Squeak developers can always pull in what they like from Pharo.

In a "perfect world", yes. I even started the DeltaStreams project with these cross pollination scenarios in my head.

Do not confuse a fork with a divorce. Think of it as mitosis. The more the merrier.

Yes, that is also the way I have argued about it. See:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.ht...

I believe that the impact of Squeak on education has yet to be realized. The necessary hardware -- the visionary Dynabook -- is just appearing. It will be years before there are enough skilled teachers for the critical mass required for the paradigm shift to occur. And there is the culture change, so difficult in a field as institutionalized as modern education. What we have been seeing are the Smalltalk explorers and trail blazers, the pioneers to whom we will someday owe an enormous debt of gratitude.

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 am in no position to recommend anything here, but I will just the same. Please forgive me. I recommend that Squeak not be killed off, or merged. Let the fork live on.

Nothing to forgive, I want to hear lots of opinions in order for me to personally form an opinion about the idea. The "view" you present above is a positive one of a forked world. The reality can be harsher:

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.

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.

I cannot close without saying that "Phreak" would be a very bad name :-)

Again, I wasn't even advocating a name change - although a name change may be a good thing if we would merge. Also, I hate to say it, but "Pharo" sucks pretty bad too I think, and you guys STILL have attracted lots of developers :) :)

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.

regards, Göran

Juan Vuletich wrote:

Göran Krampe wrote:

...

... 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. ...

This is the key issue here.

At least Pharo has an agenda. Squeak needs an agenda badly. Something along the lines of the old "Where is Squeak headed" from Dan. Without that, Squeak can't advance in any direction at all. People choosing a Smalltalk for their projects can not know what to expect. Forks can not know if they are needed or not.

Most forks have clearly defined objectives. Etoys, Croquet, Cuis do have them. The objectives for Pharo are broader, and less defined. But Pharo guys know where they are going, and they have some developer time and organization to advance.

Squeak has nothing of this.

Yes it has

The Squeak community needs to define objectives and an agenda for Squeak,

We have, and we have had our adgenda longer than pharo has had theirs. The irony being that having defined an agenda for moving forward in an inclusive manner, the pharo team forked!

or decide that we don't have them, and that the Squeak branch will not be developed further.

Cheers, Juan Vuletich

There is so much FUD in the past couple of emails I cant even summon the energy to reply to them

Keith

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

Yes it does.

Keith

Dear Juan,

Ok. So, what does that set of objectives and agenda say about:

• Backwards compatiblity

We have had Installer, and LevelPlayingField for ages. The purpose of which is to make some compatability possible between different images, and ongoing changes to API's can be back ported to other images thus preserving backwards compatability, and providing forwards compatability where possible.

We have more backwards and forwards compatibility now than we ever had before.

The crux of the difference between squeak and pharo philosophies has been the issue of backwards compatability.

• Removal (or not) of stuff

All tools we are using for 3.11 are not reliant upon a gui. This is explicitly because the stated goal has been for at least 3 years to work towards a kernel image, with which people can build up the custom image that they want.

• Addition (or not) of stuff

The proposal is to have a range of deliverables for different goals, from minimal images to fully loaded images for testing.

• Modularity
• Any concrete statement (about the software, not the process!) so

people can know what to expect ?

This statement has been that 4.0 would be as 3.10 with minimal changes for relicencing purposes.

3.11 has been proposed as an image with minimal changes, that would be proof of concept for the new process.

a) Readies the image for automated build and testing - i.e. release early and often will be properly possible at last b) Readies the image for our automated/open mantis integration for bug fixes c) Hopefully includes atomic loading for making radical changes to the image possible (i.e. new gui/compiler etc) d) Readies the image for future releases that are assembled by a selection of components, working to a design proposal rather than by an infinite set of incremental changes by one or two control freaks.

(p.s. I need help someone to test and debug (c))

The actual "design" as to what 3.11 results in has been in the form of executable code for over a year, in the ss/Tasks repository. This is probably looking a bit stale now since I have been working on bob.

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

ages ago.

http://installer.pbworks.com/Squeak311Proposal

Was there a decision process involving the community?

http://installer.pbworks.com/Squeak311

Keith

I'd like to add, that's Keith's effort to build the infrastructure for developers to simplify distributing & loading their work on different forks is extremely valuable.

By having this infrastructure at first place, we would never spend hours/days trying to port/adopt stuff to another fork - a maintainer is responsible for adopting his package and including the scripts to load it into the image w/o errors. And Sake, Installer and other related stuff is could greatly help with that.

As i understand, the 3.11 would be the first image which includes/based on such infrastructure. But it seems people keep doing things in old ways. I can't blame them for that. But if we really want to move on, we should adopt this idea.

2009/6/29 Juan Vuletich juan@jvuletich.org:

Hi Keith,

Thank you for the detailed and thoughtful answer. All you say here is important. I was aware of the new process. I was not aware of some of the details for 3.11 and 4.0. Thanks for all this.

However, I am not asking about the this. What I'm after is the general, long term objectives of Squeak. The kind of statement the Board should come with, with the endorsement of the Board.

For example, Pharo says:

• a progressive, open-source Smalltalk platform for professional use
• a flexible environment to support the research of new language concepts
• We will really favor evolutionary and incremental changes. We want to be

able to experiment with important new features or libraries.

• Beauty to learn from
• Not backward compatible
• Clean, lean and fast

Cuis says:

• Close to the ideas in Smalltalk-80 and "Design Principles Behind

Smalltalk".

• Include only kernel functionality.
• Included stuff should be in very good shape.
• Include a greatly simplified version of Morphic as the main UI.
• Easy to fix and extend.
• Cuis is yours to extend it to suit your needs.
• Stable. Smalltalk kernel should not change much.
• Compatible to a reasonable degree with packages intended for other Squeak

distributions.

• There will be optional packages available for Cuis, if people start

building or using them. We don't want to control that process.

For Squeak, along these lines, from your email I select

• We have more backwards and forwards compatibility now than we ever had

before. The crux of the difference between squeak and pharo philosophies has been the issue of backwards compatability.

• The stated goal has been for at least 3 years to work towards a kernel

image, with which people can build up the custom image

• The proposal is to have a range of deliverables for different goals, from

minimal images to fully loaded images for testing. that they want.

These kind of stuff should be at the top of Squeak.org, so people (even old timers like me) can know where is Squeak headed.

Thanks, Juan Vuletich

2009/6/29 Stéphane Rollandin lecteur@zogotounga.net:

...

For example, Pharo says:

• a progressive, open-source Smalltalk platform for professional use
• a flexible environment to support the research of new language concepts
• We will really favor evolutionary and incremental changes. We want to be

able to experiment with important new features or libraries.

• Beauty to learn from
• Not backward compatible
• Clean, lean and fast

once we remove from this list general statements like "we want it good and nice and better than Squeak" and keep only precise, specific items, what is left is:

...

• Not backward compatible

because, unfortunately, it is a main obstacle for moving forward. Or maybe not? Maybe we should start making amazing stuff right now? I really like doing amazing stuff! But i see, that to make something i need to make a tons of patches into different parts of system, or rewrite them from scratch. Only then i can start doing something. But wait! Each time i changing something in core libraries, it could break something else in someone's else code. So, i should start a fork, otherwise, my stuff can never see the light, or it would never have a chances to be as much amazing as i like to if i keep running old horse.

Stef (... running away real fast towards some place to hide)

2009/6/29 Stéphane Rollandin lecteur@zogotounga.net:

...

...

...

• Not backward compatible

because, unfortunately, it is a main obstacle for moving forward. Or maybe not? Maybe we should start making amazing stuff right now?

I am doing amazing stuff with Squeak right now. I have been doing so for years.

Then we're putting different meaning in an 'amazing' word. I can do amazing stuff, but its often requires hacks, workarounds and other different gotchas, which i hate to put into my code. And after all of that, fairly, i can't call it amazing anymore. Can you?

Now that Pharo provides the non-backward compatible way, which is fine, I don't understand why the question arises for Squeak once again. Pharo is the solution, isn't it ? (and I mean it).

You may feel content about code, which rots there for years, and no-one even cares rewriting/optimizing/making it better. But i don't. I don't like sitting on the gas canister and hoping that next spark will not blow it up.

Stef

2009/6/29 Stéphane Rollandin lecteur@zogotounga.net:

The point is that, to me, this question of backward compatibility is not theoritical. I do have a big amount of code and objects that I will just have to reimplement if backward compatibility is broken. I mean months of work, just to keep in sync with this kind of development. And if I have to do that for each release, well then it would be much easier for me to stay in 3.8 and maintain my own fork.

So what? Some people keep using even older images. But in case if you want to stay on the bleeding edge and harvest the fruits of most cool & advanced stuff, this is always demands a sacrifices. So, should people push the brake, just because you can't run at same speed?

Stef

On 6/29/09 4:12 AM, "Stéphane Rollandin" lecteur@zogotounga.net wrote:

well thank you for driving me out. I guesss I just have to shut up now.

Stef

No you do not should shut down. You have many admirers and I'm guilty to do not try to get your VeryAmazing work on FunSqueak or SqueakLightII.

Any .image which don't let you run your code is worthless , no matter if was Squeak, Pharo , Cuis or other fork.

Edgar

Hi Keith,

As Juan, I would also like to know what you are referring to? Do you mean the mission statement of the Squeak Oversight Board? http://squeakboard.wordpress.com/our-mission/

I think it is a very good mission statement. But except for perhaps "integrating contributions from collaborating groups (for example, Pharo, Etoys, and Croquet)" I see little with regards to content. (This is no critique at all, by the way!)

Or are you referring to something else?

Cheers, Bernhard

Am 28.06.2009 um 19:05 schrieb Keith Hodges:

...

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

Yes it does.

Keith

2009/6/28 Göran Krampe goran@krampe.se:

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" :)

Sometimes being popular means doing normal things. Smalltalk is an unusual programming language (in the sense of mainstream) with an overly eccentric environment in Squeak. Then there are Croquet, Etoys, and so on. It's hardly a break through if it's only "more" eccentric than eccentric. Don't you think?

The look-and-feel is designed for children. It's colourful, joyful, it bleeps and blink. How many professional developers are children? How many children are on this list? Enough with that already! Can we have a normal look-and-feel? A professional look-and-feel. =)

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 doesn't need a killer app. It needs to be spruced up and put back on track. Honey moon is over, it's time to get real.

Regards, Ian.

2009/6/28 Stéphane Rollandin lecteur@zogotounga.net:

...

Squeak doesn't need a killer app. It needs to be spruced up and put back on track. Honey moon is over, it's time to get real.

I would suggest you switch to Pharo: it's there exactly to fit your expectations. Then you can let Squeak live its life, be it overly eccentric.

Mince! On me m'attire avec de belles promesses! Pour ensuite me dérober et me laisser seul dans le noir... =P

That was however a great piece of advertisement. he he he

Ian.

El dom, 28-06-2009 a las 08:59 -0700, Randal L. Schwartz escribió:

...

...

...

...

...

"Stéphane" == Stéphane Rollandin lecteur@zogotounga.net writes:

Stéphane> I would suggest you switch to Pharo: it's there exactly to fit your Stéphane> expectations. Then you can let Squeak live its life, be it overly eccentric.

For some, what I'm about to say is obvious. But for others, this might be a deal killer.

Once Squeak core is included as part of the SFC, it will be a lot easier for a business to base its work on Squeak. If there's a question of code heritage, the SFLC will assist to provide "we stand together" support.

For Etoys, this has already happened, in that VPRI is willing to put *its* legal resources behind the current code base.

I know Pharo has just announced "mit license for everything", but there's no organization with other-than-volunteer resources that can certify that.

And given that Pharo is derived from the same original apple-licensed code that had troubled Etoys and now taints Squeak core (until the 4.0 effort is complete), I see this as a problem.

For me, that means I cannot recommend Pharo for business development.

What I would *like* to see, and am working towards as a member of the Squeak Leadership Team is:

(a) squeak core gets clean MIT license, and joins SFC (b) Pharo's license-known updates get rewritten to apply to squeak core

This would make something that is equivalent to Pharo, but with a clean license history.

In essence, I'd like to bring Pharo "back into the fold", because there *are* advantages to having a clean license history that *is* supported by someone's paid lawyers, just as there are advantages to have "modernized" the legacy Squeak look-and-feel.

I don't know of any organization backing with lawyers the FreeBSD/NetBSD/OpenBSD (MIT/BSD license) effort and of course that has not avoid using this OSes in real organizations and for mission critical operations.

Maybe that is not *as* necessary as thought.

Miguel Cobá

I know this will mean some work to unruffle some feathers and make things work again for everyone. But I want that to happen.

Randal L. Schwartz wrote:

...

...

...

...

...

"Miguel" == Miguel Enrique Cobá Martinez miguel.coba@gmail.com writes:

Miguel> I don't know of any organization backing with lawyers the Miguel> FreeBSD/NetBSD/OpenBSD (MIT/BSD license) effort and of course that has Miguel> not avoid using this OSes in real organizations and for mission Miguel> critical operations.

The licenses of those projects has not changed, ever.

Squeak has a very different situation, taking a product from private to semi-public to public source, with a lot of contributors putting code in during the "grey area" times.

Actually, wasn't NetBSD bitten by the USL v BSDI & University of California lawsuit which was over licencing of the commercial Unix code that the early BSD code was based on? I'm pretty sure I remember them not being able to make their CVS repo public in the early days because it contained commercially licenced code from the original Unix.

Miguel Cobá wrote:

On Mon, Jun 29, 2009 at 3:07 AM, Douglas Brebnersqueaklists@fang.demon.co.uk wrote:

...

Randal L. Schwartz wrote:

...

...

...

...

>> "Miguel" == Miguel Enrique Cobá Martinez miguel.coba@gmail.com writes: >> >>

Miguel> I don't know of any organization backing with lawyers the Miguel> FreeBSD/NetBSD/OpenBSD (MIT/BSD license) effort and of course that has Miguel> not avoid using this OSes in real organizations and for mission Miguel> critical operations.

The licenses of those projects has not changed, ever.

Squeak has a very different situation, taking a product from private to semi-public to public source, with a lot of contributors putting code in during the "grey area" times.

Actually, wasn't NetBSD bitten by the USL v BSDI & University of California lawsuit which was over licencing of the commercial Unix code that the early BSD code was based on? I'm pretty sure I remember them not being able to make their CVS repo public in the early days because it contained commercially licenced code from the original Unix.

But what about being more practical and take the Linux approach: use the code and, when and if ever, threatened or suited, remove the affected code and rewriting it in order to not infringe copyrights/patents.

That's pretty much what they did except... Firstly, it was almost *all* of the code potentially at risk (it was the code they got from the university that was at issue). Secondly, removing the tainted files required manual surgery to their CVS repository.

2009/6/28 Göran Krampe goran@krampe.se:

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 doesn't need a killer app. It needs to be spruced up and put back on track. Honey moon is over, it's time to get real.

Hehe, I really don't agree. :)

Squeak *is* real. We already have our killer app (Seaside). We do need to clean shit up though (and I am not talking about UI primarily) and get the improvement process working. Currently Squeak.org is getting smashed (again, I don't have hard numbers, but I think I am right) by Pharo when it comes to hard, concrete, nitty gritt work getting 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

Ian Trudel pravi:

Göran Krampe:

...

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... =)

I completely agree with Ian here. If Squeak wants to be considered for serious development, but also to attract developers from other communities and newcomers, it must have the look&feel which is close to theirs. This not mean that it must be the same, no, just that it follows the established look&feel standards elsewhere.

Current Squeak is far away from that, while Pharo is marching well into a more standard look&feel direction. This is actually one of main reasons I'm attracted to Pharo. Also because they listen to such proposals!

But this don't mean that EToys can stay more colorful, no, let it be on top of that more "traditionally professional" base. Why to mix two so different audiences into one image?

Janko

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 doesn't need a killer app. It needs to be spruced up and put back on track. Honey moon is over, it's time to get real.

Hehe, I really don't agree. :)

Squeak *is* real. We already have our killer app (Seaside). We do need to clean shit up though (and I am not talking about UI primarily) and get the improvement process working. Currently Squeak.org is getting smashed (again, I don't have hard numbers, but I think I am right) by Pharo when it comes to hard, concrete, nitty gritt work getting 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

I agree with what Juan and K. K. Subramaniam wrote. Squeak needs a goal, a statement what it is supposed to be. One thing I miss from the old days is the kitchen sink image. Neither Etoys nor Pharo have the goal for delivering such an image. So that could be a good raison d'être: Show what can be done with Squeak, and show what is done with Squeak. Something inclusive, a place for showing off all the cool, interesting, blue plane stuff, which is possible with such a dynamic environment. This attracted me to Squeak in the first place, and I think it still has the potential to attract newcomers.

I miss Connectors, MathMorphs, Alice, Games, ThingLab, Genie, Nebraska and all the other cool things that were once. But maybe it's just me. ;-)

Thanks for your attention.

Cheers, Bernhard

Am 28.06.2009 um 20:02 schrieb K. K. Subramaniam:

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.

Am 28.06.2009 um 16:08 schrieb Juan Vuletich:

Squeak doesn't have a set of objectives and an agenda that is meaningful for developers. And it hasn't had it for a long time. Pharo is new. But Tweak, Croquet and Etoys forked looong time ago. Now you also have Pharo and Cuis. Most developers are contributing to forks, and we only send our stuff for Squeak as a side-effect.

Am 28.06.2009 um 14:57 schrieb Juan Vuletich:

Squeak needs an agenda badly. Something along the lines of the old "Where is Squeak headed" from Dan. Without that, Squeak can't advance in any direction at all. People choosing a Smalltalk for their projects can not know what to expect. Forks can not know if they are needed or not.

Most forks have clearly defined objectives. Etoys, Croquet, Cuis do have them. The objectives for Pharo are broader, and less defined. But Pharo guys know where they are going, and they have some developer time and organization to advance.

Squeak has nothing of this.

The Squeak community needs to define objectives and an agenda for Squeak, or decide that we don't have them, and that the Squeak branch will not be developed further.

On Sun, 28 Jun 2009 23:09:25 +0200, Igor Stasenko wrote:

...

Isn't that made clear to anyone these days: a days of bloated images which includes everything and where everything is working is passed.

...

This so true Igor. And people must stop talking (stop moving the target) how that can be achieved, so that contributors can see the very reason for their working on things.

Otherwise people will continue to go away.

/Klaus

Am 29.06.2009 um 00:34 schrieb Bernhard Pieber:

Am 28.06.2009 um 23:44 schrieb Klaus D. Witzel:

...

On Sun, 28 Jun 2009 23:09:25 +0200, Igor Stasenko wrote: ...

...

Isn't that made clear to anyone these days: a days of bloated images which includes everything and where everything is working is passed.

...

This so true Igor. And people must stop talking (stop moving the target) how that can be achieved, so that contributors can see the very reason for their working on things.

Otherwise people will continue to go away.

I tried to explain in my response to Igor that I think the opposite is true. We lost a lot of people because we did not value their contributions to the full image enough.

+1

Markus

On Mon, 29 Jun 2009 00:34:50 +0200, Bernhard Pieber wrote:

Am 28.06.2009 um 23:44 schrieb Klaus D. Witzel:

...

On Sun, 28 Jun 2009 23:09:25 +0200, Igor Stasenko wrote: ...

...

Isn't that made clear to anyone these days: a days of bloated images which includes everything and where everything is working is passed.

...

This so true Igor. And people must stop talking (stop moving the target) how that can be achieved, so that contributors can see the very reason for their working on things.

Otherwise people will continue to go away.

I tried to explain in my response to Igor that I think the opposite is true. We lost a lot of people because we did not value their contributions to the full image enough.

Peace ;-),

Sure (peace ;) so we have lost for contradicting reasons, as well. Okay then, now wearing my project manger hat:

and now?

/Klaus

Bernhard

On Mon, 29 Jun 2009 01:25:49 +0200, Bernhard Pieber wrote:

Am 29.06.2009 um 00:50 schrieb Klaus D. Witzel:

...

...

...

Peace ;-),

Sure (peace ;) so we have lost for contradicting reasons, as well. Okay then, now wearing my project manger hat:

and now?

Good question! :-)

[...sorry, it's late...]

However, the real answer is: Let's discuss above variants.

No, since we'd be just running in circles.

Let's brainstorm other possibilities for c). Let us argue what the advantages and disadvantages of the different variants are. And let's do it in an objective (How do you translate "sachlich"?) and not emotional manner. ;-)

Yes "sachlich", but I don't get your emotional, who was so?

O.K. we have these forks that happened (counting Croquet as well). Accept it, it is the past.

On the other hand, some here vote for kitchen sink: accept it, but dictate the price. And the price tag is: modularity, everybody can load into a basic .image whatever she/he pleases. Damien and Universe have shown that it works, even if this is always ignored.

Nothing else but modularity will work in the long run. I (for example) am not interested in hunting bugs from kitchen sinkers who have long since run away (or are not responsive).

/Klaus

Cheers, Bernhard

Am 28.06.2009 um 23:09 schrieb Igor Stasenko:

2009/6/28 Bernhard Pieber bernhard@pieber.com:

...

I agree with what Juan and K. K. Subramaniam wrote. Squeak needs a goal, a statement what it is supposed to be. One thing I miss from the old days is the kitchen sink image. Neither Etoys nor Pharo have the goal for delivering such an image. So that could be a good raison d'être: Show what can be done with Squeak, and show what is done with Squeak. Something inclusive, a place for showing off all the cool, interesting, blue plane stuff, which is possible with such a dynamic environment. This attracted me to Squeak in the first place, and I think it still has the potential to attract newcomers. I miss Connectors, MathMorphs, Alice, Games, ThingLab, Genie, Nebraska and all the other cool things that were once. But maybe it's just me. ;-)

I'd like to ask, where those people who care maintaining these bits , making them available for new squeak versions, improving them, adding new features and so on? If there none of them, then how do you think, why is that? And why people, who does not interested in this stuff at first place, must do anything to maintain it? Do they have nothing else to do?

Maybe some of them were not interested in maintaining it further because someone else broke their code for no good reason from their point of view?

That's why i am totally agree with Pharo vision on that: they don't want unmaintained stuff in Pharo, that's why one of the Pharo milestones is to clean the Morphic from Etoys and other unmaintained stuff.

Etoys is all but unmaintained. And Juan has tried to maintain Morphic as far as I know.

And i share their approach on that: if you want your stuff to be able to work with base image, then provide a script/package/loader , or whatever is needed to load it into basic image and maintain it. If your package can't be loaded w/o errors, then it is your problems, not the problems of people who developed core image.

I don't agree at all that that was a wise move. I think Squeak lost a lot of existing and potential contributors by saying: "If you want your code to continue to work in Squeak, you have to constantly adapt to our changes." I think that is what Stéphane Rollandin was trying to tell us. I am convinced that the separation of the base and the full image and the concentration on the base instead of the full image was the reason why forks were inevitable. Starting refactoring was necessary and a very important service for the community, but it had to have been done in the full image! My argument is basically that of Wolfgang Eder from July 2006: http://www.nabble.com/Proposal-for-a-Squeak-migration-meeting-ts4867570i120.... That is still a very relevant thread today, by the way.

Isn't that made clear to anyone these days: a days of bloated images which includes everything and where everything is working is passed.

Obviously, it is not clear to me. ;-) Seriously, I have thought a lot about it and I am convinced that the kitchen sink image was Squeak's main attraction. The moment we lost it we started losing contributors.

Because there are people who need to deploy stuff on server (to run Seaside or Wiki, or other services), and if you put bloated stuff there, and try to scale, the people around will start asking, why it consumes so much resources?

Note, that I am not saying that the kitchen sink image could or should not be put together from a small image and nicely modularized packages. What I am saying is that if you clean up only the base image you will never be able to put together the full image because I guess many of the maintainers will not bother to repair stuff others broke. Worse yet, they probably will not bother anymore to create more cool stuff.

See, I can follow your reasoning. And it sounds very convincing. Therefore, I am not blaming anyone for going that route. I am totally sure everyone had only the best intentions. Nevertheless I am totally convinced it was a really bad idea and it still is, because that way you lose contributions and contributors.

Cheers, Bernhard

2009/6/29 Bernhard Pieber bernhard@pieber.com:

...

Am 28.06.2009 um 23:09 schrieb Igor Stasenko

Note, that I am not saying that the kitchen sink image could or should not be put together from a small image and nicely modularized packages. What I am saying is that if you clean up only the base image you will never be able to put together the full image because I guess many of the maintainers will not bother to repair stuff others broke. Worse yet, they probably will not bother anymore to create more cool stuff. See, I can follow your reasoning. And it sounds very convincing. Therefore, I am not blaming anyone for going that route. I am totally sure everyone had only the best intentions. Nevertheless I am totally convinced it was a really bad idea and it still is, because that way you lose contributions and contributors.

I will answer on this separately. Obviously people stop contributing because of failure of communication/development model. Iff we would have a separate modules, communicating with each other on well defined protocols, then none of the above problems, which you listed is taking place, or more correct to say - they are moving into a different plane. People will communicate with each other, and if someone will change the interfaces towards improving the overall design, then i don't see the reasons why others who using it, will stop doing own stuff and run away.

An opposite, when everyone depends on a single, alma-mater image , any radical changes in it will lead to major break down in multiple projects/development areas. Because everyone depends on a single entity - bloated image, instead of being dependant on a much smaller, flexible, vibrant & easily adoptable modules.

You can yell on a list: who is maintainer of kernel? who is maintainer of morphic? who is maintainer of squeak? None. It is impossible to maintain such a big code base by a single person. We need to split responsibilities, establish a new development/communication model. Only then you can get the answers in a minutes, whether your package will work with X.Y.Z image/module or not, and what you need to make it working.

...

Cheers, Bernhard

-- Best regards, Igor Stasenko AKA sig.

2009/6/29 Edgar J. De Cleene edgardec2001@yahoo.com.ar:

On 6/28/09 8:24 PM, "Igor Stasenko" siguctua@gmail.com wrote:

...

It is impossible to maintain such a big code base by a single person. We need to split responsibilities, establish a new development/communication model. Only then you can get the answers in a minutes, whether your package will work with X.Y.Z image/module or not, and what you need to make it working.

So Igor, why when years ago I fight every guy asking for a strict "people don't should mess others people work" you disagree ?

I agree. But squeak is very permissive on that. So, whatever you or me will say - people just keep doing things what they think is good for them.

Was the "Czar of packages" idea .

Edgar

Hi guys!

Bernhard Pieber wrote:

...

If those words didn't convinced you that maintaining & developing a bloated images, instead of separate, well defined modules is road to void, then nothing else can.

I am afraid you did not convince me. I do think that maintaining a full image is better.

Please note the huge amount of packages available on SM, SS etc. I am not sure who were around at the time, but one REAL problem back then was that if you did NOT make it into the image - you were left on the cold outside and had to manually maintain your addon package.

But wait... so, ok, if you DID get (your package) into the image then SqC at the time spent some of that time *for you* since they could relatively easily see if they broke something (class refs, senders of, implementors of etc). And hey, they could just try to run it too :)

But they ran a rather small kitchen.

Now, let's imagine putting all of SS/SM into a super mother of a kitchen. Lots and lots and lots of packages. Some conflicting with each other (oops), some really hard to understand, some left for dead by their original authors etc etc.

It just won't fly. Better IMHO to make it easy to live outside the image by:

- Use unit tests. If you are green, you are green. - Get good build and delivery tools. We have a bunch and more to come. - Get more advanced tools for managing code between images. DeltaStreams is one try on that. - Perhaps even add some database to the mix for global senders/implementors/class refs!

Anyway, all this has been said already. I am sorry, I really don't believe in the kitchen sink UNLESS you have a specifically targeted image.

regards, Göran

2009/6/29 Igor Stasenko siguctua@gmail.com:

2009/6/29 Bernhard Pieber bernhard@pieber.com:

...

Hi Igor,

First of all: Thanks for taking so much time discussing with me. I get the feeling that somehow my point of view is frustrating you. That is not my intention.

Am 29.06.2009 um 01:01 schrieb Igor Stasenko:

...

I don't know how you quoted my mail, but gogle thinks its not quoted . So its became unsorted.

Sorry about that. I am using Apple Mail.

...

...

Maybe some of them were not interested in maintaining it further because someone else broke their code for no good reason from their point of view?

or maybe because they were too optimistic about that once their stuff have been included once in the bloated image, they don't need to support it anymore. Now imagine the situation: each time you want to improve something, or change it radically , you deemed to be too cautious about that, because there are tons of things, which using this stuff, monkey patching different parts of it, up to the point that there is impossible to find out , where ends a basic interface and where starts the custom extensions, added by different little-toy projects over a years of bloated image existance.

I concede that some of the maintainers may well have been too optimistic. Well yes, I can remember the situation. I did a small refactoring once and the code was let's say quite in need of refactoring. Maybe I even broke something, however I tried hard not to.

...

...

I don't agree at all that that was a wise move. I think Squeak lost a lot of existing and potential contributors by saying: "If you want your code to continue to work in Squeak, you have to constantly adapt to our changes." I think that is what Stéphane Rollandin was trying to tell us. I am convinced that the separation of the base and the full image and the concentration on the base instead of the full image was the reason why forks were inevitable. Starting refactoring was necessary and a very important service for the community, but it had to have been done in the full image! My argument is basically that of Wolfgang Eder from July 2006:

http://www.nabble.com/Proposal-for-a-Squeak-migration-meeting-ts4867570i120.... That is still a very relevant thread today, by the way.

See my above part, why i think that refactoring a bloated image isn't possible, not saying that its very error prone.

I agree it is more work. Maybe even much more work. Terribly frustrating. However, impossible? No!

...

And again, where do you find so dedicated people, who will spend hundreds of hours trying to improve the code?

Good question. Let's say someone is willing to spend 100 hours. If he spends the same 100 hours caring about backwards-compatibility he is much slower. I agree. On the other hand he might keep a contributor or better yet win one because one cool feature still works. I concede that it is difficult to assess that tradeoff. We definitely seem to have very different feelings about which factor is bigger.

...

Take a look at Morphic, to what state it was progressed. Tons of methods (over 600 methods in Morph class). Do you really think that we need all of them in most basic class? I doubt that. It is a bloat, certainly. If class requires so many methods, maybe its worth splitting it on number of smaller ones? But who i am to teach you programming.

I totally agree here. And I not at all against refactoring. Quite to the contrary!

...

I can tell you what is happening , when no-one cares about maintaining things separately, in good share: people is LAZY and tend instead of learning, how things can be done by reusing the existing code, putting own extensions to existing code, and in result we got classes with over 600 methods. And no-one cares.

I do care! I have very, very high quality standards! Relly! Ask my collegues! ;-)

...

But when someone raises a head and trying to say, lets wipe it up - he get burned as heretic, because it will break the holy backwards compatibility grail.

Some may have criticised those unfairly so that one might say they were "burned as heretic". I must say, I don't think such exaggerations are helpful. But please concede that I have not done that! On the contrary, I wrote:

...

...

See, I can follow your reasoning. And it sounds very convincing. Therefore, I am not blaming anyone for going that route. I am totally sure everyone had only the best intentions.

...

If those words didn't convinced you that maintaining & developing a bloated images, instead of separate, well defined modules is road to void, then nothing else can.

I am afraid you did not convince me. I do think that maintaining a full image is better. However, I feel there is still a misunderstanding. That full image should consist of well defined modules. I don't think those two things are necessarily contradictory. However, thanks again for bearing with me!

Let me illustrate another thing:

• making a little change in a big image

vs

• making a little change in an isolated module

when you doing first, how you can be sure that you didn't break anything? by testing things which working with it? But this is only for things, which is included in you fat image. Okay, it may work. But can you be sure that your changes will work as well for every existing package for squeak? No! So, its a controversial to say , that ANY change in a fat image is backwards compatible. There is no such thing.

So, i wonder, what you found so repulsive in Pharo's statement, proclaiming that they are not backwards compatible. Neither kitchen-lovers do.

Instead, if you changing something inside a module - you either making changes in private areas, then it is guaranteed to be compatible with any users of your module, or changing the protocols - then inevitably the communication gets in a game and its your straight responsibility to announce to all interesting parties what has changed and how they could adopt to new version of your module, if they want to upgrade to it.

...

Peace, Bernhard

-- Best regards, Igor Stasenko AKA sig.

Earlier someone wrote a nice list of packages that aren't working anymore... many of these packages weren't replaced. Worse: many packages appear in Universes (for instance) but cannot be loaded (example: try to load Monticello 1.6 and you'll have an infinite loop while trying to load Monticello 1.5. Then you may ask: what you want Monticello 1.6 for? Like for installing Balloon3D from Universes ??? But then B3D is broken too...at least in Scheduler...).

Which is why there is a package@lists.squeakfoundation.org to discuss these very same issues.

If you dont tell anyone you have a problem, then how can you expect it to be fixed?

Keith

Em 28-06-2009 21:40, Igor Stasenko escreveu:

(...) Automagically by you, since you currently a release team member and must pay attention to every bit of code ever written for squeak :)

...

(...)

Not the case for any kind of summoning. But there should be some level of testing. At least to detect dead links to repositories and to detect orphaned packages. If a package is orphaned long enough, there should be a policy for tagging and moving it to a special place... Regarding to orphaned packages I like Fedora model for announcing it and seeking for new maintainers. I also think that their model for responsibility delegation chain (it is far from perfect and sometimes not quite "democratic" but works most of time) is quite reasonable.

But I guess that open software community is quite rich of good examples for maintaning distributed development.

This discussion resembles other inside Fedora community: what should be in/out of a distro and how to maintain it. There are three proposals: Squeak, Pharo, Cuis. I'll tell you what I don't like in Pharo/Cuis proposals: they resemble me Brazilian way of solving things: you have something that's just not working as you wish. Instead of correcting the circumstances that lead to the problem, people start a new project saying: "now everything will be all right". Later the so called solution is suffering from the same problems and people launches a newer project to fix what went wrong with the predecessors. And there are 3 projects running in parallel. Redundancy of effort, high costs (even in terms of dedication of people struggling to keep pace in what is happening around) and futile disputes are the only results.

I think there's nothing fundamentally wrong with squeak. The question is how to organize things. How to classify things as "core", "contributed" and "3rd party". How to keep things up to date. How to obsolete things.

It may be boring, but I think that many things could be formalized.

* First there are the leadership meetings on Wednesdays. The agenda of the meetings as well as their minutes could be placed at the www.squeak.org/Foundation. There should be a place where people could suggest topics to be included in the agenda. I know that much has been done via e-mail lists but for people (like me) who have to deal with large amounts of email these lists may be unpractical. Besides, keeping things public is a good way for letting people decide if they want or don't want to use squeak.

* As this discussion (about future of Squeak & Pharo) made clear, it is urgent to define what is in and what is out of Squeak. Since there's a real concern about back compatibility and as things are getting big and sometimes non-maintained, I would suggest that documenting things is essential.

* In my opinion, it would be interesting to create a mechanism for responsibility delegation regarding to maintenance. Regarding to distributions it would be interesting to create a mechanism for evaluating the suitability of packages to be included (like looking that the packages don't have dependencies outside the distribution and things that can lead to a situation where it is impossible to assure their maintenance). I don't think that a situation where a single person is responsible for a critical part of a distribution is acceptable: whenever such situation is identified the leadership should seek for additional people.

* In my opinion, it would be good if some sort of financial/corporate support could be granted. It would allow to have people involved in "non exciting" tasks. Again: corporate support doesn't translate in any kind of servitude and it can help to grow the universe of Squeak users. Besides, good marketing is essential: if you get good media it is more likely you'll be granted more and better projects... more people will pay attention to you.

Just a last thing about croquet. It was meant to rock but didn't... I tell: (1) poor documentation (how in hell I use it???) (2) lack of marketing (yeah... even inside university good marketing is essential). Many people just didn't figured out what it was meant to (3) performance issues (intensive use of GL, etc).

Good night all,

CdAB

On 6/28/09 11:32 PM, "Igor Stasenko" siguctua@gmail.com wrote:

where are those people who stop talking and start doing something?

Here in Argentina we have Cuis, SqueakLightII, SqueakNOS, and many more. What you don't like don't means we don't work

Edgar

...

...

...

...

"Casimiro" == Casimiro de Almeida Barreto casimiro.barreto@gmail.com writes:

Casimiro> IMHO, I think that Squeak.org should be seeking for objectives Casimiro> (medium/long term), support and popularization.

Indeed... this is pretty much agreed amongst the current SOB. However, *before* we want to nudge resources in that direction, we *need* to get the license clean. And that's currently in process, although taking time.

It would be really bad to have a huge promotion campaign for squeak right now only to have people come and find a code freeze and an uncertain license.

On 6/29/09 12:21 PM, "Juan Vuletich" juan@jvuletich.org wrote:

Maybe all this is plain wrong for many. Maybe it will bring new problems. But it will indeed avoid the situations to repeat in the future..

Not wrong as I understand the goal and send mails to some members private saying Cuis should be the stone on which we could build a better Squeak.

Pero mi querido Juan, podrías ser un poquito mas abierto y dejar que cooperemos sin "ensuciar" el Cuis ?

Edgra

Juan Vuletich wrote:

It also says:

• Lead by Juan Vuletich (jmv) after these principles.

I think this might be the most important bit.

Squeak seems to lack anyone you can point to who has the authority to stand up and say "We're doing it this way. Don't like it? Too bad." and make it stick.

Or more importantly, anyone who's *visibly* in that position, the board seems kinda amorphous, even bureaucratic that way.

Casimiro de Almeida Barreto wrote:

... This discussion resembles other inside Fedora community: what should be in/out of a distro and how to maintain it. There are three proposals: Squeak, Pharo, Cuis. I'll tell you what I don't like in Pharo/Cuis proposals: they resemble me Brazilian way of solving things: you have something that's just not working as you wish. Instead of correcting the circumstances that lead to the problem, people start a new project saying: "now everything will be all right". Later the so called solution is suffering from the same problems and people launches a newer project to fix what went wrong with the predecessors. ...

I don't agree with this at all. The biggest problems Cuis and Pharo are trying to fix are the endless discussions, the weak leadership and the impossibility to build consensus in fundamental decisions.

These problems will not happen again in Pharo or Cuis. At least not in Cuis.

Cheers, Juan Vuletich

2009/6/29 Janko Mivšek janko.mivsek@eranova.si

Juan Vuletich pravi:

...

I don't agree with this at all. The biggest problems Cuis and Pharo are trying to fix are the endless discussions, the weak leadership and the impossibility to build consensus in fundamental decisions.

I agree completelly!

Me too. The fact is that committee and consensus based process, while it can work, will always be much slower and often unsatisfactory to a large percentage of the community (until our intellects are all intimately coupled (like the Borg), I suspect this will remain the case). I see no reason to merge squeak with pharo, cuis or eToys. These forks of squeak are successful in large part because they forked from the main squeak. They are driven by people that have a very specific vision of what they want and there happen to be other people that believe in that same vision and contribute. They don't have to seek approval or build any sort of consensus from any committee. They alone get to decide to what degree they listen to their own community.

- Stephen

Em 28-06-2009 21:34, Keith Hodges escreveu:

...

Earlier someone wrote a nice list of packages that aren't working anymore... many of these packages weren't replaced. Worse: many packages appear in Universes (for instance) but cannot be loaded (example: try to load Monticello 1.6 and you'll have an infinite loop while trying to load Monticello 1.5. Then you may ask: what you want Monticello 1.6 for? Like for installing Balloon3D from Universes ??? But then B3D is broken too...at least in Scheduler...).

Which is why there is a package@lists.squeakfoundation.org to discuss these very same issues.

Excuse-me. Perhaps I informed in the wrong list (remember posting it here about some months ago)...

If you dont tell anyone you have a problem, then how can you expect it to be fixed?

Keith

On 29.06.2009, at 01:30, Casimiro de Almeida Barreto wrote:

But how to use Scratch for basic school students if it comes in English and Squeak just doesn't have anything like i18n...

I don't know where you got that idea. Scratch is fully localized in about 20 languages. Same for Etoys (though in the Etoys image we translated everything, including the Smalltalk tools, so the task for translators is much bigger).

- Bert -

2009/6/28 Ian Trudel ian.trudel@gmail.com:

2009/6/28 Göran Krampe goran@krampe.se:

...

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" :)

Sometimes being popular means doing normal things. Smalltalk is an unusual programming language (in the sense of mainstream) with an overly eccentric environment in Squeak. Then there are Croquet, Etoys, and so on. It's hardly a break through if it's only "more" eccentric than eccentric. Don't you think?

The look-and-feel is designed for children. It's colourful, joyful, it bleeps and blink. How many professional developers are children? How many children are on this list? Enough with that already! Can we have a normal look-and-feel? A professional look-and-feel. =)

From time to time I see someone claiming to fit Squeak aesthetics into

the cognitive style of the ordinary programmer-producer (or consumer) of standard software, supporting this proposal under the authority of the professionalism and the norm (which must be, of course, an external jury). There is a famous example of uniformity that is related to the Henry Ford's black Model-T mass production in 1908 : "Everybody can get a car in the color he desires, provided it is black". But today we have cars in many colors. So what happened?

Maybe some people understood that the economic forces are not the only drivers of our monolithic societies. Maybe some individuals wants what's called lifestyle, or express identification with a particular subculture. Maybe this isn't news at all as totalitarian technocracy trends exists since Industrial Revolution times (do you still write a lot of handwritten letters?), and they are merged into a complex framework of relationship with tools attacking culture, the role of integration into a technopoly, economy of niches, etc.

Making a crude generalization, I think we have an interesting case here. An unresolved tension between uniformity versus diversity. The question seems to be if uniformity enables diversity at the last stage in every individual's choice. Or this uniformity will restrict individual freedom because as modern technology advances, the degree of uniformity and regulation that restricts individual freedom advances too? (for the curious mind, in socioeconomic analisys the question if the massive standarization of products will restrict us or give new choices is still a bit unanswered, partially related with the goodness of freedom of choice)

But here we have arguments from varied sources, I usually group them in two subjective non-disjoint categories:

1) Sources (people) interested in selling or popularizing 2) People not interested in Smalltalk/Squeak popularization (or not so).

I've read some defending positions for 1), so I will make a support for 2). One of the nice things in Squeak is, with all its defects, still doesn't seem to be adapted to a marketing program (product formulation, positioning, naming, advertising, distribution, etc), with all the consequences of that: assuring participation into the market because the strategic product planners will die if they don't look so "professional" like its competitors, always trying to fit into external unknown aesthetic patterns, today the colors are wrong, tomorrow anything else, maybe one of those emerging usability frameworks states as bad thing, etc.

To my view, Squeak doesn't fit very well with the production-line programmer-worker.

Then, my vote is not positive for color uniformity in Squeak :)

Hernán

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 doesn't need a killer app. It needs to be spruced up and put back on track. Honey moon is over, it's time to get real.

Regards, Ian.

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

On Sun, Jun 28, 2009 at 10:31:08PM -0300, Hern??n Morales Durand wrote:

To my view, Squeak doesn't fit very well with the production-line programmer-worker.

Then, my vote is not positive for color uniformity in Squeak :)

+1

Dave

Dear Ian, I really understand your position, because I hated the Squeak UI for almost one year, until I started to read about Color Theory and Cognitive Pshychology and understand some things about it. However, each soul has to convince by himself or do something about it.

Let me put my feelings into the words of Schoenberg, he once said : "Art is not for everyone; and if it is for everyone, it is not Art.". And I believe pretty much the same here : "Smalltalk is not for everyone; and if it is for everyone, then it is not Smalltalk".

Cheers,

Hernán

2009/6/29 Ian Trudel ian.trudel@gmail.com:

2009/6/28 Hernán Morales Durand hernan.morales@gmail.com:

...

To my view, Squeak doesn't fit very well with the production-line programmer-worker.

Then, my vote is not positive for color uniformity in Squeak :)

Hernán

Hello Hernán!

This is a very passionate text to unveil your opinion. Thank you. Do not get me wrong on my ideas: they are not about striving for conventionalism but rather suggesting an avenue of solution that might eventually be suitable and feasible.

You might well convince me that an ergonomics based on any popular professional tools is not the optimal solution for Squeak. However, don't tell me that the current UI is suitable for grown-up programmers and professionals. It is not. Childish, confusing, undocumented, ugly, outdated and "eccentric". Have better ideas than mine? Be my guest. =)

The issue is important because the growth rate of the community is low and a certain amount of existing members move to other forks. Hernàn, you're using Squeak for some time already. You can customize Squeak UI as you deem necessary. Others might not. Morphic has no viable documentation. We need a standard image with something visually and ergonomically appealing, something approachable.

I have tried to introduce Squeak to acquaintances but it failed in general. One of the common reason is the "weird" interface. What can I do about it? Kick them in the nuts and tell them they don't know what they're talking about? =)

The colour scheme doesn't really matter, does it?

We could be rebel and eccentric on other things than colours. I think...

Then we don't want to change colours because it upsets some in the community. "Everybody can get Squeak with the features he desires, provided it is backward compatible." What will happen when the community desires a feature that will inflect such changes that will not be backward compatible? Well, we do have constraints. Heck, I've been told that we are unlikely to have international keyboard input because its implementation would certainly break the compatibility... oh, gee...

It's not that I want to be controversial... simply, I think, we should not toss away the idea to be appealing to a greater mass, especially if it helps Squeak to survive and move forward. It's not like we need less manpower...

Regards, Ian

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

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

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.

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

On Sun, 28 Jun 2009 21:21:28 +0200, Bernhard Pieber wrote:

Hey, this looks great!

:)

Care to explain more about what you are working on? What are your goals? I really like the fact that it is loadable into three of the forks. ;-)

three of the forks: a "simple" side effect by the very developer who's responsible for the rendering part, he prefers subclassing of existing Smalltalk libs.

BTW: Cuis has no WideString but will probably be the fastest of the three.

goals: render _every_ glyph that is in _any_ modern (Unicode) platform font; make fonts offline and online usable, especially on small devices if needed, on demand (by end user).

working on: three parts 1) fonts/glyphs without new plugins/VM support; 2) glyphs "char" map visualization (for end user support); 3) glyph composition (for complicated scripts which need more than one glyph per "character" location).

Have an application in mind which we can add for doing tests?

/Klaus

Cheers, Bernhard

On Sun, 28 Jun 2009 22:08:01 +0200, Bernhard Pieber wrote:

Am 28.06.2009 um 21:50 schrieb Klaus D. Witzel:

...

BTW: Cuis has no WideString but will probably be the fastest of the three.

Sound great! Cuis looks very promising!

...

goals: render _every_ glyph that is in _any_ modern (Unicode) platform font; make fonts offline and online usable, especially on small devices if needed, on demand (by end user).

Sounds cool. What do you mean by offline and online usable?

If a company/organization bought/licensed some special font, or the font is in public domain, and you don't want to install it on every PC or every device, then we can make it part of the Smalltalk .image file.

...

Have an application in mind which we can add for doing tests?

I am thinking about a kind of a special purpose, offline replicating, non-web wiki, with something like CouchDB as the persistence layer.

If you would need support for any/mix of these scripts,

- http://unicode.org/Public/UNIDATA/Blocks.txt

then our font/glyph support can be interesting for you.

...

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

That quote probably fits my project. ;-)

:)

/Klaus

2009/6/29 K. K. Subramaniam subbukk@gmail.com:

On Monday 29 Jun 2009 1:20:50 am Klaus D. Witzel wrote:

...

working on: three parts 1) fonts/glyphs without new plugins/VM support; 2)   glyphs "char" map visualization (for end user support); 3) glyph composition (for complicated scripts which need more than one glyph per "character" location).

That is a laudable set of goals. The third part is especially interesting for stroke-based characters in Indic/Arabic scripts. I can help with Kannada (U0C80) and Tamil (U0B80) fonts. How was the picture produced?

Simple: bring up the morph's halo (workspace) , then click red halo button - menu, and then export -> PNG file.

:)

Subbu

On Mon, 29 Jun 2009 11:01:37 +0200, K. K. Subramaniam wrote:

On Monday 29 Jun 2009 10:54:29 am Igor Stasenko wrote:

...

2009/6/29 K. K. Subramaniam subbukk@gmail.com:

...

On Monday 29 Jun 2009 1:20:50 am Klaus D. Witzel wrote:

...

working on: three parts 1) fonts/glyphs without new plugins/VM

support;

...

...

2. glyphs "char" map visualization (for end user support); 3) glyph

composition (for complicated scripts which need more than one glyph

per

...

...

"character" location).

That is a laudable set of goals. The third part is especially

interesting

...

for stroke-based characters in Indic/Arabic scripts. I can help with Kannada (U0C80) and Tamil (U0B80) fonts. How was the picture produced?

Simple: bring up the morph's halo (workspace) , then click red halo button - menu, and then export -> PNG file.

I meant how were glyphs rendered in Squeak? currently 3) is supported only through rendering engine plugins. I thought Klaus had dvipng [1] equivalent working natively in Squeak.

Ah, no, as written earlier we just use existing libs/VM/plugins and some new Smalltalk code. The picture was taken from a Cuis workspace from inside the .image, as Igor wrote, no magic.

Sorry for being a bit vague at the moment ;)

/Klaus

[1] http://savannah.nongnu.org/projects/dvipng

Subbu

2009/6/28 Klaus D. Witzel klaus.witzel@cobss.com:

... goals: render _every_ glyph that is in _any_ modern (Unicode) platform font; make fonts offline and online usable, especially on small devices if needed, on demand (by end user).

So you have to select the font and you don't select it using #leadingChar?

Cheers Philippe

2009/6/29 Igor Stasenko siguctua@gmail.com:

2009/6/29 Philippe Marschall philippe.marschall@gmail.com:

...

2009/6/28 Klaus D. Witzel klaus.witzel@cobss.com:

...

... goals: render _every_ glyph that is in _any_ modern (Unicode) platform font; make fonts offline and online usable, especially on small devices if needed, on demand (by end user).

So you have to select the font and you don't select it using #leadingChar?

Btw, can someone explain me, what is a #leadingChar in Character, and how it affects the output/input & different encodings/text representation?

At some point when rendering text you need to know the language of it. You could put this information in a lot of different places like paragraph, document, whatever. However since an interned integer on Squeak currently has 30bits available and Unicode is a 22bit character set why not take that 8 spare bits put that information into each character? Yeah, there some minor limitations like there are way more than 255 languages in the world and for any latin-1 character you wouldn't be able to set the language and if you wanted to use unicode you're supposed to set the language of non-Latin1 characters to something different than the one of the Latin-1 characters. It could kinda work if there was only one image, sort of. These days you'd probably use FreeType to get nice text rendering which doesn't need or use the information at the character level but anyway.

Now it starts to get funny when you're interacting with the outside world. They are not likely to use Squeak so they don't pass language information at the character level to you. So what language do you use for incoming characters? Well isn't really defined because it never really was designed to handle that.

Seaside kinda tends to communicate with the outside world, you see the problem? And our code ideally should also run on GemStone, VAST, VW, ....

Oh, and the language is of course taken into account for #=. That's funny because the strings you get could come from anywhere: database, ui, file, .... where you have no control whatsoever over what language is used. It could also have been done on a different computer with a different language setting.

Cheers Philippe

At Mon, 29 Jun 2009 22:30:31 +0300, Igor Stasenko wrote:

So, do i understood you right: this information (leadingChar) could be useful sometimes. But real world examples showing that its completely useless , at least by now. And often only adds an unnecessary complexity & confusion in handing a text & communicating with world outside the Squeak.

Well, but Squeak in Chinese/Japanese/Korean have been using it and depending on it, so this characterization is not correct.

-- Yoshiki

At Tue, 30 Jun 2009 13:16:54 +0530, K. K. Subramaniam wrote:

On Tuesday 30 Jun 2009 3:09:15 am Yoshiki Ohshima wrote:

...

At Mon, 29 Jun 2009 22:30:31 +0300,

Igor Stasenko wrote:

...

So, do i understood you right: this information (leadingChar) could be useful sometimes. But real world examples showing that its completely useless , at least by now. And often only adds an unnecessary complexity & confusion in handing a text & communicating with world outside the Squeak.

Well, but Squeak in Chinese/Japanese/Korean have been using it and depending on it, so this characterization is not correct.

The essential problem is the encoding of characters (graphemes) which have regional or lingual variations. Devanagari also has such examples. The grapheme 'a' is rendered differently in Bombay and in Calcutta. Should the variations be encoded in the context or in every grapheme codepoint?

Well, don't you rather say Mumbai and Kolkata?

leadingChar is just one way to resolve such variations. Personally, I prefer handling such variations as part of the context. A grapheme is a notional element. We need to encode it so that we can input, calculate, combine, compare and sort notional elements. Visual appearance becomes important only for manual edit and print operations.

I guess I understand your point, but not sure what you would do to implement "encode in the context".

-- Yoshiki

2009/6/29 Yoshiki Ohshima yoshiki@vpri.org:

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

...

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 ....

For Seaside you don't need to display the string so you can just ignore it.

Nope, because in Seaside sometimes we like to compare strings and #leadingChar is taken into account for #=. And we have to write code that runs on other systems. And we have to map characters to bytes and bytes to characters.

...

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*.

This is a very confused statement.  You better pass the font and language information to the outside renderer to get the proper result.

I agree but you don't know how often I have gotten this answer when I suggested to simply drop #leadingChar.

Cheers Philippe

Yoshiki Ohshima wrote:

Yeah, but insisting to use #= to do it seems to be a wrong goal Define seasideEqual: and use it elsewhere would be better.

You'd have to change too many places for this to be feasible. For example, consider Set and Dictionary operations which may have to be changed in this process.

...

And we have to map characters to bytes and bytes to characters.

Everybody does. Not sure why it is relevant.

Because a simple conversion like squeakToUtf8/utf8ToSqueak is not lossless anymore. The problem is that Unicode is Unicode is Unicode ;-) You can either use it and live with its shortcomings or you can write something completely different. But as soon as one tries to redefine it partially it leads to problems since there are too many surrounding assumptions.

...

I agree but you don't know how often I have gotten this answer when I suggested to simply drop #leadingChar.

Maybe you get the answer often because it makes sense? I wrote this a few times in last some years but if the goal is to make a comprehensible personal computer environment, some information is needed more than Unicode code points provides.

Yes, but it is not clear whether that information belongs into the string itself or in its surrounding context. The argument that a language should be part of the string itself can certainly be made but it neglects the necessity of interacting with the outside world. And in the outside world (meaning Unicode) the language tag isn't part of the string but rather part of the context. Consequently, I think that Squeak should follow similar semantics (imperfect as that may be for some uses) and have language information associated with class Text (i.e., a text attribute) not with class Character (leadingChar).

Cheers, - Andreas

2009/6/29 Yoshiki Ohshima yoshiki@vpri.org:

At Mon, 29 Jun 2009 00:38:16 -0700, Andreas Raab wrote:

...

Yoshiki Ohshima wrote:

...

Yeah, but insisting to use #= to do it seems to be a wrong goal Define seasideEqual: and use it elsewhere would be better.

You'd have to change too many places for this to be feasible. For example, consider Set and Dictionary operations which may have to be changed in this process.

Right.  And Phillippe can strip the leading char when he wants.

That's what we try do and it's such a pain. We'd have to do it for every sting that we get from anywhere. At which point string handling in Smalltalk is harder than in C and has similar pitfalls.

...

...

...

And we have to map characters to bytes and bytes to characters.

Everybody does.  Not sure why it is relevant.

Because a simple conversion like squeakToUtf8/utf8ToSqueak is not lossless anymore. The problem is that Unicode is Unicode is Unicode ;-) You can either use it and live with its shortcomings or you can write something completely different. But as soon as one tries to redefine it partially it leads to problems since there are too many surrounding assumptions.

From another POV, the communication with outside world was secondary.

No kidding, I noted.

The .changes in in UTF-8 but has the additional information always so it is lossless.

...

...

...

I agree but you don't know how often I have gotten this answer when I suggested to simply drop #leadingChar.

Maybe you get the answer often because it makes sense?  I wrote this a few times in last some years but if the goal is to make a comprehensible personal computer environment, some information is needed more than Unicode code points provides.

Yes, but it is not clear whether that information belongs into the string itself or in its surrounding context. The argument that a language should be part of the string itself can certainly be made but it neglects the necessity of interacting with the outside world. And in the outside world (meaning Unicode) the language tag isn't part of the string but rather part of the context. Consequently, I think that Squeak should follow similar semantics (imperfect as that may be for some uses) and have language information associated with class Text (i.e., a text attribute) not with class Character (leadingChar).

I should say I've been agreeing with it for a while, but it also is a huge unstabilier to the existing system.  Now Pharo people may be able to leap the gap, if they like.

I totally see the need to know the language of text to render. But the character is the wrong place to store it, seriously.

Cheers Philippe

Hi Dan!

(Watch out - rambling ahead)

Long time no hear. :)

Dan Ingalls wrote:

Good people -

Whatever the impetus, it's good to see this recent spate of self-examination.

Yep, indeed.

When I look back on the early days, we had a cycle where we would use the old system for all it was worth (even with ugly hacks), exploring some current set of initiatives, and *then* we would fall back to clean things up and integrate what we learned in the latest push.

Maybe that's what's happening now, but I feel the absence of some of those big challenges that motivate and reward real progress (not to make little of the current efforts). These could include...

Take advantage of multicore processors and associated
multi-thread OS's in our VM design(s).

Yeah, I am unsure if Cog has anything in this area. We do have the Hydra base, and personally I am quite impressed that Huemul actually has native POSIX thread == Process!

I presume the "perfect" setup is green Processes running on a pool of native threads. Thus preserving the "light weight" of Process and still be able to utilize cores.

I also would like to note that while it would be COOL to be able to scale on cores - the *reality* is that most apps we write in Squeak that *needs* to scale is typically web apps. And you scale web apps horisontally using multiple VMs and a load balancer, no big deal.

So it doesn't really matter how cool it would be - it is not a "killer" feature IMHO.

But the scalability of Erlang would open up new frontiers. :)

Demonstrate real ease of use in tapping that new
dimension of performance.  Linda and E are relevant.

Press at least one good JIT design through to completion
document it, and keep it alive on every platform.

I presume Cog is our hope? The latest "news" in this area is that Eliot mentioned he is looking closer at the JIT in Factor (factorcode.org) and even considers porting it! And lots of JIT libs around these days, Nanojit in Tracemonkey, libJIT etc etc.

But one thing is true - performance *kicks ass*. We may go on and on about how "unimportant" performance is but darnit, it really is a killer feature if we had a REAL fast VM whupping the Pyhon/Rubys. ;)

Make it easy to produce Squeak apps for the iPhone
and similar platforms for which it seems so perfect.

Mmmm, most such platforms have their "own" UI which you really need to adhere to. I think simple interpreters that very easily can play with external libs have the upper hand here. Think Python.

Bring Squeak to life in browsers.
OMeta + V8 + Canvas = Squeak everywhere, including
behind firewalls and where installation is prohibited

Cool yes. Killer feature? Nope, don't think so.

Get serious about security.  Take another look at ESqueak
and figure how to make it just a bit simpler

Doesn't make me drool. :)

Along the same lines, make it easy for Squeak to rule
the cloud.

Ah, *that* one is more like it. Not sure HOW, but i do agree that the Cloud (in whichever shape or form) is coming.

One thing I have noted as a consultant is that almost EVERY customer now runs virtual hardware. In Sweden almost always VMWare. And this actually benefits us - the customer just wants an "appliance". They often don't care what it is written in.

If Squeak could offer something unique in this arena... but I fail to see what that could be :)

Each of these has high potential impact, and it would be nice to have made some real progress in one or two areas before doing a major merge or rewrite. What if you decide to eliminate shared globals; wouldn't this be a great time to include that rewrite? What if shared variables turn out to be a great way to synchronize multiple threads in the VM; wouldn't this be a good time to fold that in? Etc.

So this may be the time to reorganize everything, but it also looks to me like there is nothing in the way of making some *bold* progress right now, and it's likely that the wider perspective achieved in the process might inform an even better next system.

That said, don't forget there are good and committed people on both sides of this discussion, and your first priority should be how to maximize the community. FWIW I recommend face-to-face discussion. And beer.

Beer is good. Too bad we are so darn spread out.

- Dan

regards, Göran

Sorry that I am late to this discussion - I was away for a week showing off Squeak at an international free software conference [1]. Even exchanged some ideas with Richard Stallman about the Squeak licensing issues (he would be happier if we used GPL, of course).

My first comment is that there are two sources for all the energy that we can now see in Pharo. One is improved processes, which is certainly something we should have in Squeak (and is *the* goal for 3.11) and the other is the "start up" glee that new projects tend to have. The latter will eventually wear off, but I am sure that the former is strong enough for it to keep going for a very long time.

I watched people and energy move from Self to Squeak, from Squeak to Slate, from Squeak to IDST and many other similar cases. It is a great thing that Pharo exists and anyone who really would like to have Squeak be an Open Source Smalltalk-80 with a professional look now has that option available. The question that was asked was if this should be the only option?

My understanding of the Etoys situation leads me to think that it can't survive as a fork. Who will continue to work on it now that ViewPoints has transferred responsibility to the new Squeakland Foundation? I would like Bert and Yoshiki to comment on this if possible. In the past we have had forks between squeakland and squeak which were later merged back and I want to see that happen again. I feel a moral responsibility for all the students and teachers that have been convinced to adopt Etoys (and I talked to quite a few this week). If Alan's suggestion of a Python version of Etoys had been followed and that was what the children were using then I wouldn't mind a "Squeak become: Pharo" situation, but it didn't happen.

So my priorities are: 1) keep Etoys going and improving 2) Croquet 3) Seaside and Aida 4) Pharo

About what Dan wrote, I agree 100%. It might seem like a contradiction, that I want as little change as possible. But that is not true at all - I accepted that relicensing was the number one priority for the community (I have always been happy with the SqueakL myself) and that doing this right would mean 6 months to a year of additional time with no progress. I actually proposed a technical solution that would both allow us to have more backwards compatibility and radical progress at the same time [2] but since nobody was convinced I am willing to push forward with more conventional development.

On the last slide of my talk last week, I mentioned "Squeak and Cloud Computing" and gave some details about a project for next year with 16 thousand Squeak processors on a 6 inch wafer. Though nothing is being done in secret, I don't think most on this list are aware of just how much work is being done on Squeak right now and how many are considering joining over the next few months.

-- Jecel [1] http://fisl.softwarelivre.org/10/www/en [2] http://wiki.squeak.org/squeak/584

Hi Bryce!

Bryce Kampjes wrote:

On Tue, 2009-06-30 at 00:59 +0200, Göran Krampe wrote:

...

...

Press at least one good JIT design through to completion
document it, and keep it alive on every platform.

I presume Cog is our hope? The latest "news" in this area is that Eliot mentioned he is looking closer at the JIT in Factor (factorcode.org) and even considers porting it! And lots of JIT libs around these days, Nanojit in Tracemonkey, libJIT etc etc.

But one thing is true - performance *kicks ass*. We may go on and on about how "unimportant" performance is but darnit, it really is a killer feature if we had a REAL fast VM whupping the Pyhon/Rubys. ;)

Exupery development is still continuing though the rest of this year is likely to be slow but speeding up as the months go by. The current task is dynamically inlining methods.

I deliberately didn't mention your work because I didn't want to put pressure and since Cog was slated for this summer (I think) I guess Cog may deliver before Exupery starts to deliver in earnest.

But inlining of methods sounds like it could be a booster, right?

regards, Göran

Dan Ingalls wrote:

That said, don't forget there are good and committed people on both sides of this discussion, and your first priority should be how to maximize the community. FWIW I recommend face-to-face discussion. And beer.

Great idea! We can have lots of face time (and beer) at Squeakfest in L.A. (August 10-12). There will be a technical track (Eliot is giving a talk) and you're all invited to come by :)

Rita

- Dan

Douglas Brebner wrote:

I feel the Pharo people deserve a beer for lighting a fire under the Squeak community and getting people motivated :)

The Squeak community was motivated before Pharo, and lots of work has been done in the past couple of years outside of Pharo to improve squeak for use in a commercial environment. My own contribution to this includes:

Installer - DSL for building images SUnit-improved SSpec TestReporter - Text based SUnit runner MC1.5 - merge of all forks of MC MC1.5 Orphanage - out of order loading MC1.5 - extensions and overrides actually work. MC1.6 - initial coding for Atomic Loading Sake - aka. make/rake for squeak Sake/Packages - replace universes Bob1 (in ruby) Sake/Bob - automatic build/test server Logging LevelPlayingField

If that lot don't constitute motivation, I don't know what does.

What pharo managed to do was demotivate several people who had contributed, and their contributions were summarily ignored.

For example, I regard the fact that Pharo started with 3.9 when there was no reason why they could not have started with 3.10, as a significant insult to Edgar and the rest of us that put lots of effort into 3.10.

As a second example I consider the fact that Pharo refuses to adopt or contribute to MC1.5 with a view to adoption. MC1.5 included a merge of several MC forks, and common tools are essential for cross fertilisation within the community. I take their actions as a demonstration that they are not interested in being community players or working with any broader community vision that I we or anyone might propose.

We had a golden opportunity for the community to work together on the important tools, and the Pharo guys will not play ball, they will not join with any vision other than their own. This has the effect of DEMOTIVATING folks like myself who would like to see all of the community work together, and have been working towards that end for over 3 years.

They will not contribute to any of the above projects that are maintained in public repositories as a community resource. Instead they retain their own forks of SUnit and MC, etc.

This has driven me to the point of not being motivated to continue to contribute to MC, because the Pharo team are effectively vetoing the adoption of any future enhancements. I cannot take pharo seriously as a commercial development tool, when it uses MC1 which doesn't cope with method extensions or overrides. (fine if you are in you ivory tower and writing your own code from scratch, but a nightmare if you try to patch up and maintain code that is not your own)

In summary, I have regrettably discovered and continue to maintain that the attitude of the Pharo team is very rude indeed. I have pondered whether this is a cultural thing (i.e. traditionally the French and English don't get along). I have discussed it with my non coding friends and others and I have not managed to come to any other constructive conclusion.

So in conclusion, I personally regard pharo as a small academic research project being carried out on behalf of the smalltalk community. It's only valuable output will be the MIT licenced code that they produce. The lack of social skills in the pharo team is only surpassed by my own. As such this renders the pharo vision useless to any bigger concept of shared objective or values, and that's what I think squeak is really all about.

Keith