Few thoughts about Google Summer of Code
Locked
12345
12345
 
|
Well I guess we can quite quickly create huge list of things that need
to be done. But since we are a very small community there is no chance we could attack all of them, we need to concentrate on few ones that provide most bang for the buck so to say. I think that we need to thank web tools (Seaside, Aida ..) for the small renaissance we are having, and my 2c is that we need to focus on that. It is growth area where inovation counts, and where we stand some chance. So we need more ready to be made components, tutorials, examples, get more integration with various web development services, perfect integration with javascript and css libraries and gadgets, NoSQL databases, message queues, HTML 5 and such. If we make reasonable progress there, some fresh developers might get attracted and other things could be addressed. Another growth area is mobile, but I think we still do not have perspective entry there like in web domain. Davorin Rusevljan http://www.cloud208.com/ _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Geert Claes
On 10/29/2010 12:29 PM, Geert Claes wrote:
>> ... 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 > > What is the developer's favorite editor/IDE and why? As mentioned before, > this is all about the User eXperience. The developer probably doesn't care > what source code control system is being used, as long as it does the job > and is easy to use. It sure cares! If the VCS doesn't allow easy integration of code with other kinds of assets (pictures, CSS, schemas expressed as DDL, etc.) and with other people on the team who work on those assets, developers _are_ going to complain. Regarding editors, it takes me a while to rewire my muscle memory from vi to mouse-based action in a Smalltalk browser; I do it only because of the inspectors and debugger etc. For a newbie, however you can reasonably expect resistence, especially if the UI shows rough edges (completion in Pharo never seems to use the keyboard shortcuts I'd use, for example). Paolo _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
Administrator
|
That's why I said, "as long as it does the job" :) The biggest target audience are probably those who expect mouse-based (or touch gesture) interaction though |
Re: Few thoughts about Google Summer of Code
|
|
On 10/29/2010 12:48 PM, Geert Claes wrote:
>> It sure cares! If the VCS doesn't allow easy integration of code with >> other kinds of assets (pictures, CSS, schemas expressed as DDL, etc.) and >> with other people on the team who work on those assets, developers >> _are_ going to complain. > > That's why I said, "as long as it does the job" :) Heh, so I was implying incorrectly that, as far as you were concerned, VCS that cared only about Smalltalk source did the job. :) >> Regarding editors, it takes me a while to rewire my muscle memory from vi >> to mouse-based action in a Smalltalk browser ... > > The biggest target audience are probably those who expect mouse-based (or > touch gesture) interaction though Not sure here... sure there's a lot of people using TextMate, but there's a lot of people using vi too. Anybody who had a past career as a sysadmin is likely to have picked it up---and likely stayed with it for Ruby/Python jobs too. Paolo _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
|
|
I think Paolo is right here. I presented Smalltalk to a bunch of Ruby user groups in 2009, and the reactions were pretty similar:
"That's way cool (especially the debugger), but why can't I use (insert text editor or VCS here)" I'm not suggesting that we ditch the image; just that we recognize the hurdle there On Oct 29, 2010, at 7:14 AM, Paolo Bonzini wrote: > On 10/29/2010 12:48 PM, Geert Claes wrote: >>> It sure cares! If the VCS doesn't allow easy integration of code with >>> other kinds of assets (pictures, CSS, schemas expressed as DDL, etc.) and >>> with other people on the team who work on those assets, developers >>> _are_ going to complain. >> >> That's why I said, "as long as it does the job" :) > > Heh, so I was implying incorrectly that, as far as you were concerned, VCS that cared only about Smalltalk source did the job. :) > >>> Regarding editors, it takes me a while to rewire my muscle memory from vi >>> to mouse-based action in a Smalltalk browser ... >> >> The biggest target audience are probably those who expect mouse-based (or >> touch gesture) interaction though > > Not sure here... sure there's a lot of people using TextMate, but there's a lot of people using vi too. Anybody who had a past career as a sysadmin is likely to have picked it up---and likely stayed with it for Ruby/Python jobs too. > > Paolo > > _______________________________________________ > Esug-list mailing list > [hidden email] > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org James Robertson http://www.jarober.com [hidden email] _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
On Fri, Oct 29, 2010 at 6:22 PM, James Robertson <[hidden email]> wrote:
> I think Paolo is right here. I presented Smalltalk to a bunch of Ruby user groups in 2009, and the reactions were pretty similar: > > "That's way cool (especially the debugger), but why can't I use (insert text editor or VCS here)" > > I'm not suggesting that we ditch the image; just that we recognize the hurdle there So if we have a Smalltalk text pane with a VI or emacs bindings, they will be happy ? ;-) -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
|
|
Not so much :)
Editor preference seems to be somewhat religious in nature :) On Oct 29, 2010, at 7:26 AM, Serge Stinckwich wrote: > On Fri, Oct 29, 2010 at 6:22 PM, James Robertson <[hidden email]> wrote: >> I think Paolo is right here. I presented Smalltalk to a bunch of Ruby user groups in 2009, and the reactions were pretty similar: >> >> "That's way cool (especially the debugger), but why can't I use (insert text editor or VCS here)" >> >> I'm not suggesting that we ditch the image; just that we recognize the hurdle there > > So if we have a Smalltalk text pane with a VI or emacs bindings, they > will be happy ? ;-) > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ James Robertson http://www.jarober.com [hidden email] _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
|
|
In reply to this post by SergeStinckwich
No, we would need to find a way to add curly braces ... Davorin Rusevljan On Oct 29, 2010 1:27 PM, "Serge Stinckwich" <[hidden email]> wrote: _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Dennis Schetinin
> On 10/29/2010 12:48 PM, Geert Claes wrote:
> >> It sure cares! If the VCS doesn't allow easy integration of code > >> with other kinds of assets (pictures, CSS, schemas expressed as > >> DDL, etc.) and with other people on the team who work on those > >> assets, developers _are_ going to complain. VCS and source code organization is something that has now become standard across all mainstream languages (i.e. Java and C# :->). Your source code should be saved in class files, in a directory structure that mirrors the package/namespace structure. Other assets are stored and versioned in a similar way. You can use any VCSs with any programming language; indeed, you may be more attached to a VCS than a language. You will use one VCS for a project, but you may use multiple languages. Similar things can be said for IDEs and VMs: you probably pick one and stick to it, although you use multiple languages. People choose a programming environment based on (most important first): 1) what everybody else is using 2) what seems familiar to them 3) what is cool 4) what is good Based on that, it's obvious Smalltalk is not going to succeed in a big way in the foreseeable future. What we need to look at are what areas we lose out on in 2), and could be changed to fit what everybody else is doing, without losing much in 4). To my mind, source code in class files and normal VCS would be doable in Smalltalk, without losing anything major. In contrast, image-based development is a major factor in our competitive advantage, allowing debugging, experimentation etc. It's hard to imagine image-based development with Eclipse or VisualStudio, and implementing Smalltalk on another existing VM is currently too hard, so I'll skip those and focus on the low-hanging fruit. Which Smalltalks (+/- add-on projects) have code in class files, interface with standard VCS, and yet still have an image-based, GUI IDE? And for those that don't, how hard would it be to get there? Steve _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by SergeStinckwich
On 10/29/2010 01:26 PM, Serge Stinckwich wrote:
>> I think Paolo is right here. I presented Smalltalk to a bunch of >> Ruby user groups in 2009, and the reactions were pretty similar: >> >> "That's way cool (especially the debugger), but why can't I use >> (insert text editor or VCS here)" >> >> I'm not suggesting that we ditch the image; just that we recognize >> the hurdle there > > So if we have a Smalltalk text pane with a VI or emacs bindings, they > will be happy ?;-) For the editor there's basically no satisfying solution. With good completion and good tools, it's possible that people will just accept losing their beloved key bindings. (Note that IMHO there's in general a UI problem especially in Squeak/Pharo, it's not just about the bindings, but I don't want to digress). For the VCS, I've always been surprised there's no git or svn backend for Monticello. It wouldn't seem _too_ hard to have a directory per package and replace each .mcz file with a commit in that directory. Alternatively, there's actually very little GST-specific code in http://github.com/timfel/gitocello (a Squeak+Monticello <-> GST+git bridge), so if someone wants to play with it... Paolo _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Dennis Schetinin
James Robertson wrote:
> -- 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 these are the major issues these days. VW's widgets are close to standard widgets these days, and most other apps' widgets diverge from the standards anyway. Squeak will suffer far more, as its look is further from the standard (last time I looked). Most IDEs are very much "all in one window", so I think VW suffers more there. The single window of Pharo and Squeak feels odd to a VW user, not to a normal person :-). Of course Pharo and Squeak could do more to have a single big IDE window with fixed panes, rather than the multiple floating windows-within-a-window that they had last time I looked. Then again, the CodeBubbles demo has got people excited, and that's pretty close to a Smalltalk "multiple browser windows" model. http://www.cs.brown.edu/people/acb/codebubbles_site.htm Steve _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Steven Kelly
On 10/29/2010 01:36 PM, Steven Kelly wrote:
> To my mind, source code in class files and normal VCS would be doable in > Smalltalk, without losing anything major. In contrast, image-based > development is a major factor in our competitive advantage, allowing > debugging, experimentation etc. It's hard to imagine image-based > development with Eclipse or VisualStudio, and implementing Smalltalk on > another existing VM is currently too hard, so I'll skip those and focus > on the low-hanging fruit. > > Which Smalltalks (+/- add-on projects) have code in class files, > interface with standard VCS GNU Smalltalk has code in class files, but this ability is (for now) hampered when you launch the IDE. However, we do have easy to implement ideas on how to allow filing out packages from the IDE (basically borrowing the "package is category" ideas of Monticello). Adding VCS hooks should not be hard. Smalltalk/X had CVS integration too, no idea if it has been updated to something more modern. > and yet still have an image-based, GUI IDE? > And for those that don't, how hard would it be to get there? GNU Smalltalk's GUI is not yet 100% usable, though it's getting there. It has inspectors, debuggers, browsers, SUnit. It needs a bit of polishing. Paolo _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
|
|
On Fri, 2010-10-29 at 13:48 +0200, Paolo Bonzini wrote:
> On 10/29/2010 01:36 PM, Steven Kelly wrote: > > To my mind, source code in class files and normal VCS would be doable in > > Smalltalk, without losing anything major. In contrast, image-based > > development is a major factor in our competitive advantage, allowing > > debugging, experimentation etc. It's hard to imagine image-based > > development with Eclipse or VisualStudio, and implementing Smalltalk on > > another existing VM is currently too hard, so I'll skip those and focus > > on the low-hanging fruit. > > > > Which Smalltalks (+/- add-on projects) have code in class files, > > interface with standard VCS > > GNU Smalltalk has code in class files, but this ability is (for now) > hampered when you launch the IDE. However, we do have easy to implement > ideas on how to allow filing out packages from the IDE (basically > borrowing the "package is category" ideas of Monticello). Adding VCS > hooks should not be hard. > > Smalltalk/X had CVS integration too, no idea if it has been updated to > something more modern. > Smalltalk/X supports CVS and SubVersion. > > and yet still have an image-based, GUI IDE? Smalltalk/X for instance :-) Jan > > And for those that don't, how hard would it be to get there? > > GNU Smalltalk's GUI is not yet 100% usable, though it's getting there. > It has inspectors, debuggers, browsers, SUnit. It needs a bit of polishing. > > Paolo > > _______________________________________________ > 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 |
Re: Few thoughts about Google Summer of Code
|
Administrator
|
In reply to this post by Paolo Bonzini-2
Sounds very interesting, what would the main advantages be of using a GIT backend? |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Dennis Schetinin
Jan Vrany wrote:
> > On 10/29/2010 01:36 PM, Steven Kelly wrote: > > > Which Smalltalks (+/- add-on projects) have code in class files, > > > interface with standard VCS > > Smalltalk/X supports CVS and SubVersion. > > > > and yet still have an image-based, GUI IDE? > > Smalltalk/X for instance :-) Thanks! But to return to my criteria: 1) what everybody else is using 2) what seems familiar to them 3) what is cool 4) what is good Even in the Smalltalk community, Smalltalk/X isn't 1). And looking at the web pages, with not even a single picture of the IDE or Smalltalk/X applications on the Products > Smalltalk/X pages, it may find itself in pretty big trouble on 3). That's a real shame, in an era when even one-person companies and research projects have smart videos showing off their products. Particularly since from what I hear, Smalltalk/X does pretty well on 4). Sorry if that sounds harsh - I do understand the other side of the coin, i.e. that there's hardly any money to be made by selling software development environments these days. Good luck to eXept with expecco, which I guess is what they focus on now. Steve _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Dennis Schetinin
>Squeak uses ToolBuilder to describe UI elements - lists, buttons, code
>panes, menus, and the like. Has anyone considered writing a >SeasideToolBuilder to generate HTML/CSS? > >frank Hi Frank seaBreeze is such a tool for seaside. If someone is interested, have a look at: http://seabreeze.heeg.de/ Markus ________________________________ Markus Rips * Senior Consultant / certified Scrum Master * [hidden email] phone: +49 231 9 75 99 24 * fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Geert Claes
On 10/29/2010 02:12 PM, Geert Claes wrote:
>> ... For the VCS, I've always been surprised there's no git or svn backend >> for Monticello. It wouldn't seem _too_ hard to have a directory per >> package and replace each .mcz file with a commit in that directory. >> >> Alternatively, there's actually very little GST-specific code in >> http://github.com/timfel/gitocello (a Squeak+Monticello<-> GST+git >> bridge), so if someone wants to play with it... > > 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. Paolo _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
|
|
In reply to this post by Steven Kelly
On Fri, Oct 29, 2010 at 1:36 PM, Steven Kelly <[hidden email]> wrote:
> People choose a programming environment based on (most important first): > > 1) what everybody else is using > 2) what seems familiar to them > 3) what is cool > 4) what is good IMHO there is one criteria that comes in front of those. First environment needs to be able to produce cool results. If environment can do some others can not, people will be using it even if it requires use of line editor. So being able to produce cool aps is our priority zero. Davorin Rusevljan http://www.cloud208.com/ _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
|
|
In reply to this post by Paolo Bonzini-2
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. Davorin Rusevljan http://www.cloud208.com/ _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
Re: Few thoughts about Google Summer of Code
|
|
In reply to this post by Dennis Schetinin
Davorin Rusevljan wrote:
> Steven Kelly <[hidden email]> wrote: > > People choose a programming environment based on (most important > > first): > > > > 1) what everybody else is using > > 2) what seems familiar to them > > 3) what is cool > > 4) what is good > > IMHO there is one criteria that comes in front of those. First > environment needs to be able to produce cool results. If environment > can do some others can not, people will be using it even if it > requires use of line editor. So being able to produce cool aps is our > priority zero. To some extent that intersects with 3), and I'd include it in 4) too: what you can produce, and how productive you are in doing it. I stand by my claim that 1) and 2) are more important in achieving mass success. 4) just helps guarantee a long life. Mind you, 1) should be rephrased to "what everybody else seems to be using", and a big score on 3) can outweigh a smaller difference on 1) and 2) over time: your message will get media coverage and some evaluators, helping to address 2) and 1) bit by bit. Steve _______________________________________________ Esug-list mailing list [hidden email] http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org |
«
Return to ESUG
|
1 view|%1 views
| Free forum by Nabble | Edit this page |