I've programmed in a range of languages. There are some that I really enjoy coding in, there are some I can put up with and there are some that frustrate and bore me. Having an interest in language design, I got somewhat curious about what it is that makes working with some languages more enjoyable than others.

A couple of questions came to me right away. First, there is probably a lot of personal preference here. What makes a language enjoyable for me to work in may well be what makes it frustrating to someone else, and vice versa. Second, languages are tools. I've said often enough that different languages are suited to different tasks, and you should pick the one that best fits the job at hand. How important a factor is whether one enjoys working in the language when trying to choose whether to use it in a project or not?

Personal Preference

Read More

Read Comments (13 Posted) Post Comment Permalink

Recently, a friend mentioned that someone had told him that writing a try...catch block in C# (or substitute some other .Net language here) resulted in a "huge penalty" in terms of performance compared to if you had not written it. That is, merely writing such a block actually hurt program performance, even if an exception was never thrown. He didn't believe this was true, and rightly so - it's completely wrong. This post is a tidied up version of my explanation.

Inside a .Net Assembly

A .Net assembly, if we ignore various headers, consists of three things:

• Bytecode: a sequence of low-level instructions that specify the body of a method
• Metadata: a set of tables, a little bit like a database, describing higher level constructs such as classes, methods, signatures and so forth
• Heaps: places where string constants and other such things are stored

Read More

Read Comments (6 Posted) Post Comment Permalink

I spent the whole day preparing worksheet and marksheets with formulas for Grade 10 IT and MATH.
The other thing that I did was to make introduction of database easy using Delphi for the learners

Read Comments (0 Posted) Post Comment Permalink

Here, for completeness without further comment, is the code for RTrim, LTrim and Trim which are included in the unit Tools.

      Function RTrim (Var S : String) : String ;
      {
         RTrim -- remove trailing blanks
      }
      Var
         i : Byte ;
      begin { RTrim }
         for i := Length(S) downto 1 do
            if S[i] > BLANK then begin
               S     := Copy(S,1,i) ;
               RTrim := S ;
               Exit
            end ;
         {
               if we reach this point then S contains only BLANKS
            so we return a null string
         }
         S     := '' ;
         RTrim := S
      end ; { RTrim }

      Function LTrim (Var S : String) : String ;
      {
         LTrim -- remove leading blanks
      }
      Var
         i : Byte ;
      begin { LTrim }
         for i := 1 to Length(S) do
            if S[i] > BLANK then begin
               S     := Copy(S,i,MAXSTR) ;
Read More

Read Comments (2 Posted) Post Comment Permalink

The next program in our project is EnTab which replaces runs of blanks in a text file by tabs and blanks. Here is the specification, i.e., the "manual"

PROGRAM
   EnTab -- convert runs of blanks into tabs
USAGE
   EnTab
FUNCTION
   EnTab copies its input to its output, replacing strings of blanks by
   tabs so that the output is visually the same as the input but contains
   fewer characters.  Tab stops are assumed to be set every 3 columns
   (i.e., 1, 4, 7, ...), so that each sequence of one to four blanks
   ending on a tab stop is replaced by a tab character.
BUGS
   1. EnTab is naive about backspaces, vertical motions and non-printing
      characters.
   2. EnTab will convert a single blank to a tab if it occurs at a tab
      stop, thus EnTab is not an exact inverse of DeTab.
   3. if any record in the input is longer than 255 char Entab will
      truncate that record to 255 char.

Read More

Read Comments (0 Posted) Post Comment Permalink

Sometimes a program you have written just doesn't run fast enough. In this article I'm going to look at how (and how not) to approach such problems along with some tips for speeding things up in various cases.

Stop Right There!

The biggest mistake people make when trying to improve the performance of their programs is jumping straight in and trying to do it without first understanding where the bottleneck lies. Often the real performance issue may not lie where you think it does.

Tools for analyzing program performance are called profilers. They will tell you which functions and sometimes even which lines of the program are taking up what factor of the execution time. This is highly valuable information and can save you a lot of wasted time. Without it, you might set about optimizing a function or method that is only taking a tiny fraction of the execution time anyway.

Read More

Read Comments (9 Posted) Post Comment Permalink

If you've asked someone to look for something you left at their house, would you say, "give me a call if it's true that you found it"? No, you'd say "give me a call if you found it". So why do so many people write things like:

if (found == true)

Instead of the shorter, clearer, equivalent:

if (found)

Yes, I know, I shouldn't let refactoring get me so cranky.

Read Comments (2 Posted) Post Comment Permalink

Most programmers today will be familiar with a number of programming paradigms. The age-old procedural programming paradigm, where a program is broken down into a number of procedures or routines, is still very much alive and the right solution for a number of problems. Object Oriented programming is one of the most popular and fashionable paradigms today, allowing for a good level of code re-use through mechanisms such as instance management (one class can be instantiated many times to give many objects), data hiding (think private variables in a class) and inheritance.

Another paradigm cross-cuts these two: that of imperative programming. This simply means that a program consists of a sequence of instructions that are executed one after the other (or at least appear to be; both the compiler and the CPU may well re-order instructions to improve performance when it does not affect the behavior of the program). In fact, when I was younger my definition of a computer program included the words “a sequence of instructions”.

Read More

Read Comments (11 Posted) Post Comment Permalink

I remember back in the good old days, I was interested in computers, and I really wanted to know how they worked and how to control them. I kept wondering how people made those creative applications I used every day on the computer. I picked up a book at the library and read it. I was thrilled and the stuff it taught me. It introduced me to something I had never known before. It was called computer programming. I learned BASIC, the easiest language I know, I read it several times, from front to back. Now I wasn't sure how to use these, or how to use them on a computer, so I wrote them down on notebook paper. I made a lot of them, my own programs, and some samples from the book I was reading. Then one day my brother told me of a program called "QBasic". When I began using it, and ran my programs, I was extremely thrilled at the moment. I used it for several years, making programs as I wished. Later, Microsoft Visual Studio came out, and I used it. I installed the Visual Basic environment. I wasn't very familiar with the layout as compared to QBasic, but it seemed a lot easier to use when I got the hang of it. I was even greater impressed that I was able to make windows and forms just like the crazy killer apps of the day. I strengthened upon this, but I eventually found some boundaries to which Basic could not go...

Read Comments (1 Posted) Post Comment Permalink

Well, I figured I may as well make the first post in my PH blog vaguely controversial. If the title's not enough for you, then let me go on to suggest that the Bible has some useful advice in it for those of us trying to decode the continual stream of acronyms that the computing industry likes to throw at us.

"What has been will be again,
 what has been done will be done again;
 there is nothing new under the sun."
    -- Ecclesiastes 1:9

One of the things that amuses me most about the computing industry is how we seem to keep getting shiny new names for the same old technologies, perhaps just applied in a different problem domain or using a different language.

Read More

Read Comments (0 Posted) Post Comment Permalink