Few thoughts about Google Summer of Code
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/
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
Geert Claes wrote:
...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.
Paolo Bonzini 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" :)
Paolo Bonzini wrote:
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
View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p3018858.html
Sent from the ESUG mailing list archive at Nabble.com.
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
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
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
James Robertson
http://www.jarober.com
jarober@gmail.com
On Fri, Oct 29, 2010 at 6:22 PM, James Robertson jarober@gmail.com 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/
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 jarober@gmail.com 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
jarober@gmail.com
No, we would need to find a way to add curly braces ...
Davorin Rusevljan
http://www.cloud208.com
On Oct 29, 2010 1:27 PM, "Serge Stinckwich" serge.stinckwich@gmail.com
wrote:
On Fri, Oct 29, 2010 at 6:22 PM, James Robertson jarober@gmail.com wrote:
I think Paolo is right...
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
h...
Esug-list mailing list
Esug-list@lists.esug.org
http...
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
Paolo Bonzini-2 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?
--
View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p3018984.html
Sent from the ESUG mailing list archive at Nabble.com.