You young programmer just can't grasp the real differences between procedural code and OOP. Try to understand, that us old dinosaurs (programmers in their 60's) use to write apps which would run on 1 megabyte RAM (not Gigabyte), run on a hard-drive which was only 20 megabytes in size or worse in a 1.44 megabyte floppy disk. I wrote my first compiler for the Commodore 64 (using a Basic compiler) which only has 64 Kilobytes of Ram. I wrote a complete POS software package for a video rental store which ran on a Kaypro computer with 2 floppy disks (no harddrive) and 640 KB ram. You learn something from writing code for computers with so little hardware capability. Todays programmers gasp if they had to use a PC with less than a core i7 and 32 Gb ram. I am shocked at how slow and bloated Visual Studio is today. No wonder why programmers need the best PC possible. My core development tools (Powerbasic and my GUI framework with its own Visual Designer) allows me to quickly write apps on almost PC I have around the house. Give me an old Windows 98 computer with 64 meg Ram (not GB) and I likely still could code on it with acceptable speed of development. There are "real" C programmers today, that their entire development system would likely run on a PC which Visual Studio developers could even get their development tools to install on, none the less actual run. I was actually one of those college students who when given a choice to punch out Fortran cards or code in a Basic interpreter on a green screened Terminal, was amazed at how quickly I could write code in that Terminal using simple old Basic. I don't use an interpreter anymore. I use a native code compiler for Windows, which allows me to compile at lightning speeds even tens of thousands of lines of code. I barely have time to take on sip of soda (not a coffee drinker) during the compile cycle for 50,000 lines of code, none the the less take a coffee break. Install the latest Visual Studio (if even possible) onto a PC with only 4 GB ram and less than a core i3 CPU) and with no SSD and see how long it takes you to to even run VS, none the less compile app of significant size. OOP adds overhead to an app and also makes following code flow more challenging. Read an interesting blog post by an engineer at Intel on Intel's website about the significant problems object oriented coding brings when trying to debug code.

The idea that Basic promotes bad code design and structure is false and without merit. Why ? Because Basic uses a "different" style of coding than most programmers use today, but not necessarily a poorer one. What do I mean ? Programmers , in what most of you younger programmers would call the old days or even ancient days, use to code in the procedural style of coding. In the early 2000's procedural programming took a big hit by the new up and coming Object Oriented Programming (aka. OOP) style. There was so much talk about how it would solve all our problems and make coding better, faster and more powerful. There were a lot of promises made and most jumped the "procedural" ship in favor of this new fangled style of coding. There were some programmers who were not so sure about this new coding style and while they may have dabbled in it, they still held onto what they knew best, procedural. Their mindset was more of a wait and see if this new fangled coding style would deliver on all the promises made. Classic Visual Basic was a hybrid of sorts and only stepped into minimal OOP, but kept the procedural style of coding for the backend code (once you were in event code most coded using a procedural style at first). In the C world, many procedural programmers jumped ship into C++ and started writing everything as a class rather than a function or procedure. But there were experienced programmers who took it slowly and did not totally give up on procedural design. So what conclusion have many of those old timers (and amazingly a number of newer younger programmers over time) come too having given OOP plenty of time to prove itself ? While there are a few benefits to OOP, such as its tends to "force" programmers to write modular code, in the long run OOP has not delivers on all of its promises. Sadly OOP has brought us a new term "BLOAT". If one is honest and is willing to read many of the articles floating around the web by experienced programmers about the challenges and weaknesses of OOP, you will find that OOP created as many problems as it appeared to solve. There is a slow, but real, movement among not only old time programmers, but also some younger ones, to take a closer look back at the tried and true procedural style of coding to see if it real was as bad as many say and whether it had any benefits now lost by using OOP for everything. The reality is the procedural style coding, whether Basic, C (rather than C++), Fortran, Java or Pascal still exists and it actually has many benefits.

BASIC has grown over the years and is no longer the beginners language it once was thought to be. Basic started out as an interpreter because it was the only way to produce a multi-tasking system back in the 1970's. While Fortran programmers had to punch cards and wait until the computer dept. had time to run their code, hundreds of Basic programmers were coding and getting immediate results on terminal all around the college. Basic introduces the old computing world to time sharing and it actually was an amazing tool for its time. In the 1980's Basic became a compiler rather than simply an interpreter. Microsoft embraced Basic with its QuickBasic and then PDS 7.1 (Professional Basic). One could code apps in Basic and link into modules written in Assembler, C or other languages. Notice Microsoft called their version of Basic , Professional ! In the 1980's Basic took on many of the best features found in other languages such as Pascal. Modular code design became the norm and the command set grew to embrace many modern constructs. In the 1990's with the advent of Windows, Basic took a big hit at first until Microsoft bought a visual development tool from another company and turned it into Visual Basic. Classic VB was not built from the grown up, so it lost many of the powerful features of its DOS ancestor (PDS 7.1). It was a pcode compiler, not a true compiler. It lost many of its low level features. The one saving grace was the visual drag and drop environment and that is why it became so popular. It was years ahead of other languages when it came to drag and drop, but it did not take long for other languages to catch up. C was a little slow to catch up, but Delphi (Pascal for Windows) caught up and for awhile was a popular language for those who wanted the drag and drop of VB, but the power of C. Microsoft spent years playing catch up trying to bring VB forward and in the end (VB 5/6) they were only able to make it a true machine code compiler by using a C backend. VB itself never was a true compiler (meaning they had to use a different backend to accomplish it, rather than make VB itself a real compiler. Yet, it still was popular because of not only its drag and drop environment, but also because of its support of ActiveX and then later OCX controls. But those custom components usually were written in C, not VB. VB was not a true native code compiler in the sense you could not compile to a real native code DLL usable by other languages (ActiveX DLL's were not the same). This did not mean that Basic tot

I am the exact opposite. Don't use OOP and don't plan on using it unless I have to. Why ? I am an experienced WIN32 programmer and the low level WIN32 is not OOP based, but is procedurally based. Only later did Windows add OOP on top, but the core of Windows is not OOP based. OOP adds complexity and overhead and the core OS needs performance and minimal overhead. Embedded programmers experience a similar experience when they have to work with minimal hardware and every clock cycle matters. The problem with procedural programming is that many programmers did not learn the importance of reusing code by building quality libraries. Procedural code can be encapsulated. That means well written libraries. Well written libraries need to built in what I like to call "the three tier" method. What is that ? (1) Low level (2) Medium level (3) High level Procedural libraries start with the low level routines which are the basis of the core functionality. But after awhile much of the core functionality is covered, so then a more medium level set of routines need to be built upon the backend of the low end routines. Medium level routines can be quite complex, but they should still be relatively simple in purpose. As you build the medium level part of a library, then one can build the much higher level routines, which be quite complex and extensive. This three tiered approach produces a tight, efficient library and IMO can perform better than any OOP library and will be significantly smaller and faster than a comparible OOP library. Modular design existed long before OOP. OOP was just a way to "force" modular design, rather than a better solution. Well written, modular, procedural code will better perform than any OOP counterpart. Also in the embedded world, where minimal hardware exists, the use of such modular procedural coding will be able to push such hardware to the limits, whereas OOP based code will have limits.

I had a C64 back in the 80's and there was actually a BASIC language compiler available for it, by Abacus. It generates machine language from Basic and has extensions beyond the built in Basic. Having been using Basic since then in many variations over the years, the language of choice for me would be Basic, but a BASIC compiler with a modern command set. I also worked with machine code on the C64. I wrote my own compiler, which had a subset of basic but was designed for maximum speed, and I wrote it in compile Basic and it generated direct to machine language. I used my own compiler to write a family friendly video game which was published in the Compute Gazette magazine (October 1987). I still write in Basic today using PowerBasic for Windows using the WIN32 API. So Basic is a good language to use, but it needs to be a fast compiler, support inline assembler and have direct access to either the hardware directly or the operating system.

A little history about WIN32 and scalable coordinates. in the Windows 3.1 days, the WIN API used dialog units which were scalable. Dialogs units with old Windows worked well, since they scaled to the system font and a dialog unit came out exactly 2 pixels in most instances on most displays. When WIN32 came along, so did many larger displays and dialog units didn't always scale properly and didn't come out exactly to pixels, but a percentage of a pixels. This would cause forms designed using the Windows Dialog Designer (aka. very old school designer dating back to Windows 3.1 and coding in pure C) to shift a pixel or two and things often didn't line up properly on some systems. As a long time WIN32 programmer I saw the pros and cons to dialog units. So when I started writing my own GUI framework based on the WIN32, I choose a different route. Dialog units are actually based on a character unit. Dialog Base Units as they are called are the average width and height of the system font. The system font in Windows 3.1 days was a fixed width and came out to 8 x 16 pixels. A dialog unit was defined as (dialog base unit width / 4) and (dialog base unit height / 8). So 8 / 4 = 2 pixels width and 16 / 8 = 2 pixels height. So dialog units came out exactly as 2 x 2 pixels. But later on with WIN32 windows could scale the system fonts and on different displays the dialog base unit did not come out exactly 8 x 16 pixels. Now you had a problem when scaling. I liked how Dialog units worked, but they were flawed when scaled. So I decided a different route. Why not define a dialog base unit in a similar way by getting the average the current system font (even variable width) to define an internal character unit size. But instead of defining coordinates using whole numbers like dialog units do, why not defined character units using floating point. This would provide pin-point accuracy. You could define a coordinate using decimals, like 1.75 horizontal character unit and 2.5 vertical character units. No matter how the end users system defined the font scaling, you would pixel accurate positioning. I actually did this in a GUI framework and surprise, it works amazingly well. By building a Visual Designer using character based units which are floating point, you can get very accurate scaling for any system. Just have the GUI framework convert internally the character units to what ever units you desire and at any scaling. Now add to this your own auto-resize engine (for when forms are resized at run time by the u

Interesting discussion. The reason it interests me is that for the last 20 years I have been developing GUI tools for a niche market (Powerbasic) and one of the things I built which it lacked was a Visual Designer. Visual Designers are not easy to build. I spent 20 years writing my own GUI framework (WIN32) with a Visual Designer engine built into it and when I looked for information about how to write a drag and drop engine specific to programming Visual Designers, there simply wasn't any. There are no native high level API's in the Windows WIN32 for this. Many indie programming languages have come into existence over the years, some hobby languages, others professional level, but the one thing they often lack is a decent Form designer. The reason is that it is not easy to build one.

Just to follow up on my post. This is why for the last ten years I have been learning how to tap into the WIN32 API in a way where I can leverage both the old and the new. Rather than always designing apps for the latest version of Windows (and then it can't run on older versions), instead I find ways to make software run on both. One of the beauties of the WIN32 API is a simple technique of loading DLL's dynamically (LoadLibrary), then poll the DLL to see whether an API exists and if it does use a new feature and if it does not, then fall back and use something all versions of Windows contain instead. There are also many power features in Windows, which have existed since Windows 95, but many programmers may take advantage of them. For example, the Windows DIB API's are very powerful and allow one to build heavy duty graphic features, which don't require any special hardware and which can run on all versions of Windows. Simply put, programmers need to push the limits of the desktop further than they have in the past. Software needs to be dynamic, changing based on the needs. Run an app on XP and an app works like normal, expecting a mouse and keyboard. Run it on Windows 8, then it should check for touch, dynamically change to accomodate tablets and mobile devices. Autoscaling whould be built into the apps so it knows how to redesign itself intelligently based on the DPI and the device type. In essence programmers need to design smarter software, which can tap into the power of the desktop and shine even on Windows 8. This is one of the reasons the Intel/Lenovo app contest is so exciting ! They want to see what we can do with the desktop. They want to see if programmers can push the limits of the desktop further, taking advantages of newer PC's and devices.

I really find it hard to imagine something like Adobe Photoshop or CorelDraw becoming a Metro app. While Metro has some benefits, IMO it loses the power of the desktop. The Desktop needs to be supported for a good number of years or Windows will fail. Why ? Everyone talks about how mobile is changing everything and that desktop PC's will disappear and everyone will have tablets in the future. I doubt it. What we are seeing is actually different. When I first started writing custom software for businesses in the late 80's (anyone remember CPM ?) and early 90's computers were very expensive. They were considered a business tool, not a consumer product. A cheap PC cost at least $2000 to $3000 ! In time, the cost of computer hardware dropped significantly and especially with globalization (aka. made in china) prices dropped so low that computer now became affordable by the masses. With this began the consumerization of PC's. Everyone could afford a computer, but there was something wrong with this. The average person who bought a PC, understood it very little. I would find myself helping consumers with their computers and they couldn't do simple things (like copy files). In essence, they had too much power in their hands. PC's now were being used as over glorified game machines, web browsers and email tools. Most consumers did not need all the power of the PC nor did they need overly complex software. So many times consumers when buying a PC would be oversold "power machines" by over zealous sales people (you need more ram, need bigger harddrive, need super duper CPU). Then something strange happened. Apple got the idea that consumers needed dedicated devices geared towards ease of use and designed for consumer needs. First it was Ipods/MP3 players and then tablets. Now everyone wants a tablet, something simple, just touch the screen and no need for a mouse or a keyboard. This new generation of computerized devices actually fit the needs of many consumers (light weight, not complex, just buy apps in an app store). So does this mean the end of the PC as we know it ? Does this mean the Desktop is dead ? Absolutely not. Why ? Because of the consumerization of the PC, the market is now dividing itself back towards its origins. PC's were originally intended as business machines, not consumer products. Now that there are consumer products to replace PC's, PC's are falling back to their origin of being a business machine designed to solve business needs. Of course a certain percentage of the PC market will fall to th

GOTO is a vital tool for programmers wanting to develop high performance applications. In my primary commercial product (a GUI engine used by other programmers) I use it over a dozen times. Even the likes of Alexander Stepanov consider it useful, so I am in good company.

One of the best languages for string manipulation is PowerBasic. You can use it to write 32 bit DLL's callable from other languages. To trim leading spaces: LTRIM$(AnyStringVar) To trim any character from left: LTRIM$(AnyStringVar, SomeCharacter) To trim any of multiple characters from left: LTRIM$(AnyStringVar, ANY SomeCharacters) To trim trailing edge spaces: RTRIM$(AnyStringVar) To trim any trailing character: RTRIM$(AnyStringVar,SomeCharacter) To trim any of multiple trailing characters: RTRIM$(AnyStringVar, ANY SomeCharacters) Trim both leading and trailing spaces: TRIM$(AnyStringVar) Trim any character leading or trailing: TRIM$(AnyStringVar, SomeCharacter) Trim any of multiple characters leading and trailing: TRIM$(AnyStringvar, ANY SomeCharacters) PowerBasic supports pointers too ! PowerBasic has many other powerful string functions (both ANSI and UNICODE) such as: ACODE$ - Translate a Unicode string into an ANSI string. BIN$ - Return a string with the binary (base 2) representation of a value. BITS$ - Copies string contents without modification. BUILD$ - Concatenate multiple strings with high efficiency. CHOOSE$ - Return one of several values, based upon the value of an index. CHR$ - Convert one or more character codes into ASCII character(s). CHR$$ - Convert one or more character codes into Unicode character(s). CHRBYTES - Determine the size of a single character in a string variable. ChrToOem$ - Translates a string of ANSI/WIDE characters to OEM byte characters. ChrToUtf8$ - Translates a string of ANSI/WIDE characters to UTF-8 byte characters. CLIP$ - Deletes characters from a string. CLSID$ - Return a 16-byte (128-bit) GUID string containing a CLSID. CSET - Center a string within the space of another string or UDT. CSET$ - Return a string containing a centered (padded) string. DEC$ - Convert an integral value to a decimal string. EXTRACT$ - Return up to the first occurrence of a specified character. FORMAT$ - Return a string containing formatted numeric data. GUID$ - Return a 16-byte (128-bit) Globally Unique Identifier GUID. GUIDTXT$ - Return a 38-byte human-readable GUID/UUID string. HEX$ - Hexadecimal (base 16) string representation of an argument. INSTR - Search a string for the first occurrence of a character or string. JOIN$ - Return a string consisting of all of the strings in a string array. LCASE$ - Return a lowercase version of a string argument. LEFT$ - Return the left

Remember TurboBasic ? Borland progressively got rid of their compiler business, first was TurboBasic (not because it was bad, but just hard to compete against Microsofts QuickBasic and PDS 7.1) and then later sold off all their programming languages. TurboBasic was sold back to its original developer, Bob Zale, and he renamed it PowerBasic. Without the resources of a big software company PowerBasic had to grow slowly, first marketing itself as an addon to Visual Basic for building real DLL's. Today it has come a long way and has a nice array of third party tools as addons. PowerBasic 10 (for Windows) and a real 32 bit compiler. The compiler itself, is not written in a higher language like C++, but it is written in pure assembler (IDE for it is written in PowerBasic). The compile speeds are just amazing. The execution speed of the compile code is also very, very fast and on par with any C compiler today. The command set is extremely rich, with things like Matrix (ARRAY) commands, fast string functions, rich data types, macros, compiler directives, debugger, register variables, pointers, inline assembler, Dynamic Dialog Tools command set and more. It comes with a PowerBasic translation of the Windows API headers and you have access to the entire array of WIN32 APIs. It also does COM and its own version of classes (OOP if you like it). You need not be an OOP programmer though, since you can write an app using 100% procedural based code. Since BASIC is a more natural language is more readable then say C++, Windows API code is actually quite readable and learning the Windows API is not as difficult for PowerBasic programmers as it might be for a C programmer. Simply put, PowerBasic is a professional level tool. Unlike something like Visual Studio which requires a couple gigabytes to install, a complete PowerBasic installation is about 10 meg. On about a 9 year old Windows XP computer (2.5 ghz Celeron CPU, 768 meg RAM) I can compile about 63,000 lines of code in less than 10 seconds. On a modern computer such compiles would be almost instantaneous.

I have been using PowerBasic for over ten years. PowerBasic is what C should have been. It produces comparibly fast and small (compact) executables as C, but it is BASIC. It sticks to the long time Microsoft BASIC syntax so QBasic, PDS 7.1 and VB programmers will find it very familiar. The command set is very rich, especially when it comes to variable length strings. It is also very low level with things like code pointers, variable pointers, pointer indirection (pointer to a pointer), inline assembler. It also does COM objects and Classes, but you can still write an app in 100 procedurally based code. It does require a good working knowledge of the WIN32 API's. The online forums provide access to some very advanced WIN32 programmers around the world. I am a third party developer who provides addons to PowerBasic and my tools also were all built using PowerBasic. Unlike Visual Basic of the past where quality addons usually were built using C or C++, PowerBasic addons are often built using PowerBasic itself. I built an advanced GUI engine for use with PowerBasic and I have designed everything from drag and drop Visual Designers to things like custom controls with things like a 2D proprietary Sprite engine, 3D OpenGL based scripting language and more. I do stuff like subclassing, superclassing, low level DIB's, threading and more all written in PowerBasic. You can build apps which can fit on a floppy disk (remember those ?). No dot.net runtimes required. No software bloat.

I won't comment about Microsofts reasons or motives in changing VB, but I will comment about the Basic language and why some may prefer not to switch to C#. BASIC has a very, very long history and despite all the criticism it has received it has endured. Why ? Because Basic is a more natural language as far as its syntax. Even non-programmers can examine Basic code and make some sense of what it is doing, unlike C code which is an acquired taste. I have been programming in Basic since 1975. I learned some Fortran, gotten plenty of books on C (interested) and even purchased a C compiler or two, but just never picked up the language. Very quickly the syntax of the language (C) was counter intuitive to my first language Basic. Now I did take the time to learn some machine language (wrote a compiler using Basic for the 6502 CPU for the commodore 64). I also learned some intel assembler and wrote some library code for use with PDS 7.1 using assembler. To me machine language and assembler was easier to pick up than C. Over the years I moved on to VB 1.0, 2.0 and finally 5.0 Pro (stopped there). Amazingly, it was all the OOP stuff which I began to dislike. While OOP has its place, OOP is not the programming panacea it was first thought to be. I personally prefer more procedural style coding over OOP and I am far more productive with such code. I still love the Basic language and it still lives despite dot.net. For the last 10 years I have used PowerBasic, rather than any Microsoft Basic. I still like VB, but it has changed too much for me and is not efficient enough for me. From my experience I find it is best not to learn too many different programming languages. You know the old saying, "jack of all trades, but master of none". I find it better to pick the language you are most productive in and to become an expert in it. If you want to learn a second language, I would recommend it be assembler (or machine language). Learning machine language makes one appreciate what a compiler does even more. One of the beauties of Basic is its readability. One can pick up code written years ago and quickly make sense of it. Now one good reason the Basic language should not be changed (the core language left alone), but rather simply add new features to it, is that if languages keep changing every few years, then much time is lost in having to rewrite code for a new syntax. When you can have perfect code which was written years ago, simply reused today, then you don't have to reinvent the wheel all the time. Sure

I recommend Hypermart ( http://hypermart.com ) My web site runs about $8 (US) a month and the service is great. You can set up things like a content manager or a forum (ie. WordPress, Drupal, Jumla, etc.) in minutes and have a fully functioning web site. I code my own HTML web pages and upload via FTP and I use WordPress for a Blog and Simple Machines for a support forum. I have used Hypermart for about 10 years and they are fantastic. They even have fast "Chat" style tech support where you get immediate results and actually talk directly to a real person. Problems can be resolved in minutes, rather than days. It is easy to register domain names (about $11/year) for your web site. Hypermart cators to businesses, small and large. For software developers who want to sell their software online, in combination with Hypermart, I recommend BMT-Micro ( http://bmtmicro.com ) for handling the credit card stuff and taking orders. I have used them for about 10 years now and they are amazing. The services are great. They can even handle sales to the EU and deal with the VAT tax. They handle all sorts of credit cards and other forms of payment. Combine these two and a programmer can start selling his software on the internet within a days time and have the look and feel of a "big" company.

I don't use any OOP at all and prefer it that way. I use PowerBasic (Basic language compiler) and I write all my code using subroutines and functions and not a single object. One can have modular design without OOP. I believe it decreases code size significantly. I develop tools for programmers and currently my primary product is in its 5th generation. I like to use the Visual Basic runtimes to compare my runtimes (DLL's) to as far as size and functionality. The VB 5.0 and 6.0 primary runtime DLL is about 1.4 meg in size. It does not even support any of the common controls which require additional OCX's. Now the GUI engine I have developed (for use with Powerbasic to write Windows apps) is less than 1 meg in size (main runtime is 684 KB) and it contains the following: - complete GUI engine for Forms and nearly all of the built in controls in Windows, even most of the Common controls (ie. toolbars, treeviews, listviews, tab, etc.) and Richedit 1.0 and 2.0 controls. - drag and drop engine built in (build your own drag and drop visual designer using it) - subclassing engine - thread engine - print engine - graphics engine - ownerdraw and customdraw engines (customize controls the way you want) besides the above, the following custom controls are built in: - Canvas control which supports double buffers and DIB's (direct access to pixels) - Shape/Hot Spot control - Masked Edit control - Drag Handle control (for use with drag and drop engine) - MCI control - Files Listbox control - Property Listbox control - SplitterBar control the latest new custom control added is: - OpenGL based 3D Canvas control with a complete proprietary 3D script language built in (yes it is a real windows control) The Canvas control has a proprietary 2D Sprite engine built in (ie. move/show/hide Sprites, even with alphablending). There is also ... - Component (non-OOP based) engine (forms become reusable components) - Superclassing engine - Custom control engine - Layering engine (put controls on different layers and show/hide by layer) - Common Dialogs and a lot more. Now I don't use any OOP at all (no objects, no COM, no ActiveX), but it is very modular in design and reuses code as much as possible innternally. I haven't even reached the size of the main Visual Basic runtime yet and it packs in far more than you get in Visual Basic. The command set (API) is easy to use as well. Lastly you can simply copy your compiled EXE (using PowerBasic) with just one (or a few) runtime DLL's to any computer witho

I posted the example code to demonstrate the Powerbasic compiler is fast, not to use it as a benchmark to compare it to another compiler. The problem with such comparisons is that some compilers use shortcuts to speed up such simple loops to make the compiler look faster than it really is. PowerBasic never does this. Without being able to examine using a disassembler to see what code the compiler is actually generating it is difficult to tell whether it is accurate. Also one has to be careful in the objects used for such small timing, to make sure they are accurate done to the millisecond level. The only way to truly compare two language is to make sure the code is not effected by any "tricks" of a compiler and the timer must be a precision timer to be completely accurate. Also you have to run such a benchmark example, using both languages on the exact same computer. There is a big difference for example between my 7 year old 2.5 ghz Intel Celeron CPU (and even the RAM speed) compared to many of the much faster CPU's likely found in the average programmers PC. If you don't take into consideration such factors you can't make any comparisons.

modified on Monday, January 10, 2011 7:46 PM

Quote: "BASIC is not fast" Thats what you may have been told, but I assure you Powerbasic is not only fast, but it can stand its own with most any other compiler, even C. The misnomer that Basic is slow and a poor language dates back to the time when many basics were interpreted. A compiled Basic can be just as fast and as any other language and there is nothing inherent to the Basic language which would make it hard to compile to a fast executable. PowerBasic (the company) are experts at optimizing machine code generated by the compiler. For example let's just take a look at a simple bit of code:

 REGISTER x AS LONG, y AS LONG, z AS LONG
 LOCAL t AS DOUBLE
 LOCAL i AS LONG
 x = 5
 y = 3
 t = TIMER
 FOR i = 1 TO 10000000
      IF x > 1000000 THEN x=5
      x = x \* y
 NEXT
 t = TIMER - t
 MSGBOX FORMAT$(t,".0000")

This simple FOR NEXT loop executes 10 million times, doing a simple multiplication calculation. Now the PowerBasic compiler does not cheat by generating short cuts in code it may assume does nothing, like other compilers do (others do that just for benchmarking to make their compiler look good). This FOR NEXT loop is executing every iteration. Now how fast does 10 million iterations take on a common Desktop running Windows XP with a mass produced 2.5 ghz Celeron CPU (no cores or multiple CPU's) ? .094 seconds ! Yes, the PowerBasic compiler is generate code for the above code which executes 10 million iterations in less than 1/10th a second. Now I don't think that is slow. Sure, some compiler out there may beat that, but PowerBasic can hold its own quite well. Now add to this the richness of the language so you can write better code (to make it faster) and the ability to add inline assembler when you want to and you have a language which can create amazingly fast executables. I should know. I have been using it commercially writing tools for programmers for about 10 years.

PowerBasic, IMO is one of the software industries best kept secrets. Most online computer and developer magazines rarely ever mention it. I have been using Powerbasic for nearly 10 years now and I can write code which will run circles around stuff written by C++ or VB# programmers. I write a good bit of code which requires optimal speed, such as things like 2D animation, 3D OpenGL animation, Image Filters, etc. I write a lot of stuff that deals with Graphics (ie. customizing controls via Ownerdraw, my own Graphics controls, etc.) and speed is critical. I can write applications or DLL's which rival the speed of any language and still write stuff that will fit on a Floppy Disk or will run on Legacy PC's like Windows 95/98 (with CPU's below 500 mhz). Now my experience as a Windows API programmer gives me some advantages, but PowerBasic allows me to tap into the Windows API with an extremely fast compiler.

One of the fastest programming languages I have come across is PowerBasic (remember Borlands TurboBasic ? This is its great grand child). Powerbasic has similiar syntax to Visual Basic (non-OOP code), but the people at Powerbasic are experts in Intel machine code and in counting CPU cycles (meaning squeezing as much speed as possible). PowerBasic also has such a rich command set, there are always better ways to optimize code. In the rare instance that is not enough, you can write inline assembler code right in the middle of basic code. PowerBasic gives you the control required to optimize code to the max! The generated machine code by the compiler is probably as fast as it gets and I am confident PowerBasic would hold its own compared to any other language. I have been using PowerBasic for about 10 years now and am a developer of programming tools for use by professional programmers (who also use PowerBasic). PowerBasic allows me to write applications (and DLL's) which are smaller in size than what is generated by most languages, even C or C++ and the speed rivals the fastest C compilers. I can work with things like pointers, register variables, calling functions via a pointer, etc. The data types are so extensive there is always a better data type for the task at hand. PowerBasic IMO probably has the best string handling command set of any language and if you have to do text parsing I doubt it could be beat by any language. I wrote a 2D Sprite engine (100% software based with no special hardware required) using Powerbasic which requires extremely fast manipulation of millions of pixels in DIB sections and it can fly, even on a slower CPU like an Intel Atom found in many Netbooks today. I actually do testing on older PC's like a Windows 95 PC with a 500 mhz CPU (or less). I like to see my software fly on even a legacy PC, so it will be super fast on the latest PC's. Many programming languages couldn't even be used on a 500 mhz Windows 95 PC (PowerBasic can) and they surely would not be used to write software for such a legacy PC (too slow). Since I write tools for programmers, I have to be concerned about speed and PowerBasic has always matched my needs. I am currently developing the next generation of my tools which also handle 3D drawing using OpenGL and my OpenGL Canvas control (yes a real Windows control) has excellent speed in translating a GL scripting Graphics Language the control provides for 3D drawing. The control must interpret a script language and then handle all the 3D drawing via OpenGL