A different application paradigm is needed

Good stuff here, railing against browser-based applications:

Web development is popular because it's fast, versatile, and relatively inexpensive -- and it's certainly easy to find developers. But that doesn't mean the alternatives don't have advantages of their own, and in some cases the Web's weaknesses might outweigh its strengths. In the interest of healthy debate, here are five reasons why concentrating your development efforts on browser-based apps might not be the best idea.

1. It's client-server all over again.
Web applications encourage a thin-client approach: the client handles UI rendering and user input, while the real processing happens on servers. What sense does that make when any modern laptop packs enough CPU and GPU power to put yesterday's Cray supercomputer to shame?

Concentrating computing power in the datacenter is fine if you're a Google or a Microsoft, but that approach puts a lot of pressure on smaller players. Scaling small server farms to meet demand can be a real challenge -- just ask Twitter.

Furthermore, security vulnerabilities abound in networked applications, and the complexity of the browser itself seemingly makes bugs inevitable. Why saddle your apps with that much baggage?

2. Web UIs are a mess.
The Web's stateless, mainly forms-based UI approach is reliable, but it's not necessarily the right model for every application. Why sacrifice the full range of real-time interactivity offered by traditional, OS-based apps? Technologies such as AJAX only simulate in the browser what systems programming could do already.

And while systems programmers are accustomed to building apps with consistent UI toolkits such as the Windows APIs, Apple's Cocoa, or Nokia's Qt, building a Web UI is too often an exercise in reinventing the wheel. Buttons, controls, and widgets vary from app to app. Sometimes the menus are along the top, other times they're off to the side. Sometimes they pop down when you roll over them, and sometimes you have to click. That inconsistency hurts your development budget, but it hurts usability more.

3. Browser technologies are too limiting.
Why give up the full range of languages, tools, and methodologies that systems programming has to offer? JavaScript has evolved into a respectable general-purpose language, but it can hardly be expected to be all things to all people. User interface code written in such languages as C++, Objective C, or Python can often be both more efficient and more maintainable than code written for the Web paradigm.

What's more, HTML and CSS are clearly deficient when it comes to rich interactivity. Witness the proliferation of multimedia plug-ins such as Flash, QuickTime, and Silverlight. Relying on these outside dependencies increases the complexity and support cost of your applications. Why bother? These tricks wouldn't be necessary if you weren't trying to shoehorn interactivity into the browser instead of sticking to the desktop.

4. The big vendors call the shots.
Recently, Sun Microsystems CEO Jonathan Schwartz described the browser as "hostile territory" for independent developers. It's a world divided between giants, he said, with Microsoft's Internet Explorer on one side and Google's stake in Chrome and Firefox on the other.

Schwartz's statements may be self-serving, but he does have a point. Increasingly, the evolution of Web standards is being driven by major browser vendors -- new features are implemented first and standardized later. Independent developers have little genuine input into the future direction of the Web. And that's to say nothing of the ongoing bickering between the various vendors. Does it make sense to rely on client-side software that's such a moving target?

5. Should every employee have a browser?
At one point, a computer on an employee's desk was for work. [Ed: Oh, the irony!] Today, every Web-enabled PC is a gateway to shopping, TV and movies, games, music, online chat, and countless other diversions -- up to and including more illicit activities, including porn and copyright infringement -- to say nothing of making them vulnerable to phishing and malware attacks.

I've been saying this since the first cunt came along with a browser-based app.

Can we please go back to green screen applications now?

So much for all the new languages

Hah! All you Ajax and PHP and Perl and Ruby kiddies can kiss my arse:

C overwhelmingly proved the most popular programming language for thousands of new open-source projects in 2008, according to license tracker Black Duck Software.

The company, which monitors 180,000 projects on nearly 4,000 sites, said almost half - 47 per cent - of new projects last year used C. Black Duck said 17,000 new open-source projects were created in total. Next in popularity after C came Java, with 28 per cent.

In scripting, JavaScript came top with 20 per cent, followed by Perl on 18 per cent.

PHP attracted just 11 per cent and Ruby six per cent. The numbers are a surprise as open-source PHP has proved popular as a web-site development language, while Ruby's been a hot topic for many.

If you want to do a man's work, you have to use a man's programming language!

Bad programming

SANS has just released a list of the top 25 programming errors:

Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.

And not just there, take a look at most bloody bespoke development shops. But it's worse than that, as Alex Wolfe so pithily says:

It really makes you wonder where we are today, when one sees that two of the top problems on the SANS list are improper input validation and improper access control (authorization). (I'm guessing there's also not much thought given to writing error catches. Probably the SQA or test folks have to tell today's youthful coders to add that stuff in afterwards.) Other goodies on the list include "hard-coded password" and improper initialization.

I guess you can't make this stuff up, but if it's as common as SANS says, I don't know if there's any hope at all.

I concur. But I'd like to point out that while error handling and input validation aren't sexy to code, users don't look at either one when selecting software. So what did you think was going to happen?

A new generation of programmers

There's a brave new world out there: Web 2.0, social networks, open source, Agile Programming, grid computing, you name the wanky buzzword and someone has attached a poncy bit of cocksnaffling onto it.

It all sounds so good, wholesome and new-agey. There's only one problem with it all: the people writing all this software are, by and large, inept, bungling fucktards with all the common sense of a pot noodle on crack. It seems that wherever I go in the course of my day job, I'm surrounded by bearded, long-haired, juice-drinking, T-shirt-wearing, vegan cock-ends who look like uber-geeks, but actually have no fucking grasp of which end of a computer is up.

The most basic concepts seem to have passed them by in the quest for the latest "big idea". They're all so busy masturbating over which way Linus is going to take kernel 2.8 that they forget that there's a here and now problem which is: "because you don't have a fucking clue what you're doing, you cocksnaffling dweeb turd, your programs are a fucking disgrace and nothing works because you didn't think there was any issue beyond getting the fucking thing to compile without errors."

The worst thing of it all (and I see this every fucking day) is that programmers make Death Star-sized clusterfucks out of their code, yet when they fix their own fuckups, they get venerated as fucking heroes. Back in the day when I used to cut code, my balls were on the line every time something when into production. If it didn't work, and work well, my manager would be kicking my arse until it was sorted. It seems that along with everything else in this caring, sharing age, that programmers are now being worshipped on those rare occasions when they manage to find their own arses with both hands.

It gets better for these indolent cock-suckers, though, because the average application now consists of so many inter-related components that they have six months of blaming everyone else for any problems before they get called to account. (What's all that about anyway? Why the fuck do you need a software stack a mile high and a 16-way server to keep track of your fucking CD collection?)

It's always down to everyone else to prove the sainted bastards are guilty of the problem (and the skanky fucks always are!)

Fucking C# programmers. I shit the cunts. Java fuckwits, too.