Pinderkent

I read through an article today that shows the struggles Web developers go through to perform basic layouts using CSS. In the article's particular example, it's simply some images and some associated textual content displayed in a grid-like manner, with the amount of text being variable.

In short, it's a practical, real-world data display that should, one would think, be very easily accomplished using CSS. As is often the case when using semantic markup and CSS, what should take only a few minutes balloons out into a battle against unexpected behavior, browser incompatibilities, browser bugs, and so on.

Whatever benefits CSS might have brought are quickly eliminated by the time and effort necessary to get the content displaying even remotely correctly. But we must also consider that the end result becomes nearly unmaintainable. Other Web developers working with the code later on will likely not appreciate or understand the struggles that went into getting everything working in the first place. Making even minor changes might not be possible, or might be extremely time consuming, with much care needed to avoid rendering incorrectly in various browsers.

I'm not suggesting that HTML tables would necessarily be a better solution. I just find it extremely bothersome that such a simple task so quickly becomes such a huge hassle when using CSS, with the end result being quite fragile. This is what we'd expect to see from an immature technology, yet CSS has been in the works for roughly 15 years, and has been implemented by a number of different groups. It's pretty pathetic, really.

Through my work, I get to visit and work with many different businesses and organizations each year. And like anyone involved in business, meetings happen (far too) frequently, and they often include presentations. Although I don't have to give them very often, I do get to sit through them frequently enough. As laptop computers and projectors have become more prevalent, we've seen slideshows and similar presentations become used more often. While major mistakes can be made easily enough when using whiteboards, handouts and other presentation media, the laptop/projector/PowerPoint combination makes mistakes almost certain for some people.

By "mistakes" I don't mean minor stumbles while speaking, momentarily forgetting what to say, and so forth. I'm talking about incidents that can, within a few seconds, ruin the reputation of the presenter and the party or parties they may represent, or perhaps put an end to a valuable deal that has been in the works for some time. Although somewhat rare, they do happen more frequently than they probably should.

Those who have sat through enough presentations will no doubt have seen scenarios where a rogue popup alert window, often from a networked application like and email client or an instant messenging client, inadvertently displays some unsavory or very personal information. Similarly, some malware may open popups with various advertisements that do no reflect well on the presenter. Another major problem is personal and/or inappropriate photographs accidentally being displayed as thumbnails in the file browser while the presenter is starting to open their presentation. And sometimes laptop users have set a sound file to automatically play when their laptop turns on, but forget to turn down the speaker volume before turning their laptop on before the presentation.

Matt Hulett recently gave some tips to help avoid such mistakes. With respect to his first two tips, one good method of achieving that is, as mentioned by one of the commenters, to have a separate account on the laptop solely for presentations. I know some frequent presenters who take that a step further, and have separate accounts for each presentation, to avoid having the presentation for one group inadvertently displayed to another.

Some of those presenters even have a separate laptop they use just for presentations, and another laptop computer they use for work and personal purposes. I know one fellow in particular who uses a very minimalistic installation of Debian on his laptop. He doesn't even bother with installing a desktop environment, instead just using twm. Essentially, he has stripped his presentation laptop down to the bare minimum needed to make his presentations, and by doing so has eliminated many of the possible causes of major incidents. One thing he even told me is that he uses a shell session running in xterm to navigate his filesystem and start his presentations, to help avoid unintentionally revealing unwanted information to his audience.

With some care, preparation and forethought, it's often relatively easy to make a presentation go well. But it's also quite easy to be in a rush and forget something minor, such as closing down a running email client. Soon enough this can balloon out into an angry audience, and possibly even the end of valuable business relationships. A secondary, minimalistic, presentation-only laptop with separate user accounts for each presentation will go a long way towards preventing some of the most common incidents. Adequate preparation usually takes care of the rest. And if all goes well, the presentation will be a success.

At the beginning of this month, I wrote about BeOS, and how far ahead of its time it was. It turns out that a former colleague of mine from many years back had read that article. He contacted me this week and mentioned that the company he works for in Germany still uses BeOS on a small number of systems!

While I'm sure it still has casual hobbyist users, I can't say that I had really expected BeOS to still be used commercially. He said that they had gotten some custom animation software developed for them nearly a decade ago, and the developers recommended BeOS since it was the most suitable OS at the time for such work.

I tried to find out more about the version of BeOS they were using, as well as what hardware they were running it on, but my former colleague wasn't sure. He didn't work directly with the systems, but said he'd try to talk to one of the users to see if they had any idea. I haven't heard back from him yet, however.

As for why they still use such old systems, he said that they work fine, the custom application still allows them to get their work done, and they don't feel any need to upgrade. That is fair enough. It's a pretty common response from small businesses who are still using older hardware and software.

I'm pleased to see that BeOS is still of use to some people, years after it was effectively discontinued. Perhaps as Haiku matures, it will eventually provide my former colleague's company (and any other BeOS users) a way to upgrade their hardware, while still being able to make full use of their custom applications, as well as the BeOS software platform.

There was recently a thread at Hacker News asking why "older developers are afraid" of JavaScript. As an older developer, I don't usually feel fear towards JavaScript. It's more a mix of disappointment, disdain and disbelief.

Furthermore, it's not just "older developers" who see JavaScript for what it truly is. There are many younger developers who know how inherently flawed and broken it is. So maybe instead of "older developer", a more appropriate term to use would be "knowledgeable developer". Anyone who has worked with a variety of programming languages should be able to easily see the many problems associated with JavaScript.

We're all very much aware of the implementation-related issues of JavaScript. Performance is one of the most significant problems. Although there has been much in the way of improvement in this area from Google, Mozilla and Apple, the situation is still not ideal. JavaScript, being embedded within all popular browsers, has been responsible for a variety of security-related problems. Aside from such implementation issues, JavaScript has some pretty serious problems with the language itself.

One reply to the Hacker News topic mentioned earlier gives a good example involving semicolon insertion. Others have pointed out this problem, such as in the JavaScript Style - why it's important and Beware Of JavaScript Semicolon Insertion articles, both of which give similar examples. Another example of the problematic nature of semicolon insertion can be found at Wikipedia.

Developers who have used more mature languages than JavaScript don't have much tolerance for oddities like that. They're dangerous and unexpected. More importantly, it's a further example of how trying to dumb down programming technologies to make them usable by Web developers has failed us yet again. HTML parsers, for instance, have to be unnecessarily complex to handle blatantly incorrect HTML markup. Another example of catering to carelessness and a lack of knowledge is PHP's magic quotes, which thankfully will be removed from PHP 6. And as mentioned earlier, we have JavaScript's semicolon insertion, itself a "feature" that exists basically to allow for, and to even promote, careless development.

JavaScript does unfortunately have its place, but only because it's really the only practical option for client-side browser scripting at this time. Regardless, those who use it should take care. Douglas Crockford has put out some useful articles and tools to help with this. His JavaScript coding conventions article, for instance, provides some good tips. His JSLint tool is useful, as well.

Perhaps someday we'll see a stricter, more mature language widely available for client-side Web browser scripting. Although this may not appeal to lazy Web developers, that would be a good thing. Care should always be taken when writing network-accessible software, regardless of whether it's a server of some sort, or client-side scripting. Having a strict and unambiguous language will help prevent many of the problems that JavaScript exhibits.

I read an article today suggesting that functional programming hasn't caught on widely because most developers today haven't been convinced that it is necessary. I'm not sure that's completely correct. Those who are truly "in the know" will have been at least investigating functional programming for some time now. The rest can merely be considered stragglers, who don't yet realize that they currently do have, or will have, a need for functional programming in the near future.

Although it was clear several years ago, we can now say with almost complete certainty now that we will soon be seeing consumer-grade PCs with 32 or more logical processors. Intel's Core i7 has recently brought us part of the way there. At the higher end, Sun's UltraSPARC T2, for instance, offers 8 cores for 64 threads of execution. The trend is obviously towards processors offering multiple cores, each of which may offer multiple threads of execution. And today's mainstream programming languages just don't take advantage of such environments too well.

Some industries have dealt with these issues already. That's why Erlang has been around for over 20 years now. Anyone who has worked on telecom systems or even just worked with Erlang knows the benefits that its concurrency model brings. These days, with the advent of consumer-grade multicore CPUs, such benefits are applicable even when using the low-end systems. In fact, to make the most of today's and tomorrow's CPUs, we will need to develop our software to be more concurrent.

To do this effectively, we likely will need to make use of at least some of the techniques pioneered by the functional programming community. Immutability is perhaps the most important and useful technique when writing concurrent software. Strong, static typing as offered by languages like Haskell and Standard ML is also very useful. Well-integrated support for writing concurrent applications, such as that offered by Erlang, is another major benefit.

However, we likely won't see the development community at large using Haskell, ML or Erlang any time soon. What we'll probably see first is a move towards hybrid or multi-paradigm languages. Clojure and Scala are two of the most familiar at this point. Both target the Java platform, which makes them appealing to existing Java users.

Somewhat surprisingly, Microsoft may very well be the ones who bring functional programming to the mainstream, through their F# language that is to be included as part of Visual Studio 2010. Functional programming will quickly be made easily accessible to a large number of application developers, at a critical time when many will likely be looking for ways to better leverage systems with many logical processors.

Unfortunately, Sun seems content with spinning their wheels with Java and worse, JavaFX Script. Given Sun's long history providing back-end hardware and software, especially hardware that offers many threads of execution, it's sort of surprising that they aren't giving more support to languages like Clojure and Scala. These are the sort of languages that give current JVM users the boost they need to remain or even become competitive.

We're starting to see a variety of factors come together now that will make functional programming techniques far more useful to the mainstream software developer. Multicore CPUs are now readily available, including in low-end consumer-grade desktops and laptops. This will start increasing the demand for efficient, scalable and practical methods of making use of these resources. A variety of open source functional languages, like Haskell, Erlang, Scala and Clojure, have shown that they're willing to help meet these demands. Microsoft is going with F#. The need to use functional techniques combined with readily-available language implementations will allow for this flourishing to occur.