TwinBasic

My concern about new features is that...
OK, this assumes that RadBasic will succeed. I think Carles is making progress, but I don't have much information about that now.

So, at the moment we have something that is already working, and well (twinBASIC) and something that we don't know (RadBasic).
So, we can't "ask" for nothing on that basis now.

But assuming that RadBasic will succeed, I would like for the VB6 successors to form something like a "consortium", where they could agree on the language.
Of course I don't mean the I want identical products, but I mean as compatible as possible.
For example, if both languages will add tuples, do it with the same syntax.

twinBasic already added lots of new features and syntax, and some of us have been helping on that process (OK, personally I very little). We discuss things trying to find the best way to do something.
I think, "and what would Carles do?". I don't know, but I think that the best syntax for tW will also be the best for RB.

Carles already stated that his route is (like the ideas of yereverluvinuncleber) first to achieve full replacement of VB6 and only after that to introduce improvements and add new features.
But of course he will have to do that at some point (to add new things and syntax), so my concern is that both languages should be as compatible as possible and more important: the language itself should use same syntax.
That is my wish, of course, it is my opinion.

OK, it is still too early.
We'll have to wait until RB is available to the open, and if Carles sticks to the idea of not adding new features until the full replacement is achieved, until then.
But I wanted to express my concern, and my wishes (in advance, for that moment).

I have always suggested something like the ECMA group but for BASIC. However, if you think about having Olaf and Niya on the same group or anyone similar with strong views it would be a continuous battle. You'd have to physically keep the .NOTters out of the room.

VB6 acts as the design for the basis of both products and we would hope that what is good for one is also good for the other. I believe that Carles' approach is the preferable one. It is both an approach and a goal combined and achieving such an early consensus is something that only a one man team can easily achieve.

Carles and the TB chaps have spoken but I think both of their heads will be down in the code trying to meet their milestones and too busy to work in concert on new functionality. Carles at least will have the benefit of hindsight when it comes to making any decisions on language features as the TB team will have spent their precious time working it all through.

Quote:

---

Originally Posted by yereverluvinuncleber

I have always suggested something like the ECMA group but for BASIC. However, if you think about having Olaf and Niya on the same group or anyone similar with strong views it would be a continuous battle. You'd have to physically keep the .NOTters out of the room.

---

I'm not talking about Niya and Olaf, but Wayne and Carles.
All the others (like us) can be proponent of ideas, express opinions, but don't decide anything.

They could add more people to the "management group" (the consortium) of course, if they want.

Quote:

---

Originally Posted by Eduardo-

I'm not talking about Niya and Olaf, but Wayne and Carles.
All the others (like us) can be proponent of ideas, express opinions, but don't decide anything.

They could add more people to the "management group" (the consortium) of course, if they want.

---

Yes of course but I was referring to an ECMA-type group that I had previously suggested. I realised from the outset that the idea was/is a non-starter.

Quote:

---

Originally Posted by yereverluvinuncleber

Yes of course but I was referring to an ECMA-type group that I had previously suggested. I realised from the outset that the idea was/is a non-starter.

---

If you put everybody there, yes.
But I didn't suggest that.

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

Quote:

---

Originally Posted by Eduardo-

My concern about new features is that...
OK, this assumes that RadBasic will succeed. I think Carles is making progress, but I don't have much information about that now.

So, at the moment we have something that is already working, and well (twinBASIC) and something that we don't know (RadBasic).
So, we can't "ask" for nothing on that basis now.

But assuming that RadBasic will succeed, I would like for the VB6 successors to form something like a "consortium", where they could agree on the language.
Of course I don't mean the I want identical products, but I mean as compatible as possible.
For example, if both languages will add tuples, do it with the same syntax.

twinBasic already added lots of new features and syntax, and some of us have been helping on that process (OK, personally I very little). We discuss things trying to find the best way to do something.
I think, "and what would Carles do?". I don't know, but I think that the best syntax for tW will also be the best for RB.

Carles already stated that his route is (like the ideas of yereverluvinuncleber) first to achieve full replacement of VB6 and only after that to introduce improvements and add new features.
But of course he will have to do that at some point (to add new things and syntax), so my concern is that both languages should be as compatible as possible and more important: the language itself should use same syntax.
That is my wish, of course, it is my opinion.

OK, it is still too early.
We'll have to wait until RB is available to the open, and if Carles sticks to the idea of not adding new features until the full replacement is achieved, until then.
But I wanted to express my concern, and my wishes (in advance, for that moment).

---

Well the number #1 goal above all else is VB6 compatibility. I think this could be achieved while giving most people what they want.

Quote:

---

Originally Posted by wqweto

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

---

This would make for an interesting discussion. Is the Continue statement worth the incompatibility with projects that use Continue as a line label? I think it is but I'm curious to see any counter arguments to this.

Quote:

---

Originally Posted by wqweto

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

---

I don't think it would be difficult to parse, since labels go after a GoTo or a Gosub, and no more (AFAIK, but may be I'm missing something).
If the "Continue" is after a GoTo or a GoSub, then it is a label, and any "Continue" on that procedure means the label and not the new keyword.

But the parser should first search the whole procedure code to see if there is a "Continue" after a GoTo or a GoSub, because the label could be at the beginning.

I'm not sure if it worth the complication, but possible I think it is possible.

Quote:

---

Originally Posted by Eduardo-

If you put everybody there, yes.
But I didn't suggest that.

---

Nor did I.

Quote:

---

Originally Posted by Niya

Well the number #1 goal above all else is VB6 compatibility.

---

Yes.

Quote:

---

Originally Posted by Niya

I think this could be achieved while giving most people what they want.

---

I have no idea what that means in the context. I was talking about agreeing on the same syntax for new language additions and improvements.

Quote:

---

Originally Posted by yereverluvinuncleber

Nor did I.

---

OK, then IDK what you suggested.

I think that having as many opinions (qualified ones) as you can get, the better.
But the decisions should be made by a few, namely Carles and Wayne.

Quote:

---

Originally Posted by Niya

This would make for an interesting discussion. Is the Continue statement worth the incompatibility with projects that use Continue as a line label? I think it is but I'm curious to see any counter arguments to this.

---

I think it does, otherwise now in VB6 you have to use GoTo or to set variables and check conditions.

Quote:

---

Originally Posted by wqweto

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

---

I think Carle's approach is simply cleaner and if it gets RB into a position to correspond to Baka's first list then it is a win for us. I can't comment on the technological approach of each team but if all else is equal and the speed of development is the same then RB's approach would seem to be the one that will get them to that point faster.

Wayne is very good to respond to queries, requests and considering new functionality but isn't that slowing him down from the core goals?

Quote:

---

Originally Posted by Eduardo-

I have no idea what that means in the context. I was talking about agreeing on the same syntax for new language additions and improvements.

---

What I mean is they can give people modern features while still achieving the goal of VB6 compatibility. All I'm saying is that these two goals are not mutually exclusive.

For example, if I were to use TwinBASIC on a full time basis, I'd want to have higher order functions. It would be one of my biggest wants. I doubt that this would conflict with the ultimate goal of VB6 compatibility. Some people want Tuples and I've seen a whole lot of very interesting suggestions on their GitHub discussions and to my mind, I think most of them can be implemented without impacting the main mission of VB6 compatibility.

Quote:

---

Originally Posted by Eduardo-

OK, then IDK what you suggested.

---

I keep wondering why you keep bringing it up... :)

All else agreed.

Quote:

---

Originally Posted by Eduardo-

I don't think it would be difficult to parse, since labels go after a GoTo or a Gosub, and no more (AFAIK, but may be I'm missing something).
If the "Continue" is after a GoTo or a GoSub, then it is a label, and any "Continue" on that procedure means the label and not the new keyword.

But the parser should first search the whole procedure code to see if there is a "Continue" after a GoTo or a GoSub, because the label could be at the beginning.

I'm not sure if it worth the complication, but possible I think it is possible.

---

Actually there is a solution. Micorsoft's solution to this was square brackets. In VB.Net if you wanted to use a reserved keyword as an identifier, you surround it in square braces like this:-

Code:

---

[Continue]

---

Something like this would probably work to solve this problem.

Quote:

---

Originally Posted by Niya

What I mean is they can give people modern features while still achieving the goal of VB6 compatibility. All I'm saying is that these two goals are not mutually exclusive.

For example, if I were to use TwinBASIC on a full time basis, I'd want to have higher order functions. It would be one of my biggest wants. I doubt that this would conflict with the ultimate goal of VB6 compatibility. Some people want Tuples and I've seen a whole lot of very interesting suggestions on their GitHub discussions and to my mind, I think most of them can be implemented without impacting the main mission of VB6 compatibility.

---

VB6 backward compatibility and full replacement (of VB6 main core, I mean the IDE, compiler) is out of the question. Both have been totally clear about the point.

To enhance it, is also well explicitly set on both cases.
The difference is the path, while RB plan is to achieve the full replacement first, tB path is to add new features in the way, and from the beginning.

I say this based on what I read on their websites.

Quote:

---

Originally Posted by Niya

Actually there is a solution. Micorsoft's solution to this was square brackets. In VB.Net if you wanted to use a reserved keyword as an identifier, you surround it in square braces like this:-

Code:

---

[Continue]

---

Something like this would probably work to solve this problem.

---

That won't work for providing backward compatibility.
The VB6 code is already written.

Quote:

---

Originally Posted by Niya

Olaf is. He doesn't want the language to be changed that much.

---

Nonsense.

What I want (doing compiler-development myself), is the developer to concentrate on 1:1 compatibilit first.
That's "hard enough" to do.

Only *after* that goal is reached, extensions to the language should be discussed.
(aside from a few things, which "come cheap" - as e.g. variable initializing in the Dim-Line).

And while discussing such extensions, one should not make the mistake of:
- "intruducing something new", which is already existing

And in case of Tuple-support, we basically already have "full compatibility, to how python handles tuples".
in python, you write:
SomeTuple = (1, 2, 3)
and you access "tuple-members" by specifying a zerobased index:
print(SomeTuple[0])

In VB we would do:
SomeTuple = Array(1, 2, 3)
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

So, one simple thing a compiler-dev could do (if the goal is, to make it "more python-compatible") -
is, to make the Array-Function specifier "optional" (which should not be that hard, when a comma-separated list is enclosed by parentheses).
So, that the "new VB" code could be written this way:
SomeTuple = (1, 2, 3) ' or Return (1, 2, 3) which TB already supports for function-results
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

Eh voila, python-compatible tuple-support in "new VB"...

As for the kind of new features I would like to see (or implement) in a VB6-successor,
I would always prefer to open it up to the "lower end" - so that it becomes more "C-like".

E.g. an easy way to pre-define Function-Declarations in a Const-Variable -
then passing this "typed Function-Pointer" along into Routines (as a nice, lowlevel way to support "delegates").

VB6 already is as a thin (COM-layer-supporting) abstraction on top of C/C++...
And I would like (in potential new features), when it would "open up a bit more to that lower level" -
(making it easier to access with less typing-efforts, supported by more compiler-checks).

Olaf

Quote:

---

Originally Posted by Eduardo-

VB6 backward compatibility and full replacement (of VB6 main core, I mean the IDE, compiler) is out of the question. Both have been totally clear about the point.

To enhance it, is also well explicitly set on both cases.
The difference is the path, while RB plan is to achieve the full replacement first, tB path is to add new features in the way, and from the beginning.

I say this based on what I read on their websites.

---

Ah ok I see what you're getting at. I'm not sure I have much of a strong opinion on differences between tB and RB. I'd have to see what RB is doing to really form a solid opinion.

Quote:

---

Originally Posted by Schmidt

Nonsense.

What I want (doing compiler-development myself), is the developer to concentrate on 1:1 compatibilit first.
That's "hard enough" to do.

---

That's fair as long as it doesn't just stop there at 1:1 compatibility. That's all I'm saying.

Quote:

---

Originally Posted by Schmidt

And in case of Tuple-support, we basically already have "full compatibility, to how python handles tuples".
in python, you write:
SomeTuple = (1, 2, 3)
and you access "tuple-members" by specifying a zerobased index:
print(SomeTuple[0])

In VB we would do:
SomeTuple = Array(1, 2, 3)
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

So, one simple thing a compiler-dev could do (if the goal is, to make it "more python-compatible") -
is, to make the Array-Function specifier "optional" (which should not be that hard, when a comma-separated list is enclosed by parentheses).
So, that the "new VB" code could be written this way:
SomeTuple = (1, 2, 3) ' or Return (1, 2, 3) which TB already supports for function-results
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

Eh voila, python-compatible tuple-support in "new VB"...

---

Well I'll say this. For me personally, Tuples aren't something I'll fight to the death for but that doesn't mean others won't. I could personally live without them but I do see their value and I can understand why some may want them. All I'm saying is to give these people a fair hearing.

Quote:

---

Originally Posted by Schmidt

As for the kind of new features I would like to see (or implement) in a VB6-successor,
I would always prefer to open it up to the "lower end" - so that it becomes more "C-like".

E.g. an easy way to pre-define Function-Declarations in a Const-Variable -
then passing this "typed Function-Pointer" along into Routines (as a nice, lowlevel way to support "delegates").

VB6 already is as a thin (COM-layer-supporting) abstraction on top of C/C++...
And I would like (in potential new features), when it would "open up a bit more to that lower level" -
(making it easier to access with less typing-efforts, supported by more compiler-checks).

Olaf

---

This I definitely agree with. Towards this I've always held the opinion that TwinBASIC could be spiced up with strong control over marshalling like we have in .Net where we can control how certain data types are marshalled to and from the Win32 API and other external binaries.

Another thing I think would be valuable is more access to COM internals specifically with regards to the generation of type libraries. Basically an easy mode MIDL type thing where you can opt for direct control over what is written type libraries when you compile something like an ActiveX DLL. I can't remember specifics today but way back in the day I remember being frustrated by the lack of control over COM from within the VB6 environment.

EDIT:

I just remembered one. I wanted the ability to specify my own interface IDs for COM interfaces in an ActiveX DLL. I don't remember why I wanted this but I do remember not being able to do this from VB6. This was very long ago mind you so my memory is a bit rusty.

Quote:

---

Originally Posted by Niya

Actually there is a solution. Micorsoft's solution to this was square brackets. In VB.Net if you wanted to use a reserved keyword as an identifier, you surround it in square braces like this:-

Code:

---

[Continue]

---

Something like this would probably work to solve this problem.

---

Not this does not work (yet) and I just opened issue #563 in the repo.

cheers,
</wqw>

Quote:

---

Originally Posted by wqweto

Not this does not work (yet) and I just opened issue #563 in the repo.

cheers,
</wqw>

---

Ah ok.

Hello,

Let me chime in.

I think the first real challenge no one has been able to achieve is very close 99% compatibility with vb6. If this can happen and so far it looks like twinBasic has a very good handle on this, it will allow current vb6 users to migrate, creating a long lasting sustainable framework. This part is super exciting and we all have waited a couple of decades for this. Imagine spending a month or so migrating our apps and maybe even getting them to work on other platforms (64bit/android/mac/linux). This will be so amazing for those of us who make a living selling our vb6 apps.

I think the second point is that maybe some of these modern features may be needed to attract new users to TwinBasic. This will be a secondary but very important factor in a long term sustainable vb6 replacement.

So keeping features to a 1:1 set with vb6 is probably the most important, but also adding modern features as long as they do not interfere can also help bring new users to the vb6/TwinBasic world.

I am so thankful and excited we may finally get what we need for the people who have large vb6 projects, it is an amazing time to be alive

my 2 cents... happy times!

Quote:

---

Originally Posted by axisdj

I think the second point is that maybe some of these modern features may be needed to attract new users to TwinBasic. This will be a secondary but very important factor in a long term sustainable vb6 replacement.

So keeping features to a 1:1 set with vb6 is probably the most important, but also adding modern features as long as they do not interfere can also help bring new users to the vb6/TwinBasic world.

---

This is exactly what I was saying. You get it.

I will add that to Olaf's point, a lot of these 'new' features are noise... and can be accomplished in a much more minimal approach.

BUT

Once programmers are sold the goods, it is hard to convince them otherwise, and if making a few well planned accommodations for the new generation so the platform will survive it is of minimal sacrifice.

I think the old way will still work, and we will have some new stuff, but without the bloat of platforms like .net

no point having 10 different ways to do the exact same thing.
too many choices and it will just be confusing and harder to learn.

better to pick the function that is easy to understand, (intuitive), and as close possible to the basic language.
if we are starting to add non-basic features, it will just mess with the language itself.

I think it should certainly start out as simple as can be while still being complete, but we always add many ways to do the same thing. After all, you could technically do without loop control structures, but instead we have several in every modern language. You don't NEED them, because they don't exist in ASM. They were added because it makes life a LOT easier for everybody. Things like tuples are just an extension of that point: You don't NEED them. In the case of tuples, however, they don't make life a LOT easier for everybody, they make life a bit easier for a few people.

Everybody will draw the line in different places as to which features are 'clearly essential' versus 'nice, but not necessary'. This tension has arisen over and over whenever anybody talks about a replacement for VB6. You can see it even in this thread over the last couple days. Everyone puts their oar in and pulls in whichever direction they think is best. It's to bad that it's not all in the same direction, but it's also understandable.

Quote:

---

Originally Posted by Shaggy Hiker

Everybody will draw the line in different places as to which features are 'clearly essential' versus 'nice, but not necessary'. This tension has arisen over and over whenever anybody talks about a replacement for VB6. You can see it even in this thread over the last couple days. Everyone puts their oar in and pulls in whichever direction they think is best. It's to bad that it's not all in the same direction, but it's also understandable.

---

This is a very strong argument for centralized decision making. I'd also add that whoever has the final authority should have an iron will. The biggest challenge I think Wanye would have in all this is saying no. He will have to be able to say no and stand by his decision regardless of any storm of criticism that may come from that. Otherwise you will end up with a huge mish-mash of ideas that don't really work well together because it's trying to be everything to everyone.

Quote:

---

Originally Posted by baka

no point having 10 different ways to do the exact same thing.
too many choices and it will just be confusing and harder to learn.

better to pick the function that is easy to understand, (intuitive), and as close possible to the basic language.
if we are starting to add non-basic features, it will just mess with the language itself.

---

Interesting point.

just thinking out loud here... maybe a guide to say something like:

looking for tuples? here is how to get the same functionality using variants.

or whatever else has a new buzz word, just have examples of how to accomplish the same with current vb6 methods.

I do think sticking to the vb6 minimalism has great value.

Quote:

---

Originally Posted by axisdj

I do think sticking to the vb6 minimalism has great value.

---

I think this should be put to the community to see how others feel about it and then Wayne can make a decision based on the feedback.

I think it already has been. All anybody needs to do is look around this forum for the threads on a new VB6 / VB6 replacement. There is always somebody asking for JUST VB6 compatibility, others asking for just that..plus a bit more, and still more asking for a raft of changes.

I'd say that Wayne should do what Wayne is doing.

Im in a gaming community forum, and theres many developers, and newcomers every month, but also many devs that fails all the time.
one thing that I noticed is that theres no lack of ambition, but not many can withstand the pressure.
theres devs that want to accommodate everyone, and devs that succumb to the masses when the masses complain, even if its just a couple it seems that devs are more focused on the people that complains more than the people that give praise.

I also notice a lot of devs that changes the story, the content to please the complainers until the game is almost unrecognizable from what it was from the beginning. the creative mind, the feel of achievement and fulfillment when you have your own goals is very important, when you change that to instead be dependent to others, it will soon be that you work for someone else and not for yourself. eventually, of what I notice, the games are quite soulless and not that interesting.

to let the dev do whatever he wishes, will not always be what everyone wants, but it will be a game that you can feel its made from a person that enjoyed doing it.

the same we can apply to TwinBasic. its important to have a balance, so its "good feedback" and not "pushing it" that will make the dev feel stressed out from it.

Quote:

---

Originally Posted by Niya

Like it or not, the programming world has changed since VB6's prime years. People are now programming with tuples, Async/Await. Functional style constructs are also becoming increasingly popular. This means, functions must be first class citizens to support higher order functions. Python is now being touted as the BASIC of the modern age, a language that is simple and easy to learn and it has all of these things. Simplicity is no longer an excuse to avoid these things. Modern programmers are not afraid of these things. If you want TwinBASIC to take off, then you must bring it up to the expected standards of the modern programmer.

---

Entirely agree. I've mentioned twinBASIC a few times at work (we're a C# shop), and the reply I invariably get is "For the love of $deity, WHY? VB6 died 20 years ago..." Of course I don't agree with that, but like it or not it's the perception of the vast majority of the programming world.

twinBASIC's primary goal is 100% backwards compatibility, and I don't see that ever changing. But the VB6 language has stagnated for 20 years whilst the world around it has moved on. You may not consider that any given new feature is particularly important (personally, I love tuples), but collectively they make the difference between a language that feels modern versus one that does not.

From what I've seen, Wayne is pretty focused on getting to feature-parity with VB6, as can be seen from the roadmap. Bugs get fixed extremely quickly, whereas ideas for language improvements (of which I've created a few...) typically get labelled as discussion items so that ideas can be thrashed out for implementation later on down the road.

The big-ticket item for VB6 parity is UI. Work is progressing on the cross-platform UI engine, which IIUC will form the starting point for a (Windows-only) VB6 / ActiveX compatible forms engine straight after. Things like the forms designer should be completely reusable.

If you don't want to make use of any new language features, there will be an optional legacy mode which will only allow VB6 constructs.

Personally, my hope for twinBASIC is that it becomes the go-to language for creating COM-based applications. 64-bit COM has been possible since forever(ish) with C / C++, but it's not exactly user-friendly. But for that to happen, it has to modernise.

Quote:

---

Originally Posted by mansellan

twinBASIC's primary goal is 100% backwards compatibility, and I don't see that ever changing. But the VB6 language has stagnated for 20 years whilst the world around it has moved on. You may not consider that any given new feature is particularly important (personally, I love tuples), but collectively they make the difference between a language that feels modern versus one that does not.

---

Yea man, this is what I'm saying. VB6 compatibility is important, yea but making TwinBASIC a modern language is equally important, I'd even go as far as saying it's more important in the long term. There is no point without either of these goals. I just get the sense that so many people would be perfectly happy if the language remains largely unchanged which I think is a horrible idea.

not sure I can agree completely. sure VB6 is old and not updated in 20 years.
if we are talking modern 3D/VR, VB6 is not exactly in the front line.

even so, you can create quite powerful windows program "right now" that can compete with any other languages.
just my game is in many ways that, since the performance is very good and comparing with similar games in my game community its like almost on another level.

why I say that? because I have a executable around 1MB that can do what the other engines requires +100MB to just start it up.
and performance wise, is eating less cpu and runs smoothly.

Im just thinking of how VB6 would be today if they improved it, adding a new compiler and continued optimizing everything.
today VB6 would be a tool that would be on par with C++, and thats what TwinBasic can be. but only if the purpose is to update VB6 of those 20 missing years.

that problem is not the language. Visual Basic 6 is already good, if not great.
the problem is low-level programming, that is what VB6 needs. like C, without it, it would be a garbage of a language.
if we can have access to low-level programming, and create DLL like C can do, it would mean, VB6 would now be on the top, not the bottom of the list.

I dont believe in many features, I believe in a language that opens the door to do stuff so we don't need C/C++ anymore.

I agree with the general sentiment expressed in this thread: tB should aim for as high as possible compatibility with vb6.

But i also agree with the "extensions" of others:
Cross-Platform
32 / 64-Bit target
...and whatever else people think as "nice-to-have"
As long as those are/stay exactly that: Extensions not interfering with the core/legacy language

What i'm opposed to are "features" going against the "spirit" of (Visual) Basic:
Examples:
1) change the notation for Arrays to square brackets (like in many other languages): Debug.Print MyArray[i] --> "because it's the way other languages handle this"!
in this example i can understand (somehow) the arguments: is "a(i)" an Access to an Array-Member or is it a function-call with i as an argument?
BUT, it's the way Arrays have been in Basic for decades. Leave it. Period!

2) atrocities like
"a += 1" instead of "a = a + 1"
DON'T!

3) And a lot more.......

What i wouldn't mind seeing in tB:
a) separate operators for boolean and bitwise logic (And yes, i'm aware that this is a can of worms because of the overloaded operators in vb6)
b) bitwise operators in the first place, like ShiftLeft and sisters
c) Do i really have to mention Inheritance?
d) Type-Helpers --> Powerful feature IMO. Extend a Type with a functionality of your own (It's not inheritance!)
e) the full set of native numeric DataTypes: signed/unsigned Numeric Types
This includes "dynamic" Types depending on the Target-Platform --> e.g. "LongPtr" being 32-Bit unsigned for 32-Bit-Target, 64-Bit unsigned for 64-Bit-Target
f) Write your own operators. With your own operators you're free to use the atrocities i mentioned in "2)" above
g) .... i'm sure i could think of other things, but let's leave it here....

Quote:

---

Originally Posted by Zvoni

2) atrocities like
"a += 1" instead of "a = a + 1"
DON'T!

---

I agree that this is an atrocity for VB.
One of the strengths of BASIC language is that it is easily understandable, clear and intuitive.
That vudú syntax is not BASICish.

One can say: then if you don't like it, don't use it.
But when someone wants to learn the language, by buying a book or going to a forum, she will encounter this vudú syntax and can be discouraged to stay on this language.
If someone is looking for a language hard to understand, then better to go to some other ones that are harder.
Most of the languages are for nerds and complicated-minded people, BASIC was one of the few exceptions (so far).
And I think that the success that VB had, had much to do with this (and with being RAD).

As can be seen by the replies here over the last few days, there is no universal agreement on the future direction of the BASIC (VB/tB/RB/whatever) language, and I doubt there ever will be. This is understandable, especially given the length of time that has passed since VB was last updated. It is clear that everyone has their own individual opinions and expectations that suits their own specific circumstances.

With twinBASIC the #1 priority is, and always has been, backwards compatibility. In terms of code-compatibility we're already getting very close to this goal. As of today, there's not much non-GUI VB code that won't compile in tB, and we've pretty much implemented the full language syntax and the full VBA standard library, barring a few obscure bits. Today we even added support for importing VBP projects (excluding GUI elements).

Along with the goal of full backwards compatibility, we are of course adding new features to the language, when it feels appropriate to do so. There is no getting around this; programming languages have moved on, and so to attract new talent requires bringing some of those new language features to twinBASIC. The truth is that there are not enough of us old-timers to make twinBASIC successful on our own... we need to attract new talent to use the language, otherwise the long-term success would be at risk.

Many will argue that you can add new features later, but I can assure you: it's just not that easy! The codebase for a compiler like twinBASIC is massive and complex; if you don't plan for features up-front at the start, the work to add them later is MUCH more involved (to the point where some new features might not even be possible without re-writing significant parts of the compiler). With tB, a huge amount of effort has gone into designing an efficient and extensible compiler that has the capability to offer any of the features of more modern languages... if and when necessary.

If you want to help steer the future direction of twinBASIC, I can only encourage you to please come over to our github issue tracker and join in with the discussions. If you've got ideas on what you'd like to see happen, please create a feature-request issue, describing your proposal. For example, baka mentions more low-level access... please come over and show us in more detail about what you want, and how that might look in practice. We're a friendly bunch, and I personally really want to hear from you!

I also noted that many of the comments/suggestions here over the last few days are for features that we've already implemented in twinBASIC (e.g. native Decimal/LongPtr/LongLong support, bitwise shifts, boolean logic etc), so I would first suggest checking out twinBASIC, as you may be pleasantly surprised.

Quote:

---

Originally Posted by WaynePhillipsEA

If you want to help steer the future direction of twinBASIC, I can only encourage you to please come over to our github issue tracker and join in with the discussions. If you've got ideas on what you'd like to see happen, please create a feature-request issue, describing your proposal. For example, baka mentions more low-level access... please come over and show us in more detail about what you want, and how that might look in practice. We're a friendly bunch, and I personally really want to hear from you!

---

Wayne, you might want to come up with some kind of a formal RFC protocol like most other languages use on github (go, rust, python) so that some of the new features in this thread can be formally specified, discussed, amended with new input and then dismissed as absurd :-))

https://github.com/rust-lang/rfcs

cheers,
</wqw>

Quote:

---

Originally Posted by Eduardo-

I agree that this is an atrocity for VB.
One of the strengths of BASIC language is that it is easily understandable, clear and intuitive.
That vudú syntax is not BASICish.

One can say: then if you don't like it, don't use it.
But when someone wants to learn the language, by buying a book or going to a forum, she will encounter this vudú syntax and can be discouraged to stay on this language.
If someone is looking for a language hard to understand, then better to go to some other ones that are harder.
Most of the languages are for nerds and complicated-minded people, BASIC was one of the few exceptions (so far).
And I think that the success that VB had, had much to do with this (and with being RAD).

---

Ed,

it's the reason why i mentioned writing your own operators.

with own operators available, people can write C in Basic to their hearts content.

But to be honest, in a chinese restaurant i order in english, so there is that..... :D

Quote:

---

Originally Posted by Zvoni

2) atrocities like
"a += 1" instead of "a = a + 1"
DON'T!

---

Unlike Tuples, this is one of the things I will fight to the death for. There is no way on God's green Earth I'd ever want to use a language where the only choice is a = a + 1.

I absolutely love being able to do this:-

Code:

---

MyVeryLongVariableOrPropName += 1

---

Instead of:-

Code:

---

MyVeryLongVariableOrPropName = MyVeryLongVariableOrPropName + 1

---

Like this is very primitive.

Thankfully though, Wayne has already implemented some of these more modern assignment operators.

But here's the thing. The people who prefer the classic BASIC way of performing increments, you can still do it. The standard binary operators still work as they always have. There is no need to fight over this specific thing. People like me can use the new operators and the people who don't like it can ignore it. Everyone wins here.

Quote:

---

Originally Posted by Niya

But here's the thing. The people who prefer the classic BASIC way of performing increments, you can still do it.

---

This is not the point, the point is not to pervert the language as I explained in post #579.
Some of us are not worried about ourselves, but interested in a future massive adoption of Basic language. So the "if you don't like it, don't use it" is a poor excuse.

Nevertheless, I would like to have a shorter way to do a = a + 1, but surely not that one.

I'll repeat myself, one of the strengths of the language is clarity, and += have no place. I'm sorry, as much as you love it.

Quote:

---

Originally Posted by Eduardo-

Some of us are not worried about ourselves, but interested in a future massive adoption of Basic language. So the "if you don't like it, don't use it" is a poor excuse.

---

Wayne already addressed this point of mass adoption:-

Quote:

---

Originally Posted by WaynePhillipsEA

Along with the goal of full backwards compatibility, we are of course adding new features to the language, when it feels appropriate to do so. There is no getting around this; programming languages have moved on, and so to attract new talent requires bringing some of those new language features to twinBASIC. The truth is that there are not enough of us old-timers to make twinBASIC successful on our own... we need to attract new talent to use the language, otherwise the long-term success would be at risk.

---

In other words, new features like these new operators are a must.

Quote:

---

Originally Posted by Eduardo-

Nevertheless, I would like to have a shorter way to do a = a + 1, but surely not that one.

I'll repeat myself, one of the strengths of the language is clarity, and += have no place. I'm sorry, as much as you love it.

---

This point is also counter to the desire to attract new talent. Other languages already do it like this and having something that feels familiar will go a long way towards attracting new people.

But I'm also curious. What shorthand would you prefer that you think is more BASIC like? The most BASIC way I could think of would be something like this:-

Code:

---

Increment(a)

---

Where the argument for Increment is passed by reference. That's about as BASIC as you can get with something like this.

I agree,

thats the reason we use Basic and not something else.

clarity is what makes me like Basic,
I dont want to have a forum with lots of threads and samples with all that crap.
and thats what we will have in a few years, when the language is so diverse that its not easy to understand anymore.

how can we "help" someone when we are using different syntax to do things? it will just be a mess. and to explain that to newbies?

and this is just 1 example, Im sure theres tons of stuff like this that will confuse.
but maybe Niya want this to happen? to create a confusing language, so he can start a new fight .NET vs TB in the future.
because a language is not just a language is also a community, forums, and people that help each other. and to do that we need stability and the use of the same syntax.

If people find simple operators like += confusing then programming is not for them. I understood what this operator did even when I was 15 years old.

Also, this entire argument is pointless because TwinBASIC already has these operators. The decision has already been made.

I'm with Niya on this one, I like +=, etc.. operators . Took almost no time for me to understand when using other languages. They're pretty much ubiquitous across other languages, so any programmer should already encountered and understood them, and new programmers to any language will wind up encountering them wherever they go. They're much faster to use, especially when you have long variable names. And they're in tB already, so let's move on.

Quote:

---

Originally Posted by Niya

If people find simple operators like += confusing then programming is not for them. I understood what this operator did even when I was 15 years old.

---

That's a non-argument if i ever saw one.

I know people who cannot read a single piece of sheet music (you know those weird glyphs on those 5 lines depicting "music"?), but they create music to die for, just by experimenting
("What happens if i press this key on the keyboard? Oh, that sounds really nice").
And that way they learn to "create" music while doing it. And they still can't read (or write) a single note on such a music sheet.

People have different strengths and skills.

and "a = a + 1" is even for a complete non-programmer more understandable than a "a += 1"

But to Wayne's answer: If it's already implemented, then be it!
I agree in that case: If you don't want to use, then don't use it!

I know when i did my transition to FreePascal/Lazarus, i came across this:
"Standard"-Way (as used from Basic): "a:=a+1;"
"Alternative"-Way: "Inc(a);" (The function has an optional second parameter you can pass the "step" to)

As always in life: Many roads lead to Rome.

What about those variants: a++, ++a
Always have to think hard when reading "for" loops in C with a lot of these additional counters

Quote:

---

Originally Posted by Arnoutdv

What about those variants: a++, ++a
Always have to think hard when reading "for" loops in C with a lot of these additional counters

---

I think this would be overdoing it. the += family is enough in my opinion. However, I'm not against having these additional postfix/prefix operators if that's something people want.

quite bad argument Niya.
its not about that, I have knowledge of many languages and they all have their own syntax.
my argument was to create a language that has a "basic" syntax and that will make life easier in the future when we share sources.

just += is quite silly to argue and Im fine with it, but when you start adding one, you add two and eventually we have many.
thats the key argument, if you start, when its time to say "its enough"?

if the counterargument is always: but but but this we can do in .net, c#, c, c++, pascal, java, ada, ruby, sql, php, assembler, machine code, hieroglyph, sand script....

are we really talking about TwinBasic or TwinMix?

Quote:

---

Originally Posted by Niya

I think this would be overdoing it. the += family is enough in my opinion. However, I'm not against having these additional postfix/prefix operators if that's something people want.

---

Agreed. That one always confused the hell out of me

Code:

---

a = 1
b = a++  'b is now 1, while a is 2
b = ++a  'b and a are now 3

---

Quote:

---

Originally Posted by baka

quite bad argument Niya.
its not about that, I have knowledge of many languages and they all have their own syntax.
my argument was to create a language that has a "basic" syntax and that will make life easier in the future when we share sources.

just += is quite silly to argue and Im fine with it, but when you start adding one, you add two and eventually we have many.
thats the key argument, if you start, when its time to say "its enough"?

if the counterargument is always: but but but this we can do in .net, c#, c, c++, pascal, java, ada, ruby, sql, php, assembler, machine code, hieroglyph, sand script....

are we really talking about TwinBasic or TwinMix?

---

Exactly.
I know it from the FPC/Lazarus-Forums.
On average, every 3 months comes a (pretty much) new forum-user, asking to add the "feature" of curly braces to declare a code-block (instead of using keywords begin/end).
Out of 100 "old" users on that forum, some 70 are going to put the popcorn into the microwave-oven, lean back, put their feet on the table, and watch the comedy-show.
30 of them are going to argue forward and backward about that topic.
Finally, one of the compiler-devs steps in and says:
"Not going to happen! Period! Deal with it! Don't like, it? Then use C/C++ or whatever other of those curly-braces-language"

Agree with baka.
Keep the Basic "Spirit" for the "official" way.

As i said: Implement writing your own operators, and all that stuff would be a non-argument, because everyone could then write his own shortcuts like he/she likes them

Code:

---

Public Operator +=(ByVal ALong As Long, Optional ByVal AStep As long = 1) As Long
  Return ALong + AStep
End Operator

---

Quote:

---

Originally Posted by Niya

these more modern assignment operators.

---

Just to be clear, there's nothing modern about += style assignment operators. They predate VB6 in C.

I've always preferred that operator over the long hand version, as well.

Quote:

---

Originally Posted by Zvoni

...
and "a = a + 1" is even for a complete non-programmer more understandable than a "a += 1"
...

---

Perhaps that is true, but I don't know. I can remember way back when we didn't have computers at home, and someone in a class looking at "a = a + 1" say that didn't make any sense at all, a could never equal a + 1.
It had to be explained that "=" didn't mean equal in this case, it was an assignment operator that was setting a to the value of a + 1.

BASIC made this clear from the start by using the syntax "Let a = a + 1" so you knew you were doing an assignment.
Eventually, someone decided that people learning to program could also learn that "a = a + 1" is doing an assignment so the "Let" keyword became optional in the later dialects.

Don't sell yourself short. I'm sure it is possible for almost anyone to learn that += is doing an assignment along with a sum.

Quote:

---

Originally Posted by Shaggy Hiker

Just to be clear, there's nothing modern about += style assignment operators. They predate VB6 in C.

I've always preferred that operator over the long hand version, as well.

---

Well I mean to say that modern programmers would expect operators like this because modern languages like Python and Rust have adopted them. But yes, you're quite correct.

Leaving all of them out of any modern dialect of BASIC is just foolish. At the very least, some of them should be included. You don't have to go all in and adopt every single one like postfix and prefix operators such as ++ and --. This is where the real confusion would begin. However, I'm not opposed to adding these operators too.

Quote:

---

Originally Posted by passel

Don't sell yourself short. I'm sure it is possible for almost anyone to learn that += is doing an assignment along with a sum.

---

Like I said before, I figured out what this operator did at 15 years old. At the time C was still way over my head due to the more advanced concepts involving pointers and memory allocations and whatnot but operators like += or ++ never confused me. I figured out what those did without any problems.

Quote:

---

Originally Posted by Niya

Wayne already addressed this point of mass adoption:-

In other words, new features like these new operators are a must.

You must be the king of misrepresentations or, if being well thought out, of misunderstandings.

This point is also counter to the desire to attract new talent. Other languages already do it like this and having something that feels familiar will go a long way towards attracting new people.

---

That's exactly my point: to attract new people.
Yes, the ones coming from other languages that support that awkward syntax will be OK with it. But how many will come from other languages?
VB attracted lot of people that wasn't even programmers. When VB appeared I don't know how many passed from other non-Basic languages to VB. The newcomers were in general new to programming or people that had already a background in Basic.

One of the strengths of Basic is that it is easily understandable, even if you are not a programmer. What would somebody guess it means if he reads a += 1?
Knocks his head on the wall.

Quote:

---

Originally Posted by Niya

But I'm also curious. What shorthand would you prefer that you think is more BASIC like? The most BASIC way I could think of would be something like this:-

Code:

---

Increment(a)

---

Where the argument for Increment is passed by reference. That's about as BASIC as you can get with something like this.

---

You could do that already in VB6.

It is difficult to find a short and at the same time clear syntax for that, specially if you want to compete with only one character syntax (+).

I could propose:

Code:

---

Inc a ' adds 1
Inc a 2 ' adds 2

---

It looks as ASM, but at least it is more straightforward.

My point is not to add syntax until you are sure it is the best choice.
Reasons like "because it will take only half an hour" or "because it will be fun to do" should be ruled out. They are not reasons to evolve a language.

I think there should be some science about how to design a programming language, it cannot be based on hunchs, or because I received a few likes from current followers.

At least, I would like to see a broader discussion about the pros and cons of each alternative, something more serious.

About +=, perhaps it is the best possible option, but let's be more sure about that.

I'll stop worrying, I can't do anything anyway.
May God help the developers to make the best choices.