QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: FellippeHeitor on June 23, 2019, 03:32:13 pm
-
https://mdhughes.tech/2019/06/23/fall-of-visual-basic-rise-of-quickbasic/ (https://mdhughes.tech/2019/06/23/fall-of-visual-basic-rise-of-quickbasic/)
-
Again, one that depreciates us?
-
I think it all depends on how you look at it. I focused on the positive words, which is why I decided to share it in the first place.
The one good thing from all this:
An innovative project called QB64 has created a modern QuickBASIC replica. It runs on Windows, MacOS, and Linux, with no emulator required.
This is a pretty credible BASIC environment.
There's a ton of sample code in program/samples, including a lot of 3D stuff.
Pro:
Structured BASIC, if you want it.
You can just recompile on every platform.
I guess that makes me a “glass is half full” person.
-
HI
Pro:
Structured BASIC, if you want it.
You can just recompile on every platform.
Con:
No interactive REPL (that was one of the few things classic line-oriented BASIC, or hybrids like ST BASIC, had going for them).
Slow compile.
Ugly editor, though probably playing with fonts and colors would improve this.
You'll always be better off just giving a newbie Python, but some people may have old code or nostalgia.
IMHO the glass is half full... but
in Pro he misses
1.the structure empowerment with OpenGl
2. and the new _Keywords
3. the open to external Library in DLL format
4. Inform RAD tool
5.vWatch Debugging tool
in Con
I stress Ugly editor. Why?
Do you like the vintage IDE on your desktop?
I know that the goal of Galleon was to make a windowed version of QBasic. And that goal is achieved so many times ago with this IDE that is in developing and growing in the time.
Is it possible that it appears cool to a new programmer? And to a young programmer?
So I can affirm that as in the developing of QB64 Galleon had taken different decisions about how to improve old QBasic to let it working better with new files ( for example: image and sound files) , or for managing mouse and other input dispositives, so together the old QBasic Keywords we can use the empowered _QB64Keywords! ( Some old keywords are not implemented but emulated to make safe and secure the programming in modern OSes) as He can decide to give an alternative for user to use a modern IDE (He should decide if one own QB64 Graphic IDE or like Dav's IDE or an integrated editor for example Notepad++) or the classical IDE.
For my personal use it is good so as is, but I'm an hobby programmer with old experience with QBasic and no commercial activities. So my goal is to play with BASIC and QB64 performs well this for me, but I have seen how can be strong to write BASIC with the right library to manage complex issue and make strong effective programs. So now is the goal of QB64 a vintage club of nostalgic programmers that knew QBasic or to be the new free BASIC compiler for programmers?
The young eyes of new programmers see different from my ones.
If I see for the first time the QB64IDE resembling old QBasic, I should think to words like nostalgia, old times, so time ago, but if I compile a simple code it runs so fast that I need to slow it.
Thanks Fellippe to launch the rock in the water, so the waves touche my brain.
Good Coding
-
what does he mean by 'Slow Compile' ?
and 'ugly editor'? looks as good as the old QB45 IDE.
-
This man has not mentioned much advantages of QB64 as compared to cons.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration
Is it true? I strongly disagree.
Ugly editor, though probably playing with fonts and colors would improve this.
Why not use Rho's Notepad++ Patch-up/DavIDE if he is not feeling comfortable with IDE?
Slow compile.
Really? For me, it takes about 10-20sec for the first compilation after downloading QB64 & after that it compiles the code in 3-6sec
-
Yeah, my compiles are pretty darn quick. 2 -4 secs most the time. Longest I've ever waited was about a 1 min and that was recompiling the QB64 IDE.
And the 'Brain damage' quote is from a guy that has been dead 17 years. So who knows when he made that remark!
-
Yeah, my compiles are pretty darn quick. 2 -4 secs most the time. Longest I've ever waited was about a 1 min and that was recompiling the QB64 IDE.
And the 'Brain damage' quote is from a guy that has been dead 17 years. So who knows when he made that remark!
Yes, the "brain damage" and other such complaints, best I can tell, may have to do with the earliest examples of Basic. Years ago, I used one dialect that had draconian restrictions of variable names, such as one letter and one number only, or required line numbers, limitations on IF statements, or other such. Maybe the programmer was more constrained to use GOTO statements, back then. But none of that applies to QuickBasic or certainly QB64.
For me, compilation time is only longish when I recompile qb64.exe. And even that is not excessive.
I've seen comparisons of QuickBasic and Python, comparing them with more obtuse languages such as C (which uses symbols such as brackets instead of clearer words). Python has the strange limitation where indentation really matters, as opposed to being just a nice little optional thing, for clarity to the human being looking at the code.
Anyway, my observation has been, I can hand my QB64 code to any "real programmer," and they always know exactly what the code is intended to do. And they make it work, in real world systems.
-
Again, one that depreciates us?
I have previously seen the verb "depreciates" used at this site transitively, and I thought that this was incorrect English. I thought that "depreciate" was an intransitive verb only, with the use as in "the value of this currency is depreciating". But my Chambers 20th-Century Dictionary gives it as a transitive verb as well, meaning "to lower the worth of" / "to disparage", as used here. Thank you, Petr, and thank you QB64: always an education!
-
As a working journalist, I found it quite positive and fairly balanced.
The QB45 IDE and its QB64 reincarnation are NOT -- say -- Visual Studio or similar.
If that's what you're expecting, then disappointment surely beckons.
Malcolm
-
I find this article... http://www.nicolasbize.com/blog/30-years-later-qbasic-is-still-the-best/ (http://www.nicolasbize.com/blog/30-years-later-qbasic-is-still-the-best/)
what would be happened if the author had had QB64?
-
@MWheatley
The QB45 IDE and its QB64 reincarnation are NOT -- say -- Visual Studio or similar
that is the point about I'm trying to talk here https://www.qb64.org/forum/index.php?topic=1454.msg106511#msg106511 (https://www.qb64.org/forum/index.php?topic=1454.msg106511#msg106511)
QB64 is not a reincarnation of QB45 and it is not a RAD development Studio like Visual Studio o similar suites!
this first affirmation QB64 is not a simple reincarnation of QB45
is clear because the goal of getting the QB45 IDE emulation and the possibility of running QBasic/QB code into windowed Oses is already got, apart the debugging emulation that is not possible until the code is compiled and not interpreted (in this QB64 resembles more TurboBasic).
moreover about the second part of affirmation are NOT -- say -- Visual Studio or similar
I don't think that the evolution of modular programming is a RAD IDE, that implies an event programming style, also if it can have a RAD tool among the tool of that IDE. So I think that the evolution of QB64 is not to become a RAD tool, but it is fine to have a RAD tool in set of tools of QB64.
Thanks for feedback
-
Hi, guys. Saw some site traffic, and I appreciate the feedback, but I was very terse in my post.
I was fairly positive about QB64; it has some flaws, but it does work and produce a standalone binary, that's a good accomplishment.
The ugly IDE: This is partly about looks, more about usability. And, I'm a Mac and UNIX developer. I don't know what the Windows world is like, but I did use DOS, mostly inside OS/2 back in the '90s.
A plain-text-only IDE is a little annoying these days, but not by itself a bad thing. But the color schemes are pretty garish, and the only replacement font isn't great. Multiple fonts and better font scaling, and a nicer UI for it (IDE Color has a nice panel, but Display is awful) would go a long ways. The thing I'd compare this with is Python's IDLE, which even though it's using the archaic Tk API, has nice system fonts, works like a native program; the color schemes are harder to change, but the defaults fit a modern OS better. Even Chipmunk BASIC has a native GUI window (which just shows a text prompt).
The system Edit menu isn't wired up, so it doesn't copy-paste on Cmd-C/X/V; I can use the IDE's Edit menu, Ctrl-C/X/V, but both ought to work. Clicking anywhere in the screen places the cursor there, not at the end of that line, which is the normal behavior. It'd be nice to have the menus instead become real Mac menus on Mac, Linux menus on Linux, etc.
The Mac (and many but not all Linux GUIs) normally use Emacs editing keys in all text areas. As an emulation of QB on DOS, maybe that's not the right thing, but it's extremely hard for a Mac nerd to type without them. Many desktop and laptop keyboards these days are "slim" and don't have Home/End, etc. except by some awkward Fn-key combo.
The default "untitled" program location being in the qb64 folder instead of the programs folder is unfortunate. And it ought to prompt to save on quit, and the Save As dialog weirdly doesn't show existing files, only the folders.
There's a lot of little stuff like that where it's not as pleasant as using IDLE or a good Scheme REPL in Terminal, let alone a focused editor like BBEdit or Atom. It could be run from the command line, but then you lose the IDE part.
The slow compiles: On first creating an app, it takes about 10-15 seconds. On recompile it's ~5 seconds for a very short program. It seems to only happen in IDE, shell is OK:
% time clang -o hello hello.c # just for comparison
clang -o hello hello.c 0.38s user 0.17s system 86% cpu 0.633 total
% time ./qb64 -c programs/hello.bas
./qb64 -c programs/hello.bas 1.74s user 0.23s system 95% cpu 2.076 total
The lack of REPL: That's a real killer for me. Being able to just type a line and see the result, whether that's in the "edit" window or a separate pane, is just fundamentally better than waiting for a compile. There are languages where the REPL is fast, like Julia and Chez Scheme; and in Python it's no slower than anything else.
I actually removed the EWD quote on BASIC shortly after posting because I'd used it in another post recently; he was making a number of joking points about computer science and the languages available. If you haven't read Dijkstra, I highly recommend doing so.
Anyway, there you go. I'll try to check back, or you can email me.
-
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration
Is it true? I strongly disagree.
Not only do I disagree about 'mutilation', I emphatically contend that making such a statement - even if the BASIC-exposed student does have subsequent problems learning good programming habits - says more about the teacher than about the student, and still more about the language-bigotry of the person making the statement.
-
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration
Is it true? I strongly disagree.
Not only do I disagree about 'mutilation', I emphatically contend that making such a statement - even if the BASIC-exposed student does have subsequent problems learning good programming habits - says more about the teacher than about the student, and still more about the language-bigotry of the person making the statement.
+1
That quote has been trolling Basic fans for years!
Get over it, everyone has moved on since that statement was originally made.
-
what does he mean by 'Slow Compile' ?
and 'ugly editor'? looks as good as the old QB45 IDE.
Opinions are like ASCII... Wait, how does that go again?
What he means by slow compile is he did a superficial job. The first time you compile a new program is a lot slower than subsequent compiles after edits, debugging, updating, etc. Rob stated he had found a way to speed up the process, after the initial file for compiled.
Superficial might also explain why he missed all the new bells and whistles.
Rob wanted to keep the old QBASIC feel, so he cloned the IDE, instead of making a more modern one, like Code::Blocks. Most newcomers couldn't possibly appreciate what they never grew up with.
Am I right? Well, you know what they say, opinions are like ASCII. Wait, how does that go again?
Pete
-
You might want to look a couple posts up where I address most of this, Pete.
"new bells and whistles"
Couldn't care less about that. I think BASIC's tolerable for retro-programming and teaching with classic BASIC books. So anything new is a hindrance. Can you draw graphics & make simple waveform sounds? Ship it.
"newcomers couldn't possibly appreciate what they never grew up with."
If you're going to attract new users, that's not a helpful attitude to have towards them.
It's especially inappropriate when applied to me. I started programming 11 years before QBasic came out. Some of the programming environments were as ugly as QB64 still is, some were quite nice (Atari ST BASIC in 1985…). And in the 30 years since, people have higher expectations.
-
Nevertheless
looking out Visual Basic in Windows and Gambas for Linux, what kind of BASIC has been developed and has spread in the age of windowed OSes?
-
Some thoughts...
The IDE is very customizable in regard to font-size, fonts, and color scheme. I immediately changed mine to LUCON with a 23 pixel size. I also got rid of most of the highlighting colors and number lines. The number of rows and columns can also be adjusted.
QB64 is 99% QuickBASIC compatible. There are just a few keywords that were not supported, like FN. So, if I wanted to give QB64 a bad fake news review, I'd just say something like... In QB64, you can't even make one FN statement that works! :D
Anyway, my point is if I read your review before trying QB64, I might not even bother to download it, and instead be off wasting my time on Chipmunk BASIC. Now that would be a shame.
About me and my programming experiences...
I started programming with punch cards in 1979, and hated it; but for some strange reason, possibly alien abduction, I bought a TI4a in 1981, and I was glad I did. Sure, it was a bitch trying to punch holes in the console, initially, but then I learned you could optionally type stuff on it! Wow, what an improvement over cards! I started learning BASIC by programming TV games, like Wheel of Fortune, Password, Card Sharks, and I was also able to write a 4K Monopoly program on the TI. I think that got me started on code optimization, which would be a necessity over the next 20 years. It recall I had a tape recorder for a drive. In 1984, I pitched that unit for an Atari 800. It had 64-bit with a real floppy drive. I didn't miss that bleep - bleep - bleep file saving and loading sound from the TI, one bit. Atari was also a great BASIC language, and the system had 4x more memory than my TI. Atari BASIC even allowed users to redefine characters, and offered extensive documentation of the use of PEEK and POKE addresses. Ah, the good ol' 16-bit days. Well, welcome to the 1990's, and with the "toy" computer age behind me, I ponied up 4,500 for a 486, state of the art, Windows 3.1 custom made system. It had TWO floppy drives, woooo-hooooo! Better still, it came with this little per-installed software program, called QBasic. QB was easy to learn, because it was very similar to Atari and TI BASIC dialects, but you still couldn't make stand-alone exe files. I solved that, by purchasing QuickBASIC, which I used to write my office software. I did appreciate code in the IDE, which helped in debugging, but I didn't appreciate the 64KB memory restriction, even with mulit-modular programming, the best you could squeak out was around 250KB. So, I had to make 16 programs to run my office, and develop a system to share the data between them. I was very happy with the results, and the ability to run over a network was a nice addition when I got my first internet setup. Anyway, the programs I coded worked much better than the "professional" software my colleagues were using. While I did have to debug problems when they arose, my colleagues were much more busy constantly calling in expensive I.T. to identify and fix their office systems. So all was going great, until MicroSoft abandoned the product. Windows systems could no longer natively run QB software. So, along comes this guy, "Galleon" who claims he was making a QB to C/C++ translator, which would run nearly all QB programs on newer operating systems. There was something about this guy. I remember I had to talk our forum owner into giving Galleon a sub-forum to showcase his work. Sure, our owner was correct we heard this song and dance from at least a dozen other accomplished BASIC and C programmers, and that it seemed quite evident none of them would ever finish anything to a workable completion, except, I had a hunch about this Galleon fellow. Good hunch, too. Somehow, this ONE guy devoted nearly 10 years of his time, and yes, he did create a finished translator, 99% QB compatible and by far the most QB compatible in existence today. He also created the IDE, the [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] forum along with contributed documentation to the QB64 Wiki. Galleon also added many new underscored keywords, and improved the compiler performance. He made a bold choice to switch from SDL to OpenGL, and he managed to make what I thought was a mistake initially, into an even better product. Now, far beyond what the QB family of products could do, the newly added keywords extended a programmer's capabilities to stay current with the times, but unlike so many other BS-BASIC languages of today, the keywords Galleon added remained BASIC in nature.
In general, the QB64 improvements over QuickBASIC are staggering, to say the least. No more limited memory. An incredible increase in speed, automated compiling and linking. In QuickBASIC, large projects had to be compiled and linked manually to get them to fit into memory. With QB64, there is no more platform dependency! QB64 has its own integrated mouse. QB64 comes with full online documentation as well as the help files in the IDE. Incredible improvements over QB in color rendering and graphics abilities. QB64 also has the speed needed to implement those improved graphics abilities. Now this is just stuff off the top of my head; so anyone else, please feel free to add more QB64 benefits.
When Galleon made some headway with the project, I decided to help debug it by consolidating my 16 office programs into one. If I found a bug, or other beta testers found a bug, Galleon did an exceptional and timely job at correcting the problem. So, amazingly, I ended up with one 86,000 line office program, and the compile time from the origination of the project, to what it is today, was remarkable. Believe it or not, early QB64 versions would take as long as 30-minutes to compile. Of course, computers were slower a decade+ ago, but still the fact that smae code now compiles in about a minute is a stunning accomplishment, especially when you consider it has to first translate all BASIC statements into C/C++ and whatever is needed for different platforms, OpenGL, etc, and then let the Mingw32 compiler do its thing.
So most of my life, I've programmed in BASIC, but about a month ago, I started learning C/C++. I think I'm starting to get comfortable with it, but I'm just finishing up my first program. It's a little over 1000 lines of code, which gets me a custom made, non-blocking text input routine, printed to the console. The screen text can be fully edited, and it has an added mouse routine, also non-blocking, which can highlight and select text, etc. So, it is a single line text editor, but certainly far from a word processor. Anyway, so, so many statements were needed just to do what QB64 automatically takes care of. I had to setup and control the console window, meaning I had to code to get rid of the vertical scroll bar, change the foreground and background colors, disable quick edit mode, size the console, get control of the cursor shape, etc. Arrays are also a pain in the ASCII with C/C++. I think I cheated my way around this first go 'round, as it works with no memory leaks or crashes, but I really need to study more on how to make and store arrays in C/C++. Now in comparison to QB64, there are little to no worries about crashes or memory leaks, which are so troubling in C++. How "Galleon" worked his way around those in translation from BASIC is really another thing to his credit. I also believe the ease in which QB64 works with OpenGL to render a real graphics window, that can act as a text window, is far better than the putting up with a C/C++ console. It would require even more programming experience for me to get a Win32 graphics window working with text editing. So it takes learning all this stuff, C, C++, and Windows API programming to accomplish what QB64 can accomplish on it own. My C/C++ experience has me even more appreciative of what QB64 can do. QB64 can even work with other libraries, if needed, and unlike the app I'm putting together, which will only work in Windows, a similar app in QB64 would run on Windows, Linux, and Mac.
Pete