Code by Kevin

About
Code by Kevin, Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.



Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

Privacy Policy

Site design: Skeleton

 

Sat, 16 Sep 2006

Earn, Not Learn

After closing the source of my software programs, introducing a 30-day demo period, and raising prices, I've noticed that sales have slowed down quite a bit. I think this is because a) a longer evaluation period and b) higher prices are going to lengthen the sales cycle. Downloads of the demo programs continue to be good. So, I'm going to be patient; I'm confident that sales will go back up after the 30-day sales cycle has fully started.

One thing I have been looking at is whether I should expand or change my programming approach. My main programming language is Tcl/Tk, supplemented by AppleScript. Tcl/Tk is a powerful, flexible, yet simple cross-platform tookit that has provided everything I need to develop complete applications. I've been programming in Tcl/Tk for two years, and I've developed a decent level of competency in it. AppleScript, which was my first programming language, is a good complement to Tcl/Tk; it's not really suitable for full-scale programs, but it's good for hooking into the Mac OS for specific things, and is also good for very simple applications that don't do very much. (For instance, I create my program updaters in AppleScript; they provide a simple GUI to update my applications.)

The main drawback of Tcl/Tk is that, as a cross-platform toolkit, it doesn't take advantage of some advanced bells and whistles of Mac OS X that are typically featured in commercial applications. It takes more work to get a Tcl/Tk program looking good on the Mac than it would if I were using a platform-specific programming environment (specifically, Cocoa, which is the Apple-recommended programming framework).

This has, at least to some degree, gotten me wondering if my choice of programming toolkits is somehow affecting how well my programs sell. In seeking feedback from other independent Mac developers about my programs, many of them simply say: "Learn Cocoa"--as if nothing else needs to be said. If a program is Cocoa, it's gold; if not, it's not.

I find it difficult to embrace such advice, for several reasons. One, Tcl/Tk isn't compatible with Cocoa; the Mac version of Tcl/Tk is built on top of Apple's older Carbon frameworks, which date back to the old Mac OS and aren't updated as frequently--or promoted nearly as heavily--as Cocoa. So learning the Cocoa frameworks would require me not only to learn a new programming environment, but also a new programming language.

Learning a new programming language is a non-trivial process. It's taken me two years to develop a reasonable degree of proficiency with Tcl/Tk--to learn how to use the language to solve problems, and to develop a useful repertoire of techniques. I can now develop a Tcl/Tk application pretty quickly, and if there is something in the language I don't know how to do, it's fairly simple to read up on that aspect of the language and incorporate it into my knowledge base. But a new programming language puts you back at square one. Each language has a different approach to solving problems, and expertise in one language doesn't give you instant expertise in another.

I gained some insight into this issue this week when I was actually updating one of the few open-source projects I still maintain--a new version of AquaEthereal, a small program that launches a popular Unix-based network monitor with a double-click. I wrote AquaEthereal in Python, a language with similar capabilities to Tcl--and which also can be use with the Tk tools for creating graphical interfaces. I've dabbled in Python but have not found a compelling reason to delve into more deeply, because it's pretty much a peer to Tcl in terms of what it can do. I decided to try and give Python a greater workout with the new version of AquaEthereal by using Tk for the GUI rather than the simple built-in dialog boxes ("EasyDialogs") that the earlier versions of AquaEthereal used. What I found, though, frustrated me. Much of the advanced Tk stuff that I commonly use in my Tcl/Tk programs can't be used from Python, or is only available with a huge amount of work; Tk on Python lags far behind Tk under Tcl, where the cutting-edge techniques with GUI development are used. After putting together an ugly, incomplete, and much more complex version of AquaEthereal using Python/Tk, I finally gave up and reverted to EasyDialogs. It just didn't seem worth the time it would take for me to re-create, in Python, the advanced stuff I already use without difficulty in Tcl.

If I were still an open-source developer, doing this strictly for fun, I'd say fine--I can take as long as I need to learn new stuff. In fact, learning new stuff is one of the chief reasons to do open-source development. Python has Cocoa bindings, and they are highly recommended by some programmers. But learning Python, and Cocoa, would be incredibly time-consuming. Now my goal is to earn, not learn. And that means using what is most productive for me as a programmer--to keep improving my older applications and creating new ones.

It's a much simpler process for me to keep polishing and refining my Tcl/Tk applications to provide the best possible Mac user experience than it would be for me to scrap all the work I've done over the past two years and learn a completely new approach. If it's hard to learn Tk from Python--where the language is different but the GUI toolkit is nominally the same as Tcl/Tk--then I can only imagine how long it would take to learn Python/Cocoa.

[/software] permanent link