Saturday, June 28, 2014

Learn how to use threads in C#

For some odd reason, the article I wrote about loving C# yesterday sparked a flurry of emails asking me about threading. So I thought I'd write a quick and dirty tutorial on how to write multithreaded applications in C#. It's not going to be enterprise-class software, but it should give you a good enough idea to get you started.

First, what is multithreading?

Multithreading is the process of running multiple instructions on a computer at the exact same time. Today's computers often have 4-8 cores which means you can execute 4-8 instructions at the same time by using multithreading programming concepts.  That often (but not always) means your software will do things faster because it can chew through data and instructions at a more rapid rate that a single threaded application.

How about an example?

The code below is a simple example of how to write a multithreaded application in C#. It's not complex and you should be able to figure it out but we'll walk through it once we're done anyway.

using System;
using System.Threading;

namespace AMulthreadedApplicationExample
{
    class ThreadedProgram
    {
        public static void MyChildThread()
        {
            Console.WriteLine("Hello World from thread #2!");
        }
        
        static void Main(string[] args)
        {
            ThreadStart childthrd = new ThreadStart(MyChildThread);
            Console.WriteLine("Hello World from thread #1!");
            Thread childThread = new Thread(childthrd);
            childThread.Start();
            Console.ReadKey();
        }
    }
}
Much of this code should already be familiar to you as it's all part of a standard C# program. So let's look specifically at the MyChildThread() method and a few statements in the Main() method.

As you can see, the MyChildThread() method is nothing special. It's just a standard method that gives no hint that it's going to be run in a multhreaded way. All the magic happens in the Main() method and it's pretty easy to understand.

First, we define a ThreadStart delegate called 'childthrd' and pass the name of the method we want to execute in the new thread to its constructor. In the third line we actually create the new thread, passing the ThreadStart delegate in the constructor of the new thread. Finally, We execute the new thread with a call to the Thread.Start() method. This last line of code is what actually starts (or schedules to start) the new thread that executes the MyChildThread() method.

Once started, threads usually run to their end and then gracefully die. But there might be times that you want to explicitly kill a thread before it finishes executing. This too is amazingly easy. To kill a thread prior to its completion you simply use the Thread.Abort() method and it kills it. It's that simple. 

While this is not, by any stretch of the imagination, an exhaustive look at threads, it should be enough for you to start doing your own research. Threads are a powerful way to write high performing software and, once you learn them, you'll find all sorts of situations where they come in handy.

Happy multitasking!







































Friday, June 27, 2014

Finding "the programming language of your soul"

Most of you who've read this blog for any length of time know that I'm not a well-rounded programmer. I don't jump from one 'latest hot language' to the next and I'm definitely not up to speed on a lot of the languages that people are so excited about today. That's because I made a decision long ago to invest my time in only learning languages that I thought would be beneficial to my career in the long term. For the most part, that's meant Java, C++, C#, Python, and Xojo. I "know" other languages and can get around in them and I can learn other languages quickly, but those five are pretty much my bread and butter and I've made the most investment in mastering them.

Out of the handful of languages I've taken the time to learn well, there are two that have delighted and surprised me so much that I've labeled them 'the languages of my soul' (hat tip to Scott Hanselman for the awesome new term). Those languages are C# and Xojo.

For completely different reasons, each of these languages have captured my attention and made me feel at home when I'm working on them. And while their approach to most tasks are radically different, I never feel like I have to struggle against the compiler or the language (I'm looking at you C++) to get work done quickly.  Don't get me wrong, both of these languages have also caused enormous frustration in my life, but it seems like every time I have real work to do, I find myself reaching out to one of them.

You might ask yourself, what's so special about these two languages in particular and why should I consider them? There are a number of things I love about each; most importantly their approach to development. C# gives me the near raw power of C++ without all the nasty headaches, gotcha's, pointers, and garbage collection worries, while Xojo just makes the old Visual Basic developer in me happy making even the most complex tasks just a few lines of code away.

But you shouldn't consider any of that. Each of us will come to the languages of our soul in different ways. I know some people who feel a near spiritual connection with Java or Python, or Lisp. I don't understand it, but I have to respect that those are the languages they've bonded with. It's what works for them. So don't take my word and simply choose C# or Xojo as your primary languages (though both would make really good choices), go out and experiment and find the language you connect the most with. Maybe that's C# and Xojo, maybe it's not. But whatever it ends up being, you will never want to work in any language again.

That's how you know your soul has found a home.






Sunday, June 15, 2014

Saying Goodbye to Xojo on Linux: Breaking up is Hard to Do

I've been using the Xojo programming language for a few years now.  When I left Windows for Linux, I began looking for a decent, easy to use, cross-platform language that not only allowed me to compile my software for different platforms but also allowed me to write it on different platforms too.

Having been a C# developer for a number of years, I naturally gravitated towards Mono. Mono was good and handled a lot of what I was doing with very little problems. But I didn't like the 'Microsofty' feel to it or the fact that support for it appeared to be declining on Linux as a whole. There were also signs that Mono was about to start focusing less on the desktop and more on mobile development, which was cool, but not a good sign for my future desktop development projects.  So, pretty quickly, Mono was out of the game for me.

Then, one day, I was having a conversation with a friend and was complaining about my development woes. He was exploring Xojo (then called RealStudio) and recommended I try it. He gushed about the cross-platform nature of both the code you wrote and the IDE and, pretty quickly, I was hooked. Sure, there weren't a lot of contract jobs asking for Xojo developers, but I didn't do a lot of contract work anyway. When you sell software for a living, most people don't really care what language it's written in. So began my love-affair with Xojo - a love affair that continues to this day, mind you.

You might be asking yourself: if he loves Xojo so much, why is he abandoning it on Linux? Good question and there's an equally good answer for it: on Linux, Xojo is basically unusable. 

I'll be the first to say that Xojo has always had its share of bugs. It's not nearly as mature as languages like C# or IDE's like Visual Studio. But it's been totally usable for a number of years. Then, I started to notice problems on the Linux side of things. First, the 2012 IDE would simply segfault and crash when started on Linux, then exceptions would fall through and be impossible to catch, the compiler would declare variables as 'undefined' even though I'd defined them two lines before and within the current scope, etc.  All in all, it meant that I often had to hang behind a version or two because something was always wrong with the current one. 

When I heard that Xojo was completely rewriting the IDE and improving some language features, I was excited.  This was where they're going to improve things to a more usable state on Linux, I thought. This was finally going to be us Linux devs time to shine and software written in Xojo ON LINUX would flood the marketplace.

Not quite.

Xojo released a stellar IDE with a lot of fixes for problems (exceptions work reliably and the IDE doesn't segfault!) Unfortunately, new bugs were introduced and it doesn't really look like Xojo is that interested in fixing them for Linux users. The showstopper for me is the IDE speed problem. The short of it is that, as you use the IDE, it continues to get slower and slower. After a few minutes, you'll type a whole line of code before it even shows on your screen. Moving controls within the visual editor is painfully slow too with controls often losing focus while you''re moving them and dropping back to the form.  I honestly can't even begin to tell you if there are compiler bugs in the Linux compiler because, well, I can't actually write enough code to test it out.

So I'm abandoning Xojo on Linux. I might install it in Windows and use it to compile cross-platform but I'm giving up on my dream of having Xojo run smoothly enough on Linux where I can do my primary development there. For Linux, I'm going back to C# and Mono. It's not my preferred choice but it works and it's stable.  I hope that Xojo takes a stronger interests in us Linux devs and actually fixes the issues it has on the platform but it just doesn't seem to be a huge priority for them.

Now, what I wrote above sounds like an awful lot of complaining and it is. Xojo is asking professional developers to spend upwards of $1000 or more for a product that you will find unusable when you install it on Linux.  I don't completely fault Xojo for this though.  Xojo use on Linux is probably a minuscule part of their user base. Mac seems to be tops with Windows being second. They don't make a lot of money on Linux and there is no compelling reason for them to invest engineering time and resources into making it a world class product. There are a number of reasons most Linux devs don't use Xojo and stability has nothing to do with it. So, even if Xojo fixed the problems, they still wouldn't make money and I definitely don't expect them to spend time and money for such a little payout.

Still, I'm a bit sad. I really like Xojo and I love how fast it is to develop with. Perhaps I'll buy a Mac and use that as my development machine just so I can enjoy Xojo.  But I sure wish I didn't have to. Maybe it's a case of wanting my cake and eating it too. Maybe I want too much from a company that doesn't make much money from my platform of choice. Perhaps I and my choice are the problem.

But perhaps...just perhaps...it will get better.