Few thoughts about Google Summer of Code

> On Fri, Oct 29, 2010 at 2:23 PM, Paolo Bonzini <[hidden email]> wrote:
>> On 10/29/2010 02:12 PM, Geert Claes wrote:
>>> Sounds very interesting, what would the main advantages be of using a GIT
>>> backend?
>>
>> It is what you use for other assets.  So the Monticello git-backed repo
>> could be simply a subtree of the project-wide repo.
>
> There would be also one trivial, but possibly important social aspect.
> Some Smalltalk projects might be hosted on GitHub, and become visible
> to larger audience.

> Hi Dennis,  Geert, Adres, Serge and other commenters..
>
> Doing good UI's is still quite hard and labour intensive - Seaside
> provides a great framework, but we are still working pretty much at
> the level of HTML / CSS concepts. I would like to see a layer
> describing logical data structures e.g. List, Tree, Matrix, Document
> (sequenced set of objects), Model (spatially arranged and possibly
> connected objects)  and a visual editor (or very high level DSL) that
> allows composition of these into user interfaces with a publish /
> subscribe event model and choice of suitable controls and widgets
> based upon the logical data type. (this one is probably a bit too big
> for a GSOC but may be tackled in pieces. )

> Hope some of this makes sense.
> Welcome feedback and comments.
> Best regards,
>
> Graham
>
> Dennis Schetinin wrote:
>
> … and observations …and questions … mostly inspired by GSoC Mentor
> Summit
>
> Mentor Summit was a great event! I didn't expect it to be THIS :) Very
> pleasant …and very hard for me: so many people, language and culture
> shock
> :) Great experience for me personally. Thank ESUG for choosing and
> sending me there.
> Bad news: Smalltalk is not popular. Well, it's not that new actually,
> we know it. But I didn't manage to fix it :) Seriously: actually, it
> looks like everybody knows Smalltalk (they know it existed I mean; few
> knows it still exists), but it is treated like a black and white movie.

> And I've heard many interesting ideas… apparently, organizational
> ideas mostly. I need some time to process them. So, for now I'll just
> outline some directions… Did we summarize our GSoC results? I thought
> I've missed them, but apparently we didn't do it. At least I found
> only this page
> http://code.google.com/p/google-summer-of-code-2010-esug/downloads/lis
> t. I didn't care much before, but now I think it is very important to
> look closer at the projects we did within GSoC, understand where we
> succeeded; where we failed; did we benefit and could we get more; make
> some plans for the future... etc.
> I think we should pay more attention to GSoC. It is very important for
> our small society. Of course, we can't be sure smalltalkers will be
> invited again next year. (One of the things I tried to understand at
> summit but still I don't: how does Google select mentor
> organizations?) But this work will be very helpful, useful, advantageous…

> We should be more serious about monitoring and controlling our projects.
> Since money are involved here, we have a right to. That's money from
> Google, but still. I think it should be a bit different from the way
> free projects are evolved within Smalltalk society. Since we have such
> opportunity we have to benefit as much as we can.
> Smalltalk gives me competitive advantages. For that matter I don't
> want to
> :)  but now I understand even better: we have to promote Smalltalk. I
> know everybody knows that, but I still want to state it once again.
> And promoting is not only about advertising and praising. We should be
> more open. We should find a way to start some cooperative projects
> with other societies/languages. I don't know how to do it. And it's
> extremely hard for me as I believe in Smalltalk superiority :) But
> still we have if we don't want Smalltalk to die. In general, it looks
> like making Smalltalk more open should be our priority, and this is
> one of the few ways to enhance prestige of Smalltalk among developers.
>
> --
> Dennis Schetinin
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>
>

> On 10/29/2010 04:15 PM, [hidden email] wrote:
> > Another significant hurdle was that each dialect has it's own fileout
> > format. CVST allowed using SIF as well for that reason, but that's
> > foreign to every dialect. Would you be happy to commit your sources
> > to git in SIF?
>
> I don't think inter-dialect communication is a problem.  Any dialect
> should be able to use whatever it prefers, like XML for VW or chunks for
> Squeak or its own syntax for GST.  Did CVST actually rely on SIF or did
> it just "allow" using it?

> On 29.10.2010, at 16:40, [hidden email] wrote:
>
>> Otherwise people will see right away that we're just faking the
>> integration. So in VW I wouldn't try to swap git in as a just a
>> different "database back end" behind Store. I think it needs to be
>> full on file based VC integration (ala CVST or whatever) that can
>> run side by side with Store if you wanted.
>
> Indeed. It might even be necessary to support out-of-the-image
> development.

> I'm not sure that's the case.  I used that line a lot when I was the Smalltalk Evangelist at Cincom, and it's true - up to a point.  However, the prospective developer who looks at the tools from a personal use standpoint cares.  So
>
> -- the not quite "standard" widgets in VisualWorks make him think
> -- the "all in one windows" thing in Pharo and Squeak make him think
>
> I don't think those are complete showstoppers, but they are hurdles - and they are additional hurdles the Smalltalk community doesn't need.  Consider that we already present two big hurdles that we require people to get past:
>
> -- The prospective user can't use his favorite editor
> -- The prospective user can't use his favorite source code control tools
>
> the UI hurdle is something that could be dealt with (and yes, I recognize the difficulties).  The last two are just there.  Given that, the additional UI level one should be considered more seriously
>

> James is quite right here ... but there are many more hurdles and all
> these new potential users must be persuaded to come over these hurdles
> and be happy with it.
>
> * e.g. even in Eclipse you're sticked to the editor - nobody complains
> about it (one may write an additional plug-in) so this hurdle can be
> accepted - if the editor is attractive and gives you real power. In the
> area of editors in all those Smalltalk systems I noticed an improvement
> in the look-and-feel area - BUT they still do not offer additional helps
> like showing all possible methods for an object. In all (Smalltalk-)
> systems is the way to navigate to another class very long, that drives
> me mad.
>
> * the source code management problem seem to be a big hurdle. systems
> like svn, git, cvs are seen as open systems and are well known here.
> Nearly all ST systems have their own system (which are often far
> superior than the other ones). Source code exchange between all
> Smalltalk systems is worse ! Java, C and all that stuff would not be so
> attractive if the users have so many problems to switch from one
> Java-IDE to another Javae-IDE, or one C-compiler to another.
>
> * the language itselfs is getting old. Missing standard namespaces,
> missing interface specifications (etc) seems to stand for old languages.
> The missing of interface specification is the worst one and I do not
> understand the community, that nobody insist on adding this to Smalltalk.
>
> * Smalltalk systems are not well suited for multiprocessor,
> multithreading area ...
>
> * delivering process is more difficult than with other languages ...
>
> * we have problems getting access to successes in other languages. Out
> of the box it is difficult to interact with Java or .NET world.
>
> * even with the often propagated better productivity we are forced (due
> to the point above) to reinvent the world instead of being able to use
> already available software components.
>
> Considering all these hurdles - and then ask newcomers why should they
> use Smalltalk IDE xyz instead of Eclipse or VisualStudio (and both are
> available for more or less free and not copyright dialog and no runtime
> license problems).
>
> Am 29.10.2010 12:14, schrieb James Robertson:
>> I'm not sure that's the case. I used that line a lot when I was the
>> Smalltalk Evangelist at Cincom, and it's true - up to a point.
>> However, the prospective developer who looks at the tools from a
>> personal use standpoint cares. So
>>
>> -- the not quite "standard" widgets in VisualWorks make him think
>> -- the "all in one windows" thing in Pharo and Squeak make him think
>>
>> I don't think those are complete showstoppers, but they are hurdles -
>> and they are additional hurdles the Smalltalk community doesn't need.
>> Consider that we already present two big hurdles that we require
>> people to get past:
>>
>> -- The prospective user can't use his favorite editor
>> -- The prospective user can't use his favorite source code control tools
>>
>> the UI hurdle is something that could be dealt with (and yes, I
>> recognize the difficulties). The last two are just there. Given that,
>> the additional UI level one should be considered more seriously
>>
>
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>

>
> On 10/30/2010 12:29 AM, Marten Feldtmann wrote:
>> James is quite right here ... but there are many more hurdles and all
>> these new potential users must be persuaded to come over these hurdles
>> and be happy with it.
>>
>> * e.g. even in Eclipse you're sticked to the editor - nobody complains
>> about it (one may write an additional plug-in) so this hurdle can be
>> accepted - if the editor is attractive and gives you real power. In the
>> area of editors in all those Smalltalk systems I noticed an improvement
>> in the look-and-feel area - BUT they still do not offer additional helps
>> like showing all possible methods for an object. In all (Smalltalk-)
>> systems is the way to navigate to another class very long, that drives
>> me mad.
>>
>> * the source code management problem seem to be a big hurdle. systems
>> like svn, git, cvs are seen as open systems and are well known here.
>> Nearly all ST systems have their own system (which are often far
>> superior than the other ones). Source code exchange between all
>> Smalltalk systems is worse ! Java, C and all that stuff would not be so
>> attractive if the users have so many problems to switch from one
>> Java-IDE to another Javae-IDE, or one C-compiler to another.
>>
>> * the language itselfs is getting old. Missing standard namespaces,
>> missing interface specifications (etc) seems to stand for old languages.
>> The missing of interface specification is the worst one and I do not
>> understand the community, that nobody insist on adding this to Smalltalk.
>>
>> * Smalltalk systems are not well suited for multiprocessor,
>> multithreading area ...
>>
>> * delivering process is more difficult than with other languages ...
>>
>> * we have problems getting access to successes in other languages. Out
>> of the box it is difficult to interact with Java or .NET world.
>>
>> * even with the often propagated better productivity we are forced (due
>> to the point above) to reinvent the world instead of being able to use
>> already available software components.
>>
>> Considering all these hurdles - and then ask newcomers why should they
>> use Smalltalk IDE xyz instead of Eclipse or VisualStudio (and both are
>> available for more or less free and not copyright dialog and no runtime
>> license problems).
>>
>> Am 29.10.2010 12:14, schrieb James Robertson:
>>> I'm not sure that's the case. I used that line a lot when I was the
>>> Smalltalk Evangelist at Cincom, and it's true - up to a point.
>>> However, the prospective developer who looks at the tools from a
>>> personal use standpoint cares. So
>>>
>>> -- the not quite "standard" widgets in VisualWorks make him think
>>> -- the "all in one windows" thing in Pharo and Squeak make him think
>>>
>>> I don't think those are complete showstoppers, but they are hurdles -
>>> and they are additional hurdles the Smalltalk community doesn't need.
>>> Consider that we already present two big hurdles that we require
>>> people to get past:
>>>
>>> -- The prospective user can't use his favorite editor
>>> -- The prospective user can't use his favorite source code control tools
>>>
>>> the UI hurdle is something that could be dealt with (and yes, I
>>> recognize the difficulties). The last two are just there. Given that,
>>> the additional UI level one should be considered more seriously
>>>
>>
>>
>> _______________________________________________
>> Esug-list mailing list
>> [hidden email]
>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>>
>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
>