possible programming challenge: a smart(er) IDE?

[madscijr]

(Disclaimer: this is more a thought experiment or topic of discussion than a hard proposal!)

One thing I have wanted to see for a while is an IDE that lets you enter your program in the language / syntax of your choice, stores the program, variable names, and comments, in some sort of universal format or intermediate language, and can "render" the source code in a different language or with different variable naming conventions, depending on the user's preference. Maybe there's a dropdown you use to select the language (e.g. QB64, Python, JavaScript, etc.) and as soon as you do, the editor immediately translates or renders the source code into whatever you choose. 

I know that this isn't necessarily as simple as it sounds where languages do not support the same features or paradigms - e.g. QB64 is statically typed and Python dynamically typed, QB is strictly procedural whereas Python can be OO or functional - but if a program sticks to the lowest common denominator of functions, or the IDE stores the maximum detail (e.g. explicit type declarations for QB which is stored under the hood, but ignored when using dynamically typed languages like Python & JavaScript) then perhaps it can work? 

Or we could take the simple route and just support the features all languages have in common (e.g. strictly procedural) so people who are more familiar
with C/JavaScript syntax can use that, people who like Python can use that, and us BASIC lovers can do that. 

Probably the biggest disconnect would be the static vs dynamic typing, so maybe the flavor of Python & JavaScript would be strongly typed (that is, instead of JavaScript we use TypeScript as the option, and is there a strongly typed compiled variant of Python? There would be now! LoL) 

Since QB64 uses a source-to-source interrim compiler to first compile to C and then compiles to machine code, perhaps that can be leveraged to multi-language support. Isn't Cython a Python to C compiler? 

Anyway, I just thought I would float the idea of a smart IDE that lets people work in whatever syntax they prefer. This would potentially increase the usefulness or the user base for QB64, or lead to a more universal platform for programming. 

I'm sure once artificial intelligence gets intelligent enough, and deep learning gets deep enough, that there can be IDEs capable of translating code on the fly between any language or even paradigm. I have to find the link again, but I have even found & used a Web-based AI tool that translated code between languages and it produced working Python code from the JavaScript examples I fed it. Perhaps we could simply have an IDE that calls that Web service with the advanced AI to do the heavy lifting of translating code? 

Anyway that's my thought for the day, which came out of another conversation we were having where Python came up... I figured I'd float the idea for discussion for y'all to shoot down or discuss, or as an idea for someone looking for a challenge! 


Cheers, and Happy Friday! :-D

[Ed Davis]

(Disclaimer: this is more a thought experiment or topic of discussion than a hard proposal!)

One thing I have wanted to see for a while is an IDE that lets you enter your program in the language / syntax of your choice, stores the program, variable names, and comments, in some sort of universal format or intermediate language, and can "render" the source code in a different language or with different variable naming conventions, depending on the user's preference. Maybe there's a dropdown you use to select the language (e.g. QB64, Python, JavaScript, etc.) and as soon as you do, the editor immediately translates or renders the source code into whatever you choose. 

I know that this isn't necessarily as simple as it sounds where languages do not support the same features or paradigms - e.g. QB64 is statically typed and Python dynamically typed, QB is strictly procedural whereas Python can be OO or functional - but if a program sticks to the lowest common denominator of functions, or the IDE stores the maximum detail (e.g. explicit type declarations for QB which is stored under the hood, but ignored when using dynamically typed languages like Python & JavaScript) then perhaps it can work? 

Or we could take the simple route and just support the features all languages have in common (e.g. strictly procedural) so people who are more familiar with C/JavaScript syntax can use that, people who like Python can use that, and us BASIC lovers can do that. 

...<snip>...

I really like this idea! And I agree with you, not easy to do.  As you surmised, lots of differences that don't translate easily.  But it is still a great idea!

For instance, I've written a "Tiny Basic" interpreter in various languages, trying to keep the code as similar as I could.  I've (re-)written it in QB64, Python, C, C++, C#, as well as various other Basic dialects: VB.NET, FreeBasic, GW-Basic, SmallBasic (the real one ), Yabasic and RCBasic.  While some things are very different, it is pretty interesting how many things are similar.  As the old saw goes, I can write Fortran in any language (Yes, Fortran was my first language, back in 1976 or so).

I'd also like to add converting QB64 to various other Basic dialects.

Also:  There was a user, STxAxTIC, - alas, he apparently ran afoul of the current powers-that-be - he had a neat scripting language called Sxript I think.  Anyway, he had a Basic program that would translate a subset of QB64 to C or Javascript, and perhaps vice versa. 
However, I could never get it to work, and was going to ask him about it, but now he is gone   Why can't we all just get along?

Again, I really like your idea, thanks for sharing it!

[mnrvovrfc]

It should be easier to do among OOP languages. Because after a programmer used C++ for long enough, he/she doesn't want to know about anything interpreted which doesn't let him/her do "classes" in a similar way. Notice some other languages like Haskell and Rust must go along with the OOP bit? Also this Terra that I discovered and failed to make use of which was supposed to expand on Lua.

One big barrier is lack of documentation, or "too much" and how it's presented. I tried to make any sense out of Rust but I guess I have to watch videos on Youtube for it. I don't drink that coffee, no thanks. The documentation for Racket (LISP descendant) is welcome although it's hard for me out of it to come up with my own program.

From QB64PE's brand of BASIC to C++ or another OOP language... nope too hard even for payware.

Try to do something simpler such as LISP to BASIC! Saying this because somewhere in the Racket documentation ("EasyDSLs") they claim that another programming language could be invented from it. I'm just trying to figure it out for text processing like I'm able to do in BASIC or Lua almost without thinking much about it. Imagine having to deal with the tokens? Imagine having to parse CSV full of commas and double-quotation marks, or anything that looks like XML?

---

There is a similar thing going on with a music program that I use extensibly, with one large crowd being left out. That crowd are the ones doing music in XM format, originally for Fasttracker II. An MPTM format is invented which is pretty much worthless because it was just derrived from Impulse Tracker's (IT). Tunings? Nobody really cares in "tracked" music. A couple of "expanded" commands are welcome, however those desiring to use XM format deserve it also. Almost forgot to mention an exception was made recently for yet another format, that of Scream Tracker (S3M), for the sake of the "OPL" synthesizer emulation which is related to the FM chip found on Soundblaster Pro. Can save either in S3M or in MPTM to retain settings from that synth emu. Not XM, and much less MOD (Amiga Protracker).

How about supporting "key off" and "envelope position" like in Fasttracker II (XM) to complete the suite? Then when somebody wants to use IT commands, as they are actually stored in MPTM at the moment, allow export to those for XM. Maybe I should create an account with their forum and make a feature request, eh?

https://openmpt.org/

Conversions were already done for documents saved with many programs no longer available. However, if the user wants to use VST plug-ins and XM format, he/she is forced to save in XM files that cannot be loaded into Fasttracker II nor MilkyTracker nor something else that recognizes only that original file format. Must save instead as MPTM because it's recommended. Must fumble with IT command letters instead of XM.

The task I've explained seems easier than one which turns BASIC into some other language from a text editor but it really isn't.

[SpriggsySpriggs]

One thing to consider would be libraries. Some things that are accomplished in Python require different libraries from what is used to achieve the same result in C/C++. Any sort of translator would have to be aware of these common libraries and know when to include them. That would be quite difficult as well.

[madscijr]

(Disclaimer: this is more a thought experiment or topic of discussion than a hard proposal!)

One thing I have wanted to see for a while is an IDE that lets you enter your program in the language / syntax of your choice, stores the program, variable names, and comments, in some sort of universal format or intermediate language, and can "render" the source code in a different language or with different variable naming conventions, depending on the user's preference. Maybe there's a dropdown you use to select the language (e.g. QB64, Python, JavaScript, etc.) and as soon as you do, the editor immediately translates or renders the source code into whatever you choose. 

I know that this isn't necessarily as simple as it sounds where languages do not support the same features or paradigms - e.g. QB64 is statically typed and Python dynamically typed, QB is strictly procedural whereas Python can be OO or functional - but if a program sticks to the lowest common denominator of functions, or the IDE stores the maximum detail (e.g. explicit type declarations for QB which is stored under the hood, but ignored when using dynamically typed languages like Python & JavaScript) then perhaps it can work? 

Or we could take the simple route and just support the features all languages have in common (e.g. strictly procedural) so people who are more familiar with C/JavaScript syntax can use that, people who like Python can use that, and us BASIC lovers can do that. 

...<snip>...

I really like this idea! And I agree with you, not easy to do.  As you surmised, lots of differences that don't translate easily.  But it is still a great idea!

For instance, I've written a "Tiny Basic" interpreter in various languages, trying to keep the code as similar as I could.  I've (re-)written it in QB64, Python, C, C++, C#, as well as various other Basic dialects: VB.NET, FreeBasic, GW-Basic, SmallBasic (the real one ), Yabasic and RCBasic.  While some things are very different, it is pretty interesting how many things are similar.  As the old saw goes, I can write Fortran in any language (Yes, Fortran was my first language, back in 1976 or so).

I'd also like to add converting QB64 to various other Basic dialects.

Also:  There was a user, STxAxTIC, - alas, he apparently ran afoul of the current powers-that-be - he had a neat scripting language called Sxript I think.  Anyway, he had a Basic program that would translate a subset of QB64 to C or Javascript, and perhaps vice versa. 
However, I could never get it to work, and was going to ask him about it, but now he is gone   Why can't we all just get along?

Again, I really like your idea, thanks for sharing it!

Why can't we all get along, indeed? 
I do miss the days when all of the QB64 world was under one roof 
(though so far this is the only roof I see?)

I remember STxAxTIC and vaguely recall their scripting language, I may have even downloaded it at some point! 

I think this is a worthwhile goal for the long run - it's not trivial, and will surely take many iterations to get working, but the first step is to discuss the problems, challenges, needs, upsides, downsides, and basically start figuring out how such an IDE might work!

[TerryRitchie]

One thing to consider would be libraries. Some things that are accomplished in Python require different libraries from what is used to achieve the same result in C/C++. Any sort of translator would have to be aware of these common libraries and know when to include them. That would be quite difficult as well.

That was the first thing that came to mind while reading through this thread. Python relies heavily on libraries.

And yes, I miss STxAxTIC's posts too. They were always very interesting. His knowledge of math was impressive.

[madscijr]

One thing to consider would be libraries. Some things that are accomplished in Python require different libraries from what is used to achieve the same result in C/C++. Any sort of translator would have to be aware of these common libraries and know when to include them. That would be quite difficult as well.

I think to begin with, we would just convert syntax for vanilla programs (ie nothing that relies on a binary library). It wouldn't be able to convert existing applications to a different language, so much as creating new programs, where users can choose what syntax to use (C, BASIC, Python, etc.) 
Maybe for now the libraries would be limited to whichever ones are available to the "primary" language (for example QB64). 

How to handle underlying libraries... hmm. 
Here's a question - how does Cython approach the whole library dependency question? 

Maybe to start, only support libraries that we actually have source code for? If they're binary libraries like PyGame, perhaps they would need to be recreated as a compilable program? I don't expect these problems to be solved overnight - this is something that will likely evolve little by little, library by library. 

If we are talking about OS m-level APIs or DLLs already on the machine, then they can be included however the given language includes them? I don't know enough about Python to know what command would be used to include a library or reference an API or DLL. 

The same with JavaScript, which lacks a lot of commands for desktop applications. Perhaps for languages lacking these kind of commands, we just create the equivalent to QB64, just done in the syntax of that language? e.g. No CLS or PRINT statement in JavaScript? Add it! No way to reference a COM DLL or declare an API function? Add it! 

The same with static variable definitions - we would expand certain languages like Python and JavaScript to add support. It would need to be done judiciously, or the work will never end. Start with the question, how do languages like cython or typescript approach adding features not in their parent languages? Can they be leveraged at all? Maybe we would get the code for the original library (e.g. numpy) and re-compile it or translate it to plain C to be part of our system? *** NOTE *** Take all this with a grain of salt - I'm just spinning my wheels, thinking out loud! LoL

Good questions though! Keep 'em coming! But at the same time, try to think of way(s) to solve these problems, not just give up.

[Pete]

I got a kick out of Bill, too. You know he had a theoretical degree in physics!

Since IDE's exist for other languages, I think a universal IDE would be a high work to reward ratio. I'm not sure anyone will want to jump on that grenade. Hey, where's Clippy?! (BOOM!)

Pete

[madscijr]

It should be easier to do among OOP languages.
...
The task I've explained seems easier than one which turns BASIC into some other language from a text editor but it really isn't.

I'm sure, just reading your description we can see how complicated it is!

I'm not sure how much easier or harder it would be for OOP languages, as a start I am focusing on a procedural language (since QB64 is not OOP) where we won't initially worry about dependence on libraries that only Python supports. You'd be able to program QB64 using Python or JavaScript syntax (minus the OO and other features those languages have that QB doesn't). And if you need to do something, you do it the QB64 way - unless someone (re)creates their favorite Python or JavaScript or (insert language/ecosystem here) library that runs under QB64.

But even without the libraries, programmers would now have the option to write QB64 programs using a SYNTAX that they may be more familiar with. Options!!

[madscijr]

One thing to consider would be libraries. Some things that are accomplished in Python require different libraries from what is used to achieve the same result in C/C++. Any sort of translator would have to be aware of these common libraries and know when to include them. That would be quite difficult as well.

That was the first thing that came to mind while reading through this thread. Python relies heavily on libraries.

And yes, I miss STxAxTIC's posts too. They were always very interesting. His knowledge of math was impressive.

Yeah, this initially would not be about porting over libraries, it would still be all done using QB64's ecosystem. If you want graphics and know pygame, too bad, you have to do it the QB64 way. BUT you get to do it in Python or JavaScript syntax. If you have to have the library, then recreate it natively. As a start anyway. (See my reply to Spriggsy for other ideas or followup questions related to this.)