On what people will write desktop apps with in the future
So a little bit ago Gruber posted about how in the near future scripting languages would be used to write desktop apps with performance sensitive pieces written in your C’s and C++’s. He followed it up with another post and Scott posted about it too. I spent a bit of time thinking about this but for some reason I had a hard time figuring out whether I agreed or not. My thinking came in two waves.
The first wave was taking the question (or I guess, statement) at face value. First I immediately stopped thinking about performance as an issue, since one tenet of the article was that hardware was becoming fast enough that dynamic languages perform just fine for most things and that for trouble spots you could code closer to the metal. So I thought about my problems developing using the stricter languages. The first was that one of my big issues is that there’s a lot of overhead associated in starting a project - looking at hello world in C or Java vs Perl and there’s a lot more work you have to do. For little web development projects, it just isn’t worth it. But for larger projects the cost of that overhead is essentially fixed and drops to nearly nothing as a percentage of the total amount of effort. So for large desktop apps, this problem seemed like it didn’t really matter.
Then I thought about that what the strict languages give you, which is less flexibility. And that is both good and bad. It is good because all that compile time checking cuts out a whole class of problem - it, in some ways, limits how bad you can make your program. Contrast this with the perl’s of the world where we’ve all heard too many times how awful the code is and how unmaintainable it can be. The flexibility that perl and dynamic languages in general provide give you a lot more rope to hang yourself with. But that additional flexibility also gives you the chance to write incredibly elegant and expressive code at the same time.
To me the rigor of static languages is a benefit when you have large projects and a large development staff. By imposing this level of strictness and catching many bugs at compile time it helps settle a sort a baseline standard. Dyamic languages fare better with a smaller development staff of excellent, experienced developers. I can really think of no situation I’d less like to be in than a large perl develoment staff with mediocre developers. My initial thinking about this was that I suspected that a lot of big companies were in the large number of developers category in which it was much more difficult to ensure the quality of each developer, so static languages could hold out as the languages of choice.
But I quickly came to my second wave of thinking on this. Ultimately this question is one of “this language is better than that language” that the interwebs has seen so much. Is Perl better than C? Is Java better than Ruby? Those questions need to be followed up with by For who? For what? There are many reasons why a company decides to go with one language over another some technical, some less technical. Does it already have a staff of developers working in a language? Is there one particularly influential person who wants to work in a particular language? Are there any libraries/frameworks already in existence that might help with the application in question?
That dynamic languages are now an option in developing desktop apps is without question and that’s great, it broadens the field. But will it take over? I don’t think so. Sure no one’s writing any cgi scripts in C anymore but Java and C# sure as heck still power a lot of web sites.
February 22nd, 2007 at 5:51 pm
What is a desktop app? Gruber’s article makes sense if the future were to stop in about three years and stay there, but it won’t.
What do people really actually use computers for? To say that it is to do things that involve desktop applications sounds like a shallow call to me.
Applications that require high performance will continue to require high performance:audio processing, video processing and still image processing will *never* run fast enough while these types of activities are moving on their own progressions (higher def, deeper media manipulation, 3rd parties innovating withing right plugin API spaces.) As a matter of fact I think that low level programming is going to be making a big comeback in these areas — single core CPU performance increases are slowing down… the next couple years are all about multicore innovation, which means really low level, high quality programming will be at a premium. Thread management is not (currently) the thing that high level languages (or numbskulls like me who use them) are best at.
OK, so that’s the high performance space. What about everything else? Well, for me at least everything else must be programmed to _work exceptionally well._ Sometimes that means fast, or convenient, or richly (like full implementation of all the oses apis and object types.) When I think apps that are written in high level languages this is not what comes to mind. Textmate, Quicksilver, Transmit, Omnioutliner and the like are very well crafted programs that take advantage of every bit of OSX api that they can to give me the best possible user experience.
So I have to think that performace and quality/integration are going to be the key decision points in the mind of a dev that is writing a desktop application for some time to come and all that leads to C/C++/ObjC type languages in my mind. I could be wrong.
Gruber is starting to sound like Dvorak to me. I must be getting old.
February 22nd, 2007 at 9:25 pm
You are totally way more smarter than me. I agree with everything you say. The area where I tihnk there is some wiggle room, though is in the space of using API’s. Taking your examples of OSX api, it seems to me that one could take other languages more scripty or dynamic and make bindings for those API’s and thus you could write apps in not ObjC but still reap the benefits of the OSX api.
February 22nd, 2007 at 10:00 pm
you are exactly right about the apis and the glue-layer. precisely.
your post makes me remember the last thing that I was really stupid-stunned-crazy about w/r/t to computers. (diggs for it) http://rubyosa.rubyforge.org/ RubyOSA is a direct and pretty (as in pretty like a girl) bridge/interface between ruby and the OSX AppleEvent API. The page says what it does very well, but the key thing is that this bridge was written such that it looks like Ruby from inside Ruby. Your iTunes library is an object, with reflection, all the normal Ruby object methods and it can be mucked with in the normal Ruby way.
Which means, that *services* are there to be written by anyone in a higher level language now. And not just services, but Services as in OSX’s OS-level services… which is pretty darn cool. But apps? Eh, what do I know. OSX’s big thing right now is their expansion/refinement of the Cocoa APIs. This is where so much of the cool stuff is happening… it seems to me that the more amazingly great an OSX app is the more it is using Apple’s code to handle it’s GUI/media management, data management and, of course integration with other apps. If Ruby or another high level language could get all up in there and stay Ruby or whatever and not just bring in ObjectiveC’s syntax (see Perl’s cocoa integration), well then anything is possible. But anything less than near-perfection, and, ideally some kind of support from the OS-vendor is going to put this stuff in a second class to the stuff written against Apple libs with Xcode, and I don’t see that kind of app (see pretty much all linux desktop applications) being the winning sort, at least on the Apple platform.
But, you are right and that is of course the way I want things to be. I think that would be fantastic.
February 23rd, 2007 at 8:31 am
Huh, I take your meaning. At what point does writing in a scripting language where all the actual cool stuff is happening in a compiled one actually support Gruber’s post. This is something I really have no capacity to think about since I never do any desktop app writing and don’t know squat about how much is contained in the API’s.
I am curious to know for all those Adobe guys, how much cool stuff is implemented in LUA and how much of that was just stringing together already cool libraries in a quicker way.