[vwnc] Would you start a new Smalltalk project today?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[vwnc] Would you start a new Smalltalk project today?

David Finlayson-4
I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,

David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Dennis smith-4
I will respond to some of this.

Re costs -- VW does not charge deployment costs???

GUI -- yes it has a few problems -- hopefully they will get
    partially corrected soon.  On the other hand, we and
    clients we deal with seem more interested in our Seaside
    UI (which is not yet 100% complete).  On the other hand
    again, I see two things here
          look -- what does a field or button look like.  There
                   are some 3rd party looks that work on that
          what you can do -- with a bit of work one can do just
                   about anything.  I have snap on/off toolbars,
                   configurable fields and buttons etc etc.


Re would I start in Smalltalk today? the answer is
    YES -- its great has been great and continues to be great -- we love it, it
                does good things for our users.
    NO -- we sell custom software to users -- in the past few years, and
                still somewhat, users (or more exactly consultants hired by users)
                don't like "Smalltalk", and we get a lower rating because of that.

For ME I would choose ST any day.  For our marketing people, I would not.

David Finlayson wrote:
I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,

David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

James Robertson-7
In reply to this post by David Finlayson-4
While I understand your issue with licensing, this is actually a pretty hard problem.  If you don't have very large sales volume, per developer fees aren't a sustainable way to run a tools business - you can't really support a development staff.

I'd love to hear a contrary view that made business sense :)


James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library




On Mar 17, 2009, at 5:33 PM, David Finlayson wrote:

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,

David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

James Robertson-7
We have a profitable business now, with growing revenues and a growing customer base.  Thus, trying to make a case to mgmt that they should start accepting losses would be pretty darn hard....


James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library




On Mar 17, 2009, at 6:39 PM, Victor wrote:

>    If you don't have very large sales volume, per developer fees aren't a sustainable way to run a tools business
 
My opinion is that the argument is valid when you are in a stable and favorable market.  However, if you want to start a new market, it's important to accept the initial losses as an investment in the future.  Otherwise the new market will never be developed and the entrepreneur will not be in the future any better than at the starting point.  This is a general philosophical approach, which should be accepted before engaging in any commercial activity.  The details are then generated from the market realities and what the tools have to offer.  If either the development or marketing are frozen for whatever reasons, it's difficult to be optimistic about the product's future.
 
Victor
 

----- Original Message -----
Sent: Tuesday, March 17, 2009 6:02 PM
Subject: Re: [vwnc] Would you start a new Smalltalk project today?

While I understand your issue with licensing, this is actually a pretty hard problem.  If you don't have very large sales volume, per developer fees aren't a sustainable way to run a tools business - you can't really support a development staff.

I'd love to hear a contrary view that made business sense :)


James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library




On Mar 17, 2009, at 5:33 PM, David Finlayson wrote:

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,

David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

david.long
nice one James.
awesome.
David

On Tue, 2009-03-17 at 18:45 -0400, James Robertson wrote:
We have a profitable business now, with growing revenues and a growing customer base.  Thus, trying to make a case to mgmt that they should start accepting losses would be pretty darn hard....



James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library







On Mar 17, 2009, at 6:39 PM, Victor wrote:

>    If you don't have very large sales volume, per developer fees aren't a sustainable way to run a tools business
 
My opinion is that the argument is valid when you are in a stable and favorable market.  However, if you want to start a new market, it's important to accept the initial losses as an investment in the future.  Otherwise the new market will never be developed and the entrepreneur will not be in the future any better than at the starting point.  This is a general philosophical approach, which should be accepted before engaging in any commercial activity.  The details are then generated from the market realities and what the tools have to offer.  If either the development or marketing are frozen for whatever reasons, it's difficult to be optimistic about the product's future.
 
Victor
 

----- Original Message -----
From: [hidden email]
To: [hidden email]
Sent: Tuesday, March 17, 2009 6:02 PM
Subject: Re: [vwnc] Would you start a new Smalltalk project today?


While I understand your issue with licensing, this is actually a pretty hard problem.  If you don't have very large sales volume, per developer fees aren't a sustainable way to run a tools business - you can't really support a development staff.


I'd love to hear a contrary view that made business sense :)




James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library







On Mar 17, 2009, at 5:33 PM, David Finlayson wrote:

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,


David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc







_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Gregory Bourassa-3
In reply to this post by David Finlayson-4
Hi David,

I would absolutely choose Smalltalk for new development.   That's my 2 cents worth.   Here are more specific responses to your posting (which is, by the way, amusing and interesting).

"best days are behind it" -- probably not, and language popularity is a non-issue as long as their is a stable vendor and/or an open-source version.

1. multi-core strategy -- language constructs for multi-processing are overrated.   Use inter-process communication, and use the OS to distribute processes.    This is much more robust and secure than threaded models.   We recently tested VW sockets on some pretty run-of-the-mill Linux boxes and found we could do 10,000+ round-trip messages per second, with enough bytes on board each message to be representative of reasonable interprocess messages.    You also have the choice of OpenTalk for IPC.    For the record, I am a curmudgeon when it comes to "distributed objects everywhere", regardless of the language;  instead, I think you will be well-served by defining the boundaries of your multiple processes (even if all are identical images), and defining the messages they send and receive.   This is better than all the language support for threading and multi-core, and it is language-neutral.

2. GUI -- We are introducing some Cairo and Pango capabilities into our applications, based on things either already in VW or soon-to-be-released.   This makes the finish of our UIs every bit as clean, smooth, and modern as the alternatives.  You can build anything you can dream up in the way of UI widgets.   I agree that the UI-painting tools fall a little short...it would be nice to have a version that was Announcement-aware, and that had direct support for a richer set of connections with the business models.     Not sure you really get anything better on those points in other languages, though. (?)

3.  Cost structure.  Sorry, I can't comment much.   Any chance of using the non-commercial for "skunk works" and only incurring the license fees when you have proved value to your organisation?

Regards.

Gregory Bourassa

======================================================

David Finlayson wrote:
I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,

David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Key Technology, Inc. Disclaimer Notice - The information and attachment(s) contained in this communication are intended for the addressee only, and may be confidential and/or legally privileged. If you have received this communication in error, please contact the sender immediately, and delete this communication from any computer or network system. Any interception, review, printing, copying, re-transmission, dissemination, or other use of, or taking of any action upon this information by persons or entities other than the intended recipient is strictly prohibited by law and may subject them to criminal or civil liability. Key Technology,  Inc. is not liable for the improper and/or incomplete transmission of the information contained in this communication or for any delay in its receipt.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

david.long
Smalltalk rules!

d
On Tue, 2009-03-17 at 16:03 -0700, Gregory Bourassa wrote:
Hi David,

I would absolutely choose Smalltalk for new development.   That's my 2 cents worth.   Here are more specific responses to your posting (which is, by the way, amusing and interesting).

"best days are behind it" -- probably not, and language popularity is a non-issue as long as their is a stable vendor and/or an open-source version.

1. multi-core strategy -- language constructs for multi-processing are overrated.   Use inter-process communication, and use the OS to distribute processes.    This is much more robust and secure than threaded models.   We recently tested VW sockets on some pretty run-of-the-mill Linux boxes and found we could do 10,000+ round-trip messages per second, with enough bytes on board each message to be representative of reasonable interprocess messages.    You also have the choice of OpenTalk for IPC.    For the record, I am a curmudgeon when it comes to "distributed objects everywhere", regardless of the language;  instead, I think you will be well-served by defining the boundaries of your multiple processes (even if all are identical images), and defining the messages they send and receive.   This is better than all the language support for threading and multi-core, and it is language-neutral.

2. GUI -- We are introducing some Cairo and Pango capabilities into our applications, based on things either already in VW or soon-to-be-released.   This makes the finish of our UIs every bit as clean, smooth, and modern as the alternatives.  You can build anything you can dream up in the way of UI widgets.   I agree that the UI-painting tools fall a little short...it would be nice to have a version that was Announcement-aware, and that had direct support for a richer set of connections with the business models.     Not sure you really get anything better on those points in other languages, though. (?)

3.  Cost structure.  Sorry, I can't comment much.   Any chance of using the non-commercial for "skunk works" and only incurring the license fees when you have proved value to your organisation?

Regards.

Gregory Bourassa

======================================================

David Finlayson wrote:
I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,


David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]




_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



Key Technology, Inc. Disclaimer Notice - The information and attachment(s) contained in this communication are intended for the addressee only, and may be confidential and/or legally privileged. If you have received this communication in error, please contact the sender immediately, and delete this communication from any computer or network system. Any interception, review, printing, copying, re-transmission, dissemination, or other use of, or taking of any action upon this information by persons or entities other than the intended recipient is strictly prohibited by law and may subject them to criminal or civil liability. Key Technology,  Inc. is not liable for the improper and/or incomplete transmission of the information contained in this communication or for any delay in its receipt.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Terry Raymond
In reply to this post by David Finlayson-4

David

 

I am working on a product that incorporates a distributed database

across multiple processors, even in the 100s of processors. It does

so by running multiple images. While it may not seem as nice as

having one image run in multiple cores it side-steps some of the hard

issues and is more scaleable. If you can distribute your work among

multiple images running on multiple machines you can scale much

better than if you are restricted to one machine running on multiple cores.

 

I don’t see the lack of a modern looking GUI as a problem as much

as the difficulty in not being able to easily incorporate 3rd-party widgets.

 

It is difficult to say if Smalltalk is the way to go for your project. But,

at one time I worked on some projects involving simulation. The big

concern of many people was how fast will the simulation run. But when

you really examined how the software was used, much more time was

used in developing and testing and doing trial runs than doing a full

simulation. So, being able to easily modify the software was more

important than how fast it ran.

 

So, I would say if your monitors are going to run for years and use

a lot of CPUs, then maybe it is better to use something like C++. But,

if they are only going to be used for a few months and under go a lot

of modification, then maybe smalltalk is the better choice.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================


From: [hidden email] [mailto:[hidden email]] On Behalf Of David Finlayson
Sent: Tuesday, March 17, 2009 5:33 PM
To: vwnc
Subject: [vwnc] Would you start a new Smalltalk project today?

 

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,

 

David


-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Antony Blakey-2
In reply to this post by David Finlayson-4
I am a commercial user of VW.

I've recently replaced my VW/GLORP/Postgresql app with one built in  
Ruby/CouchDB. I moved to Ruby because the documentation/learning  
material is superior to VW, because of the number of third party  
components, which is partly an issue of VW not being Open Source,  
because of tools such as Rails, Sinatra and Merb (which I still prefer  
over Seaside), and because I needed to focus on sustainable technology  
transfer into a market that won't accept VW. Tangentially I wanted to  
(subjectively) quantify the productivity improvement due to Smalltalk  
relative to another dynamic language (as opposed to Java in Eclipse).

My experience with Ruby is that the language itself is just too much  
of a hack, and this was especially brought home to me when I started  
doing Scala and Clojure, and that emphasized for me the beauty of  
Smalltalk and Lisp/Scheme.

I'm going back to Smalltak for new commercial development, partly  
because of this, but also because a) the Squeak community is getting a  
real injection of energy with Cog and Pharo (which itself pushes  
Squeak) and b) I'm getting a good feeling about the way the Cincom  
team is changing VW - not only what they're doing, but there seems to  
be a much clearer vision and approach that when I first encountered it.

I'm also building a commercial application in Scala and Clojure. Both  
are great languages, especially for highly concurrent apps, and the  
library support is huge because they seamlessly use Java. If this were  
the "good old days"(TM) I'm sure someone would be working on decent  
concurrency support for Smalltalk. Using multiple images is one  
approach, but not one that I like - it seems (IMHO) to be a reaction  
to the lack of resources to do something better. Most of the Erlang/
Scala/Clojure goodness could be layered into Smalltalk if someone had  
the will to do so, but I think Cincom would have to do that for it to  
get the wide support it would need to have a dependable future.

One benefit that a JVM language has, as opposed to Smalltalk, is that  
both the underlying performance improves, and the available libraries  
increase and improve independently of the language. Clojure and Scala  
don't need effort per se to improve. Oh for a Smalltalk running on the  
JVM in a high performance manner, with JVM object model integration. I  
think there is no other way to solve this problem for Smalltalk.

I really miss programming in an image despite the pain of the Object/
Subject problem. I don't think it's *always* more productive than  
Scala or Clojure (esp for concurrency) but it's more *consistently*  
productive.

Smalltalk's decline has not been terminal, implementations are  
improving albeit more slowly than one would like, and as long as it's  
the right tool for the job then you should use it.

On 18/03/2009, at 8:03 AM, David Finlayson wrote:

> Clojure has some great ideas but you need to know Lisp and Emacs.

Both Scala and Clojure have good and improving support in (to varying  
degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM  
required. I use Clojure and Scala in IntelliJ, and I've done so in  
Eclipse as well.

> 2. No Smalltalk I've used has a decent GUI. Squeak is an  
> abomination, down the road Pharo may be good, but not today and VW  
> looks like it hasn't been updated since the NT days. Although  
> everyone hates Java cross-platform desktop apps, it is interesting  
> to compare a VW app (say Bottom Feeder) to a Java app of similar  
> design (http://www.rssowl.org/overview). In my opinion the Java  
> version fits in a lot better than the VW version (particularly on  
> the Mac).

For VW, my LinkuisticsUI bundle in the public Store improves the  
situation somewhat on OSX for VW 7.6. Cincom are also making  
improvements to the OSX UI for 7.7.

Closure and Scala have Swing integration. Scala has very good SWT  
bindings. All three IDEs have GUI builders.

Maybe you should consider a Web UI - checkout tools such as Capuccino  
and efforts like bespin.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

A reasonable man adapts himself to suit his environment. An  
unreasonable man persists in attempting to adapt his environment to  
suit himself. Therefore, all progress depends on the unreasonable man.
   -- George Bernard Shaw


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

skrish
In reply to this post by David Finlayson-4
My two cents..

2009/3/18 David Finlayson <[hidden email]>
In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

Skrish: How does Groovy fit in along with Java as its backup enterprise framework. Not currently as mature as anything comparable, but with the ability to go along with Java, native bytecode compilation and fairly rapid when it comes to belting out classes/methods.. (which if required someone else can convert it to core Java..or leave it as compiled classes/jar files ). Take Groovy with Spring, future seems good for it to go..

 3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

   Skrish Moot point will be the TCO calculations, Invariably Java dev works out lot more expensive with the number of developers required for an enterprise project, but still is accepted for various other reasons.. 

   Especially if you are short of hands, and all hands on deck are expert programmers, I guess Smalltalk ( VW) is the best bet.

  

Cheers,

David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Andres Valloud-6
In reply to this post by david.long
I've been programming since I was 10.  I have yet to see / experience anything that gives me a stronger ability to take my ideas and put them to work.  I believe this is of value to customers.  Perhaps the issue is that average tools produce average results, and that leads to average expectations.  I wouldn't be surprised myself if a potential customer was a bit skeptical about our claims in that they are not your everyday, average assertions.  However, my experience (and that of my / our customers) tells me otherwise.
 
Andres.


From: [hidden email] [mailto:[hidden email]] On Behalf Of david
Sent: Tuesday, March 17, 2009 4:55 PM
To: Gregory Bourassa
Cc: vwnc
Subject: Re: [vwnc] Would you start a new Smalltalk project today?

Smalltalk rules!

d
On Tue, 2009-03-17 at 16:03 -0700, Gregory Bourassa wrote:
Hi David,

I would absolutely choose Smalltalk for new development.   That's my 2 cents worth.   Here are more specific responses to your posting (which is, by the way, amusing and interesting).

"best days are behind it" -- probably not, and language popularity is a non-issue as long as their is a stable vendor and/or an open-source version.

1. multi-core strategy -- language constructs for multi-processing are overrated.   Use inter-process communication, and use the OS to distribute processes.    This is much more robust and secure than threaded models.   We recently tested VW sockets on some pretty run-of-the-mill Linux boxes and found we could do 10,000+ round-trip messages per second, with enough bytes on board each message to be representative of reasonable interprocess messages.    You also have the choice of OpenTalk for IPC.    For the record, I am a curmudgeon when it comes to "distributed objects everywhere", regardless of the language;  instead, I think you will be well-served by defining the boundaries of your multiple processes (even if all are identical images), and defining the messages they send and receive.   This is better than all the language support for threading and multi-core, and it is language-neutral.

2. GUI -- We are introducing some Cairo and Pango capabilities into our applications, based on things either already in VW or soon-to-be-released.   This makes the finish of our UIs every bit as clean, smooth, and modern as the alternatives.  You can build anything you can dream up in the way of UI widgets.   I agree that the UI-painting tools fall a little short...it would be nice to have a version that was Announcement-aware, and that had direct support for a richer set of connections with the business models.     Not sure you really get anything better on those points in other languages, though. (?)

3.  Cost structure.  Sorry, I can't comment much.   Any chance of using the non-commercial for "skunk works" and only incurring the license fees when you have proved value to your organisation?

Regards.

Gregory Bourassa

======================================================

David Finlayson wrote:
I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,


David

-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



Key Technology, Inc. Disclaimer Notice - The information and attachment(s) contained in this communication are intended for the addressee only, and may be confidential and/or legally privileged. If you have received this communication in error, please contact the sender immediately, and delete this communication from any computer or network system. Any interception, review, printing, copying, re-transmission, dissemination, or other use of, or taking of any action upon this information by persons or entities other than the intended recipient is strictly prohibited by law and may subject them to criminal or civil liability. Key Technology,  Inc. is not liable for the improper and/or incomplete transmission of the information contained in this communication or for any delay in its receipt.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

david.long
In reply to this post by Terry Raymond
Final point score in this discussion:

Smalltalk     3
David           0


On Tue, 2009-03-17 at 20:15 -0400, Terry Raymond wrote:
David

 

I am working on a product that incorporates a distributed database

across multiple processors, even in the 100s of processors. It does

so by running multiple images. While it may not seem as nice as

having one image run in multiple cores it side-steps some of the hard

issues and is more scaleable. If you can distribute your work among

multiple images running on multiple machines you can scale much

better than if you are restricted to one machine running on multiple cores.

 

I don’t see the lack of a modern looking GUI as a problem as much

as the difficulty in not being able to easily incorporate 3rd-party widgets.

 

It is difficult to say if Smalltalk is the way to go for your project. But,

at one time I worked on some projects involving simulation. The big

concern of many people was how fast will the simulation run. But when

you really examined how the software was used, much more time was

used in developing and testing and doing trial runs than doing a full

simulation. So, being able to easily modify the software was more

important than how fast it ran.

 

So, I would say if your monitors are going to run for years and use

a lot of CPUs, then maybe it is better to use something like C++. But,

if they are only going to be used for a few months and under go a lot

of modification, then maybe smalltalk is the better choice.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================



From:[hidden email] [mailto:[hidden email]] On Behalf Of David Finlayson
Sent: Tuesday, March 17, 2009 5:33 PM
To: vwnc
Subject: [vwnc] Would you start a new Smalltalk project today?


 

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,


 


David



-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

James Robertson-7
Before we run off into navel gazing cheerleading, let's recognize that the mere raising of the question indicates that questions exist in the broader community.  Cincom is trying to engage the community as much as it can:

-- our blogs


-- My Twitter feed, and the Cincom Smalltalk one


-- This mailing list

-- The non-commercial download program

-- Smalltalk Daily


The videos are listed on Facebook, in Vimeo, Ning, YouTube, and iTunes

-- Industry Misinterpretations, our weekly podcast


The podcasts are listed in iTunes, Mevio, and Podcast Alley

-- The periodic videos


The videos are listed on Vimeo and in iTunes

We're always open to suggestions and ideas as well.  You can chat directly with me anytime by hitting the chatback widget on my blog




 
James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library




On Mar 18, 2009, at 7:59 AM, david wrote:

Final point score in this discussion:

Smalltalk     3
David           0


On Tue, 2009-03-17 at 20:15 -0400, Terry Raymond wrote:
David

 

I am working on a product that incorporates a distributed database

across multiple processors, even in the 100s of processors. It does

so by running multiple images. While it may not seem as nice as

having one image run in multiple cores it side-steps some of the hard

issues and is more scaleable. If you can distribute your work among

multiple images running on multiple machines you can scale much

better than if you are restricted to one machine running on multiple cores.

 

I don’t see the lack of a modern looking GUI as a problem as much

as the difficulty in not being able to easily incorporate 3rd-party widgets.

 

It is difficult to say if Smalltalk is the way to go for your project. But,

at one time I worked on some projects involving simulation. The big

concern of many people was how fast will the simulation run. But when

you really examined how the software was used, much more time was

used in developing and testing and doing trial runs than doing a full

simulation. So, being able to easily modify the software was more

important than how fast it ran.

 

So, I would say if your monitors are going to run for years and use

a lot of CPUs, then maybe it is better to use something like C++. But,

if they are only going to be used for a few months and under go a lot

of modification, then maybe smalltalk is the better choice.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================



From:[hidden email] [[hidden email]] On Behalf Of David Finlayson
Sent: Tuesday, March 17, 2009 5:33 PM
To: vwnc
Subject: [vwnc] Would you start a new Smalltalk project today?


 

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,


 


David



-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

david.long
Hi James,

well said. I would point out though that the massive marketing budgets available to Microsoft and IBM allow them to place their technology to the forefront regardless of
the underlying level of quality. Just for example, the last release of Windows Vista, by a company with more than 10,000 programmers was by most accounts a failure.
However, as a result of their market position, the current companies controlling the market share (Microsoft / IBM) can still fall below in terms of quality and keep their
position as leaders just because they can outspend the competition in marketing.

I don't think it hurts Smalltalk to defend it vigorously, and in fact - this is needed. People often repeat what they hear just because of effective marketing, not because
the products they advocate are in fact as good as they could be.

Another example is Linux and Windows. Linux has only a handful of known viruses, whereas Windows has created an entire multimillion dollar industry designed around
just patching and defending against viruses. However, Linux is by far the least dominant technology in terms of market share.

So, I'd say that anyone who wants to come into the Smalltalk arena, and start spouting off drivel about the benefits of technology that only exists because of
a large marketing budget deserves what they get, at least on our own turf.

respectfully,

David

On Wed, 2009-03-18 at 08:36 -0400, James Robertson wrote:
Before we run off into navel gazing cheerleading, let's recognize that the mere raising of the question indicates that questions exist in the broader community.  Cincom is trying to engage the community as much as it can:


-- our blogs


http://www.cincomsmalltalk.com/userblogs



-- My Twitter feed, and the Cincom Smalltalk one
http://twitter.com/jarober


http://twitter.com/cincomsmalltalk


-- This mailing list


-- The non-commercial download program


-- Smalltalk Daily


http://smalltalk-daily.cincomsmalltalk.com



The videos are listed on Facebook, in Vimeo, Ning, YouTube, and iTunes



-- Industry Misinterpretations, our weekly podcast


http://industry-misinterpretations.cincomsmalltalk.com



The podcasts are listed in iTunes, Mevio, and Podcast Alley



-- The periodic videos


http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=smalltalk_videos



The videos are listed on Vimeo and in iTunes



We're always open to suggestions and ideas as well.  You can chat directly with me anytime by hitting the chatback widget on my blog


http://www.cincomsmalltalk.com/blog/blogView







 
James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library







On Mar 18, 2009, at 7:59 AM, david wrote:

Final point score in this discussion:

Smalltalk     3
David           0


On Tue, 2009-03-17 at 20:15 -0400, Terry Raymond wrote:
David

 

I am working on a product that incorporates a distributed database

across multiple processors, even in the 100s of processors. It does

so by running multiple images. While it may not seem as nice as

having one image run in multiple cores it side-steps some of the hard

issues and is more scaleable. If you can distribute your work among

multiple images running on multiple machines you can scale much

better than if you are restricted to one machine running on multiple cores.

 

I don’t see the lack of a modern looking GUI as a problem as much

as the difficulty in not being able to easily incorporate 3rd-party widgets.

 

It is difficult to say if Smalltalk is the way to go for your project. But,

at one time I worked on some projects involving simulation. The big

concern of many people was how fast will the simulation run. But when

you really examined how the software was used, much more time was

used in developing and testing and doing trial runs than doing a full

simulation. So, being able to easily modify the software was more

important than how fast it ran.

 

So, I would say if your monitors are going to run for years and use

a lot of CPUs, then maybe it is better to use something like C++. But,

if they are only going to be used for a few months and under go a lot

of modification, then maybe smalltalk is the better choice.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================



From:[hidden email] [[hidden email]] On Behalf Of David Finlayson
Sent: Tuesday, March 17, 2009 5:33 PM
To: vwnc
Subject: [vwnc] Would you start a new Smalltalk project today?


 

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,


 


David



-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Isaac Gouy
In reply to this post by david.long

--- On Wed, 3/18/09, david <[hidden email]> wrote:
> Date: Wednesday, March 18, 2009, 4:59 AM
> Final point score in this discussion:
>
> Smalltalk     3
> David           0

Sampling errors are very easy to make.

I replied privately - others may have.



     
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

David Finlayson-4
In reply to this post by David Finlayson-4
Wow! I was surprised this morning to find so many responses. There
were some very thoughtful comments to my questions here. I appreciate
that, especially people who've dipped there toes into other dynamic
languages currently enjoying popularity.

A few comments:

James - I think you are doing a great job promoting CST. I noticed. As
for how to make Smalltalk pay, who can say? All I know is that I want
to try out a few programs in Smalltalk to see if productivity gains
offset the pain of using a niche technology. But my conversation with
your salespeople left me questioning whether it was worth it for the
small projects I had in mind (think cross-platform Visual Basic apps).
Alternative Smalltalks don't exist or have GUIs too weird for my
purposes. Too bad Dolphin is dead. That is pretty close to what I had
in mind (though not cross-platform).

Antony - I really enjoyed reading your comments. I've looked closely
at Clojure and Scala over the past couple of months and agree that JVM
languages have enormous advantages if they can communicate easily with
Java libraries. However, I don't think Clojure is ready for blub
programmers like myself (tools and documentation need to stabilize)
and Scala looks frighteningly complex. The major appeal of Smalltalk
to me is the combined advantages of an easy syntax with a solid
cross-platform strategy. Python and Ruby have the former, but trying
to maintain cross-platform code bases in Python has proved to be very
complicated for our team. Particularly if you need to distribute
non-standard libraries with the code. There are only a couple of us
programing to support about 50 scientists and all their weird
instruments (many of which we build in our shops). By the way, I
looked at your web site and would be very interested to hear (off
list) if you have managed to get Smalltalk communicating with ESRI
products (or other mapping software) that is very close to my domain.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Stefan Schmiedl
On Wed, 18 Mar 2009 11:00:07 -0700
David Finlayson <[hidden email]> wrote:

> Too bad Dolphin is dead. That is pretty close to what I had
> in mind (though not cross-platform).

Dolphin is not dead. It is being moved onto a new foundation.
Also, Andy Bower has posted some video tutorials lately.

http://www.object-arts.com/content/news/excitingNews.html

s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

Joerg Beekmann, DeepCove Labs (YVR)
In reply to this post by David Finlayson-4

Absolutely

 

We build and maintain a Payment Processing platform build using VisualWorks and MS SQL server. I would reconsider several of our technology and architecture choices (some would be no-brainers other harder); but I would not select a different language. We believe the productivity gains offset the disadvantages some people see in Smalltalk. The productivity gains come in two parts:

  • The environment; by this I mean mostly the libraries and tools
  • The ability to model our domain problem abstractly leaving stubs for future directions and smoothly move forward from a simple application to a very complex application. I have to admit we do not follow the mantra of “do the simplest thing that will possibly work” but rather “do the simplest thing that will work for the current problem but can be easily extended to the larger domain”. This as mostly paid off for us.

 

As for the perceived disadvantages:

  1. Lack of multi-core strategy; we are actually moving to a multi image strategy this works for us because we then let each image hand different aspects of the business problem. We are not really running a compute farm so we don’t have that issue. But even if we needed to make use of multiple cores to solve some compute intensive problem I suspect there would be ways to attack this without too much effort.
  2. We have not had a concern about the GUI stemming from its look. Our bugs yes, our design yes but look and feel of the widgets with very few exceptions no. The exceptions tend to be things that jus suck not because of the widgets are emulated but because nothing has been done to improve them while other projects went on. Our public facing application runs on Seaside so it is not an issue there.
  3. Cost structure; in our specific case the cost of VW is comparable to other tools and software we use. Moreover the savings make up for it.

 

Joerg

 

 

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of David Finlayson
Sent: Tuesday, March 17, 2009 2:33 PM
To: vwnc
Subject: [vwnc] Would you start a new Smalltalk project today?

 

I've been lurking on this list for more than a year now (Squeak and Pharo, too). I've taught myself Smalltalk from the Purple book, read Beck's Smalltalk Best Practice Patterns (awsome book) and I've written a few games in Squeak for my kids and myself (working on a planetarium program in my spare time). I am a research oceanographer and during one cruise I hooked a Squeak image up to our navigation stream using UDP and had little icons of our boat driving around the screen with pirate boats chasing it (pictures of my boss of course!).  It was great fun and I really love the language.

But...if you were starting over today, would you use Smalltalk (VW) for new projects? I need to write some network monitors that keep track of our sonar and navigation systems and alert us to problems in real-time. It seems like a job VW would be good at. But I can't shake the feeling the Smalltalk's best days are behind it:

1. Smalltalk doesn't seem to have a multicore strategy in place. For serious number crunching I recently silenced some of our in house C++ bigots with a concurrent version of our signal processing code written in Java (a project I originally hoped to do in Smalltalk, but didn't). On a modern workstation keeping 8 cores busy (Java) trumps running twice-as fast on a single core (C++). We moved production over to the Java version. All the hot new languages are functional, making multicore a high priority (F#, Scala, Clojure, etc.). Of course, they all suck compared to Smalltalk. The key to multi-core success in Java was using immutable classes and a top-notch concurency api. It wasn't that hard, but there is limited language support for this style. Clojure has some great ideas but you need to know Lisp and Emacs. Smalltalk is much more humane surely there is some way to get a Smalltalk process off onto its own cpu thread?

2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac). For cross-platform programs (we do a lot of that in my shop) it would be nice to have a RAD tool backed up with a great language like Smalltalk. Java is NOT a RAD language by any stretch of the imagination; neither Python nor Ruby have cross-platform deployment strategies in place (and no standard widget sets either). It seems to me that this could be a real boon for VW if it was done well. RealBasic? I don't know.

3. The elephant in the room with respect to VW is cost structure.  It is hard to swallow today. No mainstream language charges deployment fees. I think it is fair to charge for a development image. Even renting the development image would probably be tollerable to my management if the benifits of using Smalltalk were good enough to justify the costs (we justify it for Matlab licenses out the kazoo). But it is hard to backdoor Smalltalk into our organization under the existing licensing options (as I understand them). For example, it is not clear that a government research organization like the USGS falls under the non-comercial license and per-seat licensing means that IT has to get involved to manage program deployments which would kill Smalltalk use for skunk-work projects.

I know I am preaching to the converted here, but does it really make sense to start new development projects in Smalltalk today? If not, that's a shame because I want an enterprise-ready dynamic language. 

Cheers,

 

David


-- 
David Finlayson, Ph.D.
Operational Geologist

U.S. Geological Survey
Pacific Science Center
400 Natural Bridges Drive
Santa Cruz, CA  95060, USA

Office: 831-427-4757
Lab: 831-427-4462 
Fax: 831-427-4748 
E-mail: [hidden email]


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

david.long
In reply to this post by Stefan Schmiedl

awesome.

Sampling errors are very easy to make, indeed they are ;-)

On Wed, 2009-03-18 at 20:48 +0100, Stefan Schmiedl wrote:
On Wed, 18 Mar 2009 11:00:07 -0700
David Finlayson <[hidden email]> wrote:

> Too bad Dolphin is dead. That is pretty close to what I had
> in mind (though not cross-platform).

Dolphin is not dead. It is being moved onto a new foundation.
Also, Andy Bower has posted some video tutorials lately.

http://www.object-arts.com/content/news/excitingNews.html

s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

SageTea Group
Phone 613 722 2091 extension 5
http://www.sageteagroup.com

There are 10 different kinds of people in the world,
those that understand binary and those that don't. ;-)

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Would you start a new Smalltalk project today?

James Robertson-7
In reply to this post by David Finlayson-4
This is actually from Arden Thomas, our product manager - he's having some email issues today:

Hi David;
 
On multicore;  you will be able to leverage multi-cores on our products in the near future.
 
Please look at my multi core redux, and series of multi-core experiments, with an experimental mutli core framework built by Cincom Smalltalk engineers.
 
HTH


James Robertson
Cincom Smalltalk Product Evangelist
Talk Small and Carry a Big Class Library




On Mar 18, 2009, at 2:00 PM, David Finlayson wrote:

Wow! I was surprised this morning to find so many responses. There
were some very thoughtful comments to my questions here. I appreciate
that, especially people who've dipped there toes into other dynamic
languages currently enjoying popularity.

A few comments:

James - I think you are doing a great job promoting CST. I noticed. As
for how to make Smalltalk pay, who can say? All I know is that I want
to try out a few programs in Smalltalk to see if productivity gains
offset the pain of using a niche technology. But my conversation with
your salespeople left me questioning whether it was worth it for the
small projects I had in mind (think cross-platform Visual Basic apps).
Alternative Smalltalks don't exist or have GUIs too weird for my
purposes. Too bad Dolphin is dead. That is pretty close to what I had
in mind (though not cross-platform).

Antony - I really enjoyed reading your comments. I've looked closely
at Clojure and Scala over the past couple of months and agree that JVM
languages have enormous advantages if they can communicate easily with
Java libraries. However, I don't think Clojure is ready for blub
programmers like myself (tools and documentation need to stabilize)
and Scala looks frighteningly complex. The major appeal of Smalltalk
to me is the combined advantages of an easy syntax with a solid
cross-platform strategy. Python and Ruby have the former, but trying
to maintain cross-platform code bases in Python has proved to be very
complicated for our team. Particularly if you need to distribute
non-standard libraries with the code. There are only a couple of us
programing to support about 50 scientists and all their weird
instruments (many of which we build in our shops). By the way, I
looked at your web site and would be very interested to hear (off
list) if you have managed to get Smalltalk communicating with ESRI
products (or other mapping software) that is very close to my domain.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
12