Well there you have it guys, from the main developer himself. Instead of biting my head off for my opinions, go over there and make big noise. Here is this link.
Printable View
Well there you have it guys, from the main developer himself. Instead of biting my head off for my opinions, go over there and make big noise. Here is this link.
The following makes interesting reading
https://codedocs.org/what-is/b-programming-language
extract
Quote:
Circa 1969, Ken Thompson[2] and later Dennis Ritchie[3] developed B basing it mainly on the BCPL language Thompson used in the Multics project. B was essentially the BCPL system stripped of any component Thompson felt he could do without in order to make it fit within the memory capacity of the minicomputers of the time. The BCPL to B transition also included changes made to suit Thompson's preferences (mostly along the lines of reducing the number of non-whitespace characters in a typical program).[2] Much of the typical ALGOL-like syntax of BCPL was rather heavily changed in this process. The assignment operator := changed to = and the equality operator = was replaced by ==.
Thompson added "two-address assignment operators" using x =+ y syntax to add y to x (in C the operator is written +=). This syntax came from Douglas McIlroy's implementation of TMG, in which B's compiler was first implemented (and it came to TMG from ALGOL 68's x +:= y syntax).[2][4] Thompson went further by inventing the increment and decrement operators (++ and --). Their prefix or postfix position determines whether the value is taken before or after alteration of the operand. This innovation was not in the earliest versions of B. According to Dennis Ritchie, people often assumed that they were created for the auto-increment and auto-decrement address modes of the DEC PDP-11, but this is historically impossible as the machine didn't exist when B was first developed.[2]
yeah, and since nowadays we don't have memory limits, we don't need to make compact programming.
I can understand that, if u have 4k memory, u can't do that much before its all filled up, u need to program in a way that will take as little memory possible.
Compact language syntax and runtime memory usage aren't really related. Yes in early versions of c ++ and +1 mapped to different Cpu instructions but that hasn't been the case for decades. Any decent compiler would produce the same result regardless of language subtleties.Quote:
Originally Posted by baka
X += 1, x++, and x = x + 1 would all be treated the same in a decent compiler. The syntax is for the benefit of the programmer.
I am a VB6er, almost dyed-in-the-wool. I have programmed in javascript and I am quite used to the C-style operators there. When I am programming in .js I tend to use the proper methods or the old BASIC style and it does not worry me one jot as to whether some other programmer, versed in B or C-style syntax, thinks that my code is rubbish. I easily intertwine both styles and as long as they both work in .js (and they mostly do) then I have been content.
That should work the other way around for me too. I will continue to use the BASIC operators even if others are available. With regard to >> and RSHIT(sic) - both would suit me fine but I doubt if I'd ever have the opportunity to use either.
PlausiblyDamp that was my point.
that, its not important anymore, for decades,
but the syntax is still here, that part didnt evolve when computers got more memory.
so my point is that using those abbreviations is not a "this is how you code", but "this is how they created the syntax in the first place to save space and you are still using it for compatibility"
and thats also my argument why Basic "don't" need to implement such things, we can use LShift without worries.
I ask myself. Do I want Basic to Evolve? To be a language that is onpar with c++? hell yeah I want that. but I also want the language itself, the syntax to evolve and show we can do it our way.
its not that "its not basic'ish" to use pointer or shift this and that, I want it to be "it is basic" to use pointers and shift that and the other, but we use our own words for it.
You don't ever want to be like c++. BY all means have the same high level functionality as c++ but don't evolve the way c evolved to c++, to get not be trapped by being afraid to move on from syntax that is a hindrance, even if it means breaking changes. If you'd like to see a path along which you might evolve VBA you could take some hints from the Nim programming language which has kindly done away with all those annoying 'end xxxx' as well as refraining from using the dreaded '{ code block} ' as well as allowing the very neat syntax sugar of allowing function( a,b,c) to be written as a.function(b,c) (and other variants)
In case any one is interested in migrating an existing VB6 project to tB, I've posted my experiences here: https://www.vbforums.com/showthread....=1#post5550066. Hopefully it will help other tB newbies avoid some of the little bumps in the road I hit, but overall it was a surprisingly pleasant migration.
Wayne did a very good job with TwinBASIC. It is as true a successor to VB6 as I've ever seen! Most non-UI VB6 code just works in TwinBASIC with little to no changes. Even entire libraries like Olaf's RichClient works.Quote:
Originally Posted by jpbro
That would be GREAT! There is no good reason why there is just ONE thread on TwinBasic. Having more threads, especially with that prefix, would show the interest that exists in the project. If there are enough threads like that, it might become it's own sub-forum.Quote:
Originally Posted by mansellan
It is probably possible to have that prefix added to the set of prefixes. There are prefixes that can be used for Visual Studio, and there's the [RESOLVED] prefix, so it's a feature. That's not something that I can do, though, you'd have to ask Steve Jones.
I culled this thread, and perhaps a bit too excessively. I realize that people have strong opinions about this. I realize that people have strong opinions about other members of the forum. I have strong opinions, as well. However, this is a good thread. It will stay a good thread as long as people argue about the language and not about one another.
well I will follow the mods decision...
anyway in Bit Manipulation #396 https://github.com/WaynePhillipsEA/t...iscussions/396
theres some discussion about c-operators. and specifically Left/Right Shift (for now)
- some enjoy the c-operators
- some think we should have a basic-variation
- some think if we add a basic-variation it will pollute
well, I don't think that way, but I posted that I was even willingly accept a compromise, if they don't want to have specific functions for basic,
the suggestion was a "container", example:
cOperator.LeftShift A,2
cOperator.RightShift A,2
cOperator.LeftShiftAssign A,2
that can be used instead of all the c-operators.
and that can be filled with all kinds of operation and math stuff.
at least its not that much "polluted", instead just 1 container that has multiple choices.
even so, I would still like
LShift A,2
and maybe even
LShift A,2, True (for assignment) or A = LShift(A,2)
Yes he has done a great job, I'm very impressed so far. Certainly the most promising thing I've seen with regard to a future for existing VB6 code.Quote:
Originally Posted by Niya
This is assembly language syntax. The SHL and SHR assembly instructions use this exact syntax. In other words, we are just replacing C syntax with assembly syntax. This is not BASIC.Quote:
Originally Posted by baka
This implies a function call. A bit shift operation at the machine code level is a single instruction but a function call is made up of several instructions. In fact let me show what it will look like at the machine code level. Assuming the standard calling convention and all data types and parameters are 32 bit integers, you will get this at the call site:-Quote:
Originally Posted by baka
This would be the LShift function:-Code:push dword 2 ;; Push the value 2 onto the stack
push dword [ebp - 16] ;; Push A onto the stack
call [LShift] ;; Call the left shift function
The above may not be 100% accurate but it's going to look something like that. That's 11 instructions for something that can be performed in 1 instruction.Code:push ebp
mov ebp, esp
mov eax, [ebp + 8] ;; Copy first parameter into EAX register
mov ecx, [ebp + 12] ;; Copy the second parameter into the ECX register
shl eax, CL ;; Perform the left shift on EAX
mov esp, ebp
pop ebp
ret 8 ;; Clear the stack and return. Return value is in EAX
Now you may be tempted to suggest that LShift be implemented as an intrinsic function however, this would also undermine the argument of keeping it BASIC. Intrinsic functions are a C thing. There are no true intrinsic functions in VB6 that I am aware of. Introducing intrinsic functions into TwinBASIC would make it more like C.
This is even worse because not only are we involving function call overhead, as shown above but a whole lot of extra stuff for handling method calls on objects(VTABLES, this pointers and whatnot). We could easily be looking at 20+ instructions just to perform a simple bit shift here.Quote:
Originally Posted by baka
However, let me throw you a bone. If you insist on not having >> or <<.....just replace those symbols with something wordy like what we have with NOT, AND, OR and MOD. That is the only way that makes sense and it is consistent with what is expected of BASIC.
not really. u are not thinking carefully here.
a "compiler" can translate it into anything.
its not that what you code will be exactly that in native code.
so, if I write:
MakeShiftLeftTheBasicWay A, 2, False
the compiler can "translate that" to
A << 2
and go from there.
You're probably right that a compiler can do the right thing. Still, I think what Wayne suggested with the ability to toggle the feature on and off would make most people happiest. That would go against the wishes of those who feel it will pollute, but you can't have it all ways, and this way would be as many ways as possible.
After all, there are things in Basic that have been dragging on, and need to keep dragging on, despite most everybody realizing they aren't a good idea. Some of those ought to goto, but they won't.
Quote:
Originally Posted by baka
These two things are not the same. One is a function call syntax and the other is a binary operator. How would that clumsy syntax work when you have to do something like this:-Quote:
Originally Posted by baka
Code:Dim r, g, b As Byte
Dim intColor As Integer
r = 45
g = 100
b = 27
intColor = b Or (CInt(g) << 8) Or (CInt(r) << 16) Or (&HFFI << 24)
Simple, effective and straight to the point.
Didn't Shaggy already warn us about veering off the actual discussion to throw insults? Let's be civil here. I have opinions, just like you do. We are just having a discussion about a programming language. This is nothing personal.
I think I'll pay a little visit to GitHub later. Give you something to really be vexed about.
Take the high road. Wayne has his hands full as it is. I can't imagine that he isn't dismayed by some of the arguing going on here.
This is why I feel no previous attempt at a replacement to VB6 ever went anywhere: The people who want it, want it VERY badly, but they all want something slightly different...and are willing to fight to the point of destruction for what they want. Eventually, the person(s) working on the alternative got fed up with intransigent demands and decided to go do something less vexing.
I have an opinion on the operators, as well. I haven't shared it because it's not something I care about. Of the options suggested, I feel that LeftShift (or ShiftLeft) and << are the best alternatives (along with the right shift versions), but I don't care (my preference is one of those two alternatives). Every language has some anachronisms. C has case sensitivity, basic has Set and goto, and so on. We live with the quirks until they become endearing features. But I still don't care. If Wayne were to put it to a vote, I wouldn't vote because I don't care enough to attempt to influence the outcome by even that little bit. Let those who do care vote.
However, despite the passion people feel for the direction of a programming language, we need to be able to lose a fight graciously. If you can't do that, you end up in a debilitating, existential, battle over every little thing. Not only is that not good for either party, it's not good for TwinBasic in general.
We'll take what TB and RB have to offer us. It is not a democracy but we are living in good times for VB6 and we should not forget it.
I'm in that position. I said my opinion, that I acknowledge it is as biased as the opinion from any other person is, I made all the argumentation, and that's it.Quote:
Originally Posted by Shaggy Hiker
I admit (to myself and here) that I could be wrong.
My point is that I don't want Basic to become jargon as I see in other languages.
About the << >> operators, those are rarely used anyway. These kind of operations are not needed frequently.
Also true, so why to take it too hard if you can't decide anything.Quote:
Originally Posted by yereverluvinuncleber
Thank you Wayne, I'm very glad that this is the case.Quote:
Originally Posted by WaynePhillipsEA
I want to be able to open my existing code in a living, evolving, language.
Whatever syntactical decisions are made there, I'm sure I can live with.
I have that very complaint with the C family of syntaxes, and have made the point several times on this forum. My objection isn't so much readability as typability. Being a touch typist, getting to those symbol keys is pretty awkward. Interestingly, >> and << are an exception to this, since they happen to be above a pair of very accessible keys. I'd never really noticed that before, though. I really should like [] and {}, as they aren't so badly placed (the pinkie is a remarkably good typing finger), but I've never really liked them. I should prefer them to () and yet I don't. Funny thing, that.Quote:
Originally Posted by Eduardo-
I suppose it just goes to show that habits can be formed. My fingers know where the letters are, and where () are, but I have never formed a habit around most of the symbols on the number keys.
You make a good point about bit shift operators being very rarely used. I really LIKE to use them, when I can, but it sure is a rare event. I've always appreciated how very fast the left and right shift operations are on the x86 architecture. It doesn't matter anymore, but it was mighty nice back in the early 90s. I had a quick approximation of the Pythagorean Theorem that used those. It wasn't totally accurate, but it was far faster than a couple multiplications, let alone a square root operation.
Same here!Quote:
Originally Posted by vbrad
Just curious and for a bit of teasing
By my reckoning that means intColor is b. But preferably I'd want a compilation error for trying to Or a Byte and an Integer (which in VBA is 16 bits if I'm not mistaken, Long is 32 and long long is 64)Quote:
These two things are not the same. One is a function call syntax and the other is a binary operator. How would that clumsy syntax work when you have to do something like this:-
Code:
Simple, effective and straight to the point.Code:Dim r, g, b As Byte
Dim intColor As Integer
r = 45
g = 100
b = 27
intColor = b Or (CInt(g) << 8) Or (CInt(r) << 16) Or (&HFFI << 24)
he didnt dim it correctly
Dim r, g, b as Byte is actually Dim r as variant, g as variant, b as byte
and why do you make it byte, when u need it as integer and the result needs to be integer:
I would code it as:
Code:Dim r%, g%, b%, intColor%
r = 45: g = 100: b = 27
intColor = b or (g << 8) or (r << 16) or (255% << 24)
Pay closer attention. That is VB.Net code, not VB6.
VB6 doesn't have bit shift operators. Integers are 32 bits and Dim statements only require you to specify the type once for all variables declared in VB.Net.
That is a bit over zealous. A Byte aligns bitwise to the least significant byte of an Integer so it's a valid operation. But if you're paranoid, you can CInt it too to be explicit. The compiler does it implicitly without CInt.Quote:
Originally Posted by freeflow
I'm paranoid. I don't think I'd do either of those. I believe I'd use Color.FromARGB().
That does something different. Color.FromARGB converts an Integer to a Color structure. The code I posted is an example of how that Integer may be created in the first place. This is the full test code:-Quote:
Originally Posted by Shaggy Hiker
Output:-Code:Dim r, g, b As Byte
Dim intColor As Integer
r = 45
g = 100
b = 27
intColor = b Or (CInt(g) << 8) Or (CInt(r) << 16) Or (&HFFI << 24)
Dim cl As Color = Color.FromArgb(intColor)
Debug.WriteLine($"Color structure A = {cl.A.ToString} R = {cl.R.ToString} G = {cl.G.ToString} B = {cl.B.ToString}")
Code:Color structure A = 255 R = 45 G = 100 B = 27
You typically treat RGBA colour fields as 8 bit unsigned integers.Quote:
Originally Posted by baka
Notice that there is no vote to remove << and >> which is common-sense.
Of course I voted "NOT BOTHERED either way" as I don't mind weird BASIC operators/functions for which there is no equivalent operator in C/C++.
It's Wayne's chore now to implement NPV and PPmt functions down to the last dot and minus.
But who knows, in the next iteration of C++ language they might decide to use ¯\_(ツ)_/¯ operator for NPV equivalent :-))
cheers,
</wqw>
I voted in opposition to adding them. It's just unnecessary noise in my view. I'd also add that having multiple operators that do the exact same thing in a programming language is just madness. No other language does this.Quote:
Originally Posted by wqweto
Thanks everyone. I do find this debate fascinating, and appreciate all those that have voted.
All the financial functions are already implemented. Feel free to test them though in case we missed any edge cases!Quote:
Originally Posted by wqweto
+1 and LOLQuote:
Originally Posted by WaynePhillipsEA
Now that's sheer determination on getting 100% compatibility :-))
cheers,
</wqw>
I'll vote for a ¯\_(ツ)_/¯ operator anyday ;)Quote:
Originally Posted by wqweto
Isn't that just a RegEx string?
Really? You sure about that? Count me the number of ways you can concatenate strings in VB.NET ....Quote:
Originally Posted by Niya
-tg