3 ms·

I'm confused by your statement about "the daunting prospect of dealing with Objective C, Java and C# simultaneously. This is a ludicrous prospect for a lone dev

I'm confused by your statement about "the daunting prospect of dealing with Objective C, Java and C# simultaneously. This is a ludicrous prospect for a lone developer." Perhaps that's true for a hobbyist. But any professional software developer should already be familiar with at least one (if not all) of those languages, and should be able to pick up the others with very little work. Once you know C#, for instance, you'll quickly see that Java is essentially a subset of it these days. Sure, there are differences, but they're quite minor. The same goes for Objective-C, to some extent. The syntax is a bit different, but most of the concepts are similar enough. Even the most commonly-used libraries for each don't actually differ that much in practice. In fact, many developers with experience in industry will have already had to use multiple languages at the same time throughout their careers. They'll already know how to work on several projects simultaneously, using several languages, and many more libraries. In fact, I'd suspect that most of these professionals would feel very handicapped if they were forced to use JavaScript for all development. JavaScript has proven time and time again to not be a good language for anything but short scripts. Languages like C++, Java, C#, and Objective-C have core features that make large-scale, distributed software development possible. JavaScript lacks these, and anyone working on a large JavaScript code base will know the pains that arise. It won't be good for Firefox OS if only the most inept developers are attracted to it. That's not the kind of ecosystem that produces useful applications.

robhawkes 14y ago
You'd be surprised at what JavaScript can do nowadays… https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread
- MatthewPhillips 14y ago
  Also HexGL: http://hexgl.bkcore.com/ http://hexgl.bkcore.com/
- pkolaczk 14y ago
  There is nothing surprising in it. 3D rendering is done mostly by hardware (OpenGL), not JS. But try to code something more sophisticated computationally for CPU, not a one function long microbenchmark where the JIT can guess all the types because code is simple. Something like simulating a complex mechanical or electrical system or some discrete optimisation stuff. Then it quickly turns out carefully hand crafted JS even on Chrome is more than order of magnitude slower than naive Java code.
  - bryanlarsen 14y ago
    The JIT should very easily be able to guess all the types in a complex mechanical or electrical system, or in discrete optimization. Matrices are fairly consistently typed. I don't think that JS would do much worse than "naive C" in such a situation. To do well on these sorts of problems, you need to pull in a library that properly uses the CPU's vector unit or the GPU, no matter whether you're using C or JS.
    - pkolaczk 14y ago
      If it did whole-program optimization, it theoretically could. But it is probably too costly. You don't have that much time and resources to optimize JIT, as you have doing static compilation. That's why, contrary to common beliefs on static vs dynamic compilation, still static compilers win in most cases, compared to even very mature things like JVM or .NET CLR, even though they have much easier task than JS.
  - unhammer 14y ago
    I haven't counted how many times I've read "magnitude" in this discussion … Does anyone actually have some numbers to back up the claims?
pfisch 14y ago
Everything this person said is the truth.
bejar37 14y ago
I mostly agree with your points, although I personally think that the JavaScript ecosystem is maturing quite rapidly through node and amd.
jmmcd 14y ago
The point is not that the these three languages are hard or obscure or that using all three is hard. The point is that maintaining the same code in parallel in three languages is a Wrong thing to do. DRY. Big companies can get away with it because they can throw manpower but it's still wrong.
- markmm 14y ago
  It depends, if your app is just a dumb UI that calls out to services then all the logic etc should be in the server, the UI code should just be displaying and a bit of caching. Once you have built it in one framework it will be much faster porting it to the others. I know it requires 3 updates when you add a new feature but it's not a major pain and you get native apps running very fast.
  - drbawb 14y ago
    I'd also add that I don't think it necessarily violates "DRY". I think "doing it wrong" would be _porting_ the same code to 3 platforms. A blind port to three different mobile platforms is going to look out of place on at least 2/3 of them. Unless you're talking game development (where you pretty much invent the UI and UX from scratch), each OS has very well established human interface guidelines. I largely agree with you, but I think GP is incorrect in assuming it's 3 parallel branches of the same code. The three ports should all be different, in some cases _drastically_ different, or they're bad ports. The business logic may be the same, but the presentation should not. Also you point out a very good way to separate the business logic without rewriting it three times. Though I wonder if you could write the business logic in C as well? I know it could be used as a lowest common denominator between iOS and Android. Android does provide the NDK and JNI so you could bind to C libraries, and Objective-C (IIRC) would allow you to link C libraries as well. Not sure what the Windows Phone toolkit looks like these days, though, so I can't comment on that.
SoftwareMaven 14y ago
It's not a function of knowledge. It's a function of time.
- brendanobrien 14y ago
  Couldn't Agree more. A professional dev should know one of these languages well. They should be judicious enough with their time to know that it doesn't make sense to "just pick up" a language for job-related work.
harshaw 14y ago
"JavaScript has proven time and time again to not be a good language for anything but short scripts." Perhaps this is just troll bait... define short. Yeah, maybe javascript isn't good when building a large app with > 100K LOC that uses a bunch of existing code built in C. However, you sure as shit can built a very sophisticated product with javascript. Learn how to use prototypes and you have OO (or avoid that if you don't like it). Use modules (many ways to do this). geez. Maybe this just struck a cord with me because I am in the middle of a huge project that uses a metric shit-ton of configure scripts that seem screwed up six ways to sunday. I feel handicaped by all the BS that you have to do to get stuff working C++/java that is so trivial elsewhere.
bthomas 14y ago
Could they have used Firefox OS as an opportunity to bring another language to the browser, rather than javascript to native? ie. if you could write [Objective C/Java/C#/etc] libraries for Firefox OS and they could be compiled and served to a browser client.
- robhawkes 14y ago
  Perhaps not entirely what you're after, but Mozilla's Emscripten project will allow that: https://github.com/kripken/emscripten https://github.com/kripken/emscripten
bmuon 14y ago
It's not about languages. With a certain level of experience languages can be learned to a useful point in a weekend. The problem is the knowledge of the platform, the APIs, the problems each platform has, which parts you should use, which parts you should avoid, what performs better, what hangs your app, what renders things poorly. All those things require a lot more time to learn.
kibwen 14y ago
You're right, the difficulty isn't the language in use. Languages are easy. But learning each of the platform-specific APIs is a much more daunting task. Learning web-based APIs are no less daunting, but given that a huge proportion of new developers are starting out with web dev, being able to leverage their existing knowledge is a powerful advantage.

robhawkes 14y ago

You'd be surprised at what JavaScript can do nowadays… https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread

MatthewPhillips 14y ago
Also HexGL: http://hexgl.bkcore.com/ http://hexgl.bkcore.com/
pkolaczk 14y ago
There is nothing surprising in it. 3D rendering is done mostly by hardware (OpenGL), not JS. But try to code something more sophisticated computationally for CPU, not a one function long microbenchmark where the JIT can guess all the types because code is simple. Something like simulating a complex mechanical or electrical system or some discrete optimisation stuff. Then it quickly turns out carefully hand crafted JS even on Chrome is more than order of magnitude slower than naive Java code.
- bryanlarsen 14y ago
  The JIT should very easily be able to guess all the types in a complex mechanical or electrical system, or in discrete optimization. Matrices are fairly consistently typed. I don't think that JS would do much worse than "naive C" in such a situation. To do well on these sorts of problems, you need to pull in a library that properly uses the CPU's vector unit or the GPU, no matter whether you're using C or JS.
  - pkolaczk 14y ago
    If it did whole-program optimization, it theoretically could. But it is probably too costly. You don't have that much time and resources to optimize JIT, as you have doing static compilation. That's why, contrary to common beliefs on static vs dynamic compilation, still static compilers win in most cases, compared to even very mature things like JVM or .NET CLR, even though they have much easier task than JS.
- unhammer 14y ago
  I haven't counted how many times I've read "magnitude" in this discussion … Does anyone actually have some numbers to back up the claims?

pfisch 14y ago

Everything this person said is the truth.

bejar37 14y ago

I mostly agree with your points, although I personally think that the JavaScript ecosystem is maturing quite rapidly through node and amd.

jmmcd 14y ago

The point is not that the these three languages are hard or obscure or that using all three is hard. The point is that maintaining the same code in parallel in three languages is a Wrong thing to do. DRY. Big companies can get away with it because they can throw manpower but it's still wrong.

markmm 14y ago
It depends, if your app is just a dumb UI that calls out to services then all the logic etc should be in the server, the UI code should just be displaying and a bit of caching. Once you have built it in one framework it will be much faster porting it to the others. I know it requires 3 updates when you add a new feature but it's not a major pain and you get native apps running very fast.
- drbawb 14y ago
  I'd also add that I don't think it necessarily violates "DRY". I think "doing it wrong" would be _porting_ the same code to 3 platforms. A blind port to three different mobile platforms is going to look out of place on at least 2/3 of them. Unless you're talking game development (where you pretty much invent the UI and UX from scratch), each OS has very well established human interface guidelines. I largely agree with you, but I think GP is incorrect in assuming it's 3 parallel branches of the same code. The three ports should all be different, in some cases _drastically_ different, or they're bad ports. The business logic may be the same, but the presentation should not. Also you point out a very good way to separate the business logic without rewriting it three times. Though I wonder if you could write the business logic in C as well? I know it could be used as a lowest common denominator between iOS and Android. Android does provide the NDK and JNI so you could bind to C libraries, and Objective-C (IIRC) would allow you to link C libraries as well. Not sure what the Windows Phone toolkit looks like these days, though, so I can't comment on that.

SoftwareMaven 14y ago

It's not a function of knowledge. It's a function of time.

brendanobrien 14y ago
Couldn't Agree more. A professional dev should know one of these languages well. They should be judicious enough with their time to know that it doesn't make sense to "just pick up" a language for job-related work.

harshaw 14y ago

"JavaScript has proven time and time again to not be a good language for anything but short scripts." Perhaps this is just troll bait... define short. Yeah, maybe javascript isn't good when building a large app with > 100K LOC that uses a bunch of existing code built in C. However, you sure as shit can built a very sophisticated product with javascript. Learn how to use prototypes and you have OO (or avoid that if you don't like it). Use modules (many ways to do this). geez. Maybe this just struck a cord with me because I am in the middle of a huge project that uses a metric shit-ton of configure scripts that seem screwed up six ways to sunday. I feel handicaped by all the BS that you have to do to get stuff working C++/java that is so trivial elsewhere.

bthomas 14y ago

Could they have used Firefox OS as an opportunity to bring another language to the browser, rather than javascript to native? ie. if you could write [Objective C/Java/C#/etc] libraries for Firefox OS and they could be compiled and served to a browser client.

robhawkes 14y ago
Perhaps not entirely what you're after, but Mozilla's Emscripten project will allow that: https://github.com/kripken/emscripten https://github.com/kripken/emscripten

bmuon 14y ago

It's not about languages. With a certain level of experience languages can be learned to a useful point in a weekend. The problem is the knowledge of the platform, the APIs, the problems each platform has, which parts you should use, which parts you should avoid, what performs better, what hangs your app, what renders things poorly. All those things require a lot more time to learn.

kibwen 14y ago

You're right, the difficulty isn't the language in use. Languages are easy. But learning each of the platform-specific APIs is a much more daunting task. Learning web-based APIs are no less daunting, but given that a huge proportion of new developers are starting out with web dev, being able to leverage their existing knowledge is a powerful advantage.