On 17/10/2008, at 6:08 PM, Marcus Denker wrote:
Of course, the question always is what means "interested in this",
in the light of no funding and limited spare time?
I'm not au fait with the detailed history of Squeak, but I know that
you've been at the pointy end of the thankless and shitty task of
harvesting for release, so I mean no disrespect, and acknowledge that
it is a problem. However ...
I had no external funding and limited time and yet I managed to make
LLVM/Clang work in VW, as well as many other things. I've found that
ST can be phenomenally productive for these kind of things, especially
when you a) you don't try to solve every problem, esp. in every
'market' that uses Squeak; and b) you leverage existing codebases such
as LLVM/Clang/WebKit/GIT etc.
<rant>
IMO Smalltalk's fatal flaw is it's lack of modularity and good system
construction. Pharo is one kind of process, but IMO a more fundamental
rethink of system construction mechanisms is required, at all
granularities. IMO the #1 priority should be dealing with this problem
which has burdened Smalltalk since it's inception. It's particularly
problematic in Squeak because it tries to address so many uses,
there's so much stuff added to Squeak, and often then abandoned, and
no one seems to do any serious documentation of any architecture or
implementation, apart from a few Traits papers and one OB paper.
</rant>
I've found it more productive to completely replace components rather
than attempt to untangle the mess that it is e.g. a typical GUI
component. I've developed a very productive way of doing that
involving class cloning, hierarchy collapsing and brutal
simplification. I think 90% of the entanglement problem is in Morphic,
so being brutal there, which can be accomplished by focussing on
keeping OB working and letting just about every other GUI tool rot, is
a productive strategy. I'm greatly enhancing OB, and by relying on
it's abstraction from the GUI (and using OB-Tools) Squeak can be kept
usable whilst pruning with a chainsaw.
I can do this because I'm not trying to produce a system that is
backwards compatible in any sense, primarily because I've implemented
a solution to the system construction/modularity problem, so I'm
trying to reboot to a from-source modular bootstrap. Thus, my mileage
will vary compared to people with other constraints.
So I suppose by 'interested' I mean 'interested in LLVM/Clang in the
context of a far more brutal reboot than Pharo'. I guess skepticism is
warranted, and I failed to garner interest in the VW community in
spite of providing proof-of-concept demonstrations for my proposals,
so I admit I'm fishing (although not, I hope, trolling) :)
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
He who would make his own liberty secure, must guard even his enemy
from repression.
-- Thomas Paine
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
