[squeak-dev] what is holding back Smalltalk?

Janko Mivšek wrote: 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

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

"Igor Stasenko" <[hidden email]> 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:

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 -

Mark Volkmann <[hidden email]> 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.

--
Jeff

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

> 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

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 <[hidden email]> wrote:

> 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

> 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 <[hidden email]> 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 - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <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

Randal L. Schwartz wrote:
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

> to be relicensed all code written by former employees of OTI, Cincom,
        ^^^^^^^^^^

rewritten.

Paolo

On Fri, Nov 21, 2008 at 2:30 AM, Klaus D. Witzel <[hidden email]> 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.

--
Brad Fuller

I feel compelled to share another perspective on the importance of licenses:

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

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

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.

Jecel Assumpcao Jr escreveu:
> (...)
> 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
>  
About that I have an interesting anedocte: in 1998 I was working for the
"Department of Education of São Paulo State" (SEESP) under UNDP
contract. There, people were having hard times trying to implement a
system for the management of schools. That system would feed other
systems at the "Department" so the person in charge ("Secretary of
Education") would have real time data about schools (including student
performance, teachers performance, etc). The problem itself is simple
and, from the tech point of view, the system should not be complicated.

So, where was the trouble? Easy: the "Department" board kept issuing
incredible specifications for the system. So, it was not enough that the
goals were achieved, but the system should be "up to date with the best
in the world" (what the hell did that meant????!!!!). In short: some
people didn't want any system controlling their lack of competence and
bombed the initiative through rejecting specifications and issuing over
and over more complex and unintelligible ones.

Years later an auditing consultant observed that the best way of keeping
the status quo is always demanding the excellent even when you don't
have the satisfactory. SpringOS... :( Now they face the reality of selling mostly Intel servers
running RedHat Linux...

Am 21.11.2008 um 19:23 schrieb Claus Kick:

[stuff deleted] 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