Closer To The Ideal

I do not know much about Objective-C, but I’ve got a lot of friends who want to do iPhone apps, so I’ve thought about diving in.

Matt Gallagher writes about the best aspects of Objective-C in a really interesting post:

The short answer is that this dynamic message handling in Objective-C makes it much easier to work within a large framework that you didn’t create because you can examine, patch and modify elements of that framework on the fly. The most common situation where this is likely to occur is when dealing with an application framework.

The biggest reason for this is that you can add or change methods on existing objects, without needing to subclass them, while they are running. Approaches for this include categories, method swizzling and isa-swizzling.

This makes the following situations possible:

• You want to add a convenience method to someone else’s object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI).
• You want to change the behavior of a class you didn’t (and can’t) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa).
• You want to treat objects generically and handle potential differences with runtime introspection.
• You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object).

These points may seem somewhat mild but they are central to maximizing code reuse when working within someone else’s framework: if you need existing code to work differently, you don’t need to reimplement the whole class and you don’t need to change how it is allocated.

Languages using virtual method tables can adopt some of these ideas (like the boost::any class or C♯ 4.0’s dynamic member lookup) but these features have additional restrictions and don’t apply to all objects, meaning that they can’t be used on purely arbitrary objects (such as those you don’t control or didn’t create) and so don’t help when interacting with someone else’s framework.

Simply put: dynamic message passing instead of virtual method invocations makes Objective-C a much better language for working with a large library or framework that someone else has written.

… In my opinion, Objective-C is the best language for programming situations where you must make extensive use of a framework written by someone else (particularly an application framework). The success of Objective-C in this situation is due to the combination of:

* speed and precision (from its compiled C roots)
* dynamic flexibility (due to using message passing for method invocations)

To frame this conclusion, I’ll state that I’ve written major projects using C/WIN32, C++/PowerPlant, C++/MFC, and Java/Swing/AWT. I’ve also dabbled in smaller projects using C♯/.Net. In all of these cases I have found the application frameworks to be less flexible and less reusable because they lack the dynamic modifiability of Objective-C.

When I hear the words “change methods on existing objects… while they are running” I immediately think of Ruby. In fact, till recently, Ruby was the only language I was aware of that allowed you to modify a class at runtime. Some programmers regard this as heresy. Consider the fear in Bill Venners voice as he talks about this with Yukihiro Matsumoto (the creator of Ruby):

Bill Venners: In Ruby, I can add methods and variables to objects at runtime. I have certainly added methods and variables to classes, which become objects at runtime, in other languages. But in Java, for example, once a class is loaded or an object is instantiated, its interface stays the same. Allowing the interface to change at runtime seems a bit scary to me. I’m curious how I would use that feature in Ruby. What’s the benefit of being able to add methods at runtime?

Yukihiro Matsumoto: First of all, you don’t have to use that feature. The most useful application of dynamic features, such as adding methods to objects, is meta-programming. Such features allow you to create a library that adapts to the environment, but they are not for casual uses.

So, it seems to me, Objective-C was pioneering many of the advantages that I would nowadays associate with dynamic scripting languages, like Ruby or Groovy. But an interesting thing about Objective-C is that it is a compiled language. It was compiled largely because the computers that existed back then were not powerful enough to handle script languages. Perl and Python don’t get going till the end of the 80s, and scripting languages don’t really take off till the 90s, when there was sort of an explosion of them (Ruby, PHP, etc).

The SmallTalk language was an inspiration for Objective-C, but SmallTalk ran very slowly on the machines of the early 80s:

In the early 1980s, common software engineering practice was based on structured programming. Structured programming was implemented in order to help “break down” programs into smaller parts, primarily to make them easier to work on as they grew increasingly large. However, as the problems being solved grew in size, structured programming became less useful as more and more procedures had to be written, leading to complex control structures and a low level of code reuse.

Many saw object-oriented programming as a potential solution to the problem. In fact, Smalltalk had already addressed many of these engineering issues; some of the most complex systems in the world were Smalltalk environments.[citation needed] On the downside, Smalltalk used a virtual machine. The virtual machine interpreted an object memory called an image, containing all development tools. The Smalltalk image was very large and tended to require huge amounts of memory for the time. The virtual machine also ran very slowly, partly due to the lack of useful hardware VM/container support.

So what was needed, at that time, was a compiled language that offered the flexibility of object oriented code, and perhaps some of the productivity benefits of dynamic languages:

Objective-C was created primarily by Brad Cox and Tom Love in the early 1980s at their company Stepstone. Both had been introduced to Smalltalk while at ITT Corporation’s Programming Technology Center in 1981. Cox had become interested in the problems of true reusability in software design and programming. He realized that a language like Smalltalk would be invaluable in building development environments for system developers at ITT. Cox began by modifying the C compiler to add some of the capabilities of Smalltalk. He soon had a working implementation of an object-oriented extension to the C language, which he called “OOPC” for Object-Oriented Programming in C. Meanwhile, Love was hired by Schlumberger Research in 1982 and had the opportunity to acquire the first commercial copy of Smalltalk-80, which further influenced development of their brainchild.

Objective-C arrived at Apple via NeXT:

After Steve Jobs left Apple, he started the company NeXT. In 1988, NeXT licensed Objective-C from StepStone (the owner of the Objective-C trademark) and released its own Objective-C compiler and libraries on which the NeXTstep user interface and interface builder were based. Although the NeXT workstations failed to make a great impact in the marketplace, the tools were widely lauded in the industry. This led NeXT to drop hardware production and focus on software tools, selling NeXTstep (and OpenStep) as a platform for custom programming.

…After acquiring NeXT in 1996, Apple Inc. used OpenStep in its new operating system, Mac OS X.

I can imagine that at the time Steve Jobs was starting NeXT, Objective-C would have huge appeal as the most dynamic compiled language available at that time. And Jobs has stuck with it for over 20 years now, first bringing it into the MacOS and then making it the basis of programming in the iPhone API.

The Wikipedia page says Objective-C tends to run 3 times slower than plain C. I imagine that used to matter, though of course nowadays large projects (possibly the majority of all software written?) is written in languages that depend on a virtual machine, so I assume Objective-C is faster than most of the languages that are nowadays in heavy use.

All of this leaves me somewhat curious about why Objective-C isn’t more popular. Perhaps it is just too much in the middle in terms of performance versus its dynamic nature? Nowadays programming tends to fall into 2 worlds – when you need speed, write in C, but if you want dynamic productivity, use something like a script language: Ruby, Groovy, PHP. Or, at the very least, a language that cleans up variables and memory for you (automatic garbage collection) as in Java and C#. Possibly it is the lack of automatic garbage collection that has kept Objective-C from taking off?

(In this post, I will let hecl stand in for all scripting languages that aim to make programming easy to do on cell phones.)

All through the 1980s and for most of the 1990s, Apple made efforts to make programming easy. In 1987, Apple released Hypercard, probably the single easiest programming environment ever. Apple’s dedication to empowering people – allowing minimally-technical people to program – earned it a great deal of goodwill, so much so that Bill Atkinson (the inventor of HyperCard) basically gave it to Apple as a free gift, in exchange for the promise that it would be included on all Macintosh computers. Sadly, in this decade, Apple has forgotten about Hypercard. My sense is that this represents a larger trend within Apple: a general retreat from the goal of giving minimally-technical people easy programming tools. The death of Hypercard lead to mourning among its many fans (myself included). Danny Goodman summed up the feelings of many:

I shed my buckets of tears for HyperCard (and what might have been) many, many years ago. The first crude demo that Bill showed me was, at its root, what the World Wide Web has become. Coulda, woulda, shoulda.

Despite valiant post-version 1.1 efforts by dedicated and exceptionally bright serfs (their recollection brings fond memories), HyperCard never truly recovered from its detour to the Claris dungeon and the dungeon masters. It’s a tale of perhaps the biggest opportunity Apple missed in its self-defense against a rising Windows tide.

When I look at the current product, I see facets that are still ahead of their time, not the least of which is the extraordinarily elegant HyperTalk language by Dan Winkler — a kid straight out of college, who Bill Atkinson said was the only programmer who could keep up with him. At the same time, aspects of the product have been embarrassingly behind the times for years. Kevin was well on his way to fixing that, but the scenery changed.

Back when Apple was still proud of HyperCard, and boastful of its use by minimally-technical people, this is the kind of article that I read over and over and over again:

I thought it was really cool to see – not because I’m interested in quilting, or the program is anything brilliant (it’s simple and functional), but because enabling stuff like this is part of what I built Hecl for: to make mobile phone applications easier, quicker, and simpler to create. Someone went and typed in the code on Heclbuilder, got the program running, and now a number of people have a handy tool to do some calculations for their hobby, which is a heck of a lot easier than fooling around with SDK’s, Eclipse or Netbeans, and so on and so forth.

But this is no longer Apple talking, rather, it is David Welton, talking about Hecl.

The other tool for programming by minimally-technical people that Apple has promoted has been AppleScript. Influenced by HyperTalk (HyperCard’s programming language), Applescript has a syntax that in many ways mimics English, and therefore it is easy for English speakers to learn.

The digital revolution continues to change our lives. The biggest change over the last few years has been the mass acceptance of cell phones. Most people that I know no longer have landlines, they only have cell phones. This is the next great frontier for computer programming. And yet, Apple hasn’t yet made Applescript available to run on the iPhone. Yet hecl can run on Android.

Personally, I would love to be able to write apps for the iPhone. But I don’t want to have to learn the Object C language. I don’t have the time. I agree with Simon Brocklehurst’s criticism of this decision:

Recently, Apple bowed to the inevitable, and has released an SDK for developer testing. The language they chose to base the SDK around is Objective-C. This wasn’t a complete surprise – after all, it’s the “native” language of Mac OS X. However, while it’s not a surprise, I wonder if it’s not a major strategic error on Apple’s part. The point is this: the Mac is a niche platform, and is especially niche in terms of numbers of developers building applications in Objective-C. Compare that to iPhone, which because of its technological lead, has the chance to become a major volume player in the mobile phone space. If Apple wants iPhone to succeed, it seems strange to attempt to force developers to use an unpopular language for programming it. That isn’t the way to win – developers have many, many choices of platforms they can spend time developing for.

Brocklehurst thinks Apple should pick a popular language for its SDK. I think Apple should pick one that is easy to learn. A light weight scripting language. If Apple came out with an implementation of Applescript that ran on the iPhone, then I would start writing iPhone apps tomorrow.

But for now, it doesn’t seem like Apple is planning on doing that. So when I look around for relatively easy ways to get into cell phone programing, other light-weight scripting languages jump out at me. And they lead me to platforms other than the iPhone.

So maybe hecl is the new Applescript/Hypercard? For people who want to put together a quilting site with a cell phone connection, what is the easiest way for them to do that? Who is, right now, showing commitment to the old ideal of empowering minimally-technical people to write the apps that they want?

I am dissatisfied with the HTML that is auto-generated by the built-in scaffolding system of Symfony.  I am planning to write a plugin that will generate HTML more to my liking. I know that, in the world of Ruby On Rails, there are several plugins that improve upon the built-in scaffolding system of that framework. Since these plugins have a longer history, and are more advanced, than anything in the world of Symfony, I am looking to them for some inspiration.

This is what Hobo says about itself:

It turns out that the hard part is not going fast, but staying flexible. This is where we think Hobo really shines. If you’ve played with “app builders” before, you’ll know about The Wall. The Wall is the point you reach where you have to give up and do it the old way because that one feature you really need just isn’t going to happen. Hobo doesn’t have one.

…Like Rails itself, Hobo encapsulates a number of opinions about web application development. The opinion that is most central to Hobo is this: we have found that there is a great deal of similarity from one web application to the next. Much more similarity in fact, than is supported by today’s frameworks. We would rather implement this stuff once.

Of course this approach is common to all frameworks—everything that Rails provides is there because many or all web applications will need it: database connectivity, session management, working with HTTP, etc. etc. The difference with Hobo is that we are trying to take this idea to a much higher level than is normally expected from a web framework. The ultimate goal is: don’t program your application, just declare it.

This is what ActiveScaffold says about itself:

Most web applications have many more model objects exposed on the backend, or admin side, than they do on the front. Coding interfaces for all those models is redundant and a waste of resources when all you need is CRUD functionality that’s smart enough to handle all your ActiveRecord associations.

Enter the ActiveScaffold plugin:

• An AJAXified table interface for creating, updating, and deleting objects
• Automatic handling of ActiveRecord associations
• Sorting, Search and Pagination
• Graceful JavaScript degradation
• RESTful API support (XML/YAML/JSON) baked in
• Sexy CSS styling and theming support
• More extension points than you can shake a stick at
• Guaranteed to work on Firefox 1+, IE 6+ and Safari 2+
• Released under the MIT License, the same one as Rails itself, so you can use it freely in your commercial applications.

This is what Streamlined says about itself:

Streamlined is a plugin for Ruby on Rails that provides an instant, production-ready UI for your ActiveRecord models. It started as a way to generate Administrative back-ends, but has become more general purpose and flexible over time. Streamlined aims to bring the declarative goodness of ActiveRecord to the view tier. It manages the presentation, creation, and editing of model instances, providing full-featured scaffolds equipped with everything you need to quickly and easily develop a rich user interface for interacting with your data, including:

• Zero-configuration relationship management
• Ajax-powered widgets and transitions
• Live data filtering
• Out-of-the-box sortable lists and pagination
• Exporting to XML, CSV, and JSON
• Declarative and easily-customizable UI development
• Cross-browser support including Firefox, Internet Explorer, and Safari
• Pluggable CSS styling

This gives a sense of the possibilities.

Hobo has an especially interesting goal, to create a framework that is declarative, rather than imperative.

In the short term, my goals for a new scaffolding system are simple:

1.) The HTML should use divs and CSS rather than tables.

2.) Pagination should be included by default.

3.) An administrative dashboard should be created by default.

I know I will want these 3 things from every Symfony project I start, so, for me at least, it makes sense to have  a plugin that automates all this.

My normal workflow goes like this:

1.) I edit files on my local machine

2.) I commit the files to Subversion, which means Springloops, for us.

3.) On every commit, Springloops automatically deploys the files to our development server.

4.) I refresh my browser to see how the changes I’ve made look on the server.

This gets a little complicated when working with Symfony. Lots of files are auto-generated on the server, then I need to scp them to my local machine.

How can I get hundreds of new files, scattered among dozens of new directories, into Subversion? The “svn add” command will work recursively the first time you add a directory to your repository, but if you then add several dozen new directories to that top level directory, and if you then try to run “svn add” again, Subversion tells you that the directory is already under version control.

What’s needed is a reliable way to recursively add things to Subversion. (This isn’t a problem on Windows, because the TortoiseSVN client is good about recursively adding files. But it is a problem on Linux.)

So I am very glad that I found this script:

#!/bin/bash
echo ""
echo "Here's what we're going to do:"
echo " "
echo "Add the following files"
echo "-----------------------"
svn status | awk '/^?/ {print $2}'
echo " "
echo "Remove the following files"
echo "--------------------------"
svn status | awk '/^!/ {print $2}'
echo " "
echo "Check in the following modified files"
echo "-------------------------------------"
svn status | awk '/^M/ {print $2}'
echo " "
echo "Proceed with commit? [yn]"
read answer
if [ "$answer" = "y" ]
then
    echo " "
    echo "Adding the following files"
    svn status | awk '/^?/ {print $2}' | xargs svn add
    echo " "
    echo "Removing the following files"
    svn status | awk '/^!/ {print $2}' | xargs svn remove
    echo " "
    echo "Committing changes to repository"
    svn commit
else
    echo " "
    echo "Commit cancelled"
fi

echo " "
echo "Want to check for updates? [yn]"
read answer
if [ "$answer" = "y" ]
then
    svn update
else
    echo " "
    echo "Update cancelled"
fi

Just save this into a file at the root level of your project, and then call it from the command line when you want to commit stuff recursively.

I was pointed to this script from the Symfony forums.

Found this useful tutorial: Advanced Bash Scripting.

I’ll post it here so I can find it later. I’ve promised myself that one day, I shall be able to write all kinds of shells scripts. I’d like to be able to automate any kind of activity that we need to have happen on the server.