Smalltalk compatability

Hi all!

I am currently doing a business project, and I am wondering if different implementations of Smalltalk are compitable with each other. (e.g. VA Smalltalk can run Smalltalk (Smalltalk-80 version 2) or Strongtalk code)

Thank you!

Hi Christian,

If you want a combination Smalltalk and COBOL system, VA Smalltalk is probably your best bet.  I'm not familiar with all the Smalltalk systems out there but I don't know of any with closer ties to COBOL than VA Smalltalk.

Will the system run on an IBM mainframe or an X86 or other based computer?  If it is an IBM system, then you definitely want to go with VA Smalltalk because of the ties Joachim referred to.

If this is an IBM mainframe based project and if it is large enough to warrant it, you may want to consider creating a packed decimal class (similar to ScaledDecimal) that matches the IBM packed decimal hardware data type used by COBOL.  You would need to write a DLL to do the math, which probably won't be easy, but should be a lot faster than ScaledDecimal.

Lou

On Thursday, March 5, 2015 at 12:17:23 AM UTC-5, Christian Tam wrote:

Thank you very much Joachim!

I was asking because VA smalltalk can load COBOL libraries (<a href="https://www.youtube.com/watch?v=tyjlxSPu0bU" rel="nofollow" target="_blank" onmousedown="this.href='https://www.youtube.com/watch?v\75tyjlxSPu0bU';return true;" onclick="this.href='https://www.youtube.com/watch?v\75tyjlxSPu0bU';return true;">https://www.youtube.com/watch?v=tyjlxSPu0bU), and in this project I'm working on, it says they are using Smalltalk code, but did not specify what implementation they were using. I was hoping the answer to my question was going to be yes because the project requires integrated two enterprise systems (one COBOL-based and one Smalltalk-based). And I was seeing if I could use the Smalltalk based system add parts of the COBOL-based system to it.

Thank you again for your quick and detailed response!

On Wednesday, March 4, 2015 at 11:02:37 PM UTC-5, Joachim Tuchel wrote:

Hi Christian,

Your question isn't easy to answer, because it depends on the code.

To make it short: Most Smalltalks share a common base of Classes and Methods that are compatible between most if not all dialects. But even in this kernel of functionality there are bits and pieces where some dialects show different behavior. There once was an effort to standardize the language and there is some ANSI Standard draft, but to be honest, it is mostly a piece of paper.

When it comes to GUI or Database or whatever libraries, there is not much of a common ground between dialects. Some are closer to each other than others, but whatever pairing of Smalltalk dialects you chose, there will be differing mileages.

There are, however, bodies of code that have been ported to most or even all dialects, like SUnit, Refactorings, Seaside, and whatnot. Some of these projects have taken quite some effort to make the code portable and compatible. There have been several approaches to make code exchangeable between dialects (Rosetta, SIF, Grease), some of which are still in heavy use (like Grease). The outcome of this is that you can use SUnit or Seaside on each Smalltalk implementation and use it without the need to learn anything new or change your test code.

So the situation is not as bad as it may sound at first, but the honest answer is: there is no such thing as an implemented "Smalltalk Standard".

Things seemed to improve a lot a few years ago, when everybody wanted to have Seaside on their platform. Vendors and O/S projects tried to make their Smalltalk more compatible. Unfortunately, we are now back to a world where they returned to their ivory towers where they do things cooler or faster than all the others. It is just the projects I mentioned before who try to stay current on all platforms.

No matter how bad my answer may sound, you shouldn't overestimate its consequences in comparison to other platforms. Look at Javascript: You can easily chose a library like jQuery or ReactJS or whatever and enter an incompatible niche that is its completely separated universe from others. If its implementors stop working on it, you are in trouble. This is true in so many ecosystems, not only JS, that I'd say you will most certainly face the same kind of problems in whatever language. It is even true in the C++ world.

We can like it or not, but the whole IT market is moving in this direction. Just imagine you wanted to build software for mobile devices. Here are your best choices: C#, Swift, Java. How compatible are these languages and their ecosystems?
The vendors want to suck you and your customers into their ecosystem as deeply as possible and I think they make them as incompatible as they can possibly make them.
Sure, there are tools and projects that try to bridge gaps. Some work, some work well, but in the end, you end up using a "meta-niche".

So what you ask for is not present in the Smalltalk world, but it also isn't in any other. If we like it or not...

OTOH, given that Smalltalk implementations are closely coupled with an IDE and its specific features, you should ask yourself what it is that you really need in Strongtalk and what you don't like about it. Which IDE seems to fit well into your way of coding, testing, etc?
Try to be more specific in defining your needs and select and IDE that fits best,

hth

Joachim



Am Donnerstag, 5. März 2015 04:32:56 UTC+1 schrieb Christian Tam:

Hi all!

I am currently doing a business project, and I am wondering if different implementations of Smalltalk are compitable with each other. (e.g. VA Smalltalk can run Smalltalk (Smalltalk-80 version 2) or Strongtalk code)

Thank you!

On Thursday, March 5, 2015 at 7:18:24 AM UTC-8, Louis LaBrunda wrote:

Hi Christian,

If you want a combination Smalltalk and COBOL system, VA Smalltalk is probably your best bet.  I'm not familiar with all the Smalltalk systems out there but I don't know of any with closer ties to COBOL than VA Smalltalk.

Will the system run on an IBM mainframe or an X86 or other based computer?  If it is an IBM system, then you definitely want to go with VA Smalltalk because of the ties Joachim referred to.

If this is an IBM mainframe based project and if it is large enough to warrant it, you may want to consider creating a packed decimal class (similar to ScaledDecimal) that matches the IBM packed decimal hardware data type used by COBOL.  You would need to write a DLL to do the math, which probably won't be easy, but should be a lot faster than ScaledDecimal.

There already *is* such a DLL. ESDEC40.DLL, the one ScaledDecimal uses to do its arithmetic operations. You won't need to write your own.

Lou

On Thursday, March 5, 2015 at 12:17:23 AM UTC-5, Christian Tam wrote:

Thank you very much Joachim!

I was asking because VA smalltalk can load COBOL libraries (<a href="https://www.youtube.com/watch?v=tyjlxSPu0bU" rel="nofollow" target="_blank" onmousedown="this.href='https://www.youtube.com/watch?v\75tyjlxSPu0bU';return true;" onclick="this.href='https://www.youtube.com/watch?v\75tyjlxSPu0bU';return true;">https://www.youtube.com/watch?v=tyjlxSPu0bU), and in this project I'm working on, it says they are using Smalltalk code, but did not specify what implementation they were using. I was hoping the answer to my question was going to be yes because the project requires integrated two enterprise systems (one COBOL-based and one Smalltalk-based). And I was seeing if I could use the Smalltalk based system add parts of the COBOL-based system to it.

Thank you again for your quick and detailed response!

On Wednesday, March 4, 2015 at 11:02:37 PM UTC-5, Joachim Tuchel wrote:

Hi Christian,

Your question isn't easy to answer, because it depends on the code.

To make it short: Most Smalltalks share a common base of Classes and Methods that are compatible between most if not all dialects. But even in this kernel of functionality there are bits and pieces where some dialects show different behavior. There once was an effort to standardize the language and there is some ANSI Standard draft, but to be honest, it is mostly a piece of paper.

When it comes to GUI or Database or whatever libraries, there is not much of a common ground between dialects. Some are closer to each other than others, but whatever pairing of Smalltalk dialects you chose, there will be differing mileages.

There are, however, bodies of code that have been ported to most or even all dialects, like SUnit, Refactorings, Seaside, and whatnot. Some of these projects have taken quite some effort to make the code portable and compatible. There have been several approaches to make code exchangeable between dialects (Rosetta, SIF, Grease), some of which are still in heavy use (like Grease). The outcome of this is that you can use SUnit or Seaside on each Smalltalk implementation and use it without the need to learn anything new or change your test code.

So the situation is not as bad as it may sound at first, but the honest answer is: there is no such thing as an implemented "Smalltalk Standard".

Things seemed to improve a lot a few years ago, when everybody wanted to have Seaside on their platform. Vendors and O/S projects tried to make their Smalltalk more compatible. Unfortunately, we are now back to a world where they returned to their ivory towers where they do things cooler or faster than all the others. It is just the projects I mentioned before who try to stay current on all platforms.

No matter how bad my answer may sound, you shouldn't overestimate its consequences in comparison to other platforms. Look at Javascript: You can easily chose a library like jQuery or ReactJS or whatever and enter an incompatible niche that is its completely separated universe from others. If its implementors stop working on it, you are in trouble. This is true in so many ecosystems, not only JS, that I'd say you will most certainly face the same kind of problems in whatever language. It is even true in the C++ world.

We can like it or not, but the whole IT market is moving in this direction. Just imagine you wanted to build software for mobile devices. Here are your best choices: C#, Swift, Java. How compatible are these languages and their ecosystems?
The vendors want to suck you and your customers into their ecosystem as deeply as possible and I think they make them as incompatible as they can possibly make them.
Sure, there are tools and projects that try to bridge gaps. Some work, some work well, but in the end, you end up using a "meta-niche".

So what you ask for is not present in the Smalltalk world, but it also isn't in any other. If we like it or not...

OTOH, given that Smalltalk implementations are closely coupled with an IDE and its specific features, you should ask yourself what it is that you really need in Strongtalk and what you don't like about it. Which IDE seems to fit well into your way of coding, testing, etc?
Try to be more specific in defining your needs and select and IDE that fits best,

hth

Joachim



Am Donnerstag, 5. März 2015 04:32:56 UTC+1 schrieb Christian Tam:

Hi all!

I am currently doing a business project, and I am wondering if different implementations of Smalltalk are compitable with each other. (e.g. VA Smalltalk can run Smalltalk (Smalltalk-80 version 2) or Strongtalk code)

Thank you!

Hi Richard,

On Thursday, March 5, 2015 at 12:24:53 PM UTC-5, Richard Sargent wrote:

On Thursday, March 5, 2015 at 7:18:24 AM UTC-8, Louis LaBrunda wrote:

Hi Christian,

If you want a combination Smalltalk and COBOL system, VA Smalltalk is probably your best bet.  I'm not familiar with all the Smalltalk systems out there but I don't know of any with closer ties to COBOL than VA Smalltalk.

Will the system run on an IBM mainframe or an X86 or other based computer?  If it is an IBM system, then you definitely want to go with VA Smalltalk because of the ties Joachim referred to.

If this is an IBM mainframe based project and if it is large enough to warrant it, you may want to consider creating a packed decimal class (similar to ScaledDecimal) that matches the IBM packed decimal hardware data type used by COBOL.  You would need to write a DLL to do the math, which probably won't be easy, but should be a lot faster than ScaledDecimal.

There already *is* such a DLL. ESDEC40.DLL, the one ScaledDecimal uses to do its arithmetic operations. You won't need to write your own.

Does it use packed decimal when running on an IBM mainframe?  If so that's great.

Lou

 

 

Lou

On Thursday, March 5, 2015 at 12:17:23 AM UTC-5, Christian Tam wrote:

Thank you very much Joachim!

I was asking because VA smalltalk can load COBOL libraries (<a href="https://www.youtube.com/watch?v=tyjlxSPu0bU" rel="nofollow" target="_blank" onmousedown="this.href='https://www.youtube.com/watch?v\75tyjlxSPu0bU';return true;" onclick="this.href='https://www.youtube.com/watch?v\75tyjlxSPu0bU';return true;">https://www.youtube.com/watch?v=tyjlxSPu0bU), and in this project I'm working on, it says they are using Smalltalk code, but did not specify what implementation they were using. I was hoping the answer to my question was going to be yes because the project requires integrated two enterprise systems (one COBOL-based and one Smalltalk-based). And I was seeing if I could use the Smalltalk based system add parts of the COBOL-based system to it.

Thank you again for your quick and detailed response!

On Wednesday, March 4, 2015 at 11:02:37 PM UTC-5, Joachim Tuchel wrote:

Hi Christian,

Your question isn't easy to answer, because it depends on the code.

To make it short: Most Smalltalks share a common base of Classes and Methods that are compatible between most if not all dialects. But even in this kernel of functionality there are bits and pieces where some dialects show different behavior. There once was an effort to standardize the language and there is some ANSI Standard draft, but to be honest, it is mostly a piece of paper.

When it comes to GUI or Database or whatever libraries, there is not much of a common ground between dialects. Some are closer to each other than others, but whatever pairing of Smalltalk dialects you chose, there will be differing mileages.

There are, however, bodies of code that have been ported to most or even all dialects, like SUnit, Refactorings, Seaside, and whatnot. Some of these projects have taken quite some effort to make the code portable and compatible. There have been several approaches to make code exchangeable between dialects (Rosetta, SIF, Grease), some of which are still in heavy use (like Grease). The outcome of this is that you can use SUnit or Seaside on each Smalltalk implementation and use it without the need to learn anything new or change your test code.

So the situation is not as bad as it may sound at first, but the honest answer is: there is no such thing as an implemented "Smalltalk Standard".

Things seemed to improve a lot a few years ago, when everybody wanted to have Seaside on their platform. Vendors and O/S projects tried to make their Smalltalk more compatible. Unfortunately, we are now back to a world where they returned to their ivory towers where they do things cooler or faster than all the others. It is just the projects I mentioned before who try to stay current on all platforms.

No matter how bad my answer may sound, you shouldn't overestimate its consequences in comparison to other platforms. Look at Javascript: You can easily chose a library like jQuery or ReactJS or whatever and enter an incompatible niche that is its completely separated universe from others. If its implementors stop working on it, you are in trouble. This is true in so many ecosystems, not only JS, that I'd say you will most certainly face the same kind of problems in whatever language. It is even true in the C++ world.

We can like it or not, but the whole IT market is moving in this direction. Just imagine you wanted to build software for mobile devices. Here are your best choices: C#, Swift, Java. How compatible are these languages and their ecosystems?
The vendors want to suck you and your customers into their ecosystem as deeply as possible and I think they make them as incompatible as they can possibly make them.
Sure, there are tools and projects that try to bridge gaps. Some work, some work well, but in the end, you end up using a "meta-niche".

So what you ask for is not present in the Smalltalk world, but it also isn't in any other. If we like it or not...

OTOH, given that Smalltalk implementations are closely coupled with an IDE and its specific features, you should ask yourself what it is that you really need in Strongtalk and what you don't like about it. Which IDE seems to fit well into your way of coding, testing, etc?
Try to be more specific in defining your needs and select and IDE that fits best,

hth

Joachim



Am Donnerstag, 5. März 2015 04:32:56 UTC+1 schrieb Christian Tam:

Hi all!

I am currently doing a business project, and I am wondering if different implementations of Smalltalk are compitable with each other. (e.g. VA Smalltalk can run Smalltalk (Smalltalk-80 version 2) or Strongtalk code)

Thank you!

Does it use packed decimal when running on an IBM mainframe?  If so that's great.

Now *that* I really cannot answer. I just don't know anything about mainframe VA Smalltalk. Perhaps someone from Instantiations can answer.

Well, I do know one thing. There are no DLLs. :-) That's a Windows term.

Hi Richard,

 

Does it use packed decimal when running on an IBM mainframe?  If so that's great.

Now *that* I really cannot answer. I just don't know anything about mainframe VA Smalltalk. Perhaps someone from Instantiations can answer.

In addition to integers and floats the IBM mainframes have a data type called packed decimal and special hardware instructions to go along with it.  The instructions did the normal math stuff and helped convert to and from strings.  The packed decimal numbers are likes floats but decimal.  They have an exponent and mantissa like floats and our scaled decimals but with different ranges.  Each nibble (4 bits) of the mantissa was from 0 to 9.  The possible values from 10 to 15 are not used.  COBOL used packed decimal a lot.  They take up more memory than floats but are accurate to the penny (and more) which is why COBOL was used for finance.  Everything packed decimal was used for on mainframes we would use scaled decimal but we don't have hardware to help speed it up.

 

Well, I do know one thing. There are no DLLs. :-) That's a Windows term.

Right, I forget what the equivalent is on the mainframe in MVS or OS-Z or whatever the OS is called now.

Lou

On Thursday, March 5, 2015 at 1:24:15 PM UTC-8, Louis LaBrunda wrote:

Hi Richard,

 

Does it use packed decimal when running on an IBM mainframe?  If so that's great.

Now *that* I really cannot answer. I just don't know anything about mainframe VA Smalltalk. Perhaps someone from Instantiations can answer.

In addition to integers and floats the IBM mainframes have a data type called packed decimal and special hardware instructions to go along with it.  The instructions did the normal math stuff and helped convert to and from strings.  The packed decimal numbers are likes floats but decimal.  They have an exponent and mantissa like floats and our scaled decimals but with different ranges.  Each nibble (4 bits) of the mantissa was from 0 to 9.  The possible values from 10 to 15 are not used.  COBOL used packed decimal a lot.  They take up more memory than floats but are accurate to the penny (and more) which is why COBOL was used for finance.  Everything packed decimal was used for on mainframes we would use scaled decimal but we don't have hardware to help speed it up.

In the 70s and early 80s, I programmed on Big Iron. :-)
If I had to guess, I would guess that IBM did take advantage of their hardware in MVS Smalltalk. But, I would rather not guess.

On Thursday, March 5, 2015 at 4:53:28 PM UTC-5, Richard Sargent wrote:

On Thursday, March 5, 2015 at 1:24:15 PM UTC-8, Louis LaBrunda wrote:

Hi Richard,

 

Does it use packed decimal when running on an IBM mainframe?  If so that's great.

Now *that* I really cannot answer. I just don't know anything about mainframe VA Smalltalk. Perhaps someone from Instantiations can answer.

In addition to integers and floats the IBM mainframes have a data type called packed decimal and special hardware instructions to go along with it.  The instructions did the normal math stuff and helped convert to and from strings.  The packed decimal numbers are likes floats but decimal.  They have an exponent and mantissa like floats and our scaled decimals but with different ranges.  Each nibble (4 bits) of the mantissa was from 0 to 9.  The possible values from 10 to 15 are not used.  COBOL used packed decimal a lot.  They take up more memory than floats but are accurate to the penny (and more) which is why COBOL was used for finance.  Everything packed decimal was used for on mainframes we would use scaled decimal but we don't have hardware to help speed it up.

In the 70s and early 80s, I programmed on Big Iron. :-)
If I had to guess, I would guess that IBM did take advantage of their hardware in MVS Smalltalk. But, I would rather not guess.

John might know.  I seem to remember Smalltalk scaled decimal math being slower than COBOL math by about five times.  I don't want to guess either but I think we would have a PackedDecimal class because it is different enough from ScaledDecimal to warrant it.

Lou