[Reference counting] No garbage collection. Objective-C could still do more with respect to reference cycles, but that is primarily a non-issue, and easily solved in future versions.
I think if you solve this, you've implemented GC.
Which is not to say that you might not want some hybrid, but ref counting has its own downsides (caching, multi-threading) which the author does not mention.
[I]n a comparison with any popular scripting language, Objective-C will win, since while the scripting language may have superior syntax, it is also sure to be incapable of accomplishing many things which are trivially accomplished in Objective-C.
Such as?
The article is full of assertions which it doesn't attempt to justify, even with a link.
> I think if you solve this, you've implemented GC.
Not necessarily. There are lots of ways around this that don't involve garbage collection. There I was thinking specifically about static analysis suggesting Objective-C weak pointers in some cases. There are also runtime techniques (including assignment-time checking), memory profiler techniques, and the potential for simple new techniques that could make this discussion shorter. (This assumes you aren't classifying reference counting as a "garbage collection" method, which is sometimes done.) In any case, you are still in a better position than in a garbage collected language.
But that is a long discussion about garbage collection, and it is getting far afield from the subject, which is why the note doesn't go into it further. The main point is that how you handle reference cycles doesn't matter.
A good point. Coming from the iOS side I missed this. I mentioned Xcode's garbage collection in passing, but pointing out that garbage collection is deprecated on OS X would've made a strong argument that ARC is the better way to do things.
Agreed on your last point. I stopped reading halfway through because of all the (questionable) assumptions the author made.
I'm a massive fan of Obj-C and I think it could be a great tool for web development, but (other than potential advantages when interacting with Obj-C clients) I don't really see it as having any advantages over other platforms. Windows devs are never going to use Obj-C for their web development and I'm not really convinced OSX/Linux devs are not going to move away from Ruby/Python/PHP/Java, either.
> Windows devs are never going to use Obj-C for their web development
In the second half of the note there's a point about nearly 100% of web developers at major web companies using Macs. I'm not sure what percent of the web runs Windows (or was developed on Windows). The only major sites I know of that run Windows are the StackOverflow sites. Of course, that doesn't rule out Windows powering some reasonable percentage (including corporate backends), which I'm sure it does. It's just evidence that Windows isn't the pace setter.
> Ruby/Python/PHP/Java
PHP simply doesn't work for long-running processes. Java and Java-like languages tend to replace Ruby and Python for long-running processes on large sites, and that's the target here.
At one point Java was something Sun had to push to get people to use.
I'd love for a c/c++-based platform to overrule Java... but Objective-c isn't the right language:
- Apple is a company that likes to take control away from people, why give them more monopolistic power?
- You require a sub-decent xcode editor that only runs on mac computers. After spending around 2 years using xcode I can testify that its a piece of shit!
- Objective-c is overly verbose, horrible syntax (i.e. gluing the method name + first parameter).
Today, Apple can't even power themselves, iCloud runs on Amazon Cloud Services and Windows Azure.
In terms of language, can't see Apple wanting to take on the additional responsibility of supporting the Objective-C runtime and foundation frameworks on Linux and Windows. They can't even keep up with RADAR bug reports from existing developers.
Apple's track record on the web has been poor. Their websites are not first class. So they could have to build expertise there. I think, for backend services, networking expertise on the OS teams would go a long way.
In terms of staffing and responsibility, I don't see that as an issue, since if this does make sense for Apple, Apple is large enough that handling the workload wouldn't be a problem.
Some people have crazy ideas, and the world needs that. However, trading in Ruby or Python or [insert favorite scripting language] for Objective-C to write server code is a foolish idea that's divorced from reality (with some exceptions).
The vast majority of server code that is written is bit plumbing. Moreover, it's written by not-so-great devs who aren't gdb experts. The performance benefits of C-like languages are completely useless for all but a handful of companies like Google and Facebook. Unless you're doing heavy number crunching server side (which most web apps don't), there's no discernable benefit to using Objectiv-C or C/C++.
There are plenty of benefits to using Java or a scripting language though. The reasons are obvious to anyone techie enough to get this far.
Any dev who can write Java can write Objective-C, and there would be real benefit in switching.
> for all but a handful of companies like Google and Facebook
I think this is a mischaracterization. A lot of companies need something at Java's strength or above on the backend. It is a common problem. And organizations with those needs will account for the majority of web traffic.
> heavy number crunching
Also a mischaracterization. Even simple tasks become computationally challenging when you're doing them for a large audience.
> A lot of companies need something at Java's strength or above on the backend. It is a common problem.
A lot of companies believe they need "enterprise-class" software systems, but that doesn't mean they really do. 100 employees working with a database full of text are probably not going to overwhelm Python or Ruby on decent hardware. 100,000 might.
Isn't golang the new backend hipster? Compiled, concurrent, and google is the mommy. I would bet on golang not obj-C. As long as Apple forces people to buy apple hardware in order to make use of obj c it will not catch on.
This post has many generalizations and little technical content. The subject is interesting (for ObjC programmers mostly), but arguments are shallow.
> it was never an issue to port correct C/C++ code
In C/C++ there is no such thing as a portable application only applications that have been ported, even with standard compliant code. Try porting between Linux/Solaris/Windows and see by yourself.
> (paraphrased) Backend apps should be written in Objective-C instead Java, let's rewrite them!
Before making such bold statements about rewriting applications, what can you tell me (if anything) about the speed of a server JVM compared with Objective-C? And this is really a broad question, since for starters, languages don't scale, architectures do. Your outdated SO link doesn't begin to answer. See this general benchmark http://shootout.alioth.debian.org/u32/which-programs-are-fas... and add to that Objective-C message passing. And then think how it translates to server code. Just food for thought.
> Java API replicates the entirety of the UNIX system layer in Java-ese, obscuring any helpful C idioms or UNIX-system knowledge in the process
Because you think that those idioms and platform specific code won't be an issue when ported, or they will be plenty of devs familiar with that, which isn't the case. Most programmers out there use Java because they couldn't code their way out of a paper bag.
> You cannot postpone garbage collection forever. This is a disaster for applications that need to scale.
Nope, GC happens incrementally, and it's not a disaster for scalable Java applications that are deployed now in the real world.
> Oracle now owns Java and is a hostile entity. Java is done. Its future as a product is finished. Whatever your relationship is with Java now, expect it to deteriorate.
Completely wrong. JDK 8 lambdas will be feature completed in January 2013, and if you are an Objective-C programmer, you know how much of a change it brings to the language. And we have Jigsaw, project coin, java.util.concurrent with CAS, and countless JSR. Java has better health than ever, ask around.
> Web shops won't go for Apple servers. All the development, all the monitoring, all the operational knowledge is based on a few varieties of Linux.
It's the cost, not the knowledge. Also if you are a linux admin you get the same toys in Mac. An Apple desktop makes sense because it's less likely to interrupt the work of someone with a salary, but a farm of web servers based on Linux is cheap and easily replaceable. The best contribution of Google to the "open" world was to show that you can scale on Linux.
And this makes me think, given that Apple makes money selling hardware, where is the motivation to compete with Java/.Net promoting server frameworks? This is all about us buying Apple hardware people, don't forget.
> developers who worked at Etsy when I was there, 100% either used a Mac to develop or use a Mac to develop now. This preference is standard in the industry.
Most devs in the planet are behind a cheap HP/DELL PC. Otherwise we would know based on StackOverflow logs and sites like that. You could say best devs use laptops, because that's at least what we see in dev conferences.
> PHP is (or was) the dominant web scripting language by a large margin. This happened because of performance and ease of use,
Java couldn't compete because JVM required 128MB RAM, and one app on a shared JVM instance could bring down the rest, so Java was dangerous and cost prohibitive for small sites.
> If I had to run a monolingual web stack, I would choose Objective-C for the sole language.
This article is severely undermined by its conflating internet and web. Objective-C doesn't have a significant presence in the browser, and is consequently a useless language for achieving a monolingual web stack. The article demonstrates a complete lack of awareness of the frontend side of the web and assumes that iOS apps are this frontend. There is not a single mention of JavaScript, or even the word "browser".
It also seems to be overly focused on the idea of computational performance, when in many cases applications are IO-bound. The descending cost of compute power means this efficiency edge in computation is decreasing in importance. Also, no mention of things like PyPy? Overall, the article has a very narrow-minded and misguided view of the web.
18 comments
[ 2.5 ms ] story [ 47.3 ms ] threadI think if you solve this, you've implemented GC.
Which is not to say that you might not want some hybrid, but ref counting has its own downsides (caching, multi-threading) which the author does not mention.
[I]n a comparison with any popular scripting language, Objective-C will win, since while the scripting language may have superior syntax, it is also sure to be incapable of accomplishing many things which are trivially accomplished in Objective-C.
Such as?
The article is full of assertions which it doesn't attempt to justify, even with a link.
Not necessarily. There are lots of ways around this that don't involve garbage collection. There I was thinking specifically about static analysis suggesting Objective-C weak pointers in some cases. There are also runtime techniques (including assignment-time checking), memory profiler techniques, and the potential for simple new techniques that could make this discussion shorter. (This assumes you aren't classifying reference counting as a "garbage collection" method, which is sometimes done.) In any case, you are still in a better position than in a garbage collected language.
But that is a long discussion about garbage collection, and it is getting far afield from the subject, which is why the note doesn't go into it further. The main point is that how you handle reference cycles doesn't matter.
http://en.wikipedia.org/wiki/Objective-C#Garbage_collection
I'm a massive fan of Obj-C and I think it could be a great tool for web development, but (other than potential advantages when interacting with Obj-C clients) I don't really see it as having any advantages over other platforms. Windows devs are never going to use Obj-C for their web development and I'm not really convinced OSX/Linux devs are not going to move away from Ruby/Python/PHP/Java, either.
In the second half of the note there's a point about nearly 100% of web developers at major web companies using Macs. I'm not sure what percent of the web runs Windows (or was developed on Windows). The only major sites I know of that run Windows are the StackOverflow sites. Of course, that doesn't rule out Windows powering some reasonable percentage (including corporate backends), which I'm sure it does. It's just evidence that Windows isn't the pace setter.
> Ruby/Python/PHP/Java
PHP simply doesn't work for long-running processes. Java and Java-like languages tend to replace Ruby and Python for long-running processes on large sites, and that's the target here.
At one point Java was something Sun had to push to get people to use.
- Apple is a company that likes to take control away from people, why give them more monopolistic power? - You require a sub-decent xcode editor that only runs on mac computers. After spending around 2 years using xcode I can testify that its a piece of shit! - Objective-c is overly verbose, horrible syntax (i.e. gluing the method name + first parameter).
Today, Apple can't even power themselves, iCloud runs on Amazon Cloud Services and Windows Azure.
In terms of language, can't see Apple wanting to take on the additional responsibility of supporting the Objective-C runtime and foundation frameworks on Linux and Windows. They can't even keep up with RADAR bug reports from existing developers.
In terms of staffing and responsibility, I don't see that as an issue, since if this does make sense for Apple, Apple is large enough that handling the workload wouldn't be a problem.
The vast majority of server code that is written is bit plumbing. Moreover, it's written by not-so-great devs who aren't gdb experts. The performance benefits of C-like languages are completely useless for all but a handful of companies like Google and Facebook. Unless you're doing heavy number crunching server side (which most web apps don't), there's no discernable benefit to using Objectiv-C or C/C++.
There are plenty of benefits to using Java or a scripting language though. The reasons are obvious to anyone techie enough to get this far.
> for all but a handful of companies like Google and Facebook
I think this is a mischaracterization. A lot of companies need something at Java's strength or above on the backend. It is a common problem. And organizations with those needs will account for the majority of web traffic.
> heavy number crunching
Also a mischaracterization. Even simple tasks become computationally challenging when you're doing them for a large audience.
A lot of companies believe they need "enterprise-class" software systems, but that doesn't mean they really do. 100 employees working with a database full of text are probably not going to overwhelm Python or Ruby on decent hardware. 100,000 might.
You state a lot of opinions as facts and give zero justification.
> it was never an issue to port correct C/C++ code
In C/C++ there is no such thing as a portable application only applications that have been ported, even with standard compliant code. Try porting between Linux/Solaris/Windows and see by yourself.
> (paraphrased) Backend apps should be written in Objective-C instead Java, let's rewrite them!
Before making such bold statements about rewriting applications, what can you tell me (if anything) about the speed of a server JVM compared with Objective-C? And this is really a broad question, since for starters, languages don't scale, architectures do. Your outdated SO link doesn't begin to answer. See this general benchmark http://shootout.alioth.debian.org/u32/which-programs-are-fas... and add to that Objective-C message passing. And then think how it translates to server code. Just food for thought.
> Java API replicates the entirety of the UNIX system layer in Java-ese, obscuring any helpful C idioms or UNIX-system knowledge in the process
Because you think that those idioms and platform specific code won't be an issue when ported, or they will be plenty of devs familiar with that, which isn't the case. Most programmers out there use Java because they couldn't code their way out of a paper bag.
> You cannot postpone garbage collection forever. This is a disaster for applications that need to scale.
Nope, GC happens incrementally, and it's not a disaster for scalable Java applications that are deployed now in the real world.
> Oracle now owns Java and is a hostile entity. Java is done. Its future as a product is finished. Whatever your relationship is with Java now, expect it to deteriorate.
Completely wrong. JDK 8 lambdas will be feature completed in January 2013, and if you are an Objective-C programmer, you know how much of a change it brings to the language. And we have Jigsaw, project coin, java.util.concurrent with CAS, and countless JSR. Java has better health than ever, ask around.
> Web shops won't go for Apple servers. All the development, all the monitoring, all the operational knowledge is based on a few varieties of Linux.
It's the cost, not the knowledge. Also if you are a linux admin you get the same toys in Mac. An Apple desktop makes sense because it's less likely to interrupt the work of someone with a salary, but a farm of web servers based on Linux is cheap and easily replaceable. The best contribution of Google to the "open" world was to show that you can scale on Linux.
And this makes me think, given that Apple makes money selling hardware, where is the motivation to compete with Java/.Net promoting server frameworks? This is all about us buying Apple hardware people, don't forget.
> developers who worked at Etsy when I was there, 100% either used a Mac to develop or use a Mac to develop now. This preference is standard in the industry.
Most devs in the planet are behind a cheap HP/DELL PC. Otherwise we would know based on StackOverflow logs and sites like that. You could say best devs use laptops, because that's at least what we see in dev conferences.
> PHP is (or was) the dominant web scripting language by a large margin. This happened because of performance and ease of use,
Java couldn't compete because JVM required 128MB RAM, and one app on a shared JVM instance could bring down the rest, so Java was dangerous and cost prohibitive for small sites.
A better way than what? Erlang/Akka Actors? Java concurrent libraries? Clojure STM? Single-threaded async callback fest?
Threading for OO?
I'm not even sure what the author is comparing Obj-C for web developement to.
This article is severely undermined by its conflating internet and web. Objective-C doesn't have a significant presence in the browser, and is consequently a useless language for achieving a monolingual web stack. The article demonstrates a complete lack of awareness of the frontend side of the web and assumes that iOS apps are this frontend. There is not a single mention of JavaScript, or even the word "browser".
It also seems to be overly focused on the idea of computational performance, when in many cases applications are IO-bound. The descending cost of compute power means this efficiency edge in computation is decreasing in importance. Also, no mention of things like PyPy? Overall, the article has a very narrow-minded and misguided view of the web.