FB's Complexity (rather big ;-) but I think a good read.by (no login)Let's forget about QBasic, QB, QBX or VB-DOS shall we for a minute? Let's just compare FB to BASIC. When BASIC was created it's 8 founding principles were also established. The eight design principles of BASIC are: 1. Be easy for beginners to use 2. Be a general-purpose language 3. Allow advanced features to be added for experts (while keeping the language simple for beginners) 4. Be interactive 5. Provide clear and friendly error messages 6. Respond fast for small programs 7. Not require an understanding of computer hardware 8. Shield the user from the operating system Taken them one by one, let's see how FB fits in. As per today's reality of PCs and FB's nature itself too. As in, FB's multi OS support as much as FB's BASIC like dialect. 1. BE EASY FOR BEGINNIERS TO USE. As far as Console programming, yes, FB is as simple as QB to code because it has the PRINT statement. However, in Windows PRINT is not the way to create applications. If you take a look at the lazarus project http:/lazarus.freepascal.org you'll see that they offer a much simpler method of creating native windows application than FB does and yes they are multiplatform so one code base compiles on all supported OSes. Now, to me, this is what FB should allow. Be easy for beginners to do anything available on the OS (See the 8th principle above (and below for details) for more details). Also if you look at RapidQ, they got a good all around system for GUI development, sure that's windows only, but I'm just showing example of sytnax that could be use to allow to create windows or linux GUI forms at the language level that the beginner could atleast understand quickly enough. 2. BE A GENERAL PURPOSE LANGUAGE: No arguments here, it is a good general purpose language it has a tendancy or affinity for game development which isn't bad, but atleast it supposed SQLite and other systems to allow for application development, pending Principle 1 above is implemented of course, it still has to be as simple as possible and probably in respect to the supported OSes and their respective features. 3. Allow advanced FEATURES TO BE ADDED FOR EXPERTS: This isn't an issue per se as it's reselved 1/2 way. Yes, FB allows it, with OOP it will allow even more and that's great as far as this principle goes. But there are more than one way to implement these advanced features that can be better geared towards principle one above. For example, a thick binding (which can happen when OOP is fully implemented) or even a translation layer at the compiler level to give these advanced features a grammar that is simpler than simply supporting the library and making lib level calls to functions. Now VB 6 is good on that level, but there's better, so I don't want FB to be like VB if you get what I'm saying. But right now, it can definitaly use work. If it was implemented in regards and consideration to these BASIC principles, Pete wouldn't have a point with his argument. 4. BE INTERACTIVE. Well on this one, FB fails so does Power Basic and a few others I can think of. it's a compiler, not an interpreter so that does. Of course a good ide in this case might help with some of this. And that can't really happen fully until the language stops changing. Once the language is finished (all OOP and other features are implemented and unchangeable )... But until then fb is what it is. 5 and 6 are good so far. Future plans for error management might make things different from QB but probably a bit simpler to understand for people reading other people's code. So I'm not gonna complain about that until I see it in action. 7. Not require an understanding of computer hardware Though in most cases any multiplatform language suffers from this at different levels (path seperator symbols, date formats, drive IDs and Numbers and others. A basic should not let the programmer decide this because if this principle. This could be done with time especially at the point where a multiplatform GUI system is adopted and implemented. But some of this could be done right now to make life simpler and then expanded on. 8. Shield the user from the Operating System At this point. Once again, most multiplatform suffer from this. But there are solutions. FreePascal has it's sysutil unit which takes care of allot of the more common OS specific things you might need. This can all be done of course, with time. Basically, consider this as a to do list more than a critic of FB...But I think you'll agree that today people are asking the wrong questions during development. They are asking "ok What can FB do next?" instead of "Ok how can I make FB do this or that a better way next?" I'm not saying they shouldn't ask the first question at all, i'm saying both questions should be considered on every feature. Do I want FB to be like QB not really, not on all these points because QB does have it's design flaws and I'll be first to say that Some of the things FB does it does good. What I'm saying is that people there should stop taking posts like this one you're reading as a criticism agaisnt the developers. This post, and all other posts I've ever made were to help FB development, not to criticize it or send the development team to hell. FB is great I'm not denying it and I never said otherwise in the past despite what some say (and conclusion some might have jumped to). These posts I make I don't even make in my name. If I want my perfect basic i'll take care of it, I make these posts for all other basic users QB users of course, there's alot of them so yeah, bot for VB users too, for PB users too, for Real Basic users, for BASIC programmers all over that got curious about FB when it first started and went back to their old tools when they tried to do things and well FB just didn't answer the need the way basic programmers expected it to. I'm doign these posts because of that. I want FB to succeed of course, it's the best OpenSource contender, but eevryone should be considering these principles in the development. So everytime I hear them say we're old dinosaures that want to die with QB in their hands, they're way off. I want BASIC to move forward with the rest of the languages. To me, maybe a BASIC without these principles in mind is like making a C compiler that doesn't use { and } for it's itterations....understand what I mean? My two cents. Fb does rock, to those who want to take the time to learn all these features. But the learning curve should be the first consideration of any BASIC dialect. |
| Response Title | Author and Date |
| Good grief Myst, you should put a pop stand in the middle of that long-ascii article. | Pete on Sep 5 |
| The reports of my death have been greatly exagerated. ;-).... | on Sep 5 |
| About FP's ctrl-c glitch. | on Sep 5 |
| And you want Galleon to add stuff to QB64? | on Sep 15 |
| No, of course not.....sorry it took over a month..I just noticed this ;-).... | on Oct 18 |
| QB is going to be shielded from the OS if M$ has it's way! | on Oct 21 |
| I'll tell you why I think M$ made Vista UAC such a pain in the ascii... | Pete on Oct 21 |