Lightweight Languages Blog

Automator: More Than Meets the Eye

Mike Reilly's recent conversation with Sal Soghoian, product manager for automated technologies at Apple, really is an eye-opener if, like me, you've underestimated Apple's Automator Technology. Automator is a technology for building workflows out of actions by visually wiring together a sequence of those actions. As such, it's an end-user app, a visual programming tool for novices. But one of the common misconceptions about Automator, even among developers, is that actions are just wrappers for Applescript. Not so. As it turns out, you can build Automator actions from just about any language, which gives them enormous flexibility and untility for developers.

Bray Talks Tech

Tim Bray is truly one of the guys that just keeps the Internet humming along. He's the co-author of the XML 1.0 spec, and co-chairs the IETF AtomPub Working Group. His main job these days, however, is to evangelize developer technologies inside Sun, and to get the word out to developers about technologies being developed by Sun. He describes himself as a "two-way evangelist." John Dorsey had a talk with him at RailsConf2007.

Picking an AJAX Framework

The AJAX framework space is really starting to look like a robust place to do development these days. The number of choices is proliferating, and the level of maturity and polish in these frameworks is remarkable, and improving by the day. But not all frameworks are created equal, of course. How to choose? You need to consider how well the framework fits the style and structure of your development team. Critically, you need to see how well the widgets in the framework map to the desired feature set in your app. And then you need to know how easy those widgets are to customize. Andrew Turner and Chao Wang make it all a bit easier for you by revealing their decision-making process when choosing a framework for their latest project in "AJAX: Selecting the Framework that Fits."

Getting Started in LSL

This week, we continue our focus on the Second Life virtual environment. As a programmer, what do you need to know? First, and possibly most important, is that nearly everything you see and touch in SL was created not by Linden Labs, Second Life's creator, but by user-programmers within the virtual world. With the Linden Scripting Language, and Second Life's built-in IDE, you can create fabulous objects and (potentially) get paid for them. Here's how.

Scripting a Brave New World?

Unless your cave is particularly dark and deep, you've no doubt heard about Second Life, the virtual world where players own land, gather together with like-minded avatars, and run businesses (sometimes even successfully, though that's not the norm yet). Is it a bright, shiny, brand-new world with huge potential, or a flash in the pan? At Dr. Dobb's, we're betting on the former, which is why we've just announced our Dr. Dobb's Life 2.0 project. This is a world where code creates value, so it's a natural place for good programmers to shine. To help you do this, we're committed to bringing you the tools you need to be successful in this virtual universe. For starters, check out "Using the Linden Scripting Language."

Future-Proof Mapping

Maps are on everyone's web site these days. Google, Yahoo and Microsoft have made it pretty easy. But can you count on these services working as you expect well into the future? If you need to switch from one map provider to another, how easy will that be? Lionel Laské creates an API that insulates you from changes like these, making it an easy matter to switch from one provider to another without extensive code changes. Read all about it in "MyMap: A Portable API for Maps."

Delivering the Goods

AJAX and other Web 2.0 technologies continue to have explosive growth. Increasingly, the pressure is on to deliver fast, lightweight and secure apps with the new technology. But developers face a number of hurdles. As so often happens in the software world, this is a case of an initial technology being used for something it was never designed for. HTTP was never meant to do what we're now asking of it. So there are performance issues. There are also security risks. In "The AJAX Application Delivery Challenge," Lori MacVittie lays out the problems facing Web 2.0.

Trust Me

One of the reasons I love small, lightweight scripting languages is the way they often are used: as the glue to hold together a loose confederation of cooperating (or occasionally competing) technologies. I've always found it strangely comforting—sort of an algorithmic "can't we all just get along" plea. So it's also fitting that many of these languages have been instrumental in creating the latest crop of Web endeavors, which themselves are highly dependent on trusted interactions, not only between software components, but between people. In his article "Web 2.0 and the Engineering of Trust," Michael Swaine explores the issue of trust, one crucial component of Web 2.0 businesses.

A Common Framework

The Rich Internet Application (RIA) world these days is a soup of technologies looking for a common ingredient. Consider all the varied and often overlapping technologies for creating web app functionality: JavaScript, AJAX, Java, XML, HTML, and Flash all either compete or cooperate in building today's crop of web apps. Will we someday have a uniform, well-defined way of building components for this new platform? Jim Grandy of Laszlo Systems thinks so.

]]> Laszlo Systems OpenLaszlo RIA platform just might provide a part of that brave new landscape. OpenLaszlo is essentially an app server (a servlet to be exact) that reads in an XML file (in the syntax of Laszlo's LZX language) and generates a flash-based app to send to the client. Future plans for OpenLaszlo also include the ability to generate DHTML instead of Flash; clearly the Laszlo people see which way the wind is blowing. The LZX syntax is clear and concise, and generates tremendous levels of functionality in a very few lines of code. If you haven't played with it, you can find a very nice 10-minute introductory tutorial at the OpenLaszlo site. It's a really interesting stab at solving the problem of standardizing web application APIs.

Revenge of the Rubyist

Zed Shaw (author of the well-know Ruby tools Mongrel, liteweight web server and the Rfuzz fuzzifying HTTP client used in Web testing): One thing I'm currently working on is called Utu. It's not a Ruby project. It's a networking protocol.

]]> "Utu" is a Maori word for a philosophical system of karma revenge. There was a New Zealander, an actor, who ordered a book from Amazon. They took four days to send it to him instead of two, so he went and did research and found prior art that might invalidate the Amazon one-click patent. Did this all in week, all by himself. PhD.'s, tons of people were trying to find this, but this actor in New Zealand finds it. He gets people to donate $3,000 so he can file the invalidation claim. It grows legs, might actually invalidate one-click. He says in an article I read, "I got real angry, decided there needed to be a little bit of utu ..."

The Utu protocol is encrypted, and as people communicate, they can apply cryptographic hate as a hash cache. The server will make you do this hash cache calculation before you talk to anyone else. So if you don't like someone, or you are getting spam, you can do an implicit "sender pays" system. Cryptographic hate is a natural throttle, a social network aspect.

I've been a programmer and IT manager for ten or twelve years. For the past year I've been working on Mongrel and consulting in Ruby. I have a degree in MIS, and am pretty much self-taught as a programmer. MIS was the only track I found that would let me study people, business, and economics in computers. The programming stuff I had no problem with. I wanted to learn about human interaction in this environment.

My overall interest is in how technology changes society and how people do things. Some people say you can't find an engineering solution to a social problem. You know what? Society is totally different Before Car and After Car, or Before Planes and After Planes.

Technology is always changing society, the way humans operate. There's a connection between the introduction of mass transportation and the incidence of obesity.

Computers are just such a new technology. I was born with computers, using them and programming them since I was twelve. I see how society has changed. Cars, planes, computers ... at first it's fascinating to people, then it becomes second nature, "We've always had highways." No, you haven't always had highways!

Computers change the way people think. There are kids who have no concept of life without computers, text messaging, email and chat. How does that change the way they think about things? They understand the Internet, the security problems, in a way older people don't really get. But they don't know why, or what was beforehand.

I started writing games in Basic and kept up. When things went to C++, I was doing that. Windowing systems, I was doing that. I've seen this progression, businesses coming and going. There are a lot of guys my same age here who started at web apps. They have no understanding of why certain things are the way they are.

Computer science is a unique discipline in that it has no concept of history. You talk to computer scientists, and whatever they learned, that's the way the universe is.

For me, computing is a way to articulate my ideas and change how people interact. Most of my projects are oriented around making things fun for others, but also kind of weird. What happens if I introduce a chat system where you can hate on other people? Will the whole network shut down because everyone hates each other? Will you be able to go in and say, "Hey, if you like these guys, you also like those guys, too, and if you hate this guy, you might like that guy"?

You'll build reputations. "Don't even let people with an average hate of 25 talk to me." This is something you can't do in current Internet communication. You just have to accept everything and then reject based on Bayesian filters.

I'm also really interested in the psychology of programmers and those strange beliefs they have. Beliefs which they don't understand where they came from. There were folks like that in business school, who had never read Adam Smith. Where do these ideas of capitalist economics come from. They don't really get it. They don't understand counter movements like Marx and socialism. For them, it's just how you make cash. There's no interest in why things are as they are.

Computer scientists, it's the same deal. There are just things they believe. Most computer programmers seem to break things down into Boolean logic. It's either THIS or THAT. There's always US vs. THEM, Windows vs. Linux, Vi vs. Emacs. They're famous for this, but they are scientists, they're supposed to be logical, but there are religions. My programming language vs. that programming language. GOOD or BAD, BETTER or WORSE, TRUE or FALSE.

They don't even know there are alternate logic systems that have "True", "False" and "I don't know". What if we just make logic fuzzy? They know nothing about statistics. It's like they're on another planet. No other human being thinks like a programmer.

My theory is that this is from working with code all day. The person they talk to most of the time, eight hours a day, is this computer that only understands Boolean logic. That influences their thought, how they think about problems in the world.

When quantum computers become viable, when you finally see the Altair of quantum computing come out, I think programmers now aren't going to be able to hack it. It's going to be new people who roll into it. They can do the math, but quantum computing is more about statistics, more about a lot of things that programmers today have no clue about.

Railing against Rails

Ben Bleything (Portland, Oregon): This is my first RubyConf. I've been a Ruby programmer for about a year and a half.

]]> I got started as a serious Ruby programmer doing Rails. A friend introduced me to Ruby two or three years ago. It always looked really cool, but I didn't have time. I was writing Perl for my job. Then Rails came out and everyone said it looked really cool, so I took it as an excuse to look at Ruby.

I was one of the first in Portland to adopt Rails, but that's not saying much, because almost all of us adopted it at the same time and got working on it. I started as an independent consultant with a prepress company that was building an application in Rails and needed someone more expert than their programmers to help out.

I'm not good at marketing my services, so when a fulltime job in Rails opened up, I jumped at it. Clients come to us who need a specialised content management website.

Over time, I've wanted to do less Rails and more Ruby. RubyConf is a good way to get exposed to what's going on beyond Rails, and to be exposed to programmers who are doing stuff that isn't Rails.

I really like web development. When I build an application, I can do it in a browser faster than I can do it in GUI code. But web application programming is not what I want to spend my life doing. Writing applications to support system administration is for me the ideal thing. There's a lot of interesting glue code you have to write to bridge between the content-based model that most Web development is and the system-level things you need to do. It's fascinating to me! I've written Harmonize, a Ruby wrapper around the Mac Cocoa Sync Services.

Most of the serious programmers I know who have started out writing Ruby on Rails get to the point I'm at, where the want to start writing Ruby instead of Rails.

Thomas Werner (San Diego): Ruby is a very seductive language. Coming at it from Rails, from a PHP background, or even from Java. You've seen Rails on the Web, you say, "This might be a fast, agile way to develop applications." So you start using it.

At first you're not interested in Ruby so much as how Rails uses Ruby. But once you talk to people who have been using Ruby, you start writing more advanced controller code, putting more Ruby code into your models, you realize how great a language Ruby itself is, and how easy it is to write really interesting libraries. You start writing libraries. I wrote Chronic, a Gem for natural language date-time parsing.

Suddenly, you want to learn everything you can about Ruby.

Yukihiro "matz" Matsumoto

Matz invented Ruby. The name came first, as Masayoshi Takahashi told us this morning. "Has to be a gem," an associated advised Matz. "Why?" "Because of 'Perl'," was the answer. I hadn't been able to help noticing the pride Mr. Takahashi had expressed in the fact that Ruby is the first significant and widely accepted programming language to arise in Japan.

]]> Matz is reserved and modest. In the text below, I've edited out my gently coaxing questions and have let Matz speak for himself, hesitant as he is let us glimpse the shining light of his well-earned pride in his intellectual creation.

Matz: We have many programmers in Japan. Some are very smart. In general, Japanese are not good at English. They want to work on influential software for international distribution, but they have had to learn English before that.

Ruby is used worldwide. So, using Ruby, they can join the developer community without learning English, as Takahashi-san said in his presentation. Ruby allows Japanese developers to show their ability to people outside Japan.

I just wanted to create a language people would use in and out of Japan.

I work fulltime in Ruby. I work in Open Source integration. The systems we design for our clients include Ruby. We offer our clients a cheaper solution using Open Source software. Some of our geeky clients feel trust in the company that owns Ruby and has the creator of the language on-staff.

Of course we like to do Linux, but most people in Japan are using Windows. Linux works well in Japanese. However, the big companies are very conservative and feel resistant to relatively new operating systems.

I have kept control of the core Ruby language, the syntax, the interpreter itself. I'm not going to lose control over design of the language. I've asked others here to work on the new Ruby virtual machine, take an implementation role, but I'm not going to pass the design on to others.

I have learned from Perl and avoided some of the mistakes of Perl. I made a mistake in borrowing weird variables from Perl. In implementation, Ruby's interpreter core is too complicated. Even I cannot understand it! When something goes wrong in the interpreter core, I sometimes have a hard time reading and understanding the structure.

I could not have imagined the current state of things with companies around the world using Ruby when I released the first version in 1997. It doesn't really matter how many people use Ruby all over the world. But since Ruby is my masterpiece, when people use Ruby with satisfaction, it makes me feel better.

Who Attends the RubyConf?

Mike Howard is a veteran of programming, weighing in at 40 years in the trade, still active, still questing. I asked Mike what brought him to RubyConf 2006?

Mike Howard: I've been looking for 8-10 years for a way to build web applications that is efficient. The first thing I tried was a bunch of m4 macros and C macros that translated stuff. Every time I see a web framework I try it. That got me into Ruby. I've become really interested.

For these past ten years, I've been a consultant, doing a broad range of things, device drivers, applications, system administration ...

I'm trying to narrow my focus to something I can manage a little bit better, to stay the lone wolf, to keep from going insane. The breadth of what you have to know and the speed at which you have to learn new information pretty much follows Moore's Law. It's impossible to keep up, especially if you cover too broad a spectrum.

I think of it in terms of efficiency. I started out programming in Fortran. I eventually found C and Pascal. About 5 or 6 years ago I discovered Python and started doing everything I could in Python and PHP.

Ruby is a step above that. I've come to appreciate just how efficient and concise the Ruby syntax is and how much easier it is to solve problems in Ruby than it is in other languages. Just as a guess, there are probably two orders of magnitude of ease in Ruby compared to C, in terms of the code you have to write. I haven't measured it.

Ruby is readable. I don't write in languages that aren't readable. I have code that I wrote close to 20 years ago that's still running and the people that I wrote it for still know where I am. I may have to fix it someday.

Riding the Rails to Denver: Day 1

Denver is beautiful in the fall. The sky is clear, it's 61 F., and from behind the stark and rugged Rocky Mountains the clouds bringing this weekend's projected snow are looming like bread rising out of the bowl.

]]> RubyConf 2006 starts in Denver today. Several hundred male Rubyists and at least one female Rubyist are in attendance. Many stars -- Yukihiro "matz" Matsumoto (Ruby's chief designer), of course, with Mike Clark, Glen Vandeburg, Pat Eyler, Marcel Molina, Rich Kilmer and others -- of the Ruby and Ruby-on-Rails movement are there.

We are treated to one very funny "History of Ruby" by Masayoshi Takahashi in the opening session.

Funny? Well, yes, his mordant self-deprecating humor flavored by the concious satirical delivery of his rudimentary English is funny. But it's poignant and fraught with meaning for our transnational community of computer programming as he tells us:

The development community in Japan is the Ruby community. Imagine a world where everyone speaks Japanese, all the programming languages are taught in Japanese, all the books and the Internet are in Japanese, and you only speak English. For us, the choice is often, 'Learn Ruby or learn English'.

More later. I'm actually a working developer and have to put in some hours today. I'm scheduled to chat with Matz later today. I also am going to try to round me up one more Ruby programmer.

RubyConf 2006 - Introducing Jack Woehr

As of this date, we're handing over the reins of our Ruby Show Blog to Jack Woehr: computer scientist, programmer (contributor to the Ant project, etc.), long-time Dr. Dobb's contributor, and general Renaissance type whose interests run the gamut from goose-keeping to arranging for the Hayden Duet-layout concertina.

Jack will be reporting from RubyConf 2006 in Denver, October 20-22.