Inline...
On May 19, 2013, at 4:52 PM, Casimiro de Almeida Barreto <
[hidden email]> wrote:
> On 19-05-2013 17:36, Jecel Assumpcao Jr. wrote:
>> Frank,
>>
>>> Well, OK. It depends on what exactly you mean by "Smalltalk". If you
>>> mean Smalltalk-80, then definitely not. If you mean ANSI Smalltalk,
>>> then probably not. I don't see much value in sticking to "standards"
>>> 15 years and older.
>> While to many people "Smalltalk" is the same as "Smalltalk-80", I prefer
>> a definition what includes Smalltalk-72 as a Smalltalk. Any such
>> definition would most certainly include Self and Slate as Smalltalks
>> too.
>>
>> Sort of like the confusion about "Free Software", I got tired of
>> explaining my viewpoint regarding my Self/R design and simply renamed it
>> to Neo Smalltalk instead.
>>
>> I do note that none of the various SqueakFests were about Squeak but
>> rather about Etoys. So I agree that "Squeak Smalltalk" (which happens to
>> be the term I use in all my papers) makes exactly what we are talking
>> about very clear without restricting any future options.
>>
>> There was a time when the term "Smalltalk" caused very negative
>> reactions and several projects tried to distance themselves from it. But
>> that was when Java was new and needed agressive marketing. I feel that
>> the current situation is entirely different.
>>
>> -- Jecel
>>
>>
>>
> I tend to agree with Frank about adherence to old standards & with all
> arguments presented by Jecel.
Someone should support the broad majority of Smalltalk code. Between Squeak and Pharo, we have this, but agreeing on a set of "core" tests would help a lot IMHO.
> One fact about smalltalk is that it was plagued by fragmentation.
This is true, but so is the converse. It's a platform that makes it easy to venture into new territory. There's a point of view where this looks like the system's finest feature.
> The lack of a mainstream favored the appearance of several "smalltalk
> idioms" that quite don't talk among themselves.
Truth.
> That reduced applicability and made disrupting advancements hard to achieve. So, currently we have some commercial idioms that are simply too proprietary & expensive for general use and some free software implementations that
> are becoming too widely fragmented to allow coherent evolution.
I'm not sure I agree with this argument. I think coherent evolution is easier to do with small, tightly knit groups than with huge armies of commiters. The more cooks you have in the kitchen (and this is just my experience) the less coherent things get.
OTOH, having rigorous scrutiny from a large community is *always* good. Maybe we're weaker than some communities in this regard.
> Squeak is a really great platform. But currently is supported by a small
> community and important issues just cannot be covered.
This is also true, but a blanket statement. We should talk about the specifics. Drill down. Fill the gaps.
> After the schism,
> at least two other versions of "baby squeaks" appeared. One is dealt by
> a single developer. I hope him the best luck in the world.
Cuis is supported by a very small community of deeply passionate people, not a single developer. Saying that is like saying that Squeak was dealt exclusively by Andreas Raab when he had the most commits.
In other words: what am I, chopped liver? :)
> The other is
> supported by some academic researchers that decided to reinvent the
> wheel while designing the next thing in OOL and the result is something
> that is just not stable and consistent in one hand and don't touch
> important things already achieved by other OOLs in the other hand.
Stef and company deserve some credit for the things they have done well. The Pharo community has my complete support. It took me awhile to come to this point of view, but I'm there now.
That said, Pharo has a totally different set of goals from mine about half of the time. I like to use it for Seaside and the (lovely) PetitParser, but that's about it. Most of the fun oogly-eye morphs only load in Squeak! And I want more fun in general ASAP.
If Edgar is listening: when's the next Fun Squeak?
> So,
> IMHO, current state of affairs is bleak at best.
Book recommendation: The Soul of a New Machine (Tracy Kidder.) Adversity can in some cases bring out the absolute best in people. Yes, bleakness is scary and sucks. Being wrapped up in that is demoralizing, though, so I say: look at the adversity as a challenge. As a blessing.
> Just to be synced with current hardware and OS technologies, one
> important thing would be having squeak working fully 64bits and
> multithreaded.
Sure, but I'd rather be able to JIT on the cheaper ARM SoCs. Then I could conceivably build a decent interrim Dyna-Book/Phone. Slap a Pixel Qi display behind a capacitive screen on a battery-backed Pi-B with a wifi module slotted in one of the USB ports and call that the new baseline for a usable programming environment. Touch UI pending:)
> It happens that cog is not 64 bits and it seems it cannot
> be easily made so.
It's just work that needs doing. If we really needed it, I mean asteroid-plummeting-to-earth needed it *right now* I'm pretty sure that this group of people might be able to raise the funds to pay one of these people I know on the Internet who know how to handle this kind of thing and get it done *right.*
*cough* Eliot *cough*
We just need to get organized and raise the cash.
> The standard VM can be compiled 64 bits (64bit VM)
> but image is still 32bit.
This part is a bit confusing, admittedly.
> Worse than that, multithreading is hard to
> achieve. And simply there are not enough people to take care of these
> issues. Supposing multithreading could be achieved, then distributed
> objects (objects running in loosely coupled computer architectures)
> would become important. But IMHO it is just centuries ahead of what can
> be done today.
CogMT is heading down this way. RoarVM explored the many core approach, and (I) learned some stuff from that experiment. I'm excited to see what might be done with Jecel's Silicon Squeak project.
> Best regards,
>
> CdAB
Overall, I feel your fears. But I think we'll do better if we keep our spirits high and sing while we make the objections go away!
Cheers,
Casey
Locked
signature.asc (271 bytes)