4 ms·

This seems to be a big leap from the current events. But, indulging the leap :), why would you want it to be a new language? Phones are getting fast - why not

by chwahoo 14y ago

This seems to be a big leap from the current events. But, indulging the leap :), why would you want it to be a new language? Phones are getting fast - why not python or ruby? (Or Scala, Dart, ...) However, I don't think Java is a bad language for many programs--and doubt it's headed to a retirement home anytime soon. (I'm frankly thrilled with Java for moving some many developers to a "safe" language/environment rather than C/C++ and its buffer overflows :)

eitland 14y ago
Never tought I'd say this but since getting my new job and since Java is not any safer than .Net for the moment I have been toying with C# and it just frankly feels like a better language, esp the Linq part. (Now, before anyone starts a big project in C# remember you are going to get punished all the way from start to finish. License for OS, for dev environment, no choice of dev environment, when you have bought VS you'll have to add resharper. Then you hopefully come to deployment where once again you have no real choice, Azure or self-hosting on, guess what, MS servers which again has to be licensed. )
- inexplicable 14y ago
  Its not exactly as you state with the licenses. Most (perhaps _all_) organizations/corporates use Microsoft products and have existing licenses. Acquiring more would not be issue in these environemnts. If you are a start-up, the right way to do it would by joining the BizSpark [1] program. .Net does provide an excellent development and scaleable environment. This program grants you access to all of its products, including Office, SQL server, Visual Studio and a multitude of other applications/tools. There was a recent post on HN [2] that spoke more to this. [1] http://www.microsoft.com/BizSpark/ http://www.microsoft.com/BizSpark/ [2] http://news.ycombinator.com/item?id=3848512 http://news.ycombinator.com/item?id=3848512
deleted 14y ago
[deleted]
dizidoro 14y ago
phones are getting fast but not soooo fast like that for python and ruby. scala maybe...
Roboprog 14y ago
Sure, it's a HUGE leap, but I was day dreaming. Of course, Python can run on Parrot, right? (Parrot, as an example, would be an interesting VM to see pushed into commercial readiness)
xsmasher 14y ago
Sluggishness and battery life are big complaints about current-gen phones; going higher-level is probably not a good idea. I'm still not sure why Google went with Java over C++, other than thinking "phones are fast enough."
- rev_null 14y ago
  I think there are two reasons that they went with Java. One is the fact that they're not controlling the hardware for android. So it makes sense to use a bytecode compiled language to support different architectures. The other reason I think that Java makes sense is that it makes sandboxing much easier than native compiled code. One of the features of android is the ability to restrict what any program has access to.
- Drbble 14y ago
  Java isn't so much slower than objective-C if at all, and Android has a native API for low level programming.
  - xsmasher 14y ago
    JIT compilation is swell, if you don't count time time it takes to kick in. And you're still at the mercy of the garbage collector. If it doesn't matter because you can use C or C++ for critical parts... well you can do that from Objective-C too, and it's trivial. It's far simpler than working through a JNI bridge. I'm still puzzled by the decision, given the horror of J2ME and the failure of Java on the desktop. Why not C++?
    - Roboprog 14y ago
      Pointers and arrays. It's too much work to develop most things in C and its direct descendants. It's of course a shame that Pascal got pushed aside: most of the speed of C, but with array bounds checking and MUCH less need for pointers due to reference parameters and function return space allocated by the calling routine. And perhaps Pascal is even too much work, since we still have to manually deallocate many types of data, since it lacks even reference counting. I agree with you on the garbage collector, though. It really slows down things by thrashing on multilevel caches, despite generational GC. I would really like to perhaps see something that gave you a choice of either reference counting + destructors, or, garbage collection. I can't see how you could make mixing libraries written for one or the other style work with an arbitrary ref-cnt / GC selection, though. I'd probably miss exception handling in any event, as well. Damn trade offs. I want it all, and I don't want to pay for it!

by chwahoo 14y ago

eitland 14y ago

Never tought I'd say this but since getting my new job and since Java is not any safer than .Net for the moment I have been toying with C# and it just frankly feels like a better language, esp the Linq part. (Now, before anyone starts a big project in C# remember you are going to get punished all the way from start to finish. License for OS, for dev environment, no choice of dev environment, when you have bought VS you'll have to add resharper. Then you hopefully come to deployment where once again you have no real choice, Azure or self-hosting on, guess what, MS servers which again has to be licensed. )

inexplicable 14y ago
Its not exactly as you state with the licenses. Most (perhaps _all_) organizations/corporates use Microsoft products and have existing licenses. Acquiring more would not be issue in these environemnts. If you are a start-up, the right way to do it would by joining the BizSpark [1] program. .Net does provide an excellent development and scaleable environment. This program grants you access to all of its products, including Office, SQL server, Visual Studio and a multitude of other applications/tools. There was a recent post on HN [2] that spoke more to this. [1] http://www.microsoft.com/BizSpark/ http://www.microsoft.com/BizSpark/ [2] http://news.ycombinator.com/item?id=3848512 http://news.ycombinator.com/item?id=3848512

deleted 14y ago

[deleted]

dizidoro 14y ago

phones are getting fast but not soooo fast like that for python and ruby. scala maybe...

Roboprog 14y ago

Sure, it's a HUGE leap, but I was day dreaming. Of course, Python can run on Parrot, right? (Parrot, as an example, would be an interesting VM to see pushed into commercial readiness)

xsmasher 14y ago

Sluggishness and battery life are big complaints about current-gen phones; going higher-level is probably not a good idea. I'm still not sure why Google went with Java over C++, other than thinking "phones are fast enough."

rev_null 14y ago
I think there are two reasons that they went with Java. One is the fact that they're not controlling the hardware for android. So it makes sense to use a bytecode compiled language to support different architectures. The other reason I think that Java makes sense is that it makes sandboxing much easier than native compiled code. One of the features of android is the ability to restrict what any program has access to.
Drbble 14y ago
Java isn't so much slower than objective-C if at all, and Android has a native API for low level programming.
- xsmasher 14y ago
  JIT compilation is swell, if you don't count time time it takes to kick in. And you're still at the mercy of the garbage collector. If it doesn't matter because you can use C or C++ for critical parts... well you can do that from Objective-C too, and it's trivial. It's far simpler than working through a JNI bridge. I'm still puzzled by the decision, given the horror of J2ME and the failure of Java on the desktop. Why not C++?
  - Roboprog 14y ago
    Pointers and arrays. It's too much work to develop most things in C and its direct descendants. It's of course a shame that Pascal got pushed aside: most of the speed of C, but with array bounds checking and MUCH less need for pointers due to reference parameters and function return space allocated by the calling routine. And perhaps Pascal is even too much work, since we still have to manually deallocate many types of data, since it lacks even reference counting. I agree with you on the garbage collector, though. It really slows down things by thrashing on multilevel caches, despite generational GC. I would really like to perhaps see something that gave you a choice of either reference counting + destructors, or, garbage collection. I can't see how you could make mixing libraries written for one or the other style work with an arbitrary ref-cnt / GC selection, though. I'd probably miss exception handling in any event, as well. Damn trade offs. I want it all, and I don't want to pay for it!