Six lessons I learned about writing software

From independent software developers to the enterprise, everyone is looking for ways to improve software development, increasing productivity while not sacrificing performance. Software technologies continue to change, but have programmers really found the real keys to faster development cycles, more reliable software and improved performance?

While it is obvious we have more powerful software today, this does not mean we have better software today. As it becomes more complex, there are more things that can go wrong. In the old days, software was often written by a single programmer, while today software often is written by teams. The complexity alone of trying to get a team of programmers to work together is challenging enough, but add to this the size and scope of some applications that can be hundreds of thousands of lines of code, if not possibly in the millions of lines of code, and you can have a veritible nightmare trying to put it all together. Few trades today require so much attention to details at such a large scope as does programming.


End users assume the software they use is reliable, but developers know the truth that all software is likely to have some bugs in it. Bugs! What an interesting term we programmers use to describe "errors" in our code. The term bugs may imply that the problems with software are some how external and not our fault. Those nasty little bugs, just keep sneaking into our software. The reality though is that bugs are errors, errors in logic, errors in typing, errors in passing bad parameters. They are introduced by programmers. Yes, when our software has bugs, it is our fault! We did something wrong and it is our job to fix it.

Education Fails To Teach the Skills We Need

In the years of old, when a skill was learned it was most likely done as an apprentice to a skilled worker or tradesman. The tradesman, didn't teach for a living. The trade was his job. He used it in real life.  As the student you learned from a master of a trade who did real work for real people. Imagine seeing the work of a real cabinet maker right before your eyes and hoping to someday be able to do the same thing yourself.

While I am a self-taught programmer, who dates back to the days of CPM even before the IBM PC became popular, I did actually take a college course on programming once. I can remember back in the late 1970s, when I attended Worcester Polytechnic Institute (WPI) and studied Fortran. In those days, one had to enter a program into a main frame computer using punch cards. I can remember sitting in a large hall that could seat hundreds of students and listening to lectures on how to write software. Not what I would call an apprenticeship for sure and definitely no real world training.

I left college for personal reasons, so I do not have a degree, but my interest in computers would later come to the fore, but as a self learner. In many ways, being self taught freed me from some of the problems associated with learning programming from so called "higher education".

One of the popular programming concepts to come out of the educational system is object oriented programming or better known simply as OOP. OOP has some merits, but rather than promote OOP simply as just another tool in a programmers toolbox, it was somehow transformed into the panacea for all programming ills.

But has anyone done any extensive testing to see whether OOP is significantly better than procedural style coding? It appears that little real world research has been done in testing this out, at least that is the opinion of one long time computer expert, Richard Mansfield. In his white paper entitled "Has OOP failed?", he discusses this in length.

I Find It Hard to Argue with a Skilled Tradesman

Richard Mansfield makes a number of interesting points in his white paper, but there is one thing that adds a great deal of weight for me personally. I am a self-taught programmer, but the term "self taught" is actually a misnomer. You have to learn from someone. Everybody needs a teacher. I simply chose to pick my teachers and learn by reading, rather than have my them picked for me (as in college). When choosing a book to learn something as complex as programming I had two criteria. The first, the author must really know the subject and second he or she should be able to explain it to me without all the fancy and big words so called educators like to use, but in simple terms which make sense. I don't want a thousand page thesis on a subject that could be explained in one or two pages.

Back in the 1980s, when the home computer was really taking hold, I learned about programming on a Commodore 64, which was a huge success at the time. While many self-taught, would-be programmers of the time played with interpreted BASIC, I used an actual Basic language compiler (by Abacus) and learning machine language too. Richard Mansfield's book on 6502 machine language taught me 6502 machine language in short order. I was the apprentice and Richard Mansfield was the tradesman. Before long I wrote my own compiler, which I used to create a video game that I sold to Compute Gazette, which earned me about $1,500.

It doesn't take long for me to tell whether the author of a programming book is a real tradesman or not. Does the book waste time with a lot of "educated nonsense" and theories about programming or does it quickly get down to work showing me how it is done in the real world and why? Richard Mansfield proved himself a tradesman. As an apprentice I learned a great deal from what he wrote about programming. I then used what I learned in the real world.

Lessons from Consulting

To make a long story short, I took a hobby and eventually turned it into a real trade, which I got paid for. In the 1990s, I got an opportunity to do some programming for local businesses. Programmers back then were not a dime a dozen like they are today. It was not easy to make an IBM PC (or compatible) do a lot of complex business work, when it was only equipped with a CPU of less than 25 MHz, 640 KB RAM and a couple floppy disk drives (or at most a 20 meg hard drive). I just have to laugh when I hear programmers today complain about the Intel Atom CPU, or a PC with only 2GB of RAM or a lowly onboard Intel GPU (graphics). They have no idea how far computers have come in only a few decades.

In doing work for local businesses, I quickly learned the difference between programming theory and reality. I can remember one early customer who spent about $5,000 on two Tandy IBM compatible PCs. He needed custom software for his manufacturing business, but there was no one available to do what he needed. So he talked to the local community college computer department and asked them if they could provide some help. They told him, be prepared to pay five times what he spent on his computers for the software. The guy just spent $5,000 and now he was told he would have to spend $25,000 just to get the computers to do something useful.

This businessman found me and within a hours time, he knew he found what he needed. I quickly showed him how to get the most from his investment and proceded to write his custom software. I didn't charge a lot in those days, because despite my knowledge of programming I still viewed myself as the apprentice and not the tradesman yet. I wrote a complex software package that handled job estimating, job tracking and invoicing. I even designed my own network using a serial cable between two computers so he could have both computers work together. And I wrote the software using Basic, plus a little machine code added in.

The real test of a programmer is being able to write software that is reliable, within budget and with performance. In those early years I can even remember using a stopwatch and actually testing my database routines for optimal speed. I even would test different buffer sizes for the optimal size that would work best with the mechanics of the hard drive.

So doing real work for real businesses taught me a few important lessons that I doubt I would have learned in college:

1. Development time is critical, especially for custom software. This is one reason I never stopped using Basic. Over the years I checked out other languages, like C, but I never found any languages that had the naturalness of Basic. My code was easy to write and easy to read. Code readability is a must if you want reliable software that can be maintained.

2. Performance is always important. Even when I used interpreted Basic I optimized for performance.  When compilers became available I quickly moved to using them. When using assembler was the only way to accomplish something or to get the performance I required, I used it.

3. Productivity depends upon the ability to reuse code, and building quality library code is always important. OOP supposedly is superior for code reusability, but I have found that procedural code can produce just as good reusable code. Code reusability has more to do with the mindset of a programmer, rather than a technology like OOP. A good programmer knows when and how to build a quality library.

4. The less code you have to type the faster it gets done. Quality libraries can decrease the amount of code you have to type in, but also how you code makes a big difference. If speed is not critical for a subroutine or function, then writing it so it uses the least amount of parameters may be more valuable and in the long run will save time.

 5. The programmer is the debugger. Debugging is a skill or even an art. Programmers today depend too much on automation to do their debugging. No software debugger, no unit testing application or any other automated tool can replace the programmer's mind. If debugging is an issue, then the programmer is at fault, not the tools.

6. Keep it simple. Yes, the programming language you use, the development environment you use, how you code and even how you build reusable code should all follow the principle of "keep it simple". This is one of the biggest reasons I actually avoid OOP, which demands too much complexity and too much planning and the benefits of so called code reusability are not any better than procedural. Actually procedural coding styles can produce smaller executables, with less code, easier to maintain and most important faster (performance).

Many people will likely want to debate this point, but I can simply point to the obvious bloat in most software today. Remember, I come from a day when a person could write something like a complete accounting package (or any business app) that could run on a computer with only 640 KB RAM and two floppy drives. Today's huge UI frameworks that are 20, 30 or 40 megabytes in size says something. I can remember when some amazing programmers could build a Mac-like (or Windows) environment even with multi-tasking that could run on a Commodore 64 with only 64 KB memory (the software was called Geos). Today, Windows despite having benefits of 2GB memory or more requires a great deal of page swapping with the hard drive, just to keep pace.

Reconsider How You write Code

Now I won't say don't use OOP, which has value, particularly with some UI stuff. All I am saying is at least reconsider whether to always use OOP or not. Just because the majority of programmers have swallowed higher education's view that OOP is superior should not prevent you from considering a more balanced approach of using procedural coding first and then OOP when it really does fit the task at hand. Just for the sake of discussion and an open mind, do a Google search for the words:

Google "software performance productivity OOP procedural" and see what you find. Some of it may be nonsense, but there are a number of good programmers out there who are rethinking how they write code. Even some who use OOP regularly, have issues with it.

Regardless of whether you prefer to use procedural or OOP, take a second look at how you write code and ask yourself whether it really does follow the principle of "keep it simple". Is the code easy to follow? Is the code easy to read? How difficult is it to follow the flow of the code (the actual order the computer will execute it)? If it is difficult to follow the actual flow of the code, then simply put it will be a nightmare to debug.

A Tradesman is a Better Teacher than an Educator

If you have ever worked closely with a real tradesman (or woman) of any sort, like a carpenter, a mechanic or even a computer programmer, who really knows the trade, it is amazing when he (or she) can quickly show you not only how to accomplish a task better but also explain why it works. I can remember when my father, who was a plumber most of his life, showed me how to properly solder a joint in copper water piping. It was a little trick he had learned, and it was quite surprising. He said that some  plumbers like to make their solder joints look pretty, so they carefully run the solder around the joint. It sure looked nice, but many a time he had to go to a job to fix pipes that busted just because of this. His technique was to put a little flux on a flux brush and after putting the solder on the joint, while it was still fluid he quickly wiped around the joint with the brush as if he were wiping it off.

The end result was not pretty. Some plumbers would take one look and say it looked terrible and messy. Then my father unsoldered the pipe he just connected and showed me the inside of the joint. He told me the wiping action with the flux brush caused the solder to get sucked deep into the joint and when I saw what it looked like inside I knew he was right. The joint didn't look pretty, but it was much less likely to bust when under pressure.

The point is that the real test of the quality of anything is when it is put under pressure (or used in the real world). Software is no different. No matter how one writes software, the real test is whether the software is good or not. Does it work as intended? Is it easy to use? Was it done under budget or even faster? Is it reliable?

I am amazed at how often programmers will quickly see the word "BASIC" when I refer to how I write software and automatically come to the conclusion that this guy does not know what he is talking about. Who uses Basic anymore they will say. But the real test of any tradesman is what he has built and if it is being used by others successfully. I can honestly look back at much of the software I have written and feel a sense of accomplishment when I see how it benefited the businesses I wrote it for. Some of that software is still in use even after 10 or 15 years, because it works so well.

Today I write programming tools for other programmers and when I see a customer using my tools to build their software and they are successful it means a lot to me. Then I remember what my father said about how others viewed his technique for soldering copper pipe. All I can say is "thanks dad, you were right". If he were alive today, I would venture to say he would be happy to know I still solder pipes the way he taught me all those years ago and if asked why I do it this way, I can easily explain the reason "why" it works, because a tradesman taught me well.

When some people take issue with the white paper by Richard Mansfield about "Has OOP failed?" I tend to feel similarly. Maybe it's how we teach programming today that needs to change if we want to have better programmers.

Photo Credits:  kentoh/Shutterstock

Chris Boss is an advanced Windows API programmer and developer of 10 year-old EZGUI, which is now version 5. He owns The Computer Workshop, which opened for businesses in the late 1980s. He originally developed custom software for local businesses. Now he develops programming tools for use with the PowerBasic compiler.

101 Responses to Six lessons I learned about writing software

  1. jcollake says:

    There's always at least some merit to your arguments. However, there is also an obvious reluctance to change. I won't go into detail on your every point.

    Trust me, there are plenty of great programmers out there who can code in x86 assembly on up. Who do you think discovers these security exploits, for instance? I was programming for DOS, and before that the TRS-80, I'm not a 'newcomer'... I have an education, but was self-educated long before that. The education was valuable to me, more so than I realized at the time. It helped to round me out a bit, giving me a wider view on things. It did not indoctrinate me into anything specific.

    I don't mean to say I'm the best programmer in the world, there are lots better than me, and I wouldn't think to lecture them. And that's the point really ... it feels like a lecture about how the younger generations have it all wrong. The ironic thing is it is coming from one who practices BASIC, and has an acknowledged lack of full knowledge of even C. I'm sure [Power]BASIC is great as Rapid Application Development, but you're not going to write an OS in it (I would hope ;p).

    You learn a language, and sure you tend to stick with it -- its easier. But, you gotta remember its place in the universe ;)

  2. jcollake says:

    In addendum to my previous comments, its the assertion that as a BASIC programmer your knowledge of programming in general is superior to that of professors and other tradesmen with much more experience in a more diverse number of languages and platforms than yourself. Granted, that may not be your INTENT or even your attitude. However, it is how you come off, at least to me.

  3. chrisboss says:

    Some may wonder, why not simply learn another language like C or C++ or Java ? Personally I have found that for me, it is better to know one language really, really well rather than to be a "Jack of all trades, but master of none". No of course, some may have a much better mind than me and can learn multiple computer languages, but the differences between languages can be so drastic that I still ponder whether it can cause some confusion when switching between them. If there is a second language one should learn, then IMO I think assembler (machine) language would be a very good choice. The more one understands machine language the more it will effect their views of a higher level language. Now as far as the comments about "higher education", I am not against education by any means, but it is interesting that OOP really got its push from educators as the panacea for all ills, but after many years of OOP being touted as the solution to all programming ills, there are still a number of who question whether it really is as good as it has be sold to us as. Now as far as knowledge of programming for Windows is concerned, remember I work with the pure low level of the Windows API, rather than depend upon large UI frameworks, so I get to see how one can tap into the power of Windows at a lower level.

    • jcollake says:

      OOP is not the solution to all ills.. 
      I don't think anyone would claim it is. Bad code is bad code, whether OO or free function. I used to never use OO, only x86 assembly and C with free functions, then - after immersing myself in it - I found it to be superior, when used correctly. There are reasons it is so widely adopted, and - ironically - many of them are to fulfill the ideals you list above. I now mostly code in C++, because I have much more extensive experience in it. Fortunately, its syntax transfers easily to a lot of other languages. I'm no jack of all trades, and at this point you're making excuses.. How about this -- WHY not learn at LEAST one other language, just for fun?

      Also, I work with the Windows API directly too.. in fact, probably at a lower level than you at times, utilzing the NT native APIs, or kernel mode code for that matter. Directly calling the Windows APIs doesn't make a point, to me. I don't use any large UI frameworks, that's for sure (no abstraction layers.. no MFC, no BS). That said, frankly, using the Windows API is easier than using some of these UI abstraction layers (which do offer compelling benefits, at a price). I don't criticize those who use them, because the overhead is often quite minimal, and the output worth it.

    • jcollake says:

      OOP is not the solution to all ills.. 
      I don't think anyone would claim it is. Bad code is bad code, whether OO or free function. I used to never use OO, only x86 assembly and C with free functions, then - after immersing myself in it - I found it to be superior, when used correctly. There are reasons it is so widely adopted, and - ironically - many of them are to fulfill the ideals you list above. I now mostly code in C++, because I have much more extensive experience in it. Fortunately, its syntax transfers easily to a lot of other languages. I'm no jack of all trades, and at this point you're making excuses.. How about this -- WHY not learn at LEAST one other language, just for fun?

      Also, I work with the Windows API directly too.. in fact, probably at a lower level than you at times, utilzing the NT native APIs, or kernel mode code for that matter. Directly calling the Windows APIs doesn't make a point, to me. I don't use any large UI frameworks, that's for sure (no abstraction layers.. no MFC, no BS). That said, frankly, using the Windows API is easier than using some of these UI abstraction layers (which do offer compelling benefits, at a price). I don't criticize those who use them, because the overhead is often quite minimal, and the output worth it.

    • jcollake says:

      OOP is not the solution to all ills.. 
      I don't think anyone would claim it is. Bad code is bad code, whether OO or free function. I used to never use OO, only x86 assembly and C with free functions, then - after immersing myself in it - I found it to be superior, when used correctly. There are reasons it is so widely adopted, and - ironically - many of them are to fulfill the ideals you list above. I now mostly code in C++, because I have much more extensive experience in it. Fortunately, its syntax transfers easily to a lot of other languages. I'm no jack of all trades, and at this point you're making excuses.. How about this -- WHY not learn at LEAST one other language, just for fun?

      Also, I work with the Windows API directly too.. in fact, probably at a lower level than you at times, utilzing the NT native APIs, or kernel mode code for that matter. Directly calling the Windows APIs doesn't make a point, to me. I don't use any large UI frameworks, that's for sure (no abstraction layers.. no MFC, no BS). That said, frankly, using the Windows API is easier than using some of these UI abstraction layers (which do offer compelling benefits, at a price). I don't criticize those who use them, because the overhead is often quite minimal, and the output worth it.

    • jcollake says:

      OOP is not the solution to all ills.. 
      I don't think anyone would claim it is. Bad code is bad code, whether OO or free function. I used to never use OO, only x86 assembly and C with free functions, then - after immersing myself in it - I found it to be superior, when used correctly. There are reasons it is so widely adopted, and - ironically - many of them are to fulfill the ideals you list above. I now mostly code in C++, because I have much more extensive experience in it. Fortunately, its syntax transfers easily to a lot of other languages. I'm no jack of all trades, and at this point you're making excuses.. How about this -- WHY not learn at LEAST one other language, just for fun?

      Also, I work with the Windows API directly too.. in fact, probably at a lower level than you at times, utilzing the NT native APIs, or kernel mode code for that matter. Directly calling the Windows APIs doesn't make a point, to me. I don't use any large UI frameworks, that's for sure (no abstraction layers.. no MFC, no BS). That said, frankly, using the Windows API is easier than using some of these UI abstraction layers (which do offer compelling benefits, at a price). I don't criticize those who use them, because the overhead is often quite minimal, and the output worth it.

    • jcollake says:

      Actually, my final statement would be... BEFORE you criticize OOP so much, you should learn C++. Without learning it, you have not earned the right to criticize it. I'm sure you're an expert, and can get whatever application coded in PowerBASIC (up to a limit, you aren't gonna write a kernel mode driver in PowerBASIC). The choice of language is important in any project, especially now with Web applications. Therefore, knowing more than one is actually imperative these days.

  4. chrisboss says:

    I am sure there are many excellent educators in the computer field today (and in the past), but there is something to be said about learning a trade from those who do the real work rather than those who simply educate for a living. IMO programming has been made over complicated. I also don't think we get the full benefit of the hardware today because of programming methods which produce slower and more resource hungry software. If the guys who wrote Geos for the Commodore 64 were to write an OS like Windows today, it would be faster, more fluid and would run in 256 meg RAM and the Atom CPU would be viewed as a powerhouse CPU.

    • jcollake says:

      Things have also changed A LOT since then ... the entire software and hardware environment. It is a lot more complicated field. Sure, there is some truth in that old saying "Those who can't, teach".. as insulting as it may be to some professors, many of whom are very intelligent people, but simply not cut out for the dog-eat-dog world of business.

      Remember, the C64 hardly had a user interface anyone but computer science enthusiasts would appreciate. If those programmers were to have duplicated Windows, things would be a different story. The necessity for a complex framework evolved because of the complex environment.

  5. jcollake says:

    I'd also argue a big thing you miss is that often times the *algorithm* you use can make all the difference in the world - and this is where college really helped to round out my existing programming knowledge. A fundamental understanding of the classic search, sort, and compression algorithms is imperative. Without such, you do silly things like doing a linear search for a string through a huge data set, instead of using Boyer-Moore... or searching a sorted array by checking member by member instead of using a binary search.

  6. chrisboss says:

    jcollake, I can appreciate your comments. No, I am not a C or C++ programmer, so I may not fully appreciate some aspects of C. Yet, considering Richard Mansfields white paper, even he comments on Basic and 4GL languages having a more natural syntax than C or C++ and this is the reason I use basic. I don't use Basic simply because I can't learm C. I use Basic because it is more natural and readable than C. One of the lessons I mention in my article of "keep it simple" is a valid point. If a programming language provides me with all the power I need (even OOP if I require it) and it is more natural in syntax, then why would I want to learn a language which is more complex, less natural just because everyone else uses it ? I can write software for todays Windows tablets with a smaller footprint and excellent execution speed so what am I missing out on ?

    • jcollake says:

      And I can appreciate your argument, which is why I said some of your points have merit. For YOU BASIC is more natural and readable than C, for me its not - because I don't use BASIC every day. Is it for most programmers? I don't know ... that's a tough philosophical question. They do use it as an introductory language for a reason I suppose.

      Indeed, if it works for you and your requirements, then I have no problem with you using PowerBASIC, or whatever you need or desire. However, once you get to know OOP, you really learn to appreciate its benefits, which are HUGE - and like I said - do mirror many of the principles you state here.

      Anyway, keep writing, it is good for debate if nothing else. I too sometimes miss the old days, but with multi-threading, self-managed code (as opposed to managed code), and multiple contributors to projects, OOP is something I can't imagine living without.

      I am not sure your statement about writing software with a smaller footprint is true. Sure, you can write smaller code than a .NET application (managed code), but not a native C/C++ application. The best you could hope for is something that performs as close to it, or has a similar memory footprint. That said, if there's no substantial penalty, then you are right ... go for it. If it works for you. However, what works for others works for others for a reason.. not because it was a cult ;p.

  7. Rankine Zero says:

    I do not really see the problem with OOP.For me OOP means "structured and readable code" with the added benefit of inheritance from ancestor classes.

    Maybe it means something different to you ?
    Why someone would knowingly write unstructured code is beyond me.
    Maybe you have a strong control over your own code and can write structured code without using OOP, but in a dev team the result of that approach over a long period results in a mess of spaghetti code and local implementations and re-implementations of things that should have been in shared classes.

  8. chrisboss says:

    Procedural style code does not mean unstructured ! To assume that procedural code somehow is less structured than OOP is wrong. I design extensive UI library code, which a number of other programmers must use for their work , so it is possible to build quality reusable libraries using procedural style code. OOP actually adds complexity, not decreases it. OOP requires more up front planning than does procedural. Procedural style coding lends itself better to a more agile style of coding too. Procedural style coding also lends itself to easier tracking of code flow. If there is one thing I consider vital, it is the ability to debug code (and quickly). Procedural style coding is easier to debug IMO.  The event nature of Windows is itself is difficult enough alone when it comes to tracking code flow, but then add the complexity of OOP and debugging becomes even more difficult. Somehow programmers accustomed to OOP think that procedural style programmers are in the dark ages and know nothing about modular design, code reusability and structure. Trust me when I say that a procedural programmer can write software with just as much modularity, structure and reuse as an OOP program can.

  9. Lord Dcee says:

    I've been object oriented coding for 10 years and my code has always been readable. 
    The difference between readability and confusion is never related to the programming language or the paradigm used. It is related to the coder.

    The best example I can find is SQL Code. You can open a stored proc and cry for 3 days while trying to understand it, even if it's really an easy language to read. 

    I worked in support for Bridgestone and almost all of the business intelligence was in stored procs. You could be called at 3AM for a production problem, open a stored proc with eyes half closed and still understand the SQL Code and what it's supposed to do.

    Then, of course, if you don't know a language or a paradigm, yes, it can be hard to read the flow, but once you know a language or a paradigm, the readability and flow is only dependant on the person who coded it, procedural or not.

  10. Lord Dcee says:

    Well, honestly, I've seen quite my share of "spaghetti code and local implementations and re-implementations of things" even in OOP code... 

    (that was supposed to be a reply to RankineZero, discus went crazy)

  11. chrisboss says:

    Quote :  "spaghetti code" 
    Richard Mansfield in his white paper touches on this. Somehow OOP programmers think that procedural code (especially Basic) is all "spaghetti code". That is the furthest thing from the truth and something a college professor would say to scare students away from languages like Basic. Today, experienced Basic programmers can write highly modular code, and with or without OOP. 

  12. chrisboss says:

    And please remember. I haven't said to "never" use OOP. All I am saying is that OOP needs to be just one tool  in the toolbox, rather than some kind of "do everything" tool which replaces all others. Procedural style coding has many advantages too ! While I can currently write all the code I need without a single line of OOP code, this does not mean I could not find some use for it if it really provided some benefit.  If it fits the task then it should be used. It is just that most of the time it is not required so why add extra complexity when it is not required.

    • Lord Dcee says:

      Do you have an example that would fit the OOP paradigm for you?

      • chrisboss says:

        OOP does well with UI frameworks, but even there I find I can live without it. The point is that not everything needs to be an object. Now COM components do make some sense since they can be developed and be used in multiple programming languages. But even there I really don't like COM components because they need to be registered with the OS. If the Windows registry gets trashed in any way then COM components can get messed up if their registry info is lost. DLL's have been around a long time and DLL's written without the need for COM are actually much easier to deal with IMO. I can write large complex apps, which can simply be copied to a folder and run. No install app required, since no COM components to register. Want to run the app on a flash drive ? Just copy and go. Also the nature of objects adds overhead. Now if someone can post some links to any serious studies done which compares OOP to procedural coding to determine which is more efficient and productive it would be appreciated and I would definitely take the time to check them out.

      • StockportJambo says:

        How would you implement a data abstraction layer or business model in Basic? I'd really love to know how you'd approach such an everyday task.

  13. I think you have to give a better name to the language you use instead of simply "Basic". Visual Basic .NET is still "Basic" but it has OOP, type safety and all the features that make programming so much less error prone and safe. It's funny how you picture the world as if there's only Basic versus C/C++. That is amazing. How about mentioning C# or Java for a change ? Do you really think your "Basic" code is more readable than C# ?

    When I started programming in .NET (after having programmed all sorts of environments from assembly to Basic to Pascal to C, Borland C++ to Win32) I had to make a choice. Either go for a language which I already knew (Basic) or learn a new language all together. I opted for C# for its superior readability than Basic. C# is neater and easier to read. Basic seems bulky and shabby. Now that is just my opinion. Some people would prefer Basic or C++. (I can still use the other two languages if I need to).

    I still remember the days when I programmed in a 16-bit DOS environment and was mimicking the animated hourglass cursor in Windows 3.1 under DOS environment using Pascal and Assembly language. Those were the days! (and what a waste of time!!!!!!)

    You still mention the use of Assembly language in your coding. Now what about targeting ARM processors. Will you have to write your code all over again to target ARM processors ?

  14. chrisboss says:

    Obviously there are many consideration when choosing a development language. Cross platform is one for example. Programmers who target both Windows and Linux or Windows and Mac OS rightly need to choose a language which can handle multiple platforms. as far as cross platform development, especially targeting mobile I find HTML5 most interesting. Now when it comes to native development where performance is critical nothing beats using a language specific to a platform. Cross platform always requires comprimises, but native coding does not. Since Windows (x86) is currently the largest platform, using a language which specifically targets Windows makes sense for many programmers. Now when I refer to Basic, simply read my author bio and you can see I don't use Visual Basic, but use PowerBasic (great grand child of the famous Turbo Basic). It does not require any of the resource hungry UI frameworks and one works directly with the Windows API. It supports OOP if you require it (COM classes), but it is not required nor is it built upon COM. One can write 100% procedural style apps with it. It supports multithreading, inline assembler, UDP, TCP and serial communications. It is not cross platform though, but targets WIndows only.

  15. vincentw56 says:

    OOP isn't the problem you make it out to be. The problem is the developer. Don't give me BS about it being OOP fault. You can create crappy BASIC programming just as easily as you can with OOP. I started programming BASIC on a TI 99/4A. I've been programming for a long time.

    There are reasons things like design patterns, TDD, BDD, and DDD have been created. To help programmers be better programmers. To say OOP is bad only shows your ignorance. This is the same argument I've heard from C/C++ developers. OOP and managed code make you a dumb programmer.

    What the real problem is that most people think just because they opened Visual Studio Express or created a batch file, they are programmers. "I 'programmed' the computer to do something! I am a programmer!" Uh, no you are not.

    I can't say if procedural code is better or OOP. I use OOP everyday. I won't make that comparison because I don't know, unlike your articles damning OOP (which you seem don't use). The tool isn't the problem, it is the person using the tool. On that we can actually agree.

    BTW, I have done plumbing and wiring in my house so that must make me a plumber and electrician. I guess if programming doesn't work out, I could always switch to a different profession. :)

  16. chrisboss says:

    I am curious how many who read this article have actually read Richard Mansfields white paper it links to. I greatly respect Richard Mansfields knowledge and experience and how many of us can say they have written 38 books. I learned 6502 machine language quickly from one of his books. Now Richard Mansfield, unlike me, does have a lot of experience with OOP and some of his books are on OOP based languages like Now I simply grasp and appreciate his viewpoints on OOP, since I have write all my software today without any OOP at all. Now I honestly recognize that OOP may have it uses, even if I haven't personally had a neww for it. I can see the value of encapsulation (data inside the object). So I am not trashing OOP nor encouraging anyone to totally embandon it (likely not possible if you use a Microsoft language). What I am saying is that OOP is not the programming panacea it was originally touted to be. Now was it more questionable is many programmers negative views of Basic (a modern version of course) and also of purely procedural style coding. Now this I can honestly say from experience is that something is wrong with software today when one  simply looks at the size of many applications today. I just downloaded Visual Basic Express 2010 and it took 2.3 gig of hard drive space to install. Now who in their right mind can say that is indicates efficiency ?  I use a programming language with installs to about 10 meg and even my own GUI engine and Visual Designer which I wrote only needs about 10 meg to install and its GUI engine runtimes only 1 meg. And with that I can do what WinForms can do (Forms/Controls/Common Dialogs,printing) and multithreading, subclassing, superclassing, ownerdraw, customdraw, MCI, Turtle Graphics (vector graphics), low level DIB access (direct pixel manipulation), 2D proprietary Sprite engine with alphablending and antia-aliasing, 3D OpenGL based scripting language and more. Now what does the Visual Basic Express extra 2.2 gigabytes give me ! A programming language which takes up 2.3 gig ? Visual Studio is even worse. Now when I can see developers who use Microsoft programming languages, especially using OOP or, write software with the small footprint I can now using BASIC, then maybe I will reconsider.

    • I have read it. I would clarify a few thing from someone that has been doing this along time as well. I have been programming professionally for 26 years and as a hobby for over 30. I have also taught at the university level while working a full time job in the industry so I do agree about your point on trusting "tradesman" vs. pure academics. Have seen it a million times.

      One area of vastly needed improvement is that most schools tend to teach OO from an inheritance model (inheritance being king). That is where OO falls apart in my opinion. This class is a vehicle, this is other one is a car which implements part of vehicle, etc. ... on and on ad nauseum. You end up with unmanagable inheritance hierarchies. Worse, many times, than procedural spaghetti code. BUT it doesn't have to be that way.

      If we look at it practically it is REALLY about behavior. Classes are NOT things. They BEHAVE like things. So really the power is in polymorphic behavior. That's where the OO design really shines and you gain a much higher rate of resuability than just large libraries. Especially true in large integrated systems or for companies with diverse development staff working on large initiatives together (and with outside consultancy as well). With the proliferation of service based integration OO can also really shine in creating nicely abstracted interfaces that are resuable ... again most powerfully with a polymorphic behavior mind-set.

      For the "students" and those looking to grow out there I would continue to say (and I am a hiring manager for a Fortune 500 company) you can't just know BASIC and be very "portable". Learn Java; Learn .NET (preferrably C# but VB.NET is fine in many organizations); Learn PHP. Like it or not that is the "stuff business systems are built on". In 2011 Java, PHP, C#, C/C++ were still the topic languages in use per several studies. (example:

      I think the development community would see a lot more value in spending time learning more about design patterns and thinking of OO design as set of behaviors, using it where it is most valuable, and not necissarly fighting holy wars. ANY language can allow a sloppy, lazy programmer to write spaghetti code. It takes time learning good practices and a mind-set to do the right thing that are transformative. ~ Vince

  17. StockportJambo says:

    I'm not going to comment on the OOP vs Mickey Mouse language argument here, because I've made my case in comments to other articles you've written and it's clear you're never really going to 'get it'.

    But what I will say is that the thing you have to remember about any CS degree is that the whole thing is set up 10-15 years before it reaches the classroom. That is, a proposal is made by an educator saying "We should teach X", then it goes through multiple levels of red tape & revision (which literally takes years) before it's actually taught in academia.

    This is acceptable for fields which don't really change that drastically over time - e.g. psychology, biology, business management, etc - because the principles remain constant. But for computing & technology-related degrees generally, it's a killer.

    I did 3 years of a computing degree and left for personal reasons. What I "learned" during that time would make your hair stand on end - and certainly had absolutely zero use in the job market.

  18. Han says:

    I can't believe there's only been one mention of design patterns on this
    page so far. If there's one thing I've learned (and I can't say my 16
    years has taught me much), is that when I'm a part of the establishment
    in a company/Org... Make sure the people I bring in have a software
    engineer's mindset and not just a mercenary programmer's mindset. They
    need to at least be aware of TDD and design patterns, if not have
    already been practicing it.

    Getting a bunch of software engineers, whose average lifespan at any one
    job is less than 12 months, to subscribe to certain patterns that you
    use at your place is more important than having a bunch of programmers
    who always like to create efficient but disparate little silo

  19. vincentw56 says:

    I went out to the PowerBasic web site just to see what it is like. Well, if the web site is any indication, it is really stuck in the 90s. The web site is horrible. Looks like someone used "insert crappy WYSIWYG HTML editor here". Just plain awful. They should be ashamed at trying to sell anything with that web site.

    That being said, I did read up on it a little more and looked at some of the screen shots of the product. Man, it takes me back to the old days of Windows 3.11 and 95. Not a good thing. Blah! I know a lot of "old" programmers that are stuck in their ways. I'm an old programmer too, but I like to move forward. Why even
    move away from "green screens"? Who needs fancy graphics or good
    looking applications?

    I think I will stick with my tools even if it is "bloated" as Chris would say. At least I won't feel like I am going back in time and not forward.

    • DigitalSin says:

      I felt the same way when I first took a look at PB. The site sucks, there are no two ways about that. Programmers don't usually make good web designers and should really put a few bucks into letting someone else make your stuff presentable.

      Despite that, I bought a copy of PB and I'm impressed with it. The compiler is insanely tight, it's pretty easy to get a good looking windows app going (it doesn't have to look like Win95 UI, you can incorporate themes). It's really nice being able to throw together an app and not having to worry about what version of the .NET redist the end user is going to have. Yeah you lose some of the intrinsic ease of use the .NET framework gives you, but you also lose the bloat we tend to accept as standard fare now in app development.

      My only complaint about it is there is no web stack unless you use FastCGI. I hate CGI and I just can't see myself making an enterprise level web app based on such a non-scalable mechanism.

      • StockportJambo says:

        There's an argument to suggest nowadays that .NET is so intrinsic & widespread now, that it's available on every Windows PC (at least to .NET 3.5). The only thing I occasionally have to consider is .NET 4.0, but there are a few ways around that. One is to build the check into the installer, and download the client framework (a cut-down version of .NET runtime which gets the user up and running quickly) if needed.

        As for Basic, the lack of basic (no pun intended) functionality like server side web components or AJAX controls is a deal breaker. As I think it would be for 90-95% of developers out there.

        Fun to play with. Utterly useless in the real world.

      • DigitalSin says:

        @StockportJambo:disqus You're certainly right in that it's less of a worry today about whether the .NET runtime is installed on the end user's machine than in the past, but honestly if you're developing a client side application that's going out to a decent sized audience, you still need to work in some kind of check / bootstrap for the few people who have 1.1 or 2.0 still running on their machine.
        The bloat I was referring to wasn't just about framework runtime being or not being physically already installed when distributing a specific app. I also don't consider that part of my app's final size. It's more about memory management of the CLR. I've seen (including my own) .NET apps growing so absurdly large in memory for fairly simplistic functionality it's mind boggling. They always shrink back down and are released properly when the app shuts down, that's the whole point of garbage collection, but it's such a waste of resources I think. I know a lot of variables play into that like using 3rd party components, heavy UI libraries, specific assemblies being used, caching locally large datasets, etc but I think because many devs know there is garbage collection, they think it'll all just magically work fine with minimal performance impact. It's a mindset of waste, and it's partly why our computers have gotten faster and software hasn't really gotten a lot faster.

        Anyway for PB specifically, the lack of a good web stack will limit it to just being in my arsenal for quick utilities that need to get developed & distributed, but probably nothing hugely serious since most of my work these days is web oriented. I'd be interested to find some way to get PB on the web in a more modern way; with such a small footprint and fast execution it'd make a hell of a backend app server for executing business / data logic

      • StockportJambo says:

        I agree that lazy programmers (and we've all done it) rely too much on .NET's garbage collection, which is optimistic at best. It's tempting to do that, because we can. As I'm sure you know though, it's perfectly possible to control the GC in code & effectively override .NET's GC timers.

        In my previous job, for the application we were developing, we used to have a development phase for about a month, then we'd stop and have a two week "optimisation" phase. During that two weeks we'd spend the time running profilers & memory tools to see where optimisations could be made. Once we'd done all we felt that could possibly be done, we'd re-start development again, and so on.

        Point is, it's down to the developer. C# .NET will cheerfully give you all the rope you could possibly need to hang yourself, but ultimately it's up to you to decide what to do with it.

  20. chrisboss says:

    Want to see the power of PowerBasic in action ?

    Check out this web site: and see his amazing GDImage and WinLift tools. GDImage does some amazing graphics and when you see the size of the library (DLL) you will be surprised. This guy pushes the limits of graphics allow you to do all sorts of fancy graphics and animation. The library is a bit low level, but it is powerful. This is an example of the kind of programmers using Powerbasic. Also check out the "who uses PowerBasic" page on PowerBasics web site. Some very big corporations are using PowerBasic. If I were to sum up what PowerBasic is, it is this: "PowerBasic is what C should have been". It provides one with the power of C, but with the ease of Basic. It is a rock solid compiler too.

  21. chrisboss says:

    The key to agile (fast) software development is simplicity (aka. "keep it simple"). Didn't know much about "design patterns" for OOP, so decided to browse the web and read up on it. Obviously OOP has its problems and patterns are suppose to improve development. From what I can gather they are simply templates to help build classes. The descriptions of patterns and what they do I found so complex that alone confused me. Why don't they just say "let's make some templates to make building objects easier". The point is that software development has become overly complex today, not because it has to be, but because those who keeping trying to come up with solutions keep adding complexity, rather than decrease it. Richard Mansfield was right when said that those who use OOP will say to those who don't, basically 'you just don't get it'. That's right. Procedural programmers like myself don't get it, because it turns what should be simple into something overly complex. That is not productivity in my book. Now I strongly support automation tools (aka. templates, code generators, etc.). I even wrote my own drag and drop visual designer and code generation tool, so I believe in using automation tools (RAD). I built a GUI library, so I believe in reusable code. I use BASIC, so I believe in code readability. I use PowerBasic, so I believe in performance. Yet all of this follows the principle of "keep is simple". If I someday find a use for OOP I will use it too. The real question is how fast are you developing your applications ? If the IT dept. needs a nice small app, do you do it in a hour or two ? If the IT dept. needs a slightly more complex app can you finish it in a day ? If you are building a full blown application, can you do it in a few weeks or a month ? How reliable is the software you develop, even if you can create it quickly ? Can your software run just as well on the companies old XP computers as it does on your Windows 7 development PC's ?

    • StockportJambo says:

      "Why don't they just say "let's make some templates to make building objects easier"."

      Because that's not what they are. You can use design patterns just as easily in procedural languages as well as OOP ones. They are more about creating a framework to solve problems. You probably use patterns every day without realising it... for example you handle events using an Observer pattern, when you only want to create a single instance of a 'thing', you use a Singleton pattern, instantiating those 'thing's based on arbitrary criteria would be a Factory pattern, etc.

      They work better in OOP, but that's only because (done properly), OOP is intrinsically simpler, requires less typing, & is less error-prone than procedural languages.

      • DigitalSin says:

        Does it really require less typing? I'm not sure it does. Do you mean because of Intellisense it's less typing? I hardly think you can define how good a methodology is based on a feature implementation of a specific vendor's toolset.

        Is it less error prone? I really think that depends entirely on the design & implementation. I can't tell you how many times I've jumped into projects where there is layer after layer of abstraction, with most layers doing absolutely nothing except calling another layer, all for the sake of "good" and "consistent" OO design. It makes debugging a total pain in the ass, so I really don't see it as being less error prone than procedural, structured programming. It's certainly nowhere near simple.

        I'm not anti-OOP, I just feel like we use it because that's what we were taught to do and don't really question it much. Questioning isn't a bad thing, getting religious about a specific methodology be it procedural / structured or OO and not keeping an open mind, that's pretty bad.

      • StockportJambo says:

        @DigitalSin:disqus Yes, it does mean less typing. A properly designed object model means that to add functionality to an application means inheriting from a previously debugged "black box" style object, and only adding the functionality required - without any boiler plate code that's already handled further up the hierarchy.

        And you're right - as far as error prone goes, it does very much depend on the design... however, if your base level classes are sound, there is less scope for errors during specialisation of those classes.

  22. chrisboss says:

    Just to test my own tools, I like to write sample apps, which are basically just quick useful apps which test certain features of my library code. Let's say you were asked to write just a quick prototype (nothing fancy) of a 3D model viewer, which can display STL 3D Models with thousands of polygons (how about 1/2 million) and then display them in 3D using OpenGL. It has to be able to load a large STL file very fast too. Here is a small 3D viewer (displays STL, a number of predefined primitives and also has a 3D primitive description language to define non-STL models). It requires a good size monitor, so don't try it on a small monitor with less than 1600 x 900 resolution. I wrote in about a days time, maybe less. Didn't keep track of the time, but it was not long. Here is the app to download:

    Here is the source code:

    It is just a quck prototype created for fun (not a commercial app or anything) in a very, very short time. It should be able to run on an Windows computer with OpenGL drivers loaded from Windows 95 to Windows 8. The app source code is PowerBasic code and the app uses my own GUI Library (aka. code reusability) so I didn't have to reinvent the wheel. Doesn't use any frame work and can simply be copied to any hard drive or flash drive and run. No OCX's or COM DLL's to be registered either. Not bad for just a few hours just having fun.

    • StockportJambo says:

      Microsoft dropped support for COM some 10 years ago. Why would you even consider advocating such an ancient and flawed technology?

      The more I read of your articles & comments, the more I think Betanews should actually get a tech writer who actually understands his craft and isn't terminally stuck in 1990.

      Sorry, but there it is.

      • DigitalSin says:

        MS dropped support for COM 10 years ago? I never got that memo. I wonder how Metro and WinRT are gonna work with no COM...

      • chrisboss says:

        Dropped COM support ?  What do you think is at the core of Windows ? The new WinRT in Windows 8 is based on a form of COM. Ok, everybody using uses style controls, but that is because it does not normally  use unmanaged code addons. But what do you think is going on under the hood in the CLR ? OLE and COM are at the core of Windows. The only reason I make reference to not using any COM components or DLL's in my software, is because it is 100% unmanaged code. Maybe I should have said "I write 100% native code apps without the heavy load of the framework". is a resource hog, no matter how you put it. The footprint of the native code apps I write are tiny in comparison and can be run on any Windows PC from Windows 95 to Windows 8 without the worry about whether it has the laest runtimes. By using native code I can have a larger range of PC's it can run on and since Windows XP is still one of the most popular versions of Windows, even though ten years old, the apps I write can run on a Windows XP PC with as little as 64 meg ram. Also you said I advocate COM. I didn't say that. I simply said that (despite being a 100% native code app) it does not require any COM components.

        I guess there aren't many programmers today who have a good grasp on the power of the Windows API. may provide some degree of productivity, but it surely does not provide high performance with  a small footprint, which is especially required for the new generation of mobile computers (aka. tablets). A programmers apps may require companies to buy expensive $1000 Windows tablets just to get decent performance. Native code developers (whether they be Powerbasic, C or C++) can write apps with a tiny footprint which will run well even on a lowly Atom CPU found in $500 Windows talblets. If you need to deploy 1000 tablets in the enterprise size company and you can save $500 per tablet because the software it will use was written using native code, then you have saved the company 1/2 million dollars. That is enough money to keep 5 ($100,000 per year) good programmers employed for another year. So I guess native coding is not so backwards after all.

      • StockportJambo says:

        I guess we have different ideas of what constitutes "COM" really.

        My notion of "COM" is the old-style method of compiling a DLL and registering it globally within the system, fighting against versioning hell in the process.  dispenses with all that, thankfully. And WinRT is not COM. Similar, yes, but still very different.

    • DigitalSin says:

      Nicely done.

    • olivierc says:

      It might be my eyes, but I really think that BASIC is definitely not a "natural" language. C is actually much more readable at least for me, I would even go as far as to say that I understand assembler much better that your code.

      You seem to consider yourself as a good programmer, this code does not show that at all. But as you said it is a quick and dirty sample.

    • Adas Weber says:

      No offence Chris, but personally I don't think your code is very readable, at least not for me. Just from a purely visual perspective, I tend to use a lot more white space than you do.

      There are other technical reasons why your code isn't readable for me, but that might be due to me not being familiar with PowerBasic.

    • Let's see...

      A switch with 28 cases? (Oh wait, I just realized that was in one of the 4 generated code blocks that are interspersed in there)

      Gotta love the generated code mixed with user code. 

      Cryptic lines like this:

      Here's the thing that makes reading Basic a pain in the butt to my eyes -- It lacks some visual denotation for method (subroutine) calls. Pascal (Delphi), C derivatives, just about every other language out there.

      So, I see code like this:
      FUNCTION Main_Initialize(BYVAL VerNum&) AS LONG     LOCAL RV&     EZ_PreLoadGL     EZ_InitSpriteBuffers 10,256,256     RV&=1     FUNCTION=RV&END FUNCTION

      and my brain has to do some mental gymnastics to figure out that there are 2 methods being called there. Also, WTF is up with the local variable that is returned as the function result? Is this some weird PowerBasic thing? Cuz I'd have just coded FUNCTION=1 at the end and dropped the local variable.

      Which reminds me -- what does the 1 here denote? Does it mean the function was successful? Does 0 mean failure? Magic numbers trigger my programmer spidey sense.

      I dunno -- maybe it looks fine to you Chris, to each his own -- but to me it looks like a bunch of gibberish-ey gobbledy gook.

      • chrisboss says:

        In all fairness, any function call which starts with EZ_ is not part of the PowerBasic language. They are function calls into my own GUI library, which was written using Powerbasic. So without the docs for that library you likely may not grasp its use.  In all fairness, when I look at C++ or C# code it makes little sense to me.

  23. Adas Weber says:

    The most important lesson I have learned when developing software is that it's not the programming that is the most important - it's understanding the customer requirements!

    You can be the best procedural or OOP programmer in the world, but your application might be complete rubbish from the end user's perspective. Conversly, you could be a poor programmer writing inefficient code, yet be able to deliver the best application in the world from the end user's perspective.

    Personally I have found that spending time using a prototyping tool like SketchFlow helps enormously when developing software, both for the developer and for the end-user.

  24. chrisboss says:

    Interesting that the majority of programmers who post comments to my articles are likely using managed languages. Some may be C++ programmers. Now according to the latest Tiobe report C is still more popular than C++, so where are all the C programmers out there ? Now if C# programmers give C++ programmers a hard time for still using C++ (thats what Herb Sutter implies in his talk "Why C++ ?") then what do they think of C programmers ? Are there so few native coders any more ?

    • StockportJambo says:

      Probably. I use C# these days, but my first paid job was programming in 6502 assembler on the Commodore 64. You couldn't get more "pedal to the metal" than that. In between I used C, Amiga E, some variants of Basic (for fun only), Delphi and then for the last 10 years or so.

      I honestly don't see any C# programmers giving C++ guys a hard time. If you want to stay near the .NET sandbox, but get closer to the machine, C++ is often the way forward. Most projects I'm involved in have a combination of both in the solution file. There's not much you can't do in C#, but occasionally it's easier in C++. The truth of the matter is that you can do pretty much anything in a managed framework (the same can NOT be said of Basic), so the requirement to get down to a lower level has become less and less over the last 5-7 years or so.

      I had a look at your code you posted. It really was like travelling back in time. Do you really honestly think that's readable? Be truthful now. I know it was only a quick knock-up test, but still... if you were doing it to prove a point then that was an epic fail I'm afraid.

  25. chrisboss says:

    Found an interesting comment about OOP on the Intel web site.


    "The problems that came with Object Oriented programming is that these languages are really designed to help the developer manage the code…Now it is almost impossible to follow the execution flow. When you want to know what happened in your application when the error message popped up you have to go over all the objects and all the classes that the execution flow went through and many times execution flow travels between several member functions before leaving to another object. Following the execution flow today is almost impossible."

    Actual article it comes from:

    Tracking Code Flow is critical if you want a properly debugged app. One may question the simple code in my sample app (link below in another post), but tracking code flow is very easy. In my GUI engine I have a very simple debug window, where I can call a simple command to print to it and then I add calls in certain places (especially the primary event subroutine where all events for all forms and controls goo through) and I can easily track code flow in detail at run time. Procedural code is much easier to track code flow than OOP, IMO.

    • olivierc says:

      It is call "printf debugging", and it is far from being a good way of doing debugging. Don't you have a real debugger with PowerBasic ?  

      You say "procedural" but C++ is procedural, only difference is that a function can be virtual, and the call is resolved at runtime. Nothing fancy, and it is not a black box. It the same has having many callbacks and many variable, to find the problem you need to watch the values of the variable. 

    • How can you assert that: "Procedural code is much easier to track code flow than OOP, IMO." when you admittedly don't program OOP?

      Here's the thing -- YOU are the one who is resisting change and not branching out. 

      Are you unaware that basically all of the C++ derivative programming languages allow for procedural and/or object oriented programming depending on the need?

      Take C# for example. It allows you to write code using the style that makes the most sense:
      1) Object-oriented style: typical C# code
      2) Procedural style: static classes
      3) Functional style: lambdas/delegates
      4) Scripting: dynamics, Boo

      So, the reason why many developers use a language like C# is because it allows them to choose what programming style they want. With PowerBasic can you do the same?

  26. chrisboss says:

    As far as the runtime is concerned, it is not the size of the runtime on the hard drive which is the issue (even though tablet PC's with small SSD's every byte saved makes a difference), but the amount of memory required to load the runtime components. In a multitaksing world, there is likely a lot more running on a PC that just the one app wew may write. Windows can do a lot of page swapping, even with a lot of memory, which slows things down. The smaller the footprint the app has in memory the better.

    • You realize that the .NET runtime DLLs are shared across all managed apps running on the computer right? The overhead of the CLR is really the only thing there, and that is pretty minimal.

      Do you worry that each app you run is loading it's own copy of Win32.dll in memory?

      Really though, the .NET CLR and the Java VM both offer a really huge distinct advantage over statically compiled code -- they both can optimize for the processor they are running on without recompiling.

      Do you release x86, x64 and ARM variants for your PowerBasic programs? Do you hand optimize for each specific CPU allowing for all the different variations of SIMD calls that you could do? No?

      Not saying that .NET is always the right choice, but you trying to vilify it as the memory hogging code-bloating beast is pretty piss-poor (and really, that crown goes to SQL Server ;)).

      • I asked the same question regards targeting x86, x64 and ARM. Please illuminate us Chris or are you too busy hand optimizing for each processor and video card available in the world ?

      • StockportJambo says:

        While you're at it Chris, please answer my similar questions - e.g. how would you implement a data abstraction or business layer in PowerBasic? Could you re-write the Betanews website using PowerBasic? Explain how you would use Powerbasic to solve the problem of communicating with a SQL server that exists on the other side of the world, via two gateways & using encrypted protocols.


  27. Blackholesun says:

    When I started learning OOP I was told it is the natural way of programming, just think how you would deal with a particular use case, what you will require to perform your task. Think like this for all use cases and simply translate to objects and classes.

    Though I am a descent OOP programmer now (I think "one" eyed man in a group of blinds, suits me better. It's a popular saying so please do not take any other meaning), but it is certainly not as easy as it sounds in above lines. That natural ways simply doesn't translates into the code and I still wonder why? There may be many peoples who would be doing it easily, but I am saying it from my own experience.

    However sometimes when I read some of the code available on-line, I simply cannot stop saying WOW ! as some code does seems to be written after a considerable time spent in deciding what it should be doing. 

    When you start leaning a new language and if you know the previous language quite well then what I have experienced that it becomes hindrance in learning the new language as no matter what, you will end up comparing it with your previous language. I would like to believe I am not alone in this case. So I request people having good command on multiple languages to please share their secrets for learning the new language :)

    Lastly I would like to thank Chris for this great article and all the people for their valuable comments


    • "doesn't translates" You cannot write proper English, let alone OOP.

      • StockportJambo says:

        Seems obvious to me that English is not blackholesun's first language, which makes your comment a bit un-charitable.

      • English is not my first language either. Actually I found the concept of OOP very easy to understand when I was still a kid. I'm kind of surprised how Chris Boss is so stuck in the past arguing that languages have become so complex because of OOP. OOP has been with us for more than 20 years. Languages have really become more complex over the years but it is really up to the programmer to exploit this complexity to his favor. Take for example C# 1.0. You can still program good code in C# 1.0 and not know anything about generics, LINQ, dynamic programming, parallel programming etc etc etc which were added later on. The tools are there.... It's up to the programmer to exploit them. But please don't tell me that this complexity is making the programmer lazy!... or making the code bloated... Anything but.

  28. chrisboss says:

    Let's set one thing straight. No two programmers think alike so ones own mindset affects their choice in programming languages. For some of us, Basic is far more natural than C. Second one should choose a language which targets their specific needs, so if web development is vital then of course the languages features in this area are important. No language can do everything. Some are geared towards specific tasks like the web. Some are geared towards portability (multiplatform). Some are geared towards Windows only and high performance (that is where PowerBasic shines). Not all aplications are web based (nor should they be) and when you need execution speed, excellent string processing (few languages come close to PowerBasics string command set), extremely small footprint and direct access to the Windows API then PowerBasic is an excellent choice. Now as far as OOP is concerned, it is not OOP that I have an issue with. It is when OOP takes over a language to the point that everything is an object that is the problem. Procedural (modular design using only subs/functions rather than classes) produces less overhead and smaller executables, faster executables and is easier to track code flow. For those who are forced to use OOP, but don't feel comfortable with it, rather than keep telling them "you just need to understand it better", maybe one should seriously consider whether they may internally sense OOP just doesn't cut it for them. Maybe a more procedural approach would work better.

    • StockportJambo says:

      Except you are not talking about specialised languages - you are comparing "like with like" by putting C#, C, C++ (all general purpose languages, not designed for one specific task or platform) against your own personal favourite of Basic... somewhat laughingly saying that C# (for example) is inferior to Basic. 

      Basic is an acronym - it stands for Beginner's All Purpose Symbolic Instruction Set.Leaving the "beginner's" part out of it, the key words for me here are "all purpose". That is what C#, C, C++, Pascal etc are. You don't choose a tool for a specific job when programming, you choose the tool that fits best across *everything* you want to do.

      There is a list as long as you like of all the things that your Basic cannot do (note I don't say "can't do very well" but physically *cannot* do) but practically nothing that these other languages can't.

      And then you follow it up with attack after attack on development methodologies, when (by your own admission) you don't use or even understand most of them. You have to accept a hostile reaction when you do that.

      Respectfully, I would like to add a seventh item to your list. 7) Be OPEN to new ideas, see how they actually work & how they can make your programming life easier, and LEARN about their capabilities & limitations before you dismiss them out of hand.

      If you can do that, you might find people take your opinions & thoughts on developing software more seriously. Just a thought.

  29. chrisboss says:

    Let me set the record straight. Just because Basic originally developed for beginners decades ago, does not mean it has not matured as a language today. All the references by programmers who call basic a beginners language, old fashioned, etc. is simply put wrong. By calling Basic a non-language you make that your argument (it is a form of name calling). I work with a Basic compiler which is on par with any C compiler you have today. I can write low level code from inline assembler, using pointers, pointers to pointers, make function calls via a memory address and more. There are matrix commands work sorting, searching, etc large arrays. I have data structures just like C. It has classes and COM interfaces. It has one of the richest command sets for string manipulation around, IMO superior to C. It has 64 bit integers and 80 bit floating point math. It can work with variant data types. It does serial communications, also TCP and UDP. It does multithreading. You can build COM interfaces with it and type libraries. It has a Dynamic Dialog Toolset for those who don't want to use the Windows API , yet you can write an application using the pure Windows API. It is a built in debugger (even though I personally don't usually need one) and the ability to Trace code flow,  Profile all subs/functions/methods/properties, capture Stack frames, etc. I can do unions, overlay an array (by address) into any memory block like within a string.

    Now I write GUI tools so programmers have high level libraries to make things more productive and it can build WYSIWYG visual designers with drag and drop, do ownerdraw and custom draw, work with DIB sections (low level pixel manipulation), animate via 2D sprites, do OpenGL 3D, dynamically generate complex regions for non-rectangular windows, do high performacing timing, etc.

    So don't tell me I use a "beginners" language.

    • StockportJambo says:

      "So don't tell me I use a "beginners" language"

      I didn't. Read my post again please. I deliberately did *not* bring attention to the "beginners" part - I drew attention to the "all-purpose" part.

      Your BASIC is not all-purpose, and is therefore useless in real software development, because there are a *vast* number of everyday programming tasks that it is *incapable* of doing. I've already listed several. 

      Whether it's a fast compiler or not, whether your code is small footprint or not, whether it's procedural, functional, OO, scripted, that is a simple fact that cannot be gotten away from.

      If you wish to champion Basic as a real language that can be used by anyone in preference to C, C#, C++, Pascal etc, you would be far better focussing on Visual Basic .NET. That at least has all the power & flexibility that's needed - not a mickey-mouse "toy" implementation like PowerBasic.

      • DigitalSin says:

        I'm genuinely curious what exactly PowerBasic can't do, besides web development? I mean it can technically be used for that with FastCGI just like CC++ could be, but that's not really viable in my opinion.
        I know that's a big one (for me anyway), but are there other things you know of?

      • StockportJambo says:

        @DigitalSin:disqus  "Besides web development" covers a multitude of different sins, because the technology behind modern web development is so spread out. Beyond basic websites, you have server side components, AJAX, web services, WCF, WWF (now basically WF), etc.

        I'm willing to bet good money that it can't create Windows Services... without investigating it in detail I say that because the resident guru chose not to respond to my challenge.

        It can't compile to different platforms, e.g. x64, ARM.

        It can't handle generic data sources.

        Need me to go on?

      • DigitalSin says:

        @StockportJambo:disqus You can pretty easily parse json, so that opens up handling consuming data from generic data sources (if that's what you meant). XML is also fairly easily parsed or at least, as easily parsed as XML can be. It can create Windows services, there's some sample code on the PB forums.

        Compiling to different platforms isn't possible that I've seen, I could be wrong on that but I doubt it.

        I don't think it's fair though to ask if PB has things like WCF or WF. These are things provided by the .NET platform, and PB isn't a platform. Maybe that's where the kink here is though, it's not an apples to apples comparison to begin with so the debate will never really get anywhere. 

      • StockportJambo says:

        @DigitalSin:disqus Sure, JSON might be a solution to the data source issue, but that's only if you can obtain the data in that format.

        I accept your word that PowerBasic can create Windows Services. So at least there's that.

        Integrating with other technologies is a key component in any software development though. PB tries to do that via COM, but that's hardly a practical solution.

  30. chrisboss says:

    Powerbasic programmers also have the benefit of producing some of the fastest, smallest executables around. I was talking to a friend who just happened to have done a good bit of software development years back and worked with OOP (and I think C). He asked me what language I used and when I said that it was a lot like the way you used to program using C years ago with the Windows API, but using Basic, he comments how programming Windows using pure C was just too hard which is why everyone moved away from it (first to MFC, ATL and then later C programmers found the Windows API to difficult by itself (not productive enough). When I told him I wrote my own GUI library for Powerbasic to make things easier and when I listed all the features it had and then asked him, "how big do you think this library is ?" this is where it got interesting. I explained how it had a complete forms/controls engine, does drag and drop (build a visual designer with it), has a number of built in custom controls like propertylistbox control, has its own low level Canvas control which allows direct pixel access for high speed, but with a graphics engine and a 2D sprite engine (does frame animation, alphablending, etc.) and has an OpenGL based 3D scripting language, does MCI multimedia and so much more (the list is long) and then said to him "about 90% or more of the GUI engine is a single DLL which is only 700 KB in size". He quickly corrected me, saying "you mean 7 meg right". I said No, "700 KB". When you add the OpenGL control to it it is less than 1 meg in size. His response was "that is impossible!". He felt is was impossible to write such a feature rich GUI library and it be that small. My answer was, "I wrote it in Powerbasic". So don't tell me that I use a beginners language, when I can write apps and libraries so small and so fast it would put even C or C++ to shame.

    • StockportJambo says:

      Blimey. Twice in as many posts (three if you include the one you edited).

      And all I did was point out what the acronym BASIC stands for.

  31. DigitalSin says:

    I think the value I've gotten from this article, and the previous ones like it, is a reminder to  question the norm a bit more with respect to development. I was taught OOP from the very get go of my career, and it all made sense academically. 
    In the real world though and in working with other developers who have about the same level of experience as me (and so were also taught OOP from the very beginning), I've seen it's just used for the reason that it was just the way we were taught, not because of its real advantages. So I see large projects with multiple levels of useless abstraction layers with no functionality, I see overly engineered class diagrams with inheritance used for consistency (for that "just in case in the future" reason), but not because it provides real value. When was the last time anyone had a real, valid use-case where multiple inheritance was that one thing that really sped up development? In 15 years, I've never once seen it. 

    I'm not saying OOP is inherently bad, it can be abused or used properly just like anything else. I'm just saying that maybe we should look at the experience of some of the folks not using it and see how they are fairing, and maybe try a structured / modular approach on the next project we work on to see how it compares. Most don't have that luxury, I know I'd be laughed off the development team if I suggested not being true to the OOP gods. But then,  that's exactly my point.

    • StockportJambo says:

      For me, I was never taught OOP. Like all programming, I did a mixture of self-tuition & learning on the job. I did go to Uni, but it literally taught me nothing about developing software. As I said earlier, my first experience of programming was 6502 assembler on the Commodore 64.

      I like OOP because it's logical, natural, and mirrors the way the brain thinks & compartmentalises stuff. It also lends itself very naturally to patterns, which are more important than whatever language you use.

      Luckily, with C#, we have the best of all worlds. Functional, declarative, procedural, whatever. You use what you need at the time. And I have the peace of mind knowing that my stuff will work on any platform that supports the CLR, and optimise accordingly.

  32. Hey Chris -- I'm curious to put the claims of PowerBasic to the test.

    Since I don't have PowerBasic to build a sample with, could you compile their sample code located here ( into an executable that we could run and decide for ourselves (without having to shell out $200)?
    Specifically this:
    x## = 1y## = 1.000001t! = TimerFor i& = 1 To 100000000  x## = x## * y##Nextt! = Timer - t! 
    Just for fun, let's also include your example located here ( that has a conditional w/in the loop that makes things more interesting.

    (I'm assuming that Timer is elapsed ms and not the high-resolution timer?)

    I want to compare with this admittedly very poor example for file sizes and execution speed.

  33. bob prangnell says:

    OK I'll bite. I started programming with MBASIC on CP/M and have been doing it ever since. Quite a lot of my career has been coding in Pascal (VAX and Delphi), but really I don't consider the programming language to be that important. When I've had to do projects in other languages I've never had much trouble moving to a new one. But I just prefer Delphi for the environment.

    I like the fact that I can compile and link a 100,000 line project in just a few seconds, a compile that has most c++ environments forcing a coffee break.

    And one big thing for me is the third party component market - you can buy or get free, components that do all sorts of things. That is reusable software imho.

    OK now so what I think is the difficult part of programming is not the coding, but the design. And that is mostly independent of the language used.

    One question I have about powerbasic is how it handles exceptions/errors. Programmers love to ignore error handling, but having a powerful and flexible way to handle errors is, I think, a very important part of a language. Has powerbasic progressed at all beyond "IF error THEN GOTO 99999" sort of thing?

  34. bob prangnell says:

    I just read the linked "Has OOP failed" and I must say I think the author is a complete idiot. imho.

    Just to give one example of his biased screed:
    To see the inconsistency in OOP grammar, consider an elementary programming task like changing the size of some text. To change the font size of text to 11 points, classic (non-OOP) code is straightforward and quite similar to the English language:

          TextBox1.FontSize = 11 

    Compare that to the new "improved" OOP version:      

    Dim fnt As New System.Text.Font("Arial", 11)      
    TextBox1.Font = fnt 

    =========end quote======================

    What is so pathetic about this is that the first example, so called classic non-opp code, is in fact oop. It's setting the property value "Fontsize" of the object "Textbox1"

    The non-oop code would be more like 

    CALL setTextSize ( Textbox1, 11);

    Also, the second code fragment does something completely different to the first. It sets the font of the text box, something that could be done with the one line:

         TextBox1.Font = New System.Text.Font("Arial", 11)

    Anyway, the whole of this guys screed is just BS, from start to finish.

    Here's some more of his "ROFMAO" quotes that I'll leave you with:

    "Even highly experienced OOP programmers continually struggle with even simple tasks."

    Um, no I don't.

    "Key terms such as object, method and  property  have lost their descriptive 
    value almost entirely because they’ve become largely indistinguishable in 

    Um, I understand completely the meanings and distinctions between "object", "method" and "property". The fact that this guy thinks otherwise shows he's an idiot.

    If you read his bio you find he's written loads of books, but I doubt he's ever written any real production code.

  35. Chris --

    Can I make a suggestion that you missed from your list?

    From "The Pragmatic Programmer" (A FANTASTIC BOOK)
    Tip 8: Invest regularly in your knowledge portfolio.Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.

    I think if you were to broaden your horizons you'd have a firmer basis for your opinions -- instead your articles come off as an attempt for you to justify knowing only one language and one programming style.

    Even if you take the stance of "I'm sticking with PowerBasic -- it is the tool I prefer" learning a new language will improve your PowerBasic code. Just like a .NET programmer would benefit from knowing what the Win32 api calls are (and how they can call them from their code if they want). Heck, learn Assembly language and your PowerBasic skills would improve just from that alone (since you can use raw Assembly in PowerBasic, you could use assembly for tight loops and huge performance gains).

    Let's take Ruby as an example -- does it compile to the fastest most performant code? No. Is it insanely easy to write a web app using Ruby on Rails? Yes, it is so unbelievably easy that in the day it took you to write your OpenGL example, some Ruby programmer with a great idea just wrote a web app that'll make him a millionaire (excuse the hyperbole).

  36. chrisboss says:


    I do regularly check out different languages, but mnay of them have been forms of Basic. Sadly most have not been at the professional level I am used with my current compiler, but they have been interesting to play with. As far as learning languages with significantly different syntaxes, I find that for me it is better to stay with what won't compete in my mind with what I know best. I prefer to work with a minimal number of languages, so I can be a "master of one" rather than a "jack of all trades, but master of none". I do believe though that programmers, if they want to learn at least one second language it should be assembler. The better appreciation one has for machine code, I think it has a positive effect on high level code we work with. I have some knowledge of assembler, but it is not as up to date as I would desire. Now I also recognize the need for scripting languages, because of two reasons. Scripting languages work well when one wants an interpreted environment (immediate results can be seen when we want fast tested) , particularly for teaching younger students. Also scripting languages are very useful in that they tend to be more portable. HTML and Javascript for example. Portability, especially for the web is very important, as long as speed is not critical. I have learned some HTML and I look forward to learning more about HTML5.

    On another note, I posted a link to simple benchmark app as you requested. It is in a previous post further down.

  37. chrisboss says:


    I should also point out that for a number of years now I have been doing a lot of research but not into programming languages but into the operating system. Yes, much of my research has been into learning how to tap into the power of the Windows API. Also the last few years I spent learning OpenGL and I have enjoyed that. I find OpenGL much easier to work with than DirectX and it has some advantages for my particular needs. Learning how to tap into something like OpenGL is no small task. Built my own 3D OpenGL based scripting language, which is not something for the faint of heart. So while I know most who read my articles find my use of BASIC nostalgic and old fashioned, at least give me credit for this. How many programmers today are writing their own drag and drop (WYSIWYG) Visual Designers, complex graphic oriented custom windows controls and OpenGL 3D scripting languages built into a custom control ? Not an easy task, no matter what languages you use. So for someone many consider "stuck in time" I can at least point to something constructive I have built, which is being used all over the world in a number of commercial applications. Watch this video : and puase the video at about 4:32 (4 minutes, 32 seconds) and notice the laptop shown running software which is used to control the complex under water machinery they discuss. Chevron is a big company would you not say? The task described in this video is very important and mission critical, would you not say ? That software they are using was written by one of my customers and it is based on my GUI tools (and PowerBasic). So while many who read my articles may chuckle and laugh, Powerbasic programmers like myself are doing real work for very important commercial applications like this one.

  38. Patrick McNamara says:

    The educational system today is fairly good for teaching the skills, although you do need to find a decent college, preferably a business college. One thing that schools teach is a structured approach to programming that the self-taught person isn't always likely to learn.  This structuring makes it easier for programs to be modified and changed by different people rather than just one programmer.

  39. bob prangnell says:

    I would have a lot more respect for the opinions of someone who has mastered dozens of programming languages, and then declares language X to be the best, against the opinions of someone who only knows a couple.

    However I suspect that the person who knew dozens would respond, when asked "which is best?" with "best for what?" Horses for courses.

    As far as assembler, in almost all cases this is irrelevant nowadays. With current CPUs, usually a good compiler will produce better machine code than an assembler programmer.  (Note I said "in almost all" and "usually"...there are of course exceptions, but in ther 1980s you pretty much had to use assembler from time to time)

  40. chrisboss says:

    There are plenty of performance hungry tasks where no compiler can come close to beating well written hand coded assembler. Now of course most tasks are not that driven upon performance to that degree, but there are some where it could make a big difference. It is because programmers keep expecting the hardware to compensate for our programming that we have slow and bloated software today. Actually assembler may be more valuable today that in the past. The CPU's are faster, but the work load is significantly greater. In the old days we had text based screens with only 2 KB memory per screen buffer. Not much data to move around. Now we have 1080p video running at 30 fps or better with complex images (requires more work for a codec). We have 32 bit hig res displays greater than 1080p and work with 3D modeling at speeds which are amazing. The amount of data we have to push around today is enormous and even with faster CPU's performance is still vital. In the areas of science some computations are so complex it may push a CPU to the limit. So don't call assembler old fashioned. I think a programmer today who appreciates the importance of performance and knows the place when inline assembler can make a huge difference is a valuable asset. Programmers who simply don't care about performance expect the hardware always to be enough are the ones who are not doing there job properly. Listen to Herb Sutter (Microsoft C++ expert) in his talk (video is on channel 9 at MSDN) entitled "why C++?" discuss the importance of performance. In his own words he said for the last 10 (or 15 ?) years the industry has been pathetic about performance (yes he used the word pathetic). He is right ! 

    Now as far as knowing multiple languages, the more ones knows does not mean they are a better programmer. It is what one does with those languages which is more important. When different languages are closesly related in syntax (ie. C, Java) then it is easier to learn multiple languages. But when the languages are significantly different in syntax, then it can actually be problematic to learn too many.

    I don't respect someone simply because they know a number of programming languages. I respect the work one does, no matter what the language. I would have more respect for a programmer who only prefers say VB.NET because he feels most confortable with it and is experienced with it and prefers work with a language they really know well. When Microsoft dropped classic VB in favor of that was a disrespect of all the years of experience those programmers had developed.  Many programmers today probably laugh at those poor old classic VB programmers who just could not move forward to, but do you realize how much practical and valuable software those classic VB programmers added to the industry ? Maybe they wrote software for small nitch markets that the big guys won't waste time on ? Many a small business may have been running on custom sofware written in VB. Who are we to say the contribution of such programmers who prefered good old classic VB (aka. Basic) was of no value and its their fault they just could not keep up. Respect is earned by your contributions. If a programmer writes software which others benefit greatly from and they use it for years, then he deserves respect.

  41. Great Sir, Learned some new things from your article. Nice to be touch with you.

  42. EnderTech says:

    You had me with "become a master tradesman" and mostly with your six lessons, but completely lost me with your view of OOP.  A rebuttal to your article:

  43. chrisboss says:

    I am not saying that OOP has no place. The problem is that OOP has overrun procedural coding styles and procedural does have many benefits. For one, procedural will generate smaller applications when written correctly. OOP has overhead, no matter what anyone says. Procedural lends itself to writing code in a more agile way than OOP does. Procedural code can be just as reusable and modular as OOP can and even better in some instances. My impression is that most programmers started learning OOP right from the start in their training so don't know anything different. As a 100% procedural style coder I can honestly say it can produce amazingly tight code with a small footprint and with great modularity.

    To be quite honest, I am very disatisfied with the bloat in todays software. For example, I write software using a powerful native code compiler and my own GUI tools written using that compiler. Between the compiler and my own tools they weigh in at a hefty 20 megabytes or so. Now I downloaded the Visual Studio 2010 Express and it installed to 2.3 gigabytes. When does 2.3 gigabytes sound reasonable for a development system ? I can use the development system I use even on a lowly 9 year old Windows XP computer with minimal ram, but try Visual Studio on anything less than a recent PC with a minimum of 2 gig ram (or more) and it literally comes to a halt. programmers are quick to say that their software has plenty of performance, but I would beg to differ. How many programmers could write an app which runs just as well on a 10 year old Windows XP computer with 64 meg ram as it does on a Windows 7 computer with 2 gig memory ? Not only can I easily do that, but I for fun tested some of my 3D OpenGL stuff on a Windows 95 computer (upgraded a bit) with only a 500 mhz CP. of course without some hardware support for the opengl it was a little slow, but it did run. Something less graphic oriented would have run fine.

    While Richard Mansfield in his white paper had a number of reasons why OOP has failed, personally I feel OOP and its overuse in Windows has produced slow software with a heavy taste for resources.  The reason I strongly point out the problem with performance today in software is because the hardware we have today is amazingly powerful, but the end user experience is poorer than in the past. Sure we have fancy video chips in PC' and very fast codecs (probably optimized with assemblers) so everyone thinks we have high performance (which we do with video), but general software today is just plain terrible. Little optimizing for performance. Procedural coding may seem harder to many programmers today than OOP, but written correctly it can produce better software, with a smaller footprint and better performance.

  44. chrisboss says:

    I would like to say to those who may think I am afraid of new technology, that I do not fear new technology, but am more concerned about building upon what I know. I see comments from some who think programmers should know multiple languages, should always be on top of the latest technology and should always be pushing the limits of software using the latest programming fad. In reality a more modest approach to programming, where one designs software which can run well on a larger range of computers from the latest  PC's to those a number of years old, is more practical because end users spend less money because they don't always have to keep upgrading at a pace which makes no sense. Just look at how many PC users still are running Windows XP today. Do you know why ? If it isn't broke why fix it. If a PC has many years of life left in it, why throw it away ? If security is an issue because Microsoft doesn't want to support it anymore, just take it off the internet and keep using it and only put newer PC's on the net. Some programmers might mock those who prefer to be more modest in the computer use, but I don't.

    As far as new technology, it may open up some new choices, but it often forces programmers to throw away years of experience just for the latest programming fad. I would venture to say that there is probably billions of lines of code developed in the past, which could still be used today. Likely many would he surprised to find some companies still using code which is 10, 15 or even 20 years old. It works and works well. Why reinvent the wheel ? Would it not be better to find ways to reuse all that code and all the experience of older programmers so it can be built upon ? I wrote a BTree engine back in the mid 90's and because I use a modern compiler, which is backward compatible with older code, while offering many newer constructs, it was easy to port that code so it runs very well on the latest computers.

    So I am not against new technology. I am just against waste of years of experience, knowledge and well written code.

  45. chrisboss says:

    Tony, I think your statement in your blog describing me as having a "near crippling aversion to new technology " is a bit of a stretch. You may take issue with my views of OOP compared to procedural programming and that I can accept, but to describe me that way is really unfair and unprofessional. In am a low level Windows API programmer, a native coder, so for me new technology is what ever is new in the operating system (Windows) as far as API's. Mobile (aka. Tablet PC's) is the big thing now, especially with Windows 8 coming. My current interests are in "Touch" enabled applications which work on Windows 7 and Windows 8.  I appreciate the need for RAD tools, which is why I develop drag and drop tools. In my own tools I build support for things like multithreading, multiple monitors, OpenGL 3D graphics and plenty of graphics. I just have a much different approach than most by using a more natural language such as Basic (although it is a very high level Basic which can produce executables on par with C or C++) and because I consider performance critical and a small footprint vital. I don't think I have an aversion to new technology, when I like many developers have followed all the news about Windows 8, have downloaded the build and consumer versions of Windows 8 to experiment with, installed Windows 8 on a tablet PC for testing. I just don't find Visual Studio very friendly because I haven't been using a Microsoft programming language for the last 10 years. The real test, is not whether one is using the leading edge development tools, but whether one gets the job done and can produce quality software. At least I know I can develop software for the coming Windows (x86) tablet PC's with a smaller footprint and with excellent performance, compared to most software today.  Even if you can not accept my mindset in your world, why not watch the video of Herb Sutter (Microsoft C++ expert) in his talk "Why C++?" where he discusses the industries lack of appreciation for writing software with performance in mind. I would not be critical of programmers like myself who consider performance important, since even Microsoft is beginning to see more is needed when it comes to performance. Native coding has value and using a powerful compiler which generates small and fast executables, whether done using Powerbasic or C++, is "leading edge technology".

    • tony says:

       I think everyone appreciates performance and a small footprint and as someone who first really practiced programming in Assembler I know the benefits that procedural programming can provide. But for any major application you really will be losing the ability to use things like design patterns, encapsulation and abstraction which are powerful programming concepts that may add overhead but decrease the amount of development and maintenance time necessary. Such a tradeoff is almost always necessary, and there is a point reached when saving a handful of processor cycles or a few bytes of memory isn't worth the extra month you'll spend debugging the spaghetti code later.

      I described you that way because, honestly, all I have is your articles to base my opinion on and what I see is a large aversion to implementing new and proven technology within its scope. I feel like the negatives you posted about OOP are true about bad programming in general and are unrelated to the style of programming one does, and nothing in your writing suggests you've given a shot at writing object oriented software to the same level of quality you do procedural.

      • chrisboss says:

        Quote: "spaghetti code" . Common negative by OOP users to describe older style procedural code, particularly when you mention BASIC. Richard Mansfield in his white paper mentions this common negative OOP users often say about procedural code, but as he indicates it simply is not true. Procedural code can be just as modular, reusable and clean as any OOP code can be. While I did not say OOP should never be used, but it has its place, I am only trying to say that procedural style coding has benefits. Because I choose not to use OOP (I agree with Mansfield when he suggests it tends to bloat the command set so it simply is too much), does not mean I have an aversion to new technology. Now to build high level objects, like a GUI class which does a lot internally does have some merits. But to treat everything as if it should be a object just is too much. Goes against the old adage of "keep it simple". It is so easy to make rules about what is proper coding as if it must match some master plan, but a programmer should be able to code in a way which is natural to him/her, which allows them the flexibility to code in a way which accomplishes a task with the least amount of code and with the least amount of overhead possible.  Now I may not have spent years "trying to make sense of OOP", but someone like Richard Mansfield has. He has written at least 38 books on technology and computer programming include languages, so he is far more of an expert than I am and he finds serious problems with OOP. Again I did not say all OOP is bad. It is the overuse of OOP which may be a better summary of my views. Now to me, a language like PowerBasic which allows me to write an app using 100% procedural code or if I prefer allows me to build my own classes, objects and interfaces and go completely OOP if I prefer is a better approach. It appears that most software built using Microsoft tools tends to be OOP first almost to the exclusion of procedural. Besides, I like the idea of being able to code on nearly any computer built in the last 10 years with a language which only takes about 10 meg of space on my harddrive, compared to an unwieldy Visual Studio which weighs in as a minimum of 2.3 gig and is slow in comparison. I can actually copy my entire development system to a tiny flashdrive (just copy files) and run. Try that with Visual Studio (you can't just copy the files) ? So I guess liking things simple and easy is old fashioned.

© 1998-2020 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.