> The most interesting possiblility would be that this is the start of Apple’s evolution away from Objective-C into promoting a higher-level language for their platform
The thing is: Why would they want to transform away? As it is now Obj-C is pretty sane. The memory management is now a non-brainer so that even people who come from managed languages can grasp it. GCD is great for concurrency. And using C and C++ based 3rd party libraries is trivial.
The existing developer base is fine with Obj-C.
So maybe Apple wants to attract new developers? But why now? If they really wanted to attract new developers to their platform they would have chosen a different language for the iPhone SDK back when they released it first. But nowadays Apple's platforms have more than enough developers.
Also: Why JavaScript? JS itself is a terrible language with many inconsistencies and is unfit for larger projects - which most native applications are. There are far better and saner languages to base a new SDK upon.
Maybe I've just swallowed the Kool-Aid, but I don't see the putative benefits of Apple's switching platforms. I'm also not clear on how many people there are who a) can write non-trivial software and b) can't learn a C derivative language who c) would actually write software for Apple's platforms. It just seems like a pretty small set.
And, if Apple were to switch, why would they pick a language as shitty as Javascript?
The referred sentence is a matter of opinion, so it's a bit far-fetched to say it's a bit far-fetched, IMO. From what I know of Lua, it's fairly tiny, and it has ready access to its own meta-level -- to the point where there can be a blurring of programming and meta-programming. Instead of everything "being an Object," everything is in a table. Just rename "table" to "object" and call it a prototypical day.
No it's not, jokes aside, implicitly comparing Javascript to Lisp from the point of view of elegance is simply incorrect, for many definitions of "elegance".
If Javascript had a saner type system, better scoping, and a decent module system, it would easily be the best language out there. Right now, it is a diamond covered in loads of poop.
I still haven't found a language that implements events as elegantly as Javascript.
> a) can write non-trivial software and b) can't learn a C derivative language who c) would actually write software for Apple's platforms. It just seems like a pretty small set.
Funny. I've sometimes similarly speculated in the past that the set of developers who (a) struggle with JavaScript as a tool for in-browser apps and (b) would actually be genuinely productive with some other dynamic scripting language (Ruby, Python, CoffeeScript) in the same context is pretty small too.
But the truth is probably that whether or not someone can develop non-trivial software with any roughly equivalent language is mostly a function of available time to ramp up vs spend on other things. So, sure, Obj C and JS are close enough that anybody who can develop non-trivial software in one can probably do it in the other... but it's still going to be a time investment while you learn how things are done in the language and various associated APIs.
I don't know if Apple particularly cares if they're pulling in more developers. If they do, though, adding another language that many developers already know makes sense. It reduces the friction involved.
> And, if Apple were to switch, why would they pick a language as shitty as Javascript?
On top of the widespread at-least-shallow familiarity, not everyone shares this opinion.
Also, this is unlikely to be a "switch." It's more likely to be a gateway.
C? Buffer overflows, manual memory management, header files, severely lacking standard libraries, crap support for most modern idioms, etc etc.
C++? Tons of edge cases, template madness, unbelievable large language spec, etc etc.
Python? Python 2 - 3 dichotomy, crappy concurrency / parallelism support, , strict on whitespace, standard libs in various stages of cruft and abandonment, no proper closures, CPU bound for lots of interesting problems necessitating bilingual development with C extensions or the use of hacks such as Cython etc.
You can find a similar list for everything, from Lisp to Haskell.
Javascript "insanities" are no big deal. People have been creating large apps (including porting stuff like THE WHOLE BLOODY QT TOOLKIT to it) in it with no problems. Once you know them, you can work around them.
A huge install base, huge number of programmers, easy syntax, powering the internet, lispy-flexibility, and the fastest interpreters this side of the JVM are enough benefits to counter some crappy coercion rules and FP only math bizarreness.
Only a subset of Javascript is useful, just like how only a subset of C++ is useful, just like how only a subset of Objective-C is useful, just like how only a subset of Haskell is useful, ...
I think this comment would have been better if you had listed some insanities that make Javascript unusable. It doesn't seem objective at the moment. I, for one, honestly cannot think of what you might be referring to, but I only have a passing knowledge of Javascript so I cannot really decide if you are the GP have made the better point.
And the global object nonsense alone is enough to make it suck. Throw in the lack of an integer type, the curious `for each' statement, and the oddities surrounding `this', and it really starts to feel like this is the sort of language that over time is going to cause you a lot of heartache. It makes me sad - seriously, do people not expect better from their tools?
The maddening thing is that Javascript could so easily be vastly better, and it wouldn't take all that much. Remove any kind of implicit binding (and this could easily be optional, like Visual BASIC's option strict, or the similar thing in perl) and you'd be about 75% of the way there, in my view.
It would take a bit more to convince me that this kind of language is suitable for larger-scale projects - this based on my experience with pretty much any language that isn't statically typed - but this would at least remove one obvious type of error without impinging too much on what people appear to see as their freedoms.
ObjC has closures (blocks) and ObjC runtime (but not the syntax!) supports prototypical inheritance.
Actually the ObjC runtime is amazingly powerful and dynamic, as if it was made for a better language (e.g. can handle dynamism of Ruby http://macruby.org/)
>And, if Apple were to switch, why would they pick a language as shitty as Javascript?
That seems to be a fairly popular dismissal for a language designed in 10 days, and perhaps rightly so. JavaScript probably classifies as mediocre language compared to the wealth of sanely designed choices we have available today.
That said, have you taken a recent look at the next generation of JavaScript aka ES6/Harmony?[1]
- Modules? Yup
- Maps and Sets? You bet.
- Tail call optimizations? Sure
- Classes? Finally!
etc
That's not to suggest that a single iteration will magically fix all of its quirks and shortcomings. However, one possibility could be that Apple picked JS, not on it's checkered history, or the fact that it is popular amongst web developers today, but where it is headed tomorrow and how it could be adopted and adapted.
I grew up as a programmer through C++ and Java, and the first time I ever worked on a JavaScript project, I hated it, and I said the same thing about JavaScript as you did. That's because I was thinking like a Java programmer, and not just a programmer. As I worked more and more with JavaScript, I've grown to love. It has it's pitfalls, sure, but there's just so much flexibility in JavaScript than languages like Java or C++. Nowadays, I prefer it to Java or C++. Even for server-side programming. I get the feeling that you don't really know enough to know what you're missing.
It is advisable to taboo your practice of taking any thing X that differs from your viewpoint as a "no".
It is also advisable to taboo projecting your own experience/thoughts onto another, as if that is his/her experience/thoughts, as well.
That you love JavaScript, even for server-side programming, has absolutely zero significance in evaluating whether jfb (or anyone else, for that matter) knows enough to know what s/he is missing.
> It is advisable to taboo your practice of taking any thing X that differs from your viewpoint as a "no".
> It is also advisable to taboo projecting your own experience/thoughts onto another, as if that is his/her experience/thoughts, as well.
I disagree with that take. Personal experiences can lend themselves to evaluating context. Humans do it all the time.
If one is going to make an argument that something is "silly", and provides barley more than nil context to that argument ("enough to know"), then a context vacuum exists. If the OP isn't going to provide it, then someone else will.
last time I check a) javascript is a c derivative language and b) it is used for "non-trivial software" c) there will be developers believe it or not that would be able to create maintainable apps that maybe won't be good enough to your standards but I have a small feeling the average consumer will not care, my advice: http://alwaysbetonjs.com/ Apple's on board
I agree, there is something very special about OBJ-C these days. With subscripts, literals and even in the past with Protocols doing service objects were a breeze.
GCD is amazing and I use it more than NSOperation for easy quick off stuff.
That being said, I can see how this would be useful for gamedevelopers who wanna keep their scripts in JS/CoffeeScript instead of LUA :-)
Rather than this being the start of an evolution away from Objective C (which to me seems both unlikely and terrible), I wonder if it could be the start of an evolution away from AppleScript towards a user-scripting language that is easier to sandbox, more portable, and is familiar to a lot more script writers?
Because websites (and thus JavaScript, in some form) are the future of programming at this point in time. JavaScript just happens to be the primary programming language for interacting with HTML5 and a lot of people happen to know it pretty well.
Plus, JavaScript is not a terrible language but it does take a lot of knowledge to work with it cross-browser and use browser APIs (these browser APIs tend to suck).
I don't know why I bother to post on HN... I said websites are the future of programming. So yes, JavaScript is the client-side portion of that in which I was referring to in my previous post that you had to retort in some manner. Of course, you can use JavaScript, Ruby, Python, PHP for the server-side, but regardless that is a moot point when the article is about client-side programming on OS X.
Personally, I'm developing a fairly advanced web app. Since I'm the only developer, I can't afford to split my time between web, iOS and android development. If a JavaScript bridge allows me to reuse all the logic from my web app, but replace the UI with a snappier native one, that would save me a buttload of time.
Maybe Apple out of the goodness in their heart decided to make this easier, but I'm skeptical.
The main (very welcome) advancement seems to be that they've pushed this capability down from WebKit into JSCore. Today you can basically already do everything that's being shown in OP I think, you just were required to create an invisible WebView to host your JavaScript environment. You can easily expose classes to WebKit/JSCore (using KVC), and interact with JS objects from ObjC, and arrays, strings, etc. are auto-converted. The WebKit requirement is pretty annoying though, and as V8 has shown us, having a drop dead simple way of throwing JS into an app has some huge benefits.
Good catch, I hadn't seen that before. It definitely looks like WebScript and the new JavaScriptCore API are strongly related. It's interesting how hard the WebScript stuff is to find without knowing the name, it didn't turn up in any of my Googling when researching the post.
The fact that it's a refactoring (even a very nice one, as it seems to be) rather than a brand new API does make it less likely that Apple has any particular future plans for the API, which in turn make much of the speculation in the post even more speculative. I'm going to make an update to the post with a link to WebScript as well as a bit of additional commentary.
Totally agree it's more like an evolution, and I doubt it will be exposed on iOS at all, which means the same developer rules will apply and downloaded JS will have to be running inside a UIWebView.
The fact is that after thinking about the iOS developer rules and what is currently available in iOS, it's totally doable to write a true Javascript bridge that respect all the requirement from the iOS rules and still let your JS code access all the ObjC runtime, in a totally transparent way aka I am able to write the following:
var userName = userNameTextfield.getText();
var helloMsg = "Hello " + userName;
messageLabel.setText(helloMsg);
The first line will directly get the text value of a UITextField (no callback used here), and it will end up calling directly the 'text' property on the UITextField. So the JS bridge works transparently where JS code call native ObjC code directly (without using callback) and obviously ObjC can directly access the JS side... there are a few gotcha but the full system works beautifully and surprising enough performance are quite good. It took me a few years to come up with the cleanest solution and implementation.
I am currently working on integrating such piece of code into some of my apps and have them released on the AppStore. In fact if anyone good in JS is interested I would really appreciate some help to get that bridge off the ground since I truly believe there is a lot of great opportunities with a JS bridge to ObjC that respect all iOS rules.
My contact info are my HN profile.
My guess is that this would be fast enough to build almost any Mac app and many iOS apps. The bigger question for me is, how gross would it be to deal with the "Objective-C-ness" of the Cocoa APIs through JavaScript?
Functionally, this appears to be identical to JavaScriptCore's longstanding C bridge [1]. If Objective-C isn't your preference, there's nothing stopping you from calling into the C bridge from C++ or just plain C.
On iOS, developers have had to compile their own version of JavaScriptCore to use this API. That's the basis for HTML5 game engines like Impact [2], and some HTML5-to-Objective-C middleware platforms.
Unfortunately, until Apple says otherwise, this version of JSC is still subject to Apple's App Store review guidelines [3]. Thanks to guideline 2.8, you can't have your app, running JSC, execute any JavaScript that doesn't ship within the bundle of your app.
I'd like to see that rule change, someday. Exposing this Objective-C API in a future iOS release isn't going to change the status quo.
All good points. The big difference with the bridge going to Objective-C, though, is that I believe it is now possible to build a native UI by calling right from JavaScript to Objective-C. Impact is interesting for games and canvas-like rendering, but what I'd love is to be able to build the models and controllers of a highly performant, native-UI iOS app using JavaScript and UIKit. Sort of like Appcelerator with a layer removed.
That's fair. This does save one ugly, extra step that I didn't mention, which would be to call into the Objective-C runtime's C API [1] to dispatch messages and introspect Objective-C classes.
Should make it easier for developers to build their own middleware platform without getting too deep into reams of C boilerplate.
You should be able to to run code downloaded as part of IAP also. But this is one of the major things I wish they would change, and also one of the major reasons I'll be switching to Android.
Which is what I meant by "within the bundle of your app." That may have been a bit too iOS developer-centric, I apologize.
In Foundation, [NSBundle mainBundle] returns a reference to an object representing your application's root directory, and the code and resources found within. Roughly the same bits that you'd find within an unpacked IAP file.
That depends on the state of the bridge. Previous language bridges by Apple have generally bridged the gaps pretty well, with the main "Objective-C" relic being really, really long method names.
That said, all of the bridges I've seen were to classical-OO languages. It is possible that Cocoa won't translate as well to prototypal-OO languages like JavaScript. It will be interesting to see how Apple navigates that paradigm shift.
> all of the bridges I've seen were to classical-OO languages. It is possible that Cocoa won't translate as well to prototypal-OO languages like JavaScript.
This has already been done with Mozilla's Rhino (JavaScript or Java) and it turns out the be pretty easy to work with Java classes in that context.
On iOS it won't be that quick: you don't get anything more than the JS interpreter, as you cannot allocate any executable memory on iOS, so any JITing compiler is out of the question.
No, it applies per process: whether or not it came from a dynamically linked library distributed as part of the system is irrelevant. This is why UIWebView is slower outside of Safari.
It's important to remember that Apple shipped both the Ruby and Python Objective-C bridges in ~10.5 era OS X. You can (and I have) written OS X native software in Python; it wasn't super pretty, but the concepts mapped across reasonably well.
So I wouldn't take this as necessarily the sign of a shift in anything.
Also, people at Apple like Objective-C and its Smalltalk influences. For those of us who've been in the NeXT/Apple ecosystem a long time, it's clear that employees at Apple see Ruby as more interesting than say Javascript because of the Smalltalk influences. If any shift were to occur, money is on Ruby. But Apple likes Objective-C and no shift seems likely and we also saw what happened with MacRuby and the author leaving to do RubyMotion.
And they've invested a lot in the tooling and environment. It's not like they're just running a stock gcc toolchain; they've put a lot of very smart people on very hard problems in the language space.
Agreed. And another problem is that all these interpreted languages are terrible at exploiting parallelism which is a problem as we get more processor cores.
They were able to solve this in C by inventing Blocks and GCD.
Completely off-topic, but those (who like me, liked Hypercritical very much, but aren't active on Twitter to learn these things there), Siracusa has a new show here: http://atp.fm
It's not as good as Hypercritical, but is better than nothing!
> The most interesting possiblility would be that this is the start of Apple’s evolution away from Objective-C into promoting a higher-level language for their platform
I never had a big problem with Obj-C. It felt like any other language other than having to manually manage memory. The problem I struggled with was Cocoa as a whole. It may no longer be the case but not too long ago, there was a lack of consistency between the different APIs / SDKs. Most would written and accessed with Obj-C. A few would still be in Ansi-C. For someone who isn't a C expert, this just killed me.
This will probably be Mac-only. It will not appear on iOS unless Apple also ships BridgeSupport on iOS. BridgeSupport is needed for binding all the Obj-C parts that don't have introspection capabilities (like the C parts).
This is how most of the other full feature bridges work, PyObjC, RubyCocoa/MacRuby, LuaCocoa. Otherwise you are hamstrung anytime you need to deal with something like a C struct (e.g. NSPoint).
As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself.
You don't necessarily need BridgeSupport to call out to Objective-C.
Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge after Laurent Sansonetti left Apple. A shame.
BridgeSupport also supplies .dylibs containing inline functions/macros that don't have symbols/linkage in the main framework.
While it is possible to workaround the lack of BridgeSupport, if Apple doesn't supply it, most developers are not going to go through the effort of using it. And if Apple doesn't supply it on iOS, they aren't going to make life nice for developers doing this (continue bans on dynamic libraries for loading the .dylib containing missing symbols, on mprotect which is horribly useful for things like subclassing and block generation and JIT).
I don't know where the source went. I'm sad to hear that. If you find a copy, let me know.
Cue the typical and tiresome language-wars snark. (And time to burn some karma.) This kind of behavior is often just a shallow and distinctly anti-intellectual "irrational jingoism." If you read between the lines, so much of it just comes down to "I don't like X. I don't understand X. Doing X in the programming I do wouldn't work. It just must be bad."
That's so often just about outward signs. Programming is complicated, and the fields of programming and Computer Science are vast. If you're not aware of how miniscule a sliver of the whole thing you command, odds are you're just another unwitting Dunning Krueger victim.
Don't judge a language by what you find strange. Don't judge a language just because it wouldn't suit what you do. Figure out what makes it powerful and why it works. Until you do that, please just shut up and don't add to the noise.
I don't understand the recurring drive people have for trying to write native applications without Objective-C. The various bridges and other glue projects never feel complete or as well-integrated with the system frameworks.
The future is arriving- slowly. Hopefully soon we will be able to make the core of our apps cross-platform by leveraging languages like Javascript, and only resorting to platform-specific code for UI layers.
Are the interpreted code download app store rules still in place? ie can an app download additional JS at runtime or does everything still have to bundled?
"Javascript is so shitty though!"
"I agree!"
"Javascript isn't so shitty once you get used to it"
"It's like lisp!"
"No it isn't. Javascript is terrible and everyone who likes it is a moron"
"No they aren't!"
"YES THEY ARE"
I don't know, should we expect more from the discourse here than just rehashing the same argument over and over again?
The thing is: Why would they want to transform away? As it is now Obj-C is pretty sane. The memory management is now a non-brainer so that even people who come from managed languages can grasp it. GCD is great for concurrency. And using C and C++ based 3rd party libraries is trivial.
The existing developer base is fine with Obj-C.
So maybe Apple wants to attract new developers? But why now? If they really wanted to attract new developers to their platform they would have chosen a different language for the iPhone SDK back when they released it first. But nowadays Apple's platforms have more than enough developers.
Also: Why JavaScript? JS itself is a terrible language with many inconsistencies and is unfit for larger projects - which most native applications are. There are far better and saner languages to base a new SDK upon.