Where should we get ideas?

[mansellan]

Visual Basic is a phenomenon. It sparked a whole industry, and led to VBA, perhaps the most widely used shadow-tech of all time. There are billions (trillions?) of lines of code out there. That's pretty stunning, despite all the haters on the internet. Microsoft abandoned it for VB.Net, which was an entirely different thing, with a much steeper learning curve. And now they've even abandoned that. Awesome.

twinBASIC should strive to be better. It should always be backwards-compatible, and as it expands it should never forget its roots. It's fundamentally BASIC, and should always be approachable, readable, and user-friendly.

That said, Visual Basic was abandoned by its creator over 20 years ago. That means it's missed out on the last 20 years of language design. No overloads, no generics, no delegates...

twinBASIC has an opportunity to make up for the lost time. But that poses questions - should we use mixins or extension methods? How best to implement generics? Can we do lambdas without descending into syntax hell?

I would love it if we could discuss modernisation purely on its merits, and with reference to the Language Guidelines. It shouldn't matter whether an idea came from .Net, Java, Python, Ruby, or LanguageX The question should be: does this idea make BASIC better, and if so: how can we integrate it most empathically?

[bclothier]

Let's first talk about what makes tB (and by extension VBx different).

I would argue that the success of VBx was because you could see the result of your handiwork pretty quickly. You could do:

MsgBox "Hello, World!"

and you got a nice little messagebox whereas in most languages, you just got a console output.

Quick, who has written their first C++ GUI program in 5 minutes or less on their first day learning C++?

Erm, right. So, I think it's fair to say that VBx is pretty much GUI-centric and allows you to work at high level without getting into the business of chasing pointers like a herd of cats. But unlike more modern languages that have GUI frameworks, it definitely doesn't work on a "everything's a class!" paradigm.

For that reason, I'm more likely to compare tB to Rust, C#, and Python in this area. I like what I see in those 3 languages and can see tB benefiting from the ideas in those 3 languages.

For GUI, I'll be frank and admit that none of any current GUI framework thrills me. See my previous rants here and here. As such, I'm mainly interested in extending the GUI capabilities from what we have with VBx/Access, especially in the area of data-binding (where is the biggest pain point --- see Mathieu's rants here, here, and here. The current paradigm in VBx unfortunately thwarts the ability to make testable code and that's an area I think we can do better. But we certainly won't achieve this by bringing in the XAML/WPF, HTML/CSS/JS, nor Xaramin. Those hide the shortcomings with more complexity and more lines of code. Awesome. No thanks. I think we can do better in the GUI area.

[Greedquest]

My first intro to VBA was actually worksheet functions (UDFs) for Excel. Then it was automating the recalculation event in Excel to make an animated workbook (but doing all the heavy lifting of user interface and backend calculations in the spreadsheet, VBA just taped it together). Then it was finding out VBA worked in SOLIDWORKS too. My point is, tight integration with the host app has always been the key draw for me. This is as @bclothier says, very GUI-centric, very immediate feedback to the worksheet, but it took me a long time to create a first userform.

[mansellan]

I sometimes feel reluctant to suggest an idea, purely because it came from somewhere "non-BASIC". On the fear that it will be decried as Not BASICy enough.

If I could please explain my background... I started programming BBC BASIC in school, around 1984. In the early 90's, I got an Amiga, and was mostly distracted playing games like Turrican II. I seem to recall doing some stuff with DBase to support my dad's shop's stock control, but that was about it.

Fast-forward to 1998. I got a job at JP Morgan. Ultra-boring data entry into a mainframe terminal emulator (Rumba). Typing the same kind of thing, over, and over, and over, and... then I discovered that Rumba had a macro language, and could take screen variables. WIN! I could automate the boring bits, and just enter the small variances into dialog boxes. I started doing 2x my colleague's input rates.

Around about this time, I was being asked for reports, so I started learning Excel. Borders, cell colours, groups... nice. But then I found the VBE, and I was transfixed. I started recording macros, and then dissecting them. Reading about best-practice on the early web. Printed out the entire F1 Help into 4 ring binders. After a while, I started feeding Excel sheets into Rumba using window-waits and SendKeys. Fun times. I started doing 10x my colleagues input rates. It didn't take me long to move in JPM.

After a short detour in Network Security (automated a bunch of their reports using Access VBA), I got my first "proper" programming job - supporting the banks Derivatives trading section. Started off by writing some VBA spreadsheets to automate mainframe inputs, then converted that to VB6, then had an amazing mentor then moved me to C#2. I've been a C# programmer ever since, but I got my first, second and third start with BASIC.

[mburns08109]

Can I give you a direct answer to that question?
I think we should take our ideas from wherever we find good ones that can fit into the BASIC paradigm.

One good one example of that may be from LISP: "Code is data is code." ...can be a very good idea, but it would be too "un-basic-y" to employ it for tB. So, wheil a "Good Idea(TM)" it won't fit (easily) into the "Basic-y" mold.

[rexxitall]

You need a interpreter for that lisp thing. ANd hopefully not as primitive ones a s lisp is :) There is a discussion how to implement eval(). Which goes in that direction already. In my opinion the piece of art is to keep the things BASIC alike. In this case it would be interpreting a string as basic code at runtime :) Which is usually done by ascript control or the evil eval() :)