Usability and look-and-feel (was Re: [squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean))
2009/6/29 Hernán Morales Durand hernan.morales@gmail.com:
Dear Ian,
Hello Hernán!
I really understand your position, because I hatedthe Squeak UI for almost one year, until I started to read about Color Theory and Cognitive Pshychology and understand some things about it. However, each soul has to convince by himself or do something about it.
There are many superficial people in this crazy world. They don't get pass the current look-and-feel. It is unfortunate enough because they cannot see the true beauty behind Smalltalk. The look-and-feel is not so important to me since it's necessary to create a custom UI for our application to be deployed, and localization, deployment facilities, maintenance related stuff, etc. comes on top of my list. But, still, it's good to be able to talk about these issues and understand what the problems are.
Color Theory and Cognitive Psychology
Squeak UI is really colourful. Bright colours are stimulating and would be favourable to any child's development. It is however very difficult to spend 8, 10, or more hours a day, everyday, either on a personal project or a professional front, with such a colour scheme.
Moreover, the colours are not necessarily clearly identifying each window or graphical component; I feel lucky that it doesn't pop up the same tool with different colour each time. The lack of coherence in the colour scheme makes it exhausting and serve no other purpose than aesthetics, usability completely left aside. The lack of coherence in the general look-and-feel is also disturbing and annoying.
Usability comes second in the list of complains from my acquaintances, which I tried to Squeak-e-vangelize. The first obstacle is obviously no edit-compile-cycle but we ain't gonna get it (it makes no sense at all in Squeak). Sincerely, I think, people can get over the fact there is no edit-compile-cycle. Then, they hit themselves to a bunch of separated windows in contrast to an IDE, which traditionally provides everything integrated through panes and top menus in categories. Newcomers (or even not so new) should easily find features without having to dig into obscure menus or, sometimes, even code. Menus are a big mess. They're sometimes huge and the lack of organization is problematic. The programmers not so familiar with Squeak definitively have to understand the principle behind the workspace, transcript, class browser, saving an image, etc. Nonetheless, the sense of being lost in this new but exciting environment would not repulse them if only they could find familiar elements.
Let me put my feelings into the words of Schoenberg, he once said : "Art is not for everyone; and if it is for everyone, it is not Art.". And I believe pretty much the same here : "Smalltalk is not for everyone; and if it is for everyone, then it is not Smalltalk".
It is perfectly fine if Smalltalk is not for everyone. Though, wasn't it the initial spirit of it? Anyway, while it might not be for everyone, it shouldn't make our own community split up and flock away. Right? I've got the feeling the Squeak community has created a very comfortable niche for itself and sort of forgot about the essentials. A reality check once in a while is always good.
Cheers,
Hernán
Best regards, Ian.
Usability comes second in the list of complains from my acquaintances, which I tried to Squeak-e-vangelize. The first obstacle is obviously no edit-compile-cycle but we ain't gonna get it (it makes no sense at all in Squeak).
At this point I'm just puzzled. Why would people so deeply in love with the edit-compile-cycle they find it hard to live without it even consider Smalltalk (or Lisp, for that matter) in the first place ? I'm lost. Maybe you should start by selecting a bit more carefully the people you want to Squeak-e-vangelize (half-kidding here, no offense intended).
the programmers not so familiar with Squeak definitively have to understand the principle behind the workspace, transcript, class browser, saving an image, etc. Nonetheless, the sense of being lost in this new but exciting environment would not repulse them if only they could find familiar elements.
Or, at the contrary: let them experience a big shock that wipes out their preconceived ideas about programming. Trying to help them avoid that shock may actually make thing more difficult for them in the long term. They have to grok that Smalltalk *is* different.
Stef
There are many superficial people in this crazy world. They don't get pass the current look-and-feel. It is unfortunate enough because they cannot see the true beauty behind Smalltalk.
It is not superficial to look at Squeak and run away screaming as soon as you see it, in fact it's the exact reaction of the vast majority of developers who open up an image for the first time and it's quite a normal reaction. It looks and feels like an ugly toy rather than a serious development environment and it's Squeak's fault, not the developers.
If it looks like a toy, then it shouldn't pretend to be otherwise. If it's going to claim itself a serious platform that real work can be done on, then it needs to look and behave that way. The Pharo guys understand this, but I don't think Squeak ever will.
Progress and backwards compatibility are fundamentally opposing forces, those insisting on backwards compatibility are the ones preventing progress. Those insisting on the monolithic image of unmaintained packages are preventing progress. The Pharo guys had the right idea, break from the community containing those people so those things can be dropped and some progress can actually made instead of the yearly endless "future of Squeak" posts that always seem lead to doing nothing.
My money's Goran's first scenario: Pharo continuing to steal developer mind share and Squeak slowly stagnating and dying off.
Ramon Leon http://onsmalltalk.com
Progress and backwards compatibility are fundamentally opposing forces, those insisting on backwards compatibility are the ones preventing progress.
Because they are opposing forces, we need to balance them. What you say could be completed with: those insisting in progress are the ones preventing actual software to be implemented.
What is the point of progress if you can't harvest it ? Don't you see the drawbacks of a permanently moving target ?
Stef
Em 29-06-2009 16:03, Stéphane Rollandin escreveu:
Progress and backwards compatibility are fundamentally opposing forces, those insisting on backwards compatibility are the ones preventing progress.
Because they are opposing forces, we need to balance them. What you say could be completed with: those insisting in progress are the ones preventing actual software to be implemented.
What is the point of progress if you can't harvest it ? Don't you see the drawbacks of a permanently moving target ?
Stef
While I was working at the Secretaria de Estado da Educação de São Paulo that was the way some people found to prevent any action to be effective: if something is not excellent/optimum, then it is not worth to be considered. And in this search for excellence they didn't have even reasonable/average solutions.
I cannot figure how Pharo will deal with the problem of neglecting backwards compatibility let's say 5 years from now. Will they deploy only excellent software???? Nothing will get obsolete???? They'll rise funds to pay people to fix things every time something gets broken by a new non-backwards compatible image???? Will people be forced to work with paleolithic images????
About l&f, squeak-dev has a nice one and professional enough.
Stéphane Rollandin wrote:
Progress and backwards compatibility are fundamentally opposing forces, those insisting on backwards compatibility are the ones preventing progress.
Because they are opposing forces, we need to balance them. What you say could be completed with: those insisting in progress are the ones preventing actual software to be implemented.
Yes, and in Squeak, they are completely unbalanced, those wanting things to stay the same have won out over any major progress. The eToys thing is a perfect example, it should have been ripped out a long time ago, the eToy community already forked. The Squeak version is dead, and should have been removed but illogical resistance to change prevented it.
What is the point of progress if you can't harvest it ? Don't you see the drawbacks of a permanently moving target ?
Stef
If you can't break compatibility, there is no progress, there is only stagnation. The whole point of a version is to be able to break compatibility with previous versions, to make breaking changes, to correct mistakes of the past and make progress. Harvesting is the wrong approach, it only works for small changes. You don't harvest big rewrites, you upgrade to a new image and reload your code fix whatever your unit tests determine is now broken.
The idea of an ever evolving monolithic image that is continually patched into being current is just dead or dying. What works today is a small core image and loadable packages with unit tests so images can be rebuilt anytime, especially between versions. Unmaintained packages *should* die.
No one is forced to upgrade to the new version, if someone wants compatibility, they shouldn't upgrade. If they want the latest and greatest, then porting their code to newer versions and fixing what they broke is the price they pay, it must be that way necessarily. Otherwise there is no point in having new versions.
The drawbacks of a moving target are much less severe than the drawbacks of a stagnant and dying community which will be the end results of a attitude of not allowing breaking changes and progress. People keep forking Squeak because the Squeak community is utterly directionless and resistant to change because that's the nature of any organization led by a committee elected by diverse groups of people who don't share a common goal.
Pharo is what Squeak should have been, a place for people who actually do the work to build what they want and not be held back by those who don't and just have strong opinions and don't want things to ever change. The people actually doing the work should be the only people with any final say about what does or doesn't get done and what direction things should go. The only way to challenge the removal of old, bad, or dead code should be to volunteer to step up and maintain it.
2009/6/29 Stéphane Rollandin lecteur@zogotounga.net:
Stéphane,
There are definitively merits in favour of backward compatibility. Changes should probably be brought at a slower pace: small changes in minor versions, bigger changes to be expected in major versions. Hardly any news here. Migration tools to help maintainers should be considered. It's possible to make progress and change coexist, we have to figure out what will work in the Squeak community.
How hard would it be to implement migration tool(s) in Squeak? Anyone? Ideas?
... and reading today what I wrote almost 5 years ago, I see that I don't need to change a word: it's still pretty much the same situation.
Yes. And it will come back as long as the situation is not resolved.
What kind of maintenance do you have to do on your projects when changes are brought? What packages are your projects based on? You have to open up a little bit if you hope the community to find a suitable solution.
Ian.
What kind of maintenance do you have to do on your projects when changes are brought? What packages are your projects based on? You have to open up a little bit if you hope the community to find a suitable solution.
Sure, if it can help if I describe the way I work, I will do so. But it's not really easy. Let me think about it, so that my rambling can be somewhat useful.
Stef
Hi!
Ramon Leon wrote... ah what the heck - just read his post - I agree with 100% of what he wrote. Perfectly phrased. :)
Now... at the end Ramon writes:
The people actually doing the work should be the only people with any final say about what does or doesn't get done and what direction things should go. The only way to challenge the removal of old, bad, or dead code should be to volunteer to step up and maintain it.
This opens up an idea... I know that Steph got totally frustrated on squeak-dev when he eventually "gave up" and started Pharo. I even wrote to him privately the other day that the "trick" is to have a selective ear. But that is not easy.
The key problem is that it can be very hard to separate "doers" from "talkers" on squeak-dev. Lots of people post, lots of people have opinions - BUT... only a subset of the people with strong opinions actually contribute with code.
Ok, so sure, this may be elitist thinking and it may be a *really bad* idea - but since we are throwing ideas on the wall to see what sticks here goes:
Perhaps there should be a list for only people with "commit bit"? When decisions are to be made then that list is used so that developers can ask the others for opinions etc and only active committers have ability to post. The list should be public though.
Crazy? Perhaps. But an idea. Because my perception is that the subset of active committers very often tend to AGREE on the course of action.
regards, Göran
2009/6/29 Göran Krampe goran@krampe.se:
Hi!
Ramon Leon wrote... ah what the heck - just read his post - I agree with 100% of what he wrote. Perfectly phrased. :)
Now... at the end Ramon writes:
The people actually doing the work should be the only people
with any final say about what does or doesn't get done and what direction things should go. The only way to challenge the removal of old, bad, or dead code should be to volunteer to step up and maintain it.
This opens up an idea... I know that Steph got totally frustrated on squeak-dev when he eventually "gave up" and started Pharo. I even wrote to him privately the other day that the "trick" is to have a selective ear. But that is not easy.
The key problem is that it can be very hard to separate "doers" from "talkers" on squeak-dev. Lots of people post, lots of people have opinions - BUT... only a subset of the people with strong opinions actually contribute with code.
Ok, so sure, this may be elitist thinking and it may be a *really bad* idea
- but since we are throwing ideas on the wall to see what sticks here goes:
Perhaps there should be a list for only people with "commit bit"? When decisions are to be made then that list is used so that developers can ask the others for opinions etc and only active committers have ability to post. The list should be public though.
Crazy? Perhaps. But an idea. Because my perception is that the subset of active committers very often tend to AGREE on the course of action.
I agree that developers (or committers) should gain some sort of immunity from critics by anyone else, who is not committing. But making separate list will not help i think. We already have many of them.
And the last thing. Folklore says: the only people who doesn't making mistakes is one who doesn't doing anything. So, let the people try & fail, learn on mistakes and do better things. Lets move to ANY direction, just don't stay as an idols.
regards, Göran
On 6/29/09 6:44 PM, "Igor Stasenko" siguctua@gmail.com wrote:
Lets move to ANY direction, just don't stay as an idols.
+10
Edgar
2009/6/29 Igor Stasenko siguctua@gmail.com:
I agree that developers (or committers) should gain some sort of immunity from critics by anyone else, who is not committing. But making separate list will not help i think. We already have many of them.
Those who are not criticized are not working with anyone else. The moment the community cannot openly criticize Squeak is the moment Squeak becomes a dictatorship. Squeak is already living in a bubble and it's not necessary to create another one. The Squeak Oversight Board has to listen to those critics and decide what to do with them. Not every critics are meaningless... because what? The person who has submitted the critic did not contribute? I'll tell you what... to critic is to contribute. Those who choose to shut up don't do anything for Squeak.
Now, the community can rightfully expect the critic to go beyond "it's not good", "I don't like this or that" and so on. It's important to voice our opinions, ideas, etc. and, more importantly, the reasons behind them. If someone does not pour efforts into doing actual contribution, we can at least expect those to make an effort to express properly their idea. Talking is one step toward common understanding. Anyway, regardless of the critics, those who actively contribute to Squeak should have a meaningful voice.
Ian.
2009/6/30 Ian Trudel ian.trudel@gmail.com:
2009/6/29 Igor Stasenko siguctua@gmail.com:
I agree that developers (or committers) should gain some sort of immunity from critics by anyone else, who is not committing. But making separate list will not help i think. We already have many of them.
Those who are not criticized are not working with anyone else. The moment the community cannot openly criticize Squeak is the moment Squeak becomes a dictatorship. Squeak is already living in a bubble and it's not necessary to create another one. The Squeak Oversight Board has to listen to those critics and decide what to do with them. Not every critics are meaningless... because what? The person who has submitted the critic did not contribute? I'll tell you what... to critic is to contribute. Those who choose to shut up don't do anything for Squeak.
Now, the community can rightfully expect the critic to go beyond "it's not good", "I don't like this or that" and so on. It's important to voice our opinions, ideas, etc. and, more importantly, the reasons behind them. If someone does not pour efforts into doing actual contribution, we can at least expect those to make an effort to express properly their idea. Talking is one step toward common understanding. Anyway, regardless of the critics, those who actively contribute to Squeak should have a meaningful voice.
There are different sorts of critic: - i looked at your code and your code stinks. Rewrite it here and there. - i don't like your idea. Don't ever think implementing it.
got my point?
Ian.
2009/6/29 Igor Stasenko siguctua@gmail.com:
There are different sorts of critic:
- i looked at your code and your code stinks. Rewrite it here and there.
- i don't like your idea. Don't ever think implementing it.
got my point?
Absolutely.
Ian.
Ian Trudel wrote:
2009/6/29 Igor Stasenko siguctua@gmail.com:
There are different sorts of critic:
- i looked at your code and your code stinks. Rewrite it here and there.
- i don't like your idea. Don't ever think implementing it.
got my point?
Absolutely.
I don't. Can someone explain it to me? I've not seen any discussions on squeak-dev where people have said or even implied the latter. In reality, all of the vocal discussions center around whether to include certain changes in The Image (tm) or not. In the context of that discussion, comments like "I don't like your idea" are valid because part of the decision process needs to be to find out what the majority thinks about the validity of the change on the larger scale. That doesn't mean that a minority veto should necessarily prevent an idea from being integrated but you can't dismiss such comments merely on the grounds of not being constructive.
Cheers, - Andreas
Ok, so sure, this may be elitist thinking and it may be a *really bad* idea - but since we are throwing ideas on the wall to see what sticks here goes:
Perhaps there should be a list for only people with "commit bit"? When decisions are to be made then that list is used so that developers can ask the others for opinions etc and only active committers have ability to post. The list should be public though.
Crazy? Perhaps. But an idea. Because my perception is that the subset of active committers very often tend to AGREE on the course of action.
It's not so crazy -- Squeak can be a bit penalized in that there is no such thing as a "patch mailing list". From my experience, on a patch ML fast-talkers usually run out of arguments fast...
Paolo
On Mon, 2009-06-29 at 13:29 -0700, Ramon Leon wrote:
Stéphane Rollandin wrote:
Progress and backwards compatibility are fundamentally opposing forces, those insisting on backwards compatibility are the ones preventing progress.
Because they are opposing forces, we need to balance them. What you say could be completed with: those insisting in progress are the ones preventing actual software to be implemented.
Yes, and in Squeak, they are completely unbalanced, those wanting things to stay the same have won out over any major progress. The eToys thing is a perfect example, it should have been ripped out a long time ago, the eToy community already forked. The Squeak version is dead, and should have been removed but illogical resistance to change prevented it.
What is the point of progress if you can't harvest it ? Don't you see the drawbacks of a permanently moving target ?
Stef
If you can't break compatibility, there is no progress, there is only stagnation. The whole point of a version is to be able to break compatibility with previous versions, to make breaking changes, to correct mistakes of the past and make progress. Harvesting is the wrong approach, it only works for small changes. You don't harvest big rewrites, you upgrade to a new image and reload your code fix whatever your unit tests determine is now broken.
The idea of an ever evolving monolithic image that is continually patched into being current is just dead or dying. What works today is a small core image and loadable packages with unit tests so images can be rebuilt anytime, especially between versions. Unmaintained packages *should* die.
No one is forced to upgrade to the new version, if someone wants compatibility, they shouldn't upgrade. If they want the latest and greatest, then porting their code to newer versions and fixing what they broke is the price they pay, it must be that way necessarily. Otherwise there is no point in having new versions.
The drawbacks of a moving target are much less severe than the drawbacks of a stagnant and dying community which will be the end results of a attitude of not allowing breaking changes and progress. People keep forking Squeak because the Squeak community is utterly directionless and resistant to change because that's the nature of any organization led by a committee elected by diverse groups of people who don't share a common goal.
Pharo is what Squeak should have been, a place for people who actually do the work to build what they want and not be held back by those who don't and just have strong opinions and don't want things to ever change. The people actually doing the work should be the only people with any final say about what does or doesn't get done and what direction things should go. The only way to challenge the removal of old, bad, or dead code should be to volunteer to step up and maintain it.
I didn't want to participate at all in this thread but reading your post I feel the need to fully agree.
over and out,
Norbert
2009/6/29 Ramon Leon ramon.leon@allresnet.com:
Stéphane Rollandin wrote:
Progress and backwards compatibility are fundamentally opposing forces, those insisting on backwards compatibility are the ones preventing progress.
Because they are opposing forces, we need to balance them. What you say could be completed with: those insisting in progress are the ones preventing actual software to be implemented.
Yes, and in Squeak, they are completely unbalanced, those wanting things to stay the same have won out over any major progress. The eToys thing is a perfect example, it should have been ripped out a long time ago, the eToy community already forked. The Squeak version is dead, and should have been removed but illogical resistance to change prevented it.
What is the point of progress if you can't harvest it ? Don't you see the drawbacks of a permanently moving target ?
Stef
If you can't break compatibility, there is no progress, there is only stagnation. The whole point of a version is to be able to break compatibility with previous versions, to make breaking changes, to correct mistakes of the past and make progress. Harvesting is the wrong approach, it only works for small changes. You don't harvest big rewrites, you upgrade to a new image and reload your code fix whatever your unit tests determine is now broken.
The idea of an ever evolving monolithic image that is continually patched into being current is just dead or dying. What works today is a small core image and loadable packages with unit tests so images can be rebuilt anytime, especially between versions. Unmaintained packages *should* die.
No one is forced to upgrade to the new version, if someone wants compatibility, they shouldn't upgrade. If they want the latest and greatest, then porting their code to newer versions and fixing what they broke is the price they pay, it must be that way necessarily. Otherwise there is no point in having new versions.
The drawbacks of a moving target are much less severe than the drawbacks of a stagnant and dying community which will be the end results of a attitude of not allowing breaking changes and progress. People keep forking Squeak because the Squeak community is utterly directionless and resistant to change because that's the nature of any organization led by a committee elected by diverse groups of people who don't share a common goal.
Pharo is what Squeak should have been, a place for people who actually do the work to build what they want and not be held back by those who don't and just have strong opinions and don't want things to ever change. The people actually doing the work should be the only people with any final say about what does or doesn't get done and what direction things should go. The only way to challenge the removal of old, bad, or dead code should be to volunteer to step up and maintain it.
Well said! Thank you, Ramon for expressing a perfect and clear vision of current situation in a perfect english. I sharing the same. And can sign under every of your word. I hope some day i will learn how to express my thoughts in similar fashion. :)
-- Ramon Leon Chief Technical Officer Alliance Reservations Network IM Identities: gnaritas@aol, gnaritas2002@yahoo, ramon.leon@gmail Work: 602.889.5547 Fax: 602.224.9896
People keep forking Squeak because the Squeak community is utterly directionless and resistant to change because that's the nature of any organization led by a committee elected by diverse groups of people who don't share a common goal.
On this I fully agree with you.
See my other post about this same subject: my opinion is that these diverse groups should identify themselves and explicit their goals so that their influence do not play in the background, but in full light. Then we can find decision processes and make informed choices.
It's a sociological work we have to do. We must x-ray the community and know what it is made of exactly. Give it some structure.
Easier said than done of course.
Stef
2009/6/29 Stéphane Rollandin lecteur@zogotounga.net:
At this point I'm just puzzled. Why would people so deeply in love with the edit-compile-cycle they find it hard to live without it even consider Smalltalk (or Lisp, for that matter) in the first place ? I'm lost. Maybe you should start by selecting a bit more carefully the people you want to Squeak-e-vangelize (half-kidding here, no offense intended).
No offence taken. The problem is different. People don't like changes, people are scared of changes. And going from edit-compile-cycle to such a different approach, as in Squeak, it's a monstrously big drop.
Please, make no misunderstanding on my intention, it's not about entirely remodelling Squeak to fit another paradigm. My primary idea is to make the transition easier with some familiar elements and a better organization. The rest can be pretty much as we do... let's just not scare people off at first sight.
Or, at the contrary: let them experience a big shock that wipes out their preconceived ideas about programming. Trying to help them avoid that shock may actually make thing more difficult for them in the long term. They have to grok that Smalltalk *is* different.
30 years of big shock have proved not to work. Thank you for trying, come back in your next life. We cannot perpetuate recipes, which does not work.
2009/6/29 Ramon Leon ramon.leon@allresnet.com:
It is not superficial to look at Squeak and run away screaming as soon as you see it, in fact it's the exact reaction of the vast majority of developers who open up an image for the first time and it's quite a normal reaction. It looks and feels like an ugly toy rather than a serious development environment and it's Squeak's fault, not the developers.
Exactly my point. Squeak's fault. Our fault as a community. The sooner we understand it, the sooner we can improve the situation.
If it looks like a toy, then it shouldn't pretend to be otherwise. If it's going to claim itself a serious platform that real work can be done on, then it needs to look and behave that way. The Pharo guys understand this, but I don't think Squeak ever will.
Amen. The first sentence alone summarize well the idea.
Progress and backwards compatibility are fundamentally opposing forces, those insisting on backwards compatibility are the ones preventing progress. Those insisting on the monolithic image of unmaintained packages are preventing progress. The Pharo guys had the right idea, break from the community containing those people so those things can be dropped and some progress can actually made instead of the yearly endless "future of Squeak" posts that always seem lead to doing nothing.
The most pressing problem about backward compatibility resides in the fact that the community does not seem to understand with exactitude what the backward compatibility needs are. The years have passed and proposed change are tossed away because it might break compatibility. It becomes an easy excuse.
Paradoxically, many changes have been brought to Squeak over the years without much deep-thinking, resulting in a mess and making the compatibility issue even greater. Are we really supposed to forever support faulty code and defective designs?
The Squeak community wants backward compatibility, so it be. However, it has to be defined in a comprehensive and accurate manner, and no less. I don't want to be served meaningless excuses. Backward compatibility becomes meaningless when it is used broadly and at any moment on a system that never had a defined API, except, perhaps, Smalltalk-80 as a standard.
As Stéphane said, it's important to find the balance in opposing forces. We cannot entirely ditch the backward compatibility in favour of progress and, yet, we cannot entirely stick to backward compatibility because it will hinder progress.
My money's Goran's first scenario: Pharo continuing to steal developer mind share and Squeak slowly stagnating and dying off.
Don't be blasphemous. :)
Ramon Leon http://onsmalltalk.com
Best regards, Ian.
Or, at the contrary: let them experience a big shock that wipes out their preconceived ideas about programming. Trying to help them avoid that shock may actually make thing more difficult for them in the long term. They have to grok that Smalltalk *is* different.
30 years of big shock have proved not to work. Thank you for trying, come back in your next life.
Death is the ultimate big shock, indeed.
Stef
2009/6/29 Stéphane Rollandin lecteur@zogotounga.net:
30 years of big shock have proved not to work. Thank you for trying, come back in your next life.
Death is the ultimate big shock, indeed.
Hehe! Let's not kill Squeak before its time, all right? =)
Ian.
The most pressing problem about backward compatibility resides in the fact that the community does not seem to understand with exactitude what the backward compatibility needs are. The years have passed and proposed change are tossed away because it might break compatibility. It becomes an easy excuse.
No, I don't think that's true. Maybe I'm too much on the defensive side but I definitely remember several occurences of me having to raise concerns about proposed changes, just for the sake of protecting my own work. So I don't feel the community at large is over-valorizing backward compatibility and really tossing away all propositions.
Unfortunately it's not that simple; my feeling is that several more or less informal groups have different visions about Squeak and actually fight to impose them. Pharo is one such group having divorced from the community because it was tired to fight.
One path out of this confusion would be to have a debate about articulating those different visions, compare them and see what can be done about their differences. I did try, in my clumsy way, to start such a debate, years ago, but it did not work.
That was in 2004, almost 5 years ago:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/086611....
... and reading today what I wrote almost 5 years ago, I see that I don't need to change a word: it's still pretty much the same situation.
The Squeak community wants backward compatibility, so it be. However, it has to be defined in a comprehensive and accurate manner, and no less. I don't want to be served meaningless excuses. Backward compatibility becomes meaningless when it is used broadly and at any moment on a system that never had a defined API, except, perhaps, Smalltalk-80 as a standard.
agreed.
Stef
On Mon, Jun 29, 2009 at 10:11:00PM +0200, St?phane Rollandin wrote:
That was in 2004, almost 5 years ago:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/086611....
... and reading today what I wrote almost 5 years ago, I see that I don't need to change a word: it's still pretty much the same situation.
Yep, your voice from 2004 is still good to read in 2009.
Dave
On Mon, Jun 29, 2009 at 03:39:49PM -0400, Ian Trudel wrote:
2009/6/29 St?phane Rollandin lecteur@zogotounga.net:
Or, at the contrary: let them experience a big shock that wipes out their preconceived ideas about programming. Trying to help them avoid that shock may actually make thing more difficult for them in the long term. They have to grok that Smalltalk *is* different.
30 years of big shock have proved not to work.
Um, maybe I'm just missing something, but which part didn't work? ;-)
Thank you for trying, come back in your next life.
I have an uncomfortable feeling that when I come back in my next life, I will be confronted with java++ enterprise edition 7.3 with cloud seeding enablement and business object bus drivers. So perhaps I am not so unhappy about the state of Squeak and Pharo after all.
Dave
Or, at the contrary: let them experience a big shock that wipes out their preconceived ideas about programming. Trying to help them avoid that shock may actually make thing more difficult for them in the long term. They have to grok that Smalltalk *is* different.
30 years of big shock have proved not to work.
Um, maybe I'm just missing something, but which part didn't work? ;-) Dave
How about the part where Smalltalk gets enough mainstream acceptance that it's used as much as Python or Ruby and thousands of developers are writing libraries for it instead of a small handful? How about enough that when you tell someone you're using Smalltalk that they've actually have heard of it and know what you're talking about? Let's not act like there isn't room for improvement and that we wouldn't benefit from a larger community of fresh blood to take the place of the old gray bearded Smalltalker's before they all die.
Ramon Leon http://onsmalltalk.com
On 30.06.2009, at 04:23, Ramon Leon wrote:
Or, at the contrary: let them experience a big shock that wipes out their preconceived ideas about programming. Trying to help them avoid that shock may actually make thing more difficult for them in the long term. They have to grok that Smalltalk *is* different.
30 years of big shock have proved not to work.
Um, maybe I'm just missing something, but which part didn't work? ;-) Dave
How about the part where Smalltalk gets enough mainstream acceptance that it's used as much as Python or Ruby and thousands of developers are writing libraries for it instead of a small handful? How about enough that when you tell someone you're using Smalltalk that they've actually have heard of it and know what you're talking about? Let's not act like there isn't room for improvement and that we wouldn't benefit from a larger community of fresh blood to take the place of the old gray bearded Smalltalker's before they all die.
How about getting them young, when the kids are not yet brain-washed into how a "proper" edit-compile-run-crash development environment looks like? Say, by making a cool shiny toy environment that lets them start to play, and once they reach its limits, show them how to open the hood and program actual Smalltalk? That toy environment could initially be developed by a handful of engineers, but it would need a whole community to keep it up-to-date and make it truly useful for "grownup" tasks too. Now there's an idea ...
- Bert -
+1
Bert Freudenberg wrote:
On 30.06.2009, at 04:23, Ramon Leon wrote:
How about the part where Smalltalk gets enough mainstream acceptance that it's used as much as Python or Ruby and thousands of developers are writing libraries for it instead of a small handful? How about enough that when you tell someone you're using Smalltalk that they've actually have heard of it and know what you're talking about? Let's not act like there isn't room for improvement and that we wouldn't benefit from a larger community of fresh blood to take the place of the old gray bearded Smalltalker's before they all die.
How about getting them young, when the kids are not yet brain-washed into how a "proper" edit-compile-run-crash development environment looks like? Say, by making a cool shiny toy environment that lets them start to play, and once they reach its limits, show them how to open the hood and program actual Smalltalk? That toy environment could initially be developed by a handful of engineers, but it would need a whole community to keep it up-to-date and make it truly useful for "grownup" tasks too. Now there's an idea ...
- Bert -
2009/6/30 Bert Freudenberg bert@freudenbergs.de:
How about getting them young, when the kids are not yet brain-washed into how a "proper" edit-compile-run-crash development environment looks like? Say, by making a cool shiny toy environment that lets them start to play, and once they reach its limits, show them how to open the hood and program actual Smalltalk? That toy environment could initially be developed by a handful of engineers, but it would need a whole community to keep it up-to-date and make it truly useful for "grownup" tasks too. Now there's an idea ...
- Bert -
o_O.
Bert, are you serious?
Enough with the children! It's been done and redone and overdone. The past and the future confounded. Why can't we live the present living? You're talking about something that might (or might not) produce engineers in the next, say, 20 years? Smalltalk will be around 50 years by then. I find it painful that our community wouldn't be a little bit more practical, for a change..
Right here, right now.
Ian.
PS: I am so sorry... I don't even have spare children to furiously train on Squeak...
Bert, are you serious?
Enough with the children! It's been done and redone and overdone. The past and the future confounded. Why can't we live the present living? You're talking about something that might (or might not) produce engineers in the next, say, 20 years? Smalltalk will be around 50 years by then. I find it painful that our community wouldn't be a little bit more practical, for a change..
Right here, right now.
Ian.
PS: I am so sorry... I don't even have spare children to furiously train on Squeak...
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults. I want Smalltalk to be usable now, not at some unspecified time in some imaginary future where it takes over the world by getting kids before they've been introduced to other environments. It's pure fantasy to think this'll happen, it won't. This is the attitude that holds Squeak back and prevents anyone from taking it too seriously. This is why Pharo will continue to steal mind-share and Squeak will die.
Ramon Leon http://onsmalltalk.com
2009/7/1 Ramon Leon ramon.leon@allresnet.com:
Bert, are you serious?
Enough with the children! It's been done and redone and overdone. The past and the future confounded. Why can't we live the present living? You're talking about something that might (or might not) produce engineers in the next, say, 20 years? Smalltalk will be around 50 years by then. I find it painful that our community wouldn't be a little bit more practical, for a change..
Right here, right now.
Ian.
PS: I am so sorry... I don't even have spare children to furiously train on Squeak...
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults. I want Smalltalk to be usable now, not at some unspecified time in some imaginary future where it takes over the world by getting kids before they've been introduced to other environments. It's pure fantasy to think this'll happen, it won't. This is the attitude that holds Squeak back and prevents anyone from taking it too seriously. This is why Pharo will continue to steal mind-share and Squeak will die.
+10. Let us separate the domains: 1. Squeak for developers who need a modern & sound smalltalk environment which fullfills their needs and 2. Squeak for teachers/children/endusers who will use a wonderfull environment produced by software engineers.
If you don't have 1st, you can't progress in 2nd, because obviously developers do not like sitting in child room and pretend that they are sitting in the lab.
Ramon Leon http://onsmalltalk.com
Hi,
On Wed, Jul 1, 2009 at 6:19 AM, Ramon Leonramon.leon@allresnet.com wrote:
+10
Minus aleph null. I win. ;-)
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful.
Asking in turn, who cares about your retirement date? ;-)
Besides: isn't it a bit strange (for want of a better word) to think about children in terms of their "useful"ness?
Seriously: I think Igor has a point. Without a solid foundation on which to build such educational software, the latter will hardly be sensibly possible. So, focusing on developing a solid Squeak is of utmost importance, not only to those who are interested in building educational software, but also for those whose interests are more geared towards business applications.
That does not preclude, however, pursuit of such goals. They may not be your goals, and that's entirely fine. But please don't dismiss them as irrelevant. They aren't.
Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults.
As far as programming languages in my understanding of common sense (with textual representation) are concerned, you're right. There are others. Quite a lot of children are using that LabView-based Lego Mindstorms NXT programming environment, and you cannot say they're not learning anything about programming there.
Squeak's approach, in the form of Etoys, takes another angle, but it is nonetheless valid. It's an enabler. One that avoids syntax, favouring directly manipulable objects. It's closer to the target audience's world perception. Now is that bad? Or even irrelevant? I don't think so.
That said, I agree that Squeak as a language has a different target audience. But, and repeating myself, that does not preclude supporting other kinds of programming based on that language. Squeak is also a platform.
I want Smalltalk to be usable now, not at some unspecified time in some imaginary future where it takes over the world by getting kids before they've been introduced to other environments. It's pure fantasy to think this'll happen, it won't.
Do you think it'll take over the world in some other way? Wow. :-)
This is the attitude that holds Squeak back and prevents anyone from taking it too seriously. This is why Pharo will continue to steal mind-share and Squeak will die.
Beg to differ... I believe that too many people exhibiting overly negative attitudes to things they actually don't care about are rather more problematic. No good vibes. ;-)
And no offence intended.
Best,
Michael
P.S.: Two projects based on Squeak that truly target children of all ages (including myself) will go live today. Stay tuned. :-)
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults.
Man, do you realize what you wrote here is incredibly out of place ? This is Squeak-dev here, Squeak has been involved with education and children since its beginnings, we have EToys, Scratch, OLPC. My own children use it. If you want a cultural revolution, ok, but first gather your troops, and let us count them.
There's definitely a need to have everybody explicit their view of what it Squeak, me repeat again... surprises could be ahead.
Stef
I some ways I agree with Ramon, that Squeak should become more aimed at developers.
I do however feel that education is very important I was especially impressed by Dr. Geo II. I feel that EToys, Dr. Geo etc should become applications that can be loaded in very much like Seaside can be loaded into a variety of smalltalks.
I will probably not be too popular for saying the following, but I fail to see how EToys helps to teach children the use of smalltalk, (and hence why I am confused that so many feel that it should be part of Squeak) if it is there to help teach programming concepts to children then I would also have to say that Scratch seems to be a much better tool for doing this.
2009/7/1 Stéphane Rollandin lecteur@zogotounga.net:
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults.
Man, do you realize what you wrote here is incredibly out of place ? This is Squeak-dev here, Squeak has been involved with education and children since its beginnings, we have EToys, Scratch, OLPC. My own children use it. If you want a cultural revolution, ok, but first gather your troops, and let us count them.
There's definitely a need to have everybody explicit their view of what it Squeak, me repeat again... surprises could be ahead.
Stef
I will probably not be too popular for saying the following, but I fail to see how EToys helps to teach children the use of smalltalk, (and hence why I am confused that so many feel that it should be part of Squeak) if it is there to help teach programming concepts to children then I would also have to say that Scratch seems to be a much better tool for doing this.
Actually my children use Scratch.
Stef
On 01.07.2009, at 11:40, Ryan Simmons wrote:
I some ways I agree with Ramon, that Squeak should become more aimed at developers.
I do however feel that education is very important I was especially impressed by Dr. Geo II. I feel that EToys, Dr. Geo etc should become applications that can be loaded in very much like Seaside can be loaded into a variety of smalltalks.
Yes, that is a nice goal. This just takes considerably more effort than simply ripping it out, in particular since much of Squeak was designed to support Etoys without drawing a strict boundary. But help is welcome in disentangling.
I will probably not be too popular for saying the following, but I fail to see how EToys helps to teach children the use of smalltalk, (and hence why I am confused that so many feel that it should be part of Squeak) if it is there to help teach programming concepts to children then I would also have to say that Scratch seems to be a much better tool for doing this.
You are right - Scratch indeed prepares you better for using a "real language" later with its complete coverage of control structures. The scripts you build in Scratch can very easily be matched to some other syntax (in fact, there exists a "Python" localization that makes the Scratch tiles look like Python code), and reversely are immediately familiar to someone knowing a programming language already.
Etoys is primarily about modeling behavior rather than learning to program. Its target age group is elementary school children, whereas Scratch targets teenagers. Etoys is used to make animations, tell stories, create simulations, little games, do presentations etc. It's not for the computer science class.
But the major difference is that Etoys lets you escape to Smalltalk once you reach its limits. Scratch is intentionally a closed world, Etoys is intentionally open. You can at any time switch an Etoys script to its textual representation and edit the Smalltalk code, accessing any Squeak feature you want. Or you can create your own classes and incorporate them in an Etoys project. This gives you an environment so powerful it's second to none.
- Bert -
Bert Freudenberg wrote:
On 01.07.2009, at 11:40, Ryan Simmons wrote:
... I feel that EToys, Dr. Geo etc should become applications that can be loaded in very much like Seaside can be loaded into a variety of smalltalks.
Yes, that is a nice goal. This just takes considerably more effort than simply ripping it out, in particular since much of Squeak was designed to support Etoys without drawing a strict boundary. But help is welcome in disentangling. ...
If we ever build enough momentum, may I suggest using Cuis as the first target of such efforts? If that happened Cuis could become the basis for this new Squeak.
Cheers, Juan Vuletich
Juan Vuletich wrote:
If we ever build enough momentum, may I suggest using Cuis as the first target of such efforts? If that happened Cuis could become the basis for this new Squeak.
Hey, what is the homepage of Cuis? Do you have one? :) I downloaded it yesterday but was looking for more "words" about it. But I should fire it up of course and take a look.
regards, Göran
Göran Krampe wrote:
Juan Vuletich wrote:
If we ever build enough momentum, may I suggest using Cuis as the first target of such efforts? If that happened Cuis could become the basis for this new Squeak.
Hey, what is the homepage of Cuis? Do you have one? :) I downloaded it yesterday but was looking for more "words" about it. But I should fire it up of course and take a look.
regards, Göran
I barely started writing it one night 2 weeks ago when I dumped a big cup of hot coffee on my laptop. It died instantly. I removed the battery, the disk, put it in the kitchen sink (the real one!) and poured perhaps 20 liters of water over it to remove the coffee from inside. Then I completely disassembled it and dried each part. I put it together and incredibly it survived!
But that night I was too tired to go back to work... And later I forgot about it.
I apologize for the rant... Here it is now: http://www.jvuletich.org/Cuis/Index.html . It is just a start! Anyway, please download it from http://www.jvuletich.org/Cuis/Cuis1.0-0204.zip . The three open workspaces are much better than my words to give you a glimpse of what is it about.
I didn't say this in the web, but Cuis is the ongoing result of 5 years of cleaning and refactoring. It is used by several people daily, in 2 commercial projects. We have a product based on it that has been shipped to customers for about a year now.
Cheers, Juan Vuletich
Ryan Simmons wrote:
I some ways I agree with Ramon, that Squeak should become more aimed at developers.
I do however feel that education is very important I was especially impressed by Dr. Geo II. I feel that EToys, Dr. Geo etc should become applications that can be loaded in very much like Seaside can be loaded into a variety of smalltalks.
I will probably not be too popular for saying the following, but I fail to see how EToys helps to teach children the use of smalltalk, (and hence why I am confused that so many feel that it should be part of Squeak) if it is there to help teach programming concepts to children then I would also have to say that Scratch seems to be a much better tool for doing this.
When I'm building Etoys scripts with teachers and I show them the option in a scriptor "show code textually" they are surprised and interested. Because for kids/students, who are eager to learn more that's a way to show them what is "under the hood". You can even go all the way to the class browser and look for your etoys objects and scripts. That's not really easy at the moment, but I think that is something worth to work on! We have BotsInc, too, as a learning tool of how to use the squeak environment. What we need are ideas about how to better integrate these parts. And of course we need documentation, so that all the wonderful features of Squeak are accessible.
Rita
2009/7/1 Stéphane Rollandin lecteur@zogotounga.net:
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults.
Man, do you realize what you wrote here is incredibly out of place ? This is Squeak-dev here, Squeak has been involved with education and children since its beginnings, we have EToys, Scratch, OLPC. My own children use it. If you want a cultural revolution, ok, but first gather your troops, and let us count them.
There's definitely a need to have everybody explicit their view of what it Squeak, me repeat again... surprises could be ahead.
Stef
Rita, that is very interesting as I was wondering about whether the "show code textually" was actually used by kids/students. I do wish that EToys was in some ways more accessible as I always feel that I am about to break everything, I have lost count of the number of times I have quit squeak without saving to be able to recover the original version of a project I was working on, and I am sure that there is an easier way of doing this but I could not find it.
It would be great if there was more documentation out there and there where more resources for teaching smalltalk, I found it sad when I heard on FLOSS Weakly 66 that programs where being written for the OLPC in HTML / Javascript because smalltalk was seen as being difficult.
2009/7/1 Rita Freudenberg rita@isg.cs.uni-magdeburg.de:
Ryan Simmons wrote:
I some ways I agree with Ramon, that Squeak should become more aimed at developers.
I do however feel that education is very important I was especially impressed by Dr. Geo II. I feel that EToys, Dr. Geo etc should become applications that can be loaded in very much like Seaside can be loaded into a variety of smalltalks.
I will probably not be too popular for saying the following, but I fail to see how EToys helps to teach children the use of smalltalk, (and hence why I am confused that so many feel that it should be part of Squeak) if it is there to help teach programming concepts to children then I would also have to say that Scratch seems to be a much better tool for doing this.
When I'm building Etoys scripts with teachers and I show them the option in a scriptor "show code textually" they are surprised and interested. Because for kids/students, who are eager to learn more that's a way to show them what is "under the hood". You can even go all the way to the class browser and look for your etoys objects and scripts. That's not really easy at the moment, but I think that is something worth to work on! We have BotsInc, too, as a learning tool of how to use the squeak environment. What we need are ideas about how to better integrate these parts. And of course we need documentation, so that all the wonderful features of Squeak are accessible.
Rita
2009/7/1 Stéphane Rollandin lecteur@zogotounga.net:
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults.
Man, do you realize what you wrote here is incredibly out of place ? This is Squeak-dev here, Squeak has been involved with education and children since its beginnings, we have EToys, Scratch, OLPC. My own children use it. If you want a cultural revolution, ok, but first gather your troops, and let us count them.
There's definitely a need to have everybody explicit their view of what it Squeak, me repeat again... surprises could be ahead.
Stef
-- Rita Freudenberg FIN-ISG Otto-von-Guericke-Universität Magdeburg http://isgwww.cs.uni-magdeburg.de/isg/rita.html
At Wed, 1 Jul 2009 12:59:33 +0200, Ryan Simmons wrote:
Rita, that is very interesting as I was wondering about whether the "show code textually" was actually used by kids/students.
With proper mentors who knows it around, they sure do.
Just a sidenote, if you google:
http://www.google.com/search?q=%E3%82%B9%E3%82%AF%E3%82%A4%E3%83%BC%E3%82%AF...
(meaning "squeak script" in Japanese)
you get something close to million hits. (rather 350,000 for English). Many pages are about the tile scripting, but quite a few explains how to go from there to Smalltalk.
-- Yoshiki
+1 too.
Credit: Squeak suffers from being hardly coupled with something that is intentionally good hearted, theoretically well supported and it genuinely deserves credit for that. But time told it was a poor design. It won't help to deny reality. In practice it didn't work well. Is not that it was completely useless. It solves a problem but is not the expected breakthrough. And there are reasons for that. Make space in your mind to stop ignoring those.
Price: The price the project (paid by its comunity) for soving that problem became unacceptably high and that's why the current crisis happened.
UI without sense: Squeak make countless undeniable and unjustifiable violations to UI design and usability principles. I mean BASIC ones. Please stop rationalizing on theoretic stuff that didn't work. Prioritize what did work (inside and outside ST universe). Hint: there is iphone and the rest of the world. Honour design principles or stop self lying about who can use your stuff. Decide if you want to make software for human beings or damn engeneers/geeks.
Oprtunity: Do less to do more. I see Squeak has proved to be extremely fertile. If Squeak gets unbloated of features it can focus in doing less much much better and profit from what is good at: fertile to fast implementing models. But today nobody want just models. Those are easy. What people wants is convenience. Convenient interfaces with sense. So the oportunity for squeak would be to do that in interfaces that totally rock. Is not the art of the buttons or window borders. Is not adding features. Actually removing some will make it better. But is a lot more than that. Smalltalkers are known by its design capabilities? other comunities do. Hear how they think. Learn. Reinvent.
Sustainability: If a project do not have one clear mission, it will consume any momentum fast while being unable to make rapport with any tribe to renew efforts. It could had value to prove some theory, but in the end (today) who cares? for other pruposes it will be invisible: #fail. Stop making artifacts that makes you beg for tolerance about UI (AKA manuals/education?) crying with colleagues becaouse people "don't get it". Is not their fault! Instead do something that is worth to put money into it. Something inspiring. Something worthy to talk about (with smalltalk outsiders).
Sorry if this sounds hard but honest feedback is more valuable than water with sugar.
sebastian
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Ramon Leon Enviado el: Wednesday, July 01, 2009 01:19 Para: The general-purpose Squeak developers list Asunto: Re: Usability and look-and-feel (was Re: [squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
Bert, are you serious?
Enough with the children! It's been done and redone and
overdone. The
past and the future confounded. Why can't we live the
present living?
You're talking about something that might (or might not) produce engineers in the next, say, 20 years? Smalltalk will be around 50 years by then. I find it painful that our community wouldn't be a little bit more practical, for a change..
Right here, right now.
Ian.
PS: I am so sorry... I don't even have spare children to furiously train on Squeak...
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults. I want Smalltalk to be usable now, not at some unspecified time in some imaginary future where it takes over the world by getting kids before they've been introduced to other environments. It's pure fantasy to think this'll happen, it won't. This is the attitude that holds Squeak back and prevents anyone from taking it too seriously. This is why Pharo will continue to steal mind-share and Squeak will die.
Ramon Leon http://onsmalltalk.com
I have no idea where the myth comes from that the look of Squeak's Smalltalk development tools has anything whatsoever to do with Etoys, but anyhow it would be a good idea to stop spreading it.
"Usability and look-and-feel" is what this thread is about so constructive ideas (or even better code and designs) are welcome, but blaming it on Etoys is just cheap.
- Bert -
On 02.07.2009, at 19:09, Sebastian Sastre wrote:
+1 too.
Credit: Squeak suffers from being hardly coupled with something that is intentionally good hearted, theoretically well supported and it genuinely deserves credit for that. But time told it was a poor design. It won't help to deny reality. In practice it didn't work well. Is not that it was completely useless. It solves a problem but is not the expected breakthrough. And there are reasons for that. Make space in your mind to stop ignoring those.
Price: The price the project (paid by its comunity) for soving that problem became unacceptably high and that's why the current crisis happened.
UI without sense: Squeak make countless undeniable and unjustifiable violations to UI design and usability principles. I mean BASIC ones. Please stop rationalizing on theoretic stuff that didn't work. Prioritize what did work (inside and outside ST universe). Hint: there is iphone and the rest of the world. Honour design principles or stop self lying about who can use your stuff. Decide if you want to make software for human beings or damn engeneers/geeks.
Oprtunity: Do less to do more. I see Squeak has proved to be extremely fertile. If Squeak gets unbloated of features it can focus in doing less much much better and profit from what is good at: fertile to fast implementing models. But today nobody want just models. Those are easy. What people wants is convenience. Convenient interfaces with sense. So the oportunity for squeak would be to do that in interfaces that totally rock. Is not the art of the buttons or window borders. Is not adding features. Actually removing some will make it better. But is a lot more than that. Smalltalkers are known by its design capabilities? other comunities do. Hear how they think. Learn. Reinvent.
Sustainability: If a project do not have one clear mission, it will consume any momentum fast while being unable to make rapport with any tribe to renew efforts. It could had value to prove some theory, but in the end (today) who cares? for other pruposes it will be invisible: #fail. Stop making artifacts that makes you beg for tolerance about UI (AKA manuals/education?) crying with colleagues becaouse people "don't get it". Is not their fault! Instead do something that is worth to put money into it. Something inspiring. Something worthy to talk about (with smalltalk outsiders).
Sorry if this sounds hard but honest feedback is more valuable than water with sugar.
sebastian
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Ramon Leon Enviado el: Wednesday, July 01, 2009 01:19 Para: The general-purpose Squeak developers list Asunto: Re: Usability and look-and-feel (was Re: [squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
Bert, are you serious?
Enough with the children! It's been done and redone and
overdone. The
past and the future confounded. Why can't we live the
present living?
You're talking about something that might (or might not) produce engineers in the next, say, 20 years? Smalltalk will be around 50 years by then. I find it painful that our community wouldn't be a little bit more practical, for a change..
Right here, right now.
Ian.
PS: I am so sorry... I don't even have spare children to furiously train on Squeak...
+10
Seriously, stop talking about kids, who cares, I'll be retired by the time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults. I want Smalltalk to be usable now, not at some unspecified time in some imaginary future where it takes over the world by getting kids before they've been introduced to other environments. It's pure fantasy to think this'll happen, it won't. This is the attitude that holds Squeak back and prevents anyone from taking it too seriously. This is why Pharo will continue to steal mind-share and Squeak will die.
Ramon Leon http://onsmalltalk.com
Dear Bert, you can note that I wasn't talking about EToys. I was being completely general about Squeak. Let me clarify that I said that because to destruct wrong ideas makes room for new good ones. Think of imploding a an old building to make a 2.0 one. Criticism has to be qualified and useful. Not just "constructive". Destruct crappy stuff that takes focus and momentum out of your goal. If I talk to you about any "sugar with water" kind of criticism I'll not have any chance of helping you to make any difference. sebastian
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Bert Freudenberg Enviado el: Thursday, July 02, 2009 14:23 Para: The general-purpose Squeak developers list Asunto: Re: Usability and look-and-feel (was Re: [squeak-dev] The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
I have no idea where the myth comes from that the look of Squeak's Smalltalk development tools has anything whatsoever to do with Etoys, but anyhow it would be a good idea to stop spreading it.
"Usability and look-and-feel" is what this thread is about so constructive ideas (or even better code and designs) are welcome, but blaming it on Etoys is just cheap.
- Bert -
On 02.07.2009, at 19:09, Sebastian Sastre wrote:
+1 too.
Credit: Squeak suffers from being hardly coupled with something that is intentionally good hearted, theoretically well supported and it genuinely
deserves
credit for that. But time told it was a poor design. It won't help to deny reality. In practice it didn't work well. Is not that it was completely
useless.
It solves a problem but is not the expected breakthrough. And there are
reasons
for that. Make space in your mind to stop ignoring those.
Price: The price the project (paid by its comunity) for soving
that problem
became unacceptably high and that's why the current crisis happened.
UI without sense: Squeak make countless undeniable and unjustifiable
violations to UI
design and usability principles. I mean BASIC ones. Please stop rationalizing on theoretic stuff that didn't work. Prioritize what did work (inside
and outside
ST universe). Hint: there is iphone and the rest of the world. Honour design principles or stop self lying about who can use your stuff. Decide if you want to make software for human beings or damn engeneers/geeks.
Oprtunity: Do less to do more. I see Squeak has proved to be extremely
fertile.
If Squeak gets unbloated of features it can focus in doing less much much better and profit from what is good at: fertile to fast implementing models. But today nobody want just models. Those are easy. What
people wants
is convenience. Convenient interfaces with sense. So the
oportunity for
squeak would be to do that in interfaces that totally rock. Is not
the art
of the buttons or window borders. Is not adding features. Actually
removing
some will make it better. But is a lot more than that. Smalltalkers
are known
by its design capabilities? other comunities do. Hear how they think. Learn. Reinvent.
Sustainability: If a project do not have one clear mission, it will consume any momentum fast while being unable to make rapport with any tribe to renew
efforts.
It could had value to prove some theory, but in the end (today) who cares? for other pruposes it will be invisible: #fail. Stop making artifacts that makes you beg for tolerance about UI (AKA manuals/education?) crying with colleagues becaouse people "don't get it". Is not their fault! Instead do something that is worth to put money into it. Something inspiring. Something worthy to talk about (with
smalltalk
outsiders).
Sorry if this sounds hard but honest feedback is more
valuable than
water with sugar.
sebastian
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Ramon Leon Enviado el: Wednesday, July 01, 2009 01:19 Para: The general-purpose Squeak developers list Asunto: Re: Usability and look-and-feel (was Re: [squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
Bert, are you serious?
Enough with the children! It's been done and redone and
overdone. The
past and the future confounded. Why can't we live the
present living?
You're talking about something that might (or might not) produce engineers in the next, say, 20 years? Smalltalk will be around 50 years by then. I find it painful that our community wouldn't be a little bit more practical, for a change..
Right here, right now.
Ian.
PS: I am so sorry... I don't even have spare children to furiously train on Squeak...
+10
Seriously, stop talking about kids, who cares, I'll be
retired by the
time they're useful. Programming languages are tools that are primarily used by and useful for adults, they should be aimed at adults. I want Smalltalk to be usable now, not at some unspecified time in some imaginary future where it takes over the world by getting kids before they've been introduced to other environments.
It's pure
fantasy to think this'll happen, it won't. This is the
attitude that
holds Squeak back and prevents anyone from taking it too seriously. This is why Pharo will continue to steal mind-share and Squeak will die.
Ramon Leon http://onsmalltalk.com
Hello people,
There was a message for which I wanted to reply to but got lost somewhere. Let's write something out of the blue in regard to Usability and Look-and-Feel.
Polymorph has been mentioned but this is not a solution to the look-and-feel, this is just a skinning framework on top of an UI. Pharo has it by default and they have simulated existing UIs. Fine, it looks all right. But it seems to me over doing the thing and especially not to offer something genuine nor native UI. What's the point? (It's rhetorical question, friends)
One has pointed the basics of the look-and-feel are not right. And I absolutely agree with that. There is a lack of coherence in general. My primary idea about a look-and-feel for Squeak is really a plain but reviewed UI, a little bit more formal maybe. There are simple UIs, which are still appealing or even colourful, like BeOS GUI, Scratch, or some trendy Adobe AIR applications / Apple Aperture (black on black is not for everybody's taste though).
It really doesn't need to be polymorph nor like any existing OS. There is probably an overhead using Polymorph anyway, right? As long as it's not ugly, newcomers will try Squeak. They will try it especially if it's not ugly. As long as it's coherent, balanced in its colour scheme, it's easy to spend hours after hours with Squeak for the others.
Usability is also a big concern and would use of some simplification, reorganization, and so on. I'm trying to get first hand experience with a newcomer in regard to this, hopefully I'll be able to get some data to share.
The overall attitude of some in the community is pretty much "don't like it? change it.", "don't like Squeak? Fork it." Etc. Considering that someone has pointed out some of us uses Squeak for more than 10 years, it's not just about usability and look-and-feel anymore, but the big question is:
have we got too comfy with Squeak and accepted its general state?
That's a question everybody should think about and share their thoughts on the list. =)
Regards, Ian
On Wednesday 08 Jul 2009 12:03:37 pm Ian Trudel wrote:
The overall attitude of some in the community is pretty much "don't like it? change it.", "don't like Squeak? Fork it." Etc.
Squeak is about personal productivity. I find it offers the path of least resistance for personal programming projects. For some UI may be important, but for others, it is just a means to an end. I don't know if this can be called an attitude because Squeak's UI has absorbed many ideas over the years without losing its ability to 'get a job done'. The pace of contributions has slowed for sure, but such dips are a natural part of tech adoption curve.
Considering that someone has pointed out some of us uses Squeak for more than 10 years, it's not just about usability and look-and-feel anymore, but the big question is:
have we got too comfy with Squeak and accepted its general state?
You must be kidding :-). The diversity and volume of opinions in this list can hardly constitute 'acceptance' ;-).
Subbu
2009/7/8 K. K. Subramaniam subbukk@gmail.com:
have we got too comfy with Squeak and accepted its general state?
You must be kidding :-). The diversity and volume of opinions in this list can hardly constitute 'acceptance' ;-).
He he he. But that's not what I meant. I think some of us got used to what Squeak is and then oversee the fact that it's not so approachable, especially to newcomers.
The organization in general is still messy... using my previous example with the organization in the menus, I am still searching things in them after 8 years using Squeak. Where was that again? Or this? Or That? Practice makes perfect but, hey, there should be a statutory limit. :P
Some people just sound like Squeak does not need a good spruce up. =)
Ian.
On 2009.07.08 09:19, Ian Trudel wrote:
2009/7/8 K. K. Subramaniam subbukk@gmail.com:
have we got too comfy with Squeak and accepted its general state?You must be kidding :-). The diversity and volume of opinions in this list can hardly constitute 'acceptance' ;-).
He he he. But that's not what I meant. I think some of us got used to what Squeak is and then oversee the fact that it's not so approachable, especially to newcomers.
The organization in general is still messy... using my previous example with the organization in the menus, I am still searching things in them after 8 years using Squeak. Where was that again? Or this? Or That? Practice makes perfect but, hey, there should be a statutory limit. :P
Some people just sound like Squeak does not need a good spruce up. =)
Ian.
+10 (I'm on my second day trying to create a simple morph that fits around a few ellipses... The side effects of simple morphic operations is staggering. "Do the right thing" -- Bah . I prefer "No surprises") --Trygve
I have worked with couple of man, who were using only unix console (shell) for everything they need. And switching to graphics mode, only when they need to use a browser to visit sites :)
Needless to say, that they were highly productive and feel pretty content with an obscurity & unavailability of colorful buttons/menus etc etc. But not all of us is such professionals, and there is a huge gap between UI for decent user and UI for IT professional doing its job.
In same way, i heard from multiple people here, when i asked: why you never try/use Pharo , the answer was: - i can't use OB, it is alien to me. What is interesting, that as to me, the default Squeak browser and OB are pretty much the same. So there is another side of this: an inertia of people who mastered something & using it , and don't see any reasons why things need to be changed in any way.
But all of above stays between us - professionals & developers. What we (Squeak) proposing to decent users in this regard? I am sorry to say , but to my thinking - nearly nothing.
Igor Stasenko wrote:
In same way, i heard from multiple people here, when i asked: why you never try/use Pharo , the answer was:
- i can't use OB, it is alien to me.
What is interesting, that as to me, the default Squeak browser and OB are pretty much the same. So there is another side of this: an inertia of people who mastered something & using it , and don't see any reasons why things need to be changed in any way.
I think this particular question may have a different answer. I tried OB on Pharo when I was looking into some FFI troubles. The main noticable difference was *incredible* sluggishness. Every single action was greeted with a 2-5 seconds pause. I kid you not. Granted, my computer isn't exactly the fastest, but those were all actions where with the regular Squeak browser I feel no noticable delay whatsoever.
The other thing I noticed was that OB did not come across as very robust. Several trivial actions (like opening a context menu in the code pane) would just blow up.
If I'd have to guess, then the sluggishness of OB is a major hindrance in its acceptance. As you say, since the browsers are so similar there is really little reason to choose the slow one ;-)
Cheers, - Andreas
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
In same way, i heard from multiple people here, when i asked: why you never try/use Pharo , the answer was: - i can't use OB, it is alien to me. What is interesting, that as to me, the default Squeak browser and OB are pretty much the same. So there is another side of this: an inertia of people who mastered something & using it , and don't see any reasons why things need to be changed in any way.
I think this particular question may have a different answer. I tried OB on Pharo when I was looking into some FFI troubles. The main noticable difference was *incredible* sluggishness. Every single action was greeted with a 2-5 seconds pause. I kid you not. Granted, my computer isn't exactly the fastest, but those were all actions where with the regular Squeak browser I feel no noticable delay whatsoever.
The other thing I noticed was that OB did not come across as very robust. Several trivial actions (like opening a context menu in the code pane) would just blow up.
If I'd have to guess, then the sluggishness of OB is a major hindrance in its acceptance. As you say, since the browsers are so similar there is really little reason to choose the slow one ;-)
Well, i hope that will be fixed eventually by developers.
From other side, i like a new stuff , added to OB , like icons, tests
integration (so you can run test methods by just clicking on method in method pane) and many others. So, you have to pay the price (extra cycles) for extra features. Of couse, the price should be kept reasonable :)
Cheers, - Andreas
Igor Stasenko wrote:
If I'd have to guess, then the sluggishness of OB is a major hindrance in its acceptance. As you say, since the browsers are so similar there is really little reason to choose the slow one ;-)
Well, i hope that will be fixed eventually by developers.
You mean by the users of the browser or by the OB core developers? If the former, I find that somewhat unlikely. OB appears to be much more complex than the regular browser; I was trying to fix the annoying bug with the context menu blowing up but the structure was sort of a jungle and trying to navigate that with a browser that slow turned out to exceed my patience by a long shot ;-)
From other side, i like a new stuff , added to OB , like icons, tests integration (so you can run test methods by just clicking on method in method pane) and many others.
I like some of it too. The tests integration is definitely helpful for example.
Cheers, - Andreas
Andreas Raab wrote:
I tried OB on Pharo when I was looking into some FFI troubles. The main noticable difference was *incredible* sluggishness. Every single action was greeted with a 2-5 seconds pause. I kid you not. Granted, my computer isn't exactly the fastest, but those were all actions where with the regular Squeak browser I feel no noticable delay whatsoever.
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
To satisfy my curiosity, could someone point me to the results of any code profiling done on this issue?
2009/7/9 David Corking lists@dcorking.com:
Andreas Raab wrote:
I tried OB on Pharo when I was looking into some FFI troubles. The main noticable difference was *incredible* sluggishness. Every single action was greeted with a 2-5 seconds pause. I kid you not. Granted, my computer isn't exactly the fastest, but those were all actions where with the regular Squeak browser I feel no noticable delay whatsoever.
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
To satisfy my curiosity, could someone point me to the results of any code profiling done on this issue?
I've seen a discussion , related to this in Pharo list and related to improving the speed.
Igor Stasenko wrote:
I tried OB on Pharo when I was looking into some FFI troubles. The main noticable difference was *incredible* sluggishness. Every single action was greeted with a 2-5 seconds pause. I kid you not.
...
I've seen a discussion , related to this in Pharo list and related to improving the speed.
Igor, I saw your February post, so I see the low-hanging fruit has been harvested: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005188.ht...
However the June pharo-dev image is slow to draw new OB windows. (I didn't try more recent updates) Is OmniBrowser in Squeak equally as slow?
As an alternative: tips to avoid frequently opening new windows may be useful.
2009/7/9 David Corking lists@dcorking.com:
Igor Stasenko wrote:
I tried OB on Pharo when I was looking into some FFI troubles. The main noticable difference was *incredible* sluggishness. Every single action was greeted with a 2-5 seconds pause. I kid you not.
...
I've seen a discussion , related to this in Pharo list and related to improving the speed.
Igor, I saw your February post, so I see the low-hanging fruit has been harvested: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005188.ht...
Ah, no :) I meant a more recent discussion, maybe a week ago or so.
However the June pharo-dev image is slow to draw new OB windows. (I didn't try more recent updates) Is OmniBrowser in Squeak equally as slow?
I never tried to install it myself, so can't tell anything about it.
As an alternative: tips to avoid frequently opening new windows may be useful.
I don't have a recipe :) It depends on complexity/project code widespread & your current intents. Currently i writing some stuff which is very small addition to existing code base, so its enough to keep 2 browser windows open for almost all my needs. But sometimes it happens, that you need to go and explore things (senders/implementors etc) and very soon you could have dozens of windows open.
On 9-Jul-09, at 2:22 AM, David Corking wrote:
Andreas Raab wrote:
I tried OB on Pharo when I was looking into some FFI troubles. The main noticable difference was *incredible* sluggishness. Every single action was greeted with a 2-5 seconds pause. I kid you not. Granted, my computer isn't exactly the fastest, but those were all actions where with the regular Squeak browser I feel no noticable delay whatsoever.
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
The problem here is that "OmniBrowser" is a fairly nebulous thing. It's a collection of packages, some of which are quite mature and perform reasonably well, and others which are more experimental. The configurations that tend to get installed in Squeak and Pharo are often just the most recent commits, rather than a coherent release.
To remedy this, I'm working on polishing up a clean release, which I'll call "OmniBrowser 2.0" and impose the same numbering scheme and release discipline that's been working well for Monticello 2. It should be ready Real Soon Now.
Colin
David Corking wrote:
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
To satisfy my curiosity, could someone point me to the results of any code profiling done on this issue?
I haven't done any real profiling. But here is a starting point:
[ToolSet default browse: Behavior selector: nil] timeToRun.
On my box this takes 506 msecs in Squeak 3.10, using Pharo it's at 5020 msecs. That's 10x slower.
Cheers, - Andreas
That'd be OB then. With the StandardToolSet, Pharo0.1Core-10371, on a 2.8 Quad I get 303 ms...
Regards, Gary
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 09, 2009 4:40 PM Subject: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
David Corking wrote:
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
To satisfy my curiosity, could someone point me to the results of any code profiling done on this issue?
I haven't done any real profiling. But here is a starting point:
[ToolSet default browse: Behavior selector: nil] timeToRun.
On my box this takes 506 msecs in Squeak 3.10, using Pharo it's at 5020 msecs. That's 10x slower.
Cheers,
- Andreas
Gary Chambers wrote:
That'd be OB then. With the StandardToolSet, Pharo0.1Core-10371, on a 2.8 Quad I get 303 ms...
That sounds about right. And yes, it's obviously an OB issue - this whole discussion started out by Igor wondering why people don't like using OB. I think a major part of the answer is just that.
Cheers, - Andreas
Regards, Gary
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 09, 2009 4:40 PM Subject: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
David Corking wrote:
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
To satisfy my curiosity, could someone point me to the results of any code profiling done on this issue?
I haven't done any real profiling. But here is a starting point:
[ToolSet default browse: Behavior selector: nil] timeToRun.
On my box this takes 506 msecs in Squeak 3.10, using Pharo it's at 5020 msecs. That's 10x slower.
Cheers,
- Andreas
Indeed.
Regards, Gary
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 09, 2009 6:17 PM Subject: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
Gary Chambers wrote:
That'd be OB then. With the StandardToolSet, Pharo0.1Core-10371, on a 2.8 Quad I get 303 ms...
That sounds about right. And yes, it's obviously an OB issue - this whole discussion started out by Igor wondering why people don't like using OB. I think a major part of the answer is just that.
Cheers,
- Andreas
Regards, Gary
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 09, 2009 4:40 PM Subject: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
David Corking wrote:
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
To satisfy my curiosity, could someone point me to the results of any code profiling done on this issue?
I haven't done any real profiling. But here is a starting point:
[ToolSet default browse: Behavior selector: nil] timeToRun.
On my box this takes 506 msecs in Squeak 3.10, using Pharo it's at 5020 msecs. That's 10x slower.
Cheers,
- Andreas
That sounds about right. And yes, it's obviously an OB issue - this whole discussion started out by Igor wondering why people don't like using OB. I think a major part of the answer is just that.
It is definitely not an issue of OB, but an issue of the extensions that people load with OB.
If you try the Seaside One Click image you will notice that OB is only marginally slower than the old browser.
Lukas
Or could it be related to some preferences ???
----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)
________________________________ From: Lukas Renggli renggli@gmail.com To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 9, 2009 1:52:05 PM Subject: Re: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
That sounds about right. And yes, it's obviously an OB issue - this whole discussion started out by Igor wondering why people don't like using OB. I think a major part of the answer is just that.
It is definitely not an issue of OB, but an issue of the extensions that people load with OB.
If you try the Seaside One Click image you will notice that OB is only marginally slower than the old browser.
Lukas
More than likely. Auto-categories springs to mind...
Regards, Gary
----- Original Message ----- From: "Lukas Renggli" renggli@gmail.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 09, 2009 6:52 PM Subject: Re: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MITlicenseclean))
That sounds about right. And yes, it's obviously an OB issue - this whole discussion started out by Igor wondering why people don't like using OB. I think a major part of the answer is just that.
It is definitely not an issue of OB, but an issue of the extensions that people load with OB.
If you try the Seaside One Click image you will notice that OB is only marginally slower than the old browser.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
On Thu, Jul 9, 2009 at 6:52 PM, Lukas Renggli wrote:
If you try the Seaside One Click image you will notice that OB is only marginally slower than the old browser.
That is great news - thanks Lukas - we can be optimistic about the future of the browsers. I guess if someone digs into Damien's build scripts, the difference will become evident.
2009/7/9 Andreas Raab andreas.raab@gmx.de:
Gary Chambers wrote:
That'd be OB then. With the StandardToolSet, Pharo0.1Core-10371, on a 2.8 Quad I get 303 ms...
That sounds about right. And yes, it's obviously an OB issue - this whole discussion started out by Igor wondering why people don't like using OB. I think a major part of the answer is just that.
I don't notice very big sluggines on my quad-core. Unless i open 5-6 windows.. :)
Cheers, - Andreas
Regards, Gary
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 09, 2009 4:40 PM Subject: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT licenseclean))
David Corking wrote:
I used a 2 GHz Intel processor, and got a delay of around a second every time I opened a new browser window in pharo-dev 0.1. (I used the OB clones of the standard browsers - not any of the new browsers or undocumented new features. Also, I don't know if other images perform better.)
To satisfy my curiosity, could someone point me to the results of any code profiling done on this issue?
I haven't done any real profiling. But here is a starting point:
[ToolSet default browse: Behavior selector: nil] timeToRun.
On my box this takes 506 msecs in Squeak 3.10, using Pharo it's at 5020 msecs. That's 10x slower.
Cheers, - Andreas
For me nothing about OB is familiar. I cant find menu items, menu items work differently, and there is this text box thing which never does anything as I expect it to.
Perhaps some documentation would help, even a screencast.
Keith
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Benoit St-Jean -
Bert Freudenberg -
Casimiro de Almeida Barreto -
Colin Putney -
David Corking -
David T. Lewis -
Edgar J. De Cleene -
Gary Chambers -
Göran Krampe -
Ian Trudel -
Igor Stasenko -
Joshua Gargus -
Juan Vuletich -
K. K. Subramaniam -
Keith Hodges -
Lukas Renggli -
Michael Haupt -
Norbert Hartl -
Paolo Bonzini -
Ramon Leon -
Rita Freudenberg -
Ryan Simmons -
Sebastian Sastre -
Stéphane Rollandin -
Trygve Reenskaug -
Yoshiki Ohshima