And, if Apple were to switch, why would they pick a language as shitty as Javascript?
And, if Apple were to switch, why would they pick a language as shitty as Javascript?
I still haven't found a language that implements events as elegantly as Javascript.
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.
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.
I don't recall seeing this mentioned anywhere. Perhaps the still-imperfect browser support puts people off.
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/)
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 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 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.
You won't be able to use undocumented APIs because you won't be able to get to them.