One year of Phoenix Forums!

[aurel]

ouch
I must agree with Steve ..that given code is not basic
Also i don't say that qbjs is bad ..it is good project for people who like browser
based programming ..i am one of them who don't like this way and i tend to avoid
browser based things.

[aurel]

yes ..unless i start learn JS ..heh
well of course it would be nice to have web version or js version of micro(A)js
my main point was who need such a thing ..or i am wrong ..maybe more people
like to use web or browser based programming languages ..i don't investigate this topic
but maybe you right Bill.

I kind of try to build tokenizer fist in qb64 ..but i am kind of lazy
and translation from OxygenBasic is little bit tricky in some things
i will see

[Kernelpanic]

To get straight to the point, I've never dealt with Basic and JavaScript, but I can think of a few thoughts.

Why JS and not VisuelBasic Script, today, WSH(Windows Scripting Host)? It's probably included automatically, or you can download it.
WSH is object-oriented, and it's a form of Basic. So why you playing away when temptation is right in front of you?

I don't know if I've already posted this, but this is a very simple WSH program (it's been a while since I've made web pages with VBS or WSH). My first web scripting language was VisualBasic Script, and I still think it was better than JS. Is it really better than WSH today?


The program creates a folder under Windows and deletes it after 5 seconds without asking. Here H\:

Code: (Select All)

'Variablendeklaration erzwingen
Option Explicit

Dim Pfad, OrdnerAnzeigen
Dim fso, fo

'Ordner Beispiel erstellen
Pfad = "H:\TEMP\Beispiel"

'FileSystemObject erzeugen fuer Zugriff
Set fso = WScript.CreateObject("Scripting.FileSystemObject")

'Ordner erstellen
Set fo = fso.CreateFolder(Pfad)

'Neu erstellten Ordner anzeigen
OrdnerAnzeigen = fso.GetParentFolderName(Pfad)
Set fo = fso.GetFolder(OrdnerAnzeigen)

'5 Sekunden warten
WScript.Sleep 5000

'Ordner ohne Nachfrage loeschen
fso.DeleteFolder(Pfad)
WScript.Quit

'***Ende

[mnrvovrfc]

JS could be better for portability. In particular to FreeBSD, Haiku and other strange operating systems that support a web browser that could support JS.

That said, while I was checking out NomadBSD I should have checked out a few code examples on Firefox with QBJS...

[Ultraman]

The problem, for me, with QBJS is that it's more JavaScript than it is BASIC.

Dim result As Object   <-- What type is an Object?  It's not one from BASIC

result = Fetch(...)  <-- What command is Fetch?  It's not one from BASIC

IF result.ok THEN  <-- Apparently result is a type with a subtype in it?  Again, this isn't from BASIC..

obj = JSON.parse(...)  <-- Another not BASIC

SUB say  <-- The contents here are 100% Javascript; not BASIC

I can't see how you'd have a problem with non-BASIC things being added, considering we have a plethora of underscore commands which were not used in BASIC. Not to mention MEM, which is an object of sorts, that also did not exist in BASIC.

[bplus]

Funny how we go from a celebratory post to whining.

[SMcNeill]

I can't see how you'd have a problem with non-BASIC things being added, considering we have a plethora of underscore commands which were not used in BASIC. Not to mention MEM, which is an object of sorts, that also did not exist in BASIC.

I guess it's all a matter of perspective. To me, the underscore commands ARE part of our language -- just modern extensions to expand the old QB45 capabilities (let's be honest, who the heck would want to make games and such at 320x200 screen resolution anymore??) -- and they're something that evolved organically over the last 20 years of development of QB64. Since I knew QB45, I had a starting point into the language here, and then I could slowly learn and incorporate the new stuff as I needed it.

On the other hand, I see QBJS as a new language that is working from the very beginning with a premise of *combining* QB-commands and JavaScript, meaning that to use it properly, someone would have to have a basic understanding of both languages. For me, I'd have to learn *both* the BASIC-base *and* the QBJS-base, before I could make use of it. It's just not something I'm personally interested in learning and doing. As I've mentioned previously, I have several PCs which are off-line and don't even have a browser installed on them, making QBJS *not* the proper tool to use with them.

And kindly don't get me wrong: I have *nothing* against QBJS. In fact, I'm quite impressed at what dbox has managed to create and maintain, and I'm looking forward to see it grow and develop in the future. That's why we have a subforum here for it, and why I dedicated part of our server space when vince asked, so that a set of forums could be set up and dedicated to QBJS fully: https://qb64phoenix.com/qbjs/

QBJS just isn't a tool that I need for myself, but I'd encourage anyone else who's interested to give it a try and see if it'd be useful for them. For me, personally, I need portable EXEs which I can move from one machine to another, and QB64 gives me that, while QBJS gives the flexibility of moving from browser to browser.

The biggest problem I see with QBJS is the same style problem as I see with development for Linux -- it's impossible to test for all the different user bases out there. There's one simple reason why I tend to code exclusively with Windows in mind for my personal needs -- things tend to just work. An EXE on my PC will run on my Laptop, my neighbor's Windows machine, my cousin's windows machine, and my Aunt Sally's Windows machine. On Linux, that's not always true at all, as Mint might not run while Ubuntu will, and Archlinux is always questionable, with questions about KDE vs Gnome vs rootbeer vs limes.... Too many individual configurations and components which might -- or might not -- be supported, making it hard to actually say, "This works on Linux." QBJS has that same difficulty in development -- too many browsers out on the market which people are using which might, or might not, support any given feature. dbox, like us, tests and tries to make things as universal as possible, but no matter how hard you try, there's going to be folks who won't be able to make things work.

For me, personally, a Windows EXE file is what I need, and for that, I'm thankful for QB64PE -- but I'm also thankful that folks have choices so they can choose what suits their needs the most. A metric socket isn't much use on an imperial nut.

[mnrvovrfc]

Some of you have to update your files about Arch Linux and descendants. Because it's getting more stable, and especially with Wine, better compatible with Windows programs than Debian-based right now. I would never recommend Debian for anything for somebody who needs to run decade-2000 developed software. Especially not games, with the heavy reliance on "winetricks" because lately the guys at Arch Linux aren't even updating it. As the Debian devs move into "Bookworm" they broke a lot of stuff because compatibility with Windows is not their priority. In fact, it's not the priority of any Linux distro makers, but somehow Arch could get it right largely because they revise Wine "staging". Debian goes with "repacks" on the last "stable" version of Wine.

It's not perfect. Many Windows programs prefer Windows. It's frustrating when working with a music plug-in and the stupid thing refuses to show the GUI which is essential in knowing what has to be done and what to adjust. The app could throw an exception instead attempting to load one of its modules. It's frustrating as well having to buy an expensive music-creation application to see if the support in a strange operating system is good enough. "Just get REAPER, now there's a native Linux version of it!" When I purchased my license for REAPER, it was at v2 and there was no Linux version, had to use the Windows version through Wine. It has worked out pretty good for me so far on Fedora 36 MATE and Spiral Linux KDE. I had the license through v3 but I'm probably not going to load that any longer -- there is no need. Since then they raised the price of the non-commercial license, making sure I'm not interested in buying any longer. I could barely afford my Internet connection.

There is another problem with using the Linux version of REAPER. Just like Ardour, MusE and any other Linux app, the user is stuck using plug-ins for Linux! Cannot use the plethora of Windows VST plug-ins, and Wine cannot help there. Although half of them are buggy and ordinary with the sound, but why I cannot just use it? Now there's this Yabridge which is nice but without Wine it's not appealing to me. Before that I had to deal with Carla being buggy as hell, cooperated only in a 64-bit-only operating system where I couldn't install Wine.

I'll bet that if it weren't so doggone difficult to get "multilib" on 64-bit Slackware, even that implementation of Wine would be better than Debian's.

Also there's the urgency to move up from X-dot-org to Wayland visually, and from Pulseaudio to Pipewire with sound, making things a lot more complicated. Soon we will not be able to use our 10+ year old PC's anymore with a few Linux distros. Go into BlendOS download page and they tell you that you need a "modern" computer to work with the live ISO because they boast the latest GNOME v44 with all its memory-hogging tendencies.

This is for some of you who believe I defend Linux more than Windows. I would still have been on WindowsXP 32-bit if only one of the two Toshiba laptops I had, never failed me and I didn't have to throw them away. I would have never gotten past 32-bit Ubuntu Studio with my Linux experience and given a hoot anyhow about 64-bit. I wouldn't have been here talking to you about a 64-bit programming system.

[mnrvovrfc]

Dim result As Object   <-- What type is an Object?  It's not one from BASIC

This is possible in OpenOffice.org/Libreoffice BASIC. Last I checked was OpenOffice.org Writer v3 long ago LOL.

[bobalooie]

I'll bet that if it weren't so doggone difficult to get "multilib" on 64-bit Slackware, even that implementation of Wine would be better than Debian's.

Slackware is definitely an old-school distro; installing multilib was an adventure.