Even though I do my best to avoid using Windows, at all costs, unless it is a function of work I need to perform, I am bit impressed with how far IronPython is getting along. Even with recent news stories about ugly blue screens, and cries from a crotchety old man, about finally considering Linux or Mac, Microsoft is doing something right.
I recently starting reading Steven Holden’s blog, and in this post, he mentions some of the exciting developments in IronPython as discussed by Michael Foord. I have played around some with IronPython, and watched a presentation on IronPython at our local Python User’s group on it, recently. I wonder though, if Apple is falling a bit behind Microsoft in its support for Python as a first class development option?
I went to an iPhone Development talk today, which covered the webkit side of iPhone development, but I wondered if Apple would be forward thinking enough to beat Microsoft to the dynamic language battle, and do the iPhone SDK right. Doing it right, would be to think of the API in terms of Python and Objective C.
For example, are they going to allow pure Python code to write applications using the iPhone SDK? Apple has soundly, and routinely, beat Microsoft in the Operating System war, since OS X, but what about after that? What if the future is led by dynamic languages, and Microsoft is way ahead with IronPython?
I am not knocking the incredible hard work, and effort, that has been put into PyObjc2, and the further integration of XCode with Python. This is wonderful, and I cannot wait to start digging into PyObjc2, but does the PyObjc team have the same resources and support from Apple, that Iron Python has from Microsoft? If not, then maybe it should be a higher priority for Apple to look to the future and put more research, money, and energy into their support for dynamic languages, as this may be the next battleground for hearts and minds.
Personally, I would love to hear about Apple hiring a few Python people like Google did, and to start developing the Cocoa API with Python directly in mind, not as an afterthought. I cannot even imagine how many new, yet very experienced, developers this would bring to Cocoa, it would be mind boggling. While Apple is at it, they could abandon Applescript like they have done with carbon. If you look at GNU/Linux, it has an interesting near equivalent to Applescript Script Recorder in the form of Dogtail, where you can record and write UI events in Pure Python.
I personally think dynamic languages are an ever-growing part of the future, and I hope Apple continues their meteoric rise by taking a lead in adopting them.
Apple's problem in this domain is Applescript. Like all Apple products it has its evangelists but it has never suffered the compliment of imitation. They should have bitten the bullet and dumped AS for Python when they shifted to a Unix base. This would have had many benefits:
Freeing up a whole internal development team.
Making apps like Filemaker adopt Python rather than AS as their embedded language rendering them more powerful and more cross platform.
Allow me to have one less language to twist my mind around.
I am thinking that Ruby might become their love child. I am not a Rubyist but from the recent stuff I have read it seems that is the way of it. Java used to be their love child but seems to have turned into the red headed step-child of late. So who knows?!
I don't think Python had anything like the momentum back in the late 90s it has now. Back then I was still using Visual Basic and MS still thought it was the future.
Why doesn't Apple just adopt Mono as their preferred development platform and let MS do all the Python and DLR heavy lifting for them?
@Simon
I don't believe anyone on the Mac side would go for something culled from .NET mainly because there *could* be Microsoft entanglements with Mono. I know the arguments pro and con for Mono and I am not leaning on either side. I am saying that there is a perception that Microsoft could at any moment they wanted to strangle Mono.
Both python and ruby beat Java (in sofar as syntax is concerned).
Developer time is very important... not only because of money.
But because YOU can do more projects with an "easier" language (and Java has grown way too much...). (Perl is too ugly, and PHP is too limited on the web world)
I am a ruby guy myself, I have no ill feelings against python though.
I'd just wish python guys would stop attacking ruby and instead focuses on the older languages like perl that cant seem to leave their origins (Ruby left the "perlisms" worlds years ago, just some people still prefer to write ugly scripts, but that will be their problem in the long run)
BTW I think MS is winning this war, but MS has a multitude of other problems. It is really not liked much in the open source community. Not because they are unfair to MS, but because MS makes arbitrary standards, like purposely excluding Linux from the XNA Game world and .NET on the one hand, and buying Linux companies like Novell (Yes, Novell claims to be independent but I laugh my ass at such lies.)
Ultimately Linux is better as a DEVELOPMENT OS than any MS product right _now_ but Linux is soooo fragmented and these companies sit in key areas...
"I don't believe anyone on the Mac side would go for something culled from .NET mainly because there *could* be Microsoft entanglements with Mono. I know the arguments pro and con for Mono and I am not leaning on either side. I am saying that there is a perception that Microsoft could at any moment they wanted to strangle Mono."
I think I agree. Not so much about the con reasons against Mono (the implementation is clean) and also not that MS will sue the people away (I actually think they secretly endorse using it), but the biggest BIGGEST problem is that the people REALLY working on Mono are not "hobby" coders but paid coders.
And this is the single biggest problem. I do not trust the Mono team in this regard at all, sorry to say so.
So in essence, I agree with your conclusion. It would not be very good for Apple to embrace MS directly into their heart, even though I personally think Mono is a lot better than how Java went the road.
Wait a minute, with Leopard didn't Apple: Include scripting bridge and other niceties. Update Python, Ruby and Perl to fully support DTrace. Include Ruby on Rails with the OS. etc.
So how is Apple is falling behind while doing all of this, when Microsoft doesn't even include one such dynamic language with its OS?
As a side note:
I don't know why people insist on pulling Python into it. After working with it for over four years it became impossible to ignore Pythons problems. I held out, Python 3 will fix everything! Python 3 even worse, is a huge kludge, nothing like what was promised in the beginning.
Why should Apple buy into a language that is undergoing "big" changes, which they have little control over, and which is arguably worse than what they have right now for what they're doing?
Objective-C is a great language for system level stuff, but is dynamic enough to do really high level things. Now it has garbage collection etc. the only annoyance is the syntax.
I would love to see Apple invest in programming language development again, but after developing Dylan and then letting it go despite its advantages, I'm not sure it'll happen.
Either way, I get that you love Python :). I used to feel the same way, but that doesn't mean it's any good. It certainly doesn't mean Apple should start developing Cocoa with Python in mind.
"Is Apple Losing To Microsoft On Python Integration?"
Define "losing". Apple and MS are following two fundamentally different strategies here. IronPython is a reimplementation of CPython atop MS's Common Language Runtime; PyObjC is a bridge between ObjC/Cocoa and the existing CPython runtime. Apple don't have anything comparable to CLR, and even if they did the nature of Cocoa's APIs and behaviour is still sufficiently different to Python's to ensure there would always be some degree of mismatch betwen the two. Under the circumstances, a bridge is a reasonable compromise in best OS X tradition, and using an unmodified CPython runtime does have some benefits of its own, such as full compatibility with all third-party CPython modules and extensions.
I do agree that OS X would benefit from a very high level language running directly atop Cocoa - preferably something simple, powerful and efficient that supports JIT compilation and Erlang-style concurrency. Being first to supply a mainstream language with a non-sucky concurrency model in particular would provide a major leapfrog over the competition who are likely to be stuck with shared objects and threads for years to come. I suspect the most logical choice would be some sort of enhanced Smalltalk; it's a natural match for Cocoa and might adapt well for Actor-style concurrency. However, I'm doubtful that today's Apple would consider getting involved in such a degree of language development and support, nor am I convinced that the main body of Mac developers would be quite ready to accept such an un-Algol-ish language, so I'll not be holding my breath.
"Objective-C is a great language for system level stuff, but is dynamic enough to do really high level things. Now it has garbage collection etc. the only annoyance is the syntax."
haha. good thing syntax doesn't matter!
Noah: "While Apple is at it, they could abandon Applescript like they have done with carbon."
Won't happen - last time this idea got floated back in the Rhapsody days, the publishing industry threatened bloody revolt as they've far too much existing investment in AppleScript-based systems.
In any case, AppleScript itself is largely a non-issue in the grand scheme of things - it's a niche language that receives/consumes only modest engineering resources, and keeping it around keeps the publishing market happy and the non-programmer segment that wanders into it amused (at least for a while). Meanwhile professional developers simply ignore it as they've always done and will no doubt continue to do. There does remain the question of the underlying technologies - Apple event IPC, the Apple Event Object Model, and the Open Scripting component architecture - and where Apple should go with them, but that's another discussion for another time.
Noah: "If you look at GNU/Linux, it has an interesting near equivalent to Applescript Script Recorder in the form of Dogtail, where you can record and write UI events in Pure Python."
Nope, completely different concepts. Dogtail is analogous to Leopard Automator's recording feature, not AppleScript's.
OSA recording (what AppleScript uses) is an application-specific feature, relying on the application's GUI controller layer to emit Apple events representing the operations it's performing on the model layer; those events can then be resent to the application's Apple event interface to perform those same model operations without involving the GUI. Unfortunately, it's not widely supported because it requires extra work to implement and can be tricky to do well.
GUI recording (what Automator uses), like GUI scripting, operates at a much shallower, cruder, fragile level, recording the input to the application's GUI view layer. It's markedly inferior to OSA recording, but has one big advantage that it doesn't require any additional work by the application developer to support so pretty much comes for free ("worse is better"?).
@Toggd:
;) what can I say, good luck making C pretty. Objective-C is just C with a very expressive dynamic object model layered over the top. I'd like to say its the best of both words.
Python isn't without its warts, or do you really thing the horror that passes for OOP or FP in Python is pretty? If you do, you have no taste.
It may be worth adding that Objective-C 2.0 adds optional garbage collection, among other things. C, with a highly dynamic object system, and automatic memory management! It's almost enough to makes you drool. Not quite ;).
I too was disappointed in Apple's support for dynamic languages in Leopard. In my case, I was looking forward to some new perl development but it turned out not to be the case. The reasons why new perl features in OS X weren't ready lie mostly with the community and not with Apple but that points to the main issue: Apple's tepid support for dynamic languages. I think the reasons are many, including; not-invented-here and the overriding belief that Objective-C is better than any dynamic language. This is true in fact if you are developing for Apple machines. (I've written a bit about this by looking at the options for developing on the Mac.)
I think Apple's strategy to attract developers is to attract customers by building insanely great products - then the developers will follow using Apple's tools whether they like them or not. This just may work.
Objective-C is already a pretty dynamic language and with features like garbage collection coming in with Leopard it is that much more attractive. It's still a compiled language though and the garbage collection still has its own warts to contend with.
There is a major difference between Microsoft and Apple: Microsoft cares about developers, Apple does not. And to make things worse for Apple, they suffer from the 'not invented here' syndrome. They won't ever replace their own Objective-C and Cocoa with something coming from the outer world, and they simply don't care about developers switching to their platform. Just look at Apple's history with Java, which speaks volumes about the company's real attitude towards third party developers and foreign development tools and platforms.