Posts Tagged ‘c++’

Scala, a cursory glance

April 8th, 2009
Recently, the Scala language was brought to my attention.

Now, I've been around the language block a few times, having seen my share of languages. I'm aware and suspicious of the siren-like call new languages have for programmers. They tickle our programming curiosities to the core, offering silver-bullet, paradigm-shifting opportunities for increased productivity. Unfortunately, they require lots of commitment, community, support libraries and momentum to become useful, so one has to be pragmatic when adopting new languages. I tend to error more on the conservative side, but Scala beckoned me to have a closer look. These are my cursory observations.

What first drew me to Scala was its offering of type-safe and concise programming models, based on generics and functional programming. Although the key reason I use C++ is performance, it's the type safety and concise power of templates that keeps me there. I find type-safe languages provide for more readable and maintainable code bases, something that is critical for large and aging projects. Scala seems to push for some of these same ideals.

The first benefit of Scala is immediate: it compiles to Java byte code and is able to utilize Java libraries. This means you can integrate with your existing Java code, use the plethora of existing Java libraries and reuse the man-centuries of work that went into Java VMs. This is somewhat analogous to how C++ can use C. However, C code can (mostly) be compiled as C++ code, Scala code is not anywhere near valid Java code. Although this affords the Scala designers more freedom, it creates another learning curve for Java programmers.

I may have overestimated Scala's intended integration with Java though, as they also have a preliminary link up with .NET working. This could be interesting, or it could split its community focus.

The language itself is very functional and recursive. Functions are first class objects, specialization/type searching is handled via a powerful pattern-matching system and generics seem to be on the right track. This kind of stuff lets you build very interesting DSLs (domain specific languages), something that I think will vital for the future. This means you can build stuff like C#'s LINQ SQL query system into a programming language, without having to update the language -- all done as a library. New web presentation mark-up languages, mini-programming/scripting languages, XML query/processing, etc. could all be done as libraries. Neat stuff.

My very cursory inspections with "javap", the Java class disassembler, shows that Scala is not doing the type specific in-lining I thought it would be (for example, instantiating functions for each specific type T that is used). This means I won't get my performance wishes out of Scala, which is too bad, since that would be more interesting that providing yet another deferred-to-runtime type system (even if it has a nice type-safe compile time checker).

It's an interesting project, and I wish them the best of luck. Programming languages require large investments in time, community and libraries, and they're just beginning this long road and still have a ways to go before I'd commit any large projects to them. This segways into my final, not-really-Scala observation:

Why are the Twitter guys all hot for it?

Twitter (via programmer Alex Payne) seem to be claiming that their notorious problems with scalability and reliability can be traced back to Ruby on Rails. RoR haxxor Obie Fernandez attempts to refute this. Whether RoR can handle the load or the Twitter programmers just don't know how to use it, I don't know or care. What I do know is that if you're going to switch to something else, especially for your critical messaging queuing core, don't jump to something even more obscure and untested.

Alex Payne says Scala is fun and gives him the fuzzies, which is all fine and dandy, but for god's sake man, think about the business here and not the Scala book you're penning. You need something scalable and tested, which usually means old and boring. That's just business. Make Twitter work, sell it, and get (even more?) rich.

Alex, General , , , ,

Stupid C++ Tricks

March 7th, 2009
I recently came across this C++ Soup post, which demonstrates some cute C++ tricks. Now by cute, I mean stupid, similar to Dave Letterman's segment "stupid pet tricks" (you can google that if you've never seen this). It's a useless language exercise with little practical application except to show how obfuscated one can make C++. Are there any benefit to these tricks? Lets explore.

Now all C++ programmers do this (myself included) just to see if they understand template programming, so keep in mind that this is NOT a critique of this particular author, who I'm sure is a C++ Ninja. It's just a recent example that triggered this rant. No, just have a look at half the boost libraries to see this thinking taken to the extreme. Or even the C++ standard library; does anyone really use the cumbersome std::for_each function or any of that bind stuff? They all feel like they're unfinished ideas: they're onto something, but they're not quite there yet.

These (what I'm calling) C++ tricks are often segments of templated C++ code that push generic programming to solve some kind of basic problem, that is typically solved using simpler (but more verbose) code. A trick author is often amazed (and proud) at how small or flexible the code is, but hopefully realizes that the amount of work or expertise required to make the trick outweighs most benefits. The code is then shelved. Lets cut this silliness out.

Furthermore, most application developers will steer clear (or be ignorant) of such tricks, and popular C++ libraries do well to not require such expertise from their users.

Is there any benefit to these tricks? Yes, only to show what could be possible with C++.

C++ is an extremely powerful language, giving you compile time dynamic/generic programming with no loss of runtime performance. No other language does this so fully and completely, and C++ is still the only language option in many demanding areas.

However, the language needs to grow, and it needs to grow fast. We must look at what these tricks are trying to do, and then think how we can change the language to do the same thing in a sane, logical fashion. C++0x is working on this with lambdas, type inference, better error reporting and some other niceties. But we needed these features yesterday, and get people using them. Lets steal more features from other languages. Lets turn up the meta programming capabilities so we can extend the language without meta-compilers and preprocessors, which until now provide the bulk of the useful new language extensions.

There is no reason why C++ can't offer easy to use and powerful compile-time dynamic programming, resulting in code that looks like a dynamic scripting language, but with safer types and kick-ass performance, memory use and code size.

Lets get to work :)

Alex ,

Microsoft and Mono

February 21st, 2009
The Linux Outlaws Podcast recently (in ep. #75) had an interview with Miguel de Icaza on the topic of Mono. Since this is often a heated topic among Linux hackers, I figured I'd chime in with my two cents.

Miguel is well know in Linux land, having started the GNOME desktop and countless other desktop applications for Linux. He's done more for Linux in the past decade than most (including myself) will ever dream of doing, so critiquing such a leader can't be done lightly.

Miguel unfortunately started out as a typical C-only guy who looked on C++ as large and useless. For years with GNOME he and application developers (myself included) slaved away using the C-based GTK+ library to make graphical applications. Man-centuries were wasted dealing with cumbersome C and its unforgiving API style. C++ was ignored, almost laughed at, despite the fact commercial C++ GUI libraries have been the norm. To this day, GTK+ is still an utter failure with respect to commercial application adoption.

Eventually, even Miguel realized that C was not the language for desktop application development as it was hurting GTK+ adoption. Rather than embrace C++, he threw out the baby with the bath water and embraced C# itself for GNOME application development with the Mono project.

The Mono project is an open source implementation of Microsoft's C# language and runtime for Linux and other operating systems. Although one goal of this project is very honourable (allowing custom/vertical/boring applications from Windows-centric shops to be usable under Linux), I think in general Microsoft is making a sucker out of the Mono developers and users, and here's why:

Microsoft was once an innovative, competitive company. That however, was along time ago. They're now a convicted monopoly who still to this day function primary to lock people into their various technologies. I don't want to sound like a typical "Microsoft is evil" parrot but this is what a monopoly does. I can't fault them for it, but let's not be naive. I can spend a blog post alone on Microsoft's various transgressions, but for now I'll simply rat off areas which they really like to maintain their monopoly lock-ins: file servers/smb, office formats, web browsers/ActiveX, web browsers/IE stagnation, media formats/codecs, flash/Silverlight. Heck, I can't even access my company's MS Exchange web interface in Firefox without getting a substandard interface to email. They can't (well, don't want to) even make a website without trying to lock-in you into Internet Explorer on Windows.

Microsoft is not stupid and understands that platforms are really about capturing and holding developer mind share. Java and similar truly multi-platform technologies that they didn't control was viewed as a huge threat to the Windows empire. So Microsoft "embraced and extended" Java-principles, gave it a new name (C#) and injected a boat load of Windows-specific stuff into it. We can debate the finer differences between the languages until the cows come home, but fundamentally, at their core, they're identical languages, except that C# isn't multi-platform and is very Windows-centric. By the way, Adobe's flash/Actionscript is the next threat and target after Java, so look out for a serious assault on that front from Silverlight.

Given this, it's easy to see why Microsoft likes the Mono project. They get to pretend C# is multi-platform ("see, we're not a monopoly!") and friendly towards Linux and open source, but they don't have to devote any of their own resources to it. Furthermore, Mono on Linux will never be a first class citizen (like in Java) and will always be a version or three behind, lacking in proprietary features. To get the "true" C# experience you'll still be sold a Windows system. Microsoft gets to point to Mono and claim that C# is multi-platform, but will then tell you you must run their version on Windows to get the true, modern and full experience. This basically relegates Mono to (using the colloquial term) being Microsoft's bitch.

Although I used to code a lot of Java, I'm not really a Java proponent. But honestly, if the Linux desktop needs a garbage-collected, byte code-interpreted, type safe and object-oriented language, then Java is hard to beat. Decade or two of testing, mature IDEs, plethora of libraries and truly multi-platform (first class citizenship for Linux) and now open source (I hear?) are all features that would be stupid to ignore. But for some reason, Novell decides to chase Microsoft's ever changing specs while having to rebuild everything from the ground up.

Miguel ends off the interview with what I think is a little Stockholm syndrome. He says that most people unfairly demonize Microsoft, ignoring the specific points (like the above) those people make. Heck, he excuses Balmer's public demonization of Linux as the spouting of a sales man, ignoring the fact that this is the CEO of the big ship Microsoft. One simply needs to use non-Microsoft operating systems and applications in a Microsoft-based shop to truly understand the breadth and effect of their monopolistic lock-in.

But alas, I realize that there are other factors here in Novell's decision to fund Mono. Novell is scrambling for money and business opportunities, looking for any edge against Red Hat, even if that means dancing with the monopoly Microsoft. Although you can't fault Novell for doing what they think is in their best business interests, let's not get delusional into thinking Mono is on some level playing field with Microsoft.

Alex, General , , ,

Qt goes LGPL!

February 4th, 2009
In about a month, Nokia, owners of Troll Tech, makers of the Qt widget library will release Qt 4.5 under the LGPL license. In a web centric world desktop application programming may seem unhip and uninteresting but rest assured, this is huge news, especially for desktop app developers and potentially mobile app developers (Nokia's primary intent here is to build a platform, after all).

Qt, for those that don't know is a very nice, well polished, comprehensive graphical application building toolkit. It's a complete C++ toolkit done right: multi-platform, easy to use and well thought out. It shows to the Java/C#/etc crowd that C++ development can be fun again, it just needed a unified, nice and easy to use "standard library" that covers ALL of the things developers want to do, on all platforms. The C++ "Standard Library" only covers the most basic of things, like strings and files, leaving the C++ developer to go hunt down other libraries to fill in that last 90%.

Prior to the LGPL version, you had to use either the GPL version (requiring your software to be also under the GPL, i.e. free) or you had to buy some commercial licenses, that aren't cheap (a few thousand dollars, usually). The LGPL basically lets you have your cake and eat it too: use the free downloadable library to make applications under any license, for free. This will undoubtedly destroy Troll Tech's income, but the mothership (Nokia) views this as a cheap sacrifice, if it gets them developer mindshare.

As a Linux (well really, multi-platform) desktop app developer, this is a godsend.

Unless you were willing to cough up the dough for the expensive commercial Qt licenses, you where left with few choices, each with their own downsides:

GTK+: poor support under Windows, missing lots of mature features, verbose/cumbersome API and worst off all: it's a C library. Now, I know it's cool to hate on C++, especially from people who don't know the language (especially C programmers who've just dipped their toes in the language), but C++ is still the best way to write compiled-to-native code across multiple platforms with full performance. Period. Full stop. GTK+ programming tends to be so tedious, that everyone seems to do their own light C++ wrappers around the core classes, which has to tell you something. Heck, the GNOME desktop people are trying to push Mono (i.e. C# & GTK) as the new solution, because even they admit C & GTK+ is too messy. For the record, even though I like and use the GNOME desktop, the developer side of me hates the GTK+ library API.

GTK- -: a C++ wrapper around GTK+. Good idea, but it's still cumbersome under Windows and dealing with a framework around another framework is frought with issues. It's also not that popular, leading to less community support, application examples, testing, etc. You don't want to commit your large application to a toolkit that isn't supported, well tested, etc.

FLTK: never used it personally, but it seems small (in community and support), similar to GTK- -.

wxWidgets: After getting fed up with GTK+, I moved to wxWidgets. wxWidgets is a decent library, that seems to work for the most part with a few rough edges, nothing that can't be worked around. These rough edges, a few missing features (database support, for example) and slower development progress is all simply a result of it being a fully volunteer effort. It's a great library, and I'd still be using it if Qt wasn't going LGPL.

So to sum up, Qt is awesome. It's multi-platform, well documented, wildly adopted, broad in features and is joy to use. LGPL licensing will boost the quality and quantity of apps on the Linux desktop: by lowering the barrier to entry and by ported applications coming from Windows. Windows application developers will now be enticed with a free toolkit, which they can then later use to quickly bring their applications to Linux or Mac OS X. Finally, this same API can be used on mobile phones, making Nokia's dream of "Qt Everywhere" come true.

Alex, General , , ,

Support Wikipedia