I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script- like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
--- Mark Volkmann
On Fri, Nov 21, 2008 at 12:02 PM, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
I'd like to ask how Ruby on Rails got so popular, and what makes it different from Squeak?
Gulik.
Rails is a web framework. Did you mean Seaside?
On Thu, Nov 20, 2008 at 5:24 PM, Michael van der Gulik mikevdg@gmail.com wrote:
On Fri, Nov 21, 2008 at 12:02 PM, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
I'd like to ask how Ruby on Rails got so popular, and what makes it different from Squeak?
Gulik.
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/
-----Mensaje original----- En nombre de Michael van der Gulik
On Fri, Nov 21, 2008 at 12:02 PM, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them?Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
I'd like to ask how Ruby on Rails got so popular, and what makes it
different from Squeak?
Gulik.
Something to consider is that Ruby enthusiast are happy to say aloud that they are using Ruby. But big players keep under tight secret what they consider a key advantage over it's competitors. Even making it's vendors sing not to tell anybody. We (me and my smalltalk friends developers) always suspected that. Now I know. I you've been at Smalltalks 2008 (Argentina), You now know too ;)
Cheers.
Emilio
Most of the things that make Smalltalk great (what makes Smalltalk Smalltalk) are the things that hold it back for a lot of people.
If you want a more Unixy, scripty, Smalltalkish thing with syntax blended C and Perl that you can hack with a text editor, try Ruby.
If you want objects all the time with a crazy amount of integration in the tools and little attempt at conforming to outside ideas, Smalltalk is your game.
On Thu, Nov 20, 2008 at 5:02 PM, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
Mark Volkmann
On Nov 20, 2008, at 5:28 PM, David Mitchell wrote:
Most of the things that make Smalltalk great (what makes Smalltalk Smalltalk) are the things that hold it back for a lot of people.
Maybe I'm naive on this, but it seems like it should be easy convince lots of people that Smalltalk has a beautiful syntax and a wonderful development environment.
If you want a more Unixy, scripty, Smalltalkish thing with syntax blended C and Perl that you can hack with a text editor, try Ruby.
I think this depends on how we define "scripty". I take that to mean quick, short, one off programs. I personally use Ruby for that today. However, I'd like to be able to use Squeak when things get a little bigger. For example, suppose I want to run an application every night that queries a database, produces some text report and emails it to several people. I don't see any reason why those kinds of applications should be difficult to write and deploy using Squeak, but they seem pretty difficult to me today because I can't get the headless stuff to work.
If you want objects all the time with a crazy amount of integration in the tools and little attempt at conforming to outside ideas, Smalltalk is your game.
On Thu, Nov 20, 2008 at 5:02 PM, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
Mark Volkmann
--- Mark Volkmann
On Thu, 20 Nov 2008 17:36:06 -0600, Mark Volkmann mark@ociweb.com wrote:
I don't see any reason why those kinds of applications should be difficult to write and deploy using Squeak, but they seem pretty difficult to me today because I can't get the headless stuff to work.
What problems are you having? I run Squeak headless all the time on my robots...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
Let me just say that "scripty" doesn't have to be antithetical to Smalltalk.
If I had a Smalltalk Apache module that I could plug in to handle various requests, and still log in to as a live image? That'd be better than any scripting language.
The modularity point is a good one along the same lines: I love the image, I just want it not to be isolated.
As for GPL-tainted stuff, that shouldn't affect someone who's just =using= the product, right? (I'm not but I've been thinking about it.) Unless one digs into the source code, one should be fine, yes?
On 21.11.2008, at 00:36, Mark Volkmann wrote:
On Nov 20, 2008, at 5:28 PM, David Mitchell wrote:
Most of the things that make Smalltalk great (what makes Smalltalk Smalltalk) are the things that hold it back for a lot of people.
Maybe I'm naive on this, but it seems like it should be easy convince lots of people that Smalltalk has a beautiful syntax and a wonderful development environment.
Maybe you are naive ;)
I think David nailed it.
Smalltalk is powerful precisely because it is different than today's popular programming environments. The idea of a "live system" is too strange for the masses.
The thing with the popular languages is that they all are used in pretty much the same way - write source code in a file in an editor or IDE of your choice, build your program, run it, debug it, ship it. This makes it relatively easy to switch to a new language, it's basically just a different syntax and a change in the makefiles. You can easily replace parts of your project with pieces in another language. The SCM can work the same. You can continue to use the editor you know in your sleep.
All that makes switching to Smalltalk hard to do on your own, you basically need a team that has made the transition already. It also makes it hard to use for a little side project, because the initial overhead of new things to consider is so big. It makes it hard to find its place in the wider open-source community, which is becoming (or already is) the primary educational resource for new programmers.
But to cater to these wider audiences you would indeed have to strip Smalltalk of what makes it Smalltalk. It's been done of course, but what you end up with is not Smalltalk anymore.
- Bert -
Bert Freudenberg wrote:
Smalltalk is powerful precisely because it is different than today's popular programming environments. The idea of a "live system" is too strange for the masses.
The thing with the popular languages is that they all are used in pretty much the same way - write source code in a file in an editor or IDE of your choice, build your program, run it, debug it, ship it. This makes it relatively easy to switch to a new language, it's basically just a different syntax and a change in the makefiles. You can easily replace parts of your project with pieces in another language. The SCM can work the same. You can continue to use the editor you know in your sleep.
While this still leaves the question, what is holding back "scripty" Smalltalks like GNU Smalltalk, one possibility is to build up an IDE similar to Squeak around a text-based Smalltalk: Using the existing sources, a "live system" containing the IDE classes and objects is built around them. Changed sources are propagated to the file system and vice versa.
Such a hybrid system (which perhaps has already been done - I don't know) would combine advantages from both worlds. A python scripter can still use text editors, a Smalltalk world user can still image based development (for instance, GNU ST also has image saving), while both work on the same system. This also (almost) solves the deployment issues in Squeak, like having to hide all IDE facilities from my end-users.
IMHO, if - and only *if* - the Smalltalk open source community wants to reach a wider range of possibile users, it has to open itself and take some step towards existing solutions, whether they might be inferior or not. This does not necessarily mean, to give up Smalltalk's special characteristics. For now, I see no reason why a Pythonist or Rubyist should completely throw away almost everything he has learnt about file-based software development in order to use an admittedly more expressive and powerful, but incomplete (where is my USB support? :( ) and unmodular system? Why does everything have to be replaced, like SCM, UI, editors...? Squeak does not have the manpower to provide bug-free tool-support for everything, which is BTW called "reinvention". I believe, things like "image as a file-system", SqueakSVN, SqueakGTK and similar projects are the right direction but still not enough...
Best regards, Martin
Some guys at IBM are working on exactly this. File-based Smalltalk under Eclipse.
Based on IBM Smalltalk, replacing Envy with CVS. Originally called project Black Knight and Wrath, I think it is now known by the more pedestrian Smalltalk Development Tools (stdt):
http://www.ibm.com/developerworks/blogs/page/stdt
It sounds to me like it is a hybrid system. There is an in-memory image but all of the tools work on the parallel source. The image isn't loaded on startup, though.
IBM uses it internally (sounded like one of the reasons was in producing the J9 Java VM, which makes sense historically). Someone from the team presented at a conference. It and a separate interview are both available from the Industry Misinterpretations podcast.
I believe there is an effort to open-source stdt, but I'm sure we can appreciate the complications of a task like that!
If Eclipse had support, I could see NetBeans might someday have support for Smalltalk. Tor Norbe made a joke about it on the Java Posse podcast after discussing Squeak on the JVM. There certainly are a lot of ex- and closet Smalltalkers at Sun. If Seaside gets enough buzz with the web developer community...
On Sat, Nov 22, 2008 at 5:40 AM, Martin Beck martin.beck@hpi.uni-potsdam.de wrote:
Bert Freudenberg wrote:
Smalltalk is powerful precisely because it is different than today's popular programming environments. The idea of a "live system" is too strange for the masses.
The thing with the popular languages is that they all are used in pretty much the same way - write source code in a file in an editor or IDE of your choice, build your program, run it, debug it, ship it. This makes it relatively easy to switch to a new language, it's basically just a different syntax and a change in the makefiles. You can easily replace parts of your project with pieces in another language. The SCM can work the same. You can continue to use the editor you know in your sleep.
While this still leaves the question, what is holding back "scripty" Smalltalks like GNU Smalltalk, one possibility is to build up an IDE similar to Squeak around a text-based Smalltalk: Using the existing sources, a "live system" containing the IDE classes and objects is built around them. Changed sources are propagated to the file system and vice versa.
Such a hybrid system (which perhaps has already been done - I don't know) would combine advantages from both worlds. A python scripter can still use text editors, a Smalltalk world user can still image based development (for instance, GNU ST also has image saving), while both work on the same system. This also (almost) solves the deployment issues in Squeak, like having to hide all IDE facilities from my end-users.
IMHO, if - and only *if* - the Smalltalk open source community wants to reach a wider range of possibile users, it has to open itself and take some step towards existing solutions, whether they might be inferior or not. This does not necessarily mean, to give up Smalltalk's special characteristics. For now, I see no reason why a Pythonist or Rubyist should completely throw away almost everything he has learnt about file-based software development in order to use an admittedly more expressive and powerful, but incomplete (where is my USB support? :( ) and unmodular system? Why does everything have to be replaced, like SCM, UI, editors...? Squeak does not have the manpower to provide bug-free tool-support for everything, which is BTW called "reinvention". I believe, things like "image as a file-system", SqueakSVN, SqueakGTK and similar projects are the right direction but still not enough...
Best regards, Martin
Mark Volkmann wrote:
On Nov 20, 2008, at 5:28 PM, David Mitchell wrote:
Most of the things that make Smalltalk great (what makes Smalltalk Smalltalk) are the things that hold it back for a lot of people.
Maybe I'm naive on this, but it seems like it should be easy convince lots of people that Smalltalk has a beautiful syntax and a wonderful development environment.
No it is not, most people will ask, "where are my {};".
If you want a more Unixy, scripty, Smalltalkish thing with syntax blended C and Perl that you can hack with a text editor, try Ruby.
I think this depends on how we define "scripty". I take that to mean quick, short, one off programs. I personally use Ruby for that today.
<aside>For me, thats Perl</aside>
However, I'd like to be able to use Squeak when things get a little bigger. For example, suppose I want to run an application every night that queries a database, produces some text report and emails it to several people.
Honestly, thats Perl for me, too, hence scripting.
I don't see any reason why those kinds of applications should be difficult to write and deploy using Squeak, but they seem pretty difficult to me today because I can't get the headless stuff to work.
I agree with you there, it is not really difficult. The headless issue however, might just be a minor Squeak problem, thats not really a Smalltalk issue.
What I use(d) Smalltalk for, was mostly GUI stuff (though I use SWT for that nowadays, at work at least) and applications having a large domain model behind. That is what you can use a high level language like Smalltalk for, in my opinion that is what it was meant for. I have done my fair share of "Scripting" in Smalltalk, and it is a pain when compared to the close integration of Perl with the OS APIs (especially on Unix).
What is holding Smalltalk back then (train of thought order only)?
- In my opinion, in part, licensing models - the crud which is called VB which is used to implement actual applications - the absence of a standard Smalltalk with a standard class hierarchy - Java and C# due to their huge amount of both useful and useless frameworks - Almost no one teaches Smalltalk (I was among the last of my university who learned Smalltalk)
Just my two cents.
Am 21.11.2008 um 19:23 schrieb Claus Kick:
[stuff deleted]
What is holding Smalltalk back then (train of thought order only)?
- In my opinion, in part, licensing models
- the crud which is called VB which is used to implement actual
applications
- the absence of a standard Smalltalk with a standard class hierarchy
- Java and C# due to their huge amount of both useful and useless
frameworks
- Almost no one teaches Smalltalk (I was among the last of my
university who learned Smalltalk)
I would go further. In my not so humble opinion many (if not most) programmers don't understand what object orientation is really about. Some are too stubborn, some are too lazy and some are too stupid. Most students were taught C languages and always think the way C works: procedural. When using C++, Java or C# (that's what I call C languages) they just put "class" around their procedural, data centric code. And they all seem to be in favour of complexity. I have no other explanation of why so many people like those languages. And with every new version these languages get more and more complex (like TR1 for C++). Sigh.
Regards Andreas
David Mitchell escreveu:
Most of the things that make Smalltalk great (what makes Smalltalk Smalltalk) are the things that hold it back for a lot of people.
If you want a more Unixy, scripty, Smalltalkish thing with syntax blended C and Perl that you can hack with a text editor, try Ruby.
If you want objects all the time with a crazy amount of integration in the tools and little attempt at conforming to outside ideas, Smalltalk is your game.
Some things that hold back smalltalk:
1. It was not supported by a media boosted corporation the way Java was in the 90ties. Today everybody knows that Java sucks. Everybody knows that with current technology (JVM) it is not possible to build large intensive Java applications (just study how the garbage collection works... what happens when you have to handle large data...). But Java got a good marketing while smalltalk and Self and other really interesting things were related as "geek things". 2. Smalltalk community was not able to create a really functional organization capable of delivering important things as standards and documentation. 3. Not taking into account the commercial versions of smalltalk that are supposed to satisfy small closed markets, the open versions like squeak never succeeded in releasing and maintaining "distributions" (like Linux) where all bundled parts are more or less assured to work properly with each other.
Much of the heat recently generated around smalltalk results from people perceptions about the dead-ends imposed by other programming models (like Java). With a little lucky it will attract investment and supporting infrastructure (money to pay for people doing the hard works of documenting things, establishing certain standards, testing & debugging, etc).
I think that one of the major drawbacks of smalltalk is its 80's implementation which offers 0 (zero) modularity. A smalltalk image is a universe, which contains everything. It can't be split on parts, you can't manage these parts to load/unload on demand. Everything is tightly welded together and sometimes, even if you want to get rid of some stuff - its very hard to do. Its like a painting ink - once you stepped into it once - you start leaving footprints everywhere. Its very good from one side, but not always: for a people working in contaminated areas, they need to pass a clean-up procedures to reduce the risk of bringing unwanted stuff into that environment. In smalltalk there is no such contaminated areas - you free to go everywhere and leave your footprints. Who cares? :) This is the problem: if people don't have a discipline and leaving stuff everywhere they think it good to be, then at the end we got a complete mess, no structure, no organization, just a half-working pieces spreaded across many places.
Also, even if organized well, projects can't grow bigger than certain amount, and at some point they become unmanageable, simply because no single man can hold so much information in his head to understand it and make some progress with it. At some point, you have to split your project on separate parts and delegate your work to other people. And also, make sure that these parts can evolve more or less independently. This is where fun begins: a smalltalk inherent implementation lacks modularity and offers nothing to you how to break things apart without losing consistency. Instead, it makes you addict in using globals everywhere and be careless about future :)
Another analogue: kids playing with lego puzzle. One kid puts one piece on top of another, then second puts some more pieces on top of it, and so on, then another kid came and realizes that if he replace the piece inside a construction it would be much more elegant. But at first attempt when he tries that, he breaks the whole construction :)
I hoping this will change in near future. Smalltalk syntax is the simplest and most powerful syntax i met.
Igor Stasenko wrote:
I think that one of the major drawbacks of smalltalk is its 80's implementation which offers 0 (zero) modularity. A smalltalk image is a universe, which contains everything. It can't be split on parts, you can't manage these parts to load/unload on demand. Everything is tightly welded together and sometimes, even if you want to get rid of some stuff - its very hard to do. Its like a painting ink - once you stepped into it once - you start leaving footprints everywhere. Its very good from one side, but not always: for a people working in contaminated areas, they need to pass a clean-up procedures to reduce the risk of bringing unwanted stuff into that environment. In smalltalk there is no such contaminated areas - you free to go everywhere and leave your footprints. Who cares? :) This is the problem: if people don't have a discipline and leaving stuff everywhere they think it good to be, then at the end we got a complete mess, no structure, no organization, just a half-working pieces spreaded across many places.
Also, even if organized well, projects can't grow bigger than certain amount, and at some point they become unmanageable, simply because no single man can hold so much information in his head to understand it and make some progress with it. At some point, you have to split your project on separate parts and delegate your work to other people. And also, make sure that these parts can evolve more or less independently. This is where fun begins: a smalltalk inherent implementation lacks modularity and offers nothing to you how to break things apart without losing consistency. Instead, it makes you addict in using globals everywhere and be careless about future :)
Another analogue: kids playing with lego puzzle. One kid puts one piece on top of another, then second puts some more pieces on top of it, and so on, then another kid came and realizes that if he replace the piece inside a construction it would be much more elegant. But at first attempt when he tries that, he breaks the whole construction :)
I hoping this will change in near future. Smalltalk syntax is the simplest and most powerful syntax i met.
+ 1
Karl
"Igor Stasenko" siguctua@gmail.com wrote in message
I think that one of the major drawbacks of smalltalk is its 80's implementation which offers 0 (zero) modularity.
+1
I hoping this will change in near future.
+1
Sophie
On 21.11.2008, at 16:09, Sophie (itsme213) wrote:
"Igor Stasenko" siguctua@gmail.com wrote in message
I think that one of the major drawbacks of smalltalk is its 80's implementation which offers 0 (zero) modularity.
+1
I hoping this will change in near future.
+1
Well, other Smalltalks are more modular, so we can safely conclude that that is not what's holding back Smalltalk.
(but I do agree we should strive for modularity in Squeak of course)
- Bert -
About the licensing subthread - you guys must be new here. We only have license flamewars in April and October of each year ;-)
While I understand Randal's point, I do agree that worries about "clean room" are a bit too much. A friend of mine was sued by IBM over the BIOS in the original PC so I tracked that and the Compaq case much more closely than most here. This was an extreme case and not at all typical of other software and even then a full clean room scheme turned out not to be needed. But people still keep pointing out Compaq's method as the right way to do things:
http://www.pbs.org/nerds/part2.html (see Rod Canion's interview about 2/3 down that page)
Bert Freudenberg wrote:
Well, other Smalltalks are more modular, so we can safely conclude that that is not what's holding back Smalltalk.
(but I do agree we should strive for modularity in Squeak of course)
In fact, we can generalize this and of nearly all objections that were pointed out there is some Smalltalk to which it doesn't apply. Now it might be that only a perfect Smalltalk to which none of the objections apply could have succeeded, but I think what we have here is a case of
http://www.dreamsongs.org/WorseIsBetter.html
Smalltalk had higher upfront costs than the alternatives, but scaled much better. When I pointed out Self (Sun's own version of Smalltalk) to people in the mid 1990s they would reply "but you need a 24MB Sun machine to run that! Practically all deployed workstations only have 8MB and Java works just fine there." I would claim that this was only because Java wasn't doing anything yet (animating a funny little man) and that by the time it did half of what Self did it would be twice as large. It turned out that I was actually generous to Java, but when my prediction came true typical PCs had 256MB each.
But to understand what happened to Smalltalk you must look at the history more than at technical aspects. I don't know a good text I can link to, but Eliot spent some time on this in his AoSTA talk -
http://video.google.com/videoplay?docid=-8988857822906068209
-- Jecel
-----Mensaje original----- David Mitchell escreveu: Most of the things that make Smalltalk great (what makes Smalltalk Smalltalk) are the things that hold it back for a lot of people.
If you want a more Unixy, scripty, Smalltalkish thing with syntax blended C and Perl that you can hack with a text editor, try Ruby.
If you want objects all the time with a crazy amount of integration in the tools and little attempt at conforming to outside ideas, Smalltalk is your game.
Some things that hold back smalltalk:
1 .... Everybody knows that with current technology (JVM) it is not possible to build large intensive Java applications (just study how the garbage collection works... what happens when you have to handle large data...). ....
Careful, that's not true. With trained guys it surely can be accomplished. The small team I belong to it's an example of that. Of course it is still easier with smalltalk. And I think previous Smalltak training was key part of our success. To think that everything related to java is just trash is mistaken and doesn't help.
Cheers.
Emilio
Emilio Oca escreveu:
Careful, that's not true. With trained guys it surely can be accomplished. The small team I belong to it's an example of that. Of course it is still easier with smalltalk. And I think previous Smalltak training was key part of our success. To think that everything related to java is just trash is mistaken and doesn't help.
Cheers.
Emilio
But at what cost????
Java is more suited for small applications and I guess that Oracle people got it right when they started to migrate from old tools to Java in order to have better UI development. But when you have to handle large amounts of data and extremely dynamic objects and things like that Java performance drops to the point that it is better to use C++ or even C...
Interesting enough, there are lots of re-engineering initiatives for the Java VM. Up to the moment nobody was able to create a VM that lessens the troubles with the garbage collection system and other performance related topics.
Anyways, this list is to discuss development under squeak... I think in future I'll leave Java issues to Java lists...
Hi Casimiro,
You are misjudging [java] again. I am replying the issue you brought. And, to what this list mathers, to think Java is just worthless garbage and smalltalk is plain right doesn't help to understand how the market moves around these. Neither to understand what would be holding Smalltalk back. If that where the case, which I don't think so.
Cheers
Emilio
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]En nombre de Casimiro de Almeida Barreto Enviado el: Viernes, 21 de Noviembre de 2008 12:19 Para: The general-purpose Squeak developers list Asunto: Re: [squeak-dev] what is holding back Smalltalk?
Emilio Oca escreveu:
Careful, that's not true. With trained guys it surely can be
accomplished.
The small team I belong to it's an example of that. Of course it is still easier with smalltalk. And I think
previous Smalltak
training was key part of our success. To think that everything related to java is just trash is mistaken and doesn't help.
Cheers.
EmilioBut at what cost????
Java is more suited for small applications and I guess that Oracle people got it right when they started to migrate from old tools to Java in order to have better UI development. But when you have to handle large amounts of data and extremely dynamic objects and things like that Java performance drops to the point that it is better to use C++ or even C...
Interesting enough, there are lots of re-engineering initiatives for the Java VM. Up to the moment nobody was able to create a VM that lessens the troubles with the garbage collection system and other performance related topics.
Anyways, this list is to discuss development under squeak... I think in future I'll leave Java issues to Java lists...
Casimiro de Almeida Barreto wrote:
But at what cost????
It is a high cost at times, granted :>
Java is more suited for small applications
I am sorry, but could you please explain this?
and I guess that Oracle people got it right when they started to migrate from old tools to Java in order to have better UI development.
What UI development do you mean?
But when you have to handle large amounts of data and extremely dynamic objects and things like that Java performance drops to the point that it is better to use C++ or even C...
This sounds interesting - could you please elaborate a bit further?
Interesting enough, there are lots of re-engineering initiatives for the Java VM. Up to the moment nobody was able to create a VM that lessens the troubles with the garbage collection system and other performance related topics.
Well, one performance related topic is halfway gone: graphics.
Le jeudi 20 novembre 2008 à 17:28 -0600, David Mitchell a écrit :
Most of the things that make Smalltalk great (what makes Smalltalk Smalltalk) are the things that hold it back for a lot of people.
If you want a more Unixy, scripty, Smalltalkish thing with syntax blended C and Perl that you can hack with a text editor, try Ruby.
You may also want to try GNU Smalltalk (http://smalltalk.gnu.org). I just started using it for my scripting tasks, and so far I think it a lot better than Python or Ruby.
Nicolas
"nico" == nico petton.nicolas@gmail.com writes:
nico> You may also want to try GNU Smalltalk (http://smalltalk.gnu.org). nico> I just started using it for my scripting tasks, and so far I think it a nico> lot better than Python or Ruby.
But beware of looking at any of its source code if you ever think you might be contibuting to the Squeak core. See my discussion at http://methodsandmessages.vox.com/library/post/beware-gnu-smalltalk-if-you-w...
Randal L. Schwartz wrote:
"nico" == nico petton.nicolas@gmail.com writes:
nico> You may also want to try GNU Smalltalk (http://smalltalk.gnu.org). nico> I just started using it for my scripting tasks, and so far I think it a nico> lot better than Python or Ruby.
But beware of looking at any of its source code if you ever think you might be contibuting to the Squeak core. See my discussion at http://methodsandmessages.vox.com/library/post/beware-gnu-smalltalk-if-you-w...
Blah, blah, blah.
Paolo
And these sorts of responses are what is wrong with the smalltalk community :)
On Nov 21, 2008, at 4:54 AM, Paolo Bonzini wrote:
Randal L. Schwartz wrote:
> "nico" == nico petton.nicolas@gmail.com writes:
nico> You may also want to try GNU Smalltalk (http://smalltalk.gnu.org ). nico> I just started using it for my scripting tasks, and so far I think it a nico> lot better than Python or Ruby.
But beware of looking at any of its source code if you ever think you might be contibuting to the Squeak core. See my discussion at http://methodsandmessages.vox.com/library/post/beware-gnu-smalltalk-if-you-w...
Blah, blah, blah.
Paolo
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably.
Hi Randal,
Please excuse me but I need to support Paolo here. In sense that he doesn't stick blindfuly to those license issues while you do. Again and again. Please stop dividing Smalltalk world with such actions. Squeak is/will be MIT, GNU Smalltalk is LGPL. OK, that is, don't expose your anti-whatever license bias again and again. For the Smalltalk as a whole sake. Please.
Janko
Randal L. Schwartz wrote:
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably.
Janko,
Please excuse me, I need to support Randal here.
On Fri, Nov 21, 2008 at 15:50, Janko Mivšek janko.mivsek@eranova.si wrote:
Hi Randal,
Please excuse me but I need to support Paolo here. In sense that he doesn't stick blindfuly to those license issues while you do.
Randal is not sticking "blindly" to any license issue. His email said:
"But beware of looking at any of its source code if you ever think you might be contibuting to the Squeak core."
That is a real and valid concern. His blog entry explains it clearly as well.
Please stop dividing Smalltalk world with such actions. Squeak is/will be MIT, GNU Smalltalk is LGPL.
One could argue that the license divide is the cause of the divide.
Who would not want Generators in Squeak? It is solely because of the license concern that we can not use the good parts of GNU Smalltalk.
Who would not want Generators in Squeak? It is solely because of the license concern that we can not use the good parts of GNU Smalltalk.
Not really, because I posted at least two implementations of Generators in the public domain and people were still saying they were tainted by gst's.
Paolo
On 21-Nov-08, at 7:42 AM, Paolo Bonzini wrote:
Who would not want Generators in Squeak? It is solely because of the license concern that we can not use the good parts of GNU Smalltalk.
Not really, because I posted at least two implementations of Generators in the public domain and people were still saying they were tainted by gst's.
Cool! I've been thinking about Generators myself. Can you point me to your implementations?
Colin
Not really, because I posted at least two implementations of Generators in the public domain and people were still saying they were tainted by gst's.
Cool! I've been thinking about Generators myself. Can you point me to your implementations?
One is in GNU Smalltalk's examples/Gen3.st. It is GPL but I am ok with relicensing it to MIT. It uses separate processes, so it is not very exception friendly.
Anyway, the best one is for VW and is at
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/5274...
Squeak does not have the Promise class (a ValueHolder that runs in a separate process but forwards exceptions to the process who sent #value), unfortunately, so it won't work there out-of-the-box.
Of course, you need to figure out what it does from the usage I make in the Generator class. Otherwise you'd be tainted by VW's source code and Squeak would face being sued by Cincom for copyright violation. Sorry, couldn't help it.
Paolo
On 21.11.2008, at 14:50, Janko Mivšek wrote:
Hi Randal,
Please excuse me but I need to support Paolo here. In sense that he doesn't stick blindfuly to those license issues while you do. Again and again. Please stop dividing Smalltalk world with such actions. Squeak is/will be MIT, GNU Smalltalk is LGPL. OK, that is, don't expose your anti-whatever license bias again and again. For the Smalltalk as a whole sake. Please.
I understand your sentiment - I used to think the same about licenses. But this is exactly the kind of attitude that got us into the whole messy situation with licenses.
This was not an attack against Paolo personally or even against GNU in general - it's just that we have to be cautious where code comes from because it's easy to accidentally get infectiously-licensed code in, but it's much harder to remove later.
If there went even a single LGPL method into a release, the whole of Squeak would have to become GNU licensed. Read the LGPL if you don't believe this.
The only way around this is if the author of the LGPL code in question would explicitly allow that code to be used under the MIT license.
- Bert -
"Janko" == Janko Mivšek janko.mivsek@eranova.si writes:
Janko> Please excuse me but I need to support Paolo here. In sense that he Janko> doesn't stick blindfuly to those license issues while you do. Again and Janko> again. Please stop dividing Smalltalk world with such actions. Squeak Janko> is/will be MIT, GNU Smalltalk is LGPL. OK, that is, don't expose your Janko> anti-whatever license bias again and again. For the Smalltalk as a Janko> whole sake. Please.
Please stop mischaracterising this as a license "bias" or telling me to not perform my duty to ensure a clean license for Squeak. I truly do not want disharmony on this issue. But the lawyers (especially for the FSF) would differ on that, and that would be a serious mess. Best to do the right thing now, and not have to face a meltdown later.
The Squeak community chose Apache2. The GST authors chose GPL/LGPL. I support both of those choices completely. But it means that while code could freely flow from Squeak to GST, the opposite is *an unknown needless risk*. That's all i've ever argued on this. And any comment to the contrary deserves my clarification again.
Janko Mivšek wrote:
Hi Randal,
Please excuse me but I need to support Paolo here. In sense that he doesn't stick blindfuly to those license issues while you do. Again and again. Please stop dividing Smalltalk world with such actions. Squeak is/will be MIT, GNU Smalltalk is LGPL. OK, that is, don't expose your anti-whatever license bias again and again. For the Smalltalk as a whole sake. Please.
Janko
I hate licence issues with a passion. But I will stick up for Randal here.
If there is an issue, there is an issue, and until that issue is resolved, there still is an issue. Furthermore it is no crime to point out that there is still an issue.
When person who highlights a problem is treated as being a problem, that is actually abuse, and it has no place in our forum. I think that Paulo should apologize for being rude.
I expect to contribute to Squeak core in some manner, therefore I am not able to "get stuck in" to GNU Smalltalk, without some licence issues effecting what I do. The danger being, according to Randal, that if Squeak makes use of GNU Smalltalk code, directly or indirectly, then Squeak might come under LGPL jurisdiction.
If the above is true, then its up to the GNU Smalltalk people to change things "For Smalltalk as a whole sake"
If its not true, then show us it is not true, clearly and unequivocally
Keith
When person who highlights a problem is treated as being a problem, that is actually abuse, and it has no place in our forum.
Point taken. Sorry. But I saw the "problem" highlighted too many times without actually listening to the other side.
"Looking at" code, especially in a casual way, does not mean "writing the same code" if months later you happen to work on a similar project. At most it means "remembering something about the private interfaces".
Example 1: You debug some GNU Smalltalk code and you look at a private method in Collection or File. You definitely have no "taint" whatsoever.
Example 2: You look at Stream and notice "many methods in PositionableStream, such as #upToAll: do not need positioning if you use KMP search, so they were moved up to Stream". You can add such algorithms to Squeak without being worried of tainting. You probably read no more than the method comment, and the code you write will bear no resemblance to GNU Smalltalk's. The FSF position, which I posted multiple times, was "to understand code, look at it as much as you need; then don't look at it anymore and rewrite it on your own".
Example 3: I wrote the generators and have not looked them a while ago. If I have to explain the implementation details now, I couldn't say anything more than "it uses a single continuation instance variable independent of whether it is a continuation of the producer or the consumer, and it uses atEnd == nil to mark if it is a producer vs. consumer continuation (hum, was it == nil for the consumer and ~~ nil for the producer, or vice versa?)". Even if *I* reimplemented "clean-room" based on these memories, my code is not going to be tainted!
Corollary: There is more copyright infringement risk in doing a clean room reverse engineering with descriptions such as "Color class>>#blue returns the class variable Blue" (yes, there were some in the method rewrite effort).
I expect to contribute to Squeak core in some manner, therefore I am not able to "get stuck in" to GNU Smalltalk, without some licence issues effecting what I do. The danger being, according to Randal, that if Squeak makes use of GNU Smalltalk code, directly or indirectly, then Squeak might come under LGPL jurisdiction.
I never said you have to be careless. That is WRONG and it was demonstrated during the whole Swazoo licensing mess.
Paolo
On 22/11/2008, at 1:15 AM, Keith Hodges wrote:
If the above is true, then its up to the GNU Smalltalk people to change things "For Smalltalk as a whole sake"
Or for the Squeak people to change their license "For Smalltalk as a whole sake".
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
If a train station is a place where a train stops, what's a workstation?
Janko Mivšek wrote:
Hi Randal,
Please excuse me but I need to support Paolo here. In sense that he doesn't stick blindfuly to those license issues while you do. Again and again.
No, wait, don't put in my mouth what I didn't said. I never said licenses should not be taken seriously. I said that there are a lot of grays between "laugh at licenses" and "do clean-room reverse engineering".
Paolo
Randal L. Schwartz escreveu:
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably.
Hello Randall,
Sorry if this question bother you, but I'm not expert in legal issues and I'm used to work with GPL and LGPL software.
I understand that Squeak was first issued under Apple licensing system. Then, last year it was decided to migrate everything to the MIT license. But for people not acquainted with licensing systems, the differences may not clear. What are the incompatibilities between MIT licenses and GPL/LGPL licenses?
Best regards,
Casimiro
On 21.11.2008, at 15:02, Casimiro de Almeida Barreto wrote:
Randal L. Schwartz escreveu:
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably.
Hello Randall,
Sorry if this question bother you, but I'm not expert in legal issues and I'm used to work with GPL and LGPL software.
I understand that Squeak was first issued under Apple licensing system. Then, last year it was decided to migrate everything to the MIT license. But for people not acquainted with licensing systems, the differences may not clear. What are the incompatibilities between MIT licenses and GPL/LGPL licenses?
There is no incompatibility between MIT and GPL (although there is between Apache and GPL, and parts of Squeak are still under ASL 2.0).
But GPL is viral (and LGPL too if you rip out code and not just link to it) so it infects other code used together with the GPLed code. We do not want Squeak to become GPL licensed so we need to be careful what code to let in.
- Bert -
There is no incompatibility between MIT and GPL (although there is between Apache and GPL, and parts of Squeak are still under ASL 2.0).
There is no incompatibility between Apache and GPL3, but that's secondary.
But GPL is viral (and LGPL too if you rip out code and not just link to it) so it infects other code used together with the GPLed code. We do not want Squeak to become GPL licensed so we need to be careful what code to let in.
And to be clear about this once for all, I completely agree with the above assessment. Squeak people do need to be careful, even a bit paranoid if you want. But implying that you cannot look at GNU Smalltalk for fear that you'll glance at its code and be tainted by it, goes way beyond paranoia.
Paolo
"Paolo" == Paolo Bonzini bonzini@gnu.org writes:
Paolo> And to be clear about this once for all, I completely agree with the Paolo> above assessment. Squeak people do need to be careful, even a bit Paolo> paranoid if you want. But implying that you cannot look at GNU Paolo> Smalltalk for fear that you'll glance at its code and be tainted by it, Paolo> goes way beyond paranoia.
Get a legal document from the FSF lawyers that confirms that and holds us permanently harmless, and I'll shut up. Until then, Squeak devs are at risk.
Randal L. Schwartz wrote:
"Paolo" == Paolo Bonzini bonzini@gnu.org writes:
Paolo> And to be clear about this once for all, I completely agree with the Paolo> above assessment. Squeak people do need to be careful, even a bit Paolo> paranoid if you want. But implying that you cannot look at GNU Paolo> Smalltalk for fear that you'll glance at its code and be tainted by it, Paolo> goes way beyond paranoia.
Get a legal document from the FSF lawyers that confirms that and holds us permanently harmless, and I'll shut up. Until then, Squeak devs are at risk.
Answer 1: You do realize that it would amount to relicensing GNU Smalltalk under MIT, don't you?
Answer 2: Eliot surely remembers a lot of the code for HPS or for the VW compiler, and so does Vassili. So, add to the list of methods that have to be relicensed all code written by former employees of OTI, Cincom, IBM, Instantiations, Gemstone, and I'll shut up. Because until then, Squeak devs are at risk.
Paolo
On 21-Nov-08, at 8:16 AM, Randal L. Schwartz wrote:
"Paolo" == Paolo Bonzini bonzini@gnu.org writes:
Paolo> And to be clear about this once for all, I completely agree with the Paolo> above assessment. Squeak people do need to be careful, even a bit Paolo> paranoid if you want. But implying that you cannot look at GNU Paolo> Smalltalk for fear that you'll glance at its code and be tainted by it, Paolo> goes way beyond paranoia.
Get a legal document from the FSF lawyers that confirms that and holds us permanently harmless, and I'll shut up. Until then, Squeak devs are at risk.
Squeak devs are at risk of what? How much risk is there? Are the attendant benefits worth the risk?
The mere existence of risk isn't very good argument for or against anything - if it were, we would be fools to get out of bed in the morning.
Colin
I think there alway will be issues around licensing (and great money for lawyers) until people understand that they need to change the perception on what 'intellectual property' means.
As someone said: nobody pays a license fee to the architect who designed the building each time someone entering it. So why we should pay a software architect for each copy of his software? People should be paid for things they do, not for mass-produced copies of their creation. Making a copy is not an act of creating intellectual property - its just a mechanic process.
2008/11/22 Colin Putney cputney@wiresong.ca:
On 21-Nov-08, at 8:16 AM, Randal L. Schwartz wrote:
> "Paolo" == Paolo Bonzini bonzini@gnu.org writes:
Paolo> And to be clear about this once for all, I completely agree with the Paolo> above assessment. Squeak people do need to be careful, even a bit Paolo> paranoid if you want. But implying that you cannot look at GNU Paolo> Smalltalk for fear that you'll glance at its code and be tainted by it, Paolo> goes way beyond paranoia.
Get a legal document from the FSF lawyers that confirms that and holds us permanently harmless, and I'll shut up. Until then, Squeak devs are at risk.
Squeak devs are at risk of what? How much risk is there? Are the attendant benefits worth the risk?
The mere existence of risk isn't very good argument for or against anything
- if it were, we would be fools to get out of bed in the morning.
Colin
"What is holding back Smalltalk?" may or may not be a legitimate question. However, the question is somewhat relative to the audience. On a Squeak mailing list, the answer to this question is straightforward: there is nothing holding Smalltalk back.
It would be more interesting to survey a general population (of developers) with both specific and open questions. This would also increase the "brand awareness" (Squeak and Smalltalk in general). A survey passed along to colleagues, teachers, classroms, etc., would certainly generate more interest, at low costs, and yet the compiled data could outline the "failing" aspects of Squeak or Smalltalk in general.
Anyway, it's just some thoughts...
Ian.
Well, I think that the problem is simply answered by: People do not understand the ideas of "simplicity" and "precise" like we encourage smalltalk code to be. this is a very interesting issue, and, at some point, I would like to create a SWOT(look it up on Wikipedia) analysis of smalltalk, to see just what is going on. David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com
On Sat, Nov 22, 2008 at 4:29 AM, Ian Trudel ian.trudel@gmail.com wrote:
"What is holding back Smalltalk?" may or may not be a legitimate question. However, the question is somewhat relative to the audience. On a Squeak mailing list, the answer to this question is straightforward: there is nothing holding Smalltalk back.
It would be more interesting to survey a general population (of developers) with both specific and open questions. This would also increase the "brand awareness" (Squeak and Smalltalk in general). A survey passed along to colleagues, teachers, classroms, etc., would certainly generate more interest, at low costs, and yet the compiled data could outline the "failing" aspects of Squeak or Smalltalk in general.
Anyway, it's just some thoughts...
Ian.
On 22/11/2008, at 2:41 PM, Igor Stasenko wrote:
As someone said: nobody pays a license fee to the architect who designed the building each time someone entering it.
In fact, you pay an architect for a design each time you build it. You can't reuse an architect's design without paying for it, or negotiating a license. The fact that you live in a house designed by an architect gives you no rights to the design.
So why we should pay a software architect for each copy of his software?
You first need to prove the applicability of this analogy. And in any case, given my comment above, I think this proves the opposite of what you intend.
People should be paid for things they do, not for mass-produced copies of their creation.
You would need to provide supporting argument for this assertion to be evaluated.
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
Some defeats are instalments to victory. -- Jacob Riis
2008/11/22 Antony Blakey antony.blakey@gmail.com:
On 22/11/2008, at 2:41 PM, Igor Stasenko wrote:
As someone said: nobody pays a license fee to the architect who designed the building each time someone entering it.
In fact, you pay an architect for a design each time you build it. You can't reuse an architect's design without paying for it, or negotiating a license. The fact that you live in a house designed by an architect gives you no rights to the design.
Right, you pay for design, but nobody pays the fee for entering his authentic house (read - get a copy).
So why we should pay a software architect for each copy of his software?
You first need to prove the applicability of this analogy. And in any case, given my comment above, I think this proves the opposite of what you intend.
How do you like the following: these words is my intellectual property, and once you read them you have to pay $$ to me as license fee. Ignoring this would lead to prosecution in court. :)
People should be paid for things they do, not for mass-produced copies of their creation.
You would need to provide supporting argument for this assertion to be evaluated.
Antony Blakey
CTO, Linkuistics Pty Ltd Ph: 0438 840 787
Some defeats are instalments to victory. -- Jacob Riis
On 22/11/2008, at 6:14 PM, Igor Stasenko wrote:
2008/11/22 Antony Blakey antony.blakey@gmail.com:
On 22/11/2008, at 2:41 PM, Igor Stasenko wrote:
As someone said: nobody pays a license fee to the architect who designed the building each time someone entering it.
In fact, you pay an architect for a design each time you build it. You can't reuse an architect's design without paying for it, or negotiating a license. The fact that you live in a house designed by an architect gives you no rights to the design.
Right, you pay for design, but nobody pays the fee for entering his authentic house (read - get a copy).
No, not 'get a copy'. The appropriate equivalent is 'use the software'.
And in any case, there are buildings for which you are charged entry, and sometimes purely on the basis of the architect. Falling Water might be like that (although I think I read that it's no longer open due to structural issues).
Anyway, this argument is off-topic for this list, so I'll leave it to you to have the last word ... :)
Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
75% of statistics are made up on the spot.
2008/11/22 Antony Blakey antony.blakey@gmail.com:
On 22/11/2008, at 6:14 PM, Igor Stasenko wrote:
2008/11/22 Antony Blakey antony.blakey@gmail.com:
On 22/11/2008, at 2:41 PM, Igor Stasenko wrote:
As someone said: nobody pays a license fee to the architect who designed the building each time someone entering it.
In fact, you pay an architect for a design each time you build it. You can't reuse an architect's design without paying for it, or negotiating a license. The fact that you live in a house designed by an architect gives you no rights to the design.
Right, you pay for design, but nobody pays the fee for entering his authentic house (read - get a copy).
No, not 'get a copy'. The appropriate equivalent is 'use the software'.
And in any case, there are buildings for which you are charged entry, and sometimes purely on the basis of the architect. Falling Water might be like that (although I think I read that it's no longer open due to structural issues).
Anyway, this argument is off-topic for this list, so I'll leave it to you to have the last word ... :)
Neither do i want to continue with this. I just don't like the perception that reading anybody's open-source code and then implementing same things might taint the squeak.
Antony Blakey
CTO, Linkuistics Pty Ltd Ph: 0438 840 787
75% of statistics are made up on the spot.
I feel compelled to share another perspective on the importance of licenses: - at every round of funding, we had to sign documents describing our license content. It was very clear that the money people "knew" that anything with the letters "GPL" was a red-flag. They had no understanding whatsoever of the fine points between GPL and LGPL. It might not stop a funding round, but it definitely slows it down. - when the company that bought my company was being acquired by IBM, they ran code scans on ALL of our source code during due-diligence. Depending on the specific situation, plans were established to remove or replace code, or even kill a product. I can easily imagine situations where the license analysis would kill a deal. (I spent a couple of miserable months documenting licenses, pedigree, etc. for my small part of the portfolio)
When the financial future of your colleagues depends on these types of decisions, they take on a different level of importance.
-david
On Fri, Nov 21, 2008 at 10:05 AM, Paolo Bonzini bonzini@gnu.org wrote:
There is no incompatibility between MIT and GPL (although there is between Apache and GPL, and parts of Squeak are still under ASL 2.0).
There is no incompatibility between Apache and GPL3, but that's secondary.
But GPL is viral (and LGPL too if you rip out code and not just link to it) so it infects other code used together with the GPLed code. We do not want Squeak to become GPL licensed so we need to be careful what code to let in.
And to be clear about this once for all, I completely agree with the above assessment. Squeak people do need to be careful, even a bit paranoid if you want. But implying that you cannot look at GNU Smalltalk for fear that you'll glance at its code and be tainted by it, goes way beyond paranoia.
Paolo
Randal,
your web page doesn't come across like your mailing list communication, which has always seemed non-inflammatory and reasonable. Two things immediately annoy me on the page you reference. Firstly you say 'Damn you GPL'. Second, the comment you quote says that the GPL is 'completely unacceptable', which IMO is an aggressive (redundant) overemphasis. If it had simply said 'incompatible' it wouldn't piss me off, and would merely stand as the warning you intend.
I'm building a commercial Smalltalk implementation that will have commercially licensed components e.g. not (L)GPL, or even MIT/Apache/ BSD. I don't support all of Stallman's philosophy - I don't believe there is any moral imperative for software to be 'free'. I support the concept of DRM etc etc etc. I'm not a GPL or even O/S fanatic, although I completely support the right of anyone to use any license for *their* work without being criticized for it. I perfectly understand Paolo's response to that web page.
One could "freely examine the implementation and use as is or derive from it to contribute to the squeak project" if Squeak was GPL. I guess the GST authors simply don't want people commercially benefiting from their work without giving anything back. Fair enough. Even so, IMO it is possible to use GST to deliver commercial applications that include non-(L)GPL ST source / documentation / resources, and I could in fact deliver a commercially licensed Smalltalk using GST, subject to some reasonable conditions.
On 21/11/2008, at 11:57 PM, Randal L. Schwartz wrote:
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. --Stephen F Roberts
Begin forwarded message:
From: merlyn@stonehenge.com (Randal L. Schwartz) Date: 21 November 2008 11:57:10 PM To: Steven W Riggins mailinglists@geeksrus.com Cc: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
Subject: Re: [squeak-dev] Re: what is holding back Smalltalk? Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Begin forwarded message:
From: merlyn@stonehenge.com (Randal L. Schwartz) Date: 21 November 2008 11:57:10 PM To: Steven W Riggins mailinglists@geeksrus.com Cc: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
Subject: Re: [squeak-dev] Re: what is holding back Smalltalk? Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Begin forwarded message:
From: merlyn@stonehenge.com (Randal L. Schwartz) Date: 21 November 2008 11:57:10 PM To: Steven W Riggins mailinglists@geeksrus.com Cc: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
Subject: Re: [squeak-dev] Re: what is holding back Smalltalk? Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
I'm serious about this, and will continue to bring it up in every appropriate context. I wish this weren't the case: I pleaded with Paolo to dual license the Smalltalk code in GNU Smalltalk under the MIT license so that people can freely examine the implementation and use as is or derive from it to contribute to the squeak project. So far, these requests have been declined, albeit understandably. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
I presume by "these sorts of responses" you mean Paolo's response to me. My response is driven by my responsibility as being an elected member of the leadership team, to ensure that Squeak 4.0 will have a completely clean license. We worked very hard over the last few years to track down every contribution to squeak since its beginning, obtaining legal documents updating the license, and it would be a shame if a mistakenly derived work from GNU Smalltalk were to taint the distribution once again.
Note that if (*if*) this were to happen, I would consider relicensing the wrong pieces on a case-by-case basis to MIT.
Another point (and a follow up on the "return class variable Blue") is that the very fact of having created a class variable Blue whose value is (Color red: 0 green: 0 blue: 1) might be construed as owning copyright on part of the image. You are so proud of living in a world of objects, and then restrict yourselves to old fashioned source code when it is better to do so... So face it, Squeak's image will never be clean.
Paolo
I'm pretty "new" in my abilities, but I have found a TERRIFIC product written in VisualWorks thanks to networking with all you Smalltalk-y people. We are working to develop a data collection and reporting tool in a healthcare environment using this system that already existed and was designed specifically to be able to bring together "fragments" of information from multiple sources of data through conflict resolution rules, etc... into a single "Object Model" (set of classes).
Anyway...what I am doing is another topic--but it IS the back story for the following tale.
Because we are "developing" something together, and it is "Smalltalk" (even though it's not, but because I found it by EXPLORING Smalltalk, it's "branded"), one of our Board Members (a former programmer) is extremely leery.
In his words, he is "extremely prejudiced" against Smalltalk, even though he used it during a big project "back in the day." He calls it a "quirky, unusual" language that you can do "great and powerful things" with. The "Father of real object oriented programming," but only a "niche" language that small groups of bright people use to go of and accomplish amazing things with. But, because the business is full of "ordinary" people, he thinks you would never be able to find anyone to work with the code you have written as a business when your Smalltalk developers leave for other pursuits.
Hence, he suggests that I look to other development environments such as Java Beans or Eclipse!
All this, and we won't even be "programming," but using a "meta-programming" environment designed SPECIFICALLY to solve the KIND of problem we have (how lucky was that?). Sure, it's got Smalltalk at it's core, and yes, you can drop down into Smalltalk when you need to, but...yeesh....
Just thought you'd like an anecdotal tale of the feelings that are out there as of a few days ago!
Rob
On Thu, Nov 20, 2008 at 6:02 PM, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
Mark Volkmann
In his words, he is "extremely prejudiced" against Smalltalk, even though he used it during a big project "back in the day." He calls it a "quirky, unusual" language that you can do "great and powerful things" with. The "Father of real object oriented programming," but only a "niche" language that small groups of bright people use to go of and accomplish amazing things with. But, because the business is full of "ordinary" people, he thinks you would never be able to find anyone to work with the code you have written as a business when your Smalltalk developers leave for other pursuits.
I once wrote a simulator for telecoms equipment. The original demo took 2 weeks to produce in order to convince my boss.
After 3 months work, the simulator was simulating a single piece of equipment 2 months before real equipment was available. This gave the whole team a considerable head start. After a further 6-8 months the simulation was doing 1000 pieces of equipment simultaneously, of 3 different varieties, while at the same time simulating up to 20 users prodding the management system. There were 1500 unit tests ensuring that everything was according to spec. The simulation turned out to be key to proof of concept for our clients signing on the dotted line.
On the other side of the office, a contractor attempted to write a similar simulator for another piece of equipment, in perl. After a year that was scapped and a team of 4 started in Java. That was also scapped and a top guru tried again in java, his efforts ran on 10 pcs! Finally, last I heard another extremely expensive contractor was starting again in C++.
I estimate (being generous) that they must have spent over a half a million pounds on that failed project, and that doesnt include some rather expensive bought in libraries (for which source code was not visible). Little ol- me knocked up my Smalltalk equivalent for perhaps 5-10% of the cost. (we did buy an ST/X licence for £2000).
When I went on holiday, the only non-programmer in my team, the guy doing automated testing was quite able to fix bugs, run unit tests and keep things going. When I left the company the entire system was handed over to a perl programmer, and last I heard it was still being used by 9 people daily. I must ring up and ask if it reached its 10th bithday.
So... if your boss is happy to spend 10x as much to get a poorer result... there is not much else can be said.
cheers
Keith
Keith,
That's a great story. We should put that on the website!
On Thu, Nov 20, 2008 at 8:21 PM, Keith Hodges keith_hodges@yahoo.co.uk wrote:
In his words, he is "extremely prejudiced" against Smalltalk, even though he used it during a big project "back in the day." He calls it a "quirky, unusual" language that you can do "great and powerful things" with. The "Father of real object oriented programming," but only a "niche" language that small groups of bright people use to go of and accomplish amazing things with. But, because the business is full of "ordinary" people, he thinks you would never be able to find anyone to work with the code you have written as a business when your Smalltalk developers leave for other pursuits.
I once wrote a simulator for telecoms equipment. The original demo took 2 weeks to produce in order to convince my boss.
After 3 months work, the simulator was simulating a single piece of equipment 2 months before real equipment was available. This gave the whole team a considerable head start. After a further 6-8 months the simulation was doing 1000 pieces of equipment simultaneously, of 3 different varieties, while at the same time simulating up to 20 users prodding the management system. There were 1500 unit tests ensuring that everything was according to spec. The simulation turned out to be key to proof of concept for our clients signing on the dotted line.
On the other side of the office, a contractor attempted to write a similar simulator for another piece of equipment, in perl. After a year that was scapped and a team of 4 started in Java. That was also scapped and a top guru tried again in java, his efforts ran on 10 pcs! Finally, last I heard another extremely expensive contractor was starting again in C++.
I estimate (being generous) that they must have spent over a half a million pounds on that failed project, and that doesnt include some rather expensive bought in libraries (for which source code was not visible). Little ol- me knocked up my Smalltalk equivalent for perhaps 5-10% of the cost. (we did buy an ST/X licence for £2000).
When I went on holiday, the only non-programmer in my team, the guy doing automated testing was quite able to fix bugs, run unit tests and keep things going. When I left the company the entire system was handed over to a perl programmer, and last I heard it was still being used by 9 people daily. I must ring up and ask if it reached its 10th bithday.
So... if your boss is happy to spend 10x as much to get a poorer result... there is not much else can be said.
cheers
Keith
Brad Fuller wrote:
Keith,
That's a great story. We should put that on the website!
You really should:
- STIC - Squeak
websites.
Though you should really ask if that application is still running.
Claus
On Thu, Nov 20, 2008 at 8:21 PM, Keith Hodges keith_hodges@yahoo.co.uk wrote:
In his words, he is "extremely prejudiced" against Smalltalk, even though he used it during a big project "back in the day." He calls it a "quirky, unusual" language that you can do "great and powerful things" with. The "Father of real object oriented programming," but only a "niche" language that small groups of bright people use to go of and accomplish amazing things with. But, because the business is full of "ordinary" people, he thinks you would never be able to find anyone to work with the code you have written as a business when your Smalltalk developers leave for other pursuits.
I once wrote a simulator for telecoms equipment. The original demo took 2 weeks to produce in order to convince my boss.
After 3 months work, the simulator was simulating a single piece of equipment 2 months before real equipment was available. This gave the whole team a considerable head start. After a further 6-8 months the simulation was doing 1000 pieces of equipment simultaneously, of 3 different varieties, while at the same time simulating up to 20 users prodding the management system. There were 1500 unit tests ensuring that everything was according to spec. The simulation turned out to be key to proof of concept for our clients signing on the dotted line.
On the other side of the office, a contractor attempted to write a similar simulator for another piece of equipment, in perl. After a year that was scapped and a team of 4 started in Java. That was also scapped and a top guru tried again in java, his efforts ran on 10 pcs! Finally, last I heard another extremely expensive contractor was starting again in C++.
I estimate (being generous) that they must have spent over a half a million pounds on that failed project, and that doesnt include some rather expensive bought in libraries (for which source code was not visible). Little ol- me knocked up my Smalltalk equivalent for perhaps 5-10% of the cost. (we did buy an ST/X licence for £2000).
When I went on holiday, the only non-programmer in my team, the guy doing automated testing was quite able to fix bugs, run unit tests and keep things going. When I left the company the entire system was handed over to a perl programmer, and last I heard it was still being used by 9 people daily. I must ring up and ask if it reached its 10th bithday.
So... if your boss is happy to spend 10x as much to get a poorer result... there is not much else can be said.
cheers
Keith
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
1. The VM, it's weak, no multithreading, few IO options.
2. The restriction to image based smalltalk instead of the ability to run discreet programs...
Image based smalltalk is awesome but it makes it difficult to interface smalltalk code with external systems.
2008/11/21 Alan Grimes agrimes@speakeasy.net:
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
The VM, it's weak, no multithreading, few IO options.
The restriction to image based smalltalk instead of the ability to
run discreet programs...
Image based smalltalk is awesome but it makes it difficult to interface smalltalk code with external systems.
i think, community would be able to overcome both problems, if there was an option to build VM as shared (or static) library to include it in own project. Then image plays role as external module, which you can load and play with, and then drop it once you don't need it anymore and load another one. As well, as having a reentrant interpreter would allow to interoperate with it.
-- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights.
Alan Grimes escreveu:
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
The VM, it's weak, no multithreading, few IO options.
The restriction to image based smalltalk instead of the ability to
run discreet programs...
Image based smalltalk is awesome but it makes it difficult to interface smalltalk code with external systems.
The shortcomings about the squeak VM can be easily surpassed. Same thing about the "image" issue.
IMHO what holds Smalltalk (and squeak in particular) is lack of investment ($$$) in order to provide the things that "commercial users" (aka "regular developers/users") imagine/request as desirable (like "canonic" documentation, "canonic" books like "Smalltalk for dummies" (LOL) or "coreSmalltalk" or "Smalltalk Foundation Classes", better default options for the interfaces).
Besides these "small things" there are some important issues: there are several flavors of smalltalk and they're not compatible to each other. It seems that in the "open/free world" squeak will take the lead and perhaps it is good news. Anyways, today we have only VW to be seriously considered in the "commercial world" (since Dolphin is not multi-platform and was "half abandoned" by its developers and other smalltalks are both non portable and little known) and squeak and VW VMs are not compatible (no instant or even easy port from squeak to VW).
It is not possible to imagine the success of anything that is not accepted by the non-academic community. Currently most of the non-academic community in the World has little more than high-school degree, little or no fluency in English and earn something like US$1.000,00/month (or less) for a journey of at least 40hours/week (and lots of non payed over-time). So I do think that the two previous paragraphs are relevant aspects to the question of "what is holding back smalltalk?"
I am very newbie with smalltalk, but I have some thoughts about this question.
- Markting (someone has already say it) - Lack of investment (someone has already say it) - Smalltalk is simple. And, as It says a friend of mine, simplest things doesn't sell. It might be complex. Complex things are the most sold. - Companies needs to spend many and spent their budgets - Databases support. Squeak for example, how can be used in many enterprise projects if there is only driver for mysql and postgres ? and Glorp only with postgres... We did a survey and they are just the 20% of the market (we need support for oracle, mssql, and so on.). Because of this, we are working in SqueakDBX. - IDE. It has a lot of good things, but also a lot of limitations. I am very use to use Eclipse. And sometime to miss some features about it. - There is no company (in squeak) behind it. Managers, owners, directors, and so on, many times need this. They need it in order to have someone to blame in case of problems.
cheers,
Mariano
On Fri, Nov 21, 2008 at 10:26 AM, Casimiro de Almeida Barreto < casimiro.barreto@gmail.com> wrote:
Alan Grimes escreveu:
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
The VM, it's weak, no multithreading, few IO options.
The restriction to image based smalltalk instead of the ability to
run discreet programs...
Image based smalltalk is awesome but it makes it difficult to interface smalltalk code with external systems.
The shortcomings about the squeak VM can be easily surpassed. Same thing about the "image" issue.
IMHO what holds Smalltalk (and squeak in particular) is lack of investment ($$$) in order to provide the things that "commercial users" (aka "regular developers/users") imagine/request as desirable (like "canonic" documentation, "canonic" books like "Smalltalk for dummies" (LOL) or "coreSmalltalk" or "Smalltalk Foundation Classes", better default options for the interfaces).
Besides these "small things" there are some important issues: there are several flavors of smalltalk and they're not compatible to each other. It seems that in the "open/free world" squeak will take the lead and perhaps it is good news. Anyways, today we have only VW to be seriously considered in the "commercial world" (since Dolphin is not multi-platform and was "half abandoned" by its developers and other smalltalks are both non portable and little known) and squeak and VW VMs are not compatible (no instant or even easy port from squeak to VW).
It is not possible to imagine the success of anything that is not accepted by the non-academic community. Currently most of the non-academic community in the World has little more than high-school degree, little or no fluency in English and earn something like US$1.000,00/month (or less) for a journey of at least 40hours/week (and lots of non payed over-time). So I do think that the two previous paragraphs are relevant aspects to the question of"what is holding back smalltalk?"
Mariano Martinez Peck escreveu:
I am very newbie with smalltalk, but I have some thoughts about this question.
- Markting (someone has already say it)
- Lack of investment (someone has already say it)
- Smalltalk is simple. And, as It says a friend of mine, simplest
things doesn't sell. It might be complex. Complex things are the most sold.
Interesting that I've got other "arguments" against the adoption of smalltalk: "strange" (which can be translated as: "oh my God, where's main(), where's int myDummySomething(...)...) and "confuse" (meaning: where the hell I am supposed to look for references on classes and methods outside the ClassBrowser??? I need some written references for God sake...).
- Companies needs to spend many and spent their budgets
Not that but managers are just cautious to use tools that don't have "certified developers/users". Interesting enough, Linux ascended the sales ranks (at least around here) when companies started to "certify" developers. Not to mention that they started to employ the "black vali$e $ale$people" to counter the other vendors of "Janela$/Ventana$" OS...
- Databases support. Squeak for example, how can be used in many
enterprise projects if there is only driver for mysql and postgres ? and Glorp only with postgres... We did a survey and they are just the 20% of the market (we need support for oracle, mssql, and so on.). Because of this, we are working in SqueakDBX.
- IDE. It has a lot of good things, but also a lot of limitations. I
am very use to use Eclipse. And sometime to miss some features about it.
That's an interesting point because this can lead to a UI model closer to Java: instead of having a dedicated "world", being able to open windows in the native environment (Windows, X-Window, OS-X). Anyways, GNU smalltalk can do that.
- There is no company (in squeak) behind it. Managers, owners,
directors, and so on, many times need this. They need it in order to have someone to blame in case of problems.
But there is a foundation that formerly had support from Apple. A big task is to enhance the support of private ventures to the Squeak Foundation.
cheers,
Mariano
On Fri, 21 Nov 2008 00:02:47 +0100, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention.
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
- Exupery (native x86 methods) powers Huemul - Seaside (web++ framework++) powers GLASS - Hydra (multiple parallel .images) powers Croquet .images - Google hires developers with deep Smalltalk experience - two more gods to be worshipped in the VM temple ;) - Squeak powers NewSpeak - new book Squeak by Example (creative commons license) - port of OpenDBX to Squeak (still not on windoze) - port of Squeak/VM to "another" smartphone platform ;) - DrGeo made it to the XO (OLPC) - fresh new subcommunity Pharo - attempt? to port Moose (world class sw analysis) to Squeak - Google hires developers with deep Smalltalk experience - Squeak web site migrated to/powered by Aida/Web Squeak - 4 (four) projects run through 2008's Goggle Summer of Code - the "everybody needs it" Safara from GSoC as yet not in mainstream - the "everybody needs it" Squeak GTK from GSoC as yet not in mainstream - IBM builds Smalltalk IDE inside Eclipse - Google hires developers with deep Smalltalk experience - ESUG 2008 conference draws more attendands than ever
That list is of course incomplete, for example one wants to add the many noobs who joined #squeak and the beginners mailing list.
I do not think that *soo* much is holding back Smalltalk ;)
/Klaus
I heard that google hired developers with deep Smalltalk experience........
On Nov 21, 2008, at 12:28 AM, Klaus D. Witzel wrote:
On Fri, 21 Nov 2008 00:02:47 +0100, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention.
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
- Exupery (native x86 methods) powers Huemul
- Seaside (web++ framework++) powers GLASS
- Hydra (multiple parallel .images) powers Croquet .images
- Google hires developers with deep Smalltalk experience
- two more gods to be worshipped in the VM temple ;)
- Squeak powers NewSpeak
- new book Squeak by Example (creative commons license)
- port of OpenDBX to Squeak (still not on windoze)
- port of Squeak/VM to "another" smartphone platform ;)
- DrGeo made it to the XO (OLPC)
- fresh new subcommunity Pharo
- attempt? to port Moose (world class sw analysis) to Squeak
- Google hires developers with deep Smalltalk experience
- Squeak web site migrated to/powered by Aida/Web Squeak
- 4 (four) projects run through 2008's Goggle Summer of Code
- the "everybody needs it" Safara from GSoC as yet not in mainstream
- the "everybody needs it" Squeak GTK from GSoC as yet not in
mainstream
- IBM builds Smalltalk IDE inside Eclipse
- Google hires developers with deep Smalltalk experience
- ESUG 2008 conference draws more attendands than ever
That list is of course incomplete, for example one wants to add the many noobs who joined #squeak and the beginners mailing list.
I do not think that *soo* much is holding back Smalltalk ;)
/Klaus
Where did you hear that?
- Bert -
On 21.11.2008, at 10:47, Steven W Riggins wrote:
I heard that google hired developers with deep Smalltalk experience........
On Nov 21, 2008, at 12:28 AM, Klaus D. Witzel wrote:
On Fri, 21 Nov 2008 00:02:47 +0100, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention.
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
- Exupery (native x86 methods) powers Huemul
- Seaside (web++ framework++) powers GLASS
- Hydra (multiple parallel .images) powers Croquet .images
- Google hires developers with deep Smalltalk experience
- two more gods to be worshipped in the VM temple ;)
- Squeak powers NewSpeak
- new book Squeak by Example (creative commons license)
- port of OpenDBX to Squeak (still not on windoze)
- port of Squeak/VM to "another" smartphone platform ;)
- DrGeo made it to the XO (OLPC)
- fresh new subcommunity Pharo
- attempt? to port Moose (world class sw analysis) to Squeak
- Google hires developers with deep Smalltalk experience
- Squeak web site migrated to/powered by Aida/Web Squeak
- 4 (four) projects run through 2008's Goggle Summer of Code
- the "everybody needs it" Safara from GSoC as yet not in mainstream
- the "everybody needs it" Squeak GTK from GSoC as yet not in
mainstream
- IBM builds Smalltalk IDE inside Eclipse
- Google hires developers with deep Smalltalk experience
- ESUG 2008 conference draws more attendands than ever
That list is of course incomplete, for example one wants to add the many noobs who joined #squeak and the beginners mailing list.
I do not think that *soo* much is holding back Smalltalk ;)
/Klaus
On Fri, 21 Nov 2008 10:55:24 +0100, Bert Freudenberg wrote:
Where did you hear that?
Yes, interesting question :)
FWIW in 2006 I found that Google advertises that using their own system
- http://www.google.com/search?hl=en&q=smalltalk&gl=US
It' still there, refresh you browser until you can see one of their Smalltalk ads like this one
Smalltalk at Google? Dig SmallTalk & object oriented design? Get a Java XP job at Google www.google.com/jobs/
/Klaus
- Bert -
On 21.11.2008, at 10:47, Steven W Riggins wrote:
I heard that google hired developers with deep Smalltalk experience........
On Nov 21, 2008, at 12:28 AM, Klaus D. Witzel wrote:
On Fri, 21 Nov 2008 00:02:47 +0100, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention.
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
- Exupery (native x86 methods) powers Huemul
- Seaside (web++ framework++) powers GLASS
- Hydra (multiple parallel .images) powers Croquet .images
- Google hires developers with deep Smalltalk experience
- two more gods to be worshipped in the VM temple ;)
- Squeak powers NewSpeak
- new book Squeak by Example (creative commons license)
- port of OpenDBX to Squeak (still not on windoze)
- port of Squeak/VM to "another" smartphone platform ;)
- DrGeo made it to the XO (OLPC)
- fresh new subcommunity Pharo
- attempt? to port Moose (world class sw analysis) to Squeak
- Google hires developers with deep Smalltalk experience
- Squeak web site migrated to/powered by Aida/Web Squeak
- 4 (four) projects run through 2008's Goggle Summer of Code
- the "everybody needs it" Safara from GSoC as yet not in mainstream
- the "everybody needs it" Squeak GTK from GSoC as yet not in
mainstream
- IBM builds Smalltalk IDE inside Eclipse
- Google hires developers with deep Smalltalk experience
- ESUG 2008 conference draws more attendands than ever
That list is of course incomplete, for example one wants to add the many noobs who joined #squeak and the beginners mailing list.
I do not think that *soo* much is holding back Smalltalk ;)
/Klaus
On 21.11.2008, at 11:30, Klaus D. Witzel wrote:
On Fri, 21 Nov 2008 10:55:24 +0100, Bert Freudenberg wrote:
Where did you hear that?
Yes, interesting question :)
FWIW in 2006 I found that Google advertises that using their own system
It' still there, refresh you browser until you can see one of their Smalltalk ads like this one
Smalltalk at Google? Dig SmallTalk & object oriented design? Get a Java XP job at Google www.google.com/jobs/
Ah great.
Heh, interestingly "One Laptop per Child" is one of the sponsored ads when you google for "Smalltalk" but not for "Python".
- Bert -
On Fri, 21 Nov 2008 11:43:07 +0100, Bert Freudenberg wrote:
On 21.11.2008, at 11:30, Klaus D. Witzel wrote:
On Fri, 21 Nov 2008 10:55:24 +0100, Bert Freudenberg wrote:
Where did you hear that?
Yes, interesting question :)
FWIW in 2006 I found that Google advertises that using their own system
It' still there, refresh you browser until you can see one of their Smalltalk ads like this one
Smalltalk at Google? Dig SmallTalk & object oriented design? Get a Java XP job at Google www.google.com/jobs/
Ah great.
Heh, interestingly "One Laptop per Child" is one of the sponsored ads when you google for "Smalltalk" but not for "Python".
Yes, this is quite tricky with the AdWords system. I stumbled upon Google's Smalltalk ad when I attempted to donate some money for advertising the Squeak Smalltalk keywords with the AdWords system.
Unfortunately I had to give up coming into the ranks when "suddenly" "somebody" put in bids for the Smalltalk keyword with a US$ 4 price-per-click tag on them (reminds me to check the current bids once in a while).
I can only speculate that price tag has something to do with what you observed for Python+OLPC.
/Klaus
- Bert -
On Fri, Nov 21, 2008 at 2:30 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Smalltalk at Google? Dig SmallTalk & object oriented design? Get a Java XP job at Google www.google.com/jobs/
Interesting tactic. If you take the link, you'll see that smalltalk is not mentioned in the job description.
On Fri, 21 Nov 2008 18:04:05 +0100, Brad Fuller wrote:
On Fri, Nov 21, 2008 at 2:30 AM, Klaus D. Witzel wrote:
Smalltalk at Google? Dig SmallTalk & object oriented design? Get a Java XP job at Google www.google.com/jobs/
Interesting tactic. If you take the link, you'll see that smalltalk is not mentioned in the job description.
Right, you hit the nail on its head.
They seem to "only" want the best people, not necessarily willing to then let them do the best, FWIW.
/Klaus
Heh, we know a few people that are/were Smalltalkers and even Squeaker(s) at Google (like Lex and Nathanael), but do we know who are new hires?
-- Yoshiki
Klaus D. Witzel wrote:
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
Why would one not expect this community for Ruby or Python or Perl? Could you please explain what you mean, for this puzzles me ...
I agree and find the "us" vs "them" attitude to be unhealthy.
One should be able to define oneself without comparison to others.
On Nov 21, 2008, at 12:23 PM, Claus Kick wrote:
Klaus D. Witzel wrote:
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
Why would one not expect this community for Ruby or Python or Perl? Could you please explain what you mean, for this puzzles me ...
I agree and find the "us" vs "them" attitude to be unhealthy. One should be able to define oneself without comparison to others.
One better attitude is to consider complementary and not "vs." e.g. the comparation is not valid.
There is not right/wrong answers when the question is incorrect.
Smalltalkers do not need to answer why we has had our history to people that do not have a history yet.
Each time we compare smalltalk to new formulas (new languages, new platforms, new ooxxx++ -now more object oriented- ) we loose our small resources trying to reformulate our peculiarities to be something we are not.
Why do not try to invest our time and efforts in the undeveloped direction of Object Technology (a la smalltalk) ? as was proposed at first years of Squeak project.
We are too near the sea because we are making the smalltalk globe go down.
Focusing the on the peculiarities of smalltalk way (not the tools, nor the environment, nor it contents, but the activities smalltalk make possible) can be more valuable and will make people reflect about what they are really doing when they write "the same" in other syntax...
Each time we compare, we loose. Each time we put ourselves in front of another alternative (for others) we loose.
IMHO, it is better to feel "complementary to the normal people"; e.g. preserve our personality (a model we built/grow with smalltalk, not only a POV). As any complement we do not compete with other proposals for "system" development (I must say here system definition). Smalltalk IS marginal, and it is a lot of oportunities at the margins in this "empty world" [*].
have fun, and preserve our way, Ale.
[*] As a by product of OO method, any de-composition of the world produce more vacum (uncertanty) that definitions.
----- Original Message ----- From: "Steven W Riggins" mailinglists@geeksrus.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Friday, November 21, 2008 5:37 PM Subject: Re: [squeak-dev] Nothing much [was: what is holding back Smalltalk?]
I agree and find the "us" vs "them" attitude to be unhealthy.
One should be able to define oneself without comparison to others.
On Nov 21, 2008, at 12:23 PM, Claus Kick wrote:
Klaus D. Witzel wrote:
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
Why would one not expect this community for Ruby or Python or Perl? Could you please explain what you mean, for this puzzles me ...
On Fri, 21 Nov 2008 21:23:13 +0100, Claus Kick wrote:
Klaus D. Witzel wrote:
Me thinks that the Smalltalk community is healthy and vibrant--it is "just" a community form one would not expect for Ruby or Python or Perl, etc. To get impression of my impression take a look at what *actually* happened during the *recent* months:
Why would one not expect this community for Ruby or Python or Perl? Could you please explain what you mean, for this puzzles me ...
There are (almost uncountable ;) many things which shape these communities; perhaps I focus on some of the obvious from a day-to-day perspective:
- starting+using Smalltalk is always starting+using the whole system, there are no parts, in an absolute sense, and there is no way to change that
- the Smalltalker has generally broader knowledge about his *whole* system, think of navigating "implementers of" as an example
- the Smalltalker has generally deeper knowledge about his *whole* system, think of navigating "senders of" as an example
This (and more ;) naturally orients the community along completely different dimensions, beginning with the learning curve, through things you can change+reuse, up to things you can achieve (like VMMaker+Simulator or Etoys or Scratch or Croquet or Moose or DabbleDB or Sophie), with a handful of people, in the Smalltalk community.
/Klaus
I think, partially, Smalltalk has never reached a kind of critical mass to attract widespread attention from non CS geeks.
Part of the problem is also the slight lack of easy deployability, as already mentioned. However, I think the seeds are already sown, e.g. for browser accessed-apps that can be dynamically tinkered with.
Imagine a Croquet world accessed through today's web browser where everything is editable in Smalltalk... I'm sure that would be something of a killer app. I think the Second Life etc models don't have nearly as clean or open an architecture to rival it.
The other problem is that Squeak has been behind the curve (probably because of available resources!) to interface with "hot" topics e.g. 3D rendering, video, databases. There have usually been more mature and readily available libraries in less elegant languages.
I think the whole "reinvention of computing" effort is ripe for fruition, though - particularly as smaller, cheaper mobile devices become ubiquitous. Smalltalk could easily exploit it's agility in these areas, and I think this is indeed happening. We need a Smalltalk phone now, dammit! It would only be a matter of time before the brighter kids are hacking in Smalltalk, and then the world is set for a revolution.
Ryan
Mark Volkmann mark@ociweb.com writes:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it?
They're not very smart.
What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
Say it was made by Microsoft.
Sure I'm being a little sarcastic, but I'm not far off.
I replied separately, but if you are interested in researching what "experienced Smalltalkers see as some of the reasons why it doesn't attract more attention" you should also search the list archives. This is a bit of a permathread.
I recommend searching for the term 'marketing' or 'success'
marketing site:http://lists.squeakfoundation.org/pipermail/squeak-dev/
On Thu, Nov 20, 2008 at 5:02 PM, Mark Volkmann mark@ociweb.com wrote:
I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.
I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?
For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.
Mark Volkmann
squeak-dev@lists.squeakfoundation.org
-
Alan Grimes -
Alejandro F. Reimondo -
Andreas Wacknitz -
Antony Blakey -
Bert Freudenberg -
Blake -
Brad Fuller -
Casimiro de Almeida Barreto -
Claus Kick -
Colin Putney -
Danie Roux -
David Mitchell -
David Pennell -
David Zmick -
Emilio Oca -
Ian Trudel -
Igor Stasenko -
Janko Mivšek -
Jecel Assumpcao Jr -
jhallman＠frb.gov -
Jon Hylands -
Karl Ramberg -
Keith Hodges -
Klaus D. Witzel -
Mariano Martinez Peck -
Mark Volkmann -
Martin Beck -
merlyn＠stonehenge.com -
Michael van der Gulik -
nico -
Paolo Bonzini -
Rob Rothwell -
Ryan Mitchley -
Sophie (itsme213) -
Steven W Riggins -
Yoshiki Ohshima