Guiding Principles for twinBASIC Language Design

[bclothier]

Lately, I've observed new issues & discussions touch on the language design (and I'm also a part of the problem as well). As the cacophony of voices raises, I can't help but notice that there is no core principles to assess the proposals upon. Many people have expressed that twinBASIC should be "Basic-y" but we haven't actually really define what it means to be "Basic-y". Additionally, we've been looking at other languages for prior arts & inspirations and in some cases submit for it to be grafted into the language. Given enough grafts, we'll be in the unenviable position of creating a Frankenstein's monster.

As a consequence, several issues and discussions are unfocused (again, I take my share of blame here) and I'm concerned they are too myopic, focusing on one small aspect while not considering the overall fit with the language as a whole.

When I look at languages that have considerate success (I'm looking at Python, Rust, and C#), they all have one thing in common: they have a set of guiding principles to rally around in the design decisions that comes about. As a result, the language is very consistent and easy to use.

I think it would behooves twinBASIC to adopt its own principles. I am not sure if VBx ever had such thing but even if there were, twinBASIC is free to adopt some or all or none of them. All feature requests should be then weighted against the twinBASIC's principles so that we can help focus our discussion and not get hung up on whether x is better than y. Ultimately, this is a design decision, and there must be a tradeoff made. The principles will help us make such decisions more consistently and hopefully make twinBASIC a great language to work with.

@WaynePhillipsEA will need to develop and establish principles so that we can all point to this in guiding the feature requests.

For inspiration on what principles should look like:

Python Philosophy
Rust empowers by...
C# ECMA standard -- quoting below because it's a big zip file containing a big PDF. Yuck! On page 21:

• C# is intended to be a simple, modern, general-purpose, object-oriented programming language.
• The language, and implementations thereof, should provide support for software engineering principles such as strong type checking, array bounds checking, detection of attempts to use uninitialized variables, and automatic garbage collection. Software robustness, durability, and programmer productivity are important.
• The language is intended for use in developing software components suitable for deployment in distributed environments.
• Source code portability is very important, as is programmer portability, especially for those
programmers already familiar with C and C++.
• Support for internationalization is very important.
• C# is intended to be suitable for writing applications for both hosted and embedded systems, ranging from the very large that use sophisticated operating systems, down to the very small having dedicated functions.
• Although C# applications are intended to be economical with regard to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

If anyone else know of a great principle? philosophy? design goal? from other language, feel free to share.

[mansellan]

I agree wholeheartedly with these sentiments, and think this discussion is very timely. I too will hold my hand up to raising many specific feature requests which focus on single, narrow aspects.

I'd also like to propose that once the guiding principles are established, that all existing and future proposals for language extensions be collated and that they are considered holistically with regard to all others, so that everything evolves coherently.

Community engagement is key here.

[jpbro]

I like what you've written, and I've read the other project's missions/principles. I do think those other languages have the privilege of a clean slate (so-to-speak), whereas tB is somewhat saddled by its VB6 ancestry.

So I suggest that before we get too far ahead of ourselves, tB's guiding principles should be:

-1. tB should achieve 100% VB6 compatibility (+/- some fudge factor that accounts for all those weird programs that are never going to be recompiled) before any new developments occur.
0. Once Goal #1 is reached, it vanishes into thin air. This is the tB "singularity" from which point it must maintain 100% compatibility only with itself going forward.

1. <Let's continue this discussion as a community>

[bclothier]

Absolutely agreed. Wayne already has commented that VB6 compatibility is the number one goal, which makes twinBASIC a challenge compared to those languages I cited.

I really haven't considered the idea of allowing breaking changes once singularity is reached. As long as there are new VBx programs written, that may never happen. I predict there'll be a number of years where VBA codebases will coexist with tB, unless Microsoft decides to finally kill VBA (!). I don't know enough about VB6 to assess how many programs are still in active use & development. However, even assuming that VB6 is at absolute standstill, VBA remains alive and new codebases are created. That will probably be where tB adoption will come from and for that reason, tB must remain fully compatible and the "singularity" won't happen until then, if ever.

The other principles should therefore reflect this first principle so that we can make design decision that respects the backward compatibility while making tB a superior language.

[mansellan]

I agree, but with some reservations... 100% VB6 compatibility is absolutely top priority right now (Wayne has been at pains to point this out), and at a language level, it's pretty close. AFAICS, the only real gaps left are Forms (which is a biggie), and AppObject (which is not). I expect there will be some edge cases cropping up here and there too.

Interesting idea about the singularity, it hadn't occurred to me either. I can see where you're coming from, and its advantages, but there's a certain elegance in maintaining compatibility beyond that epoch. It's the approach that Microsoft took with C# (and I assume, VB.Net) - not tried but I would expect all C#1 code to compile in VS2022 when targetting .Net Framework 4.8.1. They only broke with this during the "Net Core reset", which was basically a ground-up rewrite for modularity and xPlat, and the perfect chance to ditch some baggage. Even with this major reset, there was some stuff they just had to carry or else code migration would have been too painful for everyone.

FreeBASIC now has many different dialects, which I think is a very bad call, to be avoided unless there's absolutely no choice.

[jpbro]

I really haven't considered the idea of allowing breaking changes once singularity is reached.

Good point, I wasn't thinking about breaking changes either. I think that once singularity has been reached, we can then have a "big bang" of ideas and growth. The hope would be that breaking changes would never occur (definitely not to the pre-singularity stuff that set the stage for the new tB universe).

But now that I've thought of it, perhaps a "guiding principles" statement makes sense in advance. What I think is that we should avoid any new language constructs until we have two things:

1. 100%-ish VBx compatibility
2. A good idea of what the community wants next <-- This is where guiding principles will be important.

As we've seen, the introduction of even the most innocuous of new features can snowball into a major debate. This debate can suck up an inordinate amount of time, and I know that time could be better put to more productive uses.

[WaynePhillipsEA]

FreeBASIC now has many different dialects, which I think is a very bad call, to be avoided unless there's absolutely no choice.

That looks painful. We absolutely must never go down that route.

[WaynePhillipsEA]

Thanks for starting this discussion. I am in full agreement, and I would urge all interested parties to come and have a say on this.

Once we've agreed the principles, I think it would be a wise idea to follow the advice from @mansellan from earlier; to create a separate GitHub repo for the language design discussions. We should be able to move any of the current and previous issues/discussions over to the new repro.

My time this week is very limited, but I am reading everything, and will of course respond in due course.

[Greedquest]

Once we've agreed the principles, I think it would be a wise[...] to create a separate GitHub repo for the language design discussions.

Alternatively take a leaf out of Go's book. They have an issue template:

https://github.com/golang/go/blob/master/.github/ISSUE_TEMPLATE/11-language-change.md

with a lot of info and which adds tags like ProposalLanguageChangetB 1.x so you can filter for LanguageChanges. You can modify a few of the fields to better match tB but it's a good start I think. Easier to keep everything in one place for cross linking discussions, issues etc.

I think the Rubberduck team has some experience with issue templates too

[WaynePhillipsEA]

Certainly, I can agree that our current issue templates need some work :)

[Greedquest]

@WaynePhillipsEA Sorry, I didn't even realise you were using them already here! Should've checked :) I guess subconsciously I may have noticed and was meaning "we don't have an issue template for language design proposals" so that was meant as an alternative to an entirely new repo.

[WaynePhillipsEA]

It might also be worth considering forming a very small committee of elected members so that the final decisions are arbitrated. Given the small community here at the moment, perhaps 3(?) elected members would suffice for now.

The final decisions should be straight forward if we get the design principles right.

[dmrvb]

I agree. BASIC up to GWBASIC was a beginners language. QB was a transition and VB a serious language. I recall it was often marketed as a tool for rapid prototyping rather than for beginners, which I always thought was daft, if it works in VB then why redo it in a harder language.
VB works at various levels and there is mostly a gentle hill but then with some big steps, like moving to API calls and making manifests etc. It would be lovely if TB could smooth these big steps. Hiding the nuts and bolts is good but again it would be great if they could be made a bit more visible to those who want to understand them.

[mansellan]

Fully agree.

VB was built alongside the MSVC of the day, and shared many of the same underpinnings. The compiler and linker share common roots IIUC. I tried to Google when MSVC lost the ability to compile to P-Code, but that seems to be lost in the mists of time. Best guess v7?

The point is, they were both native environments, which could access the (then, new and shiny) world of COM. MSVC could do anything (COM or otherwise), whilst VB6 was COM-native but with limited access to the fundamentals.

So what does this mean? IMO, VB6 should have been the natural home of COM. Everything in COM available, and intuitive. But for whatever reason, Microsoft decided that COM was too scary to make available, even to advanced users. But Declares and low-level memory operations were fine. Cue many, many years of "expert level" VB code on the forums.

twinBASIC has a chance to do this better.

EDIT: "What happened to cn2" Guessing it has something unexpectdly to do with default properties and coercion.

[VBFNiya]

Everything in COM available, and intuitive. But for whatever reason, Microsoft decided that COM was too scary to make available, even to advanced users. But Declares and low-level memory operations were fine. Cue many, many years of "expert level" VB code on the forums.

I have actually found the opposite to be true. I find COM to be extremely intimidating. It's far more difficult and cumbersome to deal with than classic C style exports. COM requires a lot of bookkeeping and a whole lot of other plumbing I still don't fully understand even after decades of dealing with it. COM feels easy in VB6 because it hides a lot from the developer but it's far more than it appears.

[bclothier]

Technically VBx isn't just COM - it's actually built on top of OLE Automation, which builds on top of COM and represents a much narrower subset of the COM ecosystem. As a consequence, the rest of COM ecosystem is inaccessible to VBx without some hackery.

The biggest problem with COM, IMO was that you had to follow conventions that are not specified in code itself, leaving it up to the programmer to write the correct implementation of the convention. .NET and other languages has since made it easier to enforce the convention using code rather than crossing the fingers and hoping that they will actually read the documentation how to use it properly. That was the nature of the beast in the 90s. Furthermore, COM was basically doing object-oriented programming in plain C (you can use it in idiomatic C++ but if you look at some of the header files, you can see that Microsoft wrote it for both plain C and C++. That meant much less language support, particularly so in C for managing resources. I think that's why they tried to patch it up with Massively Frustrating Class and Absurdly Terrible Library but that can be very daunting because they leak... like a lot.

However, I've seen that with .NET 4, COM interop became much easier and lot more things became possible as long you deal properly with the conflict between .NET's non-deterministic garbage collection and COM's deterministic reference counting. Still, it's a huge PITA. I'd love to see twinBASIC as the new best way to author COM solutions. I think we can move beyond Massively Frustrating Code or Absurdly Terrible Library and do better with twinBASIC. 😄

That's also why I think transparency as mentioned in other reply matters.

[WaynePhillipsEA]

That's a nice idea, but you are doing a pretty good yourself at present, and often a "benevolent dictator" is preferable to democracy. Looking at all the activity here, I suspect most contributors are power/low level users that are maybe not representative of the VB6 community, and are mostly concerned with non-GUI add in VBA components (for Office/access)?. The RAD GUI aspect of VB6 is under represented?? A lot of discussion concerns the low level nuts and bolts of COM whilst a typical VB6 user chooses VB6 because it protects them from all this stuff. Its a difficult one, only the "geeks" have the required understanding of compiler mechanics but are not representative of most users????

I appreciate the feedback and support :)

I would generally agree with your comments regarding VB6 devs being under-represented here, though of late it seems that we have attracted a few more people from the VBForums/VB6 community, so perhaps it will eventually become more balanced.

[vbBaka]

and that is why I wrote about the c-operators. not because I can't learn or because it looks horrendous, but to create consistency in the language.
we should be very carefully when we add something new, there need to be a holistic view of the whole language and seek for:
similarity and consistency.

for me the syntax is "very important", more important than features.
if you advocate to add new features without giving care of the language syntax, its exactly the wrong direction.
when someone says: "this is how other languages are doing", I ask myself. how much similarity are those languages with "Basic", thats the first thing. and what other languages are out there that also have that feature do, and what syntax they use, and lastly, of all the languages what language is the closest to Basic and what do they use.

if we read the Philosophy from TimPeters in Python, I would read all that everytime theres a new feature.
and I would also look at "all" operators and functions Basic has, and try to find similarities. if we don't, we fail the syntax.

as someone wrote in the other thread:
I like >> but not >>=
this is very important, that we borrow an operator from a language, but feel bad to borrow the other.
it means its not really the "right" syntax for basic, but we do like the operator as it will give us a new feature.

other languages did create their own "variation", and why did they do that?
thats also a very important question. why.
why didnt they do like most of you want, just take that operator right away without giving thoughts.

I agree that we need a guidelines here. and we need people with strong Basic-knowledge and understanding.
we could say a linguistic person, that understand the syntax very well and can find those traps if we add a feature carelessly.

[KDGundermann]

If anyone else know of a great principle? philosophy? design goal? from other language, feel free to share.

I'm now programming in MS Access/VBA for over 25 years and I like it how easy it is to develop an application using
a database, some forms, some reports and VBA to glue it all together.
But sadly VBA has some drawbacks:
not really OO, no easy way to include external libraries (beside Copy+Paste or OCXs), old IDE, etc.
So I started to learn Ruby on Rails and I fell in love with Ruby:
to quote ruby-lang.org

"Ruby is... A dynamic, open source programming language with a focus on simplicity and productivity.
It has an elegant syntax that is natural to read and easy to write.
And the Rails framework has several strong guidelines where to put your models, views, controllers etc.
Sadly Rails is focused on building web applications, and the whole web thing is a fast moving target, new browser releases and JavaScript frameworks every few weeks. It takes a lot of time to learn all these new things and upgrade your application ( on the contrary my VBA application is still running with 25 year old code)

So what I would like to see in TB is:

• easy to learn and read syntax and code
• easy to build and use external libraries ( like Gems / Bundler )
• easy to build Windows Desktop applications

[mansellan]

We can absolutely learn from the patterns (anti-patterns!) that have been discovered by countless other languages over recent years. There's nothing to gain from designing a governance model in a vacuum. We should look to see what has worked / not worked elsewhere:

• What are the most loved languages? What are the most dreaded?
• What are the goals and philosophies of other languages? How do they differ from ours?
• How big are the communities of those languages? What are their governance processes?
• Are there any patterns from the above?

This is NOT to say we should immediately import the syntax and governance model of "language X". It is to say, what can we learn from what others have tried?

[bclothier]

I think that the principles are more important right now --- the governance model can evolve as the community grows. However, the principles should be akin to the Ten Commandments. No take-backsies. We definitely should look at how they formed their goals and worked toward it, though.

[bclothier]

To get the discussion going, it might be easier to have a draft to work with. Please do feel free to scream bloody murder, chop & dice it up and edit to your heart's contents. Or post your own drafts. The principles are numbered to indicate precedence so if you think a principle is more important than other, resort accordingly. I took this from the languages' guidelines, other comments in this discussion and sorted based on what I think reflects the aims of twinBASIC. Again, if I'm wrong, just provide a better draft. 😄

1. twinBASIC is fully compatible with Visual Basic 6 (VB6) and Visual Basic for Applications (VBA) so that existing codebase can be bought forward to twinBASIC.
2. The community is paramount; it should be easy to engage, share and contribute with other twinBASIC users.
3. twinBASIC aims to be readable and clear as possible. It is better to be explicit.
4. twinBASIC should enable the developers to focus on the business problem to be solved.
   4a. A good default implementation is better than none at all.
   4b. However, the developer is free to substitute the implementation if it suits the purpose.
5. As much as possible, twinBASIC ought to be consistent in its syntax and features. Consistent is easier to learn. Readability and clarity takes priority over consistency.
6. twinBASIC will be transparent in what it is doing.
7. twinBASIC should have one and preferably only one obvious way of doing things.
8. twinBASIC should make it very easy to refactor and develop tests for the codebase.
9. twinBASIC should make documentation easy as possible, encouraging self-documentation.
10. twinBASIC makes GUI based solutions easy to build and maintain.

[mansellan]

twinBASIC is 100% backwards compatible.

Anyone can continue to bitshift exaxtly as they did before (with casts, divisions and multiplications). Others can use the new operators. Why is that not OK? Other than "people should not BASIC like that"?

[jpbro]

I understand the thrust of the argument against the alien operator. For code-sharing between parties that prefer opposing approaches, there will be an irreconcilable conflict.

For example, I'm happy with "<<" but someone else prefers "ShiftBitsToTheLeft". I write some decent code that uses "<<" and publish it on GitHub. A person who needs my code but prefers the other approach finds either:

A) Can't understand what the heck I'm doing with the "<<" operator, OR
B) Understands it but it offends their sensibilities.

For A) they can Google it and learn. Unless they are just a copy & paster, in which they don't care anyway.

For B) they can Find+Replace or just grin and bear it. This situation happens with everything single codebase in existence today when shared amongst multiple parties! There are so many programming holy wars that it's impossible to keep track. IMHO you either take someone else's code (that is offered freely) as-is, or you take the time to re-format it to your liking. This includes things like variable & method naming conventions, variable type shortcuts, single-line vs. multi-line IF statements, etc...

[VBFNiya]

For example, I'm happy with "<<" but someone else prefers "ShiftBitsToTheLeft". I write some decent code that uses "<<" and publish it on GitHub. A person who needs my code but prefers the other approach finds either:

A) Can't understand what the heck I'm doing with the "<<" operator, OR
B) Understands it but it offends their sensibilities.

Or worse...you could run into code like this:-

a = (b << 8) Or (c ShiftLeft 16)

You know there will be at least one script-kiddie out there who would think this is cool lol

[bclothier]

I understand the thrust of the argument against the alien operator. For code-sharing between parties that prefer opposing approaches, there will be an irreconcilable conflict.

I strongly suspect that's a huge motivation for the other, especially newer languages, to be more picky on the consistent syntax & idiomatic coding. What's point in sharing code if you can't use it because it's not following conventions.

Fighting over which ought to be The One True Style can be unproductive. Python tried to prevent this by making whitespace significant and thus force everyone to one style so that there would be no need to complain that so and so isn't indented with spaces.

We don't have the luxury of a clean slate so we must come up with ways to help converging toward a consistent style. I suspect the CodeLen feature will be a huge help in this aspect.

[Greedquest]

@jpbro from the Zen of Python (their answer to this discussion)

• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.

This is the kind of guideline that could resolve the unresolvable discussion of "one or both". This is the value of creating guidelines, they give authority to one side of a stalemate argument without being so strict as to prevent discussion.

tB should come up with its own guidelines to provide default standpoints for subjective decisions, standpoints which align with its particular language design goals.

[FullValueRider]

To add my penniesworth I too have seen the discussion on VBForums (and even contibuted as Freeflow) and I think the discussions are focussed on detail rather than a strategic viewpoint. Twinbasic has a design philosophy, which is to be VB6 compatible. Lesser spoken aims I would surmise would be 'rescuing' projects from VSTO and the awful awful javascript api's.

So the driving forces for twin basic development, from my viewpoint would be facilitating code moving into Twinbasic, which is the same principle as VB6 compatibility but extending further to offer a helping hand to VB , C# and other languages) and then providing better structures and syntax for moving code forward when refactoring.

From this perspective it makes perfect sense to introduce c like operators but maybe not new operators Like RShift and LShift. However, I would suggest that the use of such 'things' is flagged with a deprecated warning because they are intended only as a stepping stone to something better.

Any group formed to consider additions to twinbasic should be focussed on ' What do we add to make things better' rather than language x has this 'typing reducing' feature lets add it to Twinbasic.

As examples, the discussion on bit shifting might be circumvented if it were possible to specify bit fields in a Typedef

Type Colour

    Red as Bits(0 to 7)
    Green as Bits(8 to 15)
    Blue as Bits(16 to 23)
    Chroma as Bits(24 to 31)

end type

Cheers

Similarly the use of operator= and double operators (eg ++) could be largely avoided by having a fast behind the scenes zip method that converted two or more collection type objects to a single collection of arrays to facilitate the existing 'for each' structure

e.g. something like

Dim myItems1 as collection
Dim myItems2 as arraylist
DIm myItems3 as scripting.Dictionary

For each myGroup in myItems1,myItems2,myItems3 ' Takes the items from myItems3

      Dim myThing as long = (myGroup(0) +myGroup(1) )/mygroup(2)

This is the type of discussion I'd rather see rather than arguing about symbols used to represent syntax.

So in Summary

1. Add to twinbasic to facilitate migration into twinbasic but mark as deprecated
2. Take a higher level look at what constructs/syntax is trying to achieve and introduce new structures/operators that are 'bettter' for moving code forward.

[Greedquest]

So what languages do we want to target for migration? I like the principle - new syntax can be a blend of idiomatic VBx if there is a precedent, but also taking influence from nearby languages to help facilitate a jump. C# describes designing for "programmer portability" particularly from C/C++. So where do we want to target users migrating from?

Luckily the syntax of BASIC dialects already targets English speakers by generally being quite verbose and descriptive, meaning most people can already read VBA code and we could feasibly poach from anywhere

[FullValueRider]

I'd be wanting Wayne to be focussed as follows

1. updates that reduce the need for boilerplate code
2. updates that improve the usabilty of existing structures e.g. a get enumerator for arrays, option to enumerate arrays by column major or row major order, new types that leverage the ability to write generic or overloaded code.
3. updates that improve access to com

If I wanted to point to a language for examples of how to make things better, it would be Nim (the flexibility and speed of C++ with the readability of Basic)

[Greedquest]

@FullValueRider Ah I might have slightly cherry picked a point from your post. What I was observing is that a good (maybe more objective rather than subjective) way to justify new twinBASIC syntax is to assess how familiar it would be to potential new users migrating from other languages. I'm not sure how I feel about your "stepping stones" idea of supporting syntax aliases to transition from other languages. But I think there is a good point in taking inspiration from those languages that tB basically wants to compete with for users. This way tB will seem more familiar to them.

To expand a bit, there are three groups of potential twinBASIC users to appeal to when deciding new syntax:

1. Existing VBA/VB6 users.
2. Existing programmers using other COM focussed languages (ruby?, C/C++?), or other high level automation languages (python?) or other complimentary languages to the VBx ecosystem (C#?) - competing languages whose users may benefit from switching to tB.
3. Entirely new programmers, or at least new to the VBx ecosystem and not working already with other competing languages.

For users in the first group, of course, tB being consistent with VBA/VB6 is the number one priority. However in situations where there is a new syntax with little precedent so there is no clear "most VBA approach", it could make sense to look at the second group of users and say, which syntax will be most familiar to the majority of them? This could help resolve stalemates in a more objective way.

---

I don't really know anything about Nim so I'm not sure which of those 3 groups Nim users would fit into. I see it makes sense as inspiration since it has a BASIC influence, but I don't think we should copy it's syntax choices necessarily, given there are probably bigger userbases we want to appeal to.

[FullValueRider]

I'm only referencing Nim as it was designed from the get go to be readable as opposed to maintaining similarities with predecessor languages. I'd be looking at Nim for what makes sense in terms of usability/readability and then determining if such ideas were implementable/desirable/of benefit to twinBasic. I see no reason not to follow the same strategy for other languages.

This is not a proposal to change the nature/syntax of VBA/twinBasic, just scouting for ideas to possibly enable improvements that remove boilerplate code, enhance usability, or improve readability.

[EduardoVB]

in situations where there is a new syntax with little precedent so there is no clear "most VBA approach", it could make sense to look at the second group of users and say, which syntax will be most familiar to the majority of them?

Yes or no. VBx has an idiosyncrasy, the new syntax should be according to it.
For example do not allow variables to start with underscores.

BTW I've just been looking a bit to Nim code, VBx seems better (clearer) to me.

IMO, simplicity and readability must be number one priority, over terseness.
Avoid symbols as much as possible.

[vbBaka]

My preference is that Wayne is the one who makes the final decision. He is the one who wrote the compiler. I would think he'd like to hear from everyone else on that matter as well.

this is important, as Wayne is the director of this story. Im still trying to understand his envision and goals. so far its not that obvious.

No, but we want to make it easy

this I don't agree. what you think is "making it easy" could actually making it worse.
if you just look in vbforums all the sources we have, we could write a math problem in hundreds of ways. usually a thread with a question result in many different ways of getting to a solution. I would never have to write the way "you" want it. no thanks.

We don't have the luxury of a clean slate so we must come up with ways to help converging toward a consistent style.

and this is my concern, and why I go so much against what you try to do.
as for me I see it like: we have VB6, now lets upgrade it. I don't see VB6 as something bad that needs to be cleaned up.
TB is 100% fully back compatible, but in the same time I feel that a lot of you want to change that if you just could. but you can't, because you need to follow the decision of Wayne that it need to be compatible. while for me its: I love it. Wayne is doing a great job and I don't want to change anything, 100% means I want every bit, even the "bad part" of the language, because "it is part of the language" not a mistake or something that need to be changed.

that for me is a big concern. you want to encapsulate TB for your own subjective needs.
now the title "Guiding Principles" is reading "List of Rules". in my eyes.

edit:

but mark as deprecated

thanks you FullValueRider, for writing this. as this show exactly my point I made.
for me this is a mistake, to try to phase out VB and substitute it with something else.
why all the trouble of making it 100% fully compatible, if in the end, we need to "adapt" to your ways and stop using VB.

[VBFNiya]

Because of the COM dependency, I predict that Wayne will need to at least package some of the COM stuff to work cross-platform, which will drive the need to be able to author such components so that it's not tied to Windows but fully compatible.

I actually raised this point on VBForums and Olaf, our resident COM expert made a very convincing argument that the Wine source code could be used to port COM to different operating systems. He also implied that it would only need a subset of all the the COM APIs to be compatible with VB6. He thinks it's doable without too much effort and I'm not qualified enough in this arena to challenge that.

[bclothier]

made a very convincing argument that the Wine source code could be used to port COM to different operating systems.

I think @WaynePhillipsEA is better qualified to address this one, but I think that one objective that I failed to include in the draft was that tB would not require any runtime support to work. Right now, tB has no dependency on msvbvm60.dll nor will it require such thing just to run:

Generated EXE and DLL files tend to be very small with twinBASIC. Please note that generated EXEs and DLLs do not require any runtime or redistributable components! (unless you reference third-party components yourself).

Source

Therefore a wine dependency probably wouldn't meet that goal of being able to generate a self-contained .exe/.dll for the cross-platform. I think that is also important if we want tB to target WebAssembly (#570).

[Kr00l]

Including wine source code will not generate an dependency ? It's like including the OleTranslateColor source code I posted in #571 from reactOS. It will not produce a reactOS dependency.

[bclothier]

I was thinking of the wine .so files that provides the COM supports that needs to be installed into the *nix system. If wine source code can be compiled into the EXE then disregard my comment.

[WaynePhillipsEA]

Including wine source code will not generate an dependency ? It's like including the OleTranslateColor source code I posted in #571 from reactOS. It will not produce a reactOS dependency.

From a licencing perspective, I don't think we could do that. With Wine being LGPL, we'd need to be able to replace the Wine code in generated executables, so in our case (with a closed source compiler) this means that the Wine parts would have to be distributed as a dynamically linked object file.

You'd actually be surprised at how few Windows/COM functions we rely upon in generated executables. It's really not as big of a challenge as you might expect for us to reimplement them ourselves (without Wine, and its licencing issues).

[Kr00l]

I mean there is only a discussion when there is any new syntax that shall be added into tB, right ?

And in the past Wayne looked always for "prior art", e.g.

1. VBA64+VB6
2. VB.NET
3. FreeBasic and other basic dialects

And what feature is in discussion now or will come that does not have "prior art" ?
So, for me the guiding principles are already clear to choose the "dominant" prior-art syntax. I don't know if there will ever be some new syntax in tB that can't rely on prior art, no ?

Let's take the bit shift operator (as this caused some emotions on some users) there are only two prior arts available, either << and >> or SHL and SHR. That's it.
And in my opinion << and >> is the "dominant" prior art. So let's stick to that and move on..

I mean tB could go ahead and define it's "own art" but I don't know if that will help or just causes confusion.

[bclothier]

Just to clarify, no, it wouldn't be just about the syntax but the overall design of twinBASIC (e.g. standard libraries, IDE support, ecosystem should factor into this discussion).

[bclothier]

Draft 2. Some rewording to clarify some of the points and to incorporate others' comments, particularly regarding runtime dependencies. Added a new subpoint for the point 6 & 10. No changes in the precedences.

I do want add to the point 2 that there ought to be a central repository similar to what Rust is doing with its crates.io and docs.rust-lang.io but held back as that may be committing too much or being too specific.

We should consider carefully whether we should trim down the list - a tight focus is usually very helpful.

Again, discuss.

1. twinBASIC is fully compatible with Visual Basic 6 (VB6) and Visual Basic for Applications (VBA) so that existing codebase can be bought forward to twinBASIC.
2. The community is paramount; it should be easy to engage, share and contribute with other twinBASIC users.
3. twinBASIC aims to be readable and clear as possible. It is better to be explicit.
4. twinBASIC should enable the developers to focus on the business problem to be solved.
   4a. A good default implementation is better than none at all.
   4b. However, the developer is free to extend or substitute the implementation if it suits the purpose.
5. As much as possible, twinBASIC ought to be consistent in its syntax and features. Consistent is easier to learn. Readability and clarity takes priority over consistency.
6. twinBASIC will be transparent in what it is doing. The code should do what it say, no more, no less.
   6a. twinBASIC will provide IDE support for existing syntax that do not say what it does to achieve transparency.
7. twinBASIC should have one and preferably only one obvious way of doing things.
8. twinBASIC should make it very easy to refactor and develop tests for the codebase.
9. twinBASIC should make documentation easy as possible, encouraging self-documentation.
10. twinBASIC makes GUI based solutions easy to build, ship and maintain.
    10a. twinBASIC should be self-contained and not require runtimes or virtual machines to run.

[bclothier]

Interesting, indeed. However, I have to ask.... has anybody successfully done it?

I'm thinking back to when they first released VB.NET, they also offered a "converter" to convert VB6 code into VB.NET. That was a dismal and abject failure for many many reasons. Setting aside the more fundamental issue behind the memory management changes, it was likely to litter the code with lot of TODOs because you were then expected to change it to make it work. That converter is no longer around.

And then I'm thinking that surely in the 10+ years, pythons should have said, "Egad! People are still using 2.7! Let's make it easier for them to get from 2.7 to 3.0!" and offer some way to do just that. I think there was some efforts in form of providing compatibility libraries but that ultimately did not solve the problem. People continued to use Python 2.7.

So while this guy's idea is pretty good, I'd really want to see a practical implementation of this showing to have succeeded. If there aren't, why not?

[Greedquest]

@bclothier ah no the Go thing wasn't a converter, quite the opposite. The point was that as you said converting is the big hurdle with breaking changes so Go wanted to allow you to make a compiled package containing both Go1 and Go2 source code "by compiling to an intermediate representation that was a superset of both". So sort of hybrid approach. Incrementally convert your dependencies by hand rather than all our nothing (a python3 package must be entirely python3, including its dependencies. So much harder to make the switch)

[bclothier]

I know that. My question still stands, however. Has it been successfully done before anywhere else?

I cited VB.NET's converter as an example of failure because it illustrates that certain changes (in this example, the memory management) invalidates the assumptions the original codebase made which meant it was doomed to fail even if they beefed up the converter. The proposal from that guy does not seem to me address this type of changes. While it's unlikely that tB 2.0 will suddenly go and change memory management, we have to consider whether a similar type of change will put tB in the same situation.

[WaynePhillipsEA]

One of the side benefits of pledging that level of support for backward compatibility is that you become far more circumspect about adding new features to the language if you know there is no going back once you add it.

I really like that viewpoint, and the thought processes that it entails.

[WaynePhillipsEA]

On the backwards compatibility front, my stance on this is that from v1.0 and beyond, we strive to be, and always be, fully backwards compatible from there on in. We can potentially encourage old syntax to use some shiny new syntax (using CodeLens or other refactoring tools)... but the old syntax will always be supported.

For developers potentially looking at twinBASIC now and in the future, us taking such a strong stance on backwards compatibility will be very attractive IMO.

[mburns08109]

My $0.02 on the basic-y-ness of this is summed up in the following: KISS rules apply here.

Always recall what BASIC was intended to be from the start. It's right there in the first letter of the name of the language,

B eginners
A ll-purpose
S ymbolic
I nstruciton
C ode

Never forget that this language started with the idea that it was for BEGINNERS, new to programming.
Consequently, the language should ALWAYS consider those beginners as primary amongst the factors to be measuring when deciding upon new language features and implementations.

This is actually harder to do when you think about it because:

1. reality is messy
2. the situations that the "All-purpose" part allow for tend to increase the likelihood of increasing complexity for things for which the language may be applied over time.
3. CODE CLARITY should probably be the mantra to keep in mind for developing the language further
   (it is in that light that I prefer the LShift/RShift operators over "<<"/">>" as making Basic more tersely Forth-like should emphatically NOT be a design goal we adhere to.)
4. No. 2 (above) mitigates towards evolving language features that will make the BEGINNERS simply toss up their hands and go "what the hell is that!?" So, we should try to minimize that aspect of things as much as we feasibly can (we neither want to make Basic more COBOL-like than we want to make it more FORTH-like). Meaning, nobody wants "MOVE 2 to A" over "A = 2". Both terseness and verbosity have their limits. The trick is finding the balance between them, keeping the Beginners in mind, while allowing for the power and flexibility needed for the "All-purpose" part.

[mansellan]

The ironic thing is that because we are using COM, it's actually much easier to set up tests yet nobody does it because making mocks is too hard, even though a mocking framework is definitely feasible with COM.

This.*

COM was invented to be portable, with explicit, contractual boundaries. That should mean that it is intrinsically testable. Somehow, that never happened. Perhaps because the protocol was just too damned complicated?

Perhaps we can solve this, and fulfill the idea?

* No pun intended.

[bclothier]

I think it was more that the notion of test driven programming wasn’t really developed back then. Remember, with the Edit and Continue feature you already can test your code in real time!! How awesome is that?!? Inadvertently it served as a disincentive to invest more in the testing, especially automated, infrastructure.I also guess that such testing suite cost a pretty penny back then, so the rest of us putzs had to scrape among with our (awesome!) Edit and Continue. 😄

[wqweto]

Btw, what is Right$(t, Len(t) - i, 1) exactly?

Speed of REPL (i.e. Edit&Continue) is orthogonal to testing and testability of the code, IMO -- both are important. VBx being interpreted language has enormous REPL speed thanks to its in-proc debugger and IDE implementation.

TB is diverting from this as its development path does not include "all interpreted language" first stage or being "all IDE" from the beginning. It's more "normal" compiler first approach so probably will never reach VBx IDE REPL speed/comfort.

[bclothier]

Btw, what is Right$(t, Len(t) - i, 1) exactly?

Nonsense written by a fool who didn't correct the original mistake. 😄 The , 1 shouldn't be there. The point has more to do with the fact that there is a large latitude allowed in what is considered clear & readable. That is a potentially problem for code sharing.

[WaynePhillipsEA]

Btw, what is Right$(t, Len(t) - i, 1) exactly?

Speed of REPL (i.e. Edit&Continue) is orthogonal to testing and testability of the code, IMO -- both are important. VBx being interpreted language has enormous REPL speed thanks to its in-proc debugger and IDE implementation.

TB is diverting from this as its development path does not include "all interpreted language" first stage or being "all IDE" from the beginning. It's more "normal" compiler first approach so probably will never reach VBx IDE REPL speed/comfort.

I think you'll be surprised just how well the Edit and Continue is going to work in tB. Modern hardware, coupled with well designed software means that working out-of-process is really not a major drawback anymore. I mean, have you noticed how quick the error squiggles appear when editing tB code? The parsing and compilation phases all happen out-of-process, yet the squiggles appear almost instantly. Same goes for Intellisense.... it's pretty much instant in most cases. Edit and continue will be no different :)

[FullValueRider]

I have been using twinBasic since it became available to port a large library I use for simplifying code I write for Advent of Code problems. As an amateur programmer I'm finding the debug cycle and intellisense in VSCode a somewhat better experience than the repl in VBA (even when assisted by Rubberduck). The promised edit and continue might make a slight improvement to the twinbasic experience but its not something I'm desperately waiting for.

[bclothier]

That makes me wonder....

@retailcoder has written a lot about the Smart-UI, an anti-pattern which is very pervasive in VBx world due to the nature of GUI designer & code-behind. For example, here and there. I've rarely seen a VBx solution that did provide a good abstraction between the business logic and presentation layer. It's far more common to mix them and shove them as a one giant monolithic object. That design also hamper the testability because you no longer can test the business logic; you're going to have to monkey with controls and get the global state set up so that you can then test that one button's click.

If you build the business logic independently, then the test & debug cycle in VS Code won't appear to be a impediment. However, if you're importing an existing VBx codebase with smart-UI, you're going to have to do some refactoring first to abstract it out so that you can test the inputs & outputs without going through all the UI. For that reason, Edit & Continue is very useful for such designs but it won't help the users avoid the anti-pattern.

That then circle backs to the "beginner" question. Requiring a new user to learn all about the abstraction is hard. We should try to find ways to make it very easy and natural for them to build solutions that are not entangled in deep web of dependencies. What do you all think?

[KDGundermann]

As a beginner you are learning from documentation and examples. After mastering the first steps (variables, control structures, methods and functions) they will be looking for more enhanced examples (maybe with a gui). Where will they look for more examples? Presumably directly at the "owner" of the language, eg. for VB.NET I would be starting on the MS sites.
So we should not only create a compiler but a whole ecosystem with standard libraries for different use cases and GOOD examples for these use cases.
(btw I was caught by RubyOnRails after seeing this video from DHH https://www.youtube.com/watch?v=Gzj723LkRJY its from 2005)

[bclothier]

I wholeheartedly agree. That's pretty much why we have the point 2 and 9. I really do think rust wouldn't have taken off if they didn't have the ecosystem and I think the crate idea is frankly a genius. I don't know enough about Ruby on Rails, but it sounds like they achieved something similar and possibly even earlier than Rust which mean it is a good idea for tB to replicate (with its own spin, of course). However, I think that is best served by the community, rather than by the author as Wayne would not have time to do it all. It might start out with some curated contents and hopefully expand from there. That kind of implies a need for a system for people to submit their content so that it can become a part of the tB's curated documentation.

[WaynePhillipsEA]

Maybe we need to prioritize nugget style packages (#16), so that the community can start contributing to that end goal?

[bclothier]

I'm inclined to say yes. Looking at Rust, the cool thing is that they made the cargo and the crates explicitly a part of their build toolchain so it was easy to get started with rust, using just the native tools. Samples are great but I think we want to encourage people to get started by importing packages they need instead of modifying a sample, and we need to address the documentation (which is also a big part and thus integrated). Best to thrash this out while tB is in 0.x.x.x so we can refine the process to make it easy and intuitive as possible.

[vbBaka]

I would also want to enforce:

VB6 is the main purpose why TB was created.
VB6 should be the core of everything.
we should always start in VB6 and look, what can be done to improve it.

Im quite tired of the .NET taking charge. if you love .NET why are you here?
To make TB successful you need to place VB6 first. otherwise you will be bias to add .NET stuff.

and... how strange is not that, you want to turn TB into .NET.
why? to create a clone of .NET? we already have .NET so I don't get it.

adding new features should be:

• look into VB6, can it be upgraded? what kind of methods, syntax do VB6 have. is there a way to improve that.
  when that is done, and carefully looked into everything, and we didnt find a solution, thats the time we look into something else. even .NET.

but never, and I say, NEVER start by looking in other languages FIRST.
even if we go the VB6 route, that you feel: its not as cute, or its not as optimal, or its not as this and that, its still the way to go.

we improve VB6 and keep its language and syntax as it is.

I read from a few of you: TB is 100% backward compatible. and after that its silence.
like I wrote before, wheres the love?

and I get the response. we love VB6. do you really? and how you manifest that? and how do you explain your reasoning when you want to add new features FIRST before you even thought of a way to actually just improve what VB6 already has.

you think VB6 is just a garbage language that is limited to a few things.
but its not, we can do almost anything in VB6.
you can read that in vbforums, many subjects are about that. in the end VB6 can do a lot already.

so, now, we gonna create MixLangz and add new features because you think its cool, or look nice. or "this is how we do it"
before you even thought about what we already have in VB6 and what can be done first.

Im quite disappointed.

[VBFNiya]

Let's stop playing these games and be real here. If .Net didn't exist and TwinBASIC was the first to adopt some of the things we are suggesting, you'd not be complaining one bit. Your entire gripe with all of this is based entirely on the fact that you hate .Net therefor you don't think it should resemble anything from .Net. That makes zero sense. This goes back to my point about cars and square wheels. You want square wheels on your car because the car you hate has round wheels. Does this sound practical or even intelligent to you? Seriously.

But let me tell you another thing that is also true. .Net and C# were wildly successful regardless of you hating it. The world has embraced it and if you want the world to embrace TwinBASIC, you're going to have to look at what they did and borrow what makes sense. There are a lot of people here that have come from other worlds and they will bring their experiences with them. This would include things from the world of .Net. You cannot deny this.

I'll also say this. I'm going to shoot in the dark here and say that you have not used C#, VB.Net or anything from .Net for any extended period of time, like say a year or more. If this is true then I'd like to point out you're criticizing something you have never used. Why should anyone listen to your criticisms of a technology you have never really used? You wouldn't know anything about it therefor your critiques would have no substance. It's all just pure opinion based on nothing real. You have no real experience using .Net therefor you have no grounds to criticize this harshly. Would you like someone to judge you before they get to know you? I would think not. This is the same thing you're doing. You're judging something you know nothing about.

[VBFNiya]

look at Olaf RC6, why is that not successful? its modern, optimized, tons of functions. its a huge library.

We already covered this on VBForums. It lacks centralized documentation which is a barrier to entry for a lot of people. No one wants to go trotting through the depths of the forums to find the information about a class or function on the 12th page of a thread.

u ignore all the points so I don't want to have any discussion with you. I don't want to waste time on you if you are just trolling.
also, I know that nothing I say will work on you. you just want to mess around.
so its just waste to try to reason with you. so I will stop here.

All you're doing here is throwing a tantrum like a petulant child because you can't get your own way. When will you learn that the world doesn't revolve around you. If you want people to see things your way then make good reasonable solid points like an adult instead of throwing fits every time someone disagrees with you.

[VBFNiya]

I would also point out that you failed to address any of my points directly and instead chose to address the person behind the points, namely me. This is not the way you want to conduct a discussion. What you're doing is engaging in ad hominem and this type of debating is historically known to be ineffective at driving real change. Don't attack me. Attack my points and perhaps you can persuade people to your thinking. Just my humble suggestion.

[mansellan]

Personally, I'd like it if we all took a deep breath...

At the moment, what we have are discussions. Some are heated, to be sure. I's expect that; VB6 was treated appallingly by Microsoft.

As a bystander, I'd say that VB.Net failed in its core goals. It wasn't VB, and it wasn't .Net

• Not VB because it changed the memory model, and moved from being reference-counted to garbage-collected. And moved from being native to being managed. They are both deal breakers.
• Not .Net because it was an afterthought. All the invention went into C#.

In my humble opinion, twinBASIC should be what VB could have been if Microsoft didn't make it a .Net language. I think, by now, it would have:

• Generics
• Overloads
• Delegates
• Extensions (Linq)
• Async/Await

And probably lamdas too. I'm not suggesting twinBASIC should (or even could) have all of these, but they should all be open for discussion. Even if the final answer is "we shouldn't" or "we mustn't". We at least need to establish why.

[VBFNiya]

@mansellan

No one is suggesting we turn it into VB.Net. We are just suggesting that some things may be borrowed from the .Net and incorporated into TwinBASIC.

[aidajulia]

Hello, I have been following the evolution of twinbasic from the beginning and reading the comments and interests present

Maybe it would be useful to change strategy

That is to say, make a prototype of a twinbasic product obtaining the basics of compatibility, finishing a version 1.0, and then, afterwards, on the established prototype, and already with certain expectations covered, starting the process of modernization of the product

That is, first make a 100% compatible prototype
Then start on it, a version 2.0 that covers new functionalities, and thus you can have more time and better evaluation to obtain that version 2.0, which would be the future of twinbasic

It is a suggestion that I think may work better for everyone, since it does not blur current resources, it follows the main target to meet it and gives the best encouragement and the best experience to start the transformation of the product towards twinbasic 2.0

Thank you for trying this chimera and success in everything!

[mburns08109]

@WaynePhillipsEA
Since this conversation seems to be stagnating, can I ask you for your views on what's been said so far?

[bclothier]

Draft 3: Trying to incorporate what has came up in discussions (not just here but also other discussions/issues). I also think a different format might be more helpful in expressing the goals more clearly. Swapped the 5th point with 6th point because I think it flows better and corresponds more to how often we have to deal with the each point.

Again, discuss.

1. Backward compatibility trumps everything

twinBASIC was born out of the desire to provide an upgrade path for Visual Basic 6 and VBA. We fully believe that breaking compatibility, even to upgrade something that was working is always risky and nobody should be forced to rewrite software just to gain new features. As a consequence, twinBASIC will always remain fully compatible with VB6, VBA and future versions of twinBASIC. Any new features introduced must respect that.

2. Community is essential

Programming language is never just merely a language. A healthy programming language is one with a healthy ecosystem and to achieve this, we aim to make it easy as possible to share and contribute code and engage with other users.

3. Solving problems is the point

twinBASIC, like Visual Basic, is oriented toward helping the users focus on the business problem, rather than the implementation details. To that end, twinBASIC will try to provide good defaults and allow the user to work at the high level. However, the user is free to go lower where it is necessary for the solution.

4. Readable code is better than terse code

Because code is usually read more often, and will be read at different points, we want to encourage and promote writing readable code from the first-go. The ideal readable code is the one where the user achieves the same mental state as the writer had with minimal effort.

5. Transparency rocks

Code that says what it does is far preferable to clever hacks or implicit behaviors. twinBASIC will provide tools to help make implicit explicit and make it easy for users to see the actual behavior. Ideally, the users should never be astonished even if the code is originally gnarly.

6. Consistency matters

A consistent language is easier to learn and predict. Furthermore, consistent language makes sharing easier. To that end, twinBASIC will strive for maximum consistency in its syntax & features and make it easy for users to follow a coding style. However, readability takes priority over consistency.

7. One way is better than several ways

twinBASIC aims to push forward but in considering new features, we must take care to assess what already exists, whether there is a legitimate need that is not already met, whether it can be best done by tweaking existing features, and once exhausted, assess how new feature will fit in the overall language and provides a genuine new way that is clear and intuitive to the users. We want to minimize synonyms and different ways of saying the same thing unless it can be shown that readability and clarity will trump. By having only one way of doing, we also make the language easier to use, read and understand.

8. Refactoring and testing should be natural

twinBASIC exists expressly to support graceful upgrade of long-lived codebases without forcing a rewrite. Requirements may change but the users must be able to answer the questions on the impact and be able to make changes to the codebase without any fear of breaking the codebase or missing details. Testing should be easy and can be applied even to an existing project, which will in turn directly aid refactoring and proving that the software did not change in unexpected ways.

9. Documentation is important

In other languages, documentation is usually an afterthought. twinBASIC will make it easy as possible for users to write documentation and share it with other users.

10. Shipping will be tripping

twinBASIC will not come with runtime library, a virtual machine, a framework. It will come as it is to the end users' computer, in most compact form possible. It will not demand complex registration or installation process. xcopy deployment is the pinnacle.

[WaynePhillipsEA]

I'm pleased that I managed to get somehow close given that it is your baby!

You've done an incredible job of decoding my mind :) I'm not great with words, so I sincerely appreciate the effort that you and everyone contributing has put into this.

1. I think point 5 could have a sentence added about if compiler can't reason about code, neither can programmer (see Nim point 2). I want to add that because I think that is worth addressing what I perceive as a weak point WRT VBx code. I think there are more runtime errors and unexpected behaviors that could be better expressed as a compile error or at least a compiler warning. Is it important enough to include?

Yes, I think so. It almost feels like it should have its own bullet point.

2. Similarly, I find Nim point 6 interesting. None of the ten points address specifically the optimization, though the point 3 addresses the goal. I envision tB as primarily being a tool to produce solutions quickly without worrying about optimizations and delegating the optimization to the compiler. I further understand that because LLVM is on the roadmap, we will want to spend less time worrying about whether one form is faster than other form. I think it may be helpful for the community to be clear on the expectation on the optimization and who/what gets to do it as a general rule?

For me, it feels like point 3 already covers it, just not explicitly. If you feel that it needs to be mentioned explicitly, I'm fine with that.

3. There has been other comments about whether we need to say something about case-insensitivity and whether to disallow curly braces. The point 4 and 6 could be cited as an argument but indirectly. I want to be sure everyone's good with that or whether a more explicit language is warranted.

I would add a note to point 6 along the lines of 'The language syntax is case-insensitive. To reduce the developer burden on maintaining consistency, twinBASIC will aim to auto-correct text entered with incorrect case whenever possible'.

I am also in favour of disallowing curly braces, and the keyboard layout reason cited seems good justification. So, perhaps an extra note on point 4 'Proposed new language syntax should consider widely-used keyboard layouts, for example curly-braces are difficult to enter on Spanish keyboards and so should be avoided.'

4. Finally, do we need to address goals and design principles separately? Up to now, we've been treating them more or less interchangeably and I like keeping it simple because some of the points are more goal-oriented than other points which describes design principles so it kinds of kill two birds with one stone, but would know if others might have a different take on this.

If we need to, we could add a preamble, but I would keep the general list as it is now.

[mwolfe02]

10. Shipping will be tripping

I'm not sure what this specific phrase means. It feels like an idiom, slang, or reference that I'm not familiar with. Am I just missing something obvious here?

(By the way, I'm completely on board with the detailed description accompanying the point.)

[bclothier]

I may have overextended on that one 😄 - supposed to be a silly play on the word - tripping as in having an out of body experience.

[Greedquest]

Point 7

One way is better than several ways

I like python's wording better here

There should be one (and preferably only one) obvious way to do it

• It captures the one way Vs several distinction
• I think having an obvious way to do something is a better design goal than just having a way
• It provisions for there being an obvious approach Vs a less obvious but perhaps more performant or otherwise preferable approach*

*That said, we see clever workarounds too much in VBx, so maybe an addendum that "the obvious way should also be the best/fastest" would be helpful

---

Edit: I see above you mention adding the word "obvious" - sorry I didn't notice. This is a possible phrasing incorporating that at least.

[rexxitall]

That kind of stuff freebasic loves to add and for sure with a backdraft. (often they do that cause they are also to lazy to rewrite parts of the compiler - you has to write "forward" declarations for example. Pure fun if you fiddle on parameters...) The code with those hacks and "optimazions" will not run anymore in vb6 or vba. Peoples will get "used" to code in that style and the code basis will becomes more and more incompatible. If someones want it in that way he can already use .net, Freebasic, PureBasic and some other which makes BASIC mostly incompatible . If someones will have a use for coding like this they should use / write a preprocessor for their lazyness but the compiler should follow strict the VB6 syntax. If you want to "rob" the Freebasic eco system - no problem write a converter. Its way less powerful then VBA / VB6 so no big deal. If you try the opposite then you get gray hairs. BTW Ive done both. VBA to Freebasic and Freebasic to VBA. Last part was way more easy. And finally twinbasic can use and create COM Objects. If someones is in need he can write nice COM objects in .NET or whatever and mix the things together.

[FullValueRider]

It is indeed a marvellous achievement. There are also some other principles which I have stolen wholesale from the 'Zen of Nim'

https://nim-lang.org/blog/2021/11/15/zen-of-nim.html

1. Copying bad design is not good design.
2. If the compiler cannot reason about the code, neither can the programmer.
3. Don’t get in the programmer’s way.
4. Move work to compile-time: Programs are run more often than they are compiled.
5. Concise code is not in conflict with readability, it enables readability (i.e. Concise code is not cryptic code)
6. Optimization is specialization: When you need more speed, write custom code.
7. There should be one and only one programming language for everything. That language is twinBasic ;-}

[bclothier]

FYI - I love the find. Nim seems to have some similar goals that twinBASIC does (particularly in the area of shipping a compiled executable without requiring any framework, runtime libraries, or virtual machines).

I think the point number 2 is very valuable and address a IMO, huge shortcoming with the VBx compiler.

I find the point 6 to be quite interesting. IMPOV, optimization is hard and nobody should be in the business of optimizing as a general rule for two reasons: 1) premature optimization usually create more problems than it solves and 2) the compiler usually should be better at optimizing than programmer as a general rule. For general coding, we want to delegate as much as possible to the compiler and just worry about our problem (e.g. the point 4 in the draft 3 proposal). However, that point makes sense in Nim because they can write specialized operators and directly manage memory so they are in charge of optimizing their algorithms. In that perspective, I agree and I suspect we will have some problem domains that need to be addressed. For example, creating a generic collection library will require specialized code to optimize the use of such objects. I'm not sure yet how it will fit with the overall twinBASIC objective where the user should be able to work at a high level as the rule.

Again, great find! Thank you for sharing!

[dmrvb]

The bclothier 10 points are very good.
But, we must not tie our hands too tightly as nobody knows how tb will evolve in the future.
Back compatibility is important as a big tb market will be giving a lifeline to a lot of very old VB code, but one day this will be less important and moving tb forwards will become more important.
(I also doubt that Wayne will get 100% compatibility when he gets into the GUI side, I will settle for 99)

Point 7 "One Way" is good but it should be one obvious or preferred way, advanced users trying to get maximum performance should still have the option to do things in a more complicated way?

[bclothier]

While we may not know how tB will evolve specifically in the future, the evolution should at least follow a general trajectory so that twinBASIC stays "BASIC" and not end up being a clone. I've seen some BASIC variants and it's not pretty. One particular variant seems to me a bastard child inheriting the worst features from BASIC and worst features from C, resulting in a horrid language. The principles should at least prevent that.

Yes, the point 7 should mention something about the one way being obvious. We do want to avoid creating synonyms where we have 2 different ways of doing exactly the same thing. If there's going to be synonym, it's because of other overriding principles (e.g. improving readability as an example) but the less synonyms we have, the better. That should not mean it will restrict the expressiveness of the language, however. The users will be able to do what they need to do (c.f. point 4).

[EduardoVB]

Another possible principle, that IDK if it worth being explicitly set, is to remain case-insensitive.

[Greedquest]

This hasn't been explicitly mentioned (or maybe it has, but there are a lot of comments here!), but I think the purpose of these guidelines should be made a bit more clear. Based on posts in this discussion, I think the general sentiment is something like this:

When a decision has to be made between multiple conflicting approaches to solving a problem, an objective measure is always best - some data proving one solution is better than the others. However sometimes there is no objective way of approaching the decision, or the data is not convincing, or would be too slow to collect and lead to stagnation - at which point the decision becomes subjective.

In order to resolve debates where multiple conflicting approaches are objectively equal and the decision is purely subjective, the design guidelines provide an authoritative reference for making this subjective decision for you.

• The design guidelines are not rules and should always be phrased as "you SHOULD do x" rather than "you MUST do x". *
• The design guidelines should be chosen as the decision which best aligns with twinBASIC's goals / vision / guiding purpose and principles (TBD).
• If multiple design guidelines are in conflict then the higher priority one should be preferred.
• If an issue arises where these design guidelines are considered incorrect or insufficient, then a new issue should be raised to discuss amending the guidelines rather than continuing the discussion on that issue without any guidelines.
  • If that new issue finds the guidelines should be changed, then the original issue can be resolved under the new guidelines. If however the guidelines are found to be sufficient, then the original issue can be resolved according to the community consensus following the review.

*_{More formally we could add a preface (copied from semver.org): The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119}

That's the feeling I have about how these new design guidelines should be selected and used. The good thing is, if someone disagrees with the guidelines, then rather than having lengthy discussion in the comments of the original post that triggered the disagreement, they can insead ask a side-discussion about whether the guidelines can be changed. This is similar to how on Stack Overflow your question can be closed according to some pre-defined hopefully objective rules then subjective guidelines/ gut instinct - but as the question author you still have an opportunity to go on meta stack overflow to hash out interpretation of the guidelines or whether new guidelines need to be added.

Open to different thoughts on what these guidelines are for and how they should be used (or better wording).

[bclothier]

You make a good point about making a distinction between the goals and design principles. I think up to now, it was considered interchangeably; some of the documents that was cited seems to do the same. In many ways, the design principle is a reflection as well as the result of the goals of the language, which may be why it's considered interchangeably. If others think it should be separated, that's cool by me as long it remains consistent overall.

[mburns08109]

At the risk of sounding like a broken record on this one word and thought, I feel the need to share the following:

Haley Littleton shared in an op-ed entitled An Ode to being a Beginner (found here: https://www.rei.com/blog/hike/ode-to-beginner - but I'm going to quote some parts in case of link decay, so bear with me, please...)

"My freshman year of college, a boy with floppy hair down the hall convinced me to buy a cheap snowboard off of Craigslist, promising he would teach me how to shred. After one of the most painful days on snow of my life (I grew up skiing), I threw the board with a huff into the Goodwill pile and fumed at myself for failing after just one attempt.

I went back to skiing because I knew I would succeed.

Throughout a lifetime of [...] endeavors, many [...] partners have confronted me about being too hard on myself after only a few attempts at a new skill. Oftentimes, it seems less risky to quit rather than visibly fail.
[...]
"Don’t go if you’re going to show weakness" is the mantra that often runs through my head. Perhaps it is the fear that my incompetence will be “outed,” and I will be ridiculed. Often, it can be the simplest overheard snippet from a critic. Am I really cut out for all of this? It’s the tiny question that lurks in the back of our heads: Will I be good enough? What happens if not?"

The op-ed goes on to other topics, but those are the salient passages for us to consider here.

My central point is that this BASIC programming language was born with the purpose of serving a class of people called students and taking on the task of being an approachable tool to allow them to grasp the concepts of becoming a programmer before moving on to more advanced and esoteric concepts and toolsets in the - now seriously broadened - IT landscape as it existed back when it was first designed and created. The designers found a PEOPLE-BASED need for this kind of tool.

My personal mantra here, is that this is now a heritage for the BASIC language, and we CAN NOT loose sight of that.
It is such an important idea that I can but point to the human psychology Haley reveals in the snippets above.

We never want twinBASIC to become something that beginners will look at, and think "I can't understand this stuff" because we've allowed our evolved lust for "doing more new things" to overcome this fundamental purposes for the language. If we don't consider this as a fundamental purpose of this language (it definitely deserves a place in your 10 main points - not "implied" anywhere, but boldly and clearly stated), then we run a serious risk of allowing future work to destroy this approachability and this is the language's very essential HUMAN purpose.

One final thought on the proper perspective here is that BASIC was created in the 1970s for this purpose.
Microsoft evolved that into Visual Basic in the late 80s and early '90s.
Since then, we've had no less than 2-3 brand new generations of people enter into the world, and lots of them used BASIC as their first stepping stone into IT careers. TwinBASIC needs to continue this heritage as one if its firmest goals and design principles, so that late-comers and future generations of people will still have an approachable, yet powerful tool to turn to for starting their walk into the world of the IT-literate.

Otherwise, the lure to incorporate that newest, latest, shiny bauble of an idea/fad will eventually turn this language into the mess that C# is becoming and beginners will wind up throwing TwinBASIC onto the Goodwill heap too (and I'd really hate to see that).

OK, I'll make this my last post on this point.

[bclothier]

I want to point to the earlier discussion that I think one major difference tB will have is that it has to be self-contained. VB6 and VBA were easy to use and simple because they were basically in a walled garden nurtured by C++ developers from the outside. For the long term success of tB, it will need to be able to nurture its own ecosystem, which necessitates removing that wall in order to work with some low level details so that tB can be used to solve problems that wasn't otherwise solvable in pure VBx. In that same discussion, there seem to be a consensus that removing the arbitrary limits is good, it should be done in a way that beginners are not forced to climb a cliff just to use tB. It should be a gently sloping hill with no fences.

So, the point 3 in the draft 3 is supposed to address this aspect (and maybe also indirectly by the point 2). However, if that is a concern, we can:

1. reword either point 2 and point 3 to make it more explicit this aspect
2. reorder the points -- maybe swap the point 3 with point 2 to give it a higher precedence
3. add a new point. There's no rule that it has to be 10 points.

or some combination. Let's make it actionable.

[mburns08109]

IMO, it needs to be a separate point - and right up there amongst points 2 and 3 in terms of priority.
I like the gently sloping hill analogy.

How about something like: We must recognize and honor the historical intent of the original BASIC language as an instructional tool for those new to the world of programming, and commit to maintaining that heritage while also acknowledging the need to enhance the language for more modern programming styles and concepts. BASIC was intended for Beginners, and twinBasic must not only remember and maintain that heritage, but build upon it so that future generations of people new to the world of programming find it approachable and readily understandable both in syntax and form. There should be a gentle slope from the early beginnings to the more advanced as new concepts and capabilities are added over time.

[mansellan]

One of the great things about VBx was that it revealed its complexity slowly. Start by looking at what the macro recorder wrote for you. Try changing it around a little. Explore what the intellisense revealed. Discover the object browser and see how things are organised. Read / ask some questions on stack overflow...

I imagine that there's a big group of VBA users who have never understood what a class module is, and they are perfectly happy. It's easy to get valuable results from VBx even if you only learn a subset of the functionality. That's its killer feature.

At the same time, there are code snippets out there to do very low level stuff. Arcane API declares, even inline assembly. If a beginner finds these to solve some problem they're facing, it's incomprehensible. At best it will be some magic they can copy and paste into their Excel file. At worst, they'll recoil in horror.

VB has always been like this. Very approachable, but very powerful. And thus with a very wide range of example code.

[vbBaka]

if you follow my full-on discussion earlier, I think bclothier, the others and me finally found a good ground where I felt that TB will follow the VB6/VBA preservation while also build on top of it more features without affecting the core syntax in a negative way. and Im not easily convinced and Im also a fanatic when its about VB6 and its language. if I could be convinced I think we are in a good spot. but that doesn't means I will not start arguing if I see something that will damage that line.

[mwolfe02]

When @bclothier first opened this discussion, I had thought about suggesting something like the following:

Easy to learn, but with no artificial limits.

The idea is that the language should very much be approachable to beginning programmers, but it should not put child safety locks on all the cabinets that hold the useful (but potentially harmful) chemicals.

I think to Ben's point about nurturing the ecosystem of tB, there definitely needs to be support for very advanced tB developers to be able to build the tools necessary for the rest of us to not have to think about some of those more advanced concepts. I'm thinking about implementing high-performing data structures, for example.

With the recent introduction of the twinBASIC package manager, this further cements the need for allowing some small subset of tB developers to be able to do very low level things within the language. However, the new tB developer should not have to worry about those things. In fact, most tB developers should be able to make a full career producing useful software without those low-level tools. But they absolutely should be there!

What we want to avoid is the C# approach of introducing some new syntax every couple of years that is intended to make things easier for new developers by removing some small bit of boilerplate. That approach has the exact opposite effect. Now, when a new C# user searches for how to do something, they get half a dozen different articles on the Best Way™ to do that. And--here's the kicker--each article was correct at the time it was written.

The problem is that the Best Way™ to do things keeps changing all the time in C#. And that is what we really need to avoid in twinBASIC.

[FullValueRider]

This comment was prompted by recalling something I saw in a StackOverflow question a few days ago.
In a similar vein to @mburns08109 I would like to depreciate arguments based on 'intuitiveness'. As an example I saw on SO a couple of days ago was.

Dim myArray = Array(220 to 300 step 1)

An entirely intuitive application of syntax, but totally totally wrong.

Both 'common sense' and 'intuitiveness' reply on the application of knowledge already gained (whether we realise it or not). What we should be referring to in twinBasic is the presence or lack of predictability or orthogonality, i.e. the language behaves the same way in similar situations.

Obvious orthogonality in VBA is that arrays and collection object can be enumerated using 'for each'

Obvious non orthogonalities in VBA are

• myArray1 is myArray2
• For x = 1 to 10 but not mySubstring=myString(1 To 10) or mySlice = myArray(4 To 15) or mySlicedCollection = myCollection( 4 To 15)
• For X = 1 to 10 but not For x in 1 to 10
• For each x in myCollection but not For each myChar in myString
• VBA.Vartype(x) vs x TypeOf y

However, I am also reminded of an old joke that I think is very applicable to where @WaynePhillipsEA finds himself with twinBasic. Apologies for the sterotypes

An American driving around Southern Ireland stops in a very rural village in the back of beyond and asks a local villager for the way to Dublin.
The local replies "To be sure.  If I wanted to go to Dublin, I wouldn't start from here!"

Cheers

[mburns08109]

@FullValueRider Hey, my first comment was actually serious (and you're talking to someone who actually remembers the '70s - I was still rather young in the '60s) - I seriously don't grok that definition of orthogonal one tiny bit. Care to try and educate me? (serious question)

Now the second comment - yeah, I was being frivolous. sue me. I seriously haven't run across anything involving EBCDIC in over 20 years, so I just reacted off the cuff.

[wqweto]

Orthogonal features (or language constructs) mean that no two features overlap (don't point in the same direction) and these allow to be easily combined to achieve another new (unique) feature.

Imagine this as two vectors in 2D - x and y. If these are not congruent/parallel you can address/decomponse every vector in the same plain with something like Ax + By. If x and y are orthogonal/perpendicular you can reason about A and B independently i.e. using A to move along x direction only (as it has no part in y direction).

Orthogonal features also means that there is only one way to implement certain task as no features overlap in direction i.e. to read a file you don't have Open statement, Scripting.FileSystemObject and ADODB.Stream and then wondering which one to use.

[mburns08109]

Ah! Now THAT makes much more sense (than that other definition)! Thank You wqweto!

[uwbwsvd]

I don't know if my comment is right here. Most of the things that are discussed here are "Bohemian villages" for me. It penetrates into worlds that I have never seen before. My level: I have made an exe with TwinBasic that calls Excel, inserts two sheets, sets a title and formats the first line in bold. Booaa what?
But I enjoy using this. I want VBA without Office. Thats it.

[bclothier]

Thanks for sharing! I absolutely think that's exactly what twinBASIC should help you achieve; it would be silly to make twinBASIC a language just for programmers - it's not like we have any shortage of programming languages to work with! 😄

That said, making it work especially for non-programmers (which probably consist of a huge majority of VBA users) should be pretty important and the other goals should be in the service of that. After all that's why it's the point 3 (solving problems is the point). It's only number 3 because the backward compatibility (the point 1) is essential to bring on both VB6 and VBA users, and the community (point 2) is needed to provide new users with a ecosystem where they can get support and help to achieve, which brings us to the point 3. If you think it can be better, feel free to post a suggested revision.

[mburns08109]

So Ben,

Is it time for your next version of the main points on this topic yet?

[bclothier]

Thanks for the reminder. Will review and write something up shrotly.

[mburns08109]

ping.

[bclothier]

Just to note that I've had a draft for last few days but hadn't gotten to a point where it's an improvement over the draft 3. Sorry for the delay. Hopefully, I'll get to it this weekend.

[JBEJBE]

Hi,

lots of very good ideas and vast professional talent. But the mission is already formulated:

• implement a convincing 64-bit version of classic VB
• import and change existing code/projects with all artifacts error free in a modern IDE (see PyCharm, Visual Studio 2022 as inspirations)
• compile to 32/64-bit and (hopefully) earn money with TwinBasic related software to recover license fees

Please follow this path to success. This alone will take months of hard work. I'm convinced, Wayne will achieve these goals.

Only after settling on this "classic" code base, we should phantasize on the future evolution of the language. Guiding priciples are like company mission statements. They look good on paper, but what really counts (for me) is the time/resources to implement from initial idea to professional polished software.

So these could be future guiding language design principles for my taste:

• eanbling us programmers to write commercial software in the least amount of time, with minimum resources
• giving us the best tools available (IDE, GUI-Editor, Automations, Code-Generators, Tools, ... )
• maintain the classic character of VB, mix carefully with modern elements (immediate guis, web development, ...)
• get to know your user base with surveys and serve their main language needs (isolated commitees tend to loose base focus)

Just a few ideas ...

[mburns08109]

@bclothier

Just to note that I've had a draft for last few days but hadn't gotten to a point where it's an improvement over the draft 3. Sorry for the delay. Hopefully, I'll get to it this weekend.

ping

[bclothier]

To be honest, last time I worked on this, I had trouble improving over the last draft; any changes ended up being worse. I'll try again but I do encourage others to put in their 2¢ or to decide if it's good to be the final.

[Greedquest]

Fair enough bclothier. Is this https://github.com/twinbasic/twinbasic/discussions/610#discussioncomment-1959505 draft 3 the latest? There seem to be some good suggestions in the comments on it for anyone wanting to make some modifications. I think it's not quite perfect yet, in terms of practicality/applicability rather than sentiment, but I'll try and put that feeling into writing.

[bclothier]

Yes. It is. I welcome any suggestions to make it better. I'm aware there were feedbacks but I did have trouble incorporating because my attempts ended up watering down rather than strengthening it.

[mburns08109]

Ok, I reworded a few things just a tad, and added back the Beginners

Draft 4:
Again, discuss.

1. Backward compatibility trumps everything
   twinBASIC was born out of the desire to provide an upgrade path for Visual Basic 6 and VBA. We fully believe that breaking compatibility, even to upgrade something that was working is always risky and nobody should be forced to rewrite software just to gain new features. As a consequence, twinBASIC will always remain fully compatible with VB6, VBA and future versions of twinBASIC. Any new features introduced must respect that.

2. Community is essential
   Programming language is never just merely a language. A healthy programming language is one with a healthy ecosystem and to achieve this, we aim to make it easy as possible to share and contribute code and engage with other users.

3. Solving problems is the point
   twinBASIC, like Visual Basic, is oriented toward helping the users focus on the business problem, rather than the implementation details. To that end, twinBASIC will try to provide good defaults and allow the user to work at the high level. However, the user is free to go lower where it is necessary for the solution.

4. The B in Basic stands for Beginners, still
   We recognize the historical intent of the original BASIC language as an instructional tool for those new to the world of programming and commit to maintaining that important heritage while also acknowledging the need to enhance the language for more modern technologies and concepts. BASIC was originally intended as a tool for Beginners to learn with, and twinBasic must not only remember and maintain that heritage but also build upon it so that future generations of people new to the world of programming find it welcoming. There should be an approachably sloped learning curve from the early beginnings to the more advanced techniques when new concepts and capabilities are added over time.

5. Readable code is better than terse code
   Because code is usually read more often, and will be read at different points, we want to encourage and promote writing readable code from the start. The ideal readable code is the one where the user achieves the same mental state as the writer had with minimal effort.

6. Transparency rocks
   Code that says what it does is far preferable to clever hacks or implicit behaviors. twinBASIC will provide tools to help make implicit explicit and make it easy for users to see the actual behavior. Ideally, the users should never be astonished even if the code is originally gnarly.

7. Consistency matters
   A consistent language is easier to learn and predict. Furthermore, consistent language makes sharing easier. To that end, twinBASIC will strive for maximum consistency in its syntax & features and make it easy for users to follow a coding style. However, readability takes priority over consistency.

8. Fewer ways are better than many ways
   twinBASIC aims to push forward but in considering new features, we must take care to assess what already exists, whether there is a legitimate need that is not already met, whether it can be best done by tweaking existing features, and once exhausted, assess how new feature will fit in the overall language’s existing syntax and provides a genuine new way that is clear and as intuitive as possible to the users. We want to minimize synonyms and different ways of saying the same thing unless it can be shown that readability and clarity will trump. Having only one way of doing something where possible, we also make the language easier to use, read and understand.

9. Refactoring and testing should be natural
   twinBASIC exists expressly to support graceful upgrade of long-lived codebases without forcing a rewrite. Requirements may change but the users must be able to answer the questions on the impact and be able to make changes to the codebase without any fear of breaking the codebase or missing details. Testing should be easy and can be applied even to an existing project, which will in turn directly aid refactoring and proving that the software did not change in unexpected ways.

10. Documentation is important
    In other languages, documentation is usually an afterthought. twinBASIC will make it easy as possible for users to write documentation and share it with other users.

11. Pure and simple: YOUR Code
    Compiled twinBASIC code will not come with runtime library, a virtual machine, or some framework. It will come as it is to the end users' computer, in most compact form possible. It will not demand complex registration or installation process. XCopy deployment is the pinnacle.

[Greedquest]

@mansellan @WaynePhillipsEA Minor thing, why not just use a language-design tag for issues and discussions? Only that it's marginally easier to cross-reference within the same repo e.g. #123 links to that issue automatically. And I just anticipate lots of admin busywork closing issues here and redirecting people to the other repo (but that's not really my problem as much).

[mansellan]

@Greedquest my thinking there was that it's potentially a different audience. At the moment this repo is a mix of bug reports, feature requests, blue-sky thinking, and language proposals. By splitting out language design from more day-to-day activities, it should cut down noise for people who are just keen to use twinBASIC, as opposed to those who want to contemplate the intricacies of proposing new functionality in a non-breaking manner (which can get extremely technical!)

[Greedquest]

I reckon the beginner point could be better phrased as something like "new features should be respectful of the heritage of the language, although never at the expense of a sustainable future"

[mburns08109]

I have a rule in logic: "Never say "Never"!" <-- the one place where it's acceptable to use the word "never".

So how about "...although not at the expense of a sustainable future." ;-)

Though, that having been said, I'd counter that without new blood in the VB-programming world over time, making tB into "the greatest tool ever possible for software development" won't mean anything fairly soon after achieving that feat if nobody new can learn it fairly easily, too.

[Greedquest]

@mburns08109 I chose 'never' intentionally as I can't imagine a scenario where we would want to trade off the language lasting indefinitely against sticking to its roots. Which is I guess what you're saying; it would be very unsustainable to add complexity to the language, at the expense of attracting enough new users required to keep the language alive. So "never at the expense of a sustainable future" implies "keep it beginner friendly" since that is part of VBx/tB market niche (for the foreseeable future) and sustainable development by definition has to cater for that need.

It's downgrading from we must not compromise on sustainability to we should not. I'm a bit on the fence tbh, I see your logic that you don't want to paint yourself into a corner but equally I'd say you also don't want to allow borderline cases to slip through because the guideline is too lenient. In some ways it's easier to downgrade the restriction if needed at a later date than have a lenient opinion and then trying to make it stricter.

[mansellan]

So this issue has now been moved to lang-design (thanks @WaynePhillipsEA !) I'd suggest that we should get the latest guidelines agreed and into the repo soon, and then lock this thread - it's huge!

Any changes that need to be made later can be opened as new issues, PR'd and reviewed in the normal way.

[EduardoVB]

A guiding principle that I just realized: Keep OS portability in mind. Don't add a function or feature that might be a piece of cake on Windows and a nightmare (or impossible) on another OS.

[WaynePhillipsEA]

That's a very good point, and definitely needs to be incorporated IMO

[mburns08109]

That's a very good point, and definitely needs to be incorporated IMO

I really HATE to be the one to push back on this thought, but I feel I must.

I think this goal may be fundamentally incompatible with the 100% VB6 backwards-compatibility requirement already agreed to. VB6 was never designed or intended to be cross-platform-capable.

Look at what stages MS had to go thru with .Net to implement a real cross-platform capability: Mono, then other steps now up to MAUI - and it took them well over a decade, nearly 2, of effort to get where they are now.

I think that there are under-the-covers gotchas (like the "\" -vs- "/" path separator stuff for one example) that will make this a MUCH more difficult-to-achieve goal than some of us imagine now (the timezone stuff may be another good example - if only because I know literally nothing about how Android/Apple/etc. platforms handle that issue - except for that fact that they MUST have some means of doing so).

I'm NOT saying to toss this thought, but I'm certainly saying that we have to fall back to KISS before we overstretch and overreach our grasp in this effort - lest we never manage to get to version 1.0 at all due to over-ambitiousness.

[WaynePhillipsEA]

There's no doubt that there will be issues in implementing all of the existing VBA/VBRUN/VB functionality across all platforms. In fact, I remember mentioning the obvious filesystem issues myself much earlier in the project, where I suggested we might have to not offer the whole VBA.FileSystem module and other associated language constructs on non-Windows platforms, at least initially.

But the point remains that, going forward, we don't want to make things even harder by introducing things into the core/built-in libraries that would be obviously difficult or impossible to offer across the platforms we are planning to support in the near future. I think that's a fair point that needs including in the guiding principles.

[mburns08109]

I think that's a fair point that needs including in the guiding principles.

So:
12) When contemplating adding features to the tB language, due care is needed to assure that needless complications to future cross-platform capabilities is not compromised. (ok, that's poorly worded on first review, but gets the idea across for discussion purposes.)

...but that begs the question: given that there may be five different target platform environments, and in 4 of them a particular capability is easily implemented, but in the 5th it is not, should we abandon the feature? I'm not sure that's all that wise an idea either.

[mburns08109]

...speaking of which...is there even any sort of COM-equivalent API on any non-windows OS's/platforms?

[mansellan]

Given the work that's gone into this, I think it's time to start drafting a document. I've opened a Pull Request to add a document to the repository (guiding-principals.md) to this repository, based on @mburns08109 latest draft.

For those not familiar with how Pull Requests work, here's a quick primer: https://www.youtube.com/watch?v=For9VtrQx58

tl;dr: you can select any line and add a comment for changes you'd like.