RE: Smalltalk: Requiem or Resurgence? Push for business application

Ron,

====================
My issue is one of operation and windows.  If the mouse moving means we
loose focus and users can not use a form heads down, or if the UI
doesn't
support multiple windows, much is lost.  
====================

I am in _full_ agreement on the mouse/keyboard focus.  You might take a
look at 0003590 on Mantis.  The multiple windows point is a little gray.
 Morphic does a reasonable job of hanlding its system windows, and the
result is not all that different from MDI.  While I have not yet done
this for any real work, my expection is to field software with "one big
alignment morph" taking up the world desktop, making the main window,
well, the main window.  Again, you are bang on right about the keyboard
focus.


====================
I think that supporting frameworks
for widgets like wxWidgets is a good idea.  Integration of wxSqueak
anyone?
====================

As an option, I'm all for it.  I might even use it, though I have never
been one to scream for native widgets, and frequently emulate for
performance reasons.


====================
A second issue is one of usability and business support.  We have had a
number of people including myself trying to read and write files without
understanding CrLfFileStream.  This is really an issue for me.  I
suggested
that we need to have a way to do aStringOrCollection writeToFile: aFile
or
aStringOrCollection readFromFile: aFile that should just work without
having
to know the ins and outs of the streams or any particular platform.  The
response I got from the community was this is a language not an
application
and since we can support what needs to be done developers need to
understand
the tools.  If this is the case then we need a business squeak that
supports
applications not just tools, we need more support for processes and
business
protocols.  
====================

You might lose me here.  With respect, if you are trying to avoid the
stream I/O, then you need to do some more Smalltalk programming (streams
will grow on you).  If you are looking for better support for platform
independence, then I am not the best person to help you.


====================
EDI, ASN.1, Cryptography, Workflow, Reporting, Bluetooth,
personally I would like to see support for X12, HL7, NCPDP...  We should
have preBuilt applications that can be used or modified that can solve
real
world business problems.  
====================

HL7 is a world of its own.  Which version of the spec?  Which
information system's dialect?   It gets ugly in a hurry.  Cryptography
is pretty basic and should be well supported.  I get the sense the
Croquet will address it, and hopefully it can be folded back into
Squeak.  IIRC, I grabbed and tested a public key implementation that
worked nicely.


====================
We should be encouraging web hosts to offer
Seaside and provide applications that run on it.  
====================

No argument.  However, I doubt the market is large enough to justify a
sysop's learning the ropes, and they will be worried about "one more
process" chewing up memory, CPU time, and providing a hook for hackers.
I would like to be proven wrong, but I doubt the idea will get traction
for those reasons.


====================
Why is .net and python and
perl and php so successful?  
====================

I was hoping you could tell me ;)  Perhaps best left to another thread,
is .NET really all that successful?  It's been out for six years or so,
right??  I just don't see it crashing down on my installed base.


====================
Well when I can go and install an application
to use without knowing anything about the language it encourages me to
want
to know more and to learn to develop or modify packages.  Besides
downloading and installing a finished application is also a good way to
learn what a finished application looks like.
====================

Fair enough, but I think there is also a big hype factor at work.
Beyond that, keep in mind that Squeak as you see it today was written in
Squeak; ditto Croquet.  There must be something to it.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

Hi Bill,

> -----Original Message-----
> From: Bill Schwab
> Sent: Tuesday, May 16, 2006 5:49 PM
=====================

Ron: To be clear here I've been writing production applications for 20
years.  One of the major benefits of smalltalk is the ability to take
complicated structures and simplify them.  Small helper methods help to
improve the productivity of programmers, they can help to show proper
implantation and even help to highlight platform issues.  String (or
Collection) >> writeToFile: or writeToFileUsingBlock: aBlock are very useful
and are much easier to remember then having to know about CrLfFileStream and
it seems to me that I should not have to know what platform I'm writing for
to get a file written.  There are other very useful helper methods like
copyToClipboard that would help application developers.  I understand the
language focus but I'm supporting a more application friendly focus.

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

Ron: The answer to the HL7 question is all of the versions that I need to
support.  I believe that by providing tools that help the medical industry
we may be able to attract that industry.  I am currently working on a very
large project which will help.  

The cryptography pieces in my opinion need to be done in open source to even
be considered.  I am currently working on cryptograph frameworks and our
cryptography group is looking at the
Complete Cryptographic Module Validation Program (CMVP) through the OpenSSL
Federal Information Processing Standard (FIPS) Certification Process.  I
firmly believe that for us to progress and gain acceptance we need to take
this process very seriously and provide a system that inspires confidence in
business and reduces the risk of adoption.
=====================
=====================
Ron: I believe that the lack of open source applications is the problem.
Once there are a number of valuable applications developed in Seaside, which
are freely available, sysops will support them.  Powerful freely available
applications that solve real world problems (like properly supporting
continuations) will entice hosts that are looking to increase market share.
=====================

It's very nice to meet you Bill; maybe in the future we can work together.

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
[hidden email]
www.USMedRec.com
Squeak Cryptography Team Leader
Squeak News Team Member
Squeak Elections Team Member
Squeak Representative with The Software Freedom Law Center

Ron,


Ron: To be clear here I've been writing production applications for 20
years.  One of the major benefits of smalltalk is the ability to take
complicated structures and simplify them.  Small helper methods help to
improve the productivity of programmers, they can help to show proper
implantation and even help to highlight platform issues.  String (or
Collection) >> writeToFile: or writeToFileUsingBlock: aBlock are very
useful
and are much easier to remember then having to know about CrLfFileStream
and
it seems to me that I should not have to know what platform I'm writing
for
to get a file written.  There are other very useful helper methods like
copyToClipboard that would help application developers.  I understand
the
language focus but I'm supporting a more application friendly focus.

Bill: Fair enough, but how often does one really have a single string
that becomes the payload of a file?  I much prefer to write #printXYZOn:
method and direct it to either a write stream on a string or a file as
appropriate.  It usually ends up being sent to many objects before the
output is complete.



Ron: The answer to the HL7 question is all of the versions that I need
to
support.  I believe that by providing tools that help the medical
industry
we may be able to attract that industry.  I am currently working on a
very
large project which will help.

Bill: Go get 'em :)  On a more serious note, I agree that the medicine
needs much better software, and Smalltalk would be a great match.




Ron: The cryptography pieces in my opinion need to be done in open
source to even
be considered.

Bill: (Quite sincerely) Open source in order to be considered by you or
by "them"?




Ron: I believe that the lack of open source applications is the problem.
Once there are a number of valuable applications developed in Seaside,
which
are freely available, sysops will support them.  Powerful freely
available
applications that solve real world problems (like properly supporting
continuations) will entice hosts that are looking to increase market
share.

Bill: Perhaps a little jaded, but I'm not that confident.  Please note
that I agree with most of what you have said, but I do not consider
gaining mainstream acceptance as a reasonable goal, nor do I consider it
necessary.  I will admit that it would be nice to have money oozing from
the walls.  I can barely imagine what SqC might have done with a few
percent of the money that was dumped into Java.



Ron: It's very nice to meet you Bill; maybe in the future we can work
together.

Bill: likewise.


Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

Bill,

Ron: The cryptography pieces in my opinion need to be done in open source to
even be considered.

Bill: (Quite sincerely) Open source in order to be considered by you or by
"them"?

Ron: I believe that there are two major requirements to successful
cryptography.  

The first is that all implementations should be publicly available, without
the ability to view the implementation it's difficult for the cryptography
community to assess the correctness and validate the protection offered
matches current standards.  I know that internal changes to cryptography, to
ease the impact on users (and possibly to prevent interoperability), have
been made by very large companies for example Microsoft's Kerberos
implementation which they admit is not standard.  They are trying to keep
their changes secret (1).  For me I believe there is safety in having the
code exposed in engaging the security community as much as possible and in
offering incentives to help find problems before hackers do.

The Second is to validate the cryptographic code through certification,
which I believe lowers the risk of companies that adopt the technology.
When a company can point to due diligence that shows a proper
implementation, breaches in security which can happen to anyone if major
public implementations are hacked will be easier to defend.  The major risk
remaining is the ability to remove and replace cracked code quickly.

I guess this point could have been stated a different way.  Instead of
saying open source I should have said publicly available.  But my leaning
here is open source since I strongly believe that certified publicly
available cryptography available in Squeak will help to encourage business
adoption.  

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
[hidden email]

1. http://www.networkworld.com/news/2000/0511kerberos.html I was just
validating what I said was still true, and it appears that there have been
some additional limited disclosures but those still have not made the
community happy.

  Ron,

  I must have missed this, but what would be the suggested behavior of
#writeToFile: and #readFromFile:?  Can they deal with WideStrings?

-- Yoshiki

I had not considered WideString, my concern is mostly for the reading and
writing of human readable files.  Collections should write to a file with
the proper separators for the current platform inserted between items.  When
reading a human readable file it should parse the string so that either each
line for the platform becomes an item on a collection or you should get a
string that is has a cr between lines replacing the source separators as
necessary.  

My belief is that helper methods here will help to explain the different
streams; how they are tied to individual platforms, and will help to lower
the cost of entry for working with files.  

Ron Teitelbaum

  Ron,

> >   I must have missed this, but what would be the suggested behavior of
> > #writeToFile: and #readFromFile:?  Can they deal with WideStrings?
> >
>
> I had not considered WideString, my concern is mostly for the reading and
> writing of human readable files.

  And, a WideString is of course a human readable string, and the
external file generated from it should be a human readable file.

  But...  It seems that you're not implying to use UTF-8 no matter
what platform you're on, but rather change the encoding based on the
platfrom, right?

> Collections should write to a file with
> the proper separators for the current platform inserted between items.  When
> reading a human readable file it should parse the string so that either each
> line for the platform becomes an item on a collection or you should get a
> string that is has a cr between lines replacing the source separators as
> necessary.  

  It sounds like #writeToFile: is a thin wrapper to
MultiByteFileStream.  It just sets up the flags of it, and then calls
the existing methods such as #nextLine, etc., right?

> My belief is that helper methods here will help to explain the different
> streams; how they are tied to individual platforms, and will help to lower
> the cost of entry for working with files.

  Not sure what you mean by "different streams".  What are they?
There is only one Stream (MultiByteFileStream) that deals with the
external files.  Its flags (and converter) can be set to deal with
different external formats.

  Yes, a few helper methods would be convenient.  I just want to know
what you think would be a reasonable behavior.

-- Yoshiki

Yes and please forgive me for not having a better understanding of
WideString before responding.  I saw 32Bit characters, I thought of binary,
math, cryptography (like 32bitRegister).  International characters had not
occurred to me.  I'm sorry.

What I would like to see is a way to read and write files with one simple
method that works for all platforms.  

I don't know enough about how different platforms handle these extended
character sets.  If there is a file format or platform that supports files
stored in this extended character format and if it is possible to detect
this file type, then it would make sense to convert to a WideString or a
collection of WideStrings when reading a file of this type.  It would also
make sense to automatically write a file of this type, again if this type
exists, when writing out a file from a collection of WideStrings, or a
WideString.

If these files types are not detectable or supportable then yes it would
make sense to always use UTF-8.  In any case the goal is to have one method
that reads and writes available on String and on Collection which works for
all platforms.

Originally I tried to do this:

dir := FileDirectory default.
(fileStream := dir fileNamed: 'test.txt') ascii.
fileStream nextPutAll: 'a\b' withCRs.
fileStream flush; close.

Which used MultiByteFileStream but it wasn't configured correctly so instead
I needed:

dir := FileDirectory default.
fileStream := CrLfFileStream fileNamed: (dir fullNameFor: 'test.txt').
[ fileStream nextPutAll: 'a\b' withCRs.
fileStream flush; close ] ensure: [ fileStream close ]

If this method already works for all platforms then that's the
implementation of the helper method.  

> There is only one Stream (MultiByteFileStream) that deals with the
> external files.  Its flags (and converter) can be set to deal with
> different external formats.
>
>   Yes, a few helper methods would be convenient.  I just want to know
> what you think would be a reasonable behavior.
>
> -- Yoshiki
>

I appreciate your interest.

Ron Teitelbaum

  Ron,

  No need to say sorry!  (But I might point out that this was one of
the reason I wrote back in April why it wouldn't work well.  When the
interoperability with the platform and other applications are
concerned.)

> What I would like to see is a way to read and write files with one simple
> method that works for all platforms.  

  Me, too.  But I kind of doubt it.

  The definition of "work" is somewhat ambiguous.  For example, on the
Japanese Windows, Shift-JIS "work" better than UTF-8 in a sense, and
other way around in other sense (and ISO 2022 works for particular
applications like emails.)  And on the Chinese Windows, GB 2312 (or
such) is "better", in a sense.

  (We don't actually think such alien languages^^; ISO-8859-* and
UTF-8 will give the case.)

  Again, going to a platform neutral approach has its advantages, and
"by default", I think it is reasonable.  (UTF-8 and CR.)

  Well, there is a lot to say about this code^^;

  First, #close implies #flush, so you don't need it.  And, #ensure:
means that the ensure block is executed no matter what, so you don't
have to put #close in the receiver block.

  (I guess you just wanted to illustrate the idea, but just a
sidenote...  Using #ensure: just to close the file is quite debatable,
especially if it covers just a part of method.  In the above code, the
file open error is notified to the user (or calling method).  However,
if the writing fails for some reason such as disk-full, it siliently
closes the file and pretends the requested operation was successful.
And, think about an hypothetical case where opening file succeeds but
the assignment to the 'fileStream' variable fails...)

  All in all, for writing:

| dir fileStream |
dir := FileDirectory default.
fileStream := dir fileNamed: 'test.txt'.
fileStream wantsLineEndConversion: true.
fileStream nextPutAll: 'a\b' withCRs.
fileStream close.

and then for reading the file:

| dir fileStream result |
dir := FileDirectory default.
fileStream := dir readOnlyFileNamed: 'test.txt'.
fileStream wantsLineEndConversion: true.
result := WriteStream on: Array new.
[(line := fileStream nextLine) notNil] whileTrue: [
    result nextPut: line
].
fileStream close.
^ result contents.

seems to do one way we might want it to do.  If these are helper
methods to be used in various applications, the error handling should
be done by the callers, as the different applications want to do
different things upon an error.

-- Yoshiki

Hi Yoshiki and Ron,

Ron wrote:

> > make sense to always use UTF-8.  In any case the goal is to have
> one method
> > that reads and writes available on String and on Collection which
> works for
> > all platforms.

This goal is already achieved in base Squeak with something called
ReferenceStream.  In fact, its much more robust in that it can handle
any graph of objects, not just a Collection of Strings.

Legacy files with lists of Strings are certainly application-specific.
I can't see Collection as an appropriate place for parsing, say,
comma-delimited files.  I would use a CsvParser or something..

Yoshiki wrote:

>   (I guess you just wanted to illustrate the idea, but just a
> sidenote...  Using #ensure: just to close the file is quite
> debatable,
> especially if it covers just a part of method.  In the above code,
> the
> file open error is notified to the user (or calling method).
> However,
> if the writing fails for some reason such as disk-full, it siliently
> closes the file and pretends the requested operation was successful.

I take you up on this debate because, with all due respect, I think
this is wrong.  An error while writing the file would not be silent and
pretend success at all.  Demonstrated:

  [ self error: 'disk full' ] ensure: [ Transcript cr; show: 'now
ensure is executed' ]

> And, think about an hypothetical case where opening file succeeds but
> the assignment to the 'fileStream' variable fails...)

How could this possibly happen?  And, even IF that happened then the
state of the system is so tenuous and uncertain that ensure: is not
going to do any harm (or help, probably).

Regards,
  Chris

  Chris,

  You're right.  I must have thinking about on:do:.

> > And, think about an hypothetical case where opening file succeeds but
> > the assignment to the 'fileStream' variable fails...)
>
> How could this possibly happen?  And, even IF that happened then the
> state of the system is so tenuous and uncertain that ensure: is not
> going to do any harm (or help, probably).

  I don't know.  That is why I said hypothetical.

-- Yoshiki