Quote:

And actually, VB.Net comes really close to C#. Almost anything that can be done in C# can also be done in VB.Net. Biggest difference is that VB.Net code is more 'verbose'.

Yes, because all .Net languages share the same CLR. But the VB.Net syntax is horrific in terms of OO, trying to combine classic VB with OO notation. Whazzup with: " myLength = Len(myString) " instead of " myLength = myString.length; " ... no OO there ...
I can write C, C++, C#, Java, J# and VB (among others), but I dropped VB.Net immediately, can't get this crippled-OO notation in my head.
NOFI, but don't get me started on this subject ;-)

But on topic; a good Basic-editor sounds like a good idea, it could even 'encapsulate' labels while creating BASIC-compatible opcode.
This way one could use labels, but the result would still be a 'normal' BASIC program ...

OO *shouldn't* be put in a next MSX-BASIC, since OO is even too hard for the average programmer (I remember fellow students who didn't understand it at all, also says something about the education level ), for starting programmers it would be way too hard. Although simple data structures would be nice to have.

*offtopic*
it seems you would need to look at VB.Net a little better (although, don't do that, just use c# if you need to do something in .Net). VB.Net does have string classes and "myLength = myString.Length" works perfectly fine. Of course, you can still use "mylength = Len(myString)" but that's more a legacy thing that should've been dropped...
*/offtopic*

For what it's worth: you shouldn't teach OO, you should let them coders find out themself. Let them make some app with many different things, let them make something big. Eventually they could come up saying things are getting messy.. if you're lucky they even have a slight idea how to solve it. If you're very lucky they're already referring to OO without knowing they're referring to OO.

The thing that goes wrong in some books is that OO is explained with stupid small test programs, as a n00b-coder you can't see the benefits of it then. Those books rarely explain how programming big projects works..

(imho)

Then you're reading the wrong books...

You're absolutely right about that Wolf; one just has to see the light, but I see a lot of newbies over-designing their apps |-(

Quote:

it seems you would need to look at VB.Net a little better (although, don't do that, just use c# if you need to do something in .Net). VB.Net does have string classes and "myLength = myString.Length" works perfectly fine. Of course, you can still use "mylength = Len(myString)" but that's more a legacy thing that should've been dropped...

But the legacy is not dropped, it's a feature, that's my point ! In some respect VB.Net's power is also it's weakness ...
VB.Net is a more (VB-like) task-/procedural-based language which facilitates the use of OOP, but it doesn't require it (in a OO-based CLR).

It's legacy with VB is a good thing in some cases, especially for migrating to the .Net framework, but the VB.Net language & syntax are rather 'unfortunate' ...from a designers-viewpoint it leaves extra room for inconsistency compared to other languages.
C#, J# (or no .Net: Java) with their stricter syntax and more consistent language might be more appropiate.

The less stuff to worry about, the better ;-)

If we're talking about a new MSX-Basic version I'd still prefer something like JavaScript (it's easy but powerful enough !),
a good editor/IDE and inline-asm support like Turbo Pascal / Delphi. And ofcourse at least at KUN-BASIC speed ;-)

SKiLLa, it seems I misinterpreted your post and took some things too literally... Maybe my mind got corrupted by programming to much in VB/VB.Net I agree that VB.Net should've gotten a stricter syntax, no legacy VB stuff. If they can support it in the compiler (which translates Len(myString) to myString.Length anyways) they surely could've written a decent program to migrate old projects. Although not supporting legacy in VB.Net would've meant there's no need for VB.Net because otherwise it's mostly just a more verbose language.

JavaScript would be cool to have on MSX, I prefer it over any BASIC variant (well maybe not over VB.Net (mainly because of the framework behind it), but if I had the choice I would use C# instead of VB.Net). It's even possible to do OO'ish things in it

Quote:

I stick to my previous points: NO object orientation in our BASIC

I agree!

Quote:

Furthermore: more clarity to the dangling 'else'-clause of the if-then(-else)? statement, while is not necessary, as we have IF and GOTO

If I got you right, you mean a nested IF-statement? Then, we would need block markers like begin and end like in Pascal. This wouldn't be BASIC anymore. So I agree, we have IF and GOTO, even if it's not
good style in other languages.

but WHY do you want basic to stay 'oldfashioned' even if MANY other basic-variants have such things as block-if, select, functions etc. etc. ? It's not blasphemy to update basic orso..

Perhaps because an 'old-fashioned' BASIC is just what it is: a great stepping stone into the world of programming. If you introduce more structure/OO stuff in it, surely an advanced coder will be able to do much nicer things with it, but a complete beginner (especially youngster) will not be very keen on learning the language anymore.

Take your example:

Class Window

  Private

    Field A
    Field B#
    Field C%
    Field D$

    Function MyFunction(Look!, Rare!, Neverbeenused$, W00000T#)
    End Function

  End Private

  Public
    Field F!

    Function MyFunction2$(ForSale#, Amount_of_Boblets)
    End Function

    Function MyFunction3#(Ebay_comission, Tax)
    End Function

  End Public

  Constructor(x,y,z=1)
  End Constructor

  Destructor
  End Destructor

End Class


M33P=ApplyClass(Window)

M33P.MyFunction3(1,2)

M33p.Destructor()

End

If MSX-BASIC would have looked like this when I was a 5 year old, I would never have coded a single line of MSX-BASIC on it. Beginners want the 10 PRINT "HEY, THIS WORKS! ": GOTO 10 stuff So please, no declaring variables, block-if, procedures, functions or o.O in the default BASIC. It is very likely to scare people off. A more structural, powerful BASIC might be a great second step in the world of coding tho

I don't imply block-IFs with my remark 'properly nested IF-statements':

10 A=2:B=3
20 IF A=2 THEN IF B=3 THEN PRINT "A=2 and B=3" ELSE PRINT "A=2" ELSE PRINT "A<>2"

Two else clauses after another, thus ensuring proper nesting. It's easily done, and intuitively, it works like it should. It's a real pity that this ELSE-behaviour hasn't been implemented.

snout: you don't HAVE to use those classes! If you're 5yo, and you want to type 10 print"elephant":goto 10 then you can!
Those classes should be (and *are*, even in c++) an addition. Even in c++ you may make the most horrible spagetti code if you want to..

But really, *how* do you know that a 5yo kid is scared by this:

IF snout=MSXguru THEN
' do something
END IF

.. did you ask them? WHY do you think this is so unreadable?

10 IF snout=guru THEN GOTO 20 ELSE GOTO 50
20 '
30 '
40 '
50 <continue>

I don't know about you, but I do know what I think about that alternative

Quote:

but WHY do you want basic to stay 'oldfashioned' even if MANY other basic-variants have such things as block-if, select, functions etc. etc. ? It's not blasphemy to update basic orso..

Do you mean me or do you mean [D-Tail] to answer this question? I just answered to [D-Tail]'s post!

Wolf_, your question is very philosophical and worth to open a separate threat to discuss it. Following the discussion here, one could get the impression that we talk about different things. Do we talk about already existing MSX computers and possible modifications or improvements on the first 32 KB of ROM, or do we talk about the OCM, or do we talk about what possibly comes after the OCM, maybe MSX3 or something different, but somehow related to MSX (that means it comes from the MSX Association, has 69 bit data- and 93 bit adress bus, is based on a Z8000000000 processor implemented in an FPGA)?

IF we talk about existing MSX computers and improvements on the existing BASIC, than forget about OOP and (almost) all the other things mentioned. There's no place in the BASIC ROM to add that features, I think. (But maybe place for little improvements such as BASIC hotkeys like on the ZX81 or ZX Spectrum or VZ200, if we would modify the code and making another ROM to replace the original one. The modification mentioned wouldn't even violate compatibility!)

So WHY do I want basic to stay 'oldfashioned' even if MANY other basic-variants have such things as block-if, select, functions etc. etc. ?

First of all, I talk about 'BASIC', not about 'basic'. The acronym BASIC stands for Beginners All Purpose Symbolic Instruction Code, while 'basic' means something different, as was already mentioned.

As the name implies, BASIC is something for beginners. BASIC was invented in a time with other computational constraints than today and with less experience in software engineering than today. That's not BASIC's fault, therefore I still accept BASIC for that what it is. (Maybe we should call this kind of BASIC implementations ''classical BASIC'' to distinguish them from modern BASIC's.) So do you like to stay beginner forever?

It has turned out that BASIC's way of designing software is not the way we should proceed for many reasons. So, we could ask ourselves, why not totally discard BASIC and exclusivly using 'better' languages more appropriate to modern computers and software design methodologies? To my mind thats why one must experience the problems of one language to appreciate the benefits of another!

Modern BASICs have features which violate the basic BASIC concepts. This BASICs are still named BASIC, but looking like other languages. Yes, you can add lots of features of other languages you consider as good or desirable, but some of this features doesn't work together well, see the horrific VB.NeT syntax in terms of OO mentioned by SKiLLa. And for compatibility reasons, you can't drop obsolete features. So the language gets more and more complex so you can't survey it. You'll get inconsistencies in syntax and semantics and it is difficult to learn, especially for thouse who didn't had the chance to start learning coding when the whole developement started. For them, these modern BASICs must look ridiculous in many ways, especially if you heavily intermix 'old-fashioned' and modern features.

Its not blasphemy to update, yes, but it must be done wisely. And you must recognice when it doesn't make sense!

Besides the nostalgy, new programmers to come also must know about the historical developement. It must be possible to experience the homecomputer feeling, even if there are more powerful computers today. Even in the future, it must be possible to experience real homecomputers and its features. Unfortunatly, severeal of this features were discarded in modern computers, even if they are interesting and would ease up the use of modern computers. It must still be possible to experience that computers can be something different as the standard system used nowadays!

Quote:

Backwards compatibility is only affected if an already existing feature of MSX-BASIC would be redefined in a possible MSX3-BASIC.

That's also making it non backward compatible. But MSX2 BASIC is not backwards compatible with MSX1 BASIC. It's MSX1 BASIC which is forward compatibale with MSX2 BASIC. A whole lot of a difference...

Quote:

Quote: Backwards compatibility is only affected if an already existing feature of MSX-BASIC would be redefined in a possible MSX3-BASIC. That's also making it non backward compatible. But MSX2 BASIC is not backwards compatible with MSX1 BASIC. It's MSX1 BASIC which is forward compatibale with MSX2 BASIC. A whole lot of a difference...

Maybe you think of backwards compatibility in a different way. MSX2-BASIC is backwards compatible to MSX1-BASIC because of an MSX1-BASIC programm will also run on a MSX2-machine. Thats only possible if additional syntax and semantics doesn't change already existing syntay and semantics. A program using MSX2 specific statements naturally will not run on MSX1! According to your understanding of backwards compatibility, there'll be no evolution if you try to be backwards compatible.

Quote:

That's also making it non backward compatible. But MSX2 BASIC is not backwards compatible with MSX1 BASIC. It's MSX1 BASIC which is forward compatibale with MSX2 BASIC. A whole lot of a difference...

Huh, when a MSX1 BASIC program functions correctly in MSX2 BASIC without modifications, we call this MSX2 BASIC backwards-compatible with MSX1 BASIC, not ? Something as 'forward compatibility' is not in my dictionary. I could be wrong, but I doubt it ...

As Tanni marked out (among others), the discussion is a little 'wide', talking about the OCM BASIC, a new (modified) MSX-BASIC and even a complete new MSX-Language (Yes, vote for JS ;-). Perhaps a good subject for the next poll ( * HINT * ) ?

For the OCM I'd just like to see a 'normal' MSX-BASIC, with KUN-BASIC included. For a modified MSX-BASIC one might just add 'call [extra commands] as a plugin. And instead of a heavily modified MSX-BASIC syntax (which is not compatible with the existing MSX-BASICs) I prefer something like JS-based (or VBScript-based) as a new MSX language. Not a complete new, yet to be defined BASIC syntax. It would be easier for everybody to learn the JS/VBS notation (just with build in 'MSX objects' like VDP and MUSIC, like ASP does to VBS). This way the syntax is a 100% JS/VBS complaint, but has full MSX-functionality ...

Now please feel free to shoot at my 2 cents ...