It didn't take long for word of REAL Software's Cocoa plans to get out. While I'm not a Mac programmer, I'm still excited about the idea because I've heard a lot of Mac programmers really wanting this functionality. And frankly, if it makes Mac support that much better, then it's a great idea.
However, it's unfortunate to see the FUD started (yet again) with some people's negative speculations. Already today I've seen more than a few emails on the NUG about how terrible it would be if we were to support .NET as another target (just like how Cocoa will be another target). Statements like that come across just as clueless as statements like "Cocoa is a terrible framework; it's a 20 year old concept that Apple is foisting on its users. It'll kill Apple and I'm glad for it!" You don't see anyone claiming such utter nonsense like that, now do you? So it makes me wonder why I see it about .NET.
Let me strike out with the clue bat. .NET is the way of the future on Windows and you better get used to it because it's not going away. Just like it's painfully obvious that Apple prefers Cocoa to Carbon and that all the cool new stuff comes in the form of Cocoa, Microsoft is only going to be adding stuff accessible via .NET and letting Win32 stick around for backwards compatibility.
So my take on it is -- I'm happy to see Cocoa support since that's Apple's way of the future. And I'm looking forward to the day REALbasic supports .NET, since that's Microsoft's way of the future. Technology-wise, both concepts have their plusses and minuses. But as developers, we typically have to ignore the technological differences between that which we're used to and that which is being pushed by the OS vendors. Because, like it or not, the OS vendors always win the shoving match.
Btw, I'm not saying that REAL Software does or does not have plans for .NET support at this time. What I am saying is that it makes me sad to people strike out against a technology for no good reason and without attempting to justify their statements in any way. If someone would follow their "oh god, I hope RS doesn't do .NET" message with logical reasoning, then I'll stop complaining and actually respond in fashion. But until then, I think I'm justified in say "huh? what are you talking about?"
So here's a place for discourse for those who'd like to respond. If you think .NET is a horrible idea as a platform to support, say so here and state your reasoning. I'm curious. :-)
Just promise me you won't put the whole .NET framework into every .exe ;))
I am an avid Mac guy and would love it if Apple would support .NET, because the technology is incredibly cool. Of course, it's years and years behind Cocoa in terms of the API, but the language featureset and everything is very nice. But it's just not in the cards.
REAL, on the other hand, would stand to gain a lot if they offered .NET as a target. .NET is sort of "cross-platform that really doesn't work" and REAL seems to be the only company that really means cross-platform by cross-platform. .NET is, however, cross-language that really works. And I like that.
I'd like to know what REAL means by Cocoa support though. Does this just mean that there will be a Cocoa-RB bridge, and it will be possible to instantiate objects across the language barrier? If so, how does this affect Carbon support (because it seems like it shouldn't)?
I defended .NET on the list. I agree with Steve, though--wait until the framework is shipped with Windows, so we don't have huge bloated apps.
I think it would be worth while to support .Net, just for the availabilty. However part of the reasoning I shun doing VB.Net now is justifying piggybacking a 25mb framework for a less than 1mb application. That's where RB does excel. There are lots of nice things about .Net, but I would think down the road RB will have alot in their framework to offer as well. I wish Microsoft would make .Net available on Linux and Mac, then that'd be cool for cross platform ability. Seems like they'd want to expand their reach.
For my $.02, as long as I can still deploy Win32 apps that don't need the .NET framework, I don't see any reason why RB shouldn't support .NET.
Frankly, I think REAL has to support .NET at some not-so-distant point in the future, if they want to continue deploying on up and coming versions of Windows. We're all headed down that road, eventually...
MS will never push a cross-platform version of .NET, unless it's their last grasp at staying in the game, for one simple reason...one word....Windows. Their flagship product. As long as they can keep the largest percentage of their developers building Windows-Only applications, we're stuck with .NET staying on Windows(I'm an MS user, more so than Mac...so I mean nothing bad by this). Now, let's think about what would happen if .NET showed up on Linux and Mac...All of these developers would then have the flexibility they need to code in the environment(meaning their favorite .NET language) that's comfortable for them, on possibly more stable OS's. That would be suicide. Honestly. Now, I know MS would never allow their .NET framework to give these developers more power on other OS's than it has on Windows...but where there's a will, there's a way. Someone would figure out, create a DLL to give it some OOMPH...something. And they're surely afraid of that. Not saying I know it all...just commenting. :)
-Anthony
Hey Guys, can we pile on Aaron yet?
@Steve -- I'll fight tooth and nail to ensure THAT stupidity never happens.
@Adam -- The frameworks have been shipping with Windows for a while now, and it's only becoming more prevelant as time goes on (read: in Vista).
@Tom -- you do realize that with RB, you're still requiring 2MB of framework code + almost 50 MB of OS supported code, right? It's the same concept with .NET; eventually the .NET framework will be as ubiquitous as the OS supported code.
@Daniel -- please tell me you were being sarcastic... Cocoa APIs are not exactly the most elegant things in the world to work with. Almost every API has about a quarter of a mile long name, and Objective-C is a very strange add-on to the C language. .NET APIs are fully OO (unlike Cocoa, which, as my understanding of it goes, is flat APIs like the Win32 APIs) which make them much easier to work with, I'd imagine. Note: I've done .NET programming, I've not done Cocoa programming. People are welcome to correct me if I'm wrong on my assertions.
What I seem to be hearing from almost everyone here is a very weak "yeah yeah, we know..." ;-) You may not like Microsoft, their business practices or even their APIs. But you have to readily admit that .NET isn't going away anytime soon. And as developers, you need to ensure that your applications are supported as widely as possible. So that means you're going to need .NET every bit as much as you'll need Cocoa.
Right now, .NET is at the same stage that Cocoa was 4 years ago. Sounds neat. You get some cool features from it. But it's not what anyone is used to, therefore it's scary to many people. The same thing happened when Apple came out with Carbon (to a lesser extent). So I can understand your fears on the topic. I just think everyone's goofy for being afraid of an underlying implementation detail. Let's face it -- if RB still supports OS 9 (which, to me at least, is like teaching Latin in schools), we aren't going to be jettisoning our Win32 code base anytime soon. So if we came out with a .NET target, it'd be just as optional as Mach-O has been for OS X.
Sounds good to me, I have no objections to .NET.
Aaron- I've worked a bit with Cocoa (but went with RB due to the need to be cross-platform in my workplace). I'd have to disagree with your assessment. Cocoa APIs are quite elegant to work with. Although the APIs have long names, the inclusion of argument names in the code allows you to know what each argument is when you read your code, unlike "myMethod(3)" -- what's 3 mean? With most IDEs providing autocompletion, the long names aren't a problem, anyway. Cocoa APIs ARE fully OO (and not a flat hierarchy), in fact are more OO in some ways than Java or C# APIs due to the additional flexibility allowed by dynamic typing. It's like getting the rapid development and flexibility of scripting languages like Ruby, but with (most of) the speed of a compiled language.
Sorry to change the subject, but I'm still trying to figure out exactly how this will work. Will the Cocoa support be a checkbox that tells REALbasic to remap REALbasic APIs to their respective Cocoa APIs, or will this let us use Cocoa APIs with the REALbasic language syntax? Can you clarify this a bit please, Aaron?
An afterthought:
Cocoa and Objective-C are not perfect (no computer language is). If there's anything I'd change, it's:
1. The separation of primitive data types and OO data types. I'd like to see integers, etc., also as objects.
2. The lack of _true_ language-supported private methods and shared properties, although there are ways to do them.
3. Too much need to drop down into low-level C code. I'd rather keep my code at a high level and pure objects at all times. All external libraries should have object wrappers.
@Mike: A bridge to use Cocoa objects in REALbasic would be kind of useless if REALbasic itself didn't use Cocoa. It's painfully obvious to me that the "Cocoa support" is a different target using Cocoa to implement everything instead of Carbon. It says it right in the press release:
"REAL Software is building a new REALbasic platform layer based on Apple's Cocoa framework."
Platform layer... as in one like the Carbon platform layer, or the one for Linux, or Windows....
I think I may have inadvertently started the .NET ruckus on the NUG :P
Someone insinuated that concentrating on Cocoa support would take RS' focus away from fixing bugs, so I merely stated "at least they haven't announced REALbasic .NET yet!" (which would no doubt have the same effect). This comment then got misconstrued and quoted out of context. I was just ripping on the "features vs. bugs" crowd and suddenly became a Mac Nazi, when that's far from
the truth. Hell, my only piece of shareware to date is a Windows app!
I, for one, would not cast aspersions on support for .Net. I want Rb to run well on all platforms. If .Net is the future of the PC, then I'd love to see Rb support it.
I would like to see those of us who #1.) have probably never done what I am suggesting and #2.) Throw Their Skywalkerisms at new technolgies to be forced for a decent period (week, month, year) to go back to the days when computing wasn't done on a desktop, it was done on in a Gym-sized room. I think most people who throw out ".NET Sux" or "Cocoa = Crap" fail to remember where it is that we came from, or how much worse it was to do certain things prior to that technology being devised, OR how difficult it is to develop future working technologies, including programming languages.
If a technology truly sucks, it will die. Look at all the old IBM PC's, Atari 800's, Tandy's, and TRS-80's that clutter landfills, most vaporware (remember OpenDoc, MacHeads?) that die before making a hit with customers, and most devices (anyone remember the Orb?) that never make it. And Yes, some stuff, like the Apple II and Commodore 64, end up having a good long life (especially by today's standards), but even good technology gets replaced or dies off eventually. While they're here, though, we only have three choices: Make do with what we have, go find something else that does what you want it to, or wait for the next big thing to happen. You don't like .NET or Cocoa? Use what you do like. Pretty simple, huh? :)
@Aaron: I strongly disagree with your assertions about Cocoa. To start with, Objective-C is a very nice and elegant language. The syntax is disturbing at first, but once you use it for a while you really grow to like it. The Cocoa API are everything but "flat". Cocoa is not an API but an OO framework. There's nothing flat about it. Its true power lies in the patterns and mechanisms it enforces. Actually it's amazingly powerful. You can do complex things in very few lines of code, and it's about the best framework I've seen on any platform. Some people can't get use to the [ ] syntax which is the equivalent of -> in C++ or . in RB. That's fine, a language can't suit everyone.
.NET itself is not bad -- at least, much better than the prehistoric MFC. But the major drawback is the garbage collector (who wants his app to crawl during several seconds because of the GC?) and the JIT stupidity. C# itself is a very nice language, much better than I expected. If it was fully compiled to native code, it would be good.
But all this is moot anyway. What RB developers care about is the platform features RB exposes to them. My opinion is that a Cocoa-based RB framework will be a better OS X citizen than the actual Carbon-based one. Most new technologies on OS X primarily target Cocoa, so it's good to see RS going in this direction. I don't feel concerned about the framework size itself, it shouldn't be much larger than the current one.
I've been working for 18 years with various languages and frameworks. Cocoa is the best thing since sliced bread. .NET is the best thing that happened to the clunky Windows platform. RB is the best thing that happened to people who want to develop cross-platform apps ;-)
YMMV
Yeah, but what exactly does cocoa support mean ? Is it totally invisible to me as a Realbasic programmer ? Will it make my apps look smoother (the way cocoa apps look compared to carbon) ?
The latter thing would be fantastic. I would just like it if someone would explain it a little (from RS), so peoples imagination doesnt run wild on the NUG and I have to download 1000 e-mails with ".net is crap" (not true) and worse.
Just a brief explanation would do. Just my 2cents.
@Aaron Yes I realize there's some baggage with RB as well. But I don't think(at least seems like)its that big compared to .Net. Plus another nice reason to use RB, right? I like some of the .Net stuff, however Im not well versed in all of it, so I really cant make arguments either way. I just know when it comes to speedy apps with not alot of bs to get them up and going, RB seems to work the best. On very large projects with countless snazzy features(minimal code, most stuff just "there"), VB.Net with 3rd Charting/Grids is hard to beat.
Cocoa support is a great idea, let me have a try! ;-)
Arne
@Tom -- the baggage for .NET is more than the old baggage if you look at the whole picture because .NET relies on the Win32 APIs as well. As for RB's baggage, the majority of it is already distributed with the OS. Eventually, with .NET, that'll be the same song.
@Trausti -- More information will be forthcoming is what I've been told. Keep in mind, I don't do much Mac stuff aside from low level code (serial, sockets, threads, etc), so I don't have that much information in the first place. :-P
@Florent -- wait, every time I see Cocoa code, I see all these terribly long calls to things like NSFoobarDoesBazWithWhizbangWhileDrinkingYourBeer. Basically, I've only seen verbose APIs and never anything which looks very OO. So you're saying that Cocoa has classes with inheritance, polymorphism and the whole nine yards, with reasonable OO syntax (like the dot operator and things like that)?
I think I'm going to have to go do some research to see what this is all about, since it's painfully obvious I'm clueless on it. :-P
@Aaron -- You may find it interesting to browse a Core Data tutorial. That would probably show you the bulk of what's cool, as it's exceedingly high-level and very OO. The drawbacks really are just the strange calling convention and the manual garbage collection. The Objective-C crowd have long asserted that the language is better than C++ because of how minimal it is, but ignore them. Like anyone cares how "minimal" the syntax is. In practice, some people like it and some people hate it, but it's just a thing like any other.
My objections to the .NET API are exemplified by the difficulty of making a document-based application. To do such a thing with Cocoa, you make an NSDocument subclass to handle the model and make the interface in the Document NIB file. You implement two methods for serialization and deserialization and the system provides New, Open, Save, Save As, etc. It handles the Window menu. It handles making new windows and keeping the model with the Window. It handles the "changed" bit for you (the dot within the close button). With a tiny bit of work, it will handle Undo/Redo for you.
It would be really awesome if .NET had this kind of high-level API, but the best I've seen was the third-party Genghis library. Cocoa is full of examples of this kind of thing. Core Data is really just the most high-level API we have right now. The inheritance heirarchy might look flat because there isn't as much subclassing going on as dynamic invocation, but this is just the way the API was made, not a limitation of the language, which is OO analogously to RB albeit without operator overloading.
@Daniel -- thanks for the info!
I think the nasty taste about .NET comes from a few places. Two I haven't seen explicitly mentioned are:
1. For quite some time, everything coming out of Redmont had a .Net label (I think Starbucks was selling a double-whipped caramel .net-accino). The created some inevitable confusion about what .NET was, even within the company.
2. VB.Net changed VB so radically that it really pissed off the VB crowd (much to REALSoftware's glee). The language changes don't have much to do with .NET, but that VB.Net label pulls it in.
Of course, these have nothing directly to do with the .NET framework, but it rubs off for some reason.
@Brady -- I disagree about VB.Net. I think the language changes have everything to do with .NET: there was simply no way to integrate the .NET library facility into the existing language. By putting everything into .NET, Microsoft has said that language agnosticism is the key. Ironically, we see Apple doing the opposite by supporting Java very poorly and in general not improving the plight of Cocoa developers using other languages. Indeed, they couldn't care less; Objective-C is "the language" and you either speak it or you suffer.
I agree, the Windows situation really couldn't be any more ideal for REAL. Capitalize on Microsoft's .NET blunder with VB immediately, wait a few years and then target .NET and capitalize on Microsoft's .NET success overall. The Microsoft motto seems to be, it doesn't matter what the language is so long as the platform is Windows. The REAL motto seems to be, it doesn't matter what the platform is as long as the language is RB.
How interesting that these three companies can thrive together while making such diametrically opposed decisions!
@Trausti - +1. Looking forward to the response.
RB.Net? I remember the first days of ubiquitous .Net.... Language.Net just had to mean Language+Visual Studio. That, for starters, would be most welcome.
As for RB to CLR. Quite handy. Swordfish? Done. Franly, that's where the RB strategy of converting VB programmers is lacking. VB/ASP/ASP.Net -> RB/ASP/ASP.net. (But then again, I prefer BASIC stay away from Web Frameworks in light of the dynamic goodness of Python, Ruby, etc.)
Aaron, the research wouldn't hurt. I've heard both good and bad things about Cocoa. What looks good/bad on paper ain't always the case.
Don't forget, there's Cocoa, the framework, and Objective-C, the language. Object-C is very much object oriented, though I don't like it as much as C++. There are some interesting things about Objective-C that make it worth a look, but its memory model is the worst thing about it. Basically, you've got the C/C++ approach, which is the developer takes care of his/her own memory. There's the REALbasic/Java approach, which is that the "system" takes care of the memory. Then there is Objective-C, which takes care of the memory most of the time, but not enough of the time that a developer can stop worrying about it. If I have to worry about memory, I think I'd rather just use C++ and worry about it all the time.
Will, Apple is working on automatic garbage collection for Objective-C. It will be optional for the developer to use or not use it.
"Right now, .NET is at the same stage that Cocoa was 4 years ago."
Do you think that will be enough time for M$ to copy the jewels from Cocoa into .Net :-D
And yes to Cocoa support, spoil the Mac users a little more (they are allready spoiled upto their bones, but are still nice people). in the end RS promised cross-platform RB, so you will have to get a couple of extra horses to pull out some equivalent beauties for the windhose and Linux-user.
@Aaron: Objective-C is a very dynamic OO language. Yes it has classes and inheritance. Writing [object doThisWithParam:1 andAnotherParam:2] equates to object->doThis(1, 2) in C++. I find the Obj-C syntax much clearer at it exposes the parameters very clearly. Besides, dynamism is the big strength in Obj-C. There are "categories" which are class extensions the same way "extends" is in RB. You can extend any class loaded in your runtime, whether it's yours or the system's. Categories act like dynamic vtables, if you want to look at it this way. Also, there is strong introspection: not only can you inspect an object and its methods, but you can also add / replace methods -at run time-. You can also bypass the vtable by getting a direct pointer to the function to call.
@Will: contrary to you, I think memory management is very well done in Obj-C. First, objects are all refcounted. This means an object will go only when its refcount reaches 0 (same in RB). But additionally, there is NSAutoreleasePool. All objects that you put in an autorelease pool are finalized when the autoreleasepool that was current when they were marked "autorelease" goes away. This is a very nice way to manage objects, even though many developers seem to be stumbling on this (it requires to change the way you think your code, but I think it's for the better)
An interesting experiment would be for you (Aaron) to take an evening, a six-pack, and XCode and see how easy it is for you to write a Hello World application using Cocoa.