Oh boy. I've been really trying to restrain myself from writing this blog post. It feels like I write one like it once a year. It is the age-old (at least in internet years) argument that the web is better than the desktop or the desktop is better than the web.

Now in my usual post on this topic I pull the web idealists from their pedestals and inform them the web will never replace the desktop, and smack desktop idealists around the head and tell them they can't expect their apps to live on an island any more. The conclusion is always the same: the real power is in the internet, the web and the desktop are just two different ways of providing an interface to it, each with pros and cons.

However, what made me crack and write this post is another post by one of the aforementioned web idealists. So this post will instead be rebutting his post with a vengeance. The author is Peter-Paul Koch and the post can be found here: http://www.quirksmode.org/blog/archives/2009/11/apple_is_not_ev.html

Stupidity

So any post where the title calls a group of developers 'stupid' obviously is going to be full of bias and errors, so let's go through them.

It also supports JavaScript geolocation, which is (I hope) only the first step towards true device APIs that will give JavaScript developers access to phone functionality such as the camera, text messaging, the address book, and more. I’m assuming Apple is working on all that because it’s the next logical step.

That is a very poor assumption for one very important reason. Most people don't want to have their address book read in and text messages sent (at their expense) to all their contacts asking them to visit a website, after they themself visited that website. There's a very good reason websites don't get access to system APIs and this is it.

Safari’s support of appcache makes it possible to store the Web app’s core files on the iPhone itself, so that it only has to download the data. Thus mobile connection problems can be avoided.

But then you need a cache of the data stored locally and the ability to modify the data locally, meaning your web app needs to be run locally. What we have there is a mobile app built with web technology.

Best of all, if you want to update a Web app, you just put the updates on your Web server. There’s no need to wait for Apple’s broken approval process. iPhone developers are stupid because they’re wilfully ignoring all this.

This may be veering off slightly, but 90% of the issues with the App Store process are due to the length of time. If you got a response within 24 hours of submission and you could get a speedy response when you appeal then most of the issues would go away. So yes a web app fixes that by allowing you to update on your server.

However, you then have to pay for that server. Many web developers forget two key things about desktop/mobile development:

1. Scalability isn't an issue as you gain more processing power with each user, on the web you reduce the processing power each users gets with each new user.
2. You aren't having to also pay for the computer the application will run on, nor the resources it will use.

These two facts lead to one highly important factor for a lot of desktop/mobile developers: your expenses are lower.

Now this isn't saying that you should therefore never make a web app. Web apps are needed in many cases, but they aren't the be all and end all.

More Stupidity

Still, the graphically simple games such as sudoku and chess, the interactive shopping lists, the dictionaries and bible citation apps, the beer appreciation apps, the firmware Yahoo weather app, and most importantly all social network clients could have been written as a Web app without any loss of quality whatsoever. (Most have fairly little quality to lose in any case.)

This I have to strongly disagree with. If the web provided an equal user experience to the desktop then why do desktop clients exist? Why do people buy Lighthouse Keeper when they could use Lighthouse? Why am I writing this in MarsEdit instead of my blog's admin panel? Why are most of the tweets I see proclaiming "the end of the desktop/mobile" posted from desktop/mobile Twitter clients and not the web UI? The fact is that the web is a LONG way off matching the user experience that can be delivered on the desktop/mobile

In addition to avoiding the App Store and its insane policies, such Web apps would (mostly) work in any modern browser, whether desktop or mobile, and users of other phones or even of old-fashioned desktop computers could have used them, too.

Oh dear. The issue with this argument is that you have to build to the lowest common denominator. Sure you can have your site gracefully scale back. This blog you're reading will have a drop shadow around it and rounded corners. Of course in other browsers in may not have these. The issue is that Peter wants to have it both ways, but he can't.

You can't on the one hand laud the advanced features of Webkit in Safari (Webkit in other browsers can vary widely) while on the other hand say that your apps will work in any browser. People talk about the web as being the platform, but really the platform are the rendering engines such as Webkit (Safari, Chrome, WebOS), Gecko (Firefox, Camino) and Trident (IE), and they all just happen to support the same languages for some stuff (which is no different to Windows, OS X and Linux all supporting C).

Developers like their stuff to reach as many people as possible, right? That makes sense from both a business and an ego perspective, right? Then why do iPhone developers jump through burning hoops as nasty as the App Store approval process just to make sure that their stuff can only be used on one single platform instead of many?

That depends. Can I offer the best user experience while supporting these multiple platforms? Building a general web app that will run well in any browser is much like building a desktop app using Java, it often leads to an inferior user experience as you can't provide a consistent feature set and use advanced features of each OS it runs on. Personally I'd rather develop for one platform and build a kick ass application than develop for a wide audience on multiple platforms and build a mediocre application.

The Web

The plan failed. Jobs Himself ordered His developers to create Web applications with Web standards, but a deafening silence ensued. Then He hurriedly thought up the App Store. Too hurriedly, as it now turns out.

It's far-fetched to believe that Apple only thought up the App Store after they saw the reaction to the announcement of making web apps for the iPhone. The amount of time to build the APIs, the developer tools, the infrastructure, work out the marketing and the legal issues probably means they'd been planning this since before the first iPhone was released.

The "build web apps" announcement felt more like a stop gap measure. More a case of "stop hounding us about developing for the iPhone, if you really MUST develop for it right now then we've added a few small things to make it easier to build a web app for it".

I remember the ecstatic reaction to the announcement, because it was the very first time a major industry leader mentioned Web standards in a major presentation.

Oddly, I remember the reaction being more along the lines of "WTF?", but this goes to show the different reaction of the two communities.

Besides, Apple does not reach out to Web developers at all, and Web developers respond by not bothering with Apple beyond making sure their Web sites work in Safari.

So the fact that Webkit is probably the most open part of Apple means nothing?

I believe that Apple is working towards its own heavily CSS-centric Web OS, certainly for mobile, possibly also for the desktop, and that this evolution has been slowed down by the energy devoted to the App Store as well as the complete lack of outreach.

And I believe that they're also working on an iPony and odd as it may seem, I think that the iPony is more likely. The reason is that desktop tech has many advantages over web tech, the primary one being that it is much richer in both APIs and toolsets.

Arrogance

The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies. That’s nothing new. Most X developers (for any non-Web value of X) live in mortal fear of the browser as a development platform.

What we see here is what Peter and many other web idealists believe: that web technology is the best tool for every job. The fact is that it isn't. The only people who live in mortal fear of the browser are those who get caught up in the idea that web technology is somehow the holy grail of software development.

After ten years I am fucking tired of the “Web development is not real programming” bullshit that the arrogant bastards in “real programming” are spouting because they’re too frightened to learn something new. Fuck those condescending, ignorant, self-important, stupid, blind, fearful pricks. Fuck them real hard. Where it hurts.

As someone who has done both web and desktop development, I can see where the "web development is not real programming" idea comes from. The APIs and tools for writing, debugging and testing web technologies are a long way behind the tools for desktops. Those technologies that have the most advanced tools are ones that many web idealists deplore, such as Silverlight and Flash. It is very much real programming, it is just programming with a relatively young set of tools and APIs.

As for the arrogance that Peter talks about, any amount of arrogance on the part of desktop developers over web technologies is matched by the arrogance of web developers over desktop technologies. For every "web dev isn't real programming" quip there is a "the desktop is dead" remark. It's an eternal pissing match over who has the best lego set, completely missing the point that you can usually build something much better using the best pieces of both lego sets.

The myth

The poor, oppressed iPhone developer suffering under Apple’s heavy App Store hand is a myth invented by these developers themselves because they’re too fearful to look beyond their “native” fetish. The Web is patiently waiting in the wings like a spurned bride, quietly promising to solve all of their problems for them if they’d only look at her.

If the web really was some magical beast that would produce money from nowhere, cure cancer and give everyone a blowjob then that might be the case. But the thing is that web brings with it a whole new set of problems and doesn't really fix the most important one, which is how to build the best application possible. The web is a screwdriver to the desktop's hammer. They're both tools and if you're building a great house you'll need both.

The last heading

OK so the rebuttal is done. But it is worth reiterating for both sides of the argument: I don't believe the desktop or the web is the one true platform. The one true platform is the internet. The future isn't web apps or desktop apps or mobile apps, but all 3 that can work together. Web apps are best for when you're away from your normal computer and just need to check up on something. Desktop and mobile apps are best for providing a rich user experience and raw speed.

Everyone agrees that most of the processing needs to take place on the client, this is why most of the new web technology seems to focus on getting web apps "off" the web. This is simply going the other direction to desktop apps, where they are getting connected to the internet.

It is best to use each platform to their advantages. This is why I have Code Collector Pro, which focuses on organisation and using code snippets, as a desktop app but I have codecollector.net, which focuses on sharing, as a website. It wouldn't work anywhere near as well the other way around because they would both be playing the weaknesses, not the strengths of their platforms.

And this is why it is a pointless war. Neither side will win because the major strength of one side is the fundamental weakness of the other. They aren't at odds with one another, they complement one another perfectly. And when the idealists on both sides of the spectrum wake up to this we'll be able to stop the bickering and start making some great apps. And I'll be able to get through a full year without the urge to write another one of these bloody blog posts on the topic!

(3) Comments

---

Xcode is the primary development tool for any Mac or iPhone developer and is where we spend much of our time. As such new versions that bring new goodies are like Christmas for many developers. The fact that the version number has gone from 3.1 to 3.2 is deceptive to the huge amount of improvements that have been added.

Clang LLVM 1.0

For a lot of developers, a compiler isn't really much to get excited over. It takes your code, checks it, optimises it and converts it to something the computer can read. Usually any updates to the compiler just improve compile times a bit, optimise your code a bit more, fix some bugs or add a few more options.

However, LLVM has got a lot of people excited. It debuted in 10.5 with the LLVM GCC 4.2 compiler. This used LLVM for the optimising and converting to machine code (the back end) and GCC for the checking the code (the front end). New in Snow Leopard is the Clang front end.

But just being new isn't cause for celebration unless it does something worthwhile to use it over the older, more mature compiler. Thankfully it does, and it does it in huge strides rather than small increments. Clang LLVM 1.0 is possibly the biggest improvement to any tool in a Mac or iPhone developer's toolset since OS X was first created.

First off, it is FAST. Take your current GCC compile times and reduce the time by about 40-50%. This is a crazy speed improvement for something that is doing essentially the same job.

Secondly, it makes your code faster. It adds a new optimisation level that performs link-time optimisation. This allows it to do many more cross file optimisations. Anything that can make your app run faster without having to change any code is very welcome.

And lastly, it produces sane and actually useful error messages. For a long time we have had to put up with GCCs rather cryptic error messages. It would tell us there is an invalid binary operation with a + sign on a certain line, but if there are multiple + signs on that line then it is fairly useless. Clang tells you exactly which + sign is at fault.

If you passed in the wrong type into a function or method then GCC would tell you that there is a type mismatch. Clang tells you which argument, what type you're passing in and what the type should be.

And finally, the single best improvement in error handling is that you miss a semicolon from the end of a line, Clang will tell you the exact line it is missing from, unlike GCC which will put the error on any line except the line the error actually is on.

But Clang's introduction as a new front end isn't just good for speed and error messages. It is licensed under the BSD open source licence, meaning that Apple can integrate it tightly into Xcode. This means they can use the exact same language parser for compiling as they do for code completion, refactoring etc. This could lead to a huge number of great new features in Xcode to bring it truly up to par with the likes of Visual Studio and Eclipse in terms of its knowledge of your code.

Static Analysis

One of the new features that Clang makes possible is the new Static Analyser. You may have heard about and used the Clang Static Analyser from the command line in Leopard, well now Xcode includes it and provides a nice GUI for it.

So what is static analysis? Well it is the analysis of your code to search for common bugs. It doesn't actually launch your code and run it to test (hence the static). It can find all sorts of errors such as code that will never be called, possible memory leaks or crashes. Because it can search multiple paths through your code very quickly it can find bugs that you would never be able to find on your own and also point out assumptions you have about your code that aren't explicitly written in your code.

New Build Window

While Xcode has got quite a few new goodies, most of the stuff to get excited over are improvements to old features. Perhaps the single biggest improvement over Xcode 3.1 is the build results window. To start with, it just looks great. I can only hope the rest of Xcode gets the same cosmetic treatment at some point in the future.

But this isn't just looks. You no longer lose older warnings when you re-compile. The new filter bar at the top allows you to view all warnings and errors in your project since you last did a clean and build. And best of all, it persists across launches! You can also choose how you want the view to be grouped, either by the build step or by the type of issue that is showing up.

It also improves unit testing by no end. As you can see in the above screenshot, it now gives you details about how many tests passed out of how many ran and how long it took. It also allows you to see the full text of the error without having to go and search through the full text build log (which as far as I can see, actually isn't accessible any more, but pretty much everything you care about is accessible through the details buttons for each warning or error). This essentially fixes all my issues with running unit tests in Xcode.

New Inline Errors

I previously mentioned that error messages had been improved if you use Clang as your compiler. Well that isn't the only improvement to errors. The inline error bubbles introduced in Xcode 3.0 have been massively improved. They were always a great concept, but they caused all sorts of problems, the key one being that they reflowed your code. Well not any more.

As you can see they are put at the right of the code view, with the full line highlighted. You may also notice a small red arrow under the "e". This is thanks to compiling with Clang, which tells you precisely where the error is. This fixes pretty much every issue with the error bubbles from previous versions.

Improved Documentation

Every developer needs to read documentation, but the documentation viewer in Xcode has long been one of those things Apple has struggled to get right. The incarnation in Xcode 3.0-3.1 was reasonably useful but somewhat awkward at times and used up a lot of valuable vertical screen space for displaying search results.

The new documentation viewer is a huge improvement, though it may take some time to get used to. The whole documentation set download system has been moved from the documentation window and into the preference window. It also allows for custom doc set feeds to be added, which I don't believe was available previously. [UPDATE] Apparently this was new in Xcode 3.0

With the left side of the window freed up, search results can now be displayed there. Results are now grouped by how they were found, either by API, title or full text. It also only shows the most likely matches and hides less likely matches until you want to look at them. Coupled with this is the fact that the full doc set has been updated to the new style that was introduced with the iPhone SDK, which is a much nicer layout.

One thing that Xcode doesn't do any more is install a huge collection of developer samples. Instead you can search for samples via the documentation viewer and download them. It is nice that you have a bit more disk space, but I think this is outweighed by the fact that you have to re-download all the sample code you used. It would be nice if they had included some of the more venerable samples by default.

Xcode 3.2 also does away with the research assistant, which I always found a useless piece of carp. It replaces this with a new pop up doc panel, which is reasonably useful. This is accessed by the option double click that usually performed a search in the documentation viewer (the shortcut for this is now command-option double click).

Other Bits & Bobs

There are lots of other little improvements all over the place. For one, the code completion has improved dramatically and is far more accurate than before. No longer will you get isEqualToSet: appearing as a completion for a variable that is an NSString.

The new project and new files panels have also been improved a huge amount, with small variations on a certain project or file type being moved to an options bar. You can add options for your own templates quite easily, they are only managed by a plist file. Unfortunately I can't find any official documentation on it, so for now it is a case of seeing what Apple has done and copying it.

In the world of multi-touch trackpads, Xcode isn't being left behind and now has a few gestures of its own. Much like with other browsers, 3 finger swiping left or right will move back or forwards in the history. However, 3 finger swiping up or down now moves between the header and documentation windows, which is a great new feature and one I wish I could have on my iMac.

Speaking of file history, the history now stores location within a file as well as the actual files you accessed, giving you a much more fine grain control of going back to where you were.

The old find panel has been replaced by a Safari style find bar, which removes yet another piece of needless clutter. It still supports all the stuff you expect such as regular expression search. It also has a rather nice bezel that comes up when your search loops back to the top of a file which is a nice touch.

This reminds me of another thing that has been improved. I wouldn't class myself as a designer, but I am anal about pixels in a user interface. Xcode 3.1 and lower didn't use a standard search field, but instead had a fake field. The magnifying glass was too big and the edges weren't properly anti aliased. This drove me mad, as when I notice things like that I will forever notice them (such as when iTunes had one corner not being antialiased on its window). Anyway, this is now a standard search field now, so the pixel anal side of me can now rest easy at night.

There is one last thing that has changed, which is kind of significant. For decades the standard monospace font for coding on a Mac has been Monaco. In Snow Leopard apple introduced Menlo, a new font based of DejaVu Sans Mono. It is meant be designed with Objective-C in mind, and in deed some characters do seem to be improved a lot over regular DejaVu, such as the square brackets which are much crisper.

The big problem is the * character. Call me a traditionalist but it should be a superscript character, and in Menlo it isn't. It isn't like it is a rarely used character when coding, you use it everywhere and it really grates me. I tried Menlo for a few hours and then had to switch back to using regular DejaVu. It may be nice for some, and it does indeed have some nice improvements that even I, as someone who isn't really a font geek, can notice.

Overall

In a nutshell Xcode 3.2 is easily the best update to Xcode to date. Given the scale of the improvements and the fact that it needs a new OS, it is puzzlingly that they haven't called it Xcode 4.0. I can only assume that if this is what Apple thinks warrants a .1 increase in the version number, then Xcode 4.0 will be a huge improvement.

Like with the rest of Snow Leopard, Xcode 3.2 is a release that is built around polishing what is already there and introducing new technologies upon which the next decade worth of software can be built. I believe what we have seen thanks to the release of Clang is only the tip of the iceberg compared to what could be possible. We may now be up to version 3.2 of Xcode, but we are only just beginning to see what Xcode could become.

(20) Comments

---

In case you hadn't quite noticed yet, Mac OS X 10.6 was released today. All M Cubed apps have been tested and work fine on Snow Leopard in their current versions so you'll be able to feel safe upgrading.

However, if you do find bugs you will be able to tell us about them in our brand new support centre. You can still email us if you wish, but we also offer discussion forums that allow you to start public or private discussions that will allow you to get help from both us and other users of our software.

On top of this our new system has an integrated knowledge base. We currently have only migrated the CCP and LHK manuals over, but we will put up all sorts of useful tips and tricks in due course, so head over to support.mcubedsw.com to check it out.

(0) Comments

---

One of the perennial topics in the Mac developer community is that on whether dot syntax is a good idea. Reading through blog posts and twitter feeds an unfamiliar observer would deduce there that this is a Marmite issue: you either love it or hate it.

The problem is a lot of people familiar with the topic also see it as that, but the truth is quite different and there are some subtleties in the argument, particularly the dislike camp of which I am a member, that are often over looked. I'm hoping this blog post will give a better idea of why people, or at least I, dislike dot syntax.

History/Programming Lesson

For those unfamiliar with it (or those who don't program) I'll give a brief history and overview of the technology that causes the problem. Feel free to skip this section if you are already familiar with this tale.

In object oriented programming (OOP) you store variables (containers for data) within classes (containers for variables and methods, or actions upon that data). One of the key concepts is encapsulation, which means that these classes are black boxes and you cannot directly access the variable, but instead have to call a method to get to the data. Think of this as a bit like a cash machine, where you don't directly get the money, but instead use an interface to ask for the money and then receive it. These sorts of methods go under many names: accessors, getters and setters, properties etc.

In versions of Mac OS X prior to 10.5 writing these methods required writing a lot of code that is almost identical for each variable. For example, the code for accessing the variable foo would be:

//Header
- (id)foo;
- (void)setFoo:(id)newFoo;

//Implementation
- (id)foo {
    return foo;
}

- (void)setFoo:(id)newFoo {
    if (foo != newFoo) {
        [foo release];
        foo = [newFoo retain];
    }
}

There are many variations on these methods but they all do the same thing, either return the contents of a variable, or replace the contents with a new piece of data.

You can probably tell that writing that over and over can get tedious, when there are only minor differences you can make, usually in memory management or thread safety. So in Mac OS X 10.5, Apple introduced Objective-C 2.0 which featured, amongst other things, properties. This allowed the simplification of the above code to:

//Header
@property (retain) id foo;

//Implementation
@synthesize foo;

Much simpler. It also adds extra information that wasn't previously there, such as the type of memory management used and whether it is thread safe or not.

Now while this brought almost universal praise, Apple also introduced a new syntax for accessing these properties: dot syntax. This allowed programmers to use properties in a different way:

//Standard way
variable = [object foo];
[object setFoo:variable];

//Dot syntax way
variable = object.foo
object.foo = variable

Implementation vs Idea

For the purpose of explaining why people feel a certain way about dot syntax in Objective-C it is important to distinguish between implementation and idea. In this case, dot syntax is the implementation. The idea is a simpler way to use properties. A lot of the complaints are not with the idea, but with the implementation.

Another example of this in Objective-C 2.0 is garbage collection (automatic memory management). There are a lot of people who are wary of using garbage collection. Some are wary because they are used to the idea that garbage collectors are much slower and less efficient than manual memory management (in most cases the opposite is true with the Objective-C garbage collector), but this stigma of the idea of garbage collection remains.

Then there are people who are wary of the implementation. They feel that it is a major commitment to something that is relatively untested. I had a discussion a few days ago where a programmer started writing a garbage collected app and then found a bug with no work around other than "wait until Apple fixes it", so he had to go back through his code and switch to manual memory management.

In this case this is a complex piece of technology that is quite new and can seriously harm your project's shipping date if you encounter a bug with no work around. Now before people get the idea that I'm anti-garbage collection, I'm not. I'm using it in Minim 2.0, but this is only because it has been around for 2 years now, and many bugs have been fixed in updates to OS X 10.5. The garbage collector in Objective-C is great, it is just a 1.0 release.

Anyway, enough with the small detour into garbage collection, that isn't the main topic of this post. However, it has offered us a good example of why someone may dislike an implementation, one that is different to why most developers dislike dot syntax. Developers are wary of garbage collection because it is new. Developers dislike dot syntax because they believe it is flawed.

Why Dot Syntax?

There are many reasons one can suggest for why Apple chose dot syntax. The most obvious is that it is somewhat similar to how other languages work. Whereas Objective-C uses [object method] to run a piece of code, lots of other languages use object.method(), and some even allow identical object.property = newvalue syntax for variable access.

It is this familiarity that may help programmers move from other languages. Unfortunately this isn't necessarily the case. Dot syntax is inconsistent, working for methods that aren't properties. It also can cause confusion between objects and C structs (more on this later). I have seen several new programmers get confused by this, as they can use dot syntax for certain methods, but not for others. There are even pro-dot syntax developers who agree that it shouldn't necessarily be taught to new Objective-C programmers until they have got a good grasp of the language.

Now there is an argument against those of us who are anti-dot syntax, that we are simply Objective-C old hands who are opposed to change. This isn't the case. There are many people who have been using Objective-C since before Apple had anything to do with it who are using dot syntax and there are those who only started with it a few years before dot syntax arrived that dislike it. I only started programming in Objective-C 5 years ago, not exactly an old hand when you consider Objective-C is over 20 years old.

The other reason why this isn't true is that these programmers embrace all the other changes. They use properties and fast enumeration and garbage collection. They use new APIs and new tools. A lot of these "luddites" who are supposedly opposed to change are actually the ones at the forefront of change. The difference is that change can be for the worse or for the better, and while they believe most of Objective-C 2.0 is change for the better, dot syntax is change for the worse.

State vs Action

Now one argument for the idea of a separate syntax for property access is that it helps separate state and action. This is quite useful in places as you can tell when state will change, which is useful for many things, but importantly thread safety. For the most part I agree with this, but I believe there are issues.

The biggest is simply an issue of how you conceptually view your program working. Those who are fully behind the state vs action system see [object doSomething] and object.property as different things. One is performing an action, one is accessing state. I see things at a more abstract level, where both those are simply sending a message to an object, so they are identical in what they do. This is somewhat anal, but it is how quite a few developers feel.

Structs

I made a tweet that proved to be quite controversial, saying that I thought developers who think dot syntax is a good idea don't do much UI coding. The reason behind this idea is that UI coding requires the usage of C structs. A struct is a simple container for several pieces of data, and in some ways is a sort of lightweight class. It is because it is lightweight that it is used all over the UI side of Cocoa for defining rectangles, sizes and points.

So what is the issue? Well this is how you access a struct:

variable = struct.field;
struct.field = variable;

Looks familiar, doesn't it? This is the biggest issue, the fact that struct and property access is identical. If you look at the following, would you be able to tell me which is the struct and which is the property?

a.b = foo;
c.d = bar;

Of course that example is a bit contrived so let us look at something that you may actually find in Cocoa:

rect = controller.view.frame;
rect.size.x = 10;
controller.view.frame = rect;

Now an experienced Cocoa developer could tell you that controller and view are objects and rect and size are structs, but someone new to Cocoa couldn't tell the difference.

Of course we could just get rid of structs and use objects for everything, couldn't we? Unfortunately no. Structs are relatively lightweight when compared to objects, so are ideal for tasks such as defining a rectangle when you only need to collect 4 values into 1. You don't need all the unnecessary cruft of creating an object, so it makes your code faster and your memory usage smaller (granted these aren't as big an issue with modern computers, but there is no point slowing things down).

The other issue is that Objective-C is also C. Anything valid in C is valid in Objective-C, and structs are part of C. There is no getting rid of them. You could get rid of them from Cocoa, but you would still be mixing object.property with struct.field.

Of course this confusion can potentially be dangerous. struct.field is simple memory access/assignment, you cannot make it do more. However, object.property isn't necessarily just memory access/assignment (technically it almost never is). There could be file access, network access etc. happening under the hood, but you see the same thing. This confusion can be potentially damaging.

[UPDATE] Note, that while I mention object.property, I don't imply that accessor methods will be doing resource intensive tasks, but the fact that dot syntax isn't limited just to properties means that object.method could be used and would be computationally intensive.

Conclusion

So what is the solution. Well as I said earlier, most developers don't have an issue with the idea of a different syntax for property access, the issue is with the implementation. The solution would have been to not overload the . character. There are many other ways that property access could have been done and most of the arguments above vanish if a different character is used. Why not foo~bar, foo•bar or foo@bar. None of those characters are used in binary operations in C or Objective-C.

The important point is, those who are against dot syntax aren't simply the old school who don't like change. They like change, they embrace change, but they just feel this is a change for the worse. You may feel differently about the syntax, but there are many significant cons to the current implementation, which is why there will always be those who dislike it. And all of those cons revolve around one character.

(8) Comments

---