But I'm just saying that the Stevenote comparison to the Dell Precision 690 is bunk, or at best greatly overstates the difference because the machines aren't comparable.
Que ?
One thing to keep in mind is that Apple is offing a consumer video card in their base price vs. Dell's Quadro offering across the Precision line (a few hundred dollars minimum price difference)
Interesting. When I go to the 'customise' page on Dell's website, the default card is a 128 MB Quadro, without even a DVI socket on it (it's dual VGA). Doesn't sound too "professional" to me. Pricewatch puts that at $115. Apple's 256MB 7300GT is $90 on pricewatch. Not that much difference, really, and it at least can drive a DVI display...
Dell's BASE warranty support is better than if you bought the 3yr. AppleCare (a $250 extra, add a few hundred for on-site support that doesn't exist through Apple).
No argument that Apple's support is extra, but IMHO it's also a *lot* better - certainly in my experience anyway. I guess we'll agree to differ on this one. I have a dell server on support (since it's in a different country to me), and the quality of the support makes me shudder:-(
Not only that, the Precision 690 that was compared supports up to 64GB of memory vs. Apple's 16GB.
And yet you can't buy more than 4G of RAM from them. At least Apple *sell* you RAM. Try it on the page - the 667MHz ram isn't yet available, and you can only get 4G of it! The damn stuff is so expensive that purchasing 64G will cost a small fortune anyway!
Bottom line: Apple is a lot cheaper than Dell (see my previous post) and it certainly does compete with the 690.
So, I just ordered a Mac Pro with the following specs:
Processor 3.00 GHz Quad Xeon Memory 4GB 667 DDR2 FB DIMM ECC4x1GB Graphics Card ATI Radeon X1900 XT 512MB Hard Drive Bay1 500GB Serial ATA 3Gb/s drive Optical Drive 16x SuperDrive DL Wireless Option Airport Extreme
... as well as the standard stuff (keyboard, mouse, OSX, etc.) Cost before tax was $4249
Pricing as similar a machine as I can (replacing the ATI card with a quadra FX 3450, match RAM, lose monitor, add DVD-RW, add ethernet) I get $6282 before tax.
So, are Dell gouging an extra $2033 (or 47%) profit from their customers ? Or is it what the market will sustain for them ? Or is it that this time Apple managed to get a better deal on parts ? Who knows... It's pretty certain that if it were the other way around it would be Apple's "high prices".
Now my pricing includes a small discount, but since it seems Apple have to compete on price against Dell's discounts normally, I'm sure no-one will object to me using Apple's discounted prices against Dell, yes ? Even with the discount removed, it's still almost $1400 difference in Apple's favour.
My point is that you have to compare like with like. Sure there's no low-cost tower. Deal. If they don't sell it, you can't buy it - though in fact I'd be surprised if the gap wasn't filled soon enough... I'd expect Apple to launch the high-end towers first so there's a good population of high-end machines out there, and to exploit the pent-up demand. As soon as that demand starts to wane, I (if I were Apple:-) would introduce a lower-end machine to plug the gap. Just don't expect it for several months...
Simon (who can't wait for his new machine to arrive:-)
Are you able to back that up with any kind of figures?
I recall reading on digg (I'd go and get it to give you a link, but the way the site works makes it hard to find older stuff) a month or 6 weeks ago about how Dell have had this exploding laptop thing going on for a couple of years, but have just carried on selling them, and replacing them when customers complained. As soon as the Apple one went up in flames, it all came out of the woodwork that there'd been a couple of hundred cases over 2 (maybe 3, can't recall exactly) years...
I don't have a problem with Dell - I have one of their servers too, and I think it's well engineered. I just think Apple come in for more-than-their-fair-share of criticism. If you disagree, fine - it's a big world, plenty of space for multiple opinions.
Apple do push the limits, I think. More than most (not all) manufacturers, anyway. It hasn't stopped me from ordering a Mac Pro though (4x3GHz will *really* help on those FPGA place-and-route calculations. I've had them run for 2 weeks before now). Of course, I chose it on price as well as it being a Mac - the equivalent Dell was ~$2400 more expensive ($6638 vs $4249).
And I'm very, very rarely scary. I have to try *really* hard, and even then it doesn't really happen [sigh]. I don't put words in people's mouths then say "what a load of crud", though, either.
... then they knock you down. Dvorakitis is spreading IMHO - Ars will get a lot of page-hits (and hence ad revenue) from people wanting to read about this. Sure, Apple have had problems, but not as many as Dell, and I doubt Dell are any worse than any other random manufacturer.
Apple actually have it worse than most - to an extent they sell on style, and "shiny goodness". People are *more* vocal when something goes wrong with something they like, rather than some random notebook work gave them to use at the weekend... I'm actually surprised the vocal minority haven't been louder. Perhaps Apple ought to release the figures for their return/repair rates - I seem to recall someone saying they were well below industry norms - even *with* all this hullaballoo.
Can I also just say I bought an MBP pro, and it hasn't exhibited any of the problems mentioned in the article... because normally you never hear about it when it works fine - only when it's broken in some way. As a software developer, I knew all about that:-)
This explaination of NSAutoreleasePool is wrong. The parent seems to think that the point of an autorelease pool is to release a number of objects by releasing the pool itself.
The explanation is not wrong. I do think that it is *a* use for autorelease pools, and I'm in good company - from the NSAutoreleasePool documentation:
If your application or thread is long-lived and potentially generates a lot of autoreleased objects, you should periodically destroy and create autorelease pools (like the Application Kit does on the main thread); otherwise, autoreleased objects accumulate and your memory footprint grows. If your detached thread does not make Cocoa calls, you do not need to create an autorelease pool.
Typically, an application will create an autorelease pool on startup and use that single pool for the rest of its life time. After the main loop exits, the application might call [pool release] for the sake of good habit, but it's not really necessary since this is at the very end of the program, and all memory is freed on exit anyway.
There are normally at least 2 autorelease pools used by Cocoa code - one is created in NSApplicationMain, and for every cycle through the event loop, a child-pool is created and destroyed. For simple UI-based apps, this is usually sufficient to for the coder to not bother creating any more.
If you have background threads that use Cocoa (or most of foundation, even NSLog() requires this), you must create a pool on entry to the thread selector, and if you have while-loops which allocate a lot of autoreleased objects, it is good practice to have an autorelease pool created as the first statement of the loop, and destroyed as the last statement. It's always a judgement call as to when to do this, but in general keeping the memory footprint lower is a good idea. On background threads, it's crucial - otherwise the memory-footprint of your infinite loop in the background will just grow indefinitely.
The real point of autorelease pools is to let a method say; "I want this object to be released when my callers are done with it."
Well, that's *one* use of them. Managing memory efficiently is another.
An application gets an Autorelease pool set up for it in NSApplicationMain, the event loop creates and destroys one every time through, so you can see how it might appear to work automagically. However, when you try to set up a thread, it all falls down - you have to create your own pool and release it at the end of your thread function. Try doing an NSLog() in a thread method without setting up your own pool...
Pools nest, so you can (and it's good practice to) create inner pools for while loops that create/destroy lots of objects - in the same way, the application has a pool, each event loop has a pool, and the coder can create pools within the event-loop pool.
ObjC implements a nice-and-easy reference-counting memory management system. Autorelease pools are simply a convenience function based on the underlying reference-counted objects. I think it works well though - I think "slapped together" is a bit of an emotional-loaded term for how it works...
Actually I think I am correct - the reason the event loop is important is that it always creates an autorelease pool at the start of the loop, and destroys the pool at the end of the loop.
If you want to have threads, and you call NSThread's detachNewSelector:toTarget:withObject: method, you have to set up the autorelease pool yourself. If you have an infinite loop in a background thread, your application will probably eventually crash, simply because you've never freed any objects in the autorelease pool in that background thread - the event loop happens on the main thread, so never affects any background threads.
My point is that the event loop (which is pretty fundamental to any cocoa app) has an implicit:
pool = [NSAutoreleasePool new] (process all pending events) [pool release]
which actually strengthens my argument, not weakens it...
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
If you're trying to tell me that the generic containers of C++ come with zero cost, I have a bridge to sell you. At any level, you can make an abstraction or you can code to that level. The standard CS joke is that any problem in any language can be solved by introducing another layer of abstraction...
Objective C gives you a clear choice - use the objective language as it was designed, or (for the tiny percentage of code which really is time-critical) code in C. You get the best of both worlds - a simple, elegant object-based language, and the pedal-to-the-metal facility of C. What's to not like ?
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
I'm not convinced you're correct here... on most machines 'jsr label' and 'jsr (label)' are equivalent instructions - the speculative prefetch will have resolved (label) by the time the jsr is executed. Still, my point was that for that tiny percentage of code that is truly time-critical, you simply call a C function - no dereference is required.
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
Maybe I was unclear - I read what you wrote and I completely disagree with it. It was *not* designed at the same time, it does *not* have the same goals, it is fundamentally dissimilar, and its goals were *not* even vaguely similar. You'd have better luck comparing chalk and cheese!
Templates can create faster code than anything done in Objective-C
An interesting (and bold) statement. Ok, so I have a plugin architecture - there's a bundle of code associated with the application that may or may not have been installed by the application author. In ObjC, its a trivial (3-line) routine to validate that this anonymous code is part of the application, and should be a full peer in the class hierarchy. I'd love to see you do that with templates... ObjC's runtime-binding and introspection make it (as mentioned) trivial.
I find it bizarre that you think the tiny incompatibilities between C and C++ are significant
I think it's bizarre for you to state that a language (that is in fact less compatible with C) is more compatible with C. If you have a better metric, please explain what it is. The plain fact of the matter is that Objective C is more compatible than C++. It's as simple as that.
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. There's a lot of stuff you're saying as fact, that is simply wrong.
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:
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.
It's actually a proprietary format on the laserdisk as well - I don't know if laserdisks (weren't they analogue ?) ever had a standard format like CDROM's do. I think it was more along the lines of "format it for this machine, and only this machine can read it".
Now that the machine is vanished into the history books, the data is unreadable (or was, until they ported it to the PC, but I believe that took a *lot* of effort, and who's to say that in 20 years, the PC will still be around in it's current form ?
Interesting that the original domesday book is still useful for territorial disputes almost a thousand years after it was written, but that the domesday project, a modern equivalent on laserdisk is no longer readable roughly 20 years after introduction.
Even though later on, an effort was made to port to the PC it reminds us just how ephemeral modern information is. If a year is a long time in politics, a decade is an eternity in computing tech.
Open standards (and not closed or proprietary document formats) are the only weapon we have against a "digital dark ages" descending on us. There are already files I have from my early computing days (written to an Exabyte tape in a non-standard dump-format) that I can't read. My PhD thesis is out-of-bounds in digital form, unless I get a used DECstation from ebay...
You know, you wrote a lot of stuff there, and I didn't read any of it, which is a shame because it doesn't *look* as though it's trollbait from a cursory glance.
There's no way you're going to get people to read your stuff if you don't use paragraphs, and break your points up into digestible pieces...
There ought to be nothing wrong with kids playing in public trees, and I'd be willing to bet my house that the tree will survive an afternoon's attention from 3 twelve-year-olds.
Nice spin put on it by the police spokesman "destroying an ornamental cherry tree by stripping every branch from it". It was a tree in a public park, not a centrepiece of an arrangement. I'd love to see the twelve-year-old who could "strip every branch" from a tree... Certainly the ones in the picture didn't look up to it. Hercules'd have problems.
My dictionary defines "destroying" as "to put an end to the existence of". Somewhat emotive language for a few broken twigs, I feel. You don't lock young kids up over a few broken twigs; if you do anything, you drive them home and let their parents give them merry hell for being delivered home by the police.
Or you could just let them play. It's a friggin' tree!
Read the damn article yourself. From the article...
Officers told the children they had been seen damaging the tree which is in a wooded area of public land near their homes
So, this isn't your personal property (and I agree that kids destroying a tree in my garden would offend me). As for "tearing down", I don't know if you've ever seen a tree, but they're fairly hardy buggers - we build houses out of them, and before steel came along they were quite popular for ocean-going ships.
I'd be fairly confident that an afternoon in the company of 3 twelve-year-olds wasn't going to significantly damage the tree. Perhaps a few broken twigs, and a little less foliage. Destroying something does after-all imply a fairly major difference to the tree - my dictionary defines it as "put an end to the existence of".
This is quite clearly an example of cops going well-over-the-top in response to a minor incident, just because they can. I'd be more tempted to arrest the busybody who called the cops in the first place, for wasting police time.
If I was the child's parent, I'd be writing to the chief-constable demanding action; writing to the local and national newspapers with the story; putting adverts up in the local shop-windows asking people whether they thought it was right; writing to the local council demanding they investigate; setting up a website detailing the incident so it's public knowldge; writing to my Member of Parliament, and even the PM; in short creating such a stink that the officers in question are likely to get formally reprimanded. On every one of those letters I'd have the officers identified by badge number, the name of their Sergeant, and the actions-taken-to-date by the police to rectify their mistake.
After all, if the police have done nothing wrong, they've got nothing to worry about, have they ? All I'll do is make myself look a fool. Unless, of course, the majority of people agree with *me*
You don't lock kids up for breaking a few twigs. Betcha that tree is there long after the kids are dead. Like I said, they're hardy buggers.
I dunno, maybe because all three are bloody obvious ?
1) "Fitts' law is a model of human movement, predicting the time required to rapidly move from a starting position to a final target area". Unless you never select anything from the menu, it applies. For every GUI-user you show me who has never selected a menu-item, I'd be able to find hundreds who had.
2) Did you get the bit about "infinite depth" ? That the edges of the screen make it easier to locate the mouse because of no possibility of overshoot ? Seems completely obvious to me, but hey! Actually it seems bloody obvious to others, too
Question 5
Explain why a Macintosh pull-down menu can be accessed at least five times faster than a typical Windows pull-down menu. For extra credit, suggest at least two reasons why Microsoft made such an apparently stupid decision.
Microsoft, Sun, and others have made the decision to mount the menu bar on the window, rather than at the top of the display, as Apple did. They made this decision for at least two reasons:
Apple claimed copyright and patent rights on the Apple menu bar Everyone else assumed that moving the menu bar closer to the user, by putting it at the top of the window, would speed things up. Phalanxes of lawyers have discussed point 1. Let's deal with point two. The Apple menu bar is a lot faster than menu bars in windows. Why? Because, since the menu bar lies on a screen edge, it has an infinite height. As a result, Mac users can just throw their mice toward the top of the screen with the assurance that it will never penetrate and disappear.
Unless, of course, I'm testing them at the time. I did a test at Apple where I mounted one monitor on top of another, with the menu bar at the top of the lower display. The only way the user could get to the top monitor way by passing through the menu bar enroute.
I then gave users the task of repeatedly accessing menu bar items. When they first started out, they penetrated into the upper screen by around nine inches on average, just because their mouse velocity was so high. Then they learned they had to slow down and really aim for the menu. By the time they adjusted, their menu-access times became so ponderously slow, they took around the same time as the average Windows user.
The other "advantage" usually ascribed to a menu bar at the top of each window is that they user always knows where to look for the items pertaining to the task they are carrying out. This is silly. Users may do various tasks within a given window, and the menu items may change. Not only that, but a great many perverse applications exist, particularly in the Sun world, where the menu bar you need to access is not even in the window in which you are working! That is truly bizarre and mind-bending.
Microsoft applications are beginning to offer the possibility, in full-screen mode, of a menu bar at the top of the display. Try this out in Word or Excel. It is much faster. Microsofts general cluelessness has never been so amply displayed, however, as it is in Microsoft Visual Studio, which has a menu bar at the top of the screen with a one-pixel barrier between the screentop and the menu. Talk about snatching defeat from the jaws of victory.
3) If it's easier to do something, that's a better usability. End of.
Ok, I was sufficiently annoyed to look up the research behind the example I gave (the 'infinitely-deep menubar'). Here's the wikipaedia reference, which quotes papers from Fitts himself.
I wasn't trying to present 'evidence'. I was stating an opinion, hence the "Or hell, I could be wrong" bit at the end. I thought that was a giveaway, but perhaps not...
I'm not a researcher. I'm not actively involved with the HI design community - why would I have "evidence" on hand ? And if I don't have it to hand, I'm not going to spend hours or days looking for it just to satisfy someone I don't know on the web... If you want evidence, find it. Or if you want evidence against, find it. Just don't expect me to do it for you.
... MS had just had another technical disaster of a presentation (there've been so many, I can't actually remember which one this was), but it was very shortly before Jobs got up on the stage and had his own problems. His patter went something like:... well it is only a beta OS at the moment (flicks switch to change systems)... and that's why *WE'VE* got backup systems...
Slashdot Mirror
Interesting. When I go to the 'customise' page on Dell's website, the default card is a 128 MB Quadro, without even a DVI socket on it (it's dual VGA). Doesn't sound too "professional" to me. Pricewatch puts that at $115. Apple's 256MB 7300GT is $90 on pricewatch. Not that much difference, really, and it at least can drive a DVI display...
No argument that Apple's support is extra, but IMHO it's also a *lot* better - certainly in my experience anyway. I guess we'll agree to differ on this one. I have a dell server on support (since it's in a different country to me), and the quality of the support makes me shudder
And yet you can't buy more than 4G of RAM from them. At least Apple *sell* you RAM. Try it on the page - the 667MHz ram isn't yet available, and you can only get 4G of it! The damn stuff is so expensive that purchasing 64G will cost a small fortune anyway!
Bottom line: Apple is a lot cheaper than Dell (see my previous post) and it certainly does compete with the 690.
Simon.
Pricing as similar a machine as I can (replacing the ATI card with a quadra FX 3450, match RAM, lose monitor, add DVD-RW, add ethernet) I get $6282 before tax.
So, are Dell gouging an extra $2033 (or 47%) profit from their customers ? Or is it what the market will sustain for them ? Or is it that this time Apple managed to get a better deal on parts ? Who knows... It's pretty certain that if it were the other way around it would be Apple's "high prices".
Now my pricing includes a small discount, but since it seems Apple have to compete on price against Dell's discounts normally, I'm sure no-one will object to me using Apple's discounted prices against Dell, yes ? Even with the discount removed, it's still almost $1400 difference in Apple's favour.
My point is that you have to compare like with like. Sure there's no low-cost tower. Deal. If they don't sell it, you can't buy it - though in fact I'd be surprised if the gap wasn't filled soon enough... I'd expect Apple to launch the high-end towers first so there's a good population of high-end machines out there, and to exploit the pent-up demand. As soon as that demand starts to wane, I (if I were Apple
Simon (who can't wait for his new machine to arrive
Yeah, but at least Apple hired the original engineers :-)
Simon
I recall reading on digg (I'd go and get it to give you a link, but the way the site works makes it hard to find older stuff) a month or 6 weeks ago about how Dell have had this exploding laptop thing going on for a couple of years, but have just carried on selling them, and replacing them when customers complained. As soon as the Apple one went up in flames, it all came out of the woodwork that there'd been a couple of hundred cases over 2 (maybe 3, can't recall exactly) years...
I don't have a problem with Dell - I have one of their servers too, and I think it's well engineered. I just think Apple come in for more-than-their-fair-share of criticism. If you disagree, fine - it's a big world, plenty of space for multiple opinions.
Apple do push the limits, I think. More than most (not all) manufacturers, anyway. It hasn't stopped me from ordering a Mac Pro though (4x3GHz will *really* help on those FPGA place-and-route calculations. I've had them run for 2 weeks before now). Of course, I chose it on price as well as it being a Mac - the equivalent Dell was ~$2400 more expensive ($6638 vs $4249).
And I'm very, very rarely scary. I have to try *really* hard, and even then it doesn't really happen [sigh]. I don't put words in people's mouths then say "what a load of crud", though, either.
Simon
... then they knock you down. Dvorakitis is spreading IMHO - Ars will get a lot of page-hits (and hence ad revenue) from people wanting to read about this. Sure, Apple have had problems, but not as many as Dell, and I doubt Dell are any worse than any other random manufacturer.
:-)
Apple actually have it worse than most - to an extent they sell on style, and "shiny goodness". People are *more* vocal when something goes wrong with something they like, rather than some random notebook work gave them to use at the weekend... I'm actually surprised the vocal minority haven't been louder. Perhaps Apple ought to release the figures for their return/repair rates - I seem to recall someone saying they were well below industry norms - even *with* all this hullaballoo.
Can I also just say I bought an MBP pro, and it hasn't exhibited any of the problems mentioned in the article... because normally you never hear about it when it works fine - only when it's broken in some way. As a software developer, I knew all about that
Simon
The explanation is not wrong. I do think that it is *a* use for autorelease pools, and I'm in good company - from the NSAutoreleasePool documentation:
There are normally at least 2 autorelease pools used by Cocoa code - one is created in NSApplicationMain, and for every cycle through the event loop, a child-pool is created and destroyed. For simple UI-based apps, this is usually sufficient to for the coder to not bother creating any more.
If you have background threads that use Cocoa (or most of foundation, even NSLog() requires this), you must create a pool on entry to the thread selector, and if you have while-loops which allocate a lot of autoreleased objects, it is good practice to have an autorelease pool created as the first statement of the loop, and destroyed as the last statement. It's always a judgement call as to when to do this, but in general keeping the memory footprint lower is a good idea. On background threads, it's crucial - otherwise the memory-footprint of your infinite loop in the background will just grow indefinitely.
Well, that's *one* use of them. Managing memory efficiently is another.
Simon.
An application gets an Autorelease pool set up for it in NSApplicationMain, the event loop creates and destroys one every time through, so you can see how it might appear to work automagically. However, when you try to set up a thread, it all falls down - you have to create your own pool and release it at the end of your thread function. Try doing an NSLog() in a thread method without setting up your own pool...
Pools nest, so you can (and it's good practice to) create inner pools for while loops that create/destroy lots of objects - in the same way, the application has a pool, each event loop has a pool, and the coder can create pools within the event-loop pool.
Simon
ObjC implements a nice-and-easy reference-counting memory management system. Autorelease pools are simply a convenience function based on the underlying reference-counted objects. I think it works well though - I think "slapped together" is a bit of an emotional-loaded term for how it works...
Simon
Actually I think I am correct - the reason the event loop is important is that it always creates an autorelease pool at the start of the loop, and destroys the pool at the end of the loop.
If you want to have threads, and you call NSThread's detachNewSelector:toTarget:withObject: method, you have to set up the autorelease pool yourself. If you have an infinite loop in a background thread, your application will probably eventually crash, simply because you've never freed any objects in the autorelease pool in that background thread - the event loop happens on the main thread, so never affects any background threads.
My point is that the event loop (which is pretty fundamental to any cocoa app) has an implicit:
pool = [NSAutoreleasePool new]
(process all pending events)
[pool release]
which actually strengthens my argument, not weakens it...
Simon
If you're trying to tell me that the generic containers of C++ come with zero cost, I have a bridge to sell you. At any level, you can make an abstraction or you can code to that level. The standard CS joke is that any problem in any language can be solved by introducing another layer of abstraction...
Objective C gives you a clear choice - use the objective language as it was designed, or (for the tiny percentage of code which really is time-critical) code in C. You get the best of both worlds - a simple, elegant object-based language, and the pedal-to-the-metal facility of C. What's to not like ?
I'm not convinced you're correct here... on most machines 'jsr label' and 'jsr (label)' are equivalent instructions - the speculative prefetch will have resolved (label) by the time the jsr is executed. Still, my point was that for that tiny percentage of code that is truly time-critical, you simply call a C function - no dereference is required.
Maybe I was unclear - I read what you wrote and I completely disagree with it. It was *not* designed at the same time, it does *not* have the same goals, it is fundamentally dissimilar, and its goals were *not* even vaguely similar. You'd have better luck comparing chalk and cheese!
An interesting (and bold) statement. Ok, so I have a plugin architecture - there's a bundle of code associated with the application that may or may not have been installed by the application author. In ObjC, its a trivial (3-line) routine to validate that this anonymous code is part of the application, and should be a full peer in the class hierarchy. I'd love to see you do that with templates... ObjC's runtime-binding and introspection make it (as mentioned) trivial.
I think it's bizarre for you to state that a language (that is in fact less compatible with C) is more compatible with C. If you have a better metric, please explain what it is. The plain fact of the matter is that Objective C is more compatible than C++. It's as simple as that.
Simon
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++...
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.
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.
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.
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
You need to read the PDF manual. There's a lot of stuff you're saying as fact, that is simply wrong.
Simon
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:
... clears up after you, but it's no garbage collection, it's just a convenient way of using retain/release.
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]
ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.
Simon
More like: because they *do* have girlfriends... You have *seen* PC's and macs side-by-side, right ?
:-)
Simon
(who owns a macbook pro because (a) it's unix, (b) it runs business-apps so I can expense it, and (c) it's gorgeous, in that order
It's actually a proprietary format on the laserdisk as well - I don't know if laserdisks (weren't they analogue ?) ever had a standard format like CDROM's do. I think it was more along the lines of "format it for this machine, and only this machine can read it".
Now that the machine is vanished into the history books, the data is unreadable (or was, until they ported it to the PC, but I believe that took a *lot* of effort, and who's to say that in 20 years, the PC will still be around in it's current form ?
Simon
Interesting that the original domesday book is still useful for territorial disputes almost a thousand years after it was written, but that the domesday project, a modern equivalent on laserdisk is no longer readable roughly 20 years after introduction.
Even though later on, an effort was made to port to the PC it reminds us just how ephemeral modern information is. If a year is a long time in politics, a decade is an eternity in computing tech.
Open standards (and not closed or proprietary document formats) are the only weapon we have against a "digital dark ages" descending on us. There are already files I have from my early computing days (written to an Exabyte tape in a non-standard dump-format) that I can't read. My PhD thesis is out-of-bounds in digital form, unless I get a used DECstation from ebay...
Just food for thought...
You know, you wrote a lot of stuff there, and I didn't read any of it, which is a shame because it doesn't *look* as though it's trollbait from a cursory glance.
There's no way you're going to get people to read your stuff if you don't use paragraphs, and break your points up into digestible pieces...
Just a friendly hint.
Simon
I will type small words so you grok:
... was ... a ... tree
... public ... land
It
On
There ought to be nothing wrong with kids playing in public trees, and I'd be willing to bet my house that the tree will survive an afternoon's attention from 3 twelve-year-olds.
Nice spin put on it by the police spokesman "destroying an ornamental cherry tree by stripping every branch from it". It was a tree in a public park, not a centrepiece of an arrangement. I'd love to see the twelve-year-old who could "strip every branch" from a tree... Certainly the ones in the picture didn't look up to it. Hercules'd have problems.
My dictionary defines "destroying" as "to put an end to the existence of". Somewhat emotive language for a few broken twigs, I feel. You don't lock young kids up over a few broken twigs; if you do anything, you drive them home and let their parents give them merry hell for being delivered home by the police.
Or you could just let them play. It's a friggin' tree!
Simon
So, this isn't your personal property (and I agree that kids destroying a tree in my garden would offend me). As for "tearing down", I don't know if you've ever seen a tree, but they're fairly hardy buggers - we build houses out of them, and before steel came along they were quite popular for ocean-going ships.
I'd be fairly confident that an afternoon in the company of 3 twelve-year-olds wasn't going to significantly damage the tree. Perhaps a few broken twigs, and a little less foliage. Destroying something does after-all imply a fairly major difference to the tree - my dictionary defines it as "put an end to the existence of".
This is quite clearly an example of cops going well-over-the-top in response to a minor incident, just because they can. I'd be more tempted to arrest the busybody who called the cops in the first place, for wasting police time.
If I was the child's parent, I'd be writing to the chief-constable demanding action; writing to the local and national newspapers with the story; putting adverts up in the local shop-windows asking people whether they thought it was right; writing to the local council demanding they investigate; setting up a website detailing the incident so it's public knowldge; writing to my Member of Parliament, and even the PM; in short creating such a stink that the officers in question are likely to get formally reprimanded. On every one of those letters I'd have the officers identified by badge number, the name of their Sergeant, and the actions-taken-to-date by the police to rectify their mistake.
After all, if the police have done nothing wrong, they've got nothing to worry about, have they ? All I'll do is make myself look a fool. Unless, of course, the majority of people agree with *me*
You don't lock kids up for breaking a few twigs. Betcha that tree is there long after the kids are dead. Like I said, they're hardy buggers.
Simon
And once he's shot you in the face, he'll parade you on TV and make you apologise to him (!!)
Jon Stewart was right - DC is one scary-as-hell dude.
Simon
Sorry to reply to my own post, but I was sort of disconcerted that someone has moderated me "informative". LMFAO.
Simon.
The stargate program is being expanded...
Simon
1) "Fitts' law is a model of human movement, predicting the time required to rapidly move from a starting position to a final target area". Unless you never select anything from the menu, it applies. For every GUI-user you show me who has never selected a menu-item, I'd be able to find hundreds who had.
2) Did you get the bit about "infinite depth" ? That the edges of the screen make it easier to locate the mouse because of no possibility of overshoot ? Seems completely obvious to me, but hey! Actually it seems bloody obvious to others, too
3) If it's easier to do something, that's a better usability. End of.
Game, set, and match.
Ok, I was sufficiently annoyed to look up the research behind the example I gave (the 'infinitely-deep menubar'). Here's the wikipaedia reference, which quotes papers from Fitts himself.
Simon.
I wasn't trying to present 'evidence'. I was stating an opinion, hence the "Or hell, I could be wrong" bit at the end. I thought that was a giveaway, but perhaps not...
I'm not a researcher. I'm not actively involved with the HI design community - why would I have "evidence" on hand ? And if I don't have it to hand, I'm not going to spend hours or days looking for it just to satisfy someone I don't know on the web... If you want evidence, find it. Or if you want evidence against, find it. Just don't expect me to do it for you.
Simon
... MS had just had another technical disaster of a presentation (there've been so many, I can't actually remember which one this was), but it was very shortly before Jobs got up on the stage and had his own problems. His patter went something like: ... well it is only a beta OS at the moment ... and that's why *WE'VE* got backup systems...
:-)
(flicks switch to change systems)
Never one to miss an opportunity
Simon