Sunday, May 24, 2009

No need for bare metal speed?

Yesterday I saw a comment in a performance thread where someone stated that we don't need the "bare metal" speed we get with languages like C, C++, and the D programming language. I personally disagree. How many applications do you use that aren't written in some variation of C or C++? Probably not a lot. Why? Well, wouldn't you want the best possible performance when you're compressing files or working with large images?

There are two factors with performance: actual computational speed (processor-dependent) and resource usage. This person may have been focused on the first and is accurate to a degree, however, would you want to use a spreadsheet written in Python? Perhaps a browser written in Ruby? I'm guessing the answer is no, you don't. I'm sure there are power users of spreadsheets that already complain about performance, so why use a slower language? As for browsers, how many of you already complain that some sites are too slow? Imagine if your browser slowed them down even more? Personally, I'd rather have the software take full advantage of the CPU to make the experience as seamless as possible.

As for the second factor, resource usage, if you've followed several of my recent posts, you'll know exactly what I'm talking about. When you can reduce the amount of memory you use by a factor of 10, that's a very good thing. This is, I think, the more important aspect of those three languages vs. many others. Imagine if your office software used more memory...let's say 3 times more memory. On my current linux system, OpenOffice.org currently take up about 20MB of memory with a small document open. Multiply by three, now that's 60MB. Granted, thats only a small document. Imagine if you're talking MS Office with Outlook open plus several larger documents (50 pages). That's going to put a nice hurt on your memory usage.

Now, so far I have written this from the perspective of normal user applications, not specialized applications. Would you want to have a firewall programmed in Perl? Granted, you could probably do some cool things with it, but it's not exactly the most efficient language in the world. How about embedded systems in Java? Here's to hoping you can afford enough memory as some of these systems are very limited. Could you imagine doing something truly intense, like weather forcasting, in Ruby?

All in all, I think that guy was very wrong. We do need languages that are very efficient. Some things really do need as much performance as you can get out of them. If not, they won't be able to do their job as fast as needed and people are going to not want them. Granted, they may not be the most efficient for programming, but I think that's something that can be worked on as we get better libraries. For example, D has many built-in features that are very powerful and can reduce the amount of code you write.

Of course, this is coming from the person who will most likely be writing more code in D on a per-method/function basis as I'm trying to get into good habits using the language, like unit tests and design by contract, the latter of which I'm not doing so well with.

Labels: , , , , , , ,

Monday, May 04, 2009

Is Drizzle the Future?

I'll keep this short: are applications like Drizzle the future? I don't mean databases. I mean, instead of developing an entire app, you create a "kernel" of sorts where you can plug in various pieces of functionality to get exactly what you want. That's essentially what Drizzle has become. You can plug in a number of different pieces of functionality into it to get just the right DBMS you want. Firefox is similar to this in that it has it's extensive plugin system. There are others as well.

So, perhaps we should start thinking about creating software that serves a purpose, but can be easily extended to get just the right functionality. And, if done right, be compatible with other instances of the app or clients. This is a key as remember, Drizzle uses the MySQL protocol, so any client that can connect to MySQL can connect to Drizzle. Makes porting from one to the other easier.

Labels: , ,

Language Toolkits

I think instead of learning a language or a technology, you should learn a toolkit of languages. What I mean is this: different languages are good at different things, therefore by limiting yourself to being, for example, a Java programmer, you're limiting yourself to only one way of doing things. Instead, look at the various things you may do and learn a language in each domain. Granted, some may cross domains, but the point is that different languages are better at solving problems.

For example, Perl is great for creating one-off scripts, prototyping, creating small apps where speed is less importance than making something that can be easily created, tweaked, and ran. On the other hand, D is good for things that need more speed and be friendlier on resources. Erlang and JavaScript have their own niches where they work well.

I think at a minimum, every programmer needs to learn languages that fulfill the following tasks:
  • Application Development (C, C++, D, Java)
  • Scripting/Prototyping (Perl, Python, Ruby)
For me, since I do web development and want to do more with distributed programming, I have two more types of tasks I need to know languages for. Others may have other types of tasks they need to do. The two I mentioned above I think are the most important as many applications do need the speed of a good application development language while scripting languages are absolutely fantastic at the things they do.

Food for thought.

Labels: , , , , , , ,