Bruce Eckel is one of the better authors of programming books around. He is famous for his ‘Thinking in …’ books on Java and C++, and also has an appreciation of — and enthusiasm for — dynamic scripting languages like Python, which is quite unusual for those developing in statically-typed languages.
Bruce has just written an interesting blog entry on Ruby on the Rails, with comparisons to Java and Python. Interesting stuff. Check it out.
Dan Wood has written an interesting entry in his blog about how the logo for his company Karelia came to be. He uses this to dive into a history of Watson — probably the first Mac app to bring web services to the desktop — and his latest project, a WYSIWYG web site editor called ‘Sandvox’.
The Sandvox Story
The main motivation for the story was a rumor: someone spotted a link to a yet undisclosed piece of software on Apple’s web site called ‘iWeb’. Apparently it was posted by accident, and quickly pulled, but not before the damage was done. Dan is clearly worried that iWeb will be a direct competitor to Sandvox, and I’m afraid he is probably right.
As Dan explains, if iWeb is indeed a competitor to Sandvox, it is the second time he has been struck by Apple-flavored lightening: After establishing the market, Watson soon found itself in the ring with Sherlock 3, which bore an uncanny resemblance to Karelia’s application. Watson survived for a while longer, but eventually went the way of the dodo.
Karelia’s logo shows a small human-powered railway car; it was motivated, according to Dan, by a conversation he had with Steve Jobs just before Sherlock 3 was released. Jobs apparently told Dan that Karelia was a hand-powered rail car, and Apple was the locomotive that owned the track, and was bearing down fast. It’s a very amusing story.
Dan has since moved on, and is in the last stages of development on Sandvox. (Starting today you can download a public beta.) So the news that Apple may again be encroaching on his territory is undoubtedly a bit of shock.
Today I downloaded the Sandvox public beta, and played with it for a little while. It is a very nicely written piece of Cocoa software, and I have no doubt that it would do extremely well … if Apple were not to enter the race. If iWeb is similar in functionality — and worse still — bundled with iLife, Sandvox could be dead in the water before it even gets started.
To be honest, I don’t know how much it should really come as a shock. Sandvox reminds me a lot of Apple’s Pages and Keynote software, with the primary difference being that Sandvox is targeted at web site development. It shouldn’t come as too much of a surprise that Apple might consider developing a Pages-like app for creating web sites. Yes, Karelia may be about to be struck by lightening a second time, but that could have to do with the fact that they appear to be leaning against a flagpole in the middle of a golf course.
The Development Tightrope
If you are going to play with the big boys, there is always the risk of getting burned. It’s happened time and time again. The payoffs of writing mainstream apps are great, but the competition is high. Even if you have a unique idea, and have the market to yourself, its success may ultimately be its downfall, because it won’t go unnoticed. You had better make your money fast, because it won’t be long before you have company.
If you are really serious about making money writing Cocoa apps, I think you can learn a lot from guys like Wil Shipley. Delicious Library is mainstream enough to make a heap of cash for Mr Shipley, but perhaps not mainstream enough that it would be of interest to Apple. Apple are in the business of very high-volume software — stuff that everyone needs. Browsers, photo management software, digital duke boxes, etc, etc. Delicious Library is useful to many people, but not everyone. I don’t think it would make business sense for a company the size of Apple, but for a small company like Delicious Monster, it’s a cash cow.
Developers like Wil Shipley, Dan Wood, and Brent Simmons (of NetNewsWire fame) are highly respected members of the Cocoa development world. Cinderella stories of programmers that have developed killer apps in their spare time, quit the day job, and started living ‘The Life’, always make a great read for aspiring developers. In the beginning, I was no different, but my outlook has changed. I actually don’t want my software to be too successful.
See, the thing is, I like my day job. I don’t want to quit it, even if it meant I could develop Cocoa apps all day. I like working with Cocoa as a hobby, but I don’t think I would like it nearly as much if it dominated my every waking hour.
Not only that, but as your sales increase, the amount of time you have to spend on the business side of things increases. Eventually, you have to take on staff to help with administration and/or support, and that comes out of your income. With limited sales, you can do everything yourself, and the revenue goes straight into your personal bank account.
The point is, there is a third way: writing niche software. It won’t make you rich, but you can make some nice pocket money without the stress of running a business. If you actually like your day job, this might be the way to go. Just make sure you don’t write anything that becomes too popular.
Trade Strategist is the Cocoa software that I develop and sell. It is financial modeling software for the stock market, and the potential market is actually very small. Nonetheless, I do make some reasonable pocket money out of it, ranging between $500 and $1500 a month, depending on the release schedule. I won’t be getting rich any time soon, but the $10000 or so I earn per year from Trade Strategist does come in handy. It’s just paid for my new bathroom, for example.
There is more than one way to skin a cat: You can take the high-risk, high-rewards route of Karelia, or you can just play in the minor leagues. You won’t ever be Donald Trump, but it can still be very rewarding, and you’ll even be able to sleep at night. Here’s to hoping Dan can get some sleep before tomorrow’s keynote.
Scientific Software development is still dominated by Fortran, and what’s more, most Fortran programs have still not made the transition to the Fortran 90/95 standard, let alone Fortran 2003. Predicting the demise of Fortran is a sport almost as well-subscribed as predicting the downfall of Apple, but both Fortran and Apple have proven much more resilient than most could have anticipated. There wouldn’t be too many willing to bet against Apple at the moment, but Fortran may be about to come under pressure from new languages. Will the Fortran nay-sayers finally draw blood?
I do a lot of programming in Fortran; it forms the basis of the ADF package, which I contribute to, and most of my research programs are written in Fortran 90. I must admit to having a strong aversion to Fortran 77, especially when it is used to write new code. It was no doubt once a very powerful language, but by today’s standards is quite primitive. Fortran 90 addressed many of the deficiencies, making it a very useable language, approximately on a par with C. Some features of Fortran 90, such as arrays, are actually far superior to anything in C.
Recently, I have been following the transition to Fortran 2003 with some interest, and even looking beyond it to future Fortran standards. Fortran 2003 exists as a standard, but not yet as a practical language, because there is no compiler that fully supports it. It will be several years before it is a serious option, but you can already read about it.
Unfortunately, from my point of view, Fortran 2003 suffers from the same fate as most aging languages: it is quite verbose and ungainly. It’s not necessarily the fault of the Standard authors; it’s just what happens when you try to make something do what it was never intended for, like installing a turbo in a T-model Ford. For example, Fortran 2003 finally brings Object-Oriented Programming (OOP) to Fortran, but it is not a pretty fit. Languages like Python, that were designed for OOP from day one, are much more compact and natural.
The real question is if it even matters whether these new features are clumsy or not. Fortran is in a monopoly position, and history has told us that that can be a formidable barrier for contenders to overcome, even when the monopolist is second rate. The shear volume of Fortran code already in existence, and the reluctance of Scientists to learn a new programming language, may be enough to guarantee Fortran’s future.
It may not be all smooth sailing though, because for the first time in my career, there are efforts afoot to design new languages specifically with scientific applications in mind. One such language is Fortress, which is being developed at Sun Microsystems. Sun has achieved a lot with Java, and you might think that if anyone could come up with a viable new language, they could. Their team is headed up by Guy Steele, who helped design Java and contributed to the High Performance Fortran specification.
It will probably be another 5 years before Fortress is any more than an academic exercise, if it makes it that far. Even if it doesn’t supplant Fortran completely, it would be good to have some competition amongst scientific languages — at the moment it’s a one horse race.
One of the best ways to learn is to learn from the mistakes of others — it sure beats making your own. Recently, I got that sinking feeling that comes from realizing that you have made a colossal error of judgment, and are going to have to jump through hoops to correct it. What follows is the story so far, in the hope that others may learn from my ignorance.
The tale revolves around the financial modeling software that I develop in my spare time: Trade Strategist (TS). In one particular application window, I have utilized a number of Pop Up Buttons; each button is mapped to an instance variable in a model class, with each item in a button representing a different discrete state of the variable. There is nothing unusual about this at all.
The problems began when I started to incorporate Cocoa Bindings into TS, and decided that because the content values of the Pop Up Buttons were likely to change from time to time, I would like to be able to stipulate the different options entirely in code, rather than Interface Builder (IB). The reasoning was that I would have a better overview of all the different internal states and their labels if everything was defined close together in the program. The alternative would have been to update the Pop Up Buttons in IB by hand each time an option was added or changed. This would not have been the end of the world, but I thought my approach — in which the state labels were effectively treated as data in the model layer — was easier to oversee.
I began by defining static NSString variables for the different labels in each NSPopUpButton, and methods in my controller class to return the values with which to populate each button. I bound one of these methods to the contentValues binding of each pop up. To complete the picture, theselectedValue binding of each button was bound to an NSString instance variable in a model class. Voila!
Unfortunately, I only realized the error in my ways after a version or two of TS had passed. I was representing states internally with the same NSStrings that were used to represent the option in the user interface. Not only is this quite inefficient in memory terms, it is also extremely inflexible. If you want to change the wording of an item in a Pop Up Button, you also have to update unarchiving methods like initWithCoder:, even though the model hasn’t actually changed. It is a classic example of compromising the Model-View-Controller (MVC) doctrine.
To solve the problem — while preserving the ability to define item labels in-code — I introduced a few classes for mapping enum values to NSStrings. The appropriate form for a variable representing a discrete state in the model layer is an enumerated type (i.e. enum); a common way to represent a discrete state in the user interface is a Pop Up Button. These two entities are often used together, and it seems logical to have a simple way of mapping the values of one to the other.
The first class I defined was EnumValueLabel. This simply stores an enum value, and its associatedNSString label:
The idea is that you initialize a LabeledEnum for each enum that you want to map to aNSPopUpButton. In the following example, a class method initializes and returns a LabeledEnumcorresponding to the enumSignalType.
These classes are only really useful when they are combined with the third class:EnumValueLabelTransformer. This is a subclass of NSValueTransformer, and is used to bind theselectedValue binding of the NSPopUpButton to the enum instance variable in the model class.
With all of this apparatus in place, it is possible to define your instance variables as enumerated types, and assign them labels in code. The EnumValueLabelTransformer converts the enum values to the NSStrings that populate the NSPopUpButton. Note also that separation of model and view is now reinstated, because the item labels in the button can be varied independently of the model classes.
I am releasing the three classes described above into the public domain. You can download the source code here. As you might expect, it comes with no warranty whatsoever, and the complete freedom to do with it as you will.
I am also interested in hearing how other people handle the Pop Up Button-Enumerated Value correspondence. Do you just manually enter values in IB? Or have I missed something obvious already in Cocoa? Enter a comment below, and we might all learn something…
After writing this piece, it occurred to me that although the solution I have developed is suitable to my circumstances, it is not advisable in general. In particular, because I chose the wrong route initially, the EnumValueLabelTransformer class helps me to easily transform the NSStrings to enumvalues in the initWithCoder: method. However, if you have not made the same mistake, it is not necessary to introduce the classes discussed above, because they basically duplicate functionality already present in the NSPopUpButton class.
So how should you couple an enum to a NSPopUpButton? The most obvious way is simply to manually enter pop up items in IB, and assign a tag to each corresponding to the enum value represented. If, like me, you would prefer to define the labels in source code, you can add items to theNSPopUpButton programmatically, in an awakeFromNib method, for example:
MacResearch, which I think is a great site for the Mac using Scientist, has pondered the question of why there hasn’t been a boom in Scientific Software exclusively for the Mac. The assumption is that because the Mac has free developer tools; a great application development interface (API) in Cocoa; and easy to use scripting languages like AppleScript, that it should only be a matter of time before a number of ‘killer’ scientific apps appear.
As a Mac-using Scientist and Developer, I am quite well credentialed to offer some insight into this. In my day job, I help develop the commercial cross-platform Quantum Chemistry softwareADF, and in my spare time I develop and sell a financial-modeling app — written in Cocoa — called Trade Strategist. I also do most of my Scientific Research on the Mac, with the free Xcode tools referred to in the MacResearch article.
There are two ways in which a Scientific App could become publicly available: The first is via a company, and the second is via a Scientist. But the Mac market is relatively small, and the market for scientific Mac users even smaller. There really is not enough money in it to support a company developing exclusively for the Mac. In fact, there really isn’t enough money in Scientific Software to afford the luxury of any platform exclusivity whatsoever. Most companies I know support multiple platforms to make ends meet.
So if we assume that a company must develop cross-platform Scientific Software, it is pretty clear why there are not many company-developed apps written in Cocoa — Cocoa is a proprietary technology only supported on Mac OS X. As wonderful as it is, it is not an option for most companies, that end up choosing cross platform solutions like Qt and Tcl/Tk.
With companies out of the running, why aren’t there more software packages coming from the Scientists themselves? Ultimately, it again comes back to money, or at least time (which equals money). Even with a great API like Cocoa, developing good software is quite a time-consuming process. To get to first base is actually quite easy: You can throw together a prototype or version of your software with limited-functionality in a few days or weeks. The problem is taking the next step of turning that unpolished rock into something desirable to others.
Writing documentation, thorough testing, generalizing the functionality, improving the user interface; it all takes a lot of time. And its time the average Scientist doesn’t have to spend on such frivolous activities. Publish or perish, man! That great user interface won’t result in any new publications, so just take the ugly but functional version of the app that you already have, use it to generate your own scientific results, and leave the swarming masses to their own devices.
I am actually talking from experience here, because I once had stars in my eyes, and a piece of software that I thought could revolutionize the Scientific World: Dynasity. Dynasity is a Cocoa visualization app. I like to think of it as a visual multi-track recording studio. You create different visual tracks, and follow them in time. Dynasity also leverages QuickTime, making it possible to capture movies and stills with the click of a button.
So where is Dynasity? Where can you download it? Well, you can’t really. Dynasity is developed and used internally in my research group, but it has never been released to the public. The time required to generalize the software for a mass audience, and the problems of supporting it thereafter, make it undesirable. And any potential sales would hardly compensate the investment of time demanded. (If you are really intrigued about Dynasity, you can download it here. Note that this is not an official release, and comes with no promise of support or any warranty whatsoever.)
There are Scientific Apps available on the Mac, but they are often a bit underdone, for the reasons given above, and could hardly be classified as ‘killer apps’. There are exceptions though: As MacResearch mentioned in their piece, Mek&Tosj — fellow inhabitants of Amsterdam — write some great Cocoa software for Molecular Biologists. DataTank is also a Mac-exclusive that I like a lot; it is a visualization app like Dynasity, but much further developed.
One thing you could be forgiven for thinking from all of this is that the Mac is not much good to the Scientific Developer. Nothing could be further from the truth. I do most of my development work, from legacy Fortran to advanced C++ and Python scripting, with Apple’s free tools on a Mac. Xcode is great, and if you add to that Xgrid, gcc, and scripting languages like Python, Perl, Ruby, and Tcl, you have a winning combination. I also regularly use TextMate, an editor gaining favor with developers, and exclusive to the Mac.
In conclusion, the Mac is an insanely-great Scientific Platform, but don’t hold your breath for Mac-exclusives in the Scientific Realm. There simply isn’t the market for the big boys, and most scientists have better things to do with their time than writing help pages and answering questions of the form “I haven’t looked at the help pages yet, but can you tell me how to … ?”.
After years tossing up the idea, I finally got around to putting together a short course on advanced programming concepts for scientists. The research group I belong to has grown considerably in the last few years, and there seems to be more interest in programming than ever before, so the time seemed right.
The course is called ‘Programming Paradigms for Scientific Developers’. It consists of just three lectures: the first covers Procedural and Structured Programming; the second, Object Oriented Programming; and the third, Generic Programming. The goal is not to teach people how to write an if branch in Fortran, or define a function in Python; it is designed to address the concepts that transcend language-level details.
Scientists are not like most developers — they have a nasty habit of wanting to know why. They don’t usually accept advice unless it is accompanied by solid reasoning. Preaching inheritance and polymorphism to Scientists perfectly content with common blocks and implicit typing will get you about as far as a Ballet Dancer in a Mangrove Swamp. To get through to them, you have to be able to rationalize the concepts you are advocating, and that means a lot of soul searching.
One of the concepts I use throughout my course is that of indirection. I don’t simply mean the term as it is often used in C programming to describe the role of a pointer, I mean it in a much broader sense. Indirection relates to how directly something is represented in a piece of software. For example, a function provides a means of indirectly executing a series of instructions. The alternative to a function is directly inserting the function body into the code wherever it is required.
Because indirection occurs at every level of software development, I have been able to use it as a base from which to describe new techniques. I begin by demonstrating the role of indirection in the development techniques the Scientists are already familiar with, and then show how the more advanced programming paradigms facilitate other forms of indirection not possible in procedural programming.
An important form of indirection in Procedural Programming is that introduced by a procedure (i.e.. subroutine or function). A procedure allows the programmer to avoid duplication of code by using it indirectly via a call. Reducing duplication is an important theme in software development, and techniques that seek to introduce indirection are inevitably also designed to reduce duplication — the one facilitates the other.
A procedure also places an interface between the calling code and the procedure body. Interfaces are the means by which indirection is realized. By introducing an interface, code becomes more flexible, because as long as the interface is fixed, code behind the interface is free to vary independent of the calling code. (In object oriented terms, code behind an interface is known asimplementation.)
In summary, different forms of indirection are designed to eliminate different types of duplication by introducing different sorts of interfaces. Once you realize this, the techniques introduced in each programming paradigm make a lot more sense.
Consider Fortran’s user defined types (UDTs), which are equivalent to C’s structs. UDTs are to variables what procedures are to expressions: a form of indirection that relieves the developer from duplicating data declarations. And take inheritance in object oriented programming (OOP); it is a means of indirectly including the variables and methods of one class in another class.
Polymorphism is one of the more difficult concepts to grasp for those new to OOP. It makes more sense, however, when you recognize it as yet another incarnation of indirection, one in which interfaces are introduced to free a given piece of code from making direct reference to a particular concrete data type.
Reuse of code in procedural programs — which do not make use of polymorphism — usually involves conditional branches, with one branch for each data type used. Consider the following Fortran 90 example:
integer, parameter :: QN_OPTIMIZER = 1
integer, parameter :: CG_OPTIMIZER = 2
type (QuasiNewtonOptimizer) :: qn
type (ConjugateGradientOptimizer) :: cg
integer :: opt
select case (opt)
select case (opt)
select case (opt)
This code could form the basis of an optimization engine that includes several different types of optimizers. What you will hopefully notice is that there is a subtle form of duplication occurring in the branching structure. Exactly the same form of select block is being used for initializing the optimizers, taking a step, and deleting them again. Wouldn’t it be good if you could employ a single branching block, and somehow ‘remember’ which branch was followed, so that the rest of your code would not be polluted by duplicated blocks?
Polymorphism is in effect exactly that: a means of storing branching decisions. Consider the following rewrite of the above example:
integer, parameter :: QN_OPTIMIZER = 1
integer, parameter :: CG_OPTIMIZER = 2
type (QuasiNewtonOptimizer) :: qn
type (ConjugateGradientOptimizer) :: cg
type (Optimizer) :: optimizer
integer :: opt
! Choose implementation
select case (opt)
optimizer = qn
optimizer = cg
! Generic type remembers the choice
In this case, a new ‘generic’ type called Optimizer has been added. It effectively stores the branch chosen when an optimizer is initialized. The generic type is a polymorphic pointer: when thetakeStep and delete methods of the Optimizer object are invoked, it ‘looks up’ the stored concrete optimizer type, and invokes the appropriate subroutine. Naturally, the look up is a form of indirection, freeing the calling code from direct knowledge of the executed code, including the concrete type of the optimizer.
Standards of Fortran prior to 2003 do not directly support polymorphism of this type, but it is easy enough to fudge — the code above is real working Fortran 90. To find out more about what lies behind the Optimizer generic type, you can download my course slides, which go into plenty of detail.
Someday, I would like to incorporate automated creation of generic types into the Forpedopreprocessor, but I’ll leave that for another time …
Last week marked the 60th birthday of my Professor, Evert Jan Baerends. To celebrate the event, a meeting of minds was organized, with interesting presentations given by researchers from around the world. The presenters all had some connection to Evert Jan, and were given the opportunity to express their admiration for his contribution to Density Functional Theory (DFT).
The meeting and subsequent dinner got me thinking about the way I see Evert Jan, and the role he has played in my life. Evert Jan was actually the first academic that I contacted in The Netherlands when I was looking to move here. He didn’t have a position for me at the time, but did put me in contact with Geert-Jan Kroes, who offered me a Postdoctoral position. Later, Evert Jan offered me a permanent position in his research group, and I’ve been there ever since. So I’ve got a lot to be thankful to Evert Jan for. Without him, I would probably not be living in The Netherlands, would not be enjoying a career in Theoretical Chemistry, and probably would not be married to Jennifer and have two adored children.
It is obvious that I am indebted to Evert Jan, but how do I view his role in the group? To explain, I need to digress a little: Back in the 1990’s, Steven Spielberg directed his much acclaimed take on the holocaust, Schindler’s List. Not many people know it, but the movie was based on a book by the Australian author Thomas Keneally. Keneally originally called his work “Schindler’s Ark”, a reference to Noah and his efforts to save living things in an entirely different kind of holocaust. One of the masterful aspects of Keneally’s book is the ambiguity that he imbues the character of Oscar Schindler with. Is he a good man, saving Jews from the Nazis, or is he a businessman exploiting the most vulnerable in society? Or is it both?
What does this have to do with Evert Jan Baerends? Well, in many ways I see Evert Jan as the Oscar Schindler of Theoretical Chemistry. He has built up a large group of researchers, many of whom may have been destined for the intellectual wasteland of industry. I myself spent 6 months writing software for a private firm, before Evert Jan added me to his list, rescuing me from a tedious — though unquestionably more lucrative — future. And I’m not the only one. Somehow, Evert Jan finds a way to sneak good theoreticians into his group, whether by orthodox means or otherwise.
A case in point is Scientific Computing and Modeling (SCM), the company that Evert Jan set up to support and sell the Amsterdam Density Functional (ADF) package. SCM now employs four very talented theoretical chemists; without the company, there would be four less positions for Theoretical Chemists in the world, and some of the people now in its service may not have been able to find a University position.
University lectureships are only suited to a small number of scientists: those not only good in science, but also with an interest/talent for teaching, and managerial tendencies. It is not a given that those that end up in lecturing positions are the most talented scientists, and a lot of good scientists without an interest in management or education are forced to leave academia, and are wasted to the scientific world. Evert Jan seems to realize this, and has managed to retain many Theoretical Chemists that would be unsuitable as lecturers, but are otherwise first rate scientists.
Of course, just as with Oscar Schindler, it is a two-way street — Evert Jan also benefits from his ark. The scientists in his group have made it one of the best performing Chemistry groups in The Netherlands, so you needn’t feel sorry for him. Just as for Schindler, the question of whether he is a charitable man, or a exploitative one, or both, is of no practical concern. The results speak for themselves.