STIC General Meeting

Throwing around numbers that anybody can just make up isn't going to stop the bleeding. Smalltalk isn't evolving and that's why everybody is converting to Java and .NET. It's time for STIC to do some emergency triage, because the patient is fading fast.

However, Smalltalk suffers from one problem: no real Multi-Threading support.

Sure having separate images bound to separate cores (CPUs) does help, but it is something to be done manually hence slow. In Java, for instance, you just do "public class myClass implements Runnable" then call start() .

Something like that is missing, preferably in a generic way working for all Smalltalk dialects.

Claus

http://www.smalltalkindustrycouncil.com/ 

responds with: 502 Bad Gateway

Here's part of the page-long caveat emptor listed on SPR's (Capers Jones') website

In our consulting practice, we can observe no consistent, discrete, definitive relationship of logical source statements to function points that has universal application. ...

Just remember: as with so many other things in life, if it seems too good to be true, it probably is.

errors per function point
Those are the same numbers Ed Klimas presented at Smalltalk Solutions '99 - were the lines of code per function point numbers the same as well?

You are comparing the Java language to the Smalltalk language, and that is not how the comparison should be made any more.  You need to compare the productivity of developers as they acutally work.  This means Smalltalk with the Refactoring Browser, and Java with Eclipse.  Smalltalk is a great language with a good IDE.  Java is an ok lanaguage with a great IDE.  I have found that Java/Eclipse is a very productive environment.

 Sorry, guys. 

Problem is so many people are using the ok java language with eclipse that they begin to feel eclipse is great.

It's not. At least not if you've used smalltalk or other greater-than-ok languages.

Sorry guys.

Patrick, the problem is desperately grabbing at voodoo lines of code per function point numbers as though Smalltalk has been written with Notepad over the last 30 years, as though Java code is written with Notepad now.

"In Java with modern tools, I'd guess that I actually type less than one character out of twenty that shows up in the source, and I rarely retype anything. Bugs tend to congregate in places where I had to do the typing, and cluster especially strongly in places I had to retype."

IntelliJ

Comment by James Robertson

Regardless of who does the typing - you or the tool - more lines of code will mean more bugs. Just as more lines of prose will mean more grammatical errors...

Maybe that's true in Smalltalk, where you have to type everything, and you don't see your errors until you try to run.  In Eclipse, I don't have to type everything; Eclipse will type stuff for me.  And if I make a mistake, Eclipse will tell me instantly what, and precisely where, my mistake is.  You can trash static typing all you want, but it does reduce errors, and reduce development time.  There may be more lines of code.  I'll grant that.  But it was long ago that we stopped measuring lines of code for anything.  Didn't you guys get the memo?

Comment by Michael Lucas-Smith

We're not talking about typos here. We're talking about semantic/logical errors in what the program does. If you do a loop over a tree structure - did you get it right? .. if it's a single call to say "do the loop" then you're safe. If you hand code that loop every time you do it then you're not safe. It's about encapsulation of patterns. The more expressive your language is, the less code you have to write to achieve the same functionality with a lower likelihood of making a mistake.

I'm pointing out something simple - and if you care to deny that more actual lines of code will contain more actual bugs, I'll have to consider you delusional. Do you also believe that Eclipse and/or IntelliJ obviate the need for testing?

Ok, Michael, you are right.  Every single IT manager on this planet who has made the decision to use Java, and not Smalltalk, in their shop, is totally wrong.  Their thought processes are broken.  They cannot see the obvious benefits of Smalltalk.  They cannot see the obvious drawbacks to Java.  They cannot see the obvious drawbacks to Eclipse.  They should all be fired.  Only the Smalltalk devotees are right.

And James, you are putting words in my mouth.  Well, not in my mouth; in my comment box.  Of course you need to test.  Nobody has ever claimed differently.   I am saying that the automatic while-I-type type checking that Eclipse provides will eliminate the syntactical testing I have to do.  It eliminates a lot of the Homer Simpson "D-OH!" moments in my first few live tests, where I pass a Double into a method that expects a String.   I still need to test to ensure that my program meets the requirements of the business.  That is necessary regardless of what language you use.  Obviously.  Even Rails, the "Next BigThing"(tm), requires testing.  Whoever comes up with a language that doesn't require testing, will become a billionaire overnight.  Hasn't happened yet.  I suspect it won't.

Comment by James Robertson

Developers and Managers tend to engage in a lot of "herd" behavior - I suppose this extends beyond software, for that matter. "Whatever most people are doing" seems safer. Anything outside that box - regardless of the possible benefits - is too risky.

To be honest, most shops that fail regularly don't do so because they made a bad choice as to language/environment - they fail because their process sucks eggs.

Comment by Michael Lucas-Smith

So thanks for putting words in /my/ mouth there 'anonymous'.

Michael Lucas-Smith wrote If you hand code that loop every time you do it then you're not safe. It's about encapsulation of patterns.
Thank you for giving a specific example.

Now why should we think that someone writing in Java would be more likely to "hand code that loop every time" (instead of writing an Iterator and using it) compared to someone writing in Smalltalk?

(Maybe the Java programmer would just use the Eclipse AbstractTreeIterator.)

Comment by anonymous

The correct URL is http://www.smalltalkindustrycouncil.org

Isaac,

Probably because most Smalltalk programmers think the way you loop through a collection in Java is like so:

for (int ix0; ix < aColl.size(); ix++)

{  MyObject myObject = (MyObject)aColl.get(ix) ;

   myObject.doSomething(); }

And that used to be the way it was done, because that's how it was done in C and Java descended from C.  You typically do it like this now:

Iterator anIterator = aColl.iterator() ;

while (anIterator.hasNext() )

{  MyObject myObject = (MyObject)anIterator.next() ;

   myObject.doSomething(); }

That seems much cleaner.  And more object-oriented.

Comment by David Buck

Equivalent Smalltalk:

aColl do: [:each | each doSomething]
 

It seems even cleaner and even more object oriented.

David, I don't see how that helps demonstrate Michael's comment about encapsulation of patterns.

Neither do I.  If your point is that Smalltalk can do the same thing in fewer lines of code, then let's just use Lisp and be done with it.

As Java 5 appeared in 2004, maybe these days a Java programmer would write something like

   for (MyObject myObject : aColl) myObject.doSomething();

Isaac,

Cool, I never even knew this.