Archive for the ‘Programming’ Category

The Go Programming Language

Wednesday, November 11th, 2009

The Go Programming Language.

I’m glad to see this; there has been too little innovation on the system programming language front. I do like C, though I’ve become more conscious of its faults since I learned it (*mumble*) years ago.

I’m a little disappointed that Google didn’t throw its weight behind the other major contender in this category, The D Programming Language. They have to have considered it; I wonder if their decision not to use it involved technical considerations, licensing considerations, or a little of both.

The write-up on TechCrunch is light on technical details, and the comments are hilariously clueless: paranoiacs spluttering that Google is taking over the world, people who’ve never written a line of code in their lives declaring it an instant failure, and Johnny One-Note programmers insisting that this will never take the place of PHP, or C#, or JavaScript, or whatever their One True Language is, shrieking with terror at the thought of learning something new.

For myself, I like what I’ve read so far about Go. It looks not much more complex than C (and waaaay less complex than C++), with a more modern, more streamlined feel. I like the idea of trying to head off the formatting wars by including a canonical pretty-printer in the core tool set (though I wish they had standardized on spaces instead of tabs for indentation). Requiring braces around blocks is good: it heads off a common error in C/C++ coding, and there shouldn’t be any ‘friction’ in changing a one-line block into a multi-line block. I liked structural equivalence of types when I first encountered it in Modula-3, and the Go concept of interfaces is nicely reminiscent of that. I don’t miss the whole object oriented feature list (encapsulation, polymorphism, inheritance, and dynamic binding), so long as modularity and information hiding are supported. And garbage collection is a huge win, so long as it can be done efficiently and without causing the program to stutter.

All in all, very interesting, and a worthy challenger to D as a 21st-century systems programming language.

Go vs Go!

Wednesday, November 11th, 2009

Go! is a concurrent programming language, first publicly documented by Keith Clark and Francis McCabe in 2003 [1]. It is oriented to the needs of programming secure, production quality, agent based applications. It is multi-threaded, strongly typed and higher order (in the functional programming sense).

Google’s new ‘Go’ programming language, the very day it is announced, is already embroiled in a naming controversy.

Personally, I think they should contact the makers of LabVIEW, and see if they can acquire the naming rights for the G programming language.

Posted via web from Kevination

The One Where I Say Something Nice About .NET

Friday, October 9th, 2009

I’m working my way through  Pro ASP.NET MVC Framework, by Steven Sanderson, published by Apress. So far, I like it, for values of ‘it’ of both the book and the framework.

The book — well, the reviews on Amazon were glowing, and they’re basically right: clear prose style, ideas well expressed, and enough critique of other Microsoft technologies that you can tell it’s not a Microsoft Press title.

The framework … is interesting. It mostly abandons the ASP.NET model of server-side controls, postbacks, and viewstate in favor of plain HTML and CSS. (Though there are still advantages to using their HTML helper functions rather than coding up raw HTML yourself.) For pity’s sake, they even make jQuery available for your AJAX hacking pleasure.

What has always bothered me about “classic” ASP.NET was that it seemed to be an attempt to transplant the VB/WebForms style of development — drag-and-drop controls, a low-level event loop — onto the web. It’s a layer of abstraction over the web in an attempt to hide that fact that it is the web.

And it shows in terms of performance. Outside of low-latency intranets, the underlying architecture doesn’t support the chatty postback/viewstate implementation needed to emulate a desktop GUI event loop.

ASP.NET MVC, in contrast, feels like a web-native architecture. It’s designed around the strengths and limitations of HTTP, rather than fighting against it.

On top of that, it encourages the strong separation of concerns implied by ‘MVC’; it nudges the developer towards unit testing and test-driven development; and with the source code placed under an OSI-approved license, it represents a step by Microsoft into the world of Open Source.

All in all, I think ASP.NET MVC is quite cool.

RSSCloud Vs. PubSubHubbub: Why The Fat Pings Win

Thursday, September 10th, 2009

I’d been hearing the terms ‘PubSubHubbub’ (silly name) and ‘rssCloud’ a lot lately, and decided I ought to figure out what the heck these people are talking about. Just in time, along comes Josh Fraser with a guest post on TechCrunch, RSSCloud Vs. PubSubHubbub: Why The Fat Pings Win.

Both [PubSubHubbub] and rssCloud address a fundamental flaw in the way web applications work today. Currently, getting updates on the web requires constant polling. Subscribers are forced to act like nagging children asking, “Are we there yet?” Subscribers must constantly ping the publisher to ask if there are new updates even if the answer is “no” 99% of the time. This is terribly inefficient, wastes resources, and makes it incredibly hard to find new content in as soon as it appears. Both protocols flip the current model on its head so that updates are event driven rather than request driven. By that I mean that both protocols eliminate the need for polling by essentially telling subscribers, “Don’t ask us if there’s anything new. We’ll tell you.”

While Fraser favors PubSubHubbub, he apparently agrees that the name just doesn’t work, and refers to it throughout his piece as ‘PuSH’. If fate is kind, that name will win out. (Or else it will get submitted to IETF, and given a nondescript acronym, a la Jabber’s rehabilitation as the more businesslike XMPP.)

MVC Done Right?

Friday, October 17th, 2008

Model-View-Controller (MVC) is a design style that dates back (as so much does) to the pioneering work of the Xerox PARC facility. The idea is that applications should be separated into:

  • Model: the data that the application manipulates, and the fundamental operations it performs on that data
  • View: How the application looks to the user.
  • Controller: How user, view, and model interact.

(Yes, yes, I’m sure anyone who cares to can pick apart my definitions. Don’t care.)

The idea is, views change all the time (today it’s radio buttons, tomorrow it’s drop-downs), controllers change moderately (add a confirmation step, tighten up the authentication), and models hardly change at all (an accounting program isn’t going to change into an MMORPG). So isolate the fast-changing bits from the slow-changing ones. And also allow different specialties — database hackers, usability analysts, graphical designers — to put apply themselves to their own field exclusively.

How do you do that in web applications? The received wisdom of the day is:

  • Model: database + ORM (e.g., Hibernate, ActiveRecord)
  • View: templating language
  • Controller: application framework (Struts, Spring, Rails, etc.)

In other words, do it all on the server, all in one language (which, of course, fits all purposes, because it is the One True Language). Maintain separation of concerns with iron discipline and wishful thinking.

My own view:

  • Model: database + RESTful web service, delivering information in JSON
  • View: Static (X)HTML/CSS
  • Controller: Javascript/AJAX

The controller code can be implemented in any server-side language: Java, C#, Ruby, Python, Erlang, whatever; it just needs to be able to talk to the database and send JSON over the wire. The view can be created in an HTML/CSS environment like Dreamweaver, with no worries about whether it’s compatible with the developer toolset. And the controller logic… Well, I’ve been playing with jQuery lately, and it may shock some folks to learn that coding client-side Javascript with a good compatibility layer library is actually fun.

Dividing tasks by physical location and implementation language creates a strict separation of concerns. Server-side code does not generate HTML. Controller code does not do SQL queries. View markup contains no executable code at all: there is no template language. There is zero possibility of the parts bleeding together.

Why wouldn’t this work? Am I missing something?

ECMAscript4 is Dead; Long Live 3.1

Wednesday, August 20th, 2008

Okay, I’m a week late hearing the news, but it seems the EcmaScript (aka JavaScript, JScript, etc.) committee has cut its losses, and settled on a less ambitious next version of the standard, ECMAScript Harmony. Packages, namespaces, and early binding are gone. Which kind of leaves Adobe with a problem, as they had started implementing a lot of the ES4 features in ActionScript for Flash/Flex.

Namespaces are, in other languages, an important means of controlling complexity by partitioning the code into well-defined pieces. Maybe it’s not so essential in Jav(ahem) EcmaScript, especially in web browsers, which account for 99% of the current use cases. I think dropping them reduces the chance that EcmaScript will break out into other domains, and I think that’s unfortunate. But I’ll admit, the technical trade-offs involved are beyond my current understanding.

I’d very much like to know how this is going to affect the Tamarin project, though.

One More Data Point

Wednesday, December 12th, 2007

Safari Books Online is a service by technical publisher O’Reilly and Associates, that allows subscribers to their service to access their books, and those of several other publishers, online. (Highly recommended, BTW.)

Anyway, their front page lists the most popular books on their service. For as long as I can remember, the top book was David Flanagan’s Java in a Nutshell; but today, it has been displaced by JavaScript, the Definitive Guide (also by Flanagan, as it happens).

It’s notable mainly in support of Steve Yegge’s proposition that JavaScript is the Next Big Language. It is certainly popping up everywhere, and it is, for now, the only Apple-approved method of developing for the iPhone.

UPDATE: Okay, now both of Flanagan’s books have been displaced by a C# book. Please forget I said anything.  :)

RADAR: RESTful Application, Dumb-Ass Recipient

Thursday, November 29th, 2007

PragDave: The RADAR Architecture: RESTful Application, Dumb-Ass Recipient

I’d been thinking along similar lines for a new project (which is expected to be a sort of testbed for a web services architecture). It’s a web service meant for use by third parties.

I decided, after thrashing around a bit, that machines that reside outside our firewall should be treated like end users: the interface presented is presentation logic. The fact that it is a web service is immaterial; it is distinct from the bare RESTful API to our business rules that we present to internal applications.

The application layer is what makes a process “presentable” to outsiders. It may mean consolidating several actions that are internally seen as distinct into a single operation; or adding authentication and data validation; or conforming to externally-imposed specifications (e.g., presenting an external SOAP interface); or information hiding to allow for future changes to your model and business rules.

If Programming Languages Could Speak

Friday, October 26th, 2007

I love obscure humor. Being the only person in the room to get a joke makes me feel so special.

You pretty much have to be a programmer — and not a Johnny One-Language, but a Real Programmer — to get the humor in this post. If you aren’t, then take my word for it, it’s damn funny. (Be sure to read the comment about Python.)

JavaScript Rising

Wednesday, July 11th, 2007

In this post I wondered why no one (that I knew of) had proposed using JavaScript as a server-side language, and developed tools to support it. Well, they say it steam-engines when it comes steam-engine time. A lot of other people had the same idea; and unlike me, some of them did more than just blog about it.

Googler and blogger Steve Yegge (whose keynote at OSCON I am going to miss, dammit) made a splash by porting Rails to JavaScript — specifically, the Rhino JavaScript-on-Java interpreter that is bundled with Java SE 6. He calls it “Rhino on Rails”, the clever bastard.

In an effort to increase developer productivity at Google, Steve tried to convince the company to adopt Rails (and consequently Ruby) as a programming language. When that fell on deaf ears (Google really does not want to increase the number of languages that must be supported by their infrastructure), Steve decided to do what any other frustrated programmer would do: he ported Rails to JavaScript. Line by line. In 6 months. Working 2000 hours. Steve is a coding stud.

And he is not alone: witness Project Phobos.

Phobos is a lightweight, scripting-friendly, web application environment running on the Java platform.

It comes with a set of plugins for the NetBeans IDE that cover the complete development process. These include a fully-featured debugger; wizards to help you get started faster; a palette of Ajax widgets that can be dropped on a page, thanks to jMaki; and the ability to generate a standard web application for deployment on any servlet container or Java EE application server.

Currently, the primary language supported by Phobos is JavaScript. By leveraging JavaScript on the server, Phobos allows developers to use the same language on the client and server tier of a web application, eliminating the impedance mismatch that characterizes other approaches to Ajax.

Digging farther back in Steve Yegge’s archive, one finds he has been thinking along these lines for some time:

JavaScript is probably the most important language in the world today. Funny, huh? You’d think it would be Java or C++ or something. But I think it just might be JavaScript.

For one thing, despite JavaScript’s inevitable quirks and flaws and warts and hairy boogers and severe body odor, it possesses that magical property that you can get stuff done really fast with it…

See, JavaScript has a captive audience. It’s one of those languages you just have to know, or you get to miss out on Web programming, and in case you hadn’t noticed, thick clients are like Big Hair these days. Most non-technical people I know pretty much live in their browsers, and they only emerge periodically to stare in puzzlement at iTunes or a game or something, and wonder why isn’t it in the browser, because everything else useful seems to be. It’s where the whole world is. To non-technical people, of course. Which is, like, practically everyone.

What other language is supported, in a reasonably cross-platform manner, on the Windows, MacOS X, and Linux native APIs, the Java virtual machine, the .Net virtual machine, the Parrot virtual machine, the Flash runtime, the Silverlight runtime, and 99% of the web browsers in the world? (And, oh yeah, what’s that new thingamajig from Apple? I vaguely remember reading something about it. Can’t seem to recall the name…) In other words, JavaScript not only runs on every platform of interest; it is the only language that runs on every platform. [1]

JavaScript isn’t winning the fight to be the Next Big Language; it’s already won.

[1] Actually, I don’t know if it runs natively on PlayStation3 and XBox 360. But given the little-bitty interpreter and the great big storage media, the games could ship with their own JS runtime and not miss the space.