On Sunday 18 January 2009, M Harris wrote about 'Re: [opensuse] Perhaps <OT>: Visual Basic into MONO':

On Thursday 15 January 2009 13:05, Boyd Stephen Smith Jr. wrote:

...

If you run it against programs of any complexity you either get code that won't compile (syntax error) OR you get code that has many more bugs (runtime errors).

geeze... remember when "computer science" wasn't an oxymoron?

I don't believe it is. Unfortunately, I've yet to deal with a company or project that applied it to IT support or software development formally and consistently. Instead, we get XP and unit tests instead of correct code with known failure cases. It should be noted that, to the best of my knowledge, there is no BASIC dialect with a behavior as well specified as the C or C++ standards. (Those leave a bit to be desired, too, but are probably the best we have.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/

On Monday 2009 January 19 02:20:54 Roger Oberholtzer wrote:

On Sun, 2009-01-18 at 02:34 -0600, Boyd Stephen Smith Jr. wrote:

...

It should be noted that, to the best of my knowledge, there is no BASIC dialect with a behavior as well specified as the C or C++ standards. (Those leave a bit to be desired, too, but are probably the best we have.)

Of course. But in this case, it is MS and their own VBasic product. The various dialects of VB must surely be understood by MS.

I disagree that they have to understand it. The "correct" behavior of a piece of VB 6 code is "whatever the MS VB 6 interpreter does". That's difficult to replicate completely in practice; it's hard enough to maintain during the product lifecycle. The "correct" behavior of a piece of VB 5 code is "whatever the MS VB 5 interpreter does" -- even if this differs from what the MS VB 6 interpreter does on the same code.

Surely they know the syntax and could import it into the .NET framework.

Maybe, but they haven't shown enough interest in doing so. Last I checked, they recommended VB 6 (or before) shops move to VB.Net and provided the aforementioned, buggy migration tool to help with some of the rewriting. Also, being a .Net language means that all of your syntax needs to map to CLI bytecode, instead of x86 machine code -- not necessarily the easiest translation.

I am a bit confused by the real issues. VB code (any code, for that matter), has two relevant properties in this context:

1) the language itself. Is it supported at the syntactic level?

Each new version of VB is a slightly different language. However, they are traditionally similar enough in syntax that only a few constructs have to be altered and sometimes this can be automated. VB.Net is really a brand-new language, with a syntax that, on the surface, feels familiar to VB 6 coders. That is, it looks like VB instead of looking like Java or C++. However, there is syntax that is valid in both VB 6 and VB.Net that has different semantics. In specific, MS's .Net development environment has support for VB.Net (aka "VB 7") at the syntactic level. At this point, Mono does as well.

2) system interface. (G)UI, hardware access (keyboards, mice, files)

This is unified across the .Net framework and standardized as the CLR. It is not language-specific when you discuss .Net languages. VB.Net, C#, "Managed C++", have equal access to these interfaces. If you follow a few simple rules when you are writing your libraries in any one of these languages, all of the others can access them transparently, just like the CLR.

So, does .NET allow things to be written in VB at all?

VB 6? No. VB.Net? Yes.

I know that languages like C# are preferred. But they are not mandatory. Are they?

No. It is of course possible to design a .Net language that does not have a syntax for accessing some CLI construct, possibly making some of the CLR difficult to interact with, but such a language would be a "second-class citizen" by design. I don't think VB.Net is like this, but I've not written much VB.Net code, and the code I was writing had no need to access the "lower-level" or "lesser-used" areas of the CLR.

I would have guessed that item 2 in the list above is the primary issue.

Oddly enough, not when you are talking about .Net languages.

So if an application has separated the user interface from the calculations ('pure language' calculations and no user/system I/O), shouldn't it be 'easy' to get 'pure language' parts into .NET/MONO? As always, the GUI is the trouble part.

I'm not sure this is particularly relevant. I think good separation of roles makes the code easier to maintain and port. But, if you want to run on the CLR, you are going to have to move each and every part of program to a .Net language anyway. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/