[archive] MSIL .NET runtime

[Migrated content. Thread originally posted on 17 December 2002]

The announcment of a future MSIL .NET runtime, I like AcuCOBOL.NET better :), is great news. Could someone at AcuCorp answer a few questions about it, maybe Gisle? Please, Oh, Please :D

1. Will the Acucobol.NET runtime support all .NET built-in data types, in other words fully comply with the .NET CTS(Common Type System)?

2. Will .NET components be consumable by acucobol programs, and if so, can they sub-classed? (depends on answer to first question I suppose).

3. Will the AcuCOBOL.NET runtime debugger be able to interface with the .NET debugger?

and finally,

4. In part, based on above questions, does an MSIL .NET runtime mean AcuCorp will possibly release it's first Object Oriented version of the AcuCOBOL programming language??

Thanks.

As you certainly know, we have an official statement regarding .net support, and whether or not I should go further than that document, I will have to think twice about. I can at least assure you that this kind of subjects (inter program communications) are going to be a hot topic at next years conference in San Diego.

But I can tell you an answer to your question #4, regarding ACUCOBOL-GT and OO:

No, the incremental support for .net does not include OO COBOL. We are continously monitoring the market movement, its demands and the general development of technologies, and if a strategic shift happen, we will be there. But as of current, the demand has simply put, been almost non existant for us to support OO COBOL.

However, as said, we evaluate the need/request for this as other technology regularly and things may change fast. I would also make a point in that the new COBOL standard is as well an incentive for supporting OO COBOL as is the .net technology. Remember we are at other platforms as well, Microsoft is just one of many.

I believe I by saying that we won't provide OO COBOL as of yet, also provides a partial answer to your second question, in that you will not be able to sub class .net components.

At any rate, remember we are here talking of first generation support, as you certainly know. ACUCOBOL-GT has a history of introducing new technology and enhancing, so who knows what is coming up next.

[Migrated content. Thread originally posted on 17 December 2002]

The announcment of a future MSIL .NET runtime, I like AcuCOBOL.NET better :), is great news. Could someone at AcuCorp answer a few questions about it, maybe Gisle? Please, Oh, Please :D

1. Will the Acucobol.NET runtime support all .NET built-in data types, in other words fully comply with the .NET CTS(Common Type System)?

2. Will .NET components be consumable by acucobol programs, and if so, can they sub-classed? (depends on answer to first question I suppose).

3. Will the AcuCOBOL.NET runtime debugger be able to interface with the .NET debugger?

and finally,

4. In part, based on above questions, does an MSIL .NET runtime mean AcuCorp will possibly release it's first Object Oriented version of the AcuCOBOL programming language??

Thanks.

I appreciate the quick response. I now have a better idea on what to expect from the initial version of the MSIL runtime.

In regards to OO ACUCOBOL, my thought was not so much in the area of customer demand, as it was providing a more natural integration with .net and the .net framework. For instance, VB.NET is a much better ".net" langugage than VB6 is, due to VB.NET's full OOP model, and it's deep ties with the .net framework and CLR. I just thought perhaps ACUCOBOL might head in this direction as well.

I understand OO COBOL can be a big learning curve for existing COBOL programmers, thus many of them are not asking for it. Some of them I've talked to simply feel OO is just another way of doing things you can already accomplish, so what's the point in switching to it. That's a valid argument, but it neglects the fact that more and more programmers, and IT folk, are being raised on OO methodolgy and think and design in OO terms, and want to make full use of that knowledge, and will be more attracted to development products that let them do that.

So, what concerns me most for Acucorp are the OO minded programmers and IT decision makers out there who are saying nothing and simply going another direction. I'm not so sure you can only listen to your current clients demands when it comes to strategic improvements to the ACUCOBOL programming language. In other words, perhaps there is a growing population of OO programmers, and IT decision makers, to which ACUCOBOL could be more appealing than it is. Perception, unfortunately, goes a long way. I believe the COBOL consortium understands this as well.

Did OOP COBOL help MicroFocus? I'm not sure, perhaps their business model and practices are really whats tripped them up. Seems Fujitsu is doing well with OOP COBOL and .net, but time will tell.

Would be interesting if Acucorp could run a poll on some major technology websites that asked the question, "If more COBOL language vendors provided full Object Oriented Programming features, would COBOL be a more attractive technology solution for application development?"

I'm only raising the questions, I don't pretend to know the answers. Just some thoughts, I could be way off base. :eek: Thanks for listening.

[Migrated content. Thread originally posted on 17 December 2002]

The announcment of a future MSIL .NET runtime, I like AcuCOBOL.NET better :), is great news. Could someone at AcuCorp answer a few questions about it, maybe Gisle? Please, Oh, Please :D

1. Will the Acucobol.NET runtime support all .NET built-in data types, in other words fully comply with the .NET CTS(Common Type System)?

2. Will .NET components be consumable by acucobol programs, and if so, can they sub-classed? (depends on answer to first question I suppose).

3. Will the AcuCOBOL.NET runtime debugger be able to interface with the .NET debugger?

and finally,

4. In part, based on above questions, does an MSIL .NET runtime mean AcuCorp will possibly release it's first Object Oriented version of the AcuCOBOL programming language??

Thanks.

Just to finalize your initial questions. Yes we are going to support the datatypes of .net, which reasonably enough is embedded in the answer of the second question which I gave yesterday, that is, they will be consumable.
As for the third question, we are not planning on a full integration with the .net runtime debugger as of yet.

You got some valid angles on the question about OO Cobol, and I do myself appreciate the OO technology in many contextes. And you are certainly right that some people might consider COBOL as outdated, just because it isn't OO. Giving it a second thought though, I am not so sure about it. The flaming campaign that media has ran for over a decade stating COBOL as dead is probably not so much related to the lack of OO or not. If it were, Fujitsu and MF should have had golden days, which I don't think we can claim them to have.

At any rate, we haven't closed the door, nor do we intend to.

[Migrated content. Thread originally posted on 17 December 2002]

The announcment of a future MSIL .NET runtime, I like AcuCOBOL.NET better :), is great news. Could someone at AcuCorp answer a few questions about it, maybe Gisle? Please, Oh, Please :D

1. Will the Acucobol.NET runtime support all .NET built-in data types, in other words fully comply with the .NET CTS(Common Type System)?

2. Will .NET components be consumable by acucobol programs, and if so, can they sub-classed? (depends on answer to first question I suppose).

3. Will the AcuCOBOL.NET runtime debugger be able to interface with the .NET debugger?

and finally,

4. In part, based on above questions, does an MSIL .NET runtime mean AcuCorp will possibly release it's first Object Oriented version of the AcuCOBOL programming language??

Thanks.

Just to finalize your initial questions. Yes we are going to support the datatypes of .net, which reasonably enough is embedded in the answer of the second question which I gave yesterday, that is, they will be consumable.
As for the third question, we are not planning on a full integration with the .net runtime debugger as of yet.

You got some valid angles on the question about OO Cobol, and I do myself appreciate the OO technology in many contextes. And you are certainly right that some people might consider COBOL as outdated, just because it isn't OO. Giving it a second thought though, I am not so sure about it. The flaming campaign that media has ran for over a decade stating COBOL as dead is probably not so much related to the lack of OO or not. If it were, Fujitsu and MF should have had golden days, which I don't think we can claim them to have.

At any rate, we haven't closed the door, nor do we intend to.

[Migrated content. Thread originally posted on 17 December 2002]

The announcment of a future MSIL .NET runtime, I like AcuCOBOL.NET better :), is great news. Could someone at AcuCorp answer a few questions about it, maybe Gisle? Please, Oh, Please :D

1. Will the Acucobol.NET runtime support all .NET built-in data types, in other words fully comply with the .NET CTS(Common Type System)?

2. Will .NET components be consumable by acucobol programs, and if so, can they sub-classed? (depends on answer to first question I suppose).

3. Will the AcuCOBOL.NET runtime debugger be able to interface with the .NET debugger?

and finally,

4. In part, based on above questions, does an MSIL .NET runtime mean AcuCorp will possibly release it's first Object Oriented version of the AcuCOBOL programming language??

Thanks.

Thanks again for the reply. :)
Hope I'm not putting you on the spot.
Wouldn't it be great to see the "almost" standard OO COBOL langugage specifications available in acucobol when the MSIL runtime was released. I mean OO COBOL syntax should be rich enough to handle .net component programming, java component programming, etc, as well as just straight OO COBOL code, shouldn't it? Wouldn't that be a better overall strategy than adding more propietary syntax like what was done in acucobol for ActiveX/COM? In other words, have just one set of OO COBOL langugae features in acucobol that can be used for all OO based language/framework interoperability. Doesn't that better fit the acucobol ubiquity approach?

[Migrated content. Thread originally posted on 17 December 2002]

The announcment of a future MSIL .NET runtime, I like AcuCOBOL.NET better :), is great news. Could someone at AcuCorp answer a few questions about it, maybe Gisle? Please, Oh, Please :D

1. Will the Acucobol.NET runtime support all .NET built-in data types, in other words fully comply with the .NET CTS(Common Type System)?

2. Will .NET components be consumable by acucobol programs, and if so, can they sub-classed? (depends on answer to first question I suppose).

3. Will the AcuCOBOL.NET runtime debugger be able to interface with the .NET debugger?

and finally,

4. In part, based on above questions, does an MSIL .NET runtime mean AcuCorp will possibly release it's first Object Oriented version of the AcuCOBOL programming language??

Thanks.

May be, may be not. At present that is a hypotetical question though.