Few thoughts about Google Summer of Code
… and observations …and questions … mostly inspired by GSoC Mentor Summit 1. 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. 2. 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. People say "wow! it's cool" and go to see Avatar. :( So developers don't take Smalltalk seriously. We (Smalltalkers) know it's a mistake. But we have to show that for others. And I found myself unable to do that there. I found language and, more likely, culture barrier is too big to overcome. I didn't manage to set up a two-way communication with others. So I listened mostly. 3. 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… 4. 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/list. 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. 5. 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… what ever. 6. 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. 7. 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
On Fri, Oct 29, 2010 at 10:41 AM, Dennis Schetinin <chaetal@gmail.com> 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. People say "wow! it's cool" and go to see Avatar. :( So developers don't take Smalltalk seriously. We (Smalltalkers) know it's a mistake. But we have to show that for others. And I found myself unable to do that there. I found language and, more likely, culture barrier is too big to overcome. I didn't manage to set up a two-way communication with others. So I listened mostly. 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…
Hi Dennis, thank you for you nice report ! You are totally right ... i have the same problem when i meet developers from other languages. It's very difficult to change the mind of people. I have no real answer except continue do some cool stuff and make more noise. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
You are totally right ... i have the same problem when i meet developers from other languages. It's very difficult to change the mind of people. I have no real answer except continue do some cool stuff and make more noise.
I betcha this is a two way street. What would we see in a Smalltalker from the point of view of, say, C? Would we think we can change the Smalltalker's mind? I remember Stephane and others commenting several times that appearance is an issue, and that we need a nicer looking UI. Is this really the main selling factor these days, or does that apply mostly to students (I phrase it this way because I remember Stef making the comment specifically with respect to students)? Andres.
Valloud, Andres wrote:
... I remember Stephane and others commenting several times that appearance is an issue, and that we need a nicer looking UI. Is this really the main selling factor these days, or does that apply mostly to students? ...
Its not just appearance Andres, it's the complete User eXperience: intuitiveness, ease of use, productivity, fun factor as well as the look and feel. A lot of progress has already been made in this area, but there is still a long way to go because most Smalltalk IDE's have not evolved that much since the 70's ... that's probably part of why Smalltalk is being treated like a black and white movie :) -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.com.
Its not just appearance Andres, it's the complete User eXperience: intuitiveness, ease of use, productivity, fun factor as well as the look and feel. A lot of progress has already been made in this area, but there is still a long way to go because most Smalltalk IDE's have not evolved that much since the 70's ... that's probably part of why Smalltalk is being treated like a black and white movie :)
But see, I'm already sold, so I just don't see the point :)... IMO, we will make the most progress in this area by concentrating our efforts on the difficult problems. It makes me happy to see people concerned with how to make an image from scratch, for example. Andres.
On Fri, Oct 29, 2010 at 8:47 AM, Andres Valloud <avalloud@cincom.com> wrote:
Its not just appearance Andres, it's the complete User eXperience: intuitiveness, ease of use, productivity, fun factor as well as the look and feel. A lot of progress has already been made in this area, but there is still a long way to go because most Smalltalk IDE's have not evolved that much since the 70's ... that's probably part of why Smalltalk is being treated like a black and white movie :)
But see, I'm already sold, so I just don't see the point :)... IMO, we will make the most progress in this area by concentrating our efforts on the difficult problems. It makes me happy to see people concerned with how to make an image from scratch, for example.
As someone who spends much of my time dealing with Smalltalk users, customers, and prospects, I can say that it *does* matter to most people. Solving difficult problems is a very valuable thing to do, but without doing it in an environment that is broadly appealing (visually, UX, etc. as Geert says) Smalltalk will never have any chance of being more than a tiny niche (think of WinAmp or VLC - neither would have been successful without attractive, intuitive user interfaces, even though the real reason I used/use them was for the really practical features). Julian
One such difficult problem would be to make a visually compelling UI framework, fully capable of supporting and deploying real production applications. On 10/29/2010 1:35 AM, Julian Fitzell wrote:
On Fri, Oct 29, 2010 at 8:47 AM, Andres Valloud<avalloud@cincom.com> wrote:
Its not just appearance Andres, it's the complete User eXperience: intuitiveness, ease of use, productivity, fun factor as well as the look and feel. A lot of progress has already been made in this area, but there is still a long way to go because most Smalltalk IDE's have not evolved that much since the 70's ... that's probably part of why Smalltalk is being treated like a black and white movie :)
But see, I'm already sold, so I just don't see the point :)... IMO, we will make the most progress in this area by concentrating our efforts on the difficult problems. It makes me happy to see people concerned with how to make an image from scratch, for example.
As someone who spends much of my time dealing with Smalltalk users, customers, and prospects, I can say that it *does* matter to most people. Solving difficult problems is a very valuable thing to do, but without doing it in an environment that is broadly appealing (visually, UX, etc. as Geert says) Smalltalk will never have any chance of being more than a tiny niche (think of WinAmp or VLC - neither would have been successful without attractive, intuitive user interfaces, even though the real reason I used/use them was for the really practical features).
Julian
Valloud, Andres wrote:
One such difficult problem would be to make a visually compelling UI framework, fully capable of supporting and deploying real production applications.
This becomes much less of an issue since most development - I know not all:) - is moving to the web. -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.com.
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 On Oct 29, 2010, at 5:05 AM, Geert Claes wrote:
Valloud, Andres wrote:
One such difficult problem would be to make a visually compelling UI framework, fully capable of supporting and deploying real production applications.
This becomes much less of an issue since most development - I know not all:) - is moving to the web.
-- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.com.
_______________________________________________ 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 5:14 PM, James Robertson <jarober@gmail.com> wrote:
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
But comparing to Ruby, there is no standard UI in Ruby and this not really annoying for the people, because they deploy their application on the web. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
The Ruby <developer> sees a text editor - the one he picked. The Smalltalk developer sees the Smalltalk browser (etc). My point is that the UI is the first thing the new Smalltalker sees, and it creates an impression. On Oct 29, 2010, at 6:19 AM, Serge Stinckwich wrote:
On Fri, Oct 29, 2010 at 5:14 PM, James Robertson <jarober@gmail.com> wrote:
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
But comparing to Ruby, there is no standard UI in Ruby and this not really annoying for the people, because they deploy their application on the web.
Regards,
-- 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
Serge Stinckwich wrote:
But comparing to Ruby, there is no standard UI in Ruby and this not really annoying for the people, because they deploy their application on the web.
Hence my remark that standard UI is less of an issue on the web :) James Robertson 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. -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.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-tp3018404p301... 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-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.com.
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
On Fri, Oct 29, 2010 at 2:23 PM, Paolo Bonzini <bonzini@gnu.org> 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/
SergeStinckwich wrote:
So if we have a Smalltalk text pane with a VI or emacs bindings, they will be happy ? ;-)
If I had VI key bindings when I started using Squeak, it would have eased my adoption greatly - it was really hard for me to give up the power and efficiency of doing everything without taking my fingers off the keyboard. One of the answers I got was that because good Smalltalk methods are short, you don't need them - ha ha. So we have our own religion, too :) In actuality, this just makes the dramatic productivity increase the key bindings offer less. But here's the joke - the SVI project provides VI bindings. Here's another, Lukas showed a git interface at ESUG. A third? The GTK bindings mentioned were originally in Squeak, but there was no interest (per steph). To me, the primary issue is an inability to use and improve the things that we *already* have because: * I can't understand the intention of code - no tests and documentation * I don't know they exist - no central place/process which includes the above It seems the pattern is: 1. work on something awesome 2. let it disappear into squeaksource, because no one can find it, or figure out how to use it 3. 5 years later, have someone else do the same awesome thing from scratch 4. repeat step 2 my 2c Sean -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.com.
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/
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
I would like to try a browser that keeps track of the code navigation I have had to make so far to get where I am, something that relieves me from having to remember the graph traversal of the code. Does this exist? 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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
That sounds exactly like the TrailBlazer browser in VisualAge. -- Best regards, Peter Hugosson-Miller On Sat, October 30, 2010 09:35, Andres Valloud wrote:
I would like to try a browser that keeps track of the code navigation I have had to make so far to get where I am, something that relieves me from having to remember the graph traversal of the code. Does this exist?
Andres, On Oct 30, 2010, at 12:35 AM, Andres Valloud wrote:
I would like to try a browser that keeps track of the code navigation I have had to make so far to get where I am, something that relieves me from having to remember the graph traversal of the code. Does this exist?
In Newspeak, the Hopscotch browser maintains a history of everywhere you've been, which is always one click away - which means any class, object, workspace etc. is at most two clicks away at all times. I'm not sure if this is what you meant While I'm on the topic of Newspeak, here are some observations that are perhaps relevant to this thread. Be aware that I am engaged in shameless self promotion. a. Newspeak has a syntax. So: b You can edit Newspeak in whatever editor you want. The IDE runs in an image in the classic Smalltalk way, but also saves each class you modify in a file automatically. c. The IDE has integrated support for source control. Currently this uses a svn-Monticello integration, but the next phase will phase out Monticello and work directly with mercurial, git or svn. Furthermore e. Newspeak introduced the Alien FFI, which allows us to use the rest of the world's software. Case in point: we recently needed to talk to some software over https. Squeak does not support this natively, and requires a plugin, which is by its own documentation unstable. We just call out to libCurl. f. Using said aliens, we support a portable native GUI. Looks great on a modern Windows machine. We could support mac as well, if we had more resources. But, as Andres implies, this is fighting the last war. Hence: g. We are getting close to running the exact same GUI in a browser. h. As far as deployment goes, we can deploy apps independent of the IDE - either via the browser or as executables (on Windows) or, in principle, anything else. That is because the language actually supports modularity. Some of these features need more work to reach full maturity. This could happen sooner if we got more volunteers. While the Smalltalk community might be a good source of such volunteers, I recognize it isn't happening. So, what am I doing wrong? Newspeak is open source, it runs Squeak Smalltalk as well as Newspeak, and provides a very Smalltalk-like experience for those who want it, while addressing many of the issues that have been brought up in this thread. Even so, very few Smalltalkers are interested in working with Newspeak.
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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Cheers, Gilad
On 10/30/2010 11:17 AM, Gilad Bracha wrote:
So, what am I doing wrong? Newspeak is open source, it runs Squeak Smalltalk as well as Newspeak, and provides a very Smalltalk-like experience for those who want it, while addressing many of the issues that have been brought up in this thread. Even so, very few Smalltalkers are interested in working with Newspeak.
I've honestly been tempted many times to see what it means to port GNU Smalltalk to Newspeak the same way Squeak runs on top of it. Time is unfortunately always a problem. Paolo
Gilad, On 10/30/2010 2:17 AM, Gilad Bracha wrote:
In Newspeak, the Hopscotch browser maintains a history of everywhere you've been, which is always one click away - which means any class, object, workspace etc. is at most two clicks away at all times. I'm not sure if this is what you meant
I mean more like seeing an actual graph with nodes so I can see the shape of the traversal. I don't know if this would help in practice, but I'd like to try it. Or has this approach been tried before and I just missed it? Andres.
Gilad, I do not think you are "doing wrong" as you formulated it. In a way we Smalltalkers are maybe a bit conservative, but speaking for myself I have always found Newspeak extremely enticing. It was, as I am sure is the case for many more Smalltalkers (and my guess is many more than you suspect based on your post), always on my "should-look-into-it" list, but I just did not find (and make ;-)) the time to actually put some effort into it. I think it is worthwhile to try to make others than yourself make more noise about it, not only within the Smalltalk community. It may be a subject for another thread but I would like to put out a call among the members of this mailing list, not per-se to actually and structurally participate in the Newspeak effort, but at least to let others and Gilad know that Newspeak is on your radar and that Gilad will not need to say that "very few Smalltalkers are interested in Newspeak". I know I am! 2010/10/30 Gilad Bracha <gilad@bracha.org>
Andres,
On Oct 30, 2010, at 12:35 AM, Andres Valloud wrote:
I would like to try a browser that keeps track of the code navigation I have had to make so far to get where I am, something that relieves me from having to remember the graph traversal of the code. Does this exist?
In Newspeak, the Hopscotch browser maintains a history of everywhere you've been, which is always one click away - which means any class, object, workspace etc. is at most two clicks away at all times. I'm not sure if this is what you meant
While I'm on the topic of Newspeak, here are some observations that are perhaps relevant to this thread. Be aware that I am engaged in shameless self promotion.
a. Newspeak has a syntax. So:
b You can edit Newspeak in whatever editor you want. The IDE runs in an image in the classic Smalltalk way, but also saves each class you modify in a file automatically. c. The IDE has integrated support for source control. Currently this uses a svn-Monticello integration, but the next phase will phase out Monticello and work directly with mercurial, git or svn.
Furthermore
e. Newspeak introduced the Alien FFI, which allows us to use the rest of the world's software. Case in point: we recently needed to talk to some software over https. Squeak does not support this natively, and requires a plugin, which is by its own documentation unstable. We just call out to libCurl.
f. Using said aliens, we support a portable native GUI. Looks great on a modern Windows machine. We could support mac as well, if we had more resources. But, as Andres implies, this is fighting the last war. Hence:
g. We are getting close to running the exact same GUI in a browser.
h. As far as deployment goes, we can deploy apps independent of the IDE - either via the browser or as executables (on Windows) or, in principle, anything else. That is because the language actually supports modularity.
Some of these features need more work to reach full maturity. This could happen sooner if we got more volunteers. While the Smalltalk community might be a good source of such volunteers, I recognize it isn't happening.
So, what am I doing wrong? Newspeak is open source, it runs Squeak Smalltalk as well as Newspeak, and provides a very Smalltalk-like experience for those who want it, while addressing many of the issues that have been brought up in this thread. Even so, very few Smalltalkers are interested in working with Newspeak.
We do have Newspeak listed on http://www.world.st/implementations so everyone should make some time :) -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p302... Sent from the ESUG mailing list archive at Nabble.com.
Hi Geert, Rob and others, On Oct 30, 2010, at 8:24 AM, Geert Claes wrote:
We do have Newspeak listed on http://www.world.st/implementations so everyone should make some time :)
Thanks for that and for the good intentions! If I may, I'll make one more observation. This thread (and similar ones, oft repeated among Smalltalkers) bemoans the fact that others do not see the beauty of Smalltalk. What I liked about this thread was that Smalltalkers were engaged in serious self examination. There seemed to be a realization that some things need real changes. Perhaps as part of this self examination, one can see how hard it is to get out of one's comfort zone. The effort of engaging with and learning something different is more than most people can find the time and energy for - even when the differences are relatively modest, as in the case of Newspeak. Some of the reasons some of you cannot get around to really getting involved with Newspeak are quite analogous to the reasons why your Pythonista or Java (or whatever) colleagues cannot get serious about Smalltalk. I am well aware that this is not a terribly actionable observation. It's just the way it is. What one can do is identify weaknesses and work hard at fixing them, and hope that some people will find it worthwhile to become truly involved. Cheers, Gilad
Hi Gilad and all - This is a worthwhile topic, one to which I intend to respond, but it will take some time. Let's start by renaming the thread...
If I may, I'll make one more observation. This thread (and similar ones, oft repeated among Smalltalkers) bemoans the fact that others do not see the beauty of Smalltalk. What I liked about this thread was that Smalltalkers were engaged in serious self examination. There seemed to be a realization that some things need real changes.
Perhaps as part of this self examination, one can see how hard it is to get out of one's comfort zone. The effort of engaging with and learning something different is more than most people can find the time and energy for - even when the differences are relatively modest, as in the case of Newspeak. Some of the reasons some of you cannot get around to really getting involved with Newspeak are quite analogous to the reasons why your Pythonista or Java (or whatever) colleagues cannot get serious about Smalltalk.
I am well aware that this is not a terribly actionable observation. It's just the way it is. What one can do is identify weaknesses and work hard at fixing them, and hope that some people will find it worthwhile to become truly involved.
Good People - Adoption of a language, like any other adoption, is generally a function of the needs and wants of the audience, and the strengths and weaknesses of the substance being promoted. For better or worse, this function can be significantly biased at the outset by marketing. As technologists, we repeatedly underestimate the importance of marketing and, even when we know we need to promote our systems, we fail because the skills of marketing are not simply technical skills. Who are our users? We all have our own answer for this. I'll answer for myself so that I can be articulate -- these are the users I would like to attract, or who I feel would find our system valuable if they used it... Kids at play - ie people 8-16 who are doing fun things Kids at work - ie students 8-20 who are doing more serious things like math (including computer science), physics, graphics, music, etc Computer professionals at play - most of us Computer professionals at work - most of us About the computing context The computing context has changed a lot over the years. It used to be personal computers running Mac, Windows or Unix, and it used to be simple functions like text editing and experiments with media. Now it is mostly running in "the" browser, and communicating over the web. A couple of things have remained key values, though: The ability to create new content simply and directly, and the ability to pull together existing content flexibly. By "content" I mean both media and functions (services). The ability to assemble existing content has been the greatest strength and weakness of Smalltalk over the years. For internal content, Smalltalk is unmatched in its ability to make every extension, whether music, graphics, or a financial model, as natural as a built-in language feature. For external content, however, Smalltalk has historically faltered at the edges of its monolithic system. What do the users need and want? The ability to create new content simply and directly, the ability to assemble existing content flexibly, and the ability to share any results easily. What is important for marketing An old quote of Alan's is still relevant here: "Simple things should be simple, and complex things should be possible." Smalltalk has always suffered from two main barriers: installation and integration. Once you have it installed, and if you don't need to access anything outside, it is unmatched in its ability to make simple things simply, and to achieve complex goals as well. Within its self-contained context, its image model is perfect for saving, restoring, and sharing work between sessions, between machines, and between users. In the world of today, people expect any new thing of interest to spring to life in their browser. They expect it to look attractive, cool, powerful; anything but geeky... <http://emberapp.com/>http://emberapp.com/ <http://www.thecssawards.com/> http://www.thecssawards.com/ <http://cssmania.com/galleries/>http://cssmania.com/galleries/ You want this, too, right? So we can use "we" in place of "they". We expect it to be immediately useful. For a computer language, this means you can immediately try out some expressions and make something happen. We want this. We are busy, and we don't have time to download a new environment, figure out a new browser, learn a new graphics system, right? We expect it to be incremental - do some work, save it, pick it up later - we expect the comforts of Smalltalk-style development. We expect it to be sharable - do something and send it to someone. It's what we do with email, photos and videos. We probably want it to be self-sharing, how about your workspace in your facebook page, and tweets about each cool new thing. These are the things that Gilad and I are grappling with, and I think everyone on this list probably thinks the same way from time to time. Gilad is trying to fix some of the modularity problems in Smalltalk and exploit some of its greatest strengths, while figuring out how to host it in today's (or tomorrow's) browsers. And I've been playing around with what's possible using JavaScript directly, but with some Smalltalk comforts like a nice browser, work in a live editable environment, and save your project state as a web page. To return to Gilad's post, [my interpretation: We don't take the time and effort to explore new systems, and we don't take the time and effort to make our own systems easy for others to explore]
I am well aware that this is not a terribly actionable observation. It's just the way it is. What one can do is identify weaknesses and work hard at fixing them, and hope that some people will find it worthwhile to become truly involved.
I feel the same way. But if you feel the same way from time to time, perhaps you should start a movement to do something similar, or see how you could contribute to NewSpeak or the Lively Kernel; not to abandon Smalltalk but to experiment with how to carry *its goals* and *your desires* forward. Nothing is holding us back - D
Dan, how would you reconcile the need for immediate usefulness and the assumption that "we are busy, and we don't have time to download a new environment, figure out a new browser, learn a new graphics system", with Alan's assertion that technology these days is flawed because it requires little effort? ================ A twentieth century problem is that technology has become too "easy". When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. This is inverse vandalism: the making of things because you can. Couple this to even less sophisticated buyers and you have generated an exploitation marketplace similar to that set up for teenagers. A counter to this is to generate enormous dissatisfaction with one's designs using the entire history of human art as a standard and goal. Then the trick is to decouple the dissatisfaction from self worth--otherwise it is either too depressing or one stops too soon with trivial results. ================ In this context, what does it mean to be useful if it requires no effort? Is this an issue of being able to quickly differentiate ourselves from others because, absent a flashy presentation, we feel we (and our work) are indistinguishable from others (and their work)? Not that we have control over that issue, but I think it would be important to acknowledge that motivation explicitly if it is really there. On 10/30/2010 1:48 PM, Dan Ingalls wrote:
Good People -
Adoption of a language, like any other adoption, is generally a function of the needs and wants of the audience, and the strengths and weaknesses of the substance being promoted. For better or worse, this function can be significantly biased at the outset by marketing. As technologists, we repeatedly underestimate the importance of marketing and, even when we know we need to promote our systems, we fail because the skills of marketing are not simply technical skills.
Who are our users? We all have our own answer for this. I'll answer for myself so that I can be articulate -- these are the users I would like to attract, or who I feel would find our system valuable if they used it... Kids at play - ie people 8-16 who are doing fun things Kids at work - ie students 8-20 who are doing more serious things like math (including computer science), physics, graphics, music, etc Computer professionals at play - most of us Computer professionals at work - most of us
About the computing context The computing context has changed a lot over the years. It used to be personal computers running Mac, Windows or Unix, and it used to be simple functions like text editing and experiments with media. Now it is mostly running in "the" browser, and communicating over the web. A couple of things have remained key values, though: The ability to create new content simply and directly, and the ability to pull together existing content flexibly. By "content" I mean both media and functions (services). The ability to assemble existing content has been the greatest strength and weakness of Smalltalk over the years. For internal content, Smalltalk is unmatched in its ability to make every extension, whether music, graphics, or a financial model, as natural as a built-in language feature. For external content, however, Smalltalk has historically faltered at the edges of its monolithic system.
What do the users need and want? The ability to create new content simply and directly, the ability to assemble existing content flexibly, and the ability to share any results easily.
What is important for marketing An old quote of Alan's is still relevant here: "Simple things should be simple, and complex things should be possible." Smalltalk has always suffered from two main barriers: installation and integration. Once you have it installed, and if you don't need to access anything outside, it is unmatched in its ability to make simple things simply, and to achieve complex goals as well. Within its self-contained context, its image model is perfect for saving, restoring, and sharing work between sessions, between machines, and between users.
In the world of today, people expect any new thing of interest to spring to life in their browser. They expect it to look attractive, cool, powerful; anything but geeky... http://emberapp.com/ http://www.thecssawards.com/ http://cssmania.com/galleries/ You want this, too, right? So we can use "we" in place of "they". We expect it to be immediately useful. For a computer language, this means you can immediately try out some expressions and make something happen. We want this. We are busy, and we don't have time to download a new environment, figure out a new browser, learn a new graphics system, right? We expect it to be incremental - do some work, save it, pick it up later - we expect the comforts of Smalltalk-style development. We expect it to be sharable - do something and send it to someone. It's what we do with email, photos and videos. We probably want it to be self-sharing, how about your workspace in your facebook page, and tweets about each cool new thing.
These are the things that Gilad and I are grappling with, and I think everyone on this list probably thinks the same way from time to time. Gilad is trying to fix some of the modularity problems in Smalltalk and exploit some of its greatest strengths, while figuring out how to host it in today's (or tomorrow's) browsers. And I've been playing around with what's possible using JavaScript directly, but with some Smalltalk comforts like a nice browser, work in a live editable environment, and save your project state as a web page.
To return to Gilad's post, [my interpretation: We don't take the time and effort to explore new systems, and we don't take the time and effort to make our own systems easy for others to explore]
I am well aware that this is not a terribly actionable observation. It's just the way it is. What one can do is identify weaknesses and work hard at fixing them, and hope that some people will find it worthwhile to become truly involved.
I feel the same way. But if you feel the same way from time to time, perhaps you should start a movement to do something similar, or see how you could contribute to NewSpeak or the Lively Kernel; not to abandon Smalltalk but to experiment with how to carry *its goals* and *your desires* forward.
Nothing is holding us back
- D
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi Andres -
Dan, how would you reconcile the need for immediate usefulness and the assumption that "we are busy, and we don't have time to download a new environment, figure out a new browser, learn a new graphics system", with Alan's assertion that technology these days is flawed because it requires little effort?
To me it's a question of curriculum. You start with a few interesting things on the table and go from there. I don't think Alan has any problem with this. You need to engage your audience one way or another. Hopefully the initial set is somehow provocative.
================ A twentieth century problem is that technology has become too "easy". When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. This is inverse vandalism: the making of things because you can. Couple this to even less sophisticated buyers and you have generated an exploitation marketplace similar to that set up for teenagers. A counter to this is to generate enormous dissatisfaction with one's designs using the entire history of human art as a standard and goal. Then the trick is to decouple the dissatisfaction from self worth--otherwise it is either too depressing or one stops too soon with trivial results. ================
In this context, what does it mean to be useful if it requires no effort?
I'm not saying no effort to build significant stuff. But no effort to engage -- that's good curriculum / good marketing.
Is this an issue of being able to quickly differentiate ourselves from others because, absent a flashy presentation, we feel we (and our work) are indistinguishable from others (and their work)? Not that we have control over that issue, but I think it would be important to acknowledge that motivation explicitly if it is really there.
No, it's more about not differentiating ourselves negatively -- not adding barriers. Show what you are at first click, and what you can do at second click. I'm not saying I've succeeded here, but I know it matters. - D
Dan Ingalls wrote:
... As technologists, we repeatedly underestimate the importance of marketing and, even when we know we need to promote our systems, we fail because the skills of marketing are not simply technical skills.
Marketing should not be something which is done by non-technologists only, it is about keeping the user as the central focus of "all" activities. As you said, its about who the users are, and also about what their expectations are and how to best address these. Dan Ingalls wrote:
... Now it is mostly running in "the" browser, and communicating over the web....
Agree! Dan Ingalls wrote:
...Smalltalk has always suffered from two main barriers: installation and integration. Once you have it installed, and if you don't need to access anything outside, it is unmatched in its ability to make simple things simply, and to achieve complex goals as well...
I think Gilad was onto something with his "Objects as Software Services" talk at OOPSLA 2005 about not just the installation, but also the continuos upgrade process. For systems running in the cloud it may be a different story again? Dan Ingalls wrote:
In the world of today, people expect any new thing of interest to spring to life in their browser. They expect it to look attractive, cool, powerful; anything but geeky...
Agree again. Dan Ingalls wrote:
We expect it to be immediately useful. For a computer language, this means you can immediately try out some expressions and make something happen. We want this. We are busy, and we don't have time to download a new environment, figure out a new browser, learn a new graphics system, right? We expect it to be incremental - do some work, save it, pick it up later - we expect the comforts of Smalltalk-style development....
The "download a new environment" may not mean to a local machine, because I would like to add that we also expect to pick it up anywhere and probably also on any device! -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p302... Sent from the ESUG mailing list archive at Nabble.com.
On Sun, Oct 31, 2010 at 8:52 AM, Geert Claes <geert.wl.claes@gmail.com>wrote:
Dan Ingalls wrote:
... As technologists, we repeatedly underestimate the importance of marketing and, even when we know we need to promote our systems, we fail because the skills of marketing are not simply technical skills.
Marketing should not be something which is done by non-technologists only, it is about keeping the user as the central focus of "all" activities. As you said, its about who the users are, and also about what their expectations are and how to best address these.
Hi, I strongly agree on this. IMHO community projects need good leaders to be successful, people who cares about attracting people, create fun and visibility, discuss and set orientations, establish effective processes to lower waste of time and allow newbies to easily submit a one line code patch and give immediate feedback to them. So it means that a leader's work is actually more reading and answering emails, write documentation, retrospectives and visions than writing code. Today social network usage is strong, people search for friends and eventually build things together for fun and status, write blogs, create beautiful web sites, ... Agile movement shows how vital communication and fun are. Maybe people/community is the most important thing on these projects. Good design / technical aspect seems only the second most important thing :) Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/
Hi Geert - <several snips>
The "download a new environment" may not mean to a local machine, because I would like to add that we also expect to pick it up anywhere and probably also on any device!
I agree. We are still learning what is the sweet spot in the mobile/cloud universe, and how this relates to earlier client/server experience. - Dan
Hi again - I will stop polluting this otherwise sane list, but I can't resist one more thought... You know I never left Smalltalk; I'm just using another language right now ;-). One of the early thoughts I had when working on the Lively Kernel was to put a Smalltalk "skin" on top of it, and I'd have a Lively Smalltalk. I was going to release it to SqueakLand as an April Fool's prank, but the day came and went; then a year came and went, and so it goes... Meanwhile, Alex Warth sketched a Smalltalk evaluator in OMeta and put it up on his Tin Lizzie site. Anticipating various fun language experiments, we then integrated OMeta (as JavaScript) with the Lively Kernel, and Robert Krahn put together a Lively version of Alex's experiment. You might find it intriguing... http://lively-kernel.org/repository/webwerkstatt/Dan/OMeta-Smalltalk-Demo.xh... This should work on Safari, Chrome, Firefox and Opera, with iPad and IE9 working RSN. You should be able to select expressions and evaluate them with cmd-p or something similar (different in different browsers and platforms). If all else fails, you should be able to bring up a menu with cmd-click, and select Text-functions/print-it. Don't forget to scroll the Smalltalk workspace up -- the best examples are out of view. So, is this a joke? Modern JavaScripts runs at a speed comparable to Squeak The graphics are resolution-independent and anti-aliased It runs in almost every browser You don't need to install it to run You can save your work on a web page and share it that way too Of course it's only a two-day hack, but what if someone actually got serious about it? And what about the synergy with Gilad's interest in compiling Newspeak to JS? For me, I think we could have a lot of fun in the next year. If this tickles your fancy, hop on the Lively Kernel mail list and we'll try to give you some support. The documentation is sparse but the people are friendly. All the best - Dan
On 10/31/2010 11:32 PM, Dan Ingalls wrote:
http://lively-kernel.org/repository/webwerkstatt/Dan/OMeta-Smalltalk-Demo.xh...
Doesn't load in Firefox 3.6 (pistons spin forever), crashes the browser in Epiphany (WebKit-based). :( Paolo
I see the¨"loading" splashbox, it is taking more than 10 minutes from when started, how much time it takes to load? ----- Original Message ----- From: "Paolo Bonzini" <bonzini@gnu.org> To: "Dan Ingalls" <dan@squeakland.org> Cc: <esug-list@lists.esug.org> Sent: Sunday, October 31, 2010 8:48 PM Subject: Re: [Esug-list] Is he kidding?
On 10/31/2010 11:32 PM, Dan Ingalls wrote:
http://lively-kernel.org/repository/webwerkstatt/Dan/OMeta-Smalltalk-Demo.xh...
Doesn't load in Firefox 3.6 (pistons spin forever), crashes the browser in Epiphany (WebKit-based). :(
Paolo
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi Dan, Very cool. So let me expand on what I am after. I want to write full scale Newspeak programs that don't know or care about the DOM or the browser and run them in the browser. I want to run that same program natively on a mac or Windows. I also want to run the same program with a UI tweaked for a touchscreen of the appropriate size, natively on a tablet - any tablet. I even want to run the full IDE this way, though that is less crucial. And again, allowing for size and functionality, I want to run Newspeak apps a smartphone. Independent of whether its Android, IOS, Windows 7 or RIM or whatever else. This is a tall order, and of all these things perhaps the browser is the most important, and could subsume the others. And I want it in a mature Newspeak that is secure as well as elegant. We'll see if I get there, and when. End commercial. On Oct 31, 2010, at 3:32 PM, Dan Ingalls wrote:
Hi again -
I will stop polluting this otherwise sane list, but I can't resist one more thought...
You know I never left Smalltalk; I'm just using another language right now ;-). One of the early thoughts I had when working on the Lively Kernel was to put a Smalltalk "skin" on top of it, and I'd have a Lively Smalltalk. I was going to release it to SqueakLand as an April Fool's prank, but the day came and went; then a year came and went, and so it goes...
Meanwhile, Alex Warth sketched a Smalltalk evaluator in OMeta and put it up on his Tin Lizzie site. Anticipating various fun language experiments, we then integrated OMeta (as JavaScript) with the Lively Kernel, and Robert Krahn put together a Lively version of Alex's experiment. You might find it intriguing...
http://lively-kernel.org/repository/webwerkstatt/Dan/OMeta-Smalltalk-Demo.xh...
This should work on Safari, Chrome, Firefox and Opera, with iPad and IE9 working RSN. You should be able to select expressions and evaluate them with cmd-p or something similar (different in different browsers and platforms). If all else fails, you should be able to bring up a menu with cmd-click, and select Text-functions/print-it. Don't forget to scroll the Smalltalk workspace up -- the best examples are out of view.
So, is this a joke?
Modern JavaScripts runs at a speed comparable to Squeak The graphics are resolution-independent and anti-aliased It runs in almost every browser You don't need to install it to run You can save your work on a web page and share it that way too
Of course it's only a two-day hack, but what if someone actually got serious about it? And what about the synergy with Gilad's interest in compiling Newspeak to JS? For me, I think we could have a lot of fun in the next year. If this tickles your fancy, hop on the Lively Kernel mail list and we'll try to give you some support. The documentation is sparse but the people are friendly.
All the best
- Dan
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Cheers, Gilad
Hi guys Let me restate clearly the goal of pharo: We want a small, clean kernel. Now it does not mean that we want a smalltalk like one of the 80 :) nor one that is only looking like Smalltalk from far :). We want an innovative Smalltalk. Right now we are re-aligning the current implementation (you know squashing wrong lines and adding abstractions). Of course there are work. We would love to have a UIBuilder (and this is not because of lack of vision) and a lot more. But we want new way to structure program (traits, modules,...), solutions to provide security concerns..... But this is something that needs time to build prototype, evaluate redo, turn them into more robust solutions. So dan if you want to take pharo and run it into JS please go. We are writing a new compiler which can be certainly tweaked to generate jsbytecode (if any). Now Dan may be you should have started to build a smalltalk on Javascript and people may have understood your intentions.
From far it looked like Morphic with a funny (not fun) syntax.
Stef PS: in 2001 we could only do anything beside Java, nowadays it seems that the dogma changed again and that we cannot do anything but Javascript. This is not what you said of course I read well english but this is a fun to see cycles.
Hello Dan, I'd like to thank you for your inspiring observations, and add some information on recent developments inline. At 21:48 30/10/2010, Dan Ingalls wrote:
Good People -
Adoption of a language, like any other adoption, is generally a function of the needs and wants of the audience, and the strengths and weaknesses of the substance being promoted. For better or worse, this function can be significantly biased at the outset by marketing. As technologists, we repeatedly underestimate the importance of marketing and, even when we know we need to promote our systems, we fail because the skills of marketing are not simply technical skills.
Who are our users? We all have our own answer for this. I'll answer for myself so that I can be articulate -- these are the users I would like to attract, or who I feel would find our system valuable if they used it... Kids at play - ie people 8-16 who are doing fun things Kids at work - ie students 8-20 who are doing more serious things like math (including computer science), physics, graphics, music, etc Computer professionals at play - most of us Computer professionals at work - most of us
About the computing context The computing context has changed a lot over the years. It used to be personal computers running Mac, Windows or Unix, and it used to be simple functions like text editing and experiments with media. Now it is mostly running in "the" browser, and communicating over the web. A couple of things have remained key values, though: The ability to create new content simply and directly, and the ability to pull together existing content flexibly. By "content" I mean both media and functions (services). The ability to assemble existing content has been the greatest strength and weakness of Smalltalk over the years. For internal content, Smalltalk is unmatched in its ability to make every extension, whether music, graphics, or a financial model, as natural as a built-in language feature. For external content, however, Smalltalk has historically faltered at the edges of its monolithic system.
What do the users need and want? The ability to create new content simply and directly, the ability to assemble existing content flexibly, and the ability to share any results easily.
There is a Smalltalk- and Seaside-based solution for web applications that provide this sort of functionality. In particular, it allows managing and sharing application functionality and executions as content. Here is an example: - URL for the definition of an activity model (user-defined service): <http://www.afacms.com/cats/activities/shopping/Seaside/>http://www.afacms.com/cats/activities/shopping/Seaside/ - URL for one of its executions: <http://www.afacms.com/cats/activities/shopping/Seaside/seaside-trace-1/>http://www.afacms.com/cats/activities/shopping/Seaside/seaside-trace-1/ - URL to the cart items during that execution: <http://www.afacms.com/cats/activities/shopping/Seaside/seaside-trace-1/fillandconfirmcart-trace/myfilledcart-trace/storecart>http://www.afacms.com/cats/activities/shopping/Seaside/seaside-trace-1/fillandconfirmcart-trace/myfilledcart-trace/storecart I'd like in particular your attention to the "Twitter & England traffic info communication" example, whose definition and detailed documentation are available via: <http://www.afacms.com/examples>http://www.afacms.com/examples This example wants to show that the distinction between internal and external "functional content" is somehow blurred in this solution, since it allows "wrapping" web services as if they were implemented in Smalltalk. Further explanations and examples may be found online via: <http://www.afacms.com/blog/pontoon-app>http://www.afacms.com/blog/pontoon-app Another application example would be creating websites for online authoring and execution of eToys projects. This would whoever require integrating Lively Kernel libraries into Seaside.
What is important for marketing An old quote of Alan's is still relevant here: "Simple things should be simple, and complex things should be possible." Smalltalk has always suffered from two main barriers: installation and integration. Once you have it installed, and if you don't need to access anything outside, it is unmatched in its ability to make simple things simply, and to achieve complex goals as well. Within its self-contained context, its image model is perfect for saving, restoring, and sharing work between sessions, between machines, and between users.
In the world of today, people expect any new thing of interest to spring to life in their browser.
In the above-mentioned solution, sophisticated business logic may keep to be coded is Smalltalk, while the application allows online definition and integration of new functionality by end-user programming. End-user defined services are directly represented as executable models.
They expect it to look attractive, cool, powerful; anything but geeky... <http://emberapp.com/>http://emberapp.com/ http://www.thecssawards.com/ <http://cssmania.com/galleries/>http://cssmania.com/galleries/ You want this, too, right? So we can use "we" in place of "they". We expect it to be immediately useful. For a computer language, this means you can immediately try out some expressions and make something happen. We want this. We are busy, and we don't have time to download a new environment, figure out a new browser, learn a new graphics system, right? We expect it to be incremental - do some work, save it, pick it up later - we expect the comforts of Smalltalk-style development. We expect it to be sharable - do something and send it to someone. It's what we do with email, photos and videos. We probably want it to be self-sharing, how about your workspace in your facebook page, and tweets about each cool new thing.
Online definition of complex executable models is currently possible. Now, I'm in the process of simplifying yet more the online programming interface so as end-users can implement simple services really simply (without any training). There is no need for ordinary end-users to download or install any piece of software, although, Smalltalk programmers can still update and extend online the application server code. We are currently investigating opportunities for very large deployments for individualized support to Older Adults. Our marketing arguments are summarized here: <http://www.aas-platform.com/about/aas/key-features/>http://www.aas-platform.com/about/aas/key-features/ We try to contribute to the community grow by creating a significant space for development and commercialization of online reusable "atomic" services, in particular for Seaside components and wrappers for web services like those by major web actors. The following web-site is setup and will hopefully develop further in the coming weeks: <http://pontoonity.com/>http://pontoonity.com/ More on potential application to user-generated services may be found here: http://www.aas-platform.com/about/related-work/ugs/ This work relates further to Lively Wiki, as described here: <http://www.rezarazavi.com/about/cv/publications/iwst-2010>http://www.rezarazavi.com/about/cv/publications/iwst-2010 I'd greatly appreciate any feedback from your part, Best regards, /Reza
These are the things that Gilad and I are grappling with, and I think everyone on this list probably thinks the same way from time to time. Gilad is trying to fix some of the modularity problems in Smalltalk and exploit some of its greatest strengths, while figuring out how to host it in today's (or tomorrow's) browsers. And I've been playing around with what's possible using JavaScript directly, but with some Smalltalk comforts like a nice browser, work in a live editable environment, and save your project state as a web page.
To return to Gilad's post, [my interpretation: We don't take the time and effort to explore new systems, and we don't take the time and effort to make our own systems easy for others to explore]
I am well aware that this is not a terribly actionable observation. It's just the way it is. What one can do is identify weaknesses and work hard at fixing them, and hope that some people will find it worthwhile to become truly involved.
I feel the same way. But if you feel the same way from time to time, perhaps you should start a movement to do something similar, or see how you could contribute to NewSpeak or the Lively Kernel; not to abandon Smalltalk but to experiment with how to carry *its goals* and *your desires* forward.
Nothing is holding us back
- D _______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
I'll second Gilad's thoughts. I am familiar with VisualWorks and VA, as well as no longer existent dialects like Digitalk's. However, the several times I have tried to "get into Squeak", I've landed in a UI that doesn't work like those I am familiar with, so it seems much more difficult to learn "the Squeak way". The only tutorial was about basic Smalltalk syntax and offered no guidance for Squeak. Perhaps there are some "getting started with Squeak" guides, but Squeak itself doesn't lead you to them. We can get any number of people to try a given Smalltalk implementation, but once they get there, we need to ensure they can get around in it (if they already think Smalltalk) and can learn how the Smalltalk way differs from what they are used to otherwise. Like many people, once I account for sleep, family life, and work, there isn't a lot of time left for struggling to learn something new, no matter how popular or interesting it seems to be. We need to reduce the effort to get over the first hurdles. -----Original Message----- From: esug-list-bounces@lists.esug.org [mailto:esug-list-bounces@lists.esug.org] On Behalf Of Gilad Bracha Sent: October-30-10 7:09 PM To: Geert Claes Cc: esug-list@lists.esug.org Subject: Re: [Esug-list] Few thoughts about Google Summer of Code Hi Geert, Rob and others, On Oct 30, 2010, at 8:24 AM, Geert Claes wrote:
We do have Newspeak listed on http://www.world.st/implementations so
everyone
should make some time :)
Thanks for that and for the good intentions! If I may, I'll make one more observation. This thread (and similar ones, oft repeated among Smalltalkers) bemoans the fact that others do not see the beauty of Smalltalk. What I liked about this thread was that Smalltalkers were engaged in serious self examination. There seemed to be a realization that some things need real changes. Perhaps as part of this self examination, one can see how hard it is to get out of one's comfort zone. The effort of engaging with and learning something different is more than most people can find the time and energy for - even when the differences are relatively modest, as in the case of Newspeak. Some of the reasons some of you cannot get around to really getting involved with Newspeak are quite analogous to the reasons why your Pythonista or Java (or whatever) colleagues cannot get serious about Smalltalk. I am well aware that this is not a terribly actionable observation. It's just the way it is. What one can do is identify weaknesses and work hard at fixing them, and hope that some people will find it worthwhile to become truly involved. Cheers, Gilad _______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On Sun, Oct 31, 2010 at 6:06 PM, Richard Sargent <rsargent@5x5.on.ca> wrote:
I'll second Gilad's thoughts.
I am familiar with VisualWorks and VA, as well as no longer existent dialects like Digitalk's. However, the several times I have tried to "get into Squeak", I've landed in a UI that doesn't work like those I am familiar with, so it seems much more difficult to learn "the Squeak way". The only tutorial was about basic Smalltalk syntax and offered no guidance for Squeak. Perhaps there are some "getting started with Squeak" guides, but Squeak itself doesn't lead you to them.
There is the Squeak by Example book : http://www.squeakbyexample.org/ Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
I agree with Richard.. I am familiar with VisualWorks and Digitalk's VSE. I first met Squeak back in 2007, then Pharo, I llike both. To make a progress in teaching myself, I invested too much time. Got positively caught with the Seaside one-click experience image and I am stick for the moment. Seems that the Pharo-Squeak communities are not challenged to build something like VW´s UI Builder. Having such a feature will help Smalltalk appeal to those developers that capture small-medium sized client-server projects on their own (around 100 days of effort) that are not interesting targets to the the large consultancy businesses. ----- Original Message ----- From: "Richard Sargent" <rsargent@5x5.on.ca> To: <esug-list@lists.esug.org> Sent: Sunday, October 31, 2010 8:06 AM Subject: Re: [Esug-list] Few thoughts about Google Summer of Code
I'll second Gilad's thoughts.
I am familiar with VisualWorks and VA, as well as no longer existent dialects like Digitalk's. However, the several times I have tried to "get into Squeak", I've landed in a UI that doesn't work like those I am familiar with, so it seems much more difficult to learn "the Squeak way". The only tutorial was about basic Smalltalk syntax and offered no guidance for Squeak. Perhaps there are some "getting started with Squeak" guides, but Squeak itself doesn't lead you to them.
We can get any number of people to try a given Smalltalk implementation, but once they get there, we need to ensure they can get around in it (if they already think Smalltalk) and can learn how the Smalltalk way differs from what they are used to otherwise.
Like many people, once I account for sleep, family life, and work, there isn't a lot of time left for struggling to learn something new, no matter how popular or interesting it seems to be. We need to reduce the effort to get over the first hurdles.
-----Original Message----- From: esug-list-bounces@lists.esug.org [mailto:esug-list-bounces@lists.esug.org] On Behalf Of Gilad Bracha Sent: October-30-10 7:09 PM To: Geert Claes Cc: esug-list@lists.esug.org Subject: Re: [Esug-list] Few thoughts about Google Summer of Code
Hi Geert, Rob and others,
On Oct 30, 2010, at 8:24 AM, Geert Claes wrote:
We do have Newspeak listed on http://www.world.st/implementations so
everyone
should make some time :)
Thanks for that and for the good intentions!
If I may, I'll make one more observation. This thread (and similar ones, oft repeated among Smalltalkers) bemoans the fact that others do not see the beauty of Smalltalk. What I liked about this thread was that Smalltalkers were engaged in serious self examination. There seemed to be a realization that some things need real changes.
Perhaps as part of this self examination, one can see how hard it is to get out of one's comfort zone. The effort of engaging with and learning something different is more than most people can find the time and energy for - even when the differences are relatively modest, as in the case of Newspeak. Some of the reasons some of you cannot get around to really getting involved with Newspeak are quite analogous to the reasons why your Pythonista or Java (or whatever) colleagues cannot get serious about Smalltalk.
I am well aware that this is not a terribly actionable observation. It's just the way it is. What one can do is identify weaknesses and work hard at fixing them, and hope that some people will find it worthwhile to become truly involved.
Cheers, Gilad
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Agreed. UI frameworks are an officially certified Hard Problem. :) Julian On 10/29/10, Andres Valloud <avalloud@cincom.com> wrote:
One such difficult problem would be to make a visually compelling UI framework, fully capable of supporting and deploying real production applications.
On 10/29/2010 1:35 AM, Julian Fitzell wrote:
On Fri, Oct 29, 2010 at 8:47 AM, Andres Valloud<avalloud@cincom.com> wrote:
Its not just appearance Andres, it's the complete User eXperience: intuitiveness, ease of use, productivity, fun factor as well as the look and feel. A lot of progress has already been made in this area, but there is still a long way to go because most Smalltalk IDE's have not evolved that much since the 70's ... that's probably part of why Smalltalk is being treated like a black and white movie :)
But see, I'm already sold, so I just don't see the point :)... IMO, we will make the most progress in this area by concentrating our efforts on the difficult problems. It makes me happy to see people concerned with how to make an image from scratch, for example.
As someone who spends much of my time dealing with Smalltalk users, customers, and prospects, I can say that it *does* matter to most people. Solving difficult problems is a very valuable thing to do, but without doing it in an environment that is broadly appealing (visually, UX, etc. as Geert says) Smalltalk will never have any chance of being more than a tiny niche (think of WinAmp or VLC - neither would have been successful without attractive, intuitive user interfaces, even though the real reason I used/use them was for the really practical features).
Julian
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On 29. 10. 2010 10:35, Julian Fitzell wrote:
On 29. 10. 2010 09:34, Geert Claes wrote: Its not just appearance Andres, it's the complete User eXperience: intuitiveness, ease of use, productivity, fun factor as well as the look and feel. A lot of progress has already been made in this area, but there is still a long way to go because most Smalltalk IDE's have not evolved that much since the 70's ... that's probably part of why Smalltalk is being treated like a black and white movie :)
As someone who spends much of my time dealing with Smalltalk users, customers, and prospects, I can say that it *does* matter to most people. Solving difficult problems is a very valuable thing to do, but without doing it in an environment that is broadly appealing (visually, UX, etc. as Geert says) Smalltalk will never have any chance of being more than a tiny niche
Agree completely. Aesthetics is very important moment here, specially in a world where perception is more important than reality, as Graham very nicely shown with his examples. That's why we need to be balanced here, we need to make a better "perception" (look&feel, marketing, documentation,...) but be careful not to forget to our "reality" (technical brilliance), which is actually our stronger point and which is the cause why Smalltalk is resurrecting again and again Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
Thanks Dennis for this detailed feedback. It's important to keep the community informed. On 29 oct. 2010, at 05:41, Dennis Schetinin wrote:
We should be more open. We should find a way to start some cooperative projects with other societies/languages. [...] 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.
I fully agree. There are multiple directions to go. -Applications : We should develop cool applications that target domains that interest users (e.g. mobile applications, web). The look and feel/ user experience is important to have some impact. A recent really cool example is the Event Planning System developed by the belgian company Inceptive. We need to advertise more such applications to the outside of the community. The on-line videos and slides, blogs and the awards are made for this. Still we need more advertisements in places where we can -GUI : This is coupled with the previous item. We need native widgets. Smalltalk developers should be able to applications that comply with the appearance of other applications. Projects such as MARS (Smalltalk software with Mac OS X widgets) is an example. -Programming environments : I love the Smalltalk IDE. Still, many developers don't want to change their programming habit. May be not from the beginning. We should be able to develop Smalltalk in an text editor. This was done in GNU Smalltalk and there is also the CORAL initiative. The effort need to be continued. -Standard/Mainstream protocols, libraries, and infrastructures. We need to provide a bridge to all important pieces of software (e.g. OpenGL). Web frameworks such as Seaside, Aida are definitely a great step in this direction. -Documentation : Both on-line and paper articles and books. Code examples are important. People new to Smalltalk should quickly find some code to copy/paste and test. To sum up, there are already different actions. Still, we need to do more. If you have ideas share them with us. Spending a little of your time in one of these actions would be beneficial to everyone. Noury
-Standard/Mainstream protocols, libraries, and infrastructures. We need to provide a bridge to all important pieces of software (e.g. OpenGL).
With respect to bridging to other languages in particular, we need to be careful not to impose a Smalltalk POV on things that are not Smalltalk. For instance, the community of the "foreign" language targeted by an FFI is not going to be impressed by our efforts if they see their language misrepresented or misunderstood. This is only fair, if some other language wrote an FFI into Smalltalk, we wouldn't like this other FFI to misrepresent Smalltalk either.
People like computer scientists and modelers who are trying to solve fundamental problems, get the data structures right, get the algorithms right etc. are far more likely to look past the gloss and glitz and appreciate the power and capabilities of a language like Smalltalk.
Yes, and in some areas I think we could be doing a better job at promoting Smalltalk to those people.
What saddened me was that the projects had great looking UI's and most were available as both desktop and web applications, but the fundamental functionality, integrity, sophistication of systems and thought in design was actually at a lower standard than we had a decade ago.
I hope we manage to stay as far away from that as possible, for otherwise we would not be leveraging Smalltalk's advantages when dealing with difficult problems. And it's hard to ignore people who consistently deal with difficult problems successfully... Andres.
Noury Bouraqadi-2 wrote:
-Applications : We should develop cool applications that target domains that interest users (e.g. mobile applications, web). The look and feel/ user experience is important to have some impact. A recent really cool example is the Event Planning System developed by the belgian company Inceptive...
+1 Noury Bouraqadi-2 wrote:
-Programming environments : I love the Smalltalk IDE. Still, many developers don't want to change their programming habit. ...
Smalltalkers do love their powerful IDE, but to the average newcomer it is - compared to other IDE's these days - certainly far from being intuitive. Noury Bouraqadi-2 wrote:
-Documentation : Both on-line and paper articles and books. Code examples are important. People new to Smalltalk should quickly find some code to copy/paste and test.
Yes, I reckon a better, easier to use project/code sharing infrastructure (replacing SqueakSource) is required with more useful educational sample projects. -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.com.
Thanks for this expressions. I fully agree too !!! We are developing a Business-Process-Management-Suite, called /OfficeTalk/. /OfficeTalk /has won in the past a few awards. One of the highest priority is the GUI and the usability. /OfficeTalk /is made open to systems made with all other technologies (COM, ActiveX, DotNET, Web, aso). If we propagate more of the existing systems, Smalltalk gets more acceptance too ! Josef Springer (JOOPS Informationstechnik GmbH) Noury Bouraqadi wrote:
Thanks Dennis for this detailed feedback. It's important to keep the community informed.
On 29 oct. 2010, at 05:41, Dennis Schetinin wrote:
We should be more open. We should find a way to start some cooperative projects with other societies/languages. [...] 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.
I fully agree. There are multiple directions to go.
-Applications : We should develop cool applications that target domains that interest users (e.g. mobile applications, web). The look and feel/ user experience is important to have some impact. A recent really cool example is the Event Planning System developed by the belgian company Inceptive. We need to advertise more such applications to the outside of the community. The on-line videos and slides, blogs and the awards are made for this. Still we need more advertisements in places where we can
-GUI : This is coupled with the previous item. We need native widgets. Smalltalk developers should be able to applications that comply with the appearance of other applications. Projects such as MARS (Smalltalk software with Mac OS X widgets) is an example.
-Programming environments : I love the Smalltalk IDE. Still, many developers don't want to change their programming habit. May be not from the beginning. We should be able to develop Smalltalk in an text editor. This was done in GNU Smalltalk and there is also the CORAL initiative. The effort need to be continued.
-Standard/Mainstream protocols, libraries, and infrastructures. We need to provide a bridge to all important pieces of software (e.g. OpenGL). Web frameworks such as Seaside, Aida are definitely a great step in this direction.
-Documentation : Both on-line and paper articles and books. Code examples are important. People new to Smalltalk should quickly find some code to copy/paste and test.
To sum up, there are already different actions. Still, we need to do more. If you have ideas share them with us. Spending a little of your time in one of these actions would be beneficial to everyone.
Noury
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi Dennis, Geert, Adres, Serge and other commenters.. I used to teach information systems at the University of Cape Town, where final year students do an industry project. I visited their project demonstration expo yesterday as a a guest. I last taught there in 2003, and on that course around 2000, so it is just ten years since the last projects I supervised directly. What saddened me was that the projects had great looking UI's and most were available as both desktop and web applications, but the fundamental functionality, integrity, sophistication of systems and thought in design was actually at a lower standard than we had a decade ago. I even saw interfaces where it would require software changes to add a new product category, for example. The new shininess is largely due to the use of new tools such as Visual Studio, Web Frameworks (think JQuery, ExtJs etc. ) and new browser and OS skins (Chrome / Windows 7 etc. ). Unfortunately, like when meeting someone, or dating, first impressions count. Students (and many commercial developers and their managers who hold budgets) are impressed by shiny new toys. If these are proffered by professional looking marketing people at fancy functions at apparently successful companies (e.g. Microsoft, Oracle..) then they are all the more impressed. People like computer scientists and modelers who are trying to solve fundamental problems, get the data structures right, get the algorithms right etc. are far more likely to look past the gloss and glitz and appreciate the power and capabilities of a language like Smalltalk. So, what to do? I think there are a number of good things we can leverage, and some ideas: * Push the variants of Smalltalk that _do_ look good - these include Pharo, VisualWorks on the desktop, Dolphin etc. * Show the power of the IDEs and contrast these with the clumsy bulkiness of something like Eclipse. Here we must be careful, because there are other very slick products out there, including Visual Studio (it _is_ very pretty :| ) * Push the web capable variants (pretty much all the Smalltalks with Seaside or Aida) - many people are surprised at how well Smalltalk "does" web * Show developers the power of the language - especially the ability to create a "domain friendly" language at a level of abstraction that reduces the code required for solutions dramatically * Create literature and make it widely available on project success stories and language productivity (properly measured - e.g. function points per staff month) Interestingly, I recently was exposed to a large and "successful" Java project in an assurance environment. When we measured the developer productivity, it was about 25% lower than we were getting with mainframe COBOL in the late '70s! * And some ideas: o Link Smalltalk to "sexy" topics that have current mindshare - e.g. CloudFork is a good example. o I would like to see a GSOC project to address semantic triple store capabilities and a sematic web application of these - think Freebase o 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. ) o We should also try to put together really rich / capable development images which are easily accessible / one click install and still small enough to be grasped reasonably easily by someone new to the environment. These could include tools like: pharo, sunit, seaside, (some easy clean persistence layer), magritte, pier, swakom, moose, glamour on steroides (see previous point). Maybe integrating these tools and providing a nice dashboard could be another good GSOC target.. 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
1. 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. 2. 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. People say "wow! it's cool" and go to see Avatar. :( So developers don't take Smalltalk seriously. We (Smalltalkers) know it's a mistake. But we have to show that for others. And I found myself unable to do that there. I found language and, more likely, culture barrier is too big to overcome. I didn't manage to set up a two-way communication with others. So I listened mostly. 3. 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… 4. 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/list. 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. 5. 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… what ever. 6. 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. 7. 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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On Fri, Oct 29, 2010 at 10:17 AM, Graham McLeod <mcleod@iafrica.com> wrote:
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. )
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
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. People say "wow! it's cool" and go to see Avatar. :( So developers don't take Smalltalk seriously. We (Smalltalkers) know it's a mistake. But we have to show that for others. And I found myself unable to do that there. I found language and, more likely, culture barrier is too big to overcome. I didn't manage to set up a two-way communication with others. So I listened mostly. 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/list. 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… what ever. 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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Actually SeaBreeze does exactly what you propose here. For details see seabreeze.heeg.de. It is a UI Editor and framework on top of Seaside. Georg Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812 Tel. +49-3496-214328, Fax +49-3496-214712 -----Ursprüngliche Nachricht----- Von: esug-list-bounces@lists.esug.org [mailto:esug-list-bounces@lists.esug.org] Im Auftrag von Frank Shearar Gesendet: Freitag, 29. Oktober 2010 11:52 An: ESUG Mailing list Betreff: Re: [Esug-list] Few thoughts about Google Summer of Code On Fri, Oct 29, 2010 at 10:17 AM, Graham McLeod <mcleod@iafrica.com> wrote:
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. )
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
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. People say "wow! it's cool" and go to see Avatar. :( So developers don't take Smalltalk seriously. We (Smalltalkers) know it's a mistake. But we have to show that for others. And I found myself unable to do that there. I found language and, more likely, culture barrier is too big to overcome. I didn't manage to set up a two-way communication with others. So I listened mostly. 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 what ever. 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 Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Georg Heeg wrote:
Actually SeaBreeze does exactly what you propose here. For details see seabreeze.heeg.de. It is a UI Editor and framework on top of Seaside.
I just find the SeaBreeze Cincom software license agreement is just a bit of an awkward hurdle although I do like some concepts SeaBreeze and WebVelocity are addressing. The seabreeze.heeg.de website also really needs an up-to-date look and feel. -- View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p301... Sent from the ESUG mailing list archive at Nabble.com.
participants (25)
-
Andres Valloud -
Carlos Crosetti -
Dan Ingalls -
Davorin Rusevljan -
Dennis Schetinin -
Frank Shearar -
Geert Claes -
Georg Heeg -
Gilad Bracha -
Graham McLeod -
James Robertson -
Janko Mivšek -
Josef Springer -
Julian Fitzell -
laurent laffont -
Marten Feldtmann -
Noury Bouraqadi -
Paolo Bonzini -
Peter Hugosson-Miller -
Reza Razavi -
Richard Sargent -
Rob Vens -
Sean P. DeNigris -
Serge Stinckwich -
stephane ducasse