I was just reading a blog today with an article about what the next big programming language should be. What gets me though is how often those who ponder a better programming language use C (or C++) as the basis or foundation of what the next language should be. My question is why this love affair with C++ ?

As a long time BASIC programmer, I can understand why some may have negative views of BASIC, since they often equate BASIC with the old interpreters of old from the 80′s rather than the new generation of Basic compilers. What few seem to appreciate is that, BASIC has grown, even borrowing from other languages like Pascal or C, but using its own style of syntax. Why is the BASIC syntax so important ?

Because it removes the cryptic syntax found in most programming languages today (like C++ or Java) and replaces it with something more akin to the language we speak. I don’t know why programmers are often drawn to the cryptic rather than the simple. Personally, I find even good old assembler easier to understand than C++.

So why is syntax so important ?

Two problems plague all software. First is code readability. Most software eventually has to be updated and things added. The easier it is to be able to read source code, the faster and easier it will be to add new code to it. Now I will say though that good modular design is a must, no matter what language ones uses, so even BASIC code can be a mess if not written correctly. But when written using good modular design, BASIC source code can be so easy to read that a programmer can write something and then come back to it a couple years later and more easily make sense of it.  The second problem is debugging. Again the easier it is to read source code, it makes it easier to find the errors in the code.

I am sure plenty who read this article will likely say, “but you can’t do the things I do with a BASIC language, like you can with C++”.  While not all BASIC’s are created equal, I use PowerBasic and it has many power features which rival any C++ compiler in my opinion. To be honest though, PowerBasic is more of a coders language than a visual language. But when it comes to coding, you would be surprised at the things you can do with it.

Two areas where I really find PowerBasic to be just right for me are with strings and pointers. PowerBasics unique use of the Windows OLE engine for handling variable length strings is just downright perfect for many. You can work with variable length strings just like you did using old time Basics. No need to worry about defining an array of characters or some other technique. No need to worry about garbage collection. The compiler handles it all. You just use strings like they were meant to be used, but they can now be huge in size. Now add to this the fantastic selection of string functions PowerBasic provides and you have a powerful tool for handling large amounts of text with excellent performance. The second area which is a favorite is pointers. PowerBasics implimentation of pointers rivals anything you would find with C. I use pointers a lot. PowerBasic provides multiple syntaxes for handling pointers in different ways, so there are many options for solving problems while providing clean readable code. PowerBasic can even let you define an array into a block of memory (DIM AT an address) so the array looks like a normal array in code, but it actually is a pointer to a block of memory from something else. For example I could have a string variable and put any data I want into it and then get the address of the string and Dimension a numeric array inside that string. When you add PowerBasics rich set of data types with the use of pointers some really amazing things can be done.

In the old days, using the Windows API (WIN32) was too hard for many programmers, so Microsoft moved on to alternatives like MFC, ATL, etc. The interesting thing I have found as a WIN32 programmer is that the Windows API is not as confusing as you would think when you see an app written using PowerBasic syntax rather than C. Because BASIC is simpler in syntax and easier to read, API source code actually makes a lot more sense. True the Windows API is not easy to learn, but using PowerBasic it is a lot easier to learn and use than using C.

Now consider this. The Windows API documentation is all written with examples in C or C++ and not BASIC. PowerBasic programmers have had to spend time translating most of this info into Basic source code. Yet when you see the PowerBasic version side by side with the C version, interestingly the PowerBasic version makes a lot more sense. Someone who never dabbled with the Windows API would likely be able to make sense of the PowerBasic version quicker than the C version, at least in my opinion I believe so.

We don’t need more cryptic programming languages today. What we need is more languages which follow the rule of “keep it simple” like Basic has done. Code should be more readble, not less. Add to this a compiler like PowerBasic which produces fast (and small) executables which rival anything you can build with a C compiler and you have a powerful combination.

For more info about PowerBasic check out their web site:  http://powerbasic.com

There is little doubt that Windows (x86) tablets may flurish when Windows 8 is finally released, so how can a business (or the enterprise) build software which can make the best use of the coming flood of Windows tablets ?

I am not personally excited about Metro yet, partly because I haven’t found a good way to develop Metro apps yet. Currently the only way to build metro apps is with Visual Studio and that is not a hopeful prospect for me. Why ?

I have two problems right now with Metro development. First is that I don’t have a Powerbasic Metro compiler yet (it could happen, but may be awhile). Second is that I dislike the current state of Microsoft programming languages. Visual Studio has been overrun by XAML and OOP. OOP makes software much more complex (read my other posts about OOP). Just taking a look at the sample code generated by Visual Studio it all appears very confusing to me. It is not readable code IMO.  OOP decreases performance and add complexity to software which makes building applications even more complicated. I thought learning the Windows API (WIN32) as hard, but Metro and the new WinRT just downright confuses me.

Now, even if I was able to have the development system I desire so I could build Metro apps, would it make sense to start only writing Metro apps for Windows 8 ?

No !

Why ? Metro only works on Windows 8, so any application written for Metro will only have a small available user base initially. While the inexpensive upgrade price that Microsoft will offer for Windows 8 (about $40) is very tempting (I plan on getting a few upgrades myself), I really doubt that any PC’s other than those running Windows 7 will be good candidates for the upgrade. Many XP and Vista computers have too little memory for Windows 8 and some computers may not have the proper video cards (or GPU’s) for Windows 8. Upgrading an operating system is not so pleasant when you have to also upgrade the hardware. Also the minimum resolution for Windows 8, so all the features work (ie. Snap) is 1366 x 768 and many netbooks and PC’s don’t have that resolution. Likely the best experience for upgrades will be for those who have more recent computers with Windows 7 on it. This is why when I purchased a tablet computer, I purchased one of the few (of the inexpensive ones) which has 1366 x 768 resolution (ExoPC). While the hardware can handle Windows 8, I did find some metro apps which seemed to not like the GPU (DirectX games) and simply would not run (at least on the consumer preview). Also some older tablets or touch screens are only 2 touch point capable as well, so will not benefit fully from the multitouch features (5 touch points) of Windows 8.

So the user base for building Metro apps will likely be limited for at least the first year or two. Some PC’s won’t be worth upgrading to Windows 8, some can be upgraded but will have a degraded user experience and some computers simply won’t be ready for upgrading. Since Windows 8 has full support for the desktop, at least for me personally I can see some real opportunities for build Win32 (desktop) apps for the next few years. First you have a larger user base, from Windows XP to Windows 8. Apps can be written to take advantage of touch as well as work well with the mouse. One downside I see though is that Aero is suppose to be removed from the release version of Windows 8. The Release Preview does not provide us with the true experience of Windows 8. What will desktop apps look like on the final version of Windows 8 ? We will have to wait and see.

I am excited though about the coming update to EZGUI 5.0 , which will be EZGUI 5.1 (free to all 5.0 users). I am working on adding support for touch and a few other things that will benefit PowerBasic users when building apps for Windows 8. Even in its current state, EZGUI has a number of advantages for use in building Windows 8 (desktop) applications.

First, because the desktop will change drastically in the final release version of Windows 8, programmers will have a bit less control of how their apps will look. Some may not appreciate the forced flat Metro style look it will have for desktop apps. Fortunately, Windows (since Win95) has had the ability to customize the look and feel of controls. This feature is called OwnerDraw (and also CustomDraw). EZGUI has long supported OwnerDraw and has many features built in so you can customize your applications forms and controls far beyond the normal features of these UI elements. For example, you won’t be stuck with everything being flat, when using ownerdraw. EZGUI easily can display 3D Buttons and customize menus and controls like the tab control, listview, listbox, combobox and label controls. You also have more control of colors and fonts for the toolbar, treeview and listview controls using customdraw.

EZGUI 5.0 also has a powerful graphic engine and graphics will be important for building the kind of quality applications one may expect for Windows 8. EZGUI 5.0 has its own Canvas control and an opengl based 3D graphic control. The nice thing about using something like EZGUI 5.0 (and PowerBasic) is that the applications you create can run on Windows XP to Windows 8 (actually even Win95/98/ME too). You can build apps which blend well with the Metro style, but not be limited by the forced Windows 8 Metro look for the desktop, while still being able to write apps which will run on the entire Windows user base (XP to 8) you may desire. Also unlike many of the current applications, creating using dot.net, EZGUI 5.0/PowerBasic applications run very fast and have a very, very small footprint (memory and diskspace for app) so they will run just as well on an old Windows XP computer with only 256 meg ram as it will on Windows 8 computers. You won’t limited even on older Windows tablet computers, no matter the resolution they are. This means you can write apps which will run well on old Windows XP tablets and the new Windows 8 tablets.

A small footprint is also vital so businesses can opt for the low cost Windows 8 (x86) tablets, rather than the more expensive models many manufacturers will bring to market. Much of the coming Windows 8 software will likely require the more expensive dual and quad core CPU’s to get the “fast and fluid” experience end users desire, while EZGUI 5.0 and Powerbasic will be able to be used to build applications which run very well even on tablets (and desktops) which have only single core CPU’s (plus the many single core Atom CPU’s available today).

While Metro may have some advantages, at least for the next few years I can see how well written desktop applications may actually be more practical. Imagine being a business and while the other companies are forced to buy all new Windows 8 tablets, just to run the software they create, by using EZGUI 5.0 and PowerBasic you can build applications which can span many of the current tablets you have, many older desktop PC’s and the less expensive choices of coming Windows 8 tablets. Imagine how much money that can save.

Imagine building applications which can look just as good on a multi-monitor desktop as they do on a tablet. Write applications so they can take advantage of what ever computer they are running on. With EZGUI 5.0 ( http://cwsof.com ) and PowerBasic ( http://powerbasic.com ) you can do just that.

PowerBasic 10 is coming soon!

You can see a preview of some of the new features here:    http://www.powerbasic.com/support/pbforums/showthread.php?t=46443

I want to discuss some of these new features that they have posted on their web site pointing out the ones I am most excited about.

Static Link Libraries (SLL’s)

I think this is the most important new feature in PowerBasic 10. Now third party developers can create libraries which can be embeded in the EXE, so users don’t have to distribute DLL’s. I definitely plan on converting some of my software to SLL’s. This does not mean though that DLL’s are some how obsolete. The advantage of a DLL is that its code can be shared among multiple applications, making the total application size much smaller. For example, EZGUI 5.0 will have a DLL runtime which about 700 KB in size. It is best to keep it as a DLL, since some EZGUI users will write multiple EXE’s for their application and they all can share the same DLL, which makes the entire application much smaller. Other of my tools are perfect for the new SLL format. EZSprite is a good choice for this. EZSprite is not a very large library and I can image a number of programmers distributing a single EXE with it. Even if a programmer needed to distribute two EXE’s , both with the SLL embeded, the extra size would not be significant.

Now smaller libraries, where the user may more likely only distribute a single EXE as well, may be better converted to SLL format. This one feature alone will make the upgrade to PowerBasic 10 worth it to me. (Note: I have already preordered PowerBasic 10)

Resources

PowerBasic 10 introduces the new and improved #RESOURCE compiler directive. Rather than compile a PBR file separately, you will now be able to simply define the resources in your applications source code and not have to use the RC.exe compiler. This is a welcome addition to the language.

FASTPROC

This is an interesting new feature. It is some kind of faster procedure calling mechanism, which is limited to two long parameters. The speed of execution is the key here. Procedure calls have a certain degree of overhead, which if called repeatedly can slow things down a little. Modular code design encourages putting code into reusable procedures. The problem is when a procedure may be called thousands or millions of times in a loop. One example is when what you write is graphic intensive. I usually avoid procedure calls in such cases, because I need the optimal speed. This new faster procedure call, may allow me to write such procedure calls and not take a hit in execution speed. Now two long parameters is not a lot work with, but I don’t see any reason those parameters can’t be pointers to large structures, so the procedure can be passed large amounts of data via a pointer. I have always appreciated new mechanisms to speed up code.

There are a lot more new features, but few of them are ones I personally would use a lot. This does not mean others won’t need them though. Check out the link I posted above and read about them yourselve. Likely some will appeal to you.