Comments on: On what people will write desktop apps with in the future http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/ escape colon w q Sat, 22 Nov 2008 07:14:01 +0000 http://wordpress.org/?v=2.5.1 By: felix http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-57 felix Fri, 23 Feb 2007 13:31:23 +0000 http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-57 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. 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.

]]> By: monnrj http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-54 monnrj Fri, 23 Feb 2007 03:00:49 +0000 http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-54 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. 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.

]]> By: felix http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-53 felix Fri, 23 Feb 2007 02:25:09 +0000 http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-53 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. 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.

]]> By: monnrj http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-52 monnrj Thu, 22 Feb 2007 22:51:24 +0000 http://comments.deasil.com/2007/02/22/on-what-people-will-write-desktop-apps-with-in-the-future/#comment-52 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. 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.

]]>