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!
Showing posts with label intro. Show all posts
Showing posts with label intro. Show all posts
Saturday, 6 August 2011
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)