TwinBasic

Also, I want to point out a huge contraction in the arguments of the people who are against the addition of these short-hand operators. A lot of you also argue for TwinBASIC to be more low level. You cannot argue for syntax to be simple for beginners while at the same time arguing for more low level control. You guys post a lot of code with VarPtr this or CopyMemory that. This kind of code is not beginner friendly.

I'd also point out that operators are integral to lower level programming. Let me raise an example based on a recent post I made about HRESULTs in the VB6 section. If you wanted to extract the facility code from an HRESULT, you must perform two low level operations. First you must mask out the irrelevant bits around the facility code, then you must shift all 32 bits to the right by 16.

Now lets say in an alternate reality you guys get your wish and Wayne didn't include any new operators. How would we perform this low level operation? We'd have to do it like this:-

Code:

---

facility = (errorValue And &H7FF0000) / (2 ^ 16)

---

Do you see a problem here? That code is using division to perform bit shifts. I don't know how many of you know assembly but an integer division operation at the machine code level is quite involved. It is also very slow. However, modern processors also have bit shift instructions which are among the fastest operations a processor can perform. If a higher level language does not include bit shift operators, then you're being denied access to a very powerful tool that could be used for significant performance gains in lower level programming. That same code looks like this in VB.Net which has bit shift operators:-

Code:

---

facility = (errorValue And &H7FF0000) >> 16

---

The above would also look the same in just about every modern language. Even Python has them. This is how it would look in Python:-

Code:

---

hresult = -2146824582

facilityCode= (hresult & 0x7FF0000) >> 16

print(facilityCode)

---

Which outputs:-

Code:

---

10

---

Which is correct.

Python is the furthest thing from a low level language possible. It's entirely interpreted and very sluggish in comparison to languages that produce native code and even they dared to include operators like this.

You guys want to attract new talent to TwinBASIC. They are going to be looking at things like this when weighing their decisions about whether to adopt TwinBASIC or not. No one is going to want to perform a bit shift in 2021 using division.

Quote:

---

Originally Posted by Eduardo-

I could propose:

Code:

---

Inc a ' adds 1
Inc a 2 ' adds 2

---

---

BTW, my proposed syntax can be done too in VB6 if we wanted, or almost:

Code:

---

Private Sub Form_Load()
    Dim a As Long
   
    Inc a
    Debug.Print a
   
    Inc a, 2
    Debug.Print a
End Sub

Private Sub Inc(ByRef Var As Variant, Optional ByVal HowMuch As Variant)
    If IsMissing(HowMuch) Then
        Var = Var + 1
    Else
        Var = Var + HowMuch
    End If
End Sub

---

Quote:

---

Originally Posted by Niya

You cannot argue for syntax to be simple for beginners while at the same time arguing for more low level control.

---

Please don't confuse things.
Simplicity (and clarity) of syntax has nothing to do with level of abstraction.

Quote:

---

Originally Posted by Eduardo-

B 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.

---

Let me pounce on this for a moment. I typed in Google, why is Python so popular. And this came up as the first link.

Pay particular attention to what the author said here:-

Quote:

---

First and foremost reason why Python is much popular because it is highly productive as compared to other programming languages like C++ and Java. It is much more concise and expressive language and requires less time, effort, and lines of code to perform the same operations.

---

And this:-

Quote:

---

Python is also very famous for its simple programming syntax, code readability and English-like commands that make coding in Python lot easier and efficient.

---

This is what BASIC used to be. This is how people would describe BASIC 20 years ago. Python has now taken it's place as the go-to "easy to learn and super productive" language and it has these shorthand operators. So it seems that this point about these operators being confusing to beginners and people looking for an easy language has no footing in reality. It didn't stop Python from becoming the most popular language in the world.

A couple of other options to consider:

Code:

---

Private Sub Form_Load()
    Dim a As Long
   
    AddTo a
    Debug.Print a
   
    AddTo a, 2
    Debug.Print a
End Sub

Private Sub AddTo(ByRef Var As Variant, Optional ByVal HowMuch As Variant)
    If IsMissing(HowMuch) Then
        Var = Var + 1
    Else
        Var = Var + HowMuch
    End If
End Sub

---

Code:

---

Private Sub Form_Load()
    Dim a As Long
   
    Add a
    Debug.Print a
   
    Add a, 2
    Debug.Print a
End Sub

Private Sub Add(ByRef Var As Variant, Optional ByVal HowMuch As Variant)
    If IsMissing(HowMuch) Then
        Var = Var + 1
    Else
        Var = Var + HowMuch
    End If
End Sub

---

But the addition of any new keyword will break backward compatibility :rolleyes:

Quote:

---

Originally Posted by Eduardo-

Please don't confuse things.
Simplicity (and clarity) of syntax has nothing to do with level of abstraction.

---

My point is these things are mutually exclusive. You can have either one but you cannot have both. Low level programmers are going to want more tools like bit shift operators which would directly conflict with the wants of the proponents of extreme simplicity.

Quote:

---

Originally Posted by Niya

Let me pounce on this for a moment. I typed in Google, why is Python so popular. And this came up as the first link.

Pay particular attention to what the author said here:-


And this:-


This is what BASIC used to be. This is how people would describe BASIC 20 years ago. Python has now taken it's place as the go-to "easy to learn and super productive" language and it has these shorthand operators. So it seems that this point about these operators being confusing to beginners and people looking for an easy language has no footing in reality. It didn't stop Python from becoming the most popular language in the world.

---

If you are NOT comparing a Python with the operator with another Python that is the same but lacking the operator, or with another syntax instead, it proves nothing.

I think you are easily deceived by fallacious reasoning.

Quote:

---

Originally Posted by Eduardo-

If you are NOT comparing a Python with the operator with another Python that is the same but lacking the operator, or with another syntax instead, it proves nothing.

I think you are easily deceived by fallacious reasoning.

---

No. The entire argument around this is about making the language easier for beginners. What I am trying to point out is that when you take another language that fills the same niche that BASIC does, this niche being a language for beginners, you can clearly see that it didn't hurt that language. People still adopted it. So by that reasoning it is safe to include it in TwinBASIC. If it wasn't discouraging to beginners looking at Python then it wouldn't be for beginners adopting TwinBASIC.

Quote:

---

Originally Posted by Niya

My point is these things are mutually exclusive. You can have either one but you cannot have both. Low level programmers are going to want more tools like bit shift operators which would directly conflict with the wants of the proponents of extreme simplicity.

---

Again, you keep confusing something with something else that has nothing to do.

Let's put an example: now you can do subclassing in VB6. Intermediate level programmers, and not talking about beginners, won't understand anything if they look a code for subclassing.
Not to mention if they look code with ASM thunks from wqweto, LaVolpe or The Trick.

Offering more low level access, instead of making thinks harder to intermediate level programmers, it would make it easier.

Some subclass that don't crash the IDE, standardized, easier.
That's an example of how more "low level" things can make the language more understandable and easier.

Quote:

---

Originally Posted by Niya

No. The entire argument around this is about making the language easier for beginners. What I am trying to point out is that when you take another language that fills the same niche that BASIC does, this niche being a language for beginners, you can clearly see that it didn't hurt that language. People still adopted it. So by that reasoning it is safe to include it in TwinBASIC. If it wasn't discouraging to beginners looking at Python then it wouldn't be for beginners adopting TwinBASIC.

---

You obviously don't have a clue of how the scientific method works.

Quote:

---

People still adopted it.

---

And what was the alternative at that time?

If you make something new, you need to offer something better.

If fact, you have to try to make it the best as you can. Not that "that seems to be good enough, at lest competing with that".

I get the impression i was not precise enough:
i‘m not opposed to NEW operators (like ShiftLeft and sisters)
I‘m opposed to operators that are just syntactic sugar, when there already is a perfectly valid way, as in a=a+1

it‘s why i said to offer the possibility to write your own operators. That way those who want a+=1 or a++ can write it, and use it to their hearts content, since i doubt there is any notable difference in speed (compared to Niya‘s sample with division for shifting bits)

Quote:

---

Originally Posted by Eduardo-

BTW, my proposed syntax can be done too in VB6 if we wanted, or almost:

Code:

---

Private Sub Form_Load()
    Dim a As Long
   
    Inc a
    Debug.Print a
   
    Inc a, 2
    Debug.Print a
End Sub

Private Sub Inc(ByRef Var As Variant, Optional ByVal HowMuch As Variant)
    If IsMissing(HowMuch) Then
        Var = Var + 1
    Else
        Var = Var + HowMuch
    End If
End Sub

---

---

It's not the same thing. A function call carries significant overhead compared to incrementing a variable. Incrementing a variable looks like this at the native code level:-

Code:

---

Inc [ebp - 4]

---

A function call would look something like this at the call site:-

Code:

---

Push ebp - 4
Call [Inc]

---

Then this would be the actual function, assuming the standard calling convention:-

Code:

---

push ebp
mov ebp, esp

mov ebx, [ebp+8] ; Move pointer into EBX
inc [ebx] ;Increment value at the address pointed to by EBX

mov esp, ebp
pop ebp
ret 4 ;Assuming a 32 bit integer parameter

---

That's 6 whole extra instructions just to increment a value at a memory address.

This is not to say that your idea is bad. For this to be viable performance-wise it would have to be implemented in the compiler itself as an intrinsic function. So whenever it's called the compiler simply generate an inc instruction instead of an entire function call.

EDIT:

Also I am assuming the simplest possible implementation of an increment function like:-

Code:

---

Public Sub Inc(ByRef b As Long)
    b = b + 1
End Sub

---

If we include all that stuff with Variants and If statements, the overhead would be significantly greater.

Quote:

---

Originally Posted by Niya

It's not the same thing. A function call carries significant overhead compared to incrementing a variable. Incrementing a variable looks like this at the native code level:-

Code:

---

Inc [ebp - 4]

---

A function call would look something like this at the call site:-

Code:

---

Push [ebp - 4]
Call [Inc]

---

Then this would be the actual function, assuming the standard calling convention:-

Code:

---

push ebp
mov ebp, esp

mov eax, [ebp+8]
inc eax

mov esp, ebp
pop ebp
ret 4 ;Assuming a 32 bit integer parameter

---

That's 8 whole extra instructions just to increment a value at a memory address.

This is not to say that your idea is bad. For this to be viable performance-wise it would have to be implemented in the compiler itself as an intrinsic function. So whenever it's called the compiler simply generate an inc instruction instead of an entire function call.

---

I'm quite sure that it that was implemented natively it would not take any extra instruction.
Always missing the mark... and they go like 1000 times.

Quote:

---

This is not to say that your idea is bad. For this to be viable performance-wise it would have to be implemented in the compiler itself as an intrinsic function. So whenever it's called the compiler simply generate an inc instruction instead of an entire function call.

---

That was what we were talking about, didn't we?

Quote:

---

Originally Posted by Eduardo-

That was what we were talking about, didn't we?

---

You said this:-

Quote:

---

BTW, my proposed syntax can be done too in VB6 if we wanted, or almost:

---

Which I interpreted to mean that it wasn't needed because you could just write a function to do it. If you actually meant it should be an intrinsic, then you have my apologies for misunderstanding.

I also updated that post. I got the assembly slightly wrong because I forgot I was dealing with a ByRef parameter. It was reduced by two instructions but it's still 6 extra instructions.

I will try to explain why the reasoning "since people adopted Python, and it has the + operator, then it must be good" is a fallacious argument.
Because things that can seem obvious to someone can be difficult to others.

"people adopted Python", Ok, that's a fact (or a premise).
"Python has the + operator", that's also true.

The + operator is a side feature, some small feature between many other features.
You can not know if the + operator features played a role in favor or against the adoption. You have no way to evaluate the feature separately.

You can say (and you did) that many people adopted the language, even if it had that feature. Yes, that's a fact, but you cannot know how many (if more or less) would have adopted the language if it lacked of the feature, or had some other way to do that.

You can argue that it seems that it wasn't an stopper, because people adopted the language anyway.
OK, and with what did Python compete at the time?
Did it compete with VB6? Of course not, VB6 was discontinued, and didn't work on Linux servers.

A new language need to be better to be adopted, not the same. Now you need to compete with Python (and many others).
So, the real question is, that feature helps in the adoption, or plays against it?

Quote:

---

Originally Posted by Niya

You said this:-


Which I interpreted to mean that it wasn't needed because you could just write a function to do it. If you actually meant it should be an intrinsic, then you have my apologies for misunderstanding.

---

OK, sorry too, may be I was not clear.

Quote:

---

Originally Posted by Niya

I also updated that post. I got the assembly slightly wrong because I forgot I was dealing with a ByRef parameter. It was reduced by two instructions but it's still 6 extra instructions.

---

I think it is nevertheless interesting that it can be done in VB6, even if it is slower. As an alternative when you don't need speed and want to write less.
But it is a different discussion.
Not sure whether it worth to post it in the Codebank.
(I'll keep it in mind in case I have to do a lot of additions to long named variables and don't need super speed).

Quote:

---

Originally Posted by Eduardo-

You can say (and you did) that many people adopted the language, even if it had that feature. Yes, that's a fact, but you cannot know how many (if more or less) would have adopted the language if it lacked of the feature, or had some other way to do that.

---

This is quite correct. There really is not objective answer to this question as of now. A simple thing like a poll on StackOverflow, Reddit or Quora could probably put this question to bed easily though.

Quote:

---

Originally Posted by Eduardo-

So, the real question is, that feature helps in the adoption, or plays against it?

---

You're correct here too. I think it does help and apparently Wayne did as well. But you're right. It is entirely possible that those of us in support of this could be wrong. In the absence of a poll or some kind of census, we can only rely on our intuition and my intuition tells me that this is a must. It would be extremely unproductive to put every single feature to a vote. Sometimes, it's just better to go with your gut for the sake of expediency.

Quote:

---

Originally Posted by Eduardo-

Not sure whether it worth to post it in the Codebank.
(I'll keep it in mind in case I have to do a lot of additions to long named variables and don't need super speed).

---

I think it's too simple to warrant a Codebank entry. I think most VB6 programmers are capable of coming up with a function like that on their own.

Quote:

---

Originally Posted by Niya

A simple thing like a poll on StackOverflow, Reddit or Quora could probably put this question to bed easily though.

---

I don't think so. It doesn't work like that.

You need the ones voting being the same (or close) to the ones making the decision.
So you'll have to go to schools, people making their first steps in programming, and present to the student different alternatives.

It is easy to be biased if you don't apply the right methodology...

Quote:

---

Originally Posted by Niya

You're correct here too. I think it does help and apparently Wayne did as well. But you're right. It is entirely possible that those of us in support of this could be wrong. In the absence of a poll or some kind of census, we can only rely on our intuition and my intuition tells me that this is a must. It would be extremely unproductive to put every single feature to a vote. Sometimes, it's just better to go with your gut for the sake of expediency.

---

I don't think that the original VB team at MS made these kind of decisions based on intuitions. They must have studied and discussed pros and cons of each important thing a bit better and more seriously.
They had also feedback from some connected people around, programmers like (I think) Karl Peterson, Randy Birch and others.

Quote:

---

Originally Posted by Niya

I think it's too simple to warrant a Codebank entry. I think most VB6 programmers are capable of coming up with a function like that on their own.

---

The code is too simple, but you don't usually think about that.
The point there wouldn't be the code, but the idea.
I'm not planning to post it anyway.

Quote:

---

Originally Posted by Eduardo-

BTW, my proposed syntax can be done too in VB6 if we wanted, or almost:

Code:

---

Private Sub Form_Load()
    Dim a As Long
   
    Inc a
    Debug.Print a
   
    Inc a, 2
    Debug.Print a
End Sub

Private Sub Inc(ByRef Var As Variant, Optional ByVal HowMuch As Variant)
    If IsMissing(HowMuch) Then
        Var = Var + 1
    Else
        Var = Var + HowMuch
    End If
End Sub

---

---

Woof. Don't be doing THAT.

A = A + 1

Is a single integer addition, one of the simplest and fastest things that CPUs can do. You created an alternative that has a conditional in addition to the addition. You'd be much better off just doing the math than adding in a conditional.

Quote:

---

Originally Posted by Shaggy Hiker

Woof. Don't be doing THAT.

A = A + 1

Is a single integer addition, one of the simplest and fastest things that CPUs can do. You created an alternative that has a conditional in addition to the addition. You'd be much better off just doing the math than adding in a conditional.

---

I think I was clear that the purpose was not speed but handiness with long named variables.
Not every code needs to run at the speed of light.

Quote:

---

Originally Posted by Eduardo-

You need the ones voting being the same (or close) to the ones making the decision.
So you'll have to go to schools, people making their first steps in programming, and present to the student different alternatives.

---

That's a good idea. I'd like to see more objective comparison attempts of that nature. I've read a couple papers that tried to do something like that around unit testing. Even in the papers, they noted that their methodology left a lot to be desired, but for the test you are proposing, it would really work. When they were comparing Test Driven Development methodology vs other, they had a seriously hard time (or totally failed) to come up with two equivalent groups of students. When it comes to saying "which is easier?" you can readily find totally equivalent groups of students, since you really want to be asking beginners.

Quote:

---

Originally Posted by Eduardo-

I think I was clear that the purpose was not speed but handiness with long named variables.
Not every code needs to run at the speed of light.

---

Yeah, I should have read the other responses. However, I've never understood the point about long variables names. If you are working in an environment without intellisense, then it would make sense....but none of us are, so it seems unlikely that ANY of us care about long variable names. You type a couple characters and hit tab.

As Wayne Phillips pointed out earlier, twinBASIC v0.13.36 now allows import from VB6 projects.

Only supported documents are imported (i.e. modules and classes, not forms etc). Once VB6 forms are supported in tB (expected in early February), they will also be imported.
A log of the import process is displayed.

The new import option is in the tB activity panel.

Quote:

---

Originally Posted by Shaggy Hiker

That's a good idea. I'd like to see more objective comparison attempts of that nature. I've read a couple papers that tried to do something like that around unit testing. Even in the papers, they noted that their methodology left a lot to be desired, but for the test you are proposing, it would really work. When they were comparing Test Driven Development methodology vs other, they had a seriously hard time (or totally failed) to come up with two equivalent groups of students. When it comes to saying "which is easier?" you can readily find totally equivalent groups of students, since you really want to be asking beginners.

---

Yeap, but not easy for small companies or individuals.

I found that this code works in VB6:

Code:

---

Private Sub Form_Load()
    Dim a As Long
   
    · a
    Debug.Print a
   
    · a, 2
    Debug.Print a
End Sub

Private Sub ·(ByRef Var As Variant, Optional ByVal HowMuch As Variant)
    If IsMissing(HowMuch) Then
        Var = Var + 1
    Else
        Var = Var + HowMuch
    End If
End Sub

---

I was thinking, for the new syntax, what about:

Code:

---

+ a  ' adds 1
+ a 2 ' adds 2
' or
+ a, 2

---

What do you think?
I think that's much better than:

Code:

---

a += 1

---

Quote:

---

Originally Posted by Shaggy Hiker

Yeah, I should have read the other responses. However, I've never understood the point about long variables names. If you are working in an environment without intellisense, then it would make sense....but none of us are, so it seems unlikely that ANY of us care about long variable names.

---

Long variable names is for being explicit and descriptive what they are (or have). In procedures that have many variables it makes the code clearer and easier to understand when you come back later, or for someone else.

Quote:

---

Originally Posted by Shaggy Hiker

You type a couple characters and hit tab.

---

In VB6 it is Control+Space.
Anyway you can also copy/paste too.

But your current point contradicts the other point that "VB lacks a short way to increment variables". May be you are not one of the proponents of a new syntax (I don't remember).

Quote:

---

Originally Posted by Eduardo-

I was thinking, for the new syntax, what about:

Code:

---

+ a  ' adds 1
+ a 2 ' adds 2
' or
+ a, 2

---

What do you think?

---

I find that syntax really unpleasant (it would probably also be a nightmare to parse in all the settings expressions can exist). Why reinvent the wheel? += (and all its many kin) are ubiquitous, not only in C-like languages, but also FreeBASIC, VB.Net, Java, JavaScript, Python, PHP, Ruby... In fact it would probably be quicker to list the languages that _don't_ implement it!

A developer coming from any of these languages would lament their absence, so why inflict it? These are already implemented in twinBASIC.

Quote:

---

Originally Posted by Eduardo-

So you'll have to go to schools, people making their first steps in programming, and present to the student different alternatives.

It is easy to be biased if you don't apply the right methodology...

---

You actually gave me an idea. I don't have to resources to conduct such a census in schools but in 2021 I think it's pretty easy for the average person to conduct something similar online. I'm flirting with the idea of posing this question to a community of non-programmers to see what they say.

Quote:

---

Originally Posted by Eduardo-

I don't think that the original VB team at MS made these kind of decisions based on intuitions. They must have studied and discussed pros and cons of each important thing a bit better and more seriously.
They had also feedback from some connected people around, programmers like (I think) Karl Peterson, Randy Birch and others.

---

They decided to not include them in QuickBasic and maintained that all the way up to VB6. Yet they decided to include them in VB.Net. How would you explain this change of policy? Be mindful, that if we are assuming they did put it to vote/discussion when creating VB6, you also have to assume the same for VB.Net.

Quote:

---

Originally Posted by mansellan

I find that syntax really unpleasant (it would probably also be a nightmare to parse in all the settings expressions can exist). Why reinvent the wheel? += (and all its many kin) are ubiquitous, not only in C-like languages, but also FreeBASIC, VB.Net, Java, JavaScript, Python, PHP, Ruby... In fact it would probably be quicker to list the languages that _don't_ implement it!

A developer coming from any of these languages would lament their absence, so why inflict it? These are already implemented in twinBASIC.

---

Ahh, because many are using it then it is good?

Attachment 183304

Quote:

---

Originally Posted by Eduardo-

Ahh, because many are using it then it is good?

---

Didn't say that. I just said that it's ubiquitous. And thus will likely be expected by a traveler from another language. That's a benefit.

What's the cost? You just don't like the way it looks?

Quote:

---

Originally Posted by Niya

You actually gave me an idea. I don't have to resources to conduct such a census in schools but in 2021 I think it's pretty easy for the average person to conduct something similar online. I'm flirting with the idea of posing this question to a community of non-programmers to see what they say.

---

OK, but please do not design the questions in a way to induce the answer that you want.

Quote:

---

Originally Posted by Niya

They decided to not include them in QuickBasic and maintained that all the way up to VB6. Yet they decided to include them in VB.Net. How would you explain this change of policy? Be mindful, that if we are assuming they did put it to vote/discussion when creating VB6, you also have to assume the same for VB.Net.

---

The .Net team has nothing to do with the original VB team.

And it is clear that what they wanted was exactly the opposite: to make programming something for an elite. And they got it.

If it's because it's not human-readable, well... no programming language is entirely intuitive. For modify-and-assign, understanding would take a quick Google search, hitting results from pretty much any language...

https://www.google.com/search?q=what...us+equals+mean

Quote:

---

Originally Posted by mansellan

Didn't say that. I just said that it's ubiquitous. And thus will likely be expected by a traveler from another language. That's a benefit.

What's the cost? You just don't like the way it looks?

---

In previous posts I expressed that most of the potential newcomers won't probably come from other languages, but from people new to programming.

If else, then let's go everybody to C# or Python, they must have what we want since these are the languages that people are now using.

Quote:

---

Originally Posted by mansellan

If it's because it's not human-readable, well... no programming language is entirely intuitive. For modify-and-assign, understanding would take a quick Google search, hitting results from pretty much any language...

https://www.google.com/search?q=what...us+equals+mean

---

This is one of the main strengths of Basic, undermining that, is undermining the advantages that it has over other languages.
Yes, it is not totally human readable, but that's mainly for shortness, a = Int(a) is shorter that a = ConvertToInteger(a), but still kind of human friendly.