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 Eduardo-
Printable View
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 Eduardo-
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
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
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.Quote:
Originally Posted by Schmidt
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.
Not this does not work (yet) and I just opened issue #563 in the repo.Quote:
Originally Posted by Niya
cheers,
</wqw>
Ah ok.Quote:
Originally Posted by wqweto
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!
This is exactly what I was saying. You get it.Quote:
Originally Posted by axisdj
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.
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 Shaggy Hiker
Interesting point.Quote:
Originally Posted by baka
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.
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.Quote:
Originally Posted by axisdj
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.
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.Quote:
Originally Posted by Niya
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.
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.Quote:
Originally Posted by mansellan
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....
I agree that this is an atrocity for VB.Quote:
Originally Posted by Zvoni
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.
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 :-))Quote:
Originally Posted by WaynePhillipsEA
https://github.com/rust-lang/rfcs
cheers,
</wqw>
Quote:
Originally Posted by Eduardo-
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
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.Quote:
Originally Posted by Zvoni
I absolutely love being able to do this:-
Instead of:-Code:MyVeryLongVariableOrPropName += 1
Like this is very primitive.Code:MyVeryLongVariableOrPropName = MyVeryLongVariableOrPropName + 1
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.
This is not the point, the point is not to pervert the language as I explained in post #579.Quote:
Originally Posted by Niya
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.
Wayne already addressed this point of mass adoption:-Quote:
Originally Posted by Eduardo-
In other words, new features like these new operators are a must.Quote:
Originally Posted by WaynePhillipsEA
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.Quote:
Originally Posted by Eduardo-
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:-
Where the argument for Increment is passed by reference. That's about as BASIC as you can get with something like this.Code:Increment(a)
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.
That's a non-argument if i ever saw one.Quote:
Originally Posted by Niya
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
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.Quote:
Originally Posted by Arnoutdv
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
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
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
Just to be clear, there's nothing modern about += style assignment operators. They predate VB6 in C.Quote:
Originally Posted by Niya
I've always preferred that operator over the long hand version, as well.
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.Quote:
Originally Posted by Zvoni
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.
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.Quote:
Originally Posted by Shaggy Hiker
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.
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 passel
That's exactly my point: to attract new people.Quote:
Originally Posted by Niya
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.
You could do that already in VB6.Quote:
Originally Posted by Niya
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:
It looks as ASM, but at least it is more straightforward.Code:Inc a ' adds 1
Inc a 2 ' adds 2
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.