VisualWorks Call For Issues [GUI] 
Author Message
 VisualWorks Call For Issues [GUI]

In an anachronistic way, you're correct.  But that's the problem with the concept
of a single image running *all* Smalltalk processes, whether or not they use native
OS threads.  Is CinCom willing to guarantee the same reliability of their image and
all the processes running inside it as our operating systems?  Heck, I can crash VW
on command calling a shared library!  I've been working for a year (on and off)
trying to figure out why a DLL/C call crashes the VM.  Regardless of why, it is
fairly scary to think one bad apple can spoil a whole bunch of girls (to quote the
Osmond brothers--or was it The Jackson Five?).  I have a much harder time trashing
HPUX, AIX, Solaris, and Linux.  Slightly less crashing NT.

I think it's Smalltalk vendors dogmatic adherence to ST-80's original concept that
has contributed to Smalltalk's lack of maturity or growth.  As much as I like
Smalltalk (and I do *love* it) it has not grown out of it's VM, which may have made
sense back in the early 80s, but makes little sense today.  This is a fairly basic
example of the the lack of reuse.  Is it necessary for Smalltalk to reimplement
functionality available in commercial-class operating systems especially when it
does so in a more fragile way?  It would be one thing were the VM superior in
resilience to the OS but this is not true.

Quote:

> I understand your points but - after you get those three things, it
> won't be Smalltalk anymore.


> >   1. VW needs to behave more like normal programs than not.  I need to be able
> >      to terminate VW processes, see them alongside other OS processes, and
> >      know that when one of them crashes it won't take the entire image down
> >      with it.  Imagine the kind of applications computers would be restricted
> >      to if any single process could crash an entire machine (whoops, I forgot
> >      about Windows).
> >   2. The source code needs to exist, peacfully, outside of the image.  Sorry,
> >      XML ain't cutting it for me as a source code format.  Tags don't belong
> >      in Smalltalk anymore than they belong in my C code.  I'd like to be able
> >      to recognize the code I wrote.  Especially if I'm checking into and out
> >      of a source code repository, or simply sharing it with coworkers and
> >      friends.
> >   3. One of the biggest obstacles to learning Smalltalk (and there are several
> >      but don't get that thread started again...) is the difficulty converts
> >      have with a language with no main().  No starting point.  No comfortable
> >      place to accept command line arguments.  No comfortable place to know
> >      that when main() returns the progam goes away.  All of it.  All its
> >      address space is returned back to the OS, regardless of whether or not
> >      some variables were still pointed to.  (Whoops, forgot about Windows
> >      again).

> > --
> > .tom

> --
> James A. Robertson
> Product Manager (Smalltalk), Cincom

> <Talk Small and Carry a Big Class Library>

--
.tom


Tue, 17 Jun 2003 13:48:10 GMT  
 VisualWorks Call For Issues [GUI]
Thomas

[snip]

Quote:
>  Regardless of why, it is
> fairly scary to think one bad apple can spoil a whole bunch of girls (to
quote the
> Osmond brothers--or was it The Jackson Five?).

The Osmond brothers.

Regards,

Randy



Wed, 18 Jun 2003 01:43:35 GMT  
 VisualWorks Call For Issues [GUI]


Quote:
>In an anachronistic way, you're correct.  But that's the problem with
>the concept of a single image running *all* Smalltalk processes, whether
>or not they use native OS threads.  Is CinCom willing to guarantee the
>same reliability of their image and all the processes running inside it
>as our operating systems?  Heck, I can crash VW on command calling a
>shared library!  I've been working for a year (on and off) trying to
>figure out why a DLL/C call crashes the VM.  Regardless of why, it is
>fairly scary to think one bad apple can spoil a whole bunch of girls (to
>quote the Osmond brothers--or was it The Jackson Five?).  I have a much
>harder time trashing HPUX, AIX, Solaris, and Linux.  Slightly less
>crashing NT.

When you use dll/c you go outside of smalltalk.  To carry
the analogy further if you go outside the OS and write
haphazardly to memory you can crash the OS.

+I think it's Smalltalk vendors dogmatic adherence to ST-80's original
+concept that has contributed to Smalltalk's lack of maturity or growth.
+As much as I like Smalltalk (and I do *love* it) it has not grown out of
+it's VM, which may have made sense back in the early 80s, but makes
+little sense today.  This is a fairly basic example of the the lack of
+reuse.  Is it necessary for Smalltalk to reimplement functionality
+available in commercial-class operating systems especially when it does
+so in a more fragile way?  It would be one thing were the VM superior in
+resilience to the OS but this is not true.

If the OS was more like smalltalk then smalltalk would
not have to present itself like an OS for the applications
it hosts.

--
Terry
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
19 Tilley Ave.                  VW and ENVY/Developer
Newport, RI  02840

http://www.craftedsmalltalk.com
===========================================================



Wed, 18 Jun 2003 08:17:43 GMT  
 VisualWorks Call For Issues [GUI]


Quote:
>True.  But that doesn't mean a single task should break an entire
>system.  The fact that when I go outside of smalltalk I can take the
>whole VM down with me is, though my fault, an unacceptible fragility in
>production systems.
>Also, on what modern OS can I write hahazardly to user-space memory and
>crash the operating system?  On most OSs some sort of memory fault is
>trapped when a process writes to an address outside its mapped memory.
>If it overwrites its own memory then just that process crashes.

Device drivers can do just that.

The image executes in a box.  DLL/C executes outside the box.
Likewise, device drivers operate outside the box.  If the
developers are not careful bad things happen.

--
Terry
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
19 Tilley Ave.                  VW and ENVY/Developer
Newport, RI  02840

http://www.craftedsmalltalk.com
===========================================================



Thu, 19 Jun 2003 08:21:04 GMT  
 VisualWorks Call For Issues [GUI]
Somehow I knew you'd bring that up.  But I don't know of any device drivers
being written in Smalltalk.  Except for JavaOS, I don't know of any device
drivers written in Java, and I'm not even sure the Java's are written in Java,
but are embedded in the VM somewhere (probably written in C or assembly
language).

We both know that most software exists above the operating system as
applications, either as system or application programs.  This is where
Smalltalk is *most* applicable, but is it as resilient as it needs to be?

I'm not sure what the answer is, but I think Smalltalk would be pretty cool if
it were a combination of kernel, shared object, and *separate* threads.  The
kernel would be small, tight, and invincible.  The shared code, like DLLs,
would provide both functionality and resource efficiency.  Finally, the
threads would each have their own logical address spaces (execution spaces,
whatever) so they would be unable to infect each other.

If this model were in place, I suspect there would be more Smalltalk
programmers than C or Java programmers.

--
.tom



Thu, 19 Jun 2003 10:27:10 GMT  
 VisualWorks Call For Issues [GUI]
Terry makes an excellent point.  One other as well.  To get to an
architecture that has problems (as stated below), we would have to do a
radical restructuring of the VM.  Such a restructuring would likely
introduce many new bugs in the first release or two.

Secondly, there's an opportunity cost.  I can work with engineering to
get a limited number of projects funded and in production.  What would
you be willing to give up in order to see this?

-- better tools?
-- better GUI system?
-- better web integration?
-- standard internet API's?

It's not as simple as saying 'I want this now'.  There are always
tradeoffs.  The ones we have made thus far are based explicitly on what
I know (from personal experience in worldwide customer visits) that
people have wanted most in VW.  This doesn't make what we are doing
perfect; I hear requests wrong at least as well as the next guy ;-0

Quote:



> >I'm not sure what the answer is, but I think Smalltalk would be pretty
> >cool if it were a combination of kernel, shared object, and *separate*
> >threads.  The kernel would be small, tight, and invincible.  The shared
> >code, like DLLs, would provide both functionality and resource
> >efficiency.  Finally, the threads would each have their own logical
> >address spaces (execution spaces, whatever) so they would be unable to
> >infect each other.

> There is no way this can be done.  Suppose a library call
> messed up the call stack, under NT you get a Dr. Watson.
> How can the VM protect against that?  Also, if you want to
> get to issues like passing data (objects) between smalltalk
> and library calls you would have to avoid using direct pointers
> and use VM managed routines to move data from the heap
> to object memory, or something like that.  Next, there would
> be complaints about how inefficient that is.

> --
> Terry
> ===========================================================
> Terry Raymond       Smalltalk Professional Debug Package
> Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
> 19 Tilley Ave.                  VW and ENVY/Developer
> Newport, RI  02840

> http://www.craftedsmalltalk.com
> ===========================================================

--
James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>



Fri, 20 Jun 2003 06:21:36 GMT  
 VisualWorks Call For Issues [GUI]

Quote:

> Terry makes an excellent point.  One other as well.  To get to an
> architecture that has problems (as stated below), we would have to do a
> radical restructuring of the VM.  Such a restructuring would likely
> introduce many new bugs in the first release or two.

> Secondly, there's an opportunity cost.  I can work with engineering to
> get a limited number of projects funded and in production.  What would
> you be willing to give up in order to see this?

> -- better tools?
> -- better GUI system?
> -- better web integration?
> -- standard internet API's?

From a VM point of view, I suggest giving up at least the first three.  These
are not the providence of the VM, and the fourth one is a relevancy issue.  It
would make sense to me (thought I can't speak about money for you) for Cincom
to concentrate on those parts of the product that no one else is able to
extend--the VM.  The GUI, web integration, and even the internet APIs are
things other vendors and the community could do, and possibly if an improved
VM could attract more programmers these would be more easily found.

Since I don't expect CinCom to release the code for the VM then CinCom should
accept responsibility for it's relevancy to current technology.  The
inefficiencies mentioned in Terry's earlier post may be real, but they are
necessary.  Given the speed of current CPUs and the rate that they increase
I'm not as willing to accept inefficiency as an excuse as I may have back in
the 70s.

It's a tough spot for Smalltalk vendors to be in, I suppose.  Neither fish nor
fowl, the VM can't replace the OS phyically nor can it provide OS-like fault
process protection.

Here's an idea for the new year (since I'm now working-off the last bit of
champagne)--let's pretend CinCom had developed the best and most usable GUI
classes ever designed.  The tools are spectacular, and web/internet
integration is second to none.  Would that increase the number of production
(license-paying) systems?   Some might think so, but I'm not convinced.  If
instead CinCom could boast an uninterruptable VM replete with process
protection and the whole shot, would that attract more programmers?

In our production system I have eight python programs (servers) running at
once.  When any of them dies I have no fear that either my OS or the other
Python processes have been corrupted or compromised in anyway.  It's a
warm-and-fuzzy feeling that breeds confidence.  I think that is attractive.
As a programmer, I want to concentrate on making my application work and
finding the bugs that crash my application.  I understand my application.  I
can't (or at least am unwilling) to accept responsibility for an entire VM.

Quote:

> It's not as simple as saying 'I want this now'.  There are always
> tradeoffs.  The ones we have made thus far are based explicitly on what
> I know (from personal experience in worldwide customer visits) that
> people have wanted most in VW.  This doesn't make what we are doing
> perfect; I hear requests wrong at least as well as the next guy ;-0

--
.tom


Fri, 20 Jun 2003 16:03:07 GMT  
 VisualWorks Call For Issues [GUI]

Thomas,
        Since memory is so cheap, why not just run a bunch of Smalltalk
systems?  They can interoperate via sockets (Opentalk, CORBA, what have
you).  You can have a monitor make sure that there are always N
running.  I have many clients doing that now.

Quote:


> > Terry makes an excellent point.  One other as well.  To get to an
> > architecture that has problems (as stated below), we would have to do a
> > radical restructuring of the VM.  Such a restructuring would likely
> > introduce many new bugs in the first release or two.

> > Secondly, there's an opportunity cost.  I can work with engineering to
> > get a limited number of projects funded and in production.  What would
> > you be willing to give up in order to see this?

> > -- better tools?
> > -- better GUI system?
> > -- better web integration?
> > -- standard internet API's?

> From a VM point of view, I suggest giving up at least the first three.  These
> are not the providence of the VM, and the fourth one is a relevancy issue.  It
> would make sense to me (thought I can't speak about money for you) for Cincom
> to concentrate on those parts of the product that no one else is able to
> extend--the VM.  The GUI, web integration, and even the internet APIs are
> things other vendors and the community could do, and possibly if an improved
> VM could attract more programmers these would be more easily found.

> Since I don't expect CinCom to release the code for the VM then CinCom should
> accept responsibility for it's relevancy to current technology.  The
> inefficiencies mentioned in Terry's earlier post may be real, but they are
> necessary.  Given the speed of current CPUs and the rate that they increase
> I'm not as willing to accept inefficiency as an excuse as I may have back in
> the 70s.

> It's a tough spot for Smalltalk vendors to be in, I suppose.  Neither fish nor
> fowl, the VM can't replace the OS phyically nor can it provide OS-like fault
> process protection.

> Here's an idea for the new year (since I'm now working-off the last bit of
> champagne)--let's pretend CinCom had developed the best and most usable GUI
> classes ever designed.  The tools are spectacular, and web/internet
> integration is second to none.  Would that increase the number of production
> (license-paying) systems?   Some might think so, but I'm not convinced.  If
> instead CinCom could boast an uninterruptable VM replete with process
> protection and the whole shot, would that attract more programmers?

> In our production system I have eight Python programs (servers) running at
> once.  When any of them dies I have no fear that either my OS or the other
> Python processes have been corrupted or compromised in anyway.  It's a
> warm-and-fuzzy feeling that breeds confidence.  I think that is attractive.
> As a programmer, I want to concentrate on making my application work and
> finding the bugs that crash my application.  I understand my application.  I
> can't (or at least am unwilling) to accept responsibility for an entire VM.

> > It's not as simple as saying 'I want this now'.  There are always
> > tradeoffs.  The ones we have made thus far are based explicitly on what
> > I know (from personal experience in worldwide customer visits) that
> > people have wanted most in VW.  This doesn't make what we are doing
> > perfect; I hear requests wrong at least as well as the next guy ;-0

> --
> .tom

--
James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>



Fri, 20 Jun 2003 23:57:30 GMT  
 VisualWorks Call For Issues [GUI]

Quote:

>From a VM point of view, I suggest giving up at least the first three.
These
>are not the providence of the VM, and the fourth one is a relevancy issue.
It
>would make sense to me (thought I can't speak about money for you) for
Cincom
>to concentrate on those parts of the product that no one else is able to
>extend--the VM.  The GUI, web integration, and even the internet APIs are
>things other vendors and the community could do, and possibly if an
improved
>VM could attract more programmers these would be more easily found.

I will respectfully, but absolutely, disagree.  Programmers are not
attracted by better VMs.  They are attracted by tools that help them solve
their problems.  This implies without spending too much effort on
implementing things that are ubiquitous, taken for granted, and expected to
be available out-of-the-box.  They should be able to build a GUI without
coding half the widgets they need, or build a web application without coding
SSL.  "This is Smalltalk and you can change anything" is the wrong answer.
I've personally talked to a guy whose organization dropped VW a few (or
quite a few) years ago because of that.  They were concerned about widgets
not working the way they should, and PPD sales reps kept reminding that they
could fix anything themselves.

The thing is, it doesn't matter what people can or cannot do.  A development
environment is expected to provide certain things out of the box--and these
days that includes widgets (that work the "right" way), fairly advanced
development tools, and Internet stuff.  If it doesn't, the majority of
outsiders will conclude it's {*filter*}without checking what 3rd party or the
community can offer.  (Sure, by this logic Java should have failed right
after the first few JDK releases, but one should never underestimate the
determination of idiots in large numbers).  And how can a tool attract a
supporting community when it is not attractive to begin with?

Another major problem with delegating stuff like this to the community is
that very few--if any--of those who have real jobs (or maybe even lives)
could commit to the major responsibility and effort it takes.  If this is
not so, why don't we have a community-backed port of RB for 5i?

Cheers,
and may 2001 be good for all Smalltalkers regardless of the dialect.

--Vassili

--
Vassili Bykov



Sat, 21 Jun 2003 11:51:42 GMT  
 VisualWorks Call For Issues [GUI]
That's not a bad idea, especially since memory is cheap.  The system we're
developing now was designed to have one headless image/system, but it could
easily be modified to run several headless images/system.  Thanks!

--
.tom



Sat, 21 Jun 2003 11:44:51 GMT  
 VisualWorks Call For Issues [GUI]
I agree with Vassili completely. And I would go further - just because it's
there somewhere and you can read the code and use and extend it doesnt's mean
everybody will or can. I suspect that for most people features that are not
documented, preferably in a cookbook style - are simply not there.

But somebody said that documentation is very high on Cincom's list so this may
be superfluous. I am very much looking forward to it.

Ivan

Quote:


> >From a VM point of view, I suggest giving up at least the first three.
> These
> >are not the providence of the VM, and the fourth one is a relevancy issue.
> It
> >would make sense to me (thought I can't speak about money for you) for
> Cincom
> >to concentrate on those parts of the product that no one else is able to
> >extend--the VM.  The GUI, web integration, and even the internet APIs are
> >things other vendors and the community could do, and possibly if an
> improved
> >VM could attract more programmers these would be more easily found.

> I will respectfully, but absolutely, disagree.  Programmers are not
> attracted by better VMs.  They are attracted by tools that help them solve
> their problems.  This implies without spending too much effort on
> implementing things that are ubiquitous, taken for granted, and expected to
> be available out-of-the-box.  They should be able to build a GUI without
> coding half the widgets they need, or build a web application without coding
> SSL.  "This is Smalltalk and you can change anything" is the wrong answer.
> I've personally talked to a guy whose organization dropped VW a few (or
> quite a few) years ago because of that.  They were concerned about widgets
> not working the way they should, and PPD sales reps kept reminding that they
> could fix anything themselves.

> The thing is, it doesn't matter what people can or cannot do.  A development
> environment is expected to provide certain things out of the box--and these
> days that includes widgets (that work the "right" way), fairly advanced
> development tools, and Internet stuff.  If it doesn't, the majority of
> outsiders will conclude it's {*filter*}without checking what 3rd party or the
> community can offer.  (Sure, by this logic Java should have failed right
> after the first few JDK releases, but one should never underestimate the
> determination of idiots in large numbers).  And how can a tool attract a
> supporting community when it is not attractive to begin with?

> Another major problem with delegating stuff like this to the community is
> that very few--if any--of those who have real jobs (or maybe even lives)
> could commit to the major responsibility and effort it takes.  If this is
> not so, why don't we have a community-backed port of RB for 5i?

> Cheers,
> and may 2001 be good for all Smalltalkers regardless of the dialect.

> --Vassili

> --
> Vassili Bykov




Sat, 21 Jun 2003 23:17:07 GMT  
 VisualWorks Call For Issues [GUI]
Thus far, there are no examples I know of where 'highly polished' tools
capabilities have been added in a generally redistributable fashion for
any tool.  I could be wrong; there's a lot out there.  However, my
impression from the Smalltalk community is that <lots> of people build
tools; very few of them 'productize' them to the point that they could
be made generally available without additional work.  

The best that I would expect would be an influx of partially finished
tools that need to be maintained and polished by a centralized
development staff.

Quote:

> I agree with Vassili completely. And I would go further - just because it's
> there somewhere and you can read the code and use and extend it doesnt's mean
> everybody will or can. I suspect that for most people features that are not
> documented, preferably in a cookbook style - are simply not there.

> But somebody said that documentation is very high on Cincom's list so this may
> be superfluous. I am very much looking forward to it.

> Ivan



> > >From a VM point of view, I suggest giving up at least the first three.
> > These
> > >are not the providence of the VM, and the fourth one is a relevancy issue.
> > It
> > >would make sense to me (thought I can't speak about money for you) for
> > Cincom
> > >to concentrate on those parts of the product that no one else is able to
> > >extend--the VM.  The GUI, web integration, and even the internet APIs are
> > >things other vendors and the community could do, and possibly if an
> > improved
> > >VM could attract more programmers these would be more easily found.

> > I will respectfully, but absolutely, disagree.  Programmers are not
> > attracted by better VMs.  They are attracted by tools that help them solve
> > their problems.  This implies without spending too much effort on
> > implementing things that are ubiquitous, taken for granted, and expected to
> > be available out-of-the-box.  They should be able to build a GUI without
> > coding half the widgets they need, or build a web application without coding
> > SSL.  "This is Smalltalk and you can change anything" is the wrong answer.
> > I've personally talked to a guy whose organization dropped VW a few (or
> > quite a few) years ago because of that.  They were concerned about widgets
> > not working the way they should, and PPD sales reps kept reminding that they
> > could fix anything themselves.

> > The thing is, it doesn't matter what people can or cannot do.  A development
> > environment is expected to provide certain things out of the box--and these
> > days that includes widgets (that work the "right" way), fairly advanced
> > development tools, and Internet stuff.  If it doesn't, the majority of
> > outsiders will conclude it's {*filter*}without checking what 3rd party or the
> > community can offer.  (Sure, by this logic Java should have failed right
> > after the first few JDK releases, but one should never underestimate the
> > determination of idiots in large numbers).  And how can a tool attract a
> > supporting community when it is not attractive to begin with?

> > Another major problem with delegating stuff like this to the community is
> > that very few--if any--of those who have real jobs (or maybe even lives)
> > could commit to the major responsibility and effort it takes.  If this is
> > not so, why don't we have a community-backed port of RB for 5i?

> > Cheers,
> > and may 2001 be good for all Smalltalkers regardless of the dialect.

> > --Vassili

> > --
> > Vassili Bykov


--
James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>



Sun, 22 Jun 2003 03:22:58 GMT  
 
 [ 48 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. VisualWorks Call For Issues [GUI]

2. VisualWorks Tools Call For Issues

3. VisualWorks StORE non-call for issues

4. Wanted: Smalltalk GUI developers - VisualAge & VisualWorks

5. VisualWorks GUI

6. VisualWorks GUI question (Two ActionButton

7. couple of GUI issues

8. Issuing Operating System & GUI commands

9. GUI Issue: GL vs Xlib

10. How to dynamically change GUI with VisualWorks??

11. VisualWorks -- event handling, GUI -- next version???

12. US-Atlanta Smalltalk GUI Prototypers-VisualWorks,Unix,client/server,OO

 

 
Powered by phpBB® Forum Software