On Sun, Apr 6, 2008 at 4:11 AM, Hilaire Fernandes hilaire@ofset.org wrote:
tim Rowledge a écrit :
On 4-Apr-08, at 8:49 PM, Klaus D. Witzel wrote:
It seems to me that the board has a problem here, with both 3.9 and 3.10 :(
Well, no. It's not the board that has any sort of problem; the board is a bunch of people that meet every couple of weeks to discuss an agenda that is primarily organisation based (ie getting to a state where we can join the SFLC foudation thingy). The board is not a team that can be asked or expected to solve all *our* problems. *You lot* get to do the actual work. Until and unless you provide funds to pay a team....
I found this statement pretty irresponsible :( And reading this statement one may think what is the Sqf good for (beside the never ending registration in SFLC...) and outsiders may even fell that Squeak community is not a good place to go (no clear roadmap).
Hilaire
I think you're overstating things a bit. The point is that unless you are willing to jump in and help, or provide other means of help (i.e. funding), one shouldn't complain about the state of affairs. The people doing this work are doing it as a free service to others and for that, we should be grateful. At the same time, maybe we should be thinking about alternative means of funding. The way I see it, funding is a means of enabling more people to spend more of their time working on squeak (presumably something they enjoy). I think the bounty model doesn't work all that well, and I think being dependent on benevolent commercial ventures to develop and donate substantial code is also sub-optimal. With commercial ventures, their attention is always going to be focused on their product. Innovating and developing the core squeak system will consequently only get their attention when it is necessary to further the commercial product. And then, they will only develop it as far as it needs to go to serve their interests and no further. I find it a real shame that the economy around core platforms and tools seems to have evaporated with the open source movement. It seems that there is precious little funding available to those that want to develop new languages, new operating systems, new development tools and the like. There is a modest amount of innovation going on in spite of this reality, but progress is frustratingly slow. Here's an idea for a funding model. Instead of always releasing new stuff immediately under MIT, how about releasing some stuff under a time limited proprietary license with a specific date at which it reverts to MIT (this would be baked into the original license such that the "freedom date" is irrevocable). The date could be 3 months, 6 months or even a year or two into the future. In the interim, anyone wishing to use that software would need to pay some fee to the author(s). This is the essentially the same idea that is behind copyright laws, but on a dramatically shorter timeframe that is more appropriate for software (the life of copy rights in the US extends for life+70 years I believe, which certainly doesn't work for software). If we could make something like this work successfully (and I'd say that success means that more people are able to spend more of their time working on squeak (instead of other endeavors to pay the bills)), I think people would quickly take notice. Imagine if this came to be an expectation of all software licenses. Imagine if all commercial software were sold like this.
To me, this is more in line with basic economics. The cost to produce software is substantial, but the marginal cost to distribute software is effectively zero. So, over time the price of software (or any intellectual property) must approach zero. It's unnatural for software to be locked up under proprietary licenses for what is effectively an indefinite period of time. It's also unnatural in my opinion to rely solely on indirect means of funding (relying on people deriving inherent fun in the work or commercial benevolence or services associated with the free software, etc). Musicians will deal with this by deriving money from live performances or associated merchandising and hence be able to offer recordings for free right from the start. I doubt too many people will pay to watch many of us as we write code, so we have to think of alternative means.
Maybe if enough people were willing to pay $10 for a high quality 3.10, it would be enough to entice a few people into spending a larger chunk of their time working on that problem. The compromise we make is that for the first 6 months (or whatever the author decides), it's not free software...you must pay $10. The small size of the squeak community won't make people rich in so doing, but over time, a better squeak means a larger community and a larger community means that more people will have an opportunity to participate as a supplier in such an economy.
- Stephen
I think you're overstating things a bit. The point is that unless you are willing to jump in and help, or provide other means of help (i.e. funding), one shouldn't complain about the state of affairs. The people doing this work are doing it as a free service to others and for that, we should be grateful.
I don't understand some logical articulations here.
how does the fact that people generously offer a free service imply that the quality of this service can not be evaluated ?
and how does the fact that someone does not participate in an effort imply that this person can not criticize the way this effort is accomplished ?
could you elaborate ?
regards,
Stef
On Sun, Apr 6, 2008 at 12:20 PM, Stéphane Rollandin lecteur@zogotounga.net wrote:
I think you're overstating things a bit. The point is that unless you are
willing to jump in and help, or provide other means of help (i.e. funding), one shouldn't complain about the state of affairs. The people doing this work are doing it as a free service to others and for that, we should be grateful.
I don't understand some logical articulations here.
how does the fact that people generously offer a free service imply that the quality of this service can not be evaluated ?
and how does the fact that someone does not participate in an effort imply that this person can not criticize the way this effort is accomplished ?
could you elaborate ?
I didn't mean to imply that critique wasn't desirable. Critique is highly valuable. We should just be careful that such critique isn't misinterpreted as an expectation or demand that others address what we perceive to be shortcomings (and I'm not saying that that happened in this case).
- Stephen
Stephen Pair a écrit :
I found this statement pretty irresponsible :( And reading this statement one may think what is the Sqf good for (beside the never ending registration in SFLC...) and outsiders may even fell that Squeak community is not a good place to go (no clear roadmap). HilaireI think you're overstating things a bit. The point is that unless you are willing to jump in and help, or provide other means of help (i.e. funding), one shouldn't complain about the state of affairs. The people
Ok, so I am not this one as I was not writting about the state of affairs, but about a statement of a SqF board member regarding the state of affairs.
Regarding funding, I was believing it was one target of the board, but Tim wrote something else, which after all I don't really understand what he exactly means by "Until and unless you provide funds to pay a team...." (sorry my English does not allow me to go behind subtleties).
Hilaire
"Stephen" == Stephen Pair stephen@pairhome.net writes:
Stephen> Maybe if enough people were willing to pay $10 for a high quality Stephen> 3.10, it would be enough to entice a few people into spending a Stephen> larger chunk of their time working on that problem.
I'm pretty sure the cost to administer the collection of $10 and preventing anyone who hasn't ponied up from getting the bits will far exceed any total revenue. That's the reality. If you want money at that level, just put up a collection box, and encourage people to donate.
Randal L. Schwartz ha scritto:
"Stephen" == Stephen Pair stephen@pairhome.net writes:
Stephen> Maybe if enough people were willing to pay $10 for a high quality Stephen> 3.10, it would be enough to entice a few people into spending a Stephen> larger chunk of their time working on that problem.
I'm pretty sure the cost to administer the collection of $10 and preventing anyone who hasn't ponied up from getting the bits will far exceed any total revenue. That's the reality. If you want money at that level, just put up a collection box, and encourage people to donate.
Micropledge ( http://www.micropledge.org) is a good service to manage small-sized contributions.
Giovanni
Randal L. Schwartz wrote:
"Stephen" == Stephen Pair stephen@pairhome.net writes:
Stephen> Maybe if enough people were willing to pay $10 for a high quality Stephen> 3.10, it would be enough to entice a few people into spending a Stephen> larger chunk of their time working on that problem.
I'm pretty sure the cost to administer the collection of $10 and preventing anyone who hasn't ponied up from getting the bits will far exceed any total revenue. That's the reality. If you want money at that level, just put up a collection box, and encourage people to donate.
Indeed. I thought in the past about possible models for funding Squeak directly and one that made sense was the "Redhat model" by which I mean a subscription-based business model where people basically pay for support and a continuous integration of fixes and enhancements. Sort of like Squeak-central worked internally: Have an update stream or similar that paying customers get access to, possibly at different levels of support (fixes only; fixes+enhancements; fixes+enhancements+alpha stuff). Then make regular external releases that people can download. For a commercial entitity there is an obvious advantage to being able to continuously integrate incremental changes and having this go through an orderly QA and test cycle is another advantage. And of course, for larger companies it would mean there is a vendor to talk to. The obvious difficulty is there is zero information about the size of the market for such a business model; in particular considering that it would need to be able to compete with a free community offering.
Cheers, - Andreas
On Sun, Apr 6, 2008 at 9:17 PM, Andreas Raab andreas.raab@gmx.de wrote:
Randal L. Schwartz wrote:
"Stephen" == Stephen Pair stephen@pairhome.net writes:
Stephen> Maybe if enough people were willing to pay $10 for a high quality Stephen> 3.10, it would be enough to entice a few people into spending a Stephen> larger chunk of their time working on that problem.
I'm pretty sure the cost to administer the collection of $10 and preventing anyone who hasn't ponied up from getting the bits will far exceed any total revenue. That's the reality. If you want money at that level, just put up a collection box, and encourage people to donate.
Indeed. I thought in the past about possible models for funding Squeak directly and one that made sense was the "Redhat model" by which I mean a subscription-based business model where people basically pay for support and a continuous integration of fixes and enhancements. Sort of like Squeak-central worked internally: Have an update stream or similar that paying customers get access to, possibly at different levels of support (fixes only; fixes+enhancements; fixes+enhancements+alpha stuff). Then make regular external releases that people can download. For a commercial entitity there is an obvious advantage to being able to continuously integrate incremental changes and having this go through an orderly QA and test cycle is another advantage. And of course, for larger companies it would mean there is a vendor to talk to. The obvious difficulty is there is zero information about the size of the market for such a business model; in particular considering that it would need to be able to compete with a free community offering.
I don't consider the RedHat model to be direct funding. It's indirect in the sense that they aren't charging for the actual software, but rather the service of consolidating, testing and managing the contributions of many. That is valuable, and obviously, that can work. My argument is that maybe copyright law actually has it right, but that it's just the timeframe in which things become open source (life+70) that's off the mark. So, let's imagine that one creates some cool new thing that's interesting to most of the community. If they make it available under a license that says "pay $10 (I'm making up a number here) and you can use this as you desire now, or wait 1 year and it will be available to you under MIT" what would be the reaction? I'd say that competes very well with free. Why would anyone go to the effort of creating something competitive if the code is good, if the fee is nominal and if the duration of the commercial license is a) established up front and irrevocable, and b) not onerously far into the future. Unless someone thinks they could come up with something better in the very near future, there is very little incentive to do so. And if they do, well that benefits everyone. The people that need it most would fund the development for everyone else.
In terms of figuring out the market, there were ~500 people that cared enough about squeak to vote on the board. If you take that as a guide, then maybe you guess that with a reasonably appealing offering you could capture 50% of that market at $10. That's $2500. It's not going to set anyone free of their corporate shackles, but it's not bad if the effort amounts to a few weekends of work and you enjoy what you're doing along the way. And, the more such things we have, the more appealing squeak becomes and the more the market grows.
I am merely frustrated that in my ~5 year absence from squeak, my perception is that squeak is worse off today than it was 5 years ago. I am encouraged in some respects, but in others, it's very discouraging (very, very discouraging). I am also very concerned that the entire open source movement seems to be moving in a direction where we'll all be employed by large corporations who grant us the right to contribute to open source "at their convenience." That is disturbing.
So anyway, we can debate it, or we can try it. There are a lot of things people have contributed over the years that I would have gladly paid for as long as I knew it would be MIT licensed in the near future and was good quality. Monticello, OmniBrowser, Traits, UI enhancements, and more recently hydraVM (just to name a very few...there are many others). I would like to see someone try this with their next contribution.
- Stephen
I believe the idea of exclusive content (whatever that may be) is not a solution to funding. In fact I think it will even have the opposite effect of alienating many of the *178* who bothered enough to vote. Much better to foster a more *inclusive* community spirit and try to increase that number a 100 times. Then you may have the critical mass to offer value-added extras. Blender is a good example and despite past failures it now seems to be doing pretty well. Outside of the product itself, I put most of Blenders success down to the very vibrant BlenderArtists FORUM with "over 20,000 registered users". IMHO a modern style forum is essential these days as I suspect most of the younger generation are simply not inspired by mailing lists. There is a sense of "congregating" around a forum while a mailing-list appears as a somewhat intrusive cluttering of already busy mailboxes. It would also help if there was a more visible focus on new users and usability in general.
On Mon, Apr 7, 2008 at 4:10 AM, Stephen Pair stephen@pairhome.net wrote:
On Sun, Apr 6, 2008 at 9:17 PM, Andreas Raab andreas.raab@gmx.de wrote:
Randal L. Schwartz wrote:
"Stephen" == Stephen Pair stephen@pairhome.net writes:
Stephen> Maybe if enough people were willing to pay $10 for a high
quality
Stephen> 3.10, it would be enough to entice a few people into spending a Stephen> larger chunk of their time working on that problem.
I'm pretty sure the cost to administer the collection of $10 and
preventing
anyone who hasn't ponied up from getting the bits will far exceed any
total
revenue. That's the reality. If you want money at that level, just put
up a
collection box, and encourage people to donate.
Indeed. I thought in the past about possible models for funding Squeak
directly and one that made sense was the "Redhat model" by which I mean a subscription-based business model where people basically pay for support and a continuous integration of fixes and enhancements. Sort of like Squeak-central worked internally: Have an update stream or similar that paying customers get access to, possibly at different levels of support (fixes only; fixes+enhancements; fixes+enhancements+alpha stuff). Then make regular external releases that people can download. For a commercial entitity there is an obvious advantage to being able to continuously integrate incremental changes and having this go through an orderly QA and test cycle is another advantage. And of course, for larger companies it would mean there is a vendor to talk to. The obvious difficulty is there is zero information about the size of the market for such a business model; in particular considering that it would need to be able to compete with a free community offering.
I don't consider the RedHat model to be direct funding. It's indirect in the sense that they aren't charging for the actual software, but rather the service of consolidating, testing and managing the contributions of many. That is valuable, and obviously, that can work. My argument is that maybe copyright law actually has it right, but that it's just the timeframe in which things become open source (life+70) that's off the mark. So, let's imagine that one creates some cool new thing that's interesting to most of the community. If they make it available under a license that says "pay $10 (I'm making up a number here) and you can use this as you desire now, or wait 1 year and it will be available to you under MIT" what would be the reaction? I'd say that competes very well with free. Why would anyone go to the effort of creating something competitive if the code is good, if the fee is nominal and if the duration of the commercial license is a) established up front and irrevocable, and b) not onerously far into the future. Unless someone thinks they could come up with something better in the very near future, there is very little incentive to do so. And if they do, well that benefits everyone. The people that need it most would fund the development for everyone else.
In terms of figuring out the market, there were ~500 people that cared enough about squeak to vote on the board. If you take that as a guide, then maybe you guess that with a reasonably appealing offering you could capture 50% of that market at $10. That's $2500. It's not going to set anyone free of their corporate shackles, but it's not bad if the effort amounts to a few weekends of work and you enjoy what you're doing along the way. And, the more such things we have, the more appealing squeak becomes and the more the market grows.
I am merely frustrated that in my ~5 year absence from squeak, my perception is that squeak is worse off today than it was 5 years ago. I am encouraged in some respects, but in others, it's very discouraging (very, very discouraging). I am also very concerned that the entire open source movement seems to be moving in a direction where we'll all be employed by large corporations who grant us the right to contribute to open source "at their convenience." That is disturbing.
So anyway, we can debate it, or we can try it. There are a lot of things people have contributed over the years that I would have gladly paid for as long as I knew it would be MIT licensed in the near future and was good quality. Monticello, OmniBrowser, Traits, UI enhancements, and more recently hydraVM (just to name a very few...there are many others). I would like to see someone try this with their next contribution.
- Stephen
On Mon, Apr 7, 2008 at 5:23 AM, Derek O'Connell doconnel@gmail.com wrote:
I believe the idea of exclusive content (whatever that may be) is not a solution to funding. In fact I think it will even have the opposite effect of alienating many of the *178* who bothered enough to vote. Much better to foster a more *inclusive* community spirit and try to increase that number a 100 times.
Squeak has been around more than 10 years now. It's not evident to me that the community is significantly larger today than it was just a couple years after its debut. As for alienating, I don't see anything exclusive or alienating about this approach.
Then you may have the critical mass to offer value-added extras. Blender is a good example and despite past failures it now seems to be doing pretty well.
Blender happened under almost the exact same circumstances that I propose, only by accident (and on a much longer timeframe than I would envision).
Outside of the product itself, I put most of Blenders success down to the very vibrant BlenderArtists FORUM with "over 20,000 registered users". IMHO a modern style forum is essential these days as I suspect most of the younger generation are simply not inspired by mailing lists. There is a sense of "congregating" around a forum while a mailing-list appears as a somewhat intrusive cluttering of already busy mailboxes. It would also help if there was a more visible focus on new users and usability in general.
This is a different topic...but, yes, I'm with you on it...anything that could enhance the community experience would be a good thing.
- Stephen
On Mon, Apr 7, 2008 at 1:34 PM, Stephen Pair stephen@pairhome.net wrote:
On Mon, Apr 7, 2008 at 5:23 AM, Derek O'Connell doconnel@gmail.com wrote:
I believe the idea of exclusive content (whatever that may be) is not a solution to funding. In fact I think it will even have the opposite effect of alienating many of the *178* who bothered enough to vote. Much better to foster a more *inclusive* community spirit and try to increase that number a 100 times.
Squeak has been around more than 10 years now. It's not evident to me that the community is significantly larger today than it was just a couple years after its debut.
Are you saying that is good/bad/not-a-problem?
As for alienating, I don't see anything exclusive or alienating about this approach.
I don't disagree with your proposal in principle but I think willingness to contribute (if at all needed) may only come after the fee paying period. OTOH if that period is kept short enough then maybe people will play along with the idea.
Then you may have the critical mass to offer value-added extras. Blender is a good example and despite past failures it now seems to be doing pretty well.
Blender happened under almost the exact same circumstances that I propose, only by accident (and on a much longer timeframe than I would envision).
Do mean originally or lately? Or do you refer to the period of "Blender Publisher"? If you mean the latter then IIRC it failed and there was a period of uncertainty about Blender's future until the "Foundation" idea arose. Blender already had a good following by then but IMHO this was a catalyst for fostering community spirit and probably provided a momentum that still benefits Blender and it's users today. I only use Blender occasionally these days but I did buy Publisher and I bought every edition of the manual and will continue to do so. Why? Hmmm, because Ton and his crew are responsive, open, helpful, have vision, purpose and, damn it, I just *want* them to succeed :-) Get 20000 "users" and money will flow if only a fraction of them have that attitude.
In fairness you may now wonder if I have that attitude to Squeak. Sort-a, maybe-ish. Even though I can see potential and firmly believe that Squeak should be on everyone's "must-learn-to-use" list, I am not surprised it isn't. The user friendly façade is skin-deep, getting information is sometimes akin to pulling one's own teeth, what should be simple tasks often end up feeling like quicksand, "documentation" is seemingly a dirty word (SBE, a sterling effort, came long after my first experiences), there's too much "pay me if you want it" demand type attitude, a refusal in some respects to move with the times and especially no/little recognition that some people just want to "use" it, not get intimate with it's darkest depth's almost every time you set out to do something (that's sort of the same as the "quicksand" comment I know, but sort-of different ;-) ). I have commented in the past to the effect that some sort of buffer is needed for new/occasional users and I also think the user experience has to rock-solid.
OTOH where Squeak leads others follow and it's community has some of the brightest, ingenious, helpful and dedicated people I have come across... but it is clearly not enough. My stance is more users = more activity = more visibility = more willingness to adopt = more chance of general funding (rather than just for occasional specific tasks). Then again recent comments on the ML claiming new users not required/ community is large enough, etc, make me despondent and dents my enthusiasm.
Outside of the product itself, I put most of Blenders success down to the very vibrant BlenderArtists FORUM with "over 20,000 registered users". IMHO a modern style forum is essential these days as I suspect most of the younger generation are simply not inspired by mailing lists. There is a sense of "congregating" around a forum while a mailing-list appears as a somewhat intrusive cluttering of already busy mailboxes. It would also help if there was a more visible focus on new users and usability in general.
This is a different topic...but, yes, I'm with you on it...anything that could enhance the community experience would be a good thing.
- Stephen
Different, I agree, but all interrelated. This is one of those few occasions when I would tip my beany-cap at marketing people and saying "branding" and "delivery on brand promises" is all-important.
BTW, welcome back after your five year absence! Care to explain why you left/ what brought you back? May be some lessons there :-)
On Mon, Apr 7, 2008 at 10:44 AM, Derek O'Connell doconnel@gmail.com wrote:
On Mon, Apr 7, 2008 at 1:34 PM, Stephen Pair stephen@pairhome.net wrote:
Squeak has been around more than 10 years now. It's not evident to me
that
the community is significantly larger today than it was just a couple
years
after its debut.
Are you saying that is good/bad/not-a-problem?
I think it's bad for exactly the reasons you articulate below. It's not some vain desire to be popular. It's about engaging more people, creating a viable economy (by a variety of means) and in the end, spur more rapid progress.
As for alienating, I don't see anything exclusive or alienating about this approach.
I don't disagree with your proposal in principle but I think willingness to contribute (if at all needed) may only come after the fee paying period. OTOH if that period is kept short enough then maybe people will play along with the idea.
You may be right. I personally am very reluctant to invest effort in something that is not open source. However, something that I knew would become open source on a relatively short time horizon would be a different matter.
...snipped stuff about Blender... With Blender, my only point was that it started life as a commercial product...dabbled with some hybrid approaches along the way, and then ultimately became open source. Now that there is a substantial community around it, there are lots of options available to that community to sustain an economy. The question is, would it have evolved if it tried to start out life as open source? Or, would it have gained 5 followers and fizzled out long before anything materialized? It's also interesting to note that Smalltalk (and hence squeak) began life as a proprietary system (corporate research at first, then later commercialized, and even later open sourced). Would Smalltalk have happened without the economy around corporate research? Would we even be having this discussion if that had not happened? Has there been substantial progress since squeak was open sourced? Are there not a substantial number of people on this list that are frustrated by the slow progress? Or frustrated with their own incapacity to do anything about it (or to do as much as they would like)? I would love nothing more than to be in a position where I could focus 100% of my professional attention at squeak and the community around it.
OTOH where Squeak leads others follow and it's community has some of the brightest, ingenious, helpful and dedicated people I have come across... but it is clearly not enough. My stance is more users = more activity = more visibility = more willingness to adopt = more chance of general funding (rather than just for occasional specific tasks). Then again recent comments on the ML claiming new users not required/ community is large enough, etc, make me despondent and dents my enthusiasm.
Yes, I agree. More brains, more vitality, more progress and more fun.
BTW, welcome back after your five year absence! Care to explain why
you left/ what brought you back? May be some lessons there :-)
Well, it comes down to a scarcity of time. I had kids and I have a job and there is very little time left over. I had also failed to make swiki.net(hosted wikis) into a viable business, which, being based on squeak, would have enabled me to continue using squeak as part of my work. As for what's brought me back, I'd say it's a desire to find inspiration combined with the fact that the demands on my time are somewhat less severe (though still very constricting). I'd say the lesson is this: let's figure out a way to make working on squeak and putting food on the table less mutually exclusive.
- Stephen
The difference between Blender and Squeak if we look at them as products that Blender is _end-user_ product, while Squeak is platform without any end-user products. While Blender requires a lot to learn for some of newcomers, it's targeted on specific tasks: 3D design/rendering and postprocessing. And Squeak by itself is nothing more than a base platform for developing applications (like Blender). A squeak VM/image plays same role as operating system for Blender: you have to install some applications for working on specific tasks.
So, it's really different. Nobody willing to donate/fund operating systems. People may want to fund specific projects, which developed to deal with specific tasks in specific areas (web/3D design etc), but not operating systems, which is too generic and basic and not targeted to be used by end-users.
The way ahead for 3.10....
3.10 is out and has been announced as released. I myself was disappointed that the final 3.10 did not contain a couple of fixes that I regarded as essential. Having come to terms with the fact that I was never going to get the 3.10 team to see my point of view, I started LPF.
I myself aim to use 3.10 + LPF + Clean + Latest, as the basis for the production images that I am using. At present I am using 3.10 + LPF + LatestUnstable.
So I think that the way ahead for 3.10 is for the community to join in contributing to LPF scripts designed to be run in a fresh 3.10 image so that the combination of "3.10 + LPF + Tidy + Clean + Latest + Welcome" will produce what we are looking for, and that can be released later as 3.11 or 3.10.1
best regards
Keith
When going through the Installer sequence at http://installer.pbwiki.com/ loading into sq3.10-7159dev08.04.1,
Do this - 1. LevelPlayingField
Skip this - 1. Tidy - Cosmetic tidy up Skip this - 2. Clean - Remove packages which can be loaded again Do this - 3. Packages - Install "Sake" and Package Maps for your version Do MinorFixes only - 4. Latest - MinorFixes, MajorFixes and PackageUpgrades Do MinorFixesUnstable - 5. LatestUnstable - MinorFixesUnstable, MajorFixesUnstable and PackageUpgradesUnstable
While doing MinorFixesUnstable, all seems ok until
" http://bugs.squeak.org/view.php?id=6890 " Installer mantis ensureFix: '0006890: PluggableListMorph is slow'.
After I install 6890, the System Browser scrollbars no longer work, they extend the full length. The scroll arrows appear to work however.
Ken G. Brown
--- In squeak@yahoogroups.com, Keith Hodges <keith_hodges@...> wrote:
The way ahead for 3.10....
3.10 is out and has been announced as released. I myself was disappointed that the final 3.10 did not contain a couple of fixes that I regarded as essential. Having come to terms with the fact that I was never going to get the 3.10 team to see my point of view, I started LPF.
I myself aim to use 3.10 + LPF + Clean + Latest, as the basis for the production images that I am using. At present I am using 3.10 + LPF + LatestUnstable.
So I think that the way ahead for 3.10 is for the community to join in contributing to LPF scripts designed to be run in a fresh 3.10 image so that the combination of "3.10 + LPF + Tidy + Clean + Latest + Welcome" will produce what we are looking for, and that can be released later as 3.11 or 3.10.1
best regards
Keith
On Mon, Apr 07, 2008 at 09:38:03PM -0000, kengbrown wrote:
" http://bugs.squeak.org/view.php?id=6890 " Installer mantis ensureFix: '0006890: PluggableListMorph is slow'.
After I install 6890, the System Browser scrollbars no longer work, they extend the full length. The scroll arrows appear to work however.
I "fixed" this by removing the fixing of bug 6890 from the installer script. That fix is a little too invasive yet.
On Mon, Apr 7, 2008 at 1:51 PM, Igor Stasenko siguctua@gmail.com wrote:
The difference between Blender and Squeak if we look at them as products that Blender is _end-user_ product, while Squeak is platform without any end-user products. While Blender requires a lot to learn for some of newcomers, it's targeted on specific tasks: 3D design/rendering and postprocessing. And Squeak by itself is nothing more than a base platform for developing applications (like Blender). A squeak VM/image plays same role as operating system for Blender: you have to install some applications for working on specific tasks.
So, it's really different. Nobody willing to donate/fund operating systems. People may want to fund specific projects, which developed to deal with specific tasks in specific areas (web/3D design etc), but not operating systems, which is too generic and basic and not targeted to be used by end-users.
Yes, nobody other than Microsoft, Apple, IBM, Sun and a handful of others. ;)
- Stephen
I think that founding should first and foremost come from the people earning money from the Squeak. Companies making money from Squeak based products, consultants consulting Squeak based solutions and so on.
I'm actually preparing to donate back to community when I'll move my first customer's system on Squeak. I feel a kind of obligation to give something back, and if I make money I should give back money. This is right way to do, that's what I'm sure.
Janko
Igor Stasenko wrote:
The difference between Blender and Squeak if we look at them as products that Blender is _end-user_ product, while Squeak is platform without any end-user products. While Blender requires a lot to learn for some of newcomers, it's targeted on specific tasks: 3D design/rendering and postprocessing. And Squeak by itself is nothing more than a base platform for developing applications (like Blender). A squeak VM/image plays same role as operating system for Blender: you have to install some applications for working on specific tasks.
So, it's really different. Nobody willing to donate/fund operating systems. People may want to fund specific projects, which developed to deal with specific tasks in specific areas (web/3D design etc), but not operating systems, which is too generic and basic and not targeted to be used by end-users.
Hello Janko,
JM> I'm actually preparing to donate back to community when I'll move my JM> first customer's system on Squeak. I feel a kind of obligation to give
same with me, I've done some commercial work in Squeak mainly on the basis that it was my unpaid fun. As soon as it's recognized as a contribution worth money I plan to donate a part of this for Squeak.
Until then I mainly can donate replies to newbies :-))
Cheers,
Herbert
Smalltalk is only a niche. And Squeak is a niche in the world of Smalltalk. Furthermore, a great part of the Squeak community is academic. I don't see a good chance of fund raising a noteworthy amount until the Squeak community grows a lot and especially more companies get interested in Squeak.
I really doubt that we can find many who like to throw money at Squeak without being convinced to get something valuable back. But it is hard to get new people interested in Smalltalk and Squeak. And many of the newcomers get alienated by many aspects of Squeak: - it is hard to find documentation - it is hard to get used to Morphic (its power isn't obvious but its clutter is) - it is hard to find a Squeak version with not so many obvious bugs and problems
Andreas
A key problem with funding is the sheer amount one would need to achieve very much; if we postulate a dozen people (say 10 that do development work, a manager/leader and an admin) you would have to budget around $1.2M a year; increasing steadily as the USD sinks into the mire.
Volunteer work can achieve amazing things in some cases but it rarely has much success in handling the 'boring bits'. Look how few people have offered at any time to work on the unglamorous building of releases, harvesting of bug reports and potential fixes, writing of comments, etc etc etc. Come to that, look how few people do any of that even when paid to....
So far as I can see the only way that major work has been done in/for Squeak is when someone is funding a sizeable project and it includes a subsystem that can be spun out for general use. Interval, Apple, Disney, exobox, HP, IBM, and of course the slightly different sort of funding from some academic cases. Oh and a few of us (Anthony, Bryce, Craig, me, maybe others?) that have de-facto funded projects simply by not earning any money for an extended period whilst we do something for Squeak. Three years of my near-full-time attention adds up to a pretty big donation.
I think - as with so many things - Alan was right about funding. He successfully managed to get three major corporations to provide loosely tied funding and now has a sizeable chunk from the NSF. We do need to remember though that his aim is to develop a sensible education system, not a 'better Squeak'.
Bottom line - unless you can find major funding the only resources available are those freely offered by *you*.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim When flying inverted, remember that down is up and up is expensive
On Mon, Apr 7, 2008 at 2:31 PM, tim Rowledge tim@rowledge.org wrote:
A key problem with funding is the sheer amount one would need to achieve very much; if we postulate a dozen people (say 10 that do development work, a manager/leader and an admin) you would have to budget around $1.2M a year; increasing steadily as the USD sinks into the mire.
Are planning a mission to the moon? There are many things that could be accomplished with a lot less.
Volunteer work can achieve amazing things in some cases but it rarely has
much success in handling the 'boring bits'. Look how few people have offered at any time to work on the unglamorous building of releases, harvesting of bug reports and potential fixes, writing of comments, etc etc etc. Come to that, look how few people do any of that even when paid to....
So far as I can see the only way that major work has been done in/for Squeak is when someone is funding a sizeable project and it includes a subsystem that can be spun out for general use. Interval, Apple, Disney, exobox, HP, IBM, and of course the slightly different sort of funding from some academic cases. Oh and a few of us (Anthony, Bryce, Craig, me, maybe others?) that have de-facto funded projects simply by not earning any money for an extended period whilst we do something for Squeak. Three years of my near-full-time attention adds up to a pretty big donation.
More like enormous...funding can take many forms and be accomplished in many ways.
I think - as with so many things - Alan was right about funding. He successfully managed to get three major corporations to provide loosely tied funding and now has a sizeable chunk from the NSF. We do need to remember though that his aim is to develop a sensible education system, not a 'better Squeak'.
To date, that has certainly been the most successful approach to funding squeak.
Bottom line - unless you can find major funding the only resources available are those freely offered by *you*.
Which of course equates to major funding.
- Stephen
On 7-Apr-08, at 12:00 PM, Stephen Pair wrote:
On Mon, Apr 7, 2008 at 2:31 PM, tim Rowledge tim@rowledge.org wrote: A key problem with funding is the sheer amount one would need to achieve very much; if we postulate a dozen people (say 10 that do development work, a manager/leader and an admin) you would have to budget around $1.2M a year; increasing steadily as the USD sinks into the mire.
Are planning a mission to the moon? There are many things that could be accomplished with a lot less.
What, you think I'm not worth 100K a year?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DNPG: Do Not Pass Go
Well that seems reasonable first world rates. Recall Tim and I just came off the Sophie project where we had a budget in those figures, don't forget all the stuff that has to be done, documentation, art work, mantis, VM work, image cleanup, releases etc etc etc. Well let alone website, advertising, trade shows etc....
Today there are 4,099 entries in Mantis on Sophie, yet it's a *much* smaller scope than Squeak. So if one had *real* feature, problem, etc tracking for Squeak how big do you think the mountain would be.
On Apr 7, 2008, at 12:50 PM, tim Rowledge wrote:
On 7-Apr-08, at 12:00 PM, Stephen Pair wrote:
On Mon, Apr 7, 2008 at 2:31 PM, tim Rowledge tim@rowledge.org wrote: A key problem with funding is the sheer amount one would need to achieve very much; if we postulate a dozen people (say 10 that do development work, a manager/leader and an admin) you would have to budget around $1.2M a year; increasing steadily as the USD sinks into the mire.
Are planning a mission to the moon? There are many things that could be accomplished with a lot less.
What, you think I'm not worth 100K a year?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DNPG: Do Not Pass Go
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On 7-Apr-08, at 1:03 PM, John M McIntosh wrote:
Well that seems reasonable first world rates. Recall Tim and I just came off the Sophie project where we had a budget in those figures,
... and also don't forget that that level was *very* much reduced because we wanted to work on something useful as opposed to merely commercial.
don't forget all the stuff that has to be done, documentation, art work, mantis, VM work, image cleanup, releases etc etc etc. Well let alone website, advertising, trade shows etc....
Exactly. Actual programming work is probably less than 20% of the real total.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Programmers do it bit by bit.
On Apr 7, 2008, at 1:07 PM, tim Rowledge wrote:
On 7-Apr-08, at 1:03 PM, John M McIntosh wrote:
Well that seems reasonable first world rates. Recall Tim and I just came off the Sophie project where we had a budget in those figures,
... and also don't forget that that level was *very* much reduced because we wanted to work on something useful as opposed to merely commercial.
Ya, did Tim mention the source code was all released under a BSD license? http://sophieproject.org/about/license
Mmm lots there, really excellent typography, cairo interface, FFI to clipboard, quicktime, etc...
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
John M McIntosh wrote:
On Apr 7, 2008, at 1:07 PM, tim Rowledge wrote:
On 7-Apr-08, at 1:03 PM, John M McIntosh wrote:
Well that seems reasonable first world rates. Recall Tim and I just came off the Sophie project where we had a budget in those figures,
... and also don't forget that that level was *very* much reduced because we wanted to work on something useful as opposed to merely commercial.
Ya, did Tim mention the source code was all released under a BSD license? http://sophieproject.org/about/license
Mmm lots there, really excellent typography, cairo interface, FFI to clipboard, quicktime, etc...
The typography is really nice. How dependent is that on Tweak ?
Karl
Ah the short answer is 0% dependent on Tweak to shouldn't be....
Go look at
MCHttpRepository location: 'http://source.impara.de/Rome' user: '' password: ''
well and no-doubt you need to pickup the
Sophie-Renderer Sophie-Pages
etc
SophieTextDisplayObject is asked to render on renderOn: which invokes renderer renderText: self which does the hard work of drawing the bits. Well and lots more layers about this...
On Apr 7, 2008, at 1:43 PM, karl wrote:
John M McIntosh wrote:
On Apr 7, 2008, at 1:07 PM, tim Rowledge wrote:
On 7-Apr-08, at 1:03 PM, John M McIntosh wrote:
Well that seems reasonable first world rates. Recall Tim and I just came off the Sophie project where we had a budget in those figures,
... and also don't forget that that level was *very* much reduced because we wanted to work on something useful as opposed to merely commercial.
Ya, did Tim mention the source code was all released under a BSD license? http://sophieproject.org/about/license
Mmm lots there, really excellent typography, cairo interface, FFI to clipboard, quicktime, etc...
The typography is really nice. How dependent is that on Tweak ?
Karl
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
I tried to install Rome in a new image, but failed because of dependencies I could not figure out. I loaded the Rome-* packages one after the other and I also loaded FreeType from source.impara.de but I still cannot load Rome-Fonts because it depends on the class FreetypeFont. Also, RomeBalloonCanvas has references to CIdentityTransform, CMatrixTransform etc. which are used for the demos.
Did anybody manage to load Rome in a fresh image? Or is there a loader that would do this automatically? (How is the whole Sophie project loaded?)
Cheers, Adrian
On Apr 7, 2008, at 23:47 , John M McIntosh wrote:
Ah the short answer is 0% dependent on Tweak to shouldn't be....
Go look at
MCHttpRepository location: 'http://source.impara.de/Rome' user: '' password: ''
well and no-doubt you need to pickup the
Sophie-Renderer Sophie-Pages
etc
SophieTextDisplayObject is asked to render on renderOn: which invokes renderer renderText: self which does the hard work of drawing the bits. Well and lots more layers about this...
On Apr 7, 2008, at 1:43 PM, karl wrote:
John M McIntosh wrote:
On Apr 7, 2008, at 1:07 PM, tim Rowledge wrote:
On 7-Apr-08, at 1:03 PM, John M McIntosh wrote:
Well that seems reasonable first world rates. Recall Tim and I just came off the Sophie project where we had a budget in those figures,
... and also don't forget that that level was *very* much reduced because we wanted to work on something useful as opposed to merely commercial.
Ya, did Tim mention the source code was all released under a BSD license? http://sophieproject.org/about/license
Mmm lots there, really excellent typography, cairo interface, FFI to clipboard, quicktime, etc...
The typography is really nice. How dependent is that on Tweak ?
Karl
-- = = = = = ====================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
John M McIntosh wrote:
Ya, did Tim mention the source code was all released under a BSD license? http://sophieproject.org/about/license
Mmm lots there, really excellent typography, cairo interface, FFI to clipboard, quicktime, etc...
Which bits exactly are covered by the license?
Cheers, - Andreas
Ah a license question. Well I'm not a lawyer, however my understanding is below, I'm sure others will comment.
Sophie loads onto a base 3.8.x squeak image (license for that is?) comes from I think the iSqueak repository. then we load stuff from
source.impara.de/iSqueak (license?) ask impara source.impara.de/Tweak (license?) ask impara source.impara.de/freetype (license?) ask impara source.impara.de/Rome (license?) ask impara source.impara.de/Grit (license?) ask impara
I also have stuff from http://www.squeaksource.com/XMLSupport.html (license?) ask Michael http://www.squeaksource.com/ToolBuilder.html (license?)
For source.sophieproject.org/Sophie any category starting with Sophie- is clearly written for Sophie thus under the Sophie license. In theory all code in there should be under the Sophie license however there *could* be some contamination when you consider we modify or add to existing classes found in the base squeak and from other repositories on impara.de
Say for example overrides or mod to the base URI class in Squeak, what license does that method have then?
Other categories XUL not sure (ask impara) Although since it starts at XUL-be.2 in the repository I'm sure it's Sophie-License. System-ClipBoard-Extended Sophie License System-ClipBoard-Extended-Plugin Sophie License S3* Sophie License. Network-MIME Sophie License Files-Locations Sophie License
These are overrides and additional code to stuff in Tweak, Squeak and EToys.
Multilingual Sophie License for the overrides and additions, code base Squeak Scripting Sophie License for the overrides and additions, code base Tweak Multilingual-Display Sophie License for the overrides and additions, code base Squeak Multilingual-Scanning Sophie License for the overrides and additions, code base Squeak Network-URI Sophie License for the overrides and additions, code base Squeak Sophie-Movie Sophie License, but contains OGG code from the EToys OLPC project, (code base OLPC EToys).
Any macintosh C source code I wrote for Sophie would be under the MIT license.
Anyone of course relying on this should do their own audit of course.
On Apr 7, 2008, at 3:25 PM, Andreas Raab wrote:
John M McIntosh wrote:
Ya, did Tim mention the source code was all released under a BSD license? http://sophieproject.org/about/license Mmm lots there, really excellent typography, cairo interface, FFI to clipboard, quicktime, etc...
Which bits exactly are covered by the license?
Cheers,
- Andreas
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
John M McIntosh wrote:
Well I'm not a lawyer, however my understanding is below, I'm sure others will comment.
Well, it's basically just a question about what are the base packages covered since I happen to know a couple of them being used by Sophie that probably aren't BSD licensed (Freetype comes to mind).
Sophie loads onto a base 3.8.x squeak image (license for that is?) comes from I think the iSqueak repository. then we load stuff from
source.impara.de/iSqueak (license?) ask impara source.impara.de/Tweak (license?) ask impara source.impara.de/freetype (license?) ask impara source.impara.de/Rome (license?) ask impara source.impara.de/Grit (license?) ask impara
Tweak I can actually speak for myself ;-) but for the others it would be interesting to know what license they're under. I would suspect MIT because these started during my days at Impara and at that time MIT was the preferred license. And the core Freetype libs are probably under whatever license Freetype is under these days (haven't checked in a while).
I also have stuff from http://www.squeaksource.com/XMLSupport.html (license?) ask Michael http://www.squeaksource.com/ToolBuilder.html (license?)
Oh, Toolbuilder. Right. I'll ask the authors for MIT licensing. I think that for historical reasons it is currently probably under Squeak-L.
For source.sophieproject.org/Sophie any category starting with Sophie- is clearly written for Sophie thus under the Sophie license. In theory all code in there should be under the Sophie license however there *could* be some contamination when you consider we modify or add to existing classes found in the base squeak and from other repositories on impara.de
Yeah, I'm more curious about the core classes etc. not as much about any extensions/overrides.
Say for example overrides or mod to the base URI class in Squeak, what license does that method have then?
Don't care. Either one is fine as far as I am concerned.
Other categories XUL not sure (ask impara) Although since it starts at XUL-be.2 in the repository I'm sure it's Sophie-License. System-ClipBoard-Extended Sophie License System-ClipBoard-Extended-Plugin Sophie License S3* Sophie License. Network-MIME Sophie License Files-Locations Sophie License
These are overrides and additional code to stuff in Tweak, Squeak and EToys.
These are actually interesting to me. Any word on XUL?
Anyone of course relying on this should do their own audit of course.
Yup, but thanks for the overview.
Cheers, - Andreas
"Andreas" == Andreas Raab andreas.raab@gmx.de writes:
Andreas> And the core Freetype libs are probably under whatever license Andreas> Freetype is under these days (haven't checked in a while).
First hit for "freetype license" is http://freetype.fis.uniroma2.it/license.html, which says Freetype is essentially dual-licensed, BSD-credit and GPL.
On 07.04.2008, at 21:55, Andreas Raab wrote:
John M McIntosh wrote:
Well I'm not a lawyer, however my understanding is below, I'm sure others will comment.
Well, it's basically just a question about what are the base packages covered since I happen to know a couple of them being used by Sophie that probably aren't BSD licensed (Freetype comes to mind).
Sophie loads onto a base 3.8.x squeak image (license for that is?) comes from I think the iSqueak repository. then we load stuff from source.impara.de/iSqueak (license?) ask impara source.impara.de/Tweak (license?) ask impara source.impara.de/freetype (license?) ask impara source.impara.de/Rome (license?) ask impara source.impara.de/Grit (license?) ask impara
Tweak I can actually speak for myself ;-) but for the others it would be interesting to know what license they're under. I would suspect MIT because these started during my days at Impara and at that time MIT was the preferred license.
The official Rome repository is
http://squeaksource.com/Rome.html
where it clearly states MIT.
- Bert -
On Mon, Apr 7, 2008 at 3:50 PM, tim Rowledge tim@rowledge.org wrote:
On 7-Apr-08, at 12:00 PM, Stephen Pair wrote:
On Mon, Apr 7, 2008 at 2:31 PM, tim Rowledge tim@rowledge.org wrote:
A key problem with funding is the sheer amount one would need to achieve very much; if we postulate a dozen people (say 10 that do development work, a manager/leader and an admin) you would have to budget around $1.2M a year; increasing steadily as the USD sinks into the mire.
Are planning a mission to the moon? There are many things that could be accomplished with a lot less.
What, you think I'm not worth 100K a year?
Heh...not exactly what I meant. I meant, you could do useful things on the scale of a few weeks and one or two people.
- Stephen
On Mon, Apr 7, 2008 at 2:31 PM, tim Rowledge tim@rowledge.org wrote: A key problem with funding is the sheer amount one would need to achieve very much; if we postulate a dozen people (say 10 that do development work, a manager/leader and an admin) you would have to budget around $1.2M a year; increasing steadily as the USD sinks into the mire.
Are planning a mission to the moon? There are many things that could be accomplished with a lot less.
What, you think I'm not worth 100K a year?
Heh...not exactly what I meant. I meant, you could do useful things on the scale of a few weeks and one or two people.
- Stephen
You could also pay for people to work in countries where the US Dollar (assuming that is the currency of choice for raising the funds) still has some weight and get more bang for your buck. :-)
l8r Sean
On 2008-04-07 15:31:53 -0300, tim Rowledge tim@rowledge.org said:
A key problem with funding is the sheer amount one would need to achieve very much; if we postulate a dozen people (say 10 that do development work, a manager/leader and an admin) you would have to budget around $1.2M a year; increasing steadily as the USD sinks into the mire.
As Edgar said, here in Argentina (or other third world places), the same amount of work (and with the same quality) is cheaper. A short calculous with the same team description would represent a budget around 300 thousand dollars here. And that with very decent salaries (according with Argentina standards) I think is something to have in mind: soon or later we will have to do the work that no body else wants to do.
Cheers, Esteban
A short calculous with the same team description would represent a budget around 300 thousand dollars here. And that with very decent salaries (according with Argentina standards) I think is something to have in mind: soon or later we will have to do the work that no body else wants to do.
maybe indians ? ;-)
Not funny.
Andres.
cdrick wrote:
A short calculous with the same team description would represent a budget around 300 thousand dollars here. And that with very decent salaries (according with Argentina standards) I think is something to have in mind: soon or later we will have to do the work that no body else wants to do.
maybe indians ? ;-)
On Mon, Apr 7, 2008 at 8:31 PM, tim Rowledge tim@rowledge.org wrote:
So far as I can see the only way that major work has been done in/for Squeak is when someone is funding a sizeable project and it includes a subsystem that can be spun out for general use.
Financial backing is the way most projects get anything useful done. How could it be otherwise.
"Another interesting finding is that between 70 and 95 percent of contributing developers are paid for their work. Indeed, Linux has become something of a corporate beast over the years,"....
Andreas Wacknitz wrote:
And many of the newcomers get alienated by many aspects of Squeak: - it is hard to find documentation - it is hard to get used to Morphic (its power isn't obvious but its clutter is) - it is hard to find a Squeak version with not so many obvious bugs and problems
Long time lurker here,
Short answer: (For those who don't want to read the post)
Newcomers are turned off by seemingly irreducible complexity of the system; Squeak need continual refactoring.
Long answer:
My two cents as a "newcomer" to Squeak would be that all of these are real problems. Every year or so I evaluate Squeak, as well as commercial smalltalks as part of my consulting business. To give you an idea of where I'm coming from, our business helps startups identify new technologies and design platform architectures for "emerging markets". Our customers range from 2 guys in a garage to large multinational entertainment conglomerates. My typical project last about 4 months, and in the past 4 years, I've built systems using Javascript, Common Lisp, Perl, Python, PHP, Objective-C, C, C++, Java, Forth, Postscript, Ruby, Smalltalk, Ocaml, SML NJ, Lua, and Haskell. These applications have been running on everything from 100 node clusters to cellphones.
I've wanted to use Squeak on several occasions but ran into trouble quickly enough to have to switch gears. This year's evaluation ran into some issues:
1.) Image stability issues (or why does my image keep curling up into fetal position and crying)
* upgrading an individual package can break your image bad and in unpredictable ways * package dependencies are difficult to identify resolve before you install * base Squeak image is too big, and while the community provided images are great, it can be hard to determine what one "needs" vs. "nice to have" * staying current is too dangerous, but without an obvious release schedule / road map it is difficult to know when to upgrade
2.) Documentation vs Reality (or what smalltalkers forgot to tell their children)
* documentation within core classes often missing and occasionally out of date * while source is easily readable and understandable, much of the WHY is missing * getting non-smalltalkers into the smalltalk culture is hard without a historical perspective * breaking bad habits of gang of 4 "design patterns" programmers is nearly impossible
3.) Process & Threading & UI issues (or how squeak is slow & ugly)
* it is way too easy to lockup the current scheduler & green threads implementation * UI responsiveness on a "fast" machine often leads to buggy clicking, typing issues * Fonts are incredibly fickle and obstinate :)
4.) Extending & Embedding (or how squeak doesn't play nice with others)
* there are tons of 3rd party libraries squeak can't interface to (that _____ already does) * it is more difficult to maintain and build a custom VM, plugin, compared to other interpreted languages (as I've done with Perl, Python, Ruby, Lua, Javascript, and Java) * many platform features on Linux / BSD / Mac OS X are difficult to take advantage of without custom extensions * hard to talk to actual hardware within Squeak
But none of these things are really the issue that kept it out of the running as the choice of tool. In fact these are all different problems from the prior years evaluations.
Assume for a second that I can convince a client that they don't need to worry about supporting the product, because that's the service I'm selling them. My biggest hurdle to using Squeak in a production environment isn't image management (it is easily scriptable), and it isn't version control (MC is wonderful), and it isn't the development tools (hey they're the selling point). My biggest problem isn't finding other programmers to train, or training them (I take it as a given that even experienced programmers need constant training).
My biggest problem is that it is too complex, and too difficult to reduce that complexity without breaking things.
When you build a project on top of Squeak, it is common practice to assume that Squeak is a layer of irreducible complexity, on top of which you are adding more complexity. Design decisions within that body of code, determine the applicability of every design decision you make about your actual application. And as soon as you are attempting to do something that is non-trivial for Squeak, you find yourself in a strange sea where dragons lurk behind every wave.
Part of this problem is a historical accident, the smalltalk community in general relies heavily upon a shared cultural memory, as images beget images and layers of cruft get lost among the cobwebs. But a large part of this problem is a forgetfullness, where design decisions were made in a context, and as the context changed so too should have the design, but with the WHY lost, the change doesn't happen. Squeak needs a continuous refactoring. Odds are Alan Kay's goal of a 20k LOC system could be beaten easily by 10k if this were done.
A newcomer to Squeak looks at the incomprehensible class listings and asks herself "Do I really need this particular piece of junk", looks for an answer to "Why is this here", and is frustrated because often the answer to those questions has been forgotten (or is only held in someone else's head). Upgrading feel like Russian roulette because it is difficult to know how the changes will effect the system. And experimentation with making fundamental changes is equally frustrating as doing an engine change on car running down 101 during rush hour. From this perspective and experience Craig Latta's Spoon is an easier sell than a full Squeak release. The reason is simple, its a programmer's mantra: Less Code, Fewer Bugs, Lower cost.
Those are my 2 cents, lurking mode on.
Dave
Working mode off. Chatting mode on.
In short, the main issue is lack of modularity. As you may know this is one of the primary concerns of current board & release team. We have to deal with this, and deal nicely. Otherwise squeak will be buried under cruft of 'irreducible complexity'.
Smalltalk, by its nature does not defines a high-level abstractions which can be called 'module' or 'package'. In many other languages this concept included as basic one, while in Squeak we stick with an image-based concept, where image is a big monster with untamed complexity, where changing any piece of code could lead into breakage in unpredictable place(s), because everything is late bound.
I'm aware of at least two of module-based solutions for Squeak: - Spoon by Craig Latta - Namespaces by Michael van Der Gulik , as part of his SecureSqueak project
Both systems currently in development. And almost 99% it is solo development by their authors. Both systems having own pros and cons , and it's hard to decide (as for me), which is better for the future of Squeak.
Why we don't see these systems already employed? Currently we have so-called 'status-quo'.
I think , the main problem is more social than lack of manpower or funding: There is no high pressure from squeak community (and nobody having an ultimate power to force it) to abandon obsolete concepts, sacrifice ST-80 compatibility (partly) and move forward with system based on better design & modularity.
Chatting mode off. Working mode on.
On Apr 7, 2008, at 6:19 PM, Igor Stasenko wrote:
I think , the main problem is more social than lack of manpower or funding: There is no high pressure from squeak community (and nobody having an ultimate power to force it) to abandon obsolete concepts, sacrifice ST-80 compatibility (partly) and move forward with system based on better design & modularity.
That's an interesting observation. A lot of the popular scripting languages that move forward in sudden bursts are the ones with de- facto heads of state such as Larry Wall or Guido von Rossum. These are people who are in a position to announce to the entire community that the next version is going down such-and-such path and that is simply the way it is because their language is defined by their personality, to some extent.
As an outsider, I see Squeak seeming to be trying to function under an ideal democratic model where there's really no leadership at all. Unfortunately, you can't please everyone all the time and expect any changes to occur. Historically, you often need a single or small group of focused radicals in a position of power to effect change - for better or worse. The board could be that group of radicals by doing things like getting together and redefining what "Squeak" actually means. What it includes in an image. What it looks like. How you use it. They can do this by refusing any and all changes that do not further that new definition and by providing a quick path to remove code but a slow one to add it. Actions like that could cause tensions and ultimately Squeak may fork - or a new board gets elected - but maybe that's okay, too. They will have tried. The board could take the initiative and fork themselves starting a "Squeak Classic" branch and redefining what "Squeak" means now and into the future as the "main" branch without having to hurt too many people's feelings along the way.
l8r Sean
I think there is a bit of a logical problem here ins that if the system *didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down
On Mon, Apr 7, 2008 at 8:02 PM, tim Rowledge tim@rowledge.org wrote:
I think there is a bit of a logical problem here ins that if the system *didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
I'd prefer this logical problem be solved by moving as much junk as is practically possible out of the base image(s), but make it trivial to find and load them back in. Half that battle is in the finding. Right now, I can imagine that it's difficult for many people to tell the most useful stuff that's out there. Maybe the board or some other body could build a consensus top 20 downloads (for a newbie developer audience at first), give them prominence in the image, and make sure the load ok in the base image(s), that would be a good start. Eventually, maybe we could make it so that certain things can be triggered to get loaded automatically (I can imagine for example that turning on syntax highlighing could be made to load Shout automatically).
- Stephen
El 4/8/08 6:15 PM, "Stephen Pair" stephen@pairhome.net escribió:
I'd prefer this logical problem be solved by moving as much junk as is practically possible out of the base image(s), but make it trivial to find and load them back in. Half that battle is in the finding. Right now, I can imagine that it's difficult for many people to tell the most useful stuff that's out there. Maybe the board or some other body could build a consensus top 20 downloads (for a newbie developer audience at first), give them prominence in the image, and make sure the load ok in the base image(s), that would be a good start. Eventually, maybe we could make it so that certain things can be triggered to get loaded automatically (I can imagine for example that turning on syntax highlighing could be made to load Shout automatically).
- Stephen
Stephen:
Very happy talented Squeaker said same I saying for a while in good English.
Now , who is against this and vote for not start 3.11 ?
Monday meetings with Pavel, Craig, Matthew and a lot more could focus on license and 4.0, so all could win.
Edgar
Stephen Pair wrote:
On Mon, Apr 7, 2008 at 8:02 PM, tim Rowledge <tim@rowledge.org mailto:tim@rowledge.org> wrote:
I think there is a bit of a logical problem here ins that if the system *didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.I'd prefer this logical problem be solved by moving as much junk as is practically possible out of the base image(s), but make it trivial to find and load them back in. Half that battle is in the finding. Right now, I can imagine that it's difficult for many people to tell the most useful stuff that's out there. Maybe the board or some other body could build a consensus top 20 downloads (for a newbie developer audience at first), give them prominence in the image, and make sure the load ok in the base image(s), that would be a good start.
There are now two mechanisms for doing this, Universes and Sake/Packages. (see Sake, and Packages on Squeaksource)
The idea of Sake/Packages is that an image includes a class which lists methods for loading all of the other packages, including their dependencies. Much the same as Universes, but it is simpler to use and maintain since it doesnt have any the dependence upon a server, or a UI.
Installer provides command line front end to both.
Eventually, maybe we could make it so that certain things can be triggered to get loaded automatically (I can imagine for example that turning on syntax highlighing could be made to load Shout automatically).
- Stephen
best regards
Keith
Perhaps a friendly "wizard" upon stating of the fresh image may be appropriate. It could use Universes, perhaps, a meta-universe of high-level choices ("have fun" "develop" etc.).
Gary -----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]On Behalf Of Stephen Pair Sent: 08 April 2008 10:15 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] What turns off newcomers
On Mon, Apr 7, 2008 at 8:02 PM, tim Rowledge tim@rowledge.org wrote:
I think there is a bit of a logical problem here ins that if the system *didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
I'd prefer this logical problem be solved by moving as much junk as is practically possible out of the base image(s), but make it trivial to find and load them back in. Half that battle is in the finding. Right now, I can imagine that it's difficult for many people to tell the most useful stuff that's out there. Maybe the board or some other body could build a consensus top 20 downloads (for a newbie developer audience at first), give them prominence in the image, and make sure the load ok in the base image(s), that would be a good start. Eventually, maybe we could make it so that certain things can be triggered to get loaded automatically (I can imagine for example that turning on syntax highlighing could be made to load Shout automatically).
- Stephen
Gary Chambers wrote:
Perhaps a friendly "wizard" upon stating of the fresh image may be appropriate. It could use Universes, perhaps, a meta-universe of high-level choices ("have fun" "develop" etc.).
"have fun" should be enabled by default, right now it seems to be disabled ;-)
Michael
I understand entirely ;-)
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]On Behalf Of Michael Rueger Sent: 08 April 2008 10:55 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] What turns off newcomers
Gary Chambers wrote:
Perhaps a friendly "wizard" upon stating of the fresh image may be appropriate. It could use Universes, perhaps, a meta-universe of high-level choices ("have fun" "develop" etc.).
"have fun" should be enabled by default, right now it seems to be disabled ;-)
Michael
On Tue, 2008-04-08 at 23:54 +0200, Michael Rueger wrote:
Gary Chambers wrote:
Perhaps a friendly "wizard" upon stating of the fresh image may be appropriate. It could use Universes, perhaps, a meta-universe of high-level choices ("have fun" "develop" etc.).
"have fun" should be enabled by default, right now it seems to be disabled ;-)
Do you know how to enable it again? It seems to have disappeared from the Preferences completely. :)
Norbert
On 07.04.2008, at 17:02, tim Rowledge wrote:
I think there is a bit of a logical problem here ins that if the system *didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
IMHO in other systems the 'junk' is simply not that much in-your-face as in the SystemBrowser. It's hidden in library code that you never look at except for its documented API.
- Bert -
On 8-Apr-08, at 3:09 PM, Bert Freudenberg wrote:
On 07.04.2008, at 17:02, tim Rowledge wrote:
I think there is a bit of a logical problem here ins that if the system *didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
IMHO in other systems the 'junk' is simply not that much in-your- face as in the SystemBrowser. It's hidden in library code that you never look at except for its documented API.
Interesting way of looking at it. Perhaps it might be sensible to have a browser for typical use that shows much less detail of the 'kernel' classes so as to cause less fear and concern for less experienced developers. We did something along those lines for LearningWorks with reasonable success.
We'd need to actually *have* a 'documented API' of course....
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDL: Shift Disk Left
On 8-Apr-08, at 3:09 PM, Bert Freudenberg wrote:
On 07.04.2008, at 17:02, tim Rowledge wrote:
I think there is a bit of a logical problem here ins that if the system
*didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
IMHO in other systems the 'junk' is simply not that much in-your-face as
in the SystemBrowser. It's hidden in library code that you never look at except for its documented API.
Interesting way of looking at it. Perhaps it might be sensible to have a browser for typical use that shows much less detail of the 'kernel' classes so as to cause less fear and concern for less experienced developers. We did something along those lines for LearningWorks with reasonable success.
+1
On Apr 8, 2008, at 6:03 PM, cdrick wrote:
On 8-Apr-08, at 3:09 PM, Bert Freudenberg wrote:
On 07.04.2008, at 17:02, tim Rowledge wrote:
I think there is a bit of a logical problem here ins that if the system
*didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
IMHO in other systems the 'junk' is simply not that much in-your- face as
in the SystemBrowser. It's hidden in library code that you never look at except for its documented API.
Interesting way of looking at it. Perhaps it might be sensible to have a browser for typical use that shows much less detail of the 'kernel' classes so as to cause less fear and concern for less experienced developers. We did something along those lines for LearningWorks with reasonable success.
+1
I hate to add more noise to this, but +1 from me, too. It'd be interesting if the entire initial Squeak image UI could be made to feel more like a "traditional" language IDE by default where you primarily see *your* project code/classes with everything else available by more indirect means.
l8r Sean
Hello Sean,
SH> I hate to add more noise to this, but +1 from me, too. It'd be SH> interesting if the entire initial Squeak image UI could be made to SH> feel more like a "traditional" language IDE by default where you SH> primarily see *your* project code/classes with everything else SH> available by more indirect means.
you would need Tric Refactoring Browser by Cees DeGroot which starts empty. "Find class" adds all classes of that classes category and right clicking on a category brings "hide this category" and "hide all" menu options.
I'm on 3.8 and can't tell if the switch to OB might stop this feature. This and the tracing messages browser from Chris Muller (hierarchical cross class view of an algorithm in a single window) help me to get up to speed with projects I had to abandon for a month or two.
Cheers,
Herbert
Hello Sean,
SH> I hate to add more noise to this, but +1 from me, too. It'd be SH> interesting if the entire initial Squeak image UI could be made to SH> feel more like a "traditional" language IDE by default where you SH> primarily see *your* project code/classes with everything else SH> available by more indirect means.
you would need Tric Refactoring Browser by Cees DeGroot which starts empty. "Find class" adds all classes of that classes category and right clicking on a category brings "hide this category" and "hide all" menu options.
I'm on 3.8 and can't tell if the switch to OB might stop this feature. This and the tracing messages browser from Chris Muller (hierarchical cross class view of an algorithm in a single window) help me to get up to speed with projects I had to abandon for a month or two.
Actually, there is OB-Enhancement that helps in that respect.
If you have the last squeak-dev and squeak web... Try Smart Group Browser (open menu or first iconic button).
David is the guy who do this browser. I'm sure he'd love more feedback ;) It combines a package view (with associated MC commands) and a group view (there is a switch) called smart group, that does the same as the Tric Refractoring browser.
You should give a try. Only problem is it feels a bit slow, but I really like using it. You can create new groups and then add nearly whatever you want in it (classes, packages, class categories, method, etc...) + there is a group for the results of classes search from the upper entry (try typin Coll*Tes in the mercury panel, and go to smart group.
I use it nearly all the time, even if a bit slow somtimes but this is work in progress...
Cheers,
Cédrick
ps: but still, hiding some 'squeak mecanics' to the average user would be a good thing...
2008/4/9 tim Rowledge tim@rowledge.org:
On 8-Apr-08, at 3:09 PM, Bert Freudenberg wrote:
On 07.04.2008, at 17:02, tim Rowledge wrote:
I think there is a bit of a logical problem here ins that if the system
*didn't* have 'all that junk' the immediate result would be complaints that 'it doesn't have all that useful stuff like other systems'.
IMHO in other systems the 'junk' is simply not that much in-your-face as
in the SystemBrowser. It's hidden in library code that you never look at except for its documented API.
Interesting way of looking at it. Perhaps it might be sensible to have a browser for typical use that shows much less detail of the 'kernel' classes so as to cause less fear and concern for less experienced developers. We did something along those lines for LearningWorks with reasonable success.
We'd need to actually *have* a 'documented API' of course....
This, i think, could be achieved by introducing a some kind of view-sets, where developer can choose sets of classes/packages visible by browser. Sometimes(All the time) its more convenient to work only with particular set of classes, so all commands like senders/implementors/references etc will use only given set for searching. Btw, this was discussed previously.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDL: Shift Disk Left
"Sean" == Sean Heber sean@fifthace.com writes:
Sean> Historically, you often need a single or small group of focused radicals Sean> in a position of power to effect change - for better or worse. The Sean> board could be that group of radicals by doing things like getting Sean> together and redefining what "Squeak" actually means. What it includes Sean> in an image. What it looks like. How you use it.
Oddly enough, that's my vision for the SqF board as well. And I'm on it. I believe there needs to be a clear focus, and I'll be working to ensure that the board provides the focus.
2008/4/8 Randal L. Schwartz merlyn@stonehenge.com:
"Sean" == Sean Heber sean@fifthace.com writes:
Sean> Historically, you often need a single or small group of focused radicals Sean> in a position of power to effect change - for better or worse. The Sean> board could be that group of radicals by doing things like getting Sean> together and redefining what "Squeak" actually means. What it includes Sean> in an image. What it looks like. How you use it.
Oddly enough, that's my vision for the SqF board as well. And I'm on it. I believe there needs to be a clear focus, and I'll be working to ensure that the board provides the focus.
Count me in :)
As another observation: we should determine somehow the boundaries which should not be crossed and change dev tools to warn developer when he crossing these boundaries. One of most powerful patterns in smalltalk, that we can extend behavior of base classes like Object or ProtoObject. It is good when you just add few new methods, the chance that your extension will conflict with another package is minimal. But when you going to override methods or restructure classes(by adding/removing vars), things getting worser and worser. Sometimes it is impossible to include a nice workaround or extension without overriding methods in base(or any other) classes so, ability to redefine behavior of basic classes should be preserved. But from the moment when someone needs to change/extend basic things we getting into trouble of names/versions conflicts when using package in different images/environment. This issue, i think, is the main reason why forks appear. And fork is something which i think is most nasty thing which happens during development. It leads to fragmentation of developers community, user base, prevents exchange ideas/improvements and many other things which i missed :)
If we want Squeak to gain more popularity and flourish, we should make sure that in future versions a chance of fork will be minimal. And minimal chance should mean, that developer should have such image/tools with which he don't needs to make any forks, and be sure that his application will work rock solid under any circumstances in any Squeak environment.
Le lundi 07 avril 2008 à 17:04 -0700, Randal L. Schwartz a écrit :
"Sean" == Sean Heber sean@fifthace.com writes:
Sean> Historically, you often need a single or small group of focused radicals Sean> in a position of power to effect change - for better or worse. The Sean> board could be that group of radicals by doing things like getting Sean> together and redefining what "Squeak" actually means. What it includes Sean> in an image. What it looks like. How you use it.
Oddly enough, that's my vision for the SqF board as well. And I'm on it. I believe there needs to be a clear focus, and I'll be working to ensure that the board provides the focus.
I am tempted to think SqF board should not be afraid to choose direction leading to incompatibility in the API, especially for a better Squeak providing solution to large Squeak community user. Project like Gnome broke API several time, some lib becoming obsolete, but Gnome is very successful and developers of Gnome applications get used to port their application to new API.
Hilaire
I am tempted to think SqF board should not be afraid to choose direction leading to incompatibility in the API, especially for a better Squeak providing solution to large Squeak community user. Project like Gnome broke API several time
At the binary level, they did so only once, with the second being planned. The first digit in the version number identifies the ABI version.
That said, I agree with you.
Paolo
Paolo Bonzini a écrit :
I am tempted to think SqF board should not be afraid to choose direction leading to incompatibility in the API, especially for a better Squeak providing solution to large Squeak community user. Project like Gnome broke API several time
At the binary level, they did so only once, with the second being planned. The first digit in the version number identifies the ABI version.
That said, I agree with you.
Well I did experience it with DrGeo with Gnome MDI library becoming obsolete. Then I ported to GTK+ only libs.
Hilaire
"Hilaire" == Hilaire Fernandes hilaire@ofset.org writes:
Hilaire> I am tempted to think SqF board should not be afraid to choose direction Hilaire> leading to incompatibility in the API, especially for a better Squeak Hilaire> providing solution to large Squeak community user.
I wouldn't categorize it as "afraid" as much as "must weigh the cost/benefit ratio", if you'll forgive me for sounding like a manager for a moment.
I'm for optimizing Squeak... if the benefits clearly outweigh the costs. Even if that means more formal forks of Squeak, such as has already happened with OpenCroquet.
On Tue, Apr 8, 2008 at 11:19 AM, Igor Stasenko siguctua@gmail.com wrote:
I'm aware of at least two of module-based solutions for Squeak:
- Spoon by Craig Latta
- Namespaces by Michael van Der Gulik , as part of his SecureSqueak
project
Both systems currently in development. And almost 99% it is solo development by their authors. Both systems having own pros and cons , and it's hard to decide (as for me), which is better for the future of Squeak.
FWIW, "SecureSqueak" isn't going to be the future of Squeak; it's going to be a fork. It's going to be too different from Squeak to be a good candidate for a future version.
Gulik.
2008/4/8 Michael van der Gulik mikevdg@gmail.com:
On Tue, Apr 8, 2008 at 11:19 AM, Igor Stasenko siguctua@gmail.com wrote:
I'm aware of at least two of module-based solutions for Squeak:
- Spoon by Craig Latta
- Namespaces by Michael van Der Gulik , as part of his SecureSqueak
project
Both systems currently in development. And almost 99% it is solo development by their authors. Both systems having own pros and cons , and it's hard to decide (as for me), which is better for the future of Squeak.
FWIW, "SecureSqueak" isn't going to be the future of Squeak; it's going to be a fork. It's going to be too different from Squeak to be a good candidate for a future version.
Yes, if you read my latest post in this thread about forks. Isn't it would be better to make fork become Squeak in that way? ;) I don't want to repeat myself, but do you think it wouldn't be better to incorporate module-based system in Squeak release? Because if not, then obviously Squeak community will be forked as well. Is there a way to put stop on this? Can we make a system which will make need of forking unnecessary?
Gulik.
http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/
On Tue, Apr 8, 2008 at 2:01 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/4/8 Michael van der Gulik mikevdg@gmail.com:
On Tue, Apr 8, 2008 at 11:19 AM, Igor Stasenko siguctua@gmail.com
wrote:
I'm aware of at least two of module-based solutions for Squeak:
- Spoon by Craig Latta
- Namespaces by Michael van Der Gulik , as part of his SecureSqueak
project
Both systems currently in development. And almost 99% it is solo development by their authors. Both systems having own pros and cons , and it's hard to decide (as for me), which is better for the future of Squeak.
FWIW, "SecureSqueak" isn't going to be the future of Squeak; it's going
to
be a fork. It's going to be too different from Squeak to be a good
candidate
for a future version.
Yes, if you read my latest post in this thread about forks. Isn't it would be better to make fork become Squeak in that way? ;) I don't want to repeat myself, but do you think it wouldn't be better to incorporate module-based system in Squeak release? Because if not, then obviously Squeak community will be forked as well. Is there a way to put stop on this? Can we make a system which will make need of forking unnecessary?
I think DeltaStreams has a lot of potential to keep the various forks of Squeak together. At some stage I'll investigate whether it can be integrated into Namespaces. If this works well, it would be the best way to share bug fixes with each other.
I also think that forking the community should be encouraged. The " squeak.org image" should be a minimal lowest-common-denominator image, which others take and, by adding packages, make into a variety of images for various uses, such as Squeak-Dev or FunSqueak. For now, MC does an adequate job[1].
One of the reasons that it is unlikely that my Namespaces implementation will be able to be part of the squeak.org image is because I plan to do away with the "Smalltalk" SystemDictionary and reorganise everything into individual, live Packages, each containing hierarchies of Namespaces and Classes. The community here would never agree to such a radical change.
[1] You currently can't load my NamespaceTools package from the package universe browser because MC has trouble redefining instance variables in some of the ToolBuilder packages. It works if you recompile several classes.
Gulik.
"Michael" == Michael van der Gulik mikevdg@gmail.com writes:
Michael> One of the reasons that it is unlikely that my Namespaces Michael> implementation will be able to be part of the squeak.org image is Michael> because I plan to do away with the "Smalltalk" SystemDictionary and Michael> reorganise everything into individual, live Packages, each containing Michael> hierarchies of Namespaces and Classes. The community here would never Michael> agree to such a radical change.
I'm jumping in here only partially informed, but I know Cincom has a namespace mechanism. Is your framework similar, perhaps even compatible? And would there be a reasonable way to file in legacy classes into such a new system?
Refactoring and bringing new modules online takes a lot of time and effort. In this present climate such effort is wasted if it is only directed towards some future squeak, since most squeakers are using something other than the latest squeak.
Take Rio for example, which has gained some fans, it has been available for over a year now, and is about ready for an api review. For rio to become accepted, I would expect ensure that it loads in OLPC, Croquet, 3.7+, I would expect it to take up to 4 years for FileDirectory to expire!
Keith
Take Rio for example, which has gained some fans, it has been available for over a year now, and is about ready for an api review.
Count me in for that, as I just reimplemented parts of Rio in GNU Smalltalk (in the sense that I looked at the API document on Squeak and refactored the code in GST to obey that API). I only implemented the basic parts + ZIP access (no recursion yet, no renaming yet), but I do have some ideas on what's nice and what's less nice.
Paolo
On Apr 7, 2008, at 5:15 PM, David J. Goehrig wrote:
When you build a project on top of Squeak, it is common practice to assume that Squeak is a layer of irreducible complexity, on top of which you are adding more complexity. Design decisions within that body of code, determine the applicability of every design decision you make about your actual application. And as soon as you are attempting to do something that is non-trivial for Squeak, you find yourself in a strange sea where dragons lurk behind every wave.
(snip)
A newcomer to Squeak looks at the incomprehensible class listings and asks herself "Do I really need this particular piece of junk", looks for an answer to "Why is this here", and is frustrated because often the answer to those questions has been forgotten (or is only held in someone else's head). Upgrading feel like Russian roulette because it is difficult to know how the changes will effect the system. And experimentation with making fundamental changes is equally frustrating as doing an engine change on car running down 101 during rush hour. From this perspective and experience Craig Latta's Spoon is an easier sell than a full Squeak release. The reason is simple, its a programmer's mantra: Less Code, Fewer Bugs, Lower cost.
For what it's worth, as a long time lurker and essentially a non-user myself with a background in "traditional" languages, these two passages nearly completely nailed how I feel about Squeak and the idea of using Squeak as it exists now. I couldn't have said it better myself - and I've tried. :-)
l8r Sean
On Monday 07 April 2008 16:36:29 Sean Heber wrote:
For what it's worth, as a long time lurker and essentially a non-user myself with a background in "traditional" languages, these two passages nearly completely nailed how I feel about Squeak and the idea of using Squeak as it exists now. I couldn't have said it better myself - and I've tried. :-)
I've already been through a lot of this. What -seems- like it should be relatively easy is apparently very difficult, like creating an image from scratch or getting some one to help do it so I can learn. Nobody seems to want to take the time. I'm still interested in using Squeak for Robotics, but it isn't anywhere near usable for that yet - not enough access to low level hardware for embedded system use.
8-Dale
Hi--
Great list, David! Thanks for writing that. I would love to get my hands on any failing tests you might have, so as to get into specifics.
Igor writes:
Smalltalk, by its nature does not defines a high-level abstractions which can be called 'module' or 'package'.
I don't think doing so goes against the nature of the system, it seems to me that the designers just didn't get around to it (another one for the "historical accidents" category). In particular, I don't think having an object memory model and having high-level abstractions for modules are in conflict.
I'm aware of at least two of module-based solutions for Squeak:
- Spoon by Craig Latta
- Namespaces by Michael van Der Gulik , as part of his SecureSqueak
project
Both systems currently in development. And almost 99% it is solo development by their authors.
That doesn't surprise me in the case of Spoon, since enabling team development is the goal. It has to get to a certain usable place first, although I do think other developers could come in sooner, if we could work in person until it gets to that place.
Why we don't see these systems already employed?
Well, Spoon isn't ready today. I'm spending Mondays working on a 2008-06-20 release. I'm working on the history system now (an object-memory-based replacement for the changes and sources files). For more details, please participate on the Spoon mailing list (also available via NNTP as [1]), or on IRC in channel #spoon on irc.freenode.net. I just put out a call for history system use cases on the mailing list.
I think, the main problem is more social than lack of manpower or funding: There is no high pressure from squeak community (and nobody having an ultimate power to force it) to abandon obsolete concepts, sacrifice ST-80 compatibility (partly) and move forward with system based on better design & modularity.
Personally, as a board member I'd like to lead in that direction and just give someone else a turn next year if nobody follows. :)
thanks again,
-C
[1] nntp://news.gmane.org/gmane.comp.lang.smalltalk.squeak.spoon
-- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
On Tue, 08 Apr 2008 00:15:39 +0200, David J. Goehrig wrote:
Andreas Wacknitz wrote:
And many of the newcomers get alienated by many aspects of Squeak: - it is hard to find documentation - it is hard to get used to Morphic (its power isn't obvious but its clutter is) - it is hard to find a Squeak version with not so many obvious bugs and problems
Long time lurker here,
Short answer: (For those who don't want to read the post)
Newcomers are turned off by seemingly irreducible complexity of the system; Squeak need continual refactoring.
...
May I add, w.r.t. the menu item position of "remove (x)" in the other thread. For me as an oldtimer there are only two rules, a] + b], for arranging menu items:
a] productivity 1 - adding a new category, class, method, has more productive than anything else 2 - finding a thing you know how to spell 3 - searching for a thing you don't know how to spell 4 - copy,cut,paste & doIt,printIt & other sub-tools 5 - organizing your work (rename, etc) 6 - removing the unwanted
b] the divine words of the goods of our language, for example the arrangement of the menu items found in the text editor pane (Transcript or Workspace); they do define the default resp. overrule a].
Rule b] has importance when you consider all the publications, tutorials, etc, in which menu items are mentioned and/or documented. I think that the position of menu items must be as-consistent-as-possible accross all available tools, otherwise the newcomers won't feel comfortable.
------------
That is not to say that there should be no customization possible for the user but, I haven't seen any.
------------
Please do not hesitate and post your suggestions and observations with menu item positions.
/Klaus
Please do not hesitate and post your suggestions and observations with menu item positions.
/Klaus
Then here is mine: Smalltalk has excellent heuristics scoring by design probably one of the best at programing level but IMHO we seriusly need help of designer/s who understand about usability and UI design and we need to hear their opinions to see where to start stating priorities.
This is *a must* lecture, to be made slow and consciously, for any developer whom may build a interface for any piece of software no matter the technology or medium (web, desktop, mobile, etc): http://www.useit.com/papers/heuristic/heuristic_list.html http://www.asktog.com/basics/firstPrinciples.html
About the menus I think they have to be reviewed so they demostrate respect to this basic design principles.
The goal must be no other than the analogous psychological effect of entering in a shopping center (or any clean and safe environment) where you can read, watch, consume and produce ideas (automated thoughts aka software).
I understand the size of the challenge but that does not invalidates the fact squeak has a lot to improve in the field of usability.
cheers,
Sebastian Sastre
On Fri, 11 Apr 2008 23:38:14 +0200, Sebastian Sastre wrote:
Please do not hesitate and post your suggestions and observations with menu item positions.
/Klaus
Then here is mine: Smalltalk has excellent heuristics scoring by design probably one of the best at programing level but IMHO we seriusly need help of designer/s who understand about usability and UI design and we need to hear their opinions to see where to start stating priorities.
This is *a must* lecture, to be made slow and consciously, for any developer whom may build a interface for any piece of software no matter the technology or medium (web, desktop, mobile, etc):
http://www.useit.com/papers/heuristic/heuristic_list.html http://www.asktog.com/basics/firstPrinciples.html
About the menus I think they have to be reviewed so they demostrate respect to this basic design principles.
The goal must be no other than the analogous psychological effect of entering in a shopping center (or any clean and safe environment) where you can read, watch, consume and produce ideas (automated thoughts aka software).
A good idea but, design by psychological "rationale" is too far away from my everyday's work (though I *love* psychedelic art :)
How about starting with a MenuItemsAndLists Customizer tool, for the hands of UI designers, the model of which every tool must be conformant to ?
I understand the size of the challenge but that does not invalidates the fact squeak has a lot to improve in the field of usability.
cheers,
Sebastian Sastre
The goal must be no other than the analogous psychological effect of
entering in a shopping center (or any clean and safe environment) where
you can
read, watch, consume and produce ideas (automated thoughts aka software).
A good idea but, design by psychological "rationale" is too far away from my everyday's work (though I *love* psychedelic art :)
How about starting with a MenuItemsAndLists Customizer tool, for the hands of UI designers, the model of which every tool must be conformant to ?
Most probably tools will be useful, but be cautious on doing something too early. My previous email was intentionally wrote to sensibilize about the lack of bird's eye about usability. We need more Squeakers (that's us) to be conscious and aware of the big picture of the issue before stating priorities and investing efforts.
In the usability subject I see some improvments in the rigth direction: the OmniBrowser-Full(0.25) and eCompletion, shout, and refactory. That's why the public have an inclination to choose Squeak "distros" of Damien C. or Ramon L. they want to consume "one click experiences".
If more authors are aware of how to *build* usability we will found N more usability gems like (just to mention one) the #flag: message. Observe its effect in detail: such a simple feature, which draws a little icon on a method, can be the fundation of better comunicability among Squeak developers working on a common project thousands kms/miles away. Have in mind they may be unable to seat face to face to quickly discuss and set next steps and this is a great palliation for that problem. Sounds familiar?
And speculating about which consequences will have a Squeak with a high score in usability I can't see other but benefits for all: squeakers, squeaker users, the smalltalk community, smalltalk newcomers and finally the industry. It's an all win situation and is not necessarily onerous.
In short all I'm saying is maybe usability is being underestimated by us and if we reflect on this **I'm absolutely confident** we will find the way to do better. Usability can be constructed and we know how to construct things because we where attracted by a machine useful to invent the future.
cheers,
Sebastian
Sebastian Sastre wrote:
The goal must be no other than the analogous psychological effect of entering in a shopping center (or any clean and safe environment) where you can read, watch, consume and produce ideas (automated thoughts aka software).
Good idea - but you need to choose which shopping center you want to look like (if not behave like, in certain aspects at least).
So, what is going to be the role model? Eclipse/Netbeans? Another Smalltalk (Dolphin, VSE, VAST, VW, ST/X) IDE?
I would say Eclipse, for its probably the most commonly used IDE.
Speaking of IDE - I am using Seaside together with a WebDev Image, and there is one thing that bothers me. In the standard OBSystemBrowser, if you go to the variables tab, you get the variables browser. Then you add an instance variable, the pane is refreshed. If you add the accessor methods, it is not refreshed, i.e. there is no control refresh after the model update. I tried to find where that might be but failed, unfortunately :(
Anyhow, keep up the good work, Squeak is really nice.
Cheers,
Claus
squeak-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
Andreas Raab -
Andreas Wacknitz -
Andres Valloud -
Bert Freudenberg -
cdrick -
Claus Kick -
Craig Latta -
Dale Weber -
David J. Goehrig -
Derek O'Connell -
Edgar J. De Cleene -
Esteban Lorenzano -
Gary Chambers -
Giovanni Corriga -
Herbert König -
Hilaire Fernandes -
Igor Stasenko -
Janko Mivšek -
Jason Johnson -
John M McIntosh -
karl -
Keith Hodges -
kengbrown -
Klaus D. Witzel -
Matthew Fulmer -
merlyn＠stonehenge.com -
Michael Rueger -
Michael van der Gulik -
Norbert Hartl -
Paolo Bonzini -
Sean Heber -
Sebastian Sastre -
Stephen Pair -
Stéphane Rollandin -
tim Rowledge