Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Xcode Update Gives Objective-C Garbage Collection

timothy posted more than 8 years ago | from the alternate-tuesdays-bin-by-curb dept.

285

William Henderson writes "That's right, if you haven't read it for yourself yet, Objective-C '2.0' now supports garbage collection. I foresee a great, huge, gigantic debate about to ensue, and a lot of java-heads sparking 'I told you so'. Why not start it here on slashdot?"

cancel ×

285 comments

Sorry! There are no comments related to the filter you selected.

Hacks and Novices Rejoice! (0)

Anonymous Coward | more than 8 years ago | (#15862031)

"Garbage Collection is cool cuz you don't have to, like, remember to delete stuff"

Shudder.

Re:Hacks and Novices Rejoice! (3, Funny)

profet (263203) | more than 8 years ago | (#15862278)

"Garbage Collection is cool cuz you don't have to, like, remember to delete stuff"

Shudder.

posted wirelessly via abacus and smoke signals

Re:Hacks and Novices Rejoice! (2, Insightful)

kaffiene (38781) | more than 8 years ago | (#15862364)

*sigh*

I grew up programming in assembler and C. Even dinosaurs like myself know that memory allocation is not an issue for 99% of software projects.

Get with the new century dude.

Re:Hacks and Novices Rejoice! (1)

botik32 (90185) | more than 8 years ago | (#15862676)

memory allocation is not an issue for 99% of software projects.

Well, it should not be, unless it is poorly implemented (I hope). The Java GC leaves java apps out of my desktop, and will probably keep so for the next 5 years.

Hmm, on the second thought, I think programmers are to blame for some of it, too. The fact that you can easily allocate stuff on the heap does not mean you should do it ALL the time, in an app that would be running for days (like azureus). You would be better off allocating a buffer once, and pass it down many times, instead of allocating stuff ad-hoc and returning it up the call chain. It may (gasp!) use more memory, but will perform better in the long run. From what I have seen, defragmentating memory is a cpu-consuming task; it would be stupid to rely on an expensive maintenance process to keep your program running.

In C you get to deal with memory issues directly, and that has a huge benefit: you have the chance to spot the patterns that fragment memory over time, early. Unfortunately, Java lets you do whatever you want. In this regard, it is worse than C.

Get with the new century dude.

Thanks, but no, thanks :).

Re:Hacks and Novices Rejoice! (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15862375)

You just flunked the engineering interview.

Go back to coding in your basement clown.

Re:Hacks and Novices Rejoice! (0)

Anonymous Coward | more than 8 years ago | (#15862631)

Just wanted to point out that profet was making fun of the parent of his comment...

Re:Hacks and Novices Rejoice! (1)

cappadocius (555740) | more than 8 years ago | (#15862944)

Hacks and Novices Rejoice!

Oh no, now hobbyist Java programmers like me will be able to more easily learn Objective-C and write native Mac apps for our own amusement that you will never have to use or even acknowledge. I feel your pain.

I told you so! (0)

Anonymous Coward | more than 8 years ago | (#15862039)

But it's about time if you ask me!

...... Garbage Collection.... (-1, Flamebait)

Amouth (879122) | more than 8 years ago | (#15862044)

i am sorry if you can't remember to free your own damn memory then.. why are you writing code???/

and if it is implemented anything like java's garbage collection we... good luck

Re:...... Garbage Collection.... (1)

MyDixieWrecked (548719) | more than 8 years ago | (#15862062)

I'm confused... I thought that ObjC did have garbage collection...

isn't that what the Autorelease pool is for? or is this more automatic?

Not sure if you're joking, but... (3, Informative)

Space cowboy (13680) | more than 8 years ago | (#15862169)

An autorelease pool is a promise that when the pool is released, any objects with a retain-count of 1 will be released. So, you create your objects and call the autorelease method on them:

          NSAutoreleasePool *pool = [NSAutoreleasePool new];
          NSObject *myObject = [[NSobject new] autorelease];

All that happens is that the object is added to an internal array, and when the pool itself is released, it calls [release] on all the objects in the array. I guess it actually calls [release] on the object as soon as it's gone into the array as well, or the object's retain count would be 2 when the pool was released (one for the 'new', one for the insert-into-array). So,

        [pool release] ... clears up after you, but it's no garbage collection, it's just a convenient way of using retain/release.

ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.

Simon

Re:Not sure if you're joking, but... (0)

Anonymous Coward | more than 8 years ago | (#15862263)

The GNU runtime has support for GC for a long time before even Apple was deciding to add it to their runtime (NeXT).

Re:Not sure if you're joking, but... (1)

MyDixieWrecked (548719) | more than 8 years ago | (#15862835)

not joking. just asking for clarification.

I never really read up on garbage collection, but from the way it was originally explained to me, when I learned ObjC after learning Java, I kinda grouped the autorelease pool in my mind with Java's garbage collection.

I guess ObjC's is just a kind of slapped together GC-like implementation?

That is incorrect. (1)

porkchop_d_clown (39923) | more than 8 years ago | (#15863170)

Anything in the autorelease pool with a retain count of *zero* is automatically freed on the next invocation of the main event loop.

In other words, I don't know what this "real" garbage collection brings to the party.

Re:...... Garbage Collection.... (3, Insightful)

repruhsent (672799) | more than 8 years ago | (#15862065)

If people like you were in charge of innovation, we'd all be running Commodore 64s with hacked CP/M.

Re:...... Garbage Collection.... (0)

Anonymous Coward | more than 8 years ago | (#15862213)

That's my main computer you insensitive clod!

Re:...... Garbage Collection.... (1)

Amouth (879122) | more than 8 years ago | (#15862340)

and your point is?????

Here's my contribution to the debate. (4, Insightful)

mccalli (323026) | more than 8 years ago | (#15862051)

Fantastic.

I really do feel that manual memory management in most apps is now redundant. i fully accept its need in some cases an indeed I've advocated 'regressing' an app at work, which was ported from C to Java, back into C again to use manual memory management for performance. But that app's an exception - sub-millisecond performance is required. How many day to day apps need that?

I can feel myself waiting a few months, then ordering an updated Objective C coding book to pick this language up now.

Cheers,
Ian

Re:Here's my contribution to the debate. (2, Informative)

Rakshasa Taisab (244699) | more than 8 years ago | (#15862240)

On the other hand, I feel automatic memory management is redundant in most situations. Warm fuzzy kind of feelings.

Re:Here's my contribution to the debate. (1)

argent (18001) | more than 8 years ago | (#15862343)

I feel automatic memory management is redundant in most situations.

Yeh, let's bring back allocating memory on a big sheet of graph paper on the wall of the coding pen!

Re:Here's my contribution to the debate. (1)

TheSalzar (945163) | more than 8 years ago | (#15862809)

sum times computers arnt the easyest solution

Re:Here's my contribution to the debate. (1)

CoughDropAddict (40792) | more than 8 years ago | (#15862813)

i fully accept its need in some cases an indeed I've advocated 'regressing' an app at work, which was ported from C to Java, back into C again to use manual memory management for performance. But that app's an exception - sub-millisecond performance is required. How many day to day apps need that?

Every app that ever interacts with a user. It is never acceptable for an app to stop-the-world while it does something that I (as a user) do not care about. I get enough spinning beach balls as it is.

Re:Here's my contribution to the debate. (2, Informative)

mccalli (323026) | more than 8 years ago | (#15862915)

OK - here's a comparison. App is a multi-threaded market data-driven app. Server-side, so no GUI. Uses around a gig to gig-and-a-half of RAM. Idea is to read in market data, process and response to it in sub-millisecond time.

"Stop the world" garbage collection for this app usually takes less than 13ms. And it very rarely occurs - you can code appropriately for a garbage collector too, and minimise it ever reaching this level. Usual GC times is between There isn't a human alive that could interact with a GUI in 13ms. So no, you need sub-millisecond performance 'every time you need to interact with a user' is not actually true.

Cheers,
Ian

Re:Here's my contribution to the debate. (1)

mccalli (323026) | more than 8 years ago | (#15862927)

Argh. Meant "Usual GC times are between <1 and 3ms". Missed the fact it would start a tag.

Cheers,
Ian

number of CPUs? (0)

Anonymous Coward | more than 8 years ago | (#15862971)

I assume you are talking about a server machine. I was just wondering, how many CPUs does it have, as well as the CPU cache size. Server machines != typical desktop intel box.

Re:Here's my contribution to the debate. (1)

CoughDropAddict (40792) | more than 8 years ago | (#15862990)

"Stop the world" garbage collection for this app usually takes less than 13ms.

"Usually" isn't good enough, not when "usually" just made you drop a video frame or overrun a sound buffer. Out of curiosity, though, what language is this? Experiences I have had with Java involved watching the GUI freeze when garbage collection happens. I would be happy to hear that GC wait times had indeed gotten this fast, though it's also likely that your fast GC is a result of your particular allocation patterns.

Re:Here's my contribution to the debate. (1)

bar-agent (698856) | more than 8 years ago | (#15863054)

"Usually" isn't good enough, not when "usually" just made you drop a video frame or overrun a sound buffer.

Yes, but not every app a user interacts with has video or sound. And, doesn't the OS run most video and sound processing? Just because your own app is garbage-collected, that does not necessarily have an impact on how the OS does what it does.

Re:Here's my contribution to the debate. (1)

Breakfast Pants (323698) | more than 8 years ago | (#15863480)

'Every app that ever interacts with a user. It is never acceptable for an app to stop-the-world while it does something that I (as a user) do not care about. I get enough spinning beach balls as it is.'

You realize that a call to malloc is nondeterministic don't you? You get the same problem with manual memory management, there is just a lower average time; but 'stop the world' still happens.

Re:Here's my contribution to the debate. (1)

bsartist (550317) | more than 8 years ago | (#15863041)

I really do feel that manual memory management in most apps is now redundant.
Yes, it is. But, the "traditional" memory management in Cocoa is already at least 90% automated. What it amounts to is a few boilerplate calls in accessor methods. Xcode has been able to automatically generate simple accessors for quite some time, and for not-so-simple use there's Accessorizer.

The biggest stumbling block I see most newbies having is that a) they're accustomed to not doing any memory management at all in Java and assorted scripting languages, and b) they've heard all sorts of horror stories about how difficult MM is. So they tend to over-react and over-think it, and as a result make it far more complicated than it needs to be. Instead of simply following the simple design patterns suggested by Apple, they sprinkle -retain and -release messages throughout their code, and then try to figure out what's wrong by using the debugger to examine the reference counts directly.

In short, the problem with today's Cocoa memory management isn't that it's difficult to use as designed, it's simply that too many people won't read and follow the guidelines for using it as designed.

Re:Here's my contribution to the debate. (-1, Flamebait)

Listen Up (107011) | more than 8 years ago | (#15863483)

What?!? The Java Garbage Collector can be manually controlled. You are in charge of an entire project and didn't know that? And you converted from C to Java? A procedural language to an OO language? And then back again? Who the hell hired you?

Bullshit.

Once you learn how to program, start by working under experienced developers in private industry for a while, then try coming back here and writing an educated post that isn't full of complete bullshit.

uh, neat.... (0, Flamebait)

DrunkBastard (652218) | more than 8 years ago | (#15862054)

Well, let me be the first to enter the, "Guess I'm not using Objective-C" camp. Adding garbage collecting to this language is just a continuation of the "throw more resources at it and it'll all work just fine" mentality that exists in modern application design. Yes, the ease of use of garbage collecting has it's uses for the quick fire and forget projects and one time use apps. But other than that, bah I say!

In response to the naysayers... (5, Informative)

Hootenanny (966459) | more than 8 years ago | (#15862072)

AFAIK, garbage collection may be enabled or disabled as a compiler option. If you don't like it, then just disable it and carry on.

Re:In response to the naysayers... (2, Insightful)

cnettel (836611) | more than 8 years ago | (#15862398)

For now, but it seems to me that interoperability with a library that used garbage collection would require you to use it as well, or suffer some real pain while trying to work out the memory ownership semantics of a library that simply wasn't designed in those terms.

Library only GC (1)

SuperKendall (25149) | more than 8 years ago | (#15862824)

It seems to me that since it is a compiler option that if a library required it, it would be compiled to do so and you could simply use it from your non-GC code directly. It's not like Objective-C is suddenly running in a VM, the compiler is adding code to effect the GC.

Re:uh, neat.... (2, Insightful)

ronanbear (924575) | more than 8 years ago | (#15862104)

I'm quite happy that many programmers will be spending their time on application design rather than debugging memory leaks. Sure there are those out there with years of C experience who don't need this feature and I'm happy for them. They can continue to code the way they always have and they'll still be in demand. But there's another group who will find this really useful.

At the end of the day Apple aren't really catering for the top programmers here who will write good programs no matter what. It'll help the rest write better programs though.

Re:uh, neat.... (1)

DrunkBastard (652218) | more than 8 years ago | (#15862155)

good point. A co-worker and I were just talking about the already existing "garbage collecting" mechanisms in Objective-C regardless of this latest update, and I was simply hitting a wall about why the pseudo garbage collection existed, because I couldn't imagine such poor memory management to begin with, or a program design that would allow for this poor memory management. Like you said, if you were brought up in programming doing things cleanly and efficiently, than you don't need it, but for those who's first taste of "real" (and I use this loosely) programming was java or similar languages, than they missed out on the keep it lean, keep it clean paradigms.

Re:uh, neat.... (1)

mrchaotica (681592) | more than 8 years ago | (#15862720)

Here's the funny thing, though: Objective-C is supposed to be like SmallTalk... and SmallTalk has garbage collection!

Remember, garbage collection isn't just Java. It's been around much longer than that in lanugages like SmallTalk and LISP. And as with everthing except ActiveX, it's good for the uses it's designed for.

Re:uh, neat.... (5, Insightful)

jfengel (409917) | more than 8 years ago | (#15862196)

It isn't even a question of how good a programmer you are. It's a question of how good a programmer everybody on the team is. And "team" includes every library you use.

When memory is passed across the boundary from one developer to another, you need some kind of mechanism to track who is going to free that memory, and under what circumstances.

Garbage-collected languages make that contract fairly clear. (But not infinitely clear; there are still ways to accidentally pin objects in memory even in a GC language).

In C we got used to putting in comments saying, "I'm passing you back a static structure, so I'm not re-entrant" or "This thing is malloc'ed so free it when you're done" or "You have to pass in a reference to that object and I'll fill it in". As long as discipline is followed the program works brilliantly (no GC overhead) but if any developer anywhere on the project misreads any single one of those comments, you're completely and totally doomed.

There is still software to be cranked out by one guy who can keep the entire thing in his head, but software requirements for most things are too big for just one guy. Even the uberest of uber-hackers is limited by the dumbest guy on his team, especialyl when that dumbest guy (even if he's pretty damn smart) nulls out a memory location that wasn't finished yet.

Re:uh, neat.... (2, Informative)

pestilence669 (823950) | more than 8 years ago | (#15862670)

Yes, but in Objective C there ARE standards for who frees memory. Whomever allocates an object must free it. This seemingly difficult methodology is accomplished with auto_release pools. When you return a new instance of an object, you send it a release message, which adds it to the auto release pool. Once your event loop is complete, every object in the pool is destroyed. If the recipient wants to keep a returned object around for a little bit longer, it sends it a retain message, which removes it from the pool. In practice, this method is exceptionally simple to use. The overhead is larger than manual destruction, but much less than garbage collection. Autorelease pools are great because object destruction is delayed until the next event loop iteration. This means that lazy access to the object, immediately after release, will work without penalty.

Re:uh, neat.... (1)

pestilence669 (823950) | more than 8 years ago | (#15862708)

Correction: You send objects the "autorelease" message to use autorelease pools. "release" is the same as "delete object_here;" Otherwise, the general idea of my posting is the same.

Re:uh, neat.... (1)

feijai (898706) | more than 8 years ago | (#15863395)

"release" is the same as "delete object_here;" Otherwise, the general idea of my posting is the same.
"Release" decreases the reference count on the object by 1. If the count goes to zero, the object is freed. Else it is not.

Bring back the good old days! (1)

argent (18001) | more than 8 years ago | (#15862305)

Bring back the good old days, when you could write code like this and MEAN it!
inter lda i
      phi w
      lda i
      plo w
      lda w
      phi p
      lda w
      plo p
      sep p
      br inter
Or if you're a quiche eater...
inter mov (i)+,w
      jmp @(w)+

Your knowledge of GC is 10 years out of date (3, Insightful)

jbellis (142590) | more than 8 years ago | (#15862329)

Modern GC is *faster* than hand-coded free calls in 90% of situations.

"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion." -- http://en.wikipedia.org/wiki/Garbage_collection_(c omputer_science) [wikipedia.org]

--
Carnage Blender [carnageblender.com] : Meet interesting people. Kill them.

Re:Your knowledge of GC is 10 years out of date (2, Insightful)

cnettel (836611) | more than 8 years ago | (#15862431)

True. The most adverse effect of Java-like GCing is not the allocation method, it's the amount of allocations, and the references to wherever and whatever all the time. In C/C++, you can really store a string locally with an object. If you do it smart, you can even allocate the memory for several strings with dynamic size and still have guaranteed locality and a single heap allocation. In Java (or C#), you're almost bound to have several references, each with a separate vtable reference and so on. Structs in C# is a step in the right direction here, because they remove a tiny bit of the paradox that you have to choose between a nice OO representation or roll your own memory manager with no other primitives than, essentially, bytes.

And, to some degree, GC is responsible for the fact that it's impossible to do nice data structures on your own, as a GC needs to be able to track and relocate references. To do that, it has to grok your data structure.

Re:Your knowledge of GC is 10 years out of date (2, Interesting)

feijai (898706) | more than 8 years ago | (#15863422)

The most adverse effect of Java-like GCing is not the allocation method, it's the amount of allocations
A modern Java virtual machine uses a compacting GC. This allows it to perform the following super-duper, evil, highly intensive allocation procedure for an object of N bytes:
  1. Increment the heap pointer by N.
  2. Bzero those N bytes (if necessary).
  3. Return the old heap pointer.
In what way exactly is this more expensive than malloc? That's right, it's far less expensive than malloc. It's just as expensive as stack allocation in fact.

Where GC falls down is in the (slight) cost of deallocation of those tiny, short-lived objects and in not being able to take advantage of cache coherency for short-lived objects well -- though it's great for long-lived objects and caches. But virtual machine techniques are improving every day. Soon we'll have object analysis in most VMs to determine if objects can be stack allocated or not.

Re:Your knowledge of GC is 10 years out of date (1)

feijai (898706) | more than 8 years ago | (#15863429)

Let me clarify this: number of allocations is fairly immaterial since allocation cost is the same as just doing a stack allocation. It's the number of deallocations and moves that gets ya.

Re:Your knowledge of GC is 10 years out of date (3, Interesting)

CoughDropAddict (40792) | more than 8 years ago | (#15862863)

Modern GC is *faster* than hand-coded free calls in 90% of situations.

Greater throughput at the expense of latency. GC stops the world.

"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion."

I would like to offer you a bank account with 50% interest amortized over 500 years. I regret that you will not receive your first interest payment until the 500 years are up.

The point is that amortized performance gives you no control over when you're going to take the hit. That's OK if you only care about throughput.

Re:Your knowledge of GC is 10 years out of date (0)

Anonymous Coward | more than 8 years ago | (#15862973)

Actually, there are GC techniques that do not involve
"stopping the world" ... It's kind of unfortunate
that no one seems to have heard about generational
garbage collectors; they've been around for a while...

Re:Your knowledge of GC is 10 years out of date (1)

CoughDropAddict (40792) | more than 8 years ago | (#15863005)

Generational collection stops the world. Perhaps you are thinking of concurrent collectors?

I'll get more excited about concurrent collectors when they find their way into the mainstream and prove themselves.

Re:Your knowledge of GC is 10 years out of date (1)

DataPath (1111) | more than 8 years ago | (#15862903)

Unfortunately for you and your theories, for any major library, toolkit, driver, or anything else necessary to make an operating system remotely useful, you need low latencies, good single-point i/o, determinism. You'll never get that in garbage-collected code.

Re:uh, neat.... (1)

nacturation (646836) | more than 8 years ago | (#15862348)

Adding garbage collecting to this language is just a continuation of the "throw more resources at it and it'll all work just fine" mentality that exists in modern application design. Yes, the ease of use of garbage collecting has it's uses for the quick fire and forget projects and one time use apps. But other than that, bah I say!

No kidding. What's next... automatic IP packet collision avoidance? No thanks, I roll my own.
 

Re:uh, neat.... (1)

paulxnuke (624084) | more than 8 years ago | (#15862688)

Well, let me be the first to enter the, "Guess I'm not using Objective-C" camp

I'd love to find a way to make a living with Objective-C, if I can turn GC totally off (I assume that's possible.)

I've tried C# and managed C++ and hated both: one reason was the atrocious coding style they encourage. Objective-C is a particularly elegant and powerful C, which makes the idea even uglier, like mud wrestling in a tuxedo.

Kludging a GC library into any version of C is like pulling a U-Haul with a race car, not because it slows things down (it doesn't, in most cases) but because it doesn't fit. C++ is not about being sloppy because a runtime lets you avoid learning how to use the language. Leave GC where it's needed and serves a purpose: functional languages, scripting languages, lisp. Bolting it on to C does nothing but encourage incompetents to remain incompetent instead of moving on where they belong, be it a higher level language or McDonald's. Whoever said C++ (or any other language) has to be accessible to everybody? They tried that with VB and Lingo, and in both cases we got a few more bad programmers, the same crowd who still didn't get it, and a crappy new language to sell books.

Yell troll if you will, but given enough experience to be paid for coding (less than it takes to play most musical instruments or learn a natural language well), C++ memory management just isn't that hard, and not getting it right or refusing to try suggests a the kind of attitude I wouldn't hire. Qualified coders are going to be rarer every day the way things are going.

Technical details needed! (3, Insightful)

Anonymous Coward | more than 8 years ago | (#15862084)

We developers will need far more technical details before we can even consider using this functionality in our applications.

What garbage collection technique is used here? How does it differ from the Boehm GC-based technique offered by the GCC Objective-C compiler?

Are any guarantees given with regards to the performance of the collector? Does it suffer from many of the problems that plagued the Java GC?

What sort of modifications do we have to make in order to take advantage of this support?

Specifics please? (1)

Jerk City Troll (661616) | more than 8 years ago | (#15862724)

I have been a Java developer for eight years. What problems have plagued Java garbage collection?

Re:Specifics please? (1)

botik32 (90185) | more than 8 years ago | (#15862840)

I do not know what exactly the problem is under the hood, but every desktop java app I used, tries to hog all my RAM regardless of how much I got, or what other programs are out there. That's why my (Linux) desktop is java-free. And considering the huge amount of open source code written in C/C++, I do not miss java apps one bit.

If I could point the reason, I would probably say lazy collection is the problem. On the other hand, I would not want my CPU be busy with collection most of the time. So, there.

Re:Specifics please? (1)

kingkade (584184) | more than 8 years ago | (#15863344)

I don't think you understand garbage collection, let alone Java, well enough to make a cogent argument.

Let's start with the admitted fact that the *basic* allocator in the Sun JVM requires on the order of twice the allocated heap space. But the idea is that the unused half will be paged out by the OS even though the perceived memory usage doesn't reflect that. In addition, the same reasoning is applied to the often cited "problem" that the Sun JVM heap never sshrinks.

Not to mention that you can add on top of this the fact that allocation in Java has almost no overhead because of this scheme.

In short: stop waving your "That's why my desktop (linux, woooo) is Java-free! Yay!" flag, if you don't know the first thing. Which nobody would really mind if you came up with an actual technical reason besides the fallacy of percieved memory consumption.

Re:Specifics please? (1)

botik32 (90185) | more than 8 years ago | (#15863435)

Thank you for the ad hominem attack. And next time my computer slows to a complete crawl, I will remember that this is just a "perceived" problem. I take it your precious eclipse IDE runs on 64MB of RAM just perfectly too.

What do I know, maybe the problem with the Java GC is not technical. It could be lazy incompetent programmers churning out crappy code that requires a supercomputer to run :)

Re:Specifics please? (2, Insightful)

squiggleslash (241428) | more than 8 years ago | (#15863450)

I think the "problems" are the elitist programmers who haven't realised yet that they actually aren't perfect... ;-)

Ooohh! Ooooh! -5 Flamebait! Go on, I dare you!

Seriously though, the major problem is that Java's advantages are rarely what the loudest advocates suggest. They'll talk incessantly about how they were able to get their app out in Java in only six weeks, and that it's all about making the programmer's life easier. That's not really it. What Java does is trap more errors, and moves from an insanity (manual memory management) to a more natural, free flowing, yet structured, memory model (at the end of the day, it's not even about garbage collection, that's just a side benefit of the memory model). And moreover, it prevents programmers from making common mistakes. And some programmers think that they are good enough to avoid those mistakes. But, you know what? I seriously doubt that. And I'm sometimes the guy who's running your program. And I don't trust you. You trust you. I don't. I'm being asked to trust you when I run your software, or when I add your software to mine, and I'd rather not. Not because I'm being insulting, or hate you, or anything like that, I'm just realistic. Even Knuth has had a few bugs to fix in TeX.

Java doesn't guarantee correctness, but it catches more bugs, and it makes some of the more dangerous ones - the buffer overflows, the stack overflows, etc, etc - practically impossible. I'd be curious to know if Objective C does the same thing, or if the obsession with the GC aspect of Java has gotten the better of everyone, again.

And Leopard has DTrace (4, Interesting)

SuperKendall (25149) | more than 8 years ago | (#15862154)

Far more exciting is that Leopard gets DTrace. Look at the last line of the page the story links to.

Well, let's say as exciting.

Re:And Leopard has DTrace (1)

_damnit_ (1143) | more than 8 years ago | (#15862613)

Nice catch there! I missed that little blurb earlier. GC is nice and everyone can debate whether they like it or not, but DTrace is loved by almost everyone who touches it. I would think DTrace would be on the top of the list of things advertised to developers at WWDC. By default, that would make Leopard my favorite MacOS X platform to develop on.

Re:And Leopard has DTrace (0)

Anonymous Coward | more than 8 years ago | (#15862637)

Oh it definitely gets DTrace...

http://www.apple.com/macosx/leopard/xcode.html [apple.com]

Nonlinear debugging with an Apple GUI. Sounds great. Too bad I wasn't at WWDC...

why is it.... (1)

Anonymous Coward | more than 8 years ago | (#15862156)

... that this is under it.slashdot.org? shouldn't this be under apple.slashdot.org?

that aside, given the new architecture xcode runs on, is there a way to get an x86 port for linux of xcode?

Re:why is it.... (2, Interesting)

JulesLt (909417) | more than 8 years ago | (#15862410)

What's the new architecture it runs on?

As far as I can see it's still a Cocoa app, so while it's certainly possible (we know the Next frameworks would run on top of multiple kernels) it is unlikely unless Apple decided to open up the layers above Darwin (unlikely). Alternatively, resource could be put into the GnuStep project, but overall there seems very little interest in it. (The non-Apple Obj-C community is tiny).

DTrace is currently only on Solaris and BSD (at least last I knew).

I'd imagine there would be more hope in a project to add similar features to Eclipse, where you may at least encounter a pool of developer motivation (including Mac developers who don't want to work with XCode).

Re:why is it.... (1)

Guy Harris (3803) | more than 8 years ago | (#15862969)

What's the new architecture it runs on?

He probably meant x86, but that's not exactly "new" as in "it just happened" - XCode has supported x86 for a while now.

DTrace is currently only on Solaris and BSD (at least last I knew).

"Currently", yes, but the XCode 3.0 page [apple.com] says "Many such Xray instruments leverage the open source DTrace, now built into Mac OS X Leopard."

XCode 3.0 (0)

Anonymous Coward | more than 8 years ago | (#15862166)

I am very curious about what XCode 3.0 entails in general, but cannot find much information about it. Is there complete coverage somewhere?

Apple seriously needs to get on modernizing their tools. XCode was great when it came out, but it's now years later and their current tools look archaic next to the competition, and until now Objective-C hasn't been updated since like 1985.

Xcode 3.0 isn't released yet (1)

mbessey (304651) | more than 8 years ago | (#15862206)

Only folks attending WWDC have the XCode 3.0 pre-release. They're all covered by a Non-Disclosure Agreement, so they can't (legally) say anything about it. Some information will doubtless leak out, but you won't see anything like a full review of it until it ships (presumably with Leopard).

There's a few additional details and a screenshot up on Apple's site:
http://www.apple.com/macosx/leopard/xcode.html [apple.com]

-Mark

Why not Objective C? (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15862183)

From what I understand it's a minimal OO extension of ANSI C, that is easier than C++ to learn and easier to compile. The addition of native garbage collection to the std lib could offer huge gains in development time. I'd like to know why isn't ObjC more popular outside Apple (and NeXT) circles?

Re:Why not Objective C? (2, Interesting)

JulesLt (909417) | more than 8 years ago | (#15862381)

>I'd like to know why isn't ObjC more popular outside Apple (and NeXT) circles

Because it's 'a failed language'. If they could come up with a rebrand (AJAX) or take the concepts and give it a syntactic revamp (maybe based round Ruby) they'd be well away, but the predominant line has been C to C++ to Java (and now C-sharp) - and only recently have Java developers begun to demand the features of a true OO language.

To be fair, there were good performance reasons why C++ won over Smalltalk regardless of it's productivity benefits, but these have become less and less important for UI bound programs.

Re:Why not Objective C? (0)

Cthefuture (665326) | more than 8 years ago | (#15862429)

Because it can be a lot slower than C++. C++ gives you control over the object messasing system whereas Objective-C uses virtual methods for pretty much everything and there is nothing you can do about it. Objective-C is actually a lot like COM which is Microsoft's object extension for C. It was designed about the same time with many of the same goals. Both basically came about because of the incredibly slow progress C++ was making at the time.

Objective-C has no template system. This is a huge advantage for C++.

It could be said that Objective-C is a lot like Java with many of the same problems but because it was never marketed with a cross-platform VM it didn't take off like Java.

Overall C++ is more C-like than Objective-C. That is it gives you much more control over the exact level of performance versus ease-of-use that you want.

Re:Why not Objective C? (0)

Anonymous Coward | more than 8 years ago | (#15862491)

Templates are anti OO.

Oh dear, where to start ? (4, Informative)

Space cowboy (13680) | more than 8 years ago | (#15862846)

  • Because it can be a lot slower than C++.
    Well, actually if you really *need* speed, then ObjC groks C perfectly - it's a cast-iron guarantee that any legal C will work in objC, unlike C++. C performance is just as good as C++...

  • C++ gives you control over the object messasing system whereas Objective-C uses virtual methods for pretty much everything and there is nothing you can do about it.
    Um, no. Objective C uses dynamic despatch (ie: the method to run is determined at runtime not compile-time. This is one of its most powerful features. As for "nothing you can do", you can retrieve the bound method as an IMP (like a function pointer) and call it directly to remove any overhead. Useful in loops.

  • Objective-C is actually a lot like COM which is Microsoft's object extension for C. It was designed about the same time with many of the same goals. Both basically came about because of the incredibly slow progress C++ was making at the time.
    No. Objective C was designed as an adaption of the ideas behind smalltalk, as applied to C. It was designed in the early 1980's, COM was designed in 1993, although it wasn't called COM until 1997.

  • Objective-C has no template system. This is a huge advantage for C++.
    Well, that's a matter of opinion, but in any case, Objective C is a dynamic language. Most of the power of templates is encapsulated within the dynamic-despatch abilities of the language, coupled with the 'protocol' feature of the language.

    It could be said that Objective-C is a lot like Java with many of the same problems but because it was never marketed with a cross-platform VM it didn't take off like Java.
    I think it is significantly like java, but it's compiled (like C/C++). It's a *lot* faster than Java, and handily beats gcj too, at least on the tests I've done. You need to enumerate these "same problems" before I can respond though.

  • Overall C++ is more C-like than Objective-C. That is it gives you much more control over the exact level of performance versus ease-of-use that you want
    Um, take any legal C code and it *might* compile in C++. It *will* compile in ObjC - how can C++ be "more like C" than ObjC ?

ObjC has introspection, dynamic binding, (now) optional garbage collection, (always) a very easy retain-count allocation system, really easy-to-learn constructs (I think there's 12 new statements, or something like that), *and* a weird syntax - it grows on you though :-) It actually does surprise me that more people don't like it. If Macs get more popular, who knows, perhaps it will have its day in the sun...

You need to read the PDF manual [apple.com] . There's a lot of stuff you're saying as fact, that is simply wrong.

Simon

Re:Oh dear, where to start ? (1)

Cthefuture (665326) | more than 8 years ago | (#15863297)

C performance is just as good as C++...

While this is true, it's very ugly to due certain things in C with the same performance as a clean C++ implementation. Generic containers for instance. Dereferencing pointers costs CPU cycles. You can do it just as fast in C but like I said, the code will be nasty.

Um, no. Objective C uses dynamic despatch (ie: the method to run is determined at runtime not compile-time. This is one of its most powerful features. As for "nothing you can do", you can retrieve the bound method as an IMP (like a function pointer) and call it directly to remove any overhead. Useful in loops.

Calling via function pointer is slower due to the pointer dereference. This is exactly the difference between virtual and non-virtual methods in C++. At least in C++ you get a choice.

No. Objective C was designed as an adaption of the ideas behind smalltalk, as applied to C. It was designed in the early 1980's, COM was designed in 1993, although it wasn't called COM until 1997.

Read what a wrote. I didn't say Objective-C was based on COM. I said it was like COM. The underlying architecture is very similar. The main difference is that Objective-C extended the C syntax whereas COM is still using plain C.

Well, that's a matter of opinion, but in any case, Objective C is a dynamic language. Most of the power of templates is encapsulated within the dynamic-despatch abilities of the language, coupled with the 'protocol' feature of the language.

Templates can create faster code than anything done in Objective-C. Assuming you're using the object features and not just plain C.

Um, take any legal C code and it *might* compile in C++. It *will* compile in ObjC - how can C++ be "more like C" than ObjC ?

I find it bizarre that you think the tiny incompatibilities between C and C++ are significant. Most of the time the changes you make to C code to get it to work in C++ are actually improvements to the code.

Re:Why not Objective C? (4, Interesting)

Novajo (177012) | more than 8 years ago | (#15862977)

Objective-C has no template system. This is a huge advantage for C++.



This is interesting because C++ has templates only because it needs them and Objective-C doesn't have them because there is no need. For instance, you can't have a C++ array of "anything", unless all objects descend from the same class, and then you are restricted to functions that were declared in that base class. That's because C++ is statically typed and needs to know the virtual table to use for the function call (whatever the function is). On the other hand, Objective-C does not need templates because function calls are not looked up through a virtual table, they are dynamically sent as messages, which are handled if the object implements that function. Hence, you can (and do) have a general-purpose array in Objective-C. You can even have a general purpose hash table with changing element types...! I'd love to see an implementation in C++ that is readable.


The "Object Penalty" (i.e. the cost of using a certain object-oriented language) is fixed, and it therefore reduces over time with faster and faster computers. C++ will do anything to make that cost as small as possible, including getting in your way. So really, the advantages of C++ are decreasing over time if you consider all the hoops you have to jump through to get what you want. When you really need performance in Objective-C, you write that little snippet of code in straight C (just like everyone else does in C++ .)


I was a C++ junkie for 10 years until I tried Objective-C and quickly noticed how much more complex a task I could handle without the language getting in my way. You should try it.

Re:Why not Objective C? (1)

neutralstone (121350) | more than 8 years ago | (#15863243)

> For instance, you can't have a C++ array of "anything",
> unless all objects descend from the same class, and then you
> are restricted to functions that were declared in that base
> class.

Sounds like someone hasn't tasted the sweet goodness of Boost. (:

In particular, Boost.Any gives you a simple and type-safe way to have a ${favorite_container_type} of anything.

See here:

http://boost.org/doc/html/any.html [boost.org] ... and see also:

http://boost.org/libs/libraries.htm [boost.org]

The nice part is that if you're using XCode and you're writing an app for the Mac, you don't have to choose between Obj-C and C++; you can use Objective-C++.

Re:Why not Objective C? (1)

n3m6 (101260) | more than 8 years ago | (#15863355)

It would be interesting if John Carmack's views, if he jumps into this conversation. Afterall, he went from Objective-C (Quake 3) to C++ (DOOM 3).

Re:Why not Objective C? (0)

Anonymous Coward | more than 8 years ago | (#15863165)

Objective C is simpler and easier to learn than C++, but programming in Objective C (epecially with openstep) requires a fairly solid understanding of design patterns. It is a very smooth and easy language once you understand them, but learning how to write good objective C is one giant mountain of a learning curve. It is hard to write 'bad' code without realizing it.

Of course, it requires a lot of knowledge to program good C++ as well, but it is easy to write bad C++ and not even realize it. Thus many programmers will write merrily on their way in C++ and not even realize that their code is an ugly mess.

Here is an interview [artima.com] with Bjarne Stroustrup where he gives a similar point of view (although I don't think he likes Objective C).

Uh... Great! Just... great... (0)

creimer (824291) | more than 8 years ago | (#15862210)

Does this mean I need buy all new $50 USD books to understand this new technology?

Re:Uh... Great! Just... great... (1)

node 3 (115640) | more than 8 years ago | (#15862469)

Does this mean I need buy all new $50 USD books to understand this new technology?
What makes you think you'd need to?

If you really did buy, read, and understand those "$50 USD books" (which is doubtful, given your post), you can write programs exactly the same as you do now. If you want to take advantage of garbage collection, you can do so at your own pace, and the included documentation and examples will be more than enough to learn from.

Re:Uh... Great! Just... great... (1)

oc255 (218044) | more than 8 years ago | (#15862859)

When I surfed to slashdot, I thought "let's see what's going on in the world" not "let's read another comment system where people insult each other".

Re:Uh... Great! Just... great... (1)

node 3 (115640) | more than 8 years ago | (#15863049)

Did you reply to the wrong post? Because there's not a single insult in my post.

Yay! More Bloated Crappy Code (0)

Anonymous Coward | more than 8 years ago | (#15862310)

Yay, another tool which encourages people to create bloated, flaky code.

-I don't *need* to care about memory, everyone has 1GB anyway

-I don't *need* to perform analysis on the algorithm, the garbage collector will take care of it *for me*.

-I don't *need* to do performance analysis of my code, since the randomness of the garbage collection algo will make any results totally meaningless anyway.

This is why there are still classical OO languages, ala C++, which are for real programmers and REAL software engineers to use. Let the code monkeys deal with Java and the like.

Re:Yay! More Bloated Crappy Code (3, Insightful)

Maury Markowitz (452832) | more than 8 years ago | (#15862540)

Practically every program I run under XP has a memory leak. As a result, quitting out of any of then leads to 15-20 seconds (yes, really) of disk griding while the VM dies. And this is on *quitting*. Does anyone else find it the least ironic that it takes longer to quit a program than start it?

I love listening to people complain about GC. Of course *they* are super-programmers that don't need any of this stuff, because their code never has *any* problems in it. But here I am with all these leaky programs. They leak memory all over the place and don't care. Why? Because I don't *need* to care about memory, everyone has 1GB anyway.

valgrind is your friend. (1)

botik32 (90185) | more than 8 years ago | (#15862887)

As a good programmer, it is a sane practice to check your app under some sort of leak detector. These things make it very easy to spot and fix memory leaks under various test cases. It does not take a "super programmer" to remove 99% of memory leaks in a fairly complex program.

Re:Yay! More Bloated Crappy Code (0)

Anonymous Coward | more than 8 years ago | (#15862694)

C++ is not a classic OO. Objective-C is actually based on a classic OO language called smalltalk.

the "rewind" function - is it for real? (1)

epaulson (7983) | more than 8 years ago | (#15862379)

The marketing-fluff webpage linked to talks about stepping back during a debugging session - is this for Objective-C only or is it available for every language? Now that is a compelling reason to upgrade

NOOOOOOO #@$#$@ (3, Insightful)

pestilence669 (823950) | more than 8 years ago | (#15862385)

Objective C has one of the most elegant reference counting implementations on the planet. Virtually no thinking at all is required to manage memory. Cyclical relationships, which shouldn't exist in decent code, are its only limitation. It's also very fast. Anyone who argues that memory management in Objective C is difficult, should have their head examined.

Garbage collection is a step backward, IMO, but every language seems to be moving in this direction. I really do believe that resource awareness is crucial to efficient programming. Garbage collection encourages lazy programming habits, which I've seen in quite a few Java developers. Bad habits, once bred, are hard to get rid of.

Now, instead of profiling memory for leaks, you can profile the garbage collector, which I predict will be just as much of a headache as tracking down a memory leak. In the end, little work is saved, at least from my experience debugging other developers' Java applications. I won't know for sure until I play with XCode 3.

Re:NOOOOOOO #@$#$@ (1)

bit01 (644603) | more than 8 years ago | (#15862767)

Garbage collection can also lead to unpredictability.

I detest it when a GUI pauses for no good reason, just because the runtime library decided to do a garbage collection at that point. It breaks some of the cardinal rules of good interface design; predictability and responsiveness.

---

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

Re:NOOOOOOO #@$#$@ (3, Interesting)

pikine (771084) | more than 8 years ago | (#15862782)

Objective C has one of the most elegant reference counting implementations on the planet.

There is no need to panic. You can support both reference counting and garbage collection in one run-time, provided the objects are in separate heaps. Whenever there is a reference from reference counting heap to the garbage collected heap, you simply tell the GC that there is a "root" reference inside a reference counting object. The other direction is probably even easier. A conservative GC can discern whether a reference is managed by the GC or not. Otherwise, we can foil a GC's attempt at traversing outside of the GC heap by marking a reference as an integer or by wrapping it in a special binary object that GC does not traverse.

Now, instead of profiling memory for leaks, you can profile the garbage collector, which I predict will be just as much of a headache as tracking down a memory leak.

Ever heard of suggestions that global variables are harmful? This is even truer for GC memory management. These globals have roots that persist throughout the lifetime of a program. For this reason, Java programmers seem to suffer more GC problems than a functional language programmer. In fact, the only place you need to look at, in the case of a "GC memory leak," is your global variables.

Unless a GC implementation is flawed, GC does not produce memory leaks. The leaks you are talking about are still technically used by the program but the programmer is not aware of it.

Debugging reference counting is just as much work as debugging malloc/free. In both cases, you need a map tracking the creation, duplication, and consumption of references.

Garbage collection is a step backward, IMO, but every language seems to be moving in this direction. I really do believe that resource awareness is crucial to efficient programming.

If by efficient programming you also take into account run-time overhead, some implementation of GC is more efficient than some implementation of malloc/free. For example, a copying GC only maintains a "heap top" pointer, and any new object is allocated from heap top only. In contrast to malloc/free implemented as linked list traversal, GC takes O(1) time to allocate, and O(n) time when it runs out of memory; malloc/free always takes O(n) time.

I'm sure other people will fill in the details here if they want to. The point here is that you cannot compare blanket GC with blanket reference counting or malloc/free.

If by efficient programming you mean the time it takes to write code, I believe GC is the winner here, since you forget you're using memory altogether.

Re:NOOOOOOO #@$#$@ (2, Funny)

shobadobs (264600) | more than 8 years ago | (#15862889)

In contrast to malloc/free implemented as linked list traversal, GC takes O(1) time to allocate, and O(n) time when it runs out of memory; malloc/free always takes O(n) time.

First of all, even dumb mallocs do not 'always' take O(n) time.
And comparing GC to a craptardic mallocation strategy is like comparing any sorting algorithm against bubble sort.

Re:NOOOOOOO #@$#$@ (1)

pestilence669 (823950) | more than 8 years ago | (#15863281)

Globals aren't the only place that memory leaks occur in Java. Bad Java code can "leak" memory just as badly as C++. Poorly formed closures can definitely cause your memory to waste away. Dealing with garbage collected languages isn't always as straight forward as proponents often suggest.

Re:NOOOOOOO #@$#$@ (4, Insightful)

m874t232 (973431) | more than 8 years ago | (#15862789)

You're missing the point of garbage collection. Garbage collection isn't there to save your effort. In fact, garbage collection does not save you effort at all. The purpose of garbage collection is to make the language safe and isolate errors, something that no other storage management scheme can achieve.

Both manual storage management and garbage collection each require a lot of experience to use correctly. Your problem is likely that you underestimate both how much work it took to become proficient at manual storage management/reference counting, and how much work it would take you to become proficient in a garbage collected environment.

Re:NOOOOOOO #@$#$@ (4, Informative)

bar-agent (698856) | more than 8 years ago | (#15863108)

Objective C has one of the most elegant reference counting implementations on the planet. Virtually no thinking at all is required to manage memory.

Oh, is that why the Cocoa-Dev mailing list has a brand-new reference counting question every damn day? It is clearly not as simple as you think.

Garbage Collection and Apple (2, Interesting)

beswicks (584636) | more than 8 years ago | (#15862419)

Let me be the first to welcome our new garbage collecting Overlords.

I love Objective-C and Apple (NeXT) API's. However, while garbage collection does make it "easier" to write software, I have GREAT fears about people not leaning to clean up after themselves.

Case in point was a University project I did involving robots. Everyone happy sets about coding there little robots in Java, write some simulators, then write the actual robots logic, all in wonderful cross platform Java. Que 100 students pondering why real thing ran for 20seconds then started beeping at them. I spent a LONG time trying to explain to people that with 64k of memory, and NO garbage collection (yey "special" Java) you cannot just keep creating temporary objects at will and hoping mummy will clean up.

I think its super that Apple will be even easier to write for, but please make sure your know how to clean up after yourself before you start coding, you never know when silicon mummy will be on holiday.

NB. Not sure I mean "easier" to write software, maybe "allows you to write with a little more of your brain unplugged".

Oh, come on, mods. (0)

Anonymous Coward | more than 8 years ago | (#15862657)

I loathe /. cliches as much as the next person, but "Garbage Collecting Overlords" definitely deserves a point or two.

Apple innovates... (2, Funny)

cortana (588495) | more than 8 years ago | (#15862492)

-lgc
I kid, I kid! :)

cpu/human trade off (1)

fermion (181285) | more than 8 years ago | (#15862605)

It seems to me that everything in programing, or really any process type thing, is managing resources. Any project has a certain amount of human power, a certain amount of time, and a certain amount of mechanical or electrical power. And while a competent programmer should be able to manage memory, when we have all these tight deadlines and all these cheap cycles, why take the time or pay the extra money? In the end, except for application where there is no excess power, it makes a lot of sense to utilize the technological innovation of garbage collection. I myself think not managing my own memory is boring, but I do realize that most people simply do not want to deal with it.

I think we really have to accept and embrace real innovations to productivity. Things such as compilers, optimizers, high level interfaces, has brought us great benefit. If we look at it in real terms the advancements are awesome. In the Mythical Man Month I seem to recall that coding speeds were cited as dozens of lines per day. Compare that to what we can do now. The down side is that we perhaps waste resources, and in many ways the computer industry is crushing itself under the weight of wasted resources, but that is merely another management issue.

Why this story doesn't show in RSS?? (0, Offtopic)

Qwavel (733416) | more than 8 years ago | (#15862745)

I've started to notice that there are /. stories that I miss because they don't appear in the RSS feed. What's going on?

many people miss the point of GC (2, Insightful)

m874t232 (973431) | more than 8 years ago | (#15862811)

Many people think that the purpose of garbage collection is to make programming easier. But that's not the purpose of garbage collection at all. Memory management in a garbage collected language is at least as much effort as memory management in a language with manual storage management, and it requires at least as much experience to use well.

The purpose of garbage collection is to make languages safer. If Objective C 2.0 has additional features to make it safer (variable initialization, pointer checks, etc.), then garbage collection will help it. Otherwise, it's just a gimmick.

Unfortunately, from Apple's web page, it's difficult to see what exactly they did; adding garbage collection to Objective C in a useful and correct way is a nearly intractable problem, and I won't believe that they succeeded until I see more data.

Customers don't like to pay for memory leaks (1)

bADlOGIN (133391) | more than 8 years ago | (#15863025)

That's why garbage collection is so popular. Even if it's not your code, it could always be your co-workers code (added in a hurry under a tight deadline), or some proprietary 3rd party library kept on life support via the lowest offshore bidder (which you still pay full US sales & marketing Lexus buying price for). In those cases, give me a GC platform any day. Because the people who will be screaming for your head on a platter don't care who's fault it is for not cleaning up, and you have better things to do (like solve their problems and make working software) in the 1st place...

Support for a Java-like messaging syntax? (0)

Anonymous Coward | more than 8 years ago | (#15863106)

For years there has been speculation that Apple would add support for Java-style messaging syntax to Objective-C.

Objective-C uses a Smalltalk-like syntax when sending a message to an object:
eg. [object messageName:arg1 furtherMessageName:arg2];

Java, on the other hand, uses a syntax derived from C++:
eg. object.messageNameFurtherMessageName(arg1, arg2);

Will "Objective-C 2.0" offer support for the Java-style syntax?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>