The Software Purist |

TAG | XML

I was interviewing a candidate recently, and we were talking about some of the programming languages he claimed to know, which was mainly focused around C++ and C#. We started to discuss some of the types of problems he finds easier to solve in each when he said something I found very misleading: “A programming language is really just syntax”. As we talked more, I started to ponder what a shallow understanding of a language this really was. It’s kind of like questioning whether a dollar is a dollar is a dollar. Smart financial people know that the source of the dollar is very important, and so the utter simplification is misleading.

Before I get too far into this, I will note that if you’re using .Net, you can get a lot closer to making the premise of the initial argument, because the .Net languages all can support the same APIs. That wasn’t the case for this individual, as he was using C++, not C++/CLI. With that being said, let’s get into some of the real substantial differences:

1) The standard libraries that the language supports. I find this to be one of the most underrated aspects of working with a language. I think part of the reason is that when you use some languages (C++) there’s a large population of programmers who don’t really make good use of the standard libraries. In my experience, this is often because they sometimes fall into using non-portable APIs, such as Microsoft’s ATL or MFC instead of STL containers, or libraries that may be considered more suitable for an embedded environment. Anyway, I think this is a critical feature, because, again consider the example of C++: Something as commonly used as XML is not standard. This is almost unfathomable for programmers of languages like Java or C#. Meanwhile, the flipside is .Net, which is immense and becomes very difficult for a developer to be proficient in all of it.

2) Third party libraries the language supports. I would consider this almost as important as the standard libraries issue. Unlike the standard libraries, there’s a much better chance that the third party libraries have API interfaces to be used in multiple languages. This will be one of the the top things you would consider when choosing the appropriate language for a task.

3) Language Paradigms: This is another feature which gets underrated at times. Does the language properly support Object-Oriented Programming? Template Meta-Programming? Functional? How easily does it support multi-threading? Again, all of these are critical differences between languages which go well beyond syntax.

4) Static Typing or Dynamic Typing or Both (coughC#cough)? With static typing, you can potentially find a lot of structural errors during compile time and need less code coverage during your unit tests. With dynamic typing, you don’t have these luxuries, but have much better support for rapid development.

5) The tools that are supported for your language.

6) Syntax. I consider this one of the least important differences between languages. It’s very easy for a professional programmer to adjust to a new syntax, assuming it isn’t completely nonsensical.

In the end, I think of this like deciphering any sort of spoken or written language. At the end of the day, if you aren’t able to communicate effectively, then your words are meaningless. This goes far beyond sentence structure. When discussing programming languages, it goes far beyond syntax.

· · · · · · · · ·

Nov/09

23

Boost 1.41.0

I was very excited when I noticed that the C++ Boost library has a new release which just came out, Boost 1.41.0.  Going through the release notes, there are some significant bug fixes in some of the libraries I use.  In addition, there is a new library called Property Tree.  This seems like a simple, but very useful concept for storing different types of property and configuration data.  I am already considering using it on a project I’m working on.  I like that it supports both XML and JSON.  This is a bonus for me, because both protocols are so widely used and have their own benefits and drawbacks, I like to support both whenever possible.  You can check out the “Five Minute Tutorial” here: Boost.PropertyTree Tutorial.

While we’re at it, it’s a good time to give a quick overview of the magic boost building incantation I use. Boost has their own building system called Bjam, which you will need to download. Unfortunately, Boost Build has it’s own proprietary building system, which is generally only useful for Boost projects, and so, it’s usually worth only learning the bare minimum to build, unless you’re planning on making your own Boost-style library, or possibly making heavy edits to a Boost distribution (which I generally discourage). Here is the line I use to build:

bjam –toolset=msvc-9.0 –build-type=complete stage

This, of course, builds everything. This may be more than what you need, and so things can be tweaked as needed, by changing the build type or adding additional flags. You can change the compiler version by changing the toolset (e.g.: msvc-8.0 will build Visual Studio 2005). Additionally, certain libraries are not built, unless you set additional environment variables beforehand, to indicate you want to build them. As a quick example, if you need ZLIB support, you have to set the ZLIB_BINARY, ZLIB_INCLUDE and ZLIB_LIBPATH environment variables before executing. I usually gather all the options I want and then make a batch file, which I check into source control, so that I can always repeat this build process.

You can get the new Boost release here: Boost

· · · · ·

Theme Design by devolux.nh2.me