A lot of beginner programmers, especially those new to the Linux world, have a lot of issues compiling programs. This isn't exclusive to C, of course, so hopefully you can take something away from this post and apply it other languages, too.
There are two primary stages to "compiling" a program. The first stage is the compilation stage. There are several intermediary steps but the end result is that your code, in this case C, is translated into a machine readable language. The second stage is called "linking". This is when each part of your program and any external libraries are linked together to create an actual executable binary file you run or a library file.
Disclaimer - This post may be hazardous to your health (not really). It is a non-exhaustive and non-authoritative introduction to compiling and linking programs on the command line in Linux. I can't emphasize enough that you should reference the documentation provided by the compiler you're using and that said documentation will always trump anything contained herein. Side effects may include: nausea, dry mouth, hair loss, severe depression and momentary blindness. If any of these side effects occur, discontinue use immediately and contact your physician.
Stage 1 - Compilation:
The Compiler:
First off, you have your choice of compiler. We are going to concern ourselves with the GNU C Compiler (gcc); currently, the most widely used C compiler for Linux. LLVM has been gaining ground but we won't be discussing it here though it stands to reason much of what you learn would still be applicable. The GNU C Compiler, usually simply referred to as GCC, is actually a collection of tools for compiling programming languages. Each tool has a unique name which reflects the language it is designed for. For example, compilers exist for the following languages in addition to C: C++ (g++), Java (gcj) and Fortran (gfortran). Only some, though possibly all, may be installed on your system by default.
Important: Do NOT use g++ to compile C language sources. There's a reason why they are separate compilers.
In the case of C, make sure you have a GCC installed on your system. Open a terminal and type:
gcc --version
If you get an error of some kind, chances are you don't have GCC installed and will need to do so before you can go any further.
Hint: For those of you running a Linux system like Arch, Debian, Fedora or Ubuntu you can install any of the tools discussed within this document quite easily. For example, Debian based systems usually have a 'build-essential' target via apt-get for installing commonly used tools for building programs from source. You can simply issue the command 'apt-get install build-essential' without the quotes. Check your specific distribution's instructions for installing these tools from their respective repositories.
Everything in this how-to should be run in a terminal. Make sure you change to the directory where your source files are contained and execute the supplied commands within than directory. There are many, many compiler flags to know but the following should be considered a minimum:
gcc -Wall -pedantic -std=c99 my_file.c -o my_program
...replacing "my_file.c" and "my_program" with the proper names of your file(s) and desired program name.
Compiling a source file with the above flags will produce a final binary, skipping the separate linking stage. However, as your programs get more complex it becomes advantageous to build intermediary objects first then link them together later.
Compiler Flags:
These flags are passed to the compiler to tell it what you want. There are some very important ones to know:
-std=c99 - This flag sets the specific standard for gcc to comply with. At the time of writing gcc defaults to a standard called gnu89, which is the c89 standard with GNU extensions. If you plan on writing a program which may be compiled on a system which does not use gcc as it's C compiler (LLVM, MS Visual Studio, Borland C, etc) then it is probably in your best interest to force the use the most current C standard and disable the GNU extensions. gcc is not 100% c99 compliant but the non-compliant features are rarely used. If you require any of the features of c99 which have not yet been implemented in gcc then you'll have to use another compiler anyway.
-o - Specify an output name for the object or binary. In the most basic case, you use it to specify the name of the program you are producing. If you don't use this flag, gcc will default to using the name of the source file and create a .o file for an intermediary object (myfile.c becomes myfile.o) or, in the case of creating a binary, it will default to a.out for the binary file.
Compiler Warnings:
Warnings should always be turned on. Here are some very important/common ones to know:
-Wall - all warnings; this is misleading because it doesn't actually turn on ALL warnings but just the most commonly desired ones.
-Wextra - turns on extra, more strict warnings.
-ansi - specifies that you want to adhere strictly to the C standard. It turns off all GNU extensions to the C language making it fully ANSI compliant. This is important for portability between compilers. This is automatically turned on when you specify the standards c89 or c99 with the -std flag. However, as stated earlier, gcc defaults to gnu89 (c89 with GNU extensions) and the -ansi flag will explicitly disable these extensions. -std=gnu89 -ansi is equivilent to -std=c89.
-pedantic - makes ANSI warnings fatal, meaning that they'll be reported as errors instead or warnings and halt compilation. It is usually a good idea to always enable this flag when you give -ansi or -std=c89/99.
Extra Compiler Flags:
-c - compile object code but do not link. This produces a file with the .o extension. Object files, those ending with .o, are later linked together to create a final binary or library.
-I <directory> - This flag allows you to specify an additional location for the compiler to find your header (.h) files by replacing <directory> with the location of the headers being searched for. This is useful if you store your header files in a directory other than the one your regular source (.c) files are located. You can chain as many of these flags together to add as many directories as you need. If you don't know why you would need to use this then it's safe to just leave it out.
Stage 2 - Linking:
The Linker:
As noted earlier, building a program is a two step process. The second step, after compiling, is linking. In most, if not all, large projects sources are usually compiled first into object files. On their own, they do nothing and are essentially useless. In order to work, they need to be linked together to create a single binary file, an actual program, then made executable. This is where the linker, named 'ld', comes in. The linker has its own set of flags which may either be passed to gcc or to ld itself. It is probably easier, and in your best interest, to issue the flags to gcc for simplicity's sake.
Linker Flags:
-l<library> - where library is the name of the external library you need to link into your program, sans (minus) the 'lib' prefix. In other words, if you with to link the math library, libmath into your program, you drop the 'lib' part and use: -lmath. Actually, the linker can find libraries with a basic regex so you can link -lm for the math library.
Extra Linker Flags:
-static - Used to force libraries linked to your program statically. This means that the library itself is incorporated (bolted on) into your program. This increases the size of your program but does away with some of the issues associated with dynamic linking. A discussion on dynamic vs. static linking is WAY beyond the scope of this article.
-dynamic - Force libraries to be dynamically linked to your program. This means that the library is linked to your program but not actually loaded until the program is run.
-L <directory> - Specify a path to find extra/custom libraries by replacing <directory> with the location of the libraries being searched for. This can be used to link external libraries not in installed in the normal paths searched by the linker. It is also used to specify directories within your project if you are linking to internal libraries.
The Next Steps:
For compiling very small programs it is usually easiest just to run gcc from the command line. As programs get larger, though, it usually becomes necessary to remove some of the complexity. The next step would be to create a custom Makefile to build your program. You may then simply issue a single command, make, and the rest of the work is done for you. I mentioned earlier that it becomes simpler to compile sources into objects first then link them later. That is because as a project gets larger the longer it takes to compile and link. By utilizing a Makefile only files which have been modified are recompiled and then re-linking thereby speeding up the build process when changes are being made. This is especially helpful when debugging.
The next step would probably to use a full build system like the GNU autotools. Autotools is a general term for a suite of programs: aclocal, autoconf, autoheader, automake, autopoint and libtool. GNU autotools provides a method of making your code more portable and easier to distribute. They can even roll a tarball for you and compress it. By utilizing tools like GNU gettext and GNOME's intltool you can integrate translations into your project, too. The autotools are the backbone of other distribution methods, as well, like creating an .rpm or .deb in Linux and knowing how to use them tends to be an essential skill. There is plenty of help on the Internet on using GNU's autotools. Just do a web search and you'll find plenty of help.
If you're having trouble, read: How to Get Help
Wednesday, 24 August 2011
Thursday, 11 August 2011
Much Adieu About Patents
I can appreciate the significance of patents. Were I an inventor and I created something novel I would want to protect that invention. Why should someone else ride on my coat-tails? I invested time and money creating my invention and I should have the right to protect that investment. There are actually three separate methods I can use to protect them: trademarks, copyrights, and patents. That said, I'm only going to talk about one of them. Patents.
There is a limit, though. An idea must be novel. If it occurs in the natural world, like mathematics, then it can't be patented. Two plus two is four. It is innate to the universe. Most any child can do basic arithmetic. Extrapolate this method to physics, also a mathematical discipline, and you see the same. The universe and Earth existed long before humans evolved and so those things are not novel in the sense of human creation and therefore can not be patented. What of human physiology? What of human creations based on naturally occurring things. Where, in essence, is the line?
You can't patent a human heart but you can patent a creation which mimics one. You can't patent a human gene but you can patent an altered gene; that is, a gene which has been modified to such an extent that it can be said to be non-naturally occurring. You can't patent a mathematical equation but you can patent a computer algorithm. You can patent something that has already been created as long as no one else has patented it first.
Now, those who follow patent law realize that some of my statements aren't entirely true. While yes, you can patent a creation previously developed and lay claim to it, the patent would be invalid if prior art, examples or depictions of your invention prior to patenting it, can be found. A gene therapy which does not alter the genome in such a way that it can still be said to be naturally occurring also can't be patented.
Some patents are so blatantly obvious that you wonder how one was ever granted in the first place. Certainly, it would be nullified upon re-examination but what if it never comes to that? Patents are a weapon. The sharp edge of innovation. What do you do if you are being sued, by a company with nigh unlimited money, for patent infringement for obviously bogus patents and you yourself would run out of money before you could ever hope to have the patent(s) re-examined? What do you do when that same company offers you a license agreement or a settlement for an exorbitant fee but much less than the cost of your defense? Do you go bankrupt or settle? Which is the better choice?
In computing, the idea of patents is very murky. Computing is, in essence, mathematics. a + b = c is equivalent to 1 + 2 = 3. Calculus. a, b and c are variables which contain values. Using a function to add them together via a mathematical equation and returning the result is just that. Math. Math, as we've already stated is naturally occuring and can't be patented. It's not so simple though. What if my equation is made up of a quantification of superfluous things? Take, for example, a dating site. They may use an equation like: personality + interests = compatibility. They quantify intangible things and use an equation to compute a compatibility score. The equation is naturally occurring but the quantification algorithm is supposedly novel thereby making it patent eligible. Strange, isn't it? That little loop-hole? The question is, is it a valid argument?
I, personally, am not sure it is. However, let's assume that's the case. The issue at hand is: at what point does it make sense to patent an idea to protect yourself from people stealing your ideas vs. attacking anyone who may even remotely prove to undermine your stranglehold on a market? That's the difference between anti-trust and legitimate business practice. Let's be real here. If you invent something unique and novel you can patent it. If you create 100 such items you could potentially hold 100 patents. Yet, some companies have patents in the 1,000's, some over 10,000! That doesn't seem logical to me. How can any one company invent that many patent-able things? The truth? They can't, and they didn't. First off, many of the patents are erroneous at best. They wouldn't hold up to re-examination. Second, these are patents that were purchased from others. Companies amass what people term "war chests" of patents specifically to use against others, or protect themselves against attack. Does that sound like the kind of behavior that patents are supposed to protect?
Patent policy is in dire need of reform but don't hold your breath. Industry controls government not the people. Industry, or at least the most powerful members, like patents the way they are. They don't have to innovate, spending millions of dollars on research and development. No, they can't just extort money from other companies too small to defend themselves, forcing them to sign licensing agreements over bankruptcy.
Does this sound like the innovation that patent law is supposed to protect and promote? I think it's rather to the contrary, that current patent law is stifling innovation. "You create something new and we'll sue you." Ya, I'll get right on that band-wagon. Patent law was based on protecting inventors of things. Like, the Frisbee or McDonald's method of building a hamburger/sandwich (I kid you not). Software patents don't make sense. On the surface it does by conventional means but computers, or more specifically the software they run, are not conventional inventions. They're equations. Literature, if you will. That's why we write programs in computer languages. You can't patent the method of assembling a sentence any more than you can patent water or the equation two plus two equals four. All of them are naturally occurring and could be discovered by anyone. There is nothing novel about them.
I agree that patents are a worthy cause to support. I also think that patent law is in dire need of reform. It just saddens me that it will probably never happen and consumers will be the ones to pay for it. Licenses and litigation cost us money because the more costs a company incurs the more they have to pass on to us. Patents really are something that should concern every one of us because they effect our own personal bottom line. That TV, mobile phone, or any other electronic device (each of those items run software even though you're not aware of it) could cost cheaper if it wasn't for patents. Not because there is a patent on that device which allows only one person to create it. Indeed, if you can innovate a different device to compete against it then you finally have true innovation, the purpose for which patents were created. No, it costs more because companies are either paying licensing fees, lawyers or purchasing patents to protect themselves. If software patents were abolished then the world would be a much better place for all of us.
Groklaw, incidentally, is an excellent site to follow. I highly recommend it.
There is a limit, though. An idea must be novel. If it occurs in the natural world, like mathematics, then it can't be patented. Two plus two is four. It is innate to the universe. Most any child can do basic arithmetic. Extrapolate this method to physics, also a mathematical discipline, and you see the same. The universe and Earth existed long before humans evolved and so those things are not novel in the sense of human creation and therefore can not be patented. What of human physiology? What of human creations based on naturally occurring things. Where, in essence, is the line?
You can't patent a human heart but you can patent a creation which mimics one. You can't patent a human gene but you can patent an altered gene; that is, a gene which has been modified to such an extent that it can be said to be non-naturally occurring. You can't patent a mathematical equation but you can patent a computer algorithm. You can patent something that has already been created as long as no one else has patented it first.
Now, those who follow patent law realize that some of my statements aren't entirely true. While yes, you can patent a creation previously developed and lay claim to it, the patent would be invalid if prior art, examples or depictions of your invention prior to patenting it, can be found. A gene therapy which does not alter the genome in such a way that it can still be said to be naturally occurring also can't be patented.
Some patents are so blatantly obvious that you wonder how one was ever granted in the first place. Certainly, it would be nullified upon re-examination but what if it never comes to that? Patents are a weapon. The sharp edge of innovation. What do you do if you are being sued, by a company with nigh unlimited money, for patent infringement for obviously bogus patents and you yourself would run out of money before you could ever hope to have the patent(s) re-examined? What do you do when that same company offers you a license agreement or a settlement for an exorbitant fee but much less than the cost of your defense? Do you go bankrupt or settle? Which is the better choice?
In computing, the idea of patents is very murky. Computing is, in essence, mathematics. a + b = c is equivalent to 1 + 2 = 3. Calculus. a, b and c are variables which contain values. Using a function to add them together via a mathematical equation and returning the result is just that. Math. Math, as we've already stated is naturally occuring and can't be patented. It's not so simple though. What if my equation is made up of a quantification of superfluous things? Take, for example, a dating site. They may use an equation like: personality + interests = compatibility. They quantify intangible things and use an equation to compute a compatibility score. The equation is naturally occurring but the quantification algorithm is supposedly novel thereby making it patent eligible. Strange, isn't it? That little loop-hole? The question is, is it a valid argument?
I, personally, am not sure it is. However, let's assume that's the case. The issue at hand is: at what point does it make sense to patent an idea to protect yourself from people stealing your ideas vs. attacking anyone who may even remotely prove to undermine your stranglehold on a market? That's the difference between anti-trust and legitimate business practice. Let's be real here. If you invent something unique and novel you can patent it. If you create 100 such items you could potentially hold 100 patents. Yet, some companies have patents in the 1,000's, some over 10,000! That doesn't seem logical to me. How can any one company invent that many patent-able things? The truth? They can't, and they didn't. First off, many of the patents are erroneous at best. They wouldn't hold up to re-examination. Second, these are patents that were purchased from others. Companies amass what people term "war chests" of patents specifically to use against others, or protect themselves against attack. Does that sound like the kind of behavior that patents are supposed to protect?
Patent policy is in dire need of reform but don't hold your breath. Industry controls government not the people. Industry, or at least the most powerful members, like patents the way they are. They don't have to innovate, spending millions of dollars on research and development. No, they can't just extort money from other companies too small to defend themselves, forcing them to sign licensing agreements over bankruptcy.
Does this sound like the innovation that patent law is supposed to protect and promote? I think it's rather to the contrary, that current patent law is stifling innovation. "You create something new and we'll sue you." Ya, I'll get right on that band-wagon. Patent law was based on protecting inventors of things. Like, the Frisbee or McDonald's method of building a hamburger/sandwich (I kid you not). Software patents don't make sense. On the surface it does by conventional means but computers, or more specifically the software they run, are not conventional inventions. They're equations. Literature, if you will. That's why we write programs in computer languages. You can't patent the method of assembling a sentence any more than you can patent water or the equation two plus two equals four. All of them are naturally occurring and could be discovered by anyone. There is nothing novel about them.
I agree that patents are a worthy cause to support. I also think that patent law is in dire need of reform. It just saddens me that it will probably never happen and consumers will be the ones to pay for it. Licenses and litigation cost us money because the more costs a company incurs the more they have to pass on to us. Patents really are something that should concern every one of us because they effect our own personal bottom line. That TV, mobile phone, or any other electronic device (each of those items run software even though you're not aware of it) could cost cheaper if it wasn't for patents. Not because there is a patent on that device which allows only one person to create it. Indeed, if you can innovate a different device to compete against it then you finally have true innovation, the purpose for which patents were created. No, it costs more because companies are either paying licensing fees, lawyers or purchasing patents to protect themselves. If software patents were abolished then the world would be a much better place for all of us.
Groklaw, incidentally, is an excellent site to follow. I highly recommend it.
Tuesday, 9 August 2011
How to Get Help
Originally, this was going to be a part of another post but I've decided that this piece of information should really be on its own. The idea for this post comes mainly from my experiences and observations on the programming forums I frequent, namely the Ubuntu Programming Forums. Nothing is more frustrating than someone who won't help themselves.
So, my first piece of advice is: Try to figure it out for yourself, first. There is a lot of information on the Internet and in books. Asking for help should not be your go-to course of action. Indeed, consider it your last line of defense. Let's be honest, while it may be the easiest, it's certainly not the fastest and probably not the most exhaustive. Sometimes, you're lucky to get an answer all. So, search first and ask second.
If you want to get an answer quickly, learn how to use search engines properly. I can't stress this enough. Think about what you're asking. Try to make your search terms very specific but not overly complicated. A good search will likely only contain a couple words. It should not be a full sentence or proper English (or whatever tongue you're searching in). "How do I compile a program," is less effective than, "compile c" isn't. After looking at the first couple results and you decide it's not helping (they're all on how to compile c on windows or in an IDE and you need to know how to compile it on the Linux command line) you need to grow your search criteria, "compile c linux command line." The order of terms isn't usually important. For more help on optimizing your search results try, "google search help," and blam, you get an answer.
So, my first piece of advice is: Try to figure it out for yourself, first. There is a lot of information on the Internet and in books. Asking for help should not be your go-to course of action. Indeed, consider it your last line of defense. Let's be honest, while it may be the easiest, it's certainly not the fastest and probably not the most exhaustive. Sometimes, you're lucky to get an answer all. So, search first and ask second.
If you want to get an answer quickly, learn how to use search engines properly. I can't stress this enough. Think about what you're asking. Try to make your search terms very specific but not overly complicated. A good search will likely only contain a couple words. It should not be a full sentence or proper English (or whatever tongue you're searching in). "How do I compile a program," is less effective than, "compile c" isn't. After looking at the first couple results and you decide it's not helping (they're all on how to compile c on windows or in an IDE and you need to know how to compile it on the Linux command line) you need to grow your search criteria, "compile c linux command line." The order of terms isn't usually important. For more help on optimizing your search results try, "google search help," and blam, you get an answer.
My second piece of advice: When asking questions on a web forum make sure you ask something specific and give as much information as possible. Asking, "How do I compile a program," is so nebulous that if you get an answer at all, it likely won't be very friendly. You need to specify what language you need to compile, which operating system and/or distribution, and any prior experience you have. Saying something like, "I've done some searching and couldn't turn anything up..." or "After a couple searching, I'm still confused because..." will help but, let's face it, if you really haven't done that people are going to know. Assume they're a lot smarter than you are until they prove you wrong (and many will). Do your homework. Like I've said already, it becomes obvious quickly if you haven't. People become hostile if all you do is want them to do the work and not do any yourself. Try and be as self-sufficient as possible. Take the initiative. Only ask questions when you just can't figure it out yourself and searches aren't getting you anywhere.
My third piece of advice: Make sure your question is relevant to the forum you're in. If you're on a Linux forum don't ask a Windows-only question. It's not that people can't answer or will be offended by it (though they might) but do you really think that is going to be the best source of answers? Doesn't it make sense to go where a lot of other Windows developers are? Asking why a program won't install or how to create a web page on a programming forum (happens all the time) make sense to you? What relevance does it have? Why kind of help are you really expecting? Would you ask a doctor how to build a house, ask a police officer how to tend your lawn or a cab driver how to fly an airplane? Basically, don't ask off-topic questions! If you have an honest question, no matter how basic or silly, and you've clearly tried to help yourself, then most people will be happy to help.
My last piece of advice: Think for yourself. Think about what you've been told and see if it makes sense. Does it agree with what you already know? Always check more than once source to make sure they agree (in computing, they often don't). There's a lot of bad advice (hopefully, this isn't) out there so it's always a good idea to not accept the first thing you read and keep looking at at least two or three alternative sources. Make sure the sources are credible too. Why would you trust the authority of someone if they've done nothing to back it up. There's a huge difference between theoretical knowledge and practical knowledge.
Good hunting.
My third piece of advice: Make sure your question is relevant to the forum you're in. If you're on a Linux forum don't ask a Windows-only question. It's not that people can't answer or will be offended by it (though they might) but do you really think that is going to be the best source of answers? Doesn't it make sense to go where a lot of other Windows developers are? Asking why a program won't install or how to create a web page on a programming forum (happens all the time) make sense to you? What relevance does it have? Why kind of help are you really expecting? Would you ask a doctor how to build a house, ask a police officer how to tend your lawn or a cab driver how to fly an airplane? Basically, don't ask off-topic questions! If you have an honest question, no matter how basic or silly, and you've clearly tried to help yourself, then most people will be happy to help.
My last piece of advice: Think for yourself. Think about what you've been told and see if it makes sense. Does it agree with what you already know? Always check more than once source to make sure they agree (in computing, they often don't). There's a lot of bad advice (hopefully, this isn't) out there so it's always a good idea to not accept the first thing you read and keep looking at at least two or three alternative sources. Make sure the sources are credible too. Why would you trust the authority of someone if they've done nothing to back it up. There's a huge difference between theoretical knowledge and practical knowledge.
Good hunting.
Saturday, 6 August 2011
An Introduction of Sorts, Part 4
In the final installment of my introduction I'd like to move away from programming. There's no question that Programming is a big part of my life. I am currently working on my Vocab Builder project and it will take me a long time to complete, if ever. I also like computers in general. I like to game. I'm adept at many office programs (both free and propriety). I follow developments in software patents, something I'm fairly against. Patents, I mean, not following the news about them. I use Linux extensively and believe in Free and Open Source Software. Not to be confused with the now nebulous Open Source Software which gets paraded around these days like a wolf in sheeps' clothing. I'm no granola crunching, long haired, smelly hippy mind you. I also support proprietary software; everything has its place. But, on to other things!
First and foremost, I'm a proud father of two young girls. Most days I love being a dad. It is an incredible experience. Most days. I won't lie to you though. It's not all roses and sunshine. Some times it's not fun being a parent. Heck, there are a lot of days like that! Thankfully, though, the good outweighs the bad. There are so many things people never tell you about being a parent and in many ways that does everyone a disservice. Everyone is led to believe that, while parenting isn't easy, it's not hard either. They don't ever give you the full picture. Mind you, if they did, you might make yourself a eunuch or use some other form of irreversible birth control!
I work as a credit manager for a small-medium distribution company. I enjoy working with numbers and finances so the job works well for me. I can support my family and do something I don't hate. Most of the people I work with are fantastic people too. Nutty, like me.To quote J.K. Rowling, we're, "Nuttier than squirrel pooh." What more could you ask for? Well, less of a commute but I'm just being picky now, aren't I?
My lovely wife is a stay-at-home mom. About two years ago, while on maternity leave with my first daughter, she decided to start a hobby making children's shirts. Well, not making the shirts but buying blank shirts and putting a design on them. Mostly they're clever sayings. I came up with the clever ones. No really! The hobby has now changed into a business called Geekling Designs. My wife, Jennifer, and I run the business jointly, discussing new ideas for designs, the company's direction, the acquisition of equipment and regular day-to-day business decisions. Sometimes I'm amazed at how little we fight. I mean, we all have disagreements. Or, should I say, I'm always right and she sometimes, incorrectly, disagrees with me. It's not easy though, having a full time job, two young children and a business to run. I'm just thankful, each and every day, that I'm not where my wife is sitting. At home all day with two young children both under 4 and trying to run a business at the same time? No thanks! It's time to go to work! See ya, hun!
We also have two pets. A cat and a Pug. Pug owners understand why I didn't call our Pug a dog. They're not dogs. They're smelly, snuffly, loud, barrels with legs with so much personality it just oozes out of them. Literally some times. It's ever so fun cleaning eye goop out of their nose fold/wrinkle. She's getting too fat too, from lack of exercise, so we need to get her running about more. Just that the heat makes her wheezy and she chokes on her own tongue. Lovely. The cat, on the other hand, is equally a pain but we love her. If she feels like she's not getting enough attention she likes to bunt your cup containing scalding hot tea as you bring it to your lips. Or sit on your CRT monitor with her back to you and dangle her tail in front of the screen. When that doesn't work, she'll casually stretch out over the monitor and dangle a front and back leg over the screen and try and bring in the tail for some extra added interference. If it's the LCD screen, she just sits in front of it and stares at you.
All in all, the zoo in which I live is incredibly entertaining and fun. I may complain from time to time but make no mistake: I love each and every one of them.They're all a part of me. Who I am and who I'll become. I hope that nothing ever happens to take them away from me as I'll certainly be the lesser for it.
And that, as they say, is that!
First and foremost, I'm a proud father of two young girls. Most days I love being a dad. It is an incredible experience. Most days. I won't lie to you though. It's not all roses and sunshine. Some times it's not fun being a parent. Heck, there are a lot of days like that! Thankfully, though, the good outweighs the bad. There are so many things people never tell you about being a parent and in many ways that does everyone a disservice. Everyone is led to believe that, while parenting isn't easy, it's not hard either. They don't ever give you the full picture. Mind you, if they did, you might make yourself a eunuch or use some other form of irreversible birth control!
I work as a credit manager for a small-medium distribution company. I enjoy working with numbers and finances so the job works well for me. I can support my family and do something I don't hate. Most of the people I work with are fantastic people too. Nutty, like me.To quote J.K. Rowling, we're, "Nuttier than squirrel pooh." What more could you ask for? Well, less of a commute but I'm just being picky now, aren't I?
My lovely wife is a stay-at-home mom. About two years ago, while on maternity leave with my first daughter, she decided to start a hobby making children's shirts. Well, not making the shirts but buying blank shirts and putting a design on them. Mostly they're clever sayings. I came up with the clever ones. No really! The hobby has now changed into a business called Geekling Designs. My wife, Jennifer, and I run the business jointly, discussing new ideas for designs, the company's direction, the acquisition of equipment and regular day-to-day business decisions. Sometimes I'm amazed at how little we fight. I mean, we all have disagreements. Or, should I say, I'm always right and she sometimes, incorrectly, disagrees with me. It's not easy though, having a full time job, two young children and a business to run. I'm just thankful, each and every day, that I'm not where my wife is sitting. At home all day with two young children both under 4 and trying to run a business at the same time? No thanks! It's time to go to work! See ya, hun!
We also have two pets. A cat and a Pug. Pug owners understand why I didn't call our Pug a dog. They're not dogs. They're smelly, snuffly, loud, barrels with legs with so much personality it just oozes out of them. Literally some times. It's ever so fun cleaning eye goop out of their nose fold/wrinkle. She's getting too fat too, from lack of exercise, so we need to get her running about more. Just that the heat makes her wheezy and she chokes on her own tongue. Lovely. The cat, on the other hand, is equally a pain but we love her. If she feels like she's not getting enough attention she likes to bunt your cup containing scalding hot tea as you bring it to your lips. Or sit on your CRT monitor with her back to you and dangle her tail in front of the screen. When that doesn't work, she'll casually stretch out over the monitor and dangle a front and back leg over the screen and try and bring in the tail for some extra added interference. If it's the LCD screen, she just sits in front of it and stares at you.
All in all, the zoo in which I live is incredibly entertaining and fun. I may complain from time to time but make no mistake: I love each and every one of them.They're all a part of me. Who I am and who I'll become. I hope that nothing ever happens to take them away from me as I'll certainly be the lesser for it.
And that, as they say, is that!
An Introduction of Sorts, Part 3
The next step of our journey takes us through the second to last leg of my introduction.
So, in my escapades with C, I have learned the following:
1) C is not the best language for every task. Naively, I thought that if I started with C not only would I be able to write any kind of program (which you can) a person can conceive of but that it would act as the basis for learning any future languages (which it doesn't) should I so desire.
2) There are many cool languages to learn, too many in fact. In working through Beginning Linux Programming I came across Tcl/Tk, Perl and shell scripting (Bash specifically). Through other sources I came across Java, Python, LISP and Go. And from there things explode. There are literally hundreds of languages out there!
3) Learning a language doesn't teach you to program, at least, not well. As it turns out, knowing a language doesn't help you much. Algorithms and structure go a lot further in teaching programming. Understanding how to implement a linked list, the best method to store persistent data or the most efficient method of manipulating data is far more essential than knowing where to place a semi-colon or bracket.
4) A compiled language is not the end-all be-all. The JVM, for example, is very cool and Java has all kinds of implementations. You don't need to write Java to use the JVM. Clojure or Jython are examples of languages which are compiled to Java bytecode for execution on the JVM and can take advantage of everything it can provide.
5) Interpreted languages like Perl, Tcl or Python are not slow. First thing to remember, is that over the years things improve and a lot of information on the Internet is old. Really old. A post from 2002 ranting on how slow Python is, is no longer relevant. A heck of a lot has changed in 9 years. With the way technology changes these days, a matter of months can make all the difference. It also has to do with writing idiomatic code and implementing good/quick algorithms which complement the language. While yes, in certain instances, a C implementation of a specific task is faster than the equivalent in Python. However, compare parsing lines of text with C or C++ to Perl. Write an application with a GUI in C and compare that with Tcl/Tk, Java or Python. It's all about matching the tool with the job. You don't bring a hammer to tighten a screw.
6) There is no one way to do something. Quicksort or Bubble Sort are not the only ways to sort data. Not only that but often language implementations may be faster than anything you come up with on your own. You need to know the strengths and weaknesses of the language you're working in to get the most out of it.
7) Dynamic Linking is not necessarily superior to Static Linking. It is also not to be confused with Dynamic Loading. Google's Go language taught me that.
8) Skills aren't necessarily transferable. Knowing how to manipulate pointers, manage memory and use pre-processor directives doesn't usually apply outside the C world. Many languages don't have pointers (or are at least not the headache they are in C), use garbage collection and have no need of pre-processor directives. That doesn't mean that C, or any other language (read: all), with non-transferable skills don't have something to teach. It just means that everything you learn won't be transferable to another language.
9) There is a trade-off between writing a fast program and writing a program quickly. No one wants a slow and sluggish application. On the other hand, a couple seconds overall is likely not even noticeable in most situations. Now, compare that with how quickly a program can be written in Python or Go to C or C++. There's no comparison.
10) Design is where you should spend 90% of your time. I can't stress this enough. An excellent programmer following poor design will create a mediocre application. A poor programmer implementing an excellent design will create a good program. If you can combine the two, a good design with a good programmer, and you'll make an awesome application.
11) Benchmarks mean little to nothing. Look no further than this example. Any language can be optimized in such a way but I can't think of a better example.
It's funny that, reading back, I haven't even scratched the surface of what there is to learn but this certainly is a foundation for describing how much I know.
In the end, not much.
So, in my escapades with C, I have learned the following:
1) C is not the best language for every task. Naively, I thought that if I started with C not only would I be able to write any kind of program (which you can) a person can conceive of but that it would act as the basis for learning any future languages (which it doesn't) should I so desire.
2) There are many cool languages to learn, too many in fact. In working through Beginning Linux Programming I came across Tcl/Tk, Perl and shell scripting (Bash specifically). Through other sources I came across Java, Python, LISP and Go. And from there things explode. There are literally hundreds of languages out there!
3) Learning a language doesn't teach you to program, at least, not well. As it turns out, knowing a language doesn't help you much. Algorithms and structure go a lot further in teaching programming. Understanding how to implement a linked list, the best method to store persistent data or the most efficient method of manipulating data is far more essential than knowing where to place a semi-colon or bracket.
4) A compiled language is not the end-all be-all. The JVM, for example, is very cool and Java has all kinds of implementations. You don't need to write Java to use the JVM. Clojure or Jython are examples of languages which are compiled to Java bytecode for execution on the JVM and can take advantage of everything it can provide.
5) Interpreted languages like Perl, Tcl or Python are not slow. First thing to remember, is that over the years things improve and a lot of information on the Internet is old. Really old. A post from 2002 ranting on how slow Python is, is no longer relevant. A heck of a lot has changed in 9 years. With the way technology changes these days, a matter of months can make all the difference. It also has to do with writing idiomatic code and implementing good/quick algorithms which complement the language. While yes, in certain instances, a C implementation of a specific task is faster than the equivalent in Python. However, compare parsing lines of text with C or C++ to Perl. Write an application with a GUI in C and compare that with Tcl/Tk, Java or Python. It's all about matching the tool with the job. You don't bring a hammer to tighten a screw.
6) There is no one way to do something. Quicksort or Bubble Sort are not the only ways to sort data. Not only that but often language implementations may be faster than anything you come up with on your own. You need to know the strengths and weaknesses of the language you're working in to get the most out of it.
7) Dynamic Linking is not necessarily superior to Static Linking. It is also not to be confused with Dynamic Loading. Google's Go language taught me that.
8) Skills aren't necessarily transferable. Knowing how to manipulate pointers, manage memory and use pre-processor directives doesn't usually apply outside the C world. Many languages don't have pointers (or are at least not the headache they are in C), use garbage collection and have no need of pre-processor directives. That doesn't mean that C, or any other language (read: all), with non-transferable skills don't have something to teach. It just means that everything you learn won't be transferable to another language.
9) There is a trade-off between writing a fast program and writing a program quickly. No one wants a slow and sluggish application. On the other hand, a couple seconds overall is likely not even noticeable in most situations. Now, compare that with how quickly a program can be written in Python or Go to C or C++. There's no comparison.
10) Design is where you should spend 90% of your time. I can't stress this enough. An excellent programmer following poor design will create a mediocre application. A poor programmer implementing an excellent design will create a good program. If you can combine the two, a good design with a good programmer, and you'll make an awesome application.
11) Benchmarks mean little to nothing. Look no further than this example. Any language can be optimized in such a way but I can't think of a better example.
It's funny that, reading back, I haven't even scratched the surface of what there is to learn but this certainly is a foundation for describing how much I know.
In the end, not much.
Wednesday, 3 August 2011
An Introduction of Sorts, Part 2
Learning C without the help of formal education isn't the easiest task. Some times I feel like MacGyver trying to use an elastic band, a paperclip and a funnel to make a rocket ship. No really! That's what trying to write a game or large program is like in C. The language gives you some rudimentary tools with which to craft intricate art with. However, that being said some very powerful programs can be written in C. You just need to learn how to use the tools and fine tune their use.
I would describe myself as an intermediate to advanced C programmer. By no means am I an expert and I'm a far cry from being a master/guru. To understand why I consider myself thus, you need to understand the full breadth of a computer language. Any one computer language consists of two parts: 1) Syntax, 2) Libraries and Tools. Learning the syntax and idioms of a language can be difficult but as you grow and learn it turns out that discovering the idiosyncrasies of a language is the easy part. Learning the standard and third party libraries and tools are the hard part. When I began learning C, I thought that once I had learned the language I was done. I was a master. Just call me Yoda. Ya, right. Let's see...what do we need to know:
1) Language Grammar: punctuation (semi-colons, brackets), code blocks, scope, reserved words, loops, conditionals, macros, preprossessor directives, etc. all make up language syntax;
2) Compiling: compiler flags, linker flags, and all other manners of subtle nuances of each compiler you need to know in order to even build your code;
3) Debuggers: backtraces, core dumps, debugging programs (gdb), profiling and symbol tables are some of the tools you need to learn to be an effective programmer in C;
4) Standard Libraries: printing, strings, locales, file input/output, etc.;
5) Non-Standard Standard Libraries: "You're kidding me, right?" you might be asking. Oh, no! I'm not joking. Unix libraries vs. Windows, POSIX libraries, and all manner of things in between. Start learning sockets, you'll see what I mean;
6) Standards Complient: No, there's no one version of C. There are several C standards and more are on the way. Learning C once isn't the end. You'll need to keep reviewing the new standards, especially when a compiler changes to a different default standard (C89 for gcc but I expect it to change C99 eventually);
7) Third-Party Libraries: This is the balance of all the other libraries out there. For C? There's a LOT.
8) Portability: This one is a mixed bag and it depends on how people are using the word. For some, portable code means it can be ported to other Unix variants like BSD, Linux, etc.. For others, like myself, I take it to mean code can be ported between operating systems. In most cases, this is no easy task and can quickly turn into a nightmare. Remember I mentioned sockets? Just the tip of the iceburg. More on that in another post.
I feel like I'm missing something. I probably am.
Well, there is something. A couple somethings. There are the tools you need to work with your code. The first of these is a development platform. What operating system do you use to program on? I, personally, program on my Ubuntu Linux box. You'll need to pick up a compiler. The most popular in the Linux world are GCC and LLVM. You'll need to install a debugger. How about an automatic build system? Oh, don't forget a programming environment. Now, I prefer to use a terminal and a text editor. Others, especially those from the Windows world, prefer an IDE.
I eventually chose a book called Beginning Linux Programming. Now, I already had enough background to jump right in and this turned out to be a fantastic book for me. Now, it is more focused on Linux programming, as the name implies, but it also teaches theory and techniques usable by anyone. The main thing I learned was that I had a lot more to learn. A lot more.
Your mind fried yet? I know mine is.
I would describe myself as an intermediate to advanced C programmer. By no means am I an expert and I'm a far cry from being a master/guru. To understand why I consider myself thus, you need to understand the full breadth of a computer language. Any one computer language consists of two parts: 1) Syntax, 2) Libraries and Tools. Learning the syntax and idioms of a language can be difficult but as you grow and learn it turns out that discovering the idiosyncrasies of a language is the easy part. Learning the standard and third party libraries and tools are the hard part. When I began learning C, I thought that once I had learned the language I was done. I was a master. Just call me Yoda. Ya, right. Let's see...what do we need to know:
1) Language Grammar: punctuation (semi-colons, brackets), code blocks, scope, reserved words, loops, conditionals, macros, preprossessor directives, etc. all make up language syntax;
2) Compiling: compiler flags, linker flags, and all other manners of subtle nuances of each compiler you need to know in order to even build your code;
3) Debuggers: backtraces, core dumps, debugging programs (gdb), profiling and symbol tables are some of the tools you need to learn to be an effective programmer in C;
4) Standard Libraries: printing, strings, locales, file input/output, etc.;
5) Non-Standard Standard Libraries: "You're kidding me, right?" you might be asking. Oh, no! I'm not joking. Unix libraries vs. Windows, POSIX libraries, and all manner of things in between. Start learning sockets, you'll see what I mean;
6) Standards Complient: No, there's no one version of C. There are several C standards and more are on the way. Learning C once isn't the end. You'll need to keep reviewing the new standards, especially when a compiler changes to a different default standard (C89 for gcc but I expect it to change C99 eventually);
7) Third-Party Libraries: This is the balance of all the other libraries out there. For C? There's a LOT.
8) Portability: This one is a mixed bag and it depends on how people are using the word. For some, portable code means it can be ported to other Unix variants like BSD, Linux, etc.. For others, like myself, I take it to mean code can be ported between operating systems. In most cases, this is no easy task and can quickly turn into a nightmare. Remember I mentioned sockets? Just the tip of the iceburg. More on that in another post.
I feel like I'm missing something. I probably am.
Well, there is something. A couple somethings. There are the tools you need to work with your code. The first of these is a development platform. What operating system do you use to program on? I, personally, program on my Ubuntu Linux box. You'll need to pick up a compiler. The most popular in the Linux world are GCC and LLVM. You'll need to install a debugger. How about an automatic build system? Oh, don't forget a programming environment. Now, I prefer to use a terminal and a text editor. Others, especially those from the Windows world, prefer an IDE.
I eventually chose a book called Beginning Linux Programming. Now, I already had enough background to jump right in and this turned out to be a fantastic book for me. Now, it is more focused on Linux programming, as the name implies, but it also teaches theory and techniques usable by anyone. The main thing I learned was that I had a lot more to learn. A lot more.
Your mind fried yet? I know mine is.
An Introduction of Sorts, Part 1
Learning to program can be a very daunting task. It doesn't seem that way at first, of course, but once you dive in you finally get to see what it's all about. It's like being a parent. No one can prepare you for being a parent. I realize that phrase is getting cliche but that makes it no less true. Your kids can make you incredibly happy and unbelievably angry. You're tired all the time. You get no time to yourself. You're delirious with frustration and lack of sleep. Same with programming. Well, except having no time for yourself. You get a lot of that.
Like most kids, my life with computers started with video games. The problem is, the more you play the more critical you become. "These graphics suck!" you say, and "That's a terrible bug! How did this junk ever get out the door?" Eventually, you might even think, "I can do better!" So, you put your money where your mouth is and here you are. Programming. Ya, not so easy is it?
First off is language choice. Now, if you decide to pursue programming as a career and head to college or university your choices are narrow. You basically get to pick whatever it is your school curriculum decides to teach first year students. But, if you're like me and went to school to attain some other degree or didn't go to school at all, you'll find out that the choice isn't a simple one. There are literally hundreds of languages for all kinds of tasks which are all perfect for you! Which one is right? Which should I pick first? I wish I could help you. There's no easy answer and I have neither time or desire to help. Sorry.
Now, I did happen to putter around with BASIC when I was in high-school and I tinkered with a rather obscure language called LPC. I did happen to take a first year programming course in college in which I was introduced to C which was remarkably like LPC. Later on I took a Visual BASIC and second year C++ courses. I did well with Visual BASIC but I failed miserably in the C++ course, dropping out early in the term. To program you need to be in the right frame of mind. You need to be ready for the world of programming as much as it needs to be ready for you! "Look out world! Here I come!" BLAM! Right into a brick wall. That's how it is. If you expect it to be easy, think again. Anyone who says that it is, is either a liar or a genius. Smart money is on the former.
Many years down the road I decided to give programming another go. I still played with LPC a bit but now I wanted to do "real" programming (to understand why I felt this way, perhaps check what LPC is used for). My path lead to me back to C, and this time, I was ready.
Like most kids, my life with computers started with video games. The problem is, the more you play the more critical you become. "These graphics suck!" you say, and "That's a terrible bug! How did this junk ever get out the door?" Eventually, you might even think, "I can do better!" So, you put your money where your mouth is and here you are. Programming. Ya, not so easy is it?
First off is language choice. Now, if you decide to pursue programming as a career and head to college or university your choices are narrow. You basically get to pick whatever it is your school curriculum decides to teach first year students. But, if you're like me and went to school to attain some other degree or didn't go to school at all, you'll find out that the choice isn't a simple one. There are literally hundreds of languages for all kinds of tasks which are all perfect for you! Which one is right? Which should I pick first? I wish I could help you. There's no easy answer and I have neither time or desire to help. Sorry.
Now, I did happen to putter around with BASIC when I was in high-school and I tinkered with a rather obscure language called LPC. I did happen to take a first year programming course in college in which I was introduced to C which was remarkably like LPC. Later on I took a Visual BASIC and second year C++ courses. I did well with Visual BASIC but I failed miserably in the C++ course, dropping out early in the term. To program you need to be in the right frame of mind. You need to be ready for the world of programming as much as it needs to be ready for you! "Look out world! Here I come!" BLAM! Right into a brick wall. That's how it is. If you expect it to be easy, think again. Anyone who says that it is, is either a liar or a genius. Smart money is on the former.
Many years down the road I decided to give programming another go. I still played with LPC a bit but now I wanted to do "real" programming (to understand why I felt this way, perhaps check what LPC is used for). My path lead to me back to C, and this time, I was ready.
Subscribe to:
Posts (Atom)