[bsaul]

The fact that the site is still down makes wonder what they're doing.

Provided that the hacker did report all the security bugs to Apple, one could suppose that it would only require of couple of days to fix the bugs, put the site back online, and start performing a full security audit along with massive code rewrite in parallel.

The only reason i see why they would still be offline, is that they instead decided to rewrite some crucial portion of the code from the ground up (which is what the email they sent the other day would suggest). But 1 week in emergency mode for a company like Apple really means rewriting TONS of code...

<offtopic> Anyone know the state of Objective-C on the server ? I really like that language now that it has ARC, and i wonder if apple is still using that technology on the server side </offtopic>

[kylebrown]

It was a really bad idea to plan a "complete overhaul" and "rebuild" everything, over the weekend. Some manager must've thought that they could wave a wand and get shit done.

[nwh]

They certainly aren't using WebObjects for everything, so I can't imagine they are particularly happy with it. Little bits of it are PHP for example, like the file search on the main page:

    https://developer.apple.com/search/index.php?q=HN

[bsaul]

That URL is SO depressing...

It could almost be the masterpiece of a tumblr blog on top technology companies using crapware for themselves.

[martinml]

In 2011 it took Sony about a month to restore PSN services after its infamous breach: http://en.wikipedia.org/wiki/PlayStation_Network_outage#Time...

[threeseed]

The developer portal is written in WebObjects/Java.

And whilst I am sure they are using Project Wonder which wraps up a lot of the old WebObjects code there is still the fact that it is a deprecated technology.

And it's never just write some code and deploy in these situations. It will involve testers signing it off, performance testing, security testing, deployment etc. So all those parts add up. Plus there's no "Steve Jobs will fire you" threat breathing down your neck.

[bsaul]

It really amaze me that Apple didn't and continues not to invest more on server side technologies, knowing how much apps are connected today (i can't find a single app that doesn't talk to a server one way or another).

I mean, we all know the sad state of server-side development compared to client-side (x), yet it took a personal project for Google to create Go, it took a legal issue with java for Microsoft to start working on C#, and Apple still got nothing.

(x) : not wanting to launch a flame war, but the fact that people at Google created both Go and Dart in the last 5 years does say something, not to mention the countless "Java+" languages like scala or groovy. Also, by client-side i mostly mean objective-c on xcode, which has really become a joy.

[protomyth]

I do wish they had converted WebObjects back to Objective-C and released EOF with it. It would have been nice to write the app and the server code in the same language and environment.

[bsaul]

Completely agree. Objective-C with ARC and blocks has the perfect blend of dynamic language + static typing that i'm looking for (although the syntax really feels like a hack).

Now, libraries for the server are clearly not there, and i suppose that you would need to write them in C to get descent performances, which is unrealistic i guess.

[gecko]

EOF, sure, but WebObjects in general? You don't actually want that. You just think you do.

Look: WebObjects was amazing at the time. But have you used it recently (meaning in the last several years) to write something? Because it's almost literally impossible to write something that looks modern and acts modern.

WebObject was designed to hide web development as much as possible from the developer. I.e., to make writing desktop applications and web applications as similar as possible. You'd make a view in HTML, a controller in Objective-C (or later Java), draw connections between them just as if you were making something in Interface Builder, etc. Basically, HTML just became another OpenStep view you could target.

The downside of hiding the web part of web development as much as possible is you get a technology that is very far removed from modern practice. To achieve the view/controller design pattern above, WebObjects effectively effectively uses a continuation-like pattern to hide the whole HTTP request/response loop. That's why WebObjects URLs are disgusting beasts: they tell WebObjects what state corresponds to what you're doing. ASP.NET WebForms does this same thing, by the way, although it slaps its data (called ViewState) into invisible form elements on the client-side, whereas WebObjects stores its state server-side. Former inflates the page by 30k in even simple situations, latter makes the server need tons of RAM, but they both get you to the same place, and about equally well.

The problem is that's not how you write web apps these days. If you're doing a simple-as-tea CRUD app, then sure, whatever, but you could also just publish your FileMaker or Access database to the web and be done with it in that case. And for everything else, WebObjects, unlike even ASP.NET WebForms, makes it virtually impossible to have clean, trivially usable REST endpoints, which means you can kick your responsive client-heavy web app ideas to the curb. Yes, you can work around it, and ProjectWonder provides some tolerable solutions, but you're really fighting the framework the whole way. Why bother?

I'm also highly dubious that having Objective-C on the server is really a good thing. All those pointer errors you make in your iOS app that generally just result in a crash suddenly result in your server being rooted. Memory fragmentation becomes an insanely huge deal, since Objective-C's GC is primitive, and so on and so forth.

EOF was great, and would probably still be great. WebObjects was a great idea at the time, but that time has gone.

[protomyth]

> You don't actually want that. You just think you do.

No, I pretty sure I want an updated version of it. We don't have any clue where it would have evolved, but I wouldn't be surprised if Apple would have kept at it, there would have been a "Final Cut Pro X" moment.

> All those pointer errors you make in your iOS app that generally just result in a crash suddenly result in your server being rooted.

I really don't seem to run into those as much as others, maybe I'm lucky. Between Ruby or Objective-C, I'll take my chances with Objective-C.

[badman_ting]

I guess Jobs's ghost fired Forestall, then.