A Serious Article Debating the Pros and Cons of FreeBASIC
So what can the community start to do to help? Write tutorials, books, wiki's, download FB source? I wouldn't know where to begin if I wanted to help in ways that I've even mentioned(Adding inheritence for example). What can I do to help motivate the developers to spend more of their precious spare time to develop? I think that's a question that is worth asking. I really do appreciate their work, but maybe they are not being told this enough.
A very good language was the now discontinued RapidQ (but it was closed-source, and interpreted). It allowed all programming styles, from:-OOPSIE- wrote:As a bad programmer, could I put in a request that you make all these big word features that have been mentioned, very optional, tucked out of the way and not on by default.
To me, Basic should be basic. It's even in the name!
Code: Select all
10 PRINT "Hello":PRINT "World"
20 END
Code: Select all
CREATE MainForm AS QForm
Center
CREATE MainMenu AS QMainMenu
CREATE FileMenu AS QMenuItem
Caption = "&File"
CREATE OpenItem AS QMenuItem
Caption = "&Open"
END CREATE
CREATE SaveItem AS QMenuItem
Caption = "&Save"
END CREATE
END CREATE
END CREATE
ShowModal
END CREATE
FBLite is very close to RapidQ, so I continue to think that, with a little of OOP (a "lite one", with no constructors, and no operator), it would be perfect for beginners (much friendler than pure FB). When beginner gain confidence, can switch to full FB (as powerful as C++, but with no need to learn again from start).
FB now is facing the same problems of linux: a good system, but made by developers for developers, so essential and not user friendly: most features are command-line only (like in early versions of linux), the IDE is made to speed up work for experienced users, not to welcome beginners). A full, complete environment cannot be user-friendly, and an user-friendly one cannot be complete. Linux solved that by making different distributions for different targets, and I think that FB should choose the same path (even FreePascal did something similar... I heard about a Delphi-simulator, based on FP compiler)
Hi together!
I see some things a little different than the OP and some posters here.
- The origins of freebasic are in QuickBasic. Still many beginners change vom QB to freebasic due to the compatibility of the latter to the first. However this compatibility paradigm was left behind more and more in the last two years (though it was preserved technically by the dialect concept) in favour of a language development towards C/C++. The treasure of freebasic is compatibility, a small compiler, fast code and bindings to rich libraries, it's failure would be an overloaded, oversophisticated language concept.
- I don't see a FB participation problem, even more FB not being "on life support". Only the compiler developers team is currently drained out. Is that a large damage? May be it's a favour for not to move too quickly far away from the simple basic language tradition of former times. I would say: We don't need inheritance and lamda expressions and all that stuff. If FB becomes a one by one copy of C++, one can use C++.
- What we need? Low tresholds for programming starters and QB switchers. And that would be first of all a one by one clone of the QB IDE. I wonder why nobody has started such a project. FBEdit is wonderful, but far too complex for to be a good beginners IDE.
- What we need further else? FB has great bindings to a lot of great libraries. But most of them demand higher programming skills. OpenGL and GTK are two examples. What could be very useful: A small easy-to-use-GUI-lib, not requiring pointers, classes, callback functions and all that stuff, but just commands like "make_button(name,x,y,xsize,ysize)" and "if on_button_click(name) then..." and such things.
Croco
I see some things a little different than the OP and some posters here.
- The origins of freebasic are in QuickBasic. Still many beginners change vom QB to freebasic due to the compatibility of the latter to the first. However this compatibility paradigm was left behind more and more in the last two years (though it was preserved technically by the dialect concept) in favour of a language development towards C/C++. The treasure of freebasic is compatibility, a small compiler, fast code and bindings to rich libraries, it's failure would be an overloaded, oversophisticated language concept.
- I don't see a FB participation problem, even more FB not being "on life support". Only the compiler developers team is currently drained out. Is that a large damage? May be it's a favour for not to move too quickly far away from the simple basic language tradition of former times. I would say: We don't need inheritance and lamda expressions and all that stuff. If FB becomes a one by one copy of C++, one can use C++.
- What we need? Low tresholds for programming starters and QB switchers. And that would be first of all a one by one clone of the QB IDE. I wonder why nobody has started such a project. FBEdit is wonderful, but far too complex for to be a good beginners IDE.
- What we need further else? FB has great bindings to a lot of great libraries. But most of them demand higher programming skills. OpenGL and GTK are two examples. What could be very useful: A small easy-to-use-GUI-lib, not requiring pointers, classes, callback functions and all that stuff, but just commands like "make_button(name,x,y,xsize,ysize)" and "if on_button_click(name) then..." and such things.
Croco
Most QB fundamentalists have switched to QB64 and won't bother us any more, so freebasic is more "free". Anyway, QB64 requires you to keep the program structured in the same way, and doesn't allow modern tecniques, while FB does. So FB is a good tool in "migrating" to advanced programming.croco97 wrote:
- The origins of freebasic are in QuickBasic. Still many beginners change vom QB to freebasic due to the compatibility of the latter to the first. However this compatibility paradigm was left behind more and more in the last two years (though it was preserved technically by the dialect concept) in favour of a language development towards C/C++. The treasure of freebasic is compatibility, a small compiler, fast code and bindings to rich libraries, it's failure would be an overloaded, oversophisticated language concept.
Also, having three compilers that can understand the same code (pure QB code works on QB, FB and QB64) makes a sort of standard: QB code, in fact, can be run on older and newer system, it's hardware-independent, and allows graphic and sound features with no external libraries... I can see a lot of applications for that.
Somebody already tried it:croco97 wrote: - What we need? Low tresholds for programming starters and QB switchers. And that would be first of all a one by one clone of the QB IDE. I wonder why nobody has started such a project. FBEdit is wonderful, but far too complex for to be a good beginners IDE.
http://www.freebasic.net/forum/viewtopi ... 1d2f452888
http://www.freebasic.net/forum/viewtopi ... nteger+176
http://www.freebasic.net/forum/viewtopi ... c38b1831e5
As I've already said, it could be used in a distro.
A library for building GUI programs (maybe multiplatform) like RapidQ or VB would make FB a lot easier and popular.croco97 wrote: - What we need further else? FB has great bindings to a lot of great libraries. But most of them demand higher programming skills. OpenGL and GTK are two examples. What could be very useful: A small easy-to-use-GUI-lib, not requiring pointers, classes, callback functions and all that stuff, but just commands like "make_button(name,x,y,xsize,ysize)" and "if on_button_click(name) then..." and such things.
Also a 3d library like miniB3d (downloaded it, looking if I can arrange something... I know Blitz3D, not BlitzMax) could make FB interesting for newcomers.
Both of them, anyway, would require inheritance (at least a bit). Some work-arounds are possible, but not easy.
QB compatibility may have been a great design goal in the beginning of the FB project but it is high time for it be totally and utterly wiped from the FB project forever. Drop it, delete it, military wipe it from the archives. Concentrate totally, 100%, on the FB compiler and do away with QB, FBLite, etc... The compiler would be cleaner and easier to maintain, less cumbersome backward compatibility hacks, and it would represent the most modern BASIC available to programmers.
If people want a QB compiler then, well, use QB itself. My gut feeling is that if only one dialect of FB existed then maybe more tools would exist from developers and it would be a hell of alot easier to get new developers on board to help out. I was a staunch QB45 user years and years ago but I certainly wouldn't want to devote my precious programming time to hacking compiler code to make it work on the latest operating systems.
Now it seems that the language is all over the place trying to be everything to everyone. I don't see why QB compatibility is so important or expected. 20 years is long enough to hold onto that dinosaur. It's time to fossilize it.
:-)
If people want a QB compiler then, well, use QB itself. My gut feeling is that if only one dialect of FB existed then maybe more tools would exist from developers and it would be a hell of alot easier to get new developers on board to help out. I was a staunch QB45 user years and years ago but I certainly wouldn't want to devote my precious programming time to hacking compiler code to make it work on the latest operating systems.
Now it seems that the language is all over the place trying to be everything to everyone. I don't see why QB compatibility is so important or expected. 20 years is long enough to hold onto that dinosaur. It's time to fossilize it.
:-)
No OOP features are required for either, so inheritance is not required in the least. You can do both quite easily with normal procedural code. And actually, we were doing GUI programs in FB long before v1c walked away, and it was very simple to do...a newbie could have understood it pretty easily with the skeleton applications we wrote.angros47 wrote:A library for building GUI programs (maybe multiplatform) like RapidQ or VB would make FB a lot easier and popular.
Also a 3d library like miniB3d (downloaded it, looking if I can arrange something... I know Blitz3D, not BlitzMax) could make FB interesting for newcomers.
Both of them, anyway, would require inheritance (at least a bit). Some work-arounds are possible, but not easy.
If you remove -lang QB and -lang fblite, the result is no more basic: no line numbers, all declarations explicit, no GOTO/GOSUB... if it cannot compile programs written in BASIC, you cannot call it a BASIC compiler.
Why all of us are using FB? Why didn't switch to VB.NET? Or to VB6? These compilers are the official successors of QB, microsoft recommands them... but they are different, and somebody didn't like it. That's why we are here, because we like BASIC, not VB, not C++, not pascal, but BASIC.
Please close this thread, it's going nowhere: one says that we don't need inheritance, another says that we don't need QB mode... what we need? to remove every feature that makes FB unique? to change FB into a crippled Pascal-like language? to have a so strict syntax that even an "hello world" would give 25 warnings?
Why all of us are using FB? Why didn't switch to VB.NET? Or to VB6? These compilers are the official successors of QB, microsoft recommands them... but they are different, and somebody didn't like it. That's why we are here, because we like BASIC, not VB, not C++, not pascal, but BASIC.
Please close this thread, it's going nowhere: one says that we don't need inheritance, another says that we don't need QB mode... what we need? to remove every feature that makes FB unique? to change FB into a crippled Pascal-like language? to have a so strict syntax that even an "hello world" would give 25 warnings?
You've got be joking, right? When did QB become "THE" BASIC by which all future BASIC's are supposed to be judged by? Even back in its day, QB was only an adequate language at best. FB can and should only be able to compile FB BASIC programs... it doesn't need to be able to compile BASIC source code as generated by other BASIC compilers. That just doesn't make sense. I guess we should also ensure that it compiles all Business Basic, BASICA, TurboBasic, True Basic and PowerBasic source code as well?If you remove -lang QB and -lang fblite, the result is no more basic: no line numbers, all declarations explicit, no GOTO/GOSUB... if it cannot compile programs written in BASIC, you cannot call it a BASIC compiler.
Who the hell wants a BASIC that is rooted in 1960's architecture? If that is the impetus for FB then we better make sure that it is punch card compatible and runs in under 2K of memory. Line numbers need to be dead. Explicit declarations is just good programming practice and needs to be enforced. GOSUB/GOTO... I see the uses for it and would be nice to retain, but they can easily be replace by simple calls to a Sub/Function. Old school is nice for nostalgia reasons but the past is the past... it needs to stay there and let's move on.
I always thought that FB was supposed be the new, modern, BASIC implementation that would compete with the Big Boys in the programming language world. FB is not like VB.NET so there is no reason to think that forging ahead with the FB feature set would blur the lines on FB and VB.NET.
It's about time that a debate was made on this subject. Time to dust the cobwebs off the FB source code and push it in the right direction rather than worry that any deviation from the "QB Standard" would amount to programming sacrilege.
Just as C evolved, so did BASIC. FB represents an evolved BASIC. QB represents an evolved BASIC as well. Hell, even BASICA represents an evolved BASIC, and let's not forget about GW-BASIC. There is no need to stagnate the evolution of BASIC by hanging on to archaic technique. While I do not now nor will I EVER agree with the decision to remove GOTO (C still uses it, and it's absolutely necessary in assembly language), removal of line numbers and GOSUB is a necessary step in keeping FB modern. QB is *not* the standard; most of FB's early adopters (like me) simply come from the QB world so that's what we expect, and many people transitioning now have roots in QB. But this is not QB, it's FB, so people need to quit whining about it. If they want a QB that works on today's systems, go play with QB64 or make your own QB compiler...after all, the source code was leaked out years ago.
Hi all
I also agree with McLovin
As far as some of the more advanced features (proposed and current), the important point is that if I want to use them, I can. If I dont understand them and want to stick to simple features, I can. Dont write the compiler so that some of the more advanced features are mandatory.
But guy's DON'T even think about dropping Dos support.
Regards
I also agree with McLovin
Even being the Dinosaur here, QB compatibility is the past. However, lets not Nuke it, just leave it as is, close all development on it. If any one wants to use it they can.I don't see why QB compatibility is so important or expected. 20 years is long enough to hold onto that dinosaur. It's time to fossilize it.
As far as some of the more advanced features (proposed and current), the important point is that if I want to use them, I can. If I dont understand them and want to stick to simple features, I can. Dont write the compiler so that some of the more advanced features are mandatory.
But guy's DON'T even think about dropping Dos support.
Regards
OK, one useful outcome of this discussion is that FB seems not to be regarded mainly as a beginners language (which would not require many enhancements beyond the FBC0.15 or 0.16 specification.)Eponasoft wrote:Just as C evolved, so did BASIC. (...) There is no need to stagnate the evolution of BASIC by hanging on to archaic technique.
Actually it is regarded as a productive tool for productive modern programming. But in which valley of the huge software development landscape FB does fit? FB's interface to web programming is non existing, there is no binding to a platform like Java or .NET (Mono), even no Eclipse or NetBeans plugin, and there are hundreds of languages each with ten times larger developer communities than FB ever had. Game Development? Well, I don't know many people in the community being able to connect Milkshape3D or Blender to FB. There is an excellent development of an Irrlicht Wrapper, but who did apply it? And even if many people did: Why did they do it in FB and not in C/C++?
I don't see currently the sharp profile of FB as a productive modern programming tool for experienced programmers. May be it's Linux/Windows cross platform features combined with it's rich bindings shape such a profile. Not to forget the (currently still existing) compatibility to Microsoft VBA, which has a large professional dimension.
I'm curious about your comments.
C evolved, but can still compile programs written in the original ANSI C, otherwise you cannot call it a C compiler. Even C++ (that is a different language) can.
So I expect that a basic compiler can AT LEAST compile ANSI BASIC (http://en.wikipedia.org/wiki/Dartmouth_BASIC, http://en.wikipedia.org/wiki/ANSI_BASIC). Otherwise, you can call the language with the name you like, but not basic. Since there are hundreds of languages that are called basic, but are not basic-compliant, i see no point in building another.
I think that FB should be to QB what C++ is to C: it's compatible, can import old programs, but adds advanced features like OOP.
The most important open source C compiler is, of course, GCC: well, it's a three-in-one compiler, because it can use C, Objective C and C++, and nobody complies about it. So why FB cannot be the same?
Remember when V1C dropped GOSUB inside SUBs? Many users refused to switch to the new version, until -lang QB was introduced (and now GOSUB is available again in FBLITE). FBLITE is very similar to Power Basic for windows, because it has a real Basic structure, but without the limitations needed to keep retrocompatibility with QB.
Also, if distros should be made, every distro should use the most suitable dialect (a distro for beginner should use fblite, a distro for retrocompatibility -lang QB). With dialects, every distro could read even programs written for others, simply changing a switch.
This topic has been already discussed in a lot of threads, and lead nowhere: so please stop asking to drop features!
So I expect that a basic compiler can AT LEAST compile ANSI BASIC (http://en.wikipedia.org/wiki/Dartmouth_BASIC, http://en.wikipedia.org/wiki/ANSI_BASIC). Otherwise, you can call the language with the name you like, but not basic. Since there are hundreds of languages that are called basic, but are not basic-compliant, i see no point in building another.
I think that FB should be to QB what C++ is to C: it's compatible, can import old programs, but adds advanced features like OOP.
The most important open source C compiler is, of course, GCC: well, it's a three-in-one compiler, because it can use C, Objective C and C++, and nobody complies about it. So why FB cannot be the same?
Remember when V1C dropped GOSUB inside SUBs? Many users refused to switch to the new version, until -lang QB was introduced (and now GOSUB is available again in FBLITE). FBLITE is very similar to Power Basic for windows, because it has a real Basic structure, but without the limitations needed to keep retrocompatibility with QB.
Also, if distros should be made, every distro should use the most suitable dialect (a distro for beginner should use fblite, a distro for retrocompatibility -lang QB). With dialects, every distro could read even programs written for others, simply changing a switch.
This topic has been already discussed in a lot of threads, and lead nowhere: so please stop asking to drop features!