The language is portable to any platform, very powerful, and isn't at-risk of suffering the same fate as Java.
The criticisms of it are mostly fluff in my opinion...people trying to say that their personal stylistic perferences should be industry standards, or justifying their own lack of skill by saying C++ makes things harder than they should be, etc.
C++ is not an application-level programming, but a systems-level one. Java plays both roles. Furthermore, it is not the language that is of value, but the enormous (and standard) class library; a defined component model standard for distributed computing; a defined component model standard for thin-client development; a defined standard for persistence; a defined transactional model; etc, etc, etc.
Many of the things mentioned above (sans the hiccups and false starts) have been refined, tested and tried on the field for a decade now. That is what's lacking in C++ (a language that I like more than Java... and I work on Java for a living mind you.)
There are no comparison between the two languages because they are incomparable; defined and designed for two completely different niches and roles. It's not about replacing one language with another, but about replacing an entire ecosystem with another one.
Having worked on both, worked on Java for the last 12 years (on both application and system development) and about to work again in C++ and C (embedded stuff), I can tell you this:
C++ (or the lack of equivalent enterprise/distributed plumbing) makes it unsuitable for the roles fulfilled by Java (or.NET). And vice versa, Java (despite having a shitload of de-facto and de-jure standard plumbing) is unsuitable for the roles filled by C++.
When you work with both languages and when you work on both application and system development, you very quickly how different they are; how silly is to compare them; and how impractical (if not impossible) is to consider using one in place of the other.
Google tries to pull a Microsoft and splinter the Java platform in a very bad way. Embrace, extend, destroy.
Google hasn't created a java platform to compete with Oracle's. They created a virtual machine that reads in completely different byte code. It just happens that you write the source in Java.
Not source in Java, but source in a subset of Java. You can't legally provide a subset of Java, or a superset of it as per the Java license agreement. Google would have been better off implementing an entire different name space of libraries outside of the java, javax. and org. namespaces delineated in the standard JDKs.
I don't necessarily think that Google did something extremely evil or fragmentary, but they did something that was legally murky (as per the Java license agreement) banking on the defunct Sun being too weak/unable/stupid to go after them.
They should have started with a branch new name space of libraries or they should have bought Sun when they had the chance. </blooper>
Nope. Microsoft modified Java's platform and still called it Java. It wanted to add incompatible features and extend Java to its liking, ruining the write once run everywhere.
There was already a Sun/Oracle lead platform (and strategy) for Java on the phone, it was JavaMe and it wasn't good enough.
Google is thus taking the result of the compilation of a Java program and making it run on a phone in a different platform. It never clamed dalvik to be a Java VM, it just uses the Java language. That's very different from what Microsoft did.
Google has no interest in destroying the Java language and platform. It uses it in several places, including Google App Engine.
And herein lies the problem. A legal implementation of a Java run-time or compilation must ensure the java and javax namespaces are exactly as laid out in the Java license agreement. Not a superset (as MS tried to do with J++) nor a subset as in the case of the Android runtime.
You probably should have read the first few paragraphs:
"1.2 Your use of products, software, services and websites in connection with the Open Handset Alliance website (referred to collectively as the "Services" in this document) is subject to the terms of a legal agreement between you and Google. "Google" means Google Inc., a Delaware corporation with principal place of business at 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States. This document explains how the agreement is made up, and sets out some of the terms of that agreement. "
... and...
"2. Accepting the Terms
2.1 In order to use the Services, you must first agree to the Terms. You may not use the Services if you do not accept the Terms. "
The entire document relates to and describes terms of service for the website, not Android. If you want to know about the licensing terms for Android you need to look at the license(s) in the source.
Not just for the website, but for (and I quote the lines you just quoted, emphasis mine):
1.2 Your use of products, software, services and websites in connection with the Open Handset Alliance website
So, it is not just related to (and describing terms of) service for the website but:
products
software
services, and
websites
related to the OHA website. Somehow I think Android is a) a product and/or b) a software related to c) the OHA website (and/or the OHA itself which is also a Google trademarked name.)
...A lot of light emitting diode, especially white light emitting diode, uses phosphor powder to stimulate light of different wavelengths. However, phosphor powder is highly toxic and its price is expensive. As a result, Dr. Yen-Hsun Wu had the idea to discover a method that is less toxic to replace phosphor powder....
By implanting the gold nanoparticles into the leaves of the Bacopa caroliniana plants, the scientists were able to induce the chlorophyll in the leaves to produce a red emission. Under a high wavelength of ultraviolet light, the gold nanoparticles were able to produce a blue-violet fluorescence to trigger a red emission in the surrounding chlorophyll.
So it sounds like the trees need a "high wavelength of ultraviolet light" to get them to glow. Seems like they are just replacing the phosphor that makes a white LED glow with these gold implanted leaves. But you'd still need a UV light source (which could be an array of UV LED's?).
I'm not sure that this is really an environmental win -- replacing an array of white LED's that last 10 years with an array of UV LED's that point to trees that need their leaves to be impregnated with gold (and replaced annually?) doesn't sound all that environmentally friendly. How bad is the LED phosphor for the environment?
The point of this research is not say "aha! this is the solution". It is an exploration of a technique in its embryonic stage. Obviously, it is not about coating all trees down the boulevard with gold nano particles and having them bathe under directed UV lamps.
What if this can lead matter manufactured from trees and leafs (like paper) that glows under slight UV radiation, all of that packaged into a light source?
Or genetically modified (and necessarily sterile) trees and plants that can absorb natural UV from the sun and glow at night (Pandora here we come)?
Either one (and many other ideas) seem far-fetched, but so was the idea that everyone would have a computer the size of a cell phone with which to watch videos many decades ago.
Every single useful product we have today has its root on prototypes that were impractical (and perhaps even dangerous) for general use. And that's what TFA is showing, a prototype with the goal not necessarily to produce glowing, gold-coated Pandora-like trees, but searching for less toxic (and hopefully more affordable and eco-friendly) lightning technology.
For people who like to think of themselves as highly technical, many/.'ers seem to have zero understanding of what research is about.
OK, replying to myself because I obviously didn't have enough coffee yet:
They list as the benefits over Scala
- Extensible type system
- Easy transition from Java
- Reified Generics
From those 3 points, only the last one sounds useful...
You are kidding right? In reality-land, for better or worse, #2 is probably as important of all for a lot of Java shops as #3 if not more. Type erasure sucks balls, but we can get it to work (just as we were able to write good working code without generics.)
Adoption and ease of transition are things people tend to undervalue/underestimate. Being able to leverage a language with better qualities with as little code change as possible is certainly an enormous, practical incentive. For me, I would give an eye to work on something else (Scala, Ruby/Python on the VM or Clojure), but the reality on the ground is that something like Groovy (using the Groovy++ compiler, though) is the most likely candidate for adoption given its easier transition.
Gosu seems to embrace the good qualities of next gen JVM languages (and C#) without a substantial deviation to the syntax.
Necessary/. anti-fanboy disclaimer: Before the/. fanboy crowd displays their usual lack of reading comprehension, I'm not saying that Java syntax is superior or that the syntax sported by the other JVM languages is deficient or bizarre. I'm simply stating the fact that there is an associated, practical cost of transition (in terms of education, time of getting proficiency, possible introduction of coding errors, etc) that is proportional to the syntax differences that need to be overcome - this without considering the external pressures of writing software for solving problems in the right here and right now.
With infinite time and resources, and zero friction from requirement/requirement changes and organization dynamics, syntax differences would not matter. AFAIK, that is not the context in which programming shops operate.
. Another important addition is the use of delegates. Oh my, I can only think of the possibilities we currently can only do in Java with a lot of boilerplate.
Replacing Java with another JVM language doesn't help you one bit if you have a problem with relying on Oracle software
1. Most people don't have a problem relying on Oracle software (and by that I mean Oracle's commercial software and not the libs under the java/javax namespaces).
2. Your statement is pretty much non-sequitur. Seems more like a problem statement looking for a problem to reference to.
Re:"Alice" one of the best learning languages toda
on
Land of Lisp
·
· Score: 1
That's the most bonkers thing I've ever read.
Not really, it actually closely resembles practical things that need to be done in many large scale systems written in procedural languages. People have been doing a lot of (mostly) good things to implement re-use and modularity in procedural languages for a long time (just as there are plenty of strategic/tactical reasons to use a procedural programming language over an object oriented one.)
Furthermore, reading that gives the novice reader a glimpse at how things occur under the hood. At the end of the day, OO is syntactic sugar use for the sake of modularity and structural soundness. It eventually has to be implemented on a procedural manner (even if it is invisible to your eyes thanks to the compiler.)
I wouldn't recommend BASIC or LISP for someone wanting to learn modern object-oriented programming today. A lot of us started out with a structured languages like this, but you wouldn't want to start out that way if you were doing it for the first time now. My university uses Alice and it works pretty well. Alice teaches much more modern object-oriented principles that would be much more useful than BASIC or LISP to a modern programming student.
What a horrendous idea. If the whole goal is to learn more OO principles, that's a f* up goal by itself. Not everything is OO; reality is multi-paradigm; and beyond a certain granularity OO code is intrinsically tied to modular, structural and procedural principles. Barring the naturally gifted, people can't learn proper OO skills (much less general analysis and design skills) without knowing modular, procedural and structured programming.
One of the greatest failures of CS education has been the failure to teach that, the fallacy that you can simply use nothing but one or two OO languages and a 100% OO paradigm as a general plan for teaching programming. Testament of this is that, even after 3 decades, people still can't tell you precisely what a good OO system is like. One just have to look at the OO code base that is out there. Truly hideous and anything but OO.
A good chunk of people think they are doing OO when in reality they are using OO languages to implement poorly written procedural code (typically without any notion of structural soundness or modularity.)
In fact, a lot of what the world needs right now combines/requires procedural programming. RDBM access is strictly procedural/declarative - and don't bring the fallacy of ORMs. People can't effectively use ORMs without knowing the procedural/declarative interfaces that lie underneath it. Services are intrinsically procedural and so are the languages that interface/combine them (think BPEL.)
When people miss that and are confronted with the *real* multi-paradigm world, they either try to force a OO paradigm on the procedural interfaces/services, or the service-accessing code devolves into an in-cohesive, inflexible procedural lasagna.
I've been doing OO development for quite a while now, quite successfully if I may add, and I've worked in teams that have made the transition (quite successfully also) from procedural/modular to OO programming. From experience I can tell you most CS students cannot fully understand (or fail to understand) OO principles without understanding procedural, structural and modular principles (and spending a lot of credit hours in them.)
We need people that are exposed to the nitty gritty details of multi-paradigm realities of world problems, not pampered from the beginning with graphical systems intended to show... yay... more OO principles. You want to teach people more OO principles? Then lay a solid multi-paradigm foundation with plenty of credit hours in several programming languages, getting them to deal with issues of structure, modularity, procedures and the like.
Kids that get exposed to those will get much more mileage from OO education, and equally useful, that exposure will filter those who really can't cut it for CS because not everyone is cut for it (and this applies for any degree and people trying to get in them.)
Even if now it is with Unicode as opposed to some crazy keyboard combination using non-standard keyboards, this path will only lead us to APL all over again. No thank you.
This is more like a badly thought of solution looking for a problem no one practical wants to even touch with a 10-foot pole.
Not something as simple as writing ASCII by a long shot.
It isn't as complex or cumbersome as many of you think either. I know, I've seem them (Japanese) going at it. The challenges of Japanese writing are not unique to typing as they also apply to hand writing. There is really no option other than do what they do with their typing software. And it is very effective and not that cumbersome for someone that already knows Kanji, Katagana, Hiragana and Romanji (the usage of the Roman alphabet for Japanese words) - namely anyone literate in Japan.
Japanese is typed using a more-or-less standard QWERTY keyboard.
Tediously.
I've seen my wife going at it (and Japanese people in all types of computerized businesses on Japan). They certainly don't have much of a problem. Kanji writing is a unique and complex task not easily amenable for typing on a keyboard. Hiragana and katagana are much more amenable and most Japanese know to write with "Romanji". The software they use simply finds the appropriate Kanji, Hiragana and Katagana after they type the corresponding Romanji.
So in essence, they are typing just as we do using a Roman alphabet with the software doing the translation automatically just as modern word processors automatically correct misspells for you (and in both cases, the software gets it right most of the time.)
Oracle isn't going anywhere. This lawsuit isn't going to be anything at all like SCO/IBM or SCO/Novell because Oracle is many times larger than SCO is and is at least 2 orders of magnitude more relevant.
Java is everywhere. Schools teach it. Companies use it.
If Google really copied things from the Java source like actual source code or documentation, they might be screwed. It sounds like from the summary that the bulk of this 'copying' was the API, which I don't think is even eligible for copyright(not artistic).
The APIs are governed by a patent license that states how the APIs are to be presented. In fact it goes specifically to forbid presenting a subset or a superset of the APIs presented under the java.*, javax.* package/namespaces (and the org.* namespaces currently included into the J2SEE, J2ME and JEE profiles.)
Here is where Google is screwed since people that program for Dalvik are using a subset of the Java API (in addition to extensions.)
However...
The patent license was intended in this way to prevent someone from doing something that is a superset or subset of "official" Java, and call it Java.
Here, Google has never called what they do on Dalvik "Java". So on that technicality, they might (just might) have some legal room to maneuver.
However, Google has implicitly presented the Dalvik platform to Java developers (J2ME developers in particular) saying "you can using your Java skills to develop in Android. It's just like Java."
That kind of wording, however implicit as it might be, that can be justifiably open to litigation.
The jury is still out on how all of this is going to pan out, but it is important to understand (regardless of how you feel about it) the following:
Sun didn't go after Google because it couldn't. Oracle now can (there was legal ground precendence.)
Google did this banking on Sun's unwillingness/inability to go after them.
Google banked on legal ambiguities to develop and market a platform that caters to J2ME developers.
By doing so, and by not buying Sun when they had the chance, Google has put itself is a midly annoying position. It is not a precarious one as I'm sure Google has enough muscle to fight it off (or come to a settlement with Oracle.) But it is an annoying one for everybody else.
Its considered unethical by the majority of scientists to recycle papers unless there is a significant update from one to the next, i.e., methods changed, or additional steps are taken which improve the results. It is not considered unethical to have your paper resubmitted to a different conference or journal if it was rejected from another however.
I know, I was referring to the former. In fact, referring a paper to different conferences (say within the same year), that I would *not* consider it recycling.
> I once had an English teacher who said, "If you have more than five consecutive words matching a source, without a citation then it's plagiarism." Perhaps that's how freshman writing assignments are graded, but it's silly when applied to scientific papers.
No. Just... no. It is not "silly," it is insulting, in either freshman english lit or scientific papers. Any teacher who defines plagiarism that way has a lot more to learn than he has to teach.
Perhaps so, but I could see where such a rule could come from, and it could instill a discipline of making sure things are properly cited. Without any other context, obviously the rule is rubbish, but I could see it as an excellent rule to live by when taking freshman courses in writing/composition.
Even though recycling is not plagiarism, I would love to see this tool being used to create some sort of recycling ranking for individual academics and colleges. There is a not-so-fine line between exploring different aspects of a subject and simply recycling for the purpose of maximizing presence. The former is necessary for the pursuit of research. The later is just f* dishonesty (and a costly one for society since it is typically used for securing research moolah.)
I think you overestimate the number of J2ME devs compared to Symbian ones. There's a lot of those. And comparing anything to Apple is disingenuous as Apple wants the lock in of a little-used language, just like MS wants lock-in with.NET.
My comparison was never meant wrt to open vs locked-in. It is a given that any of the ones mentioned are meant as a way to lock in a given share of the consumer and development market.
Still, I would not have made the UI components java-based at all, as I think Java is a lock-in language all of its own.
It's always been a lock-in language. Where is the surprise in that?
(I shudder at all that "100% pure" Java marketing),
Why shudder at it? We have been developing from small to truly colossal systems in nothing but pure Java for the last 13 years. I don't quite follow the remark.
I think they should have made it more as open component, probably in C, with bindings for all languages the dev likes - so you can still code in Java if you liked, or C/C++, or python, all the time knowing you were getting a first-class support for interaction with the underlying system.
That could have been a possibility.
Is Java a better thing to code against? That depends on your skill set
This has nothing to do with skill sets. Really. For example, I can program in Java, C and C++ and have done programming at the application and system level, on both Unix and Windows (all the way down to the dinosaurs of Motif and raw Win32 API). But for application level programming, I'm sorry, productivity is up with a managed language (and the inverse is true for systems programming and a systems programming language.)
I can arm an application-level app (be it a UI or a back-end system) using a managed programming language a lot faster than with C or C++.) And there are things for which I'm much more productive using the later (say, having to implement a network protocol stack, flip bits or, I dunno, communicating through the serial port.)
Productivity is not simply about skills, but about using the appropriate tool for the appropriate task. There is no silver bullet nor golden universal hammer.
and before anyone says 'but we need to make it as easy as possible', if that was the case, the language used would have been Basic:)
Don't see what the problem with Basic is either. There is a lot of people that write crap code in Basic, but the same can be found with Java, Delphi or C/C++. It is an excellent tool when you need to write an application that shuttles data from one point (a db) to another (a screen) and where having to deal with the details under the hoods is not carrying a particular ROI for the given task.
I would have a problem seeing Basic being used when a lower-level language is more appropriate... and viceversa. There are no universal tools in programming.
Don't forget the VM is the OS as far as Java is concerned.
Exactly. That's the idea.
Google could easily have put that work into the Linux kernel (or the Android API layer) without needing to put a VM layer on top of it all.
And Ericson could have done the same with their telecommunications systems. Instead they implemented and deployed the Erlang VM with quite a lot of success. Having a VM opens a plethora of advantages. VMs have been explored for almost 3 decades now, with them being successful stories in the industry for last 18-15 years. Ruby, CPython, Erlang, Java,.NET CLR and so many flavors of systems written in Smalltalk, Lisp and Prolog, each a testament of how effective VMs can be.
There are times when you embed functionality at the kernel level. At others, you abstract it out to an operating environment running on top of it (in many cases in the
Dalvik on the other hand started (and has remained so) with support to a subset of Java. Why? Because it caters to the masses of J2ME developers already in existence; another strategic move, and a better response to iPhone's reliance on Objective-C.
This confuses me, see if they wanted a strategic language for Android that gained a absolute heap of developers, J2ME wasn't it.
Why not? The number of former J2ME developers is decent, and the transition to developing on a mobile platform is that much more cost-effective for the masses of J2SE/JEE developers out there. Google simply said "here, you know Java? Then you can use your skills almost without changes and be productive almost immediately".
It was C/C++ as used by Symbian.
Why would C/C++ be a better strategic language for Android? Do we have any ratio of C/C++ developers with Symbian experienced over the number of J2ME developers (and the potential J2SE/JEE developers that could be trigger happy and more than ready to do mobile stuff)?
Also, consider that it's not the quasi-Java language that Android programmers use that is the platform. It's the Dalvik VM. It is not beyond the realm of possibilities that the same VM will support subsets of Ruby and Python for mobile development, benefiting from a core of "blessed" libraries, sandboxed on a VM (which is more appropriate for application programming).
Add some symbian->Android conversion tools, libraries or frameworks and you'd have had a massive amount of development loveliness. To point this out, on many Android forums one cry I used to read a lot was "how can I port my existing C++ code to Android, why did they make it all Java".
One could also make the same argument with iPhone and Objective-C. There is a matter of application control that Google is pursuing here, and I have a suspicion that Google is not that kin of C and C++ given they are looking - for better or worse - for system programming language alternatives such as Go.
I think Google went Java because it was their 2nd (or is it 1st) choice language, and the guys doing the phone API happened to want to make it Java, probably no other reason than that.
That's all the reason they needed to be honest.
Now they should start improving the Qt abilities and getting a richer software ecosystem going instead of trying to lock it all down to Dalvik-code only. (ie make it easier and more supported, to write in C/C++ and maybe Python too)
I beg to differ. With a Dalvik VM, it might be a lot easier to create a Jython or JRuby subset to run on a common managed application core than to write it down on C/C++ and having a separate Python environment (the later with code managed independently of Dalvik and the former not being managed at all). With a VM, you can establish a lot of different application policies common to all run-times, enforced at run-time, with the OS unencumbered by them.
It is a model that has worked well on all flavors of Java, and on all things run by a VM (Erlang, Ruby, etc.) Google could have also gone the way you described, but I suspect they decided to go the way they did for the reasons mentioned above.
Obviously you would not get all the amenities you'll have on Python (.ie. ability to call C libraries.)
Why not, since Dalvik implements JNI?
Possibly because of the same restrictions placed already by Dalvik on the type of libraries one can execute under the java.* and javax.* namespaces.
I mean, this is all speculation from my part, but if Dalvik - by design - restricts on what is available under the java/javax namespaces (for a variety of reasons), it will also follow that it will put restrictions on executing arbitrary native code via JNI (as Google App Engine does now.)
Android is all cool and stuff, it's also FLOSS and great, and whatever.
However, it has its shortcomings which make it less than a desirable phone operating system for me. First of all, MeeGo, Maemo and their cousins allow me to run any vanilla GNU/Linux GUI applications. They are most often inconvenient to use on a phone, but they are sometimes better than what's available on the platform. On Android I'm limited to apps written for Android. Thanks but no thanks.
Also, programming for Android? You need Java or another language that compiles for JVM.
Just a small (but very important) correction It's not the JVM, but the Dalvik VM. Bytecode is different, architecture is different, and Dalvik by design will not run J2ME things that can run on a JVM.
Want to program in Python? Good luck. You can't, and you'll never can, because Jython isn't portable to Android.
Considering that Google App's engine primary language (for a while) was Python, I doubt that Python (or a subset of it) will never be supported on Android. To run Python on a VM, you. do. not. necessarily. need. Jython. You simply need (a yet to be developed) Jython-like equivalent for the Dalvik.
Obviously you would not get all the amenities you'll have on Python (.ie. ability to call C libraries.), but then again, you do not get all the Java amenities on Dalvik anyways. Now, the status quo is all the result of strategic considerations.
Google App engine supports Python and Ruby (and even Scala IIRC) because the web development bestiary is that much diverse. It caters to the widest possible set of development shops, a good strategic move.
Dalvik on the other hand started (and has remained so) with support to a subset of Java. Why? Because it caters to the masses of J2ME developers already in existence; another strategic move, and a better response to iPhone's reliance on Objective-C.
The Oracle-Google legal wrangling might actually give Google a reason to start supporting a different programming model should it comes to that. Given its historical support for Python, it could come to that as it is not infeasible (given Google's engineering resources), nor foreign (given its history with Python.)
There is nothing technical that prevents a subset of Python from ever running on Dalvik, ergo my objection to your position, which I quote - "You can't, and you'll never can, because Jython isn't portable to Android"
Want to program Ruby? Haha. With non-Android distros I can write an app, run it on my desktop without any additional software installed, and then copy it to the phone as is. And it will run.
Again, nothing prevents this from occurring. More power to you if you can write Ruby apps on non-Android distros, but you seem to be missing the point about the nature of Android and the mobile development marketplace. It locks on a Java variant because it is strategically sound to lock and focus on the masses of J2ME developers (not on virtually non-existing mobile python/ruby masses.)
More importantly And there is nothing on Dalvik that prevents it from EVER and FOREVER running something else should market forces end up driving that need.
This is just to show that money neither buys class nor precludes one from committing stupid, senseless (and this tough economy, insensitive) acts of excessive tackiness and expensive attention whoring.
Slashdot Mirror
The language is portable to any platform, very powerful, and isn't at-risk of suffering the same fate as Java.
The criticisms of it are mostly fluff in my opinion...people trying to say that their personal stylistic perferences should be industry standards, or justifying their own lack of skill by saying C++ makes things harder than they should be, etc.
C++ is not an application-level programming, but a systems-level one. Java plays both roles. Furthermore, it is not the language that is of value, but the enormous (and standard) class library; a defined component model standard for distributed computing; a defined component model standard for thin-client development; a defined standard for persistence; a defined transactional model; etc, etc, etc.
Many of the things mentioned above (sans the hiccups and false starts) have been refined, tested and tried on the field for a decade now. That is what's lacking in C++ (a language that I like more than Java... and I work on Java for a living mind you.)
There are no comparison between the two languages because they are incomparable; defined and designed for two completely different niches and roles. It's not about replacing one language with another, but about replacing an entire ecosystem with another one.
Having worked on both, worked on Java for the last 12 years (on both application and system development) and about to work again in C++ and C (embedded stuff), I can tell you this:
C++ (or the lack of equivalent enterprise/distributed plumbing) makes it unsuitable for the roles fulfilled by Java (or .NET). And vice versa, Java (despite having a shitload of de-facto and de-jure standard plumbing) is unsuitable for the roles filled by C++.
When you work with both languages and when you work on both application and system development, you very quickly how different they are; how silly is to compare them; and how impractical (if not impossible) is to consider using one in place of the other.
Google tries to pull a Microsoft and splinter the Java platform in a very bad way. Embrace, extend, destroy.
Google hasn't created a java platform to compete with Oracle's. They created a virtual machine that reads in completely different byte code. It just happens that you write the source in Java.
Not source in Java, but source in a subset of Java. You can't legally provide a subset of Java, or a superset of it as per the Java license agreement. Google would have been better off implementing an entire different name space of libraries outside of the java, javax. and org. namespaces delineated in the standard JDKs.
I don't necessarily think that Google did something extremely evil or fragmentary, but they did something that was legally murky (as per the Java license agreement) banking on the defunct Sun being too weak/unable/stupid to go after them.
They should have started with a branch new name space of libraries or they should have bought Sun when they had the chance. </blooper>
Nope. Microsoft modified Java's platform and still called it Java. It wanted to add incompatible features and extend Java to its liking, ruining the write once run everywhere.
There was already a Sun/Oracle lead platform (and strategy) for Java on the phone, it was JavaMe and it wasn't good enough.
Google is thus taking the result of the compilation of a Java program and making it run on a phone in a different platform. It never clamed dalvik to be a Java VM, it just uses the Java language. That's very different from what Microsoft did.
Google has no interest in destroying the Java language and platform. It uses it in several places, including Google App Engine.
And herein lies the problem. A legal implementation of a Java run-time or compilation must ensure the java and javax namespaces are exactly as laid out in the Java license agreement. Not a superset (as MS tried to do with J++) nor a subset as in the case of the Android runtime.
You probably should have read the first few paragraphs:
... and ...
The entire document relates to and describes terms of service for the website, not Android. If you want to know about the licensing terms for Android you need to look at the license(s) in the source.
Not just for the website, but for (and I quote the lines you just quoted, emphasis mine):
1.2 Your use of products, software, services and websites in connection with the Open Handset Alliance website
So, it is not just related to (and describing terms of) service for the website but:
related to the OHA website. Somehow I think Android is a) a product and/or b) a software related to c) the OHA website (and/or the OHA itself which is also a Google trademarked name.)
The article says:
...A lot of light emitting diode, especially white light emitting diode, uses phosphor powder to stimulate light of different wavelengths. However, phosphor powder is highly toxic and its price is expensive. As a result, Dr. Yen-Hsun Wu had the idea to discover a method that is less toxic to replace phosphor powder. ...
By implanting the gold nanoparticles into the leaves of the Bacopa caroliniana plants, the scientists were able to induce the chlorophyll in the leaves to produce a red emission. Under a high wavelength of ultraviolet light, the gold nanoparticles were able to produce a blue-violet fluorescence to trigger a red emission in the surrounding chlorophyll.
So it sounds like the trees need a "high wavelength of ultraviolet light" to get them to glow. Seems like they are just replacing the phosphor that makes a white LED glow with these gold implanted leaves. But you'd still need a UV light source (which could be an array of UV LED's?).
I'm not sure that this is really an environmental win -- replacing an array of white LED's that last 10 years with an array of UV LED's that point to trees that need their leaves to be impregnated with gold (and replaced annually?) doesn't sound all that environmentally friendly. How bad is the LED phosphor for the environment?
The point of this research is not say "aha! this is the solution". It is an exploration of a technique in its embryonic stage. Obviously, it is not about coating all trees down the boulevard with gold nano particles and having them bathe under directed UV lamps.
What if this can lead matter manufactured from trees and leafs (like paper) that glows under slight UV radiation, all of that packaged into a light source?
Or genetically modified (and necessarily sterile) trees and plants that can absorb natural UV from the sun and glow at night (Pandora here we come)?
Either one (and many other ideas) seem far-fetched, but so was the idea that everyone would have a computer the size of a cell phone with which to watch videos many decades ago.
Every single useful product we have today has its root on prototypes that were impractical (and perhaps even dangerous) for general use. And that's what TFA is showing, a prototype with the goal not necessarily to produce glowing, gold-coated Pandora-like trees, but searching for less toxic (and hopefully more affordable and eco-friendly) lightning technology.
For people who like to think of themselves as highly technical, many /.'ers seem to have zero understanding of what research is about.
Conifers don't lose their leafs on autumn.
It has a lot of features Java 8 will presumably have but looks almost like C#. I wonder if they're not running into problems with Microsoft there.
They have a copyright on the delegate syntax? </rolls eyes + sarcasm>
OK, replying to myself because I obviously didn't have enough coffee yet:
They list as the benefits over Scala - Extensible type system - Easy transition from Java - Reified Generics
From those 3 points, only the last one sounds useful...
You are kidding right? In reality-land, for better or worse, #2 is probably as important of all for a lot of Java shops as #3 if not more. Type erasure sucks balls, but we can get it to work (just as we were able to write good working code without generics.)
Adoption and ease of transition are things people tend to undervalue/underestimate. Being able to leverage a language with better qualities with as little code change as possible is certainly an enormous, practical incentive. For me, I would give an eye to work on something else (Scala, Ruby/Python on the VM or Clojure), but the reality on the ground is that something like Groovy (using the Groovy++ compiler, though) is the most likely candidate for adoption given its easier transition.
Gosu seems to embrace the good qualities of next gen JVM languages (and C#) without a substantial deviation to the syntax.
Necessary /. anti-fanboy disclaimer: Before the /. fanboy crowd displays their usual lack of reading comprehension, I'm not saying that Java syntax is superior or that the syntax sported by the other JVM languages is deficient or bizarre. I'm simply stating the fact that there is an associated, practical cost of transition (in terms of education, time of getting proficiency, possible introduction of coding errors, etc) that is proportional to the syntax differences that need to be overcome - this without considering the external pressures of writing software for solving problems in the right here and right now.
With infinite time and resources, and zero friction from requirement/requirement changes and organization dynamics, syntax differences would not matter. AFAIK, that is not the context in which programming shops operate. . Another important addition is the use of delegates. Oh my, I can only think of the possibilities we currently can only do in Java with a lot of boilerplate.
Replacing Java with another JVM language doesn't help you one bit if you have a problem with relying on Oracle software
1. Most people don't have a problem relying on Oracle software (and by that I mean Oracle's commercial software and not the libs under the java/javax namespaces).
2. Your statement is pretty much non-sequitur. Seems more like a problem statement looking for a problem to reference to.
That's the most bonkers thing I've ever read.
Not really, it actually closely resembles practical things that need to be done in many large scale systems written in procedural languages. People have been doing a lot of (mostly) good things to implement re-use and modularity in procedural languages for a long time (just as there are plenty of strategic/tactical reasons to use a procedural programming language over an object oriented one.)
Furthermore, reading that gives the novice reader a glimpse at how things occur under the hood. At the end of the day, OO is syntactic sugar use for the sake of modularity and structural soundness. It eventually has to be implemented on a procedural manner (even if it is invisible to your eyes thanks to the compiler.)
I wouldn't recommend BASIC or LISP for someone wanting to learn modern object-oriented programming today. A lot of us started out with a structured languages like this, but you wouldn't want to start out that way if you were doing it for the first time now. My university uses Alice and it works pretty well. Alice teaches much more modern object-oriented principles that would be much more useful than BASIC or LISP to a modern programming student.
What a horrendous idea. If the whole goal is to learn more OO principles, that's a f* up goal by itself. Not everything is OO; reality is multi-paradigm; and beyond a certain granularity OO code is intrinsically tied to modular, structural and procedural principles. Barring the naturally gifted, people can't learn proper OO skills (much less general analysis and design skills) without knowing modular, procedural and structured programming.
One of the greatest failures of CS education has been the failure to teach that, the fallacy that you can simply use nothing but one or two OO languages and a 100% OO paradigm as a general plan for teaching programming. Testament of this is that, even after 3 decades, people still can't tell you precisely what a good OO system is like. One just have to look at the OO code base that is out there. Truly hideous and anything but OO.
A good chunk of people think they are doing OO when in reality they are using OO languages to implement poorly written procedural code (typically without any notion of structural soundness or modularity.)
In fact, a lot of what the world needs right now combines/requires procedural programming. RDBM access is strictly procedural/declarative - and don't bring the fallacy of ORMs. People can't effectively use ORMs without knowing the procedural/declarative interfaces that lie underneath it. Services are intrinsically procedural and so are the languages that interface/combine them (think BPEL.)
When people miss that and are confronted with the *real* multi-paradigm world, they either try to force a OO paradigm on the procedural interfaces/services, or the service-accessing code devolves into an in-cohesive, inflexible procedural lasagna.
I've been doing OO development for quite a while now, quite successfully if I may add, and I've worked in teams that have made the transition (quite successfully also) from procedural/modular to OO programming. From experience I can tell you most CS students cannot fully understand (or fail to understand) OO principles without understanding procedural, structural and modular principles (and spending a lot of credit hours in them.)
We need people that are exposed to the nitty gritty details of multi-paradigm realities of world problems, not pampered from the beginning with graphical systems intended to show... yay... more OO principles. You want to teach people more OO principles? Then lay a solid multi-paradigm foundation with plenty of credit hours in several programming languages, getting them to deal with issues of structure, modularity, procedures and the like.
Kids that get exposed to those will get much more mileage from OO education, and equally useful, that exposure will filter those who really can't cut it for CS because not everyone is cut for it (and this applies for any degree and people trying to get in them.)
This is more like a badly thought of solution looking for a problem no one practical wants to even touch with a 10-foot pole.
Not something as simple as writing ASCII by a long shot.
It isn't as complex or cumbersome as many of you think either. I know, I've seem them (Japanese) going at it. The challenges of Japanese writing are not unique to typing as they also apply to hand writing. There is really no option other than do what they do with their typing software. And it is very effective and not that cumbersome for someone that already knows Kanji, Katagana, Hiragana and Romanji (the usage of the Roman alphabet for Japanese words) - namely anyone literate in Japan.
Japanese is typed using a more-or-less standard QWERTY keyboard.
Tediously.
I've seen my wife going at it (and Japanese people in all types of computerized businesses on Japan). They certainly don't have much of a problem. Kanji writing is a unique and complex task not easily amenable for typing on a keyboard. Hiragana and katagana are much more amenable and most Japanese know to write with "Romanji". The software they use simply finds the appropriate Kanji, Hiragana and Katagana after they type the corresponding Romanji.
So in essence, they are typing just as we do using a Roman alphabet with the software doing the translation automatically just as modern word processors automatically correct misspells for you (and in both cases, the software gets it right most of the time.)
Oracle isn't going anywhere. This lawsuit isn't going to be anything at all like SCO/IBM or SCO/Novell because Oracle is many times larger than SCO is and is at least 2 orders of magnitude more relevant.
Java is everywhere. Schools teach it. Companies use it.
If Google really copied things from the Java source like actual source code or documentation, they might be screwed. It sounds like from the summary that the bulk of this 'copying' was the API, which I don't think is even eligible for copyright(not artistic).
The APIs are governed by a patent license that states how the APIs are to be presented. In fact it goes specifically to forbid presenting a subset or a superset of the APIs presented under the java.*, javax.* package/namespaces (and the org.* namespaces currently included into the J2SEE, J2ME and JEE profiles.)
Here is where Google is screwed since people that program for Dalvik are using a subset of the Java API (in addition to extensions.)
However...
The patent license was intended in this way to prevent someone from doing something that is a superset or subset of "official" Java, and call it Java.
Here, Google has never called what they do on Dalvik "Java". So on that technicality, they might (just might) have some legal room to maneuver.
However, Google has implicitly presented the Dalvik platform to Java developers (J2ME developers in particular) saying "you can using your Java skills to develop in Android. It's just like Java."
That kind of wording, however implicit as it might be, that can be justifiably open to litigation.
The jury is still out on how all of this is going to pan out, but it is important to understand (regardless of how you feel about it) the following:
By doing so, and by not buying Sun when they had the chance, Google has put itself is a midly annoying position. It is not a precarious one as I'm sure Google has enough muscle to fight it off (or come to a settlement with Oracle.) But it is an annoying one for everybody else.
Its considered unethical by the majority of scientists to recycle papers unless there is a significant update from one to the next, i.e., methods changed, or additional steps are taken which improve the results. It is not considered unethical to have your paper resubmitted to a different conference or journal if it was rejected from another however.
I know, I was referring to the former. In fact, referring a paper to different conferences (say within the same year), that I would *not* consider it recycling.
> I once had an English teacher who said, "If you have more than five consecutive words matching a source, without a citation then it's plagiarism." Perhaps that's how freshman writing assignments are graded, but it's silly when applied to scientific papers.
No. Just... no. It is not "silly," it is insulting, in either freshman english lit or scientific papers. Any teacher who defines plagiarism that way has a lot more to learn than he has to teach.
Perhaps so, but I could see where such a rule could come from, and it could instill a discipline of making sure things are properly cited. Without any other context, obviously the rule is rubbish, but I could see it as an excellent rule to live by when taking freshman courses in writing/composition.
Even though recycling is not plagiarism, I would love to see this tool being used to create some sort of recycling ranking for individual academics and colleges. There is a not-so-fine line between exploring different aspects of a subject and simply recycling for the purpose of maximizing presence. The former is necessary for the pursuit of research. The later is just f* dishonesty (and a costly one for society since it is typically used for securing research moolah.)
Because, because beyond certain point of recycling, it's just dishonesty.
I think you overestimate the number of J2ME devs compared to Symbian ones. There's a lot of those. And comparing anything to Apple is disingenuous as Apple wants the lock in of a little-used language, just like MS wants lock-in with .NET.
My comparison was never meant wrt to open vs locked-in. It is a given that any of the ones mentioned are meant as a way to lock in a given share of the consumer and development market.
Still, I would not have made the UI components java-based at all, as I think Java is a lock-in language all of its own.
It's always been a lock-in language. Where is the surprise in that?
(I shudder at all that "100% pure" Java marketing),
Why shudder at it? We have been developing from small to truly colossal systems in nothing but pure Java for the last 13 years. I don't quite follow the remark.
I think they should have made it more as open component, probably in C, with bindings for all languages the dev likes - so you can still code in Java if you liked, or C/C++, or python, all the time knowing you were getting a first-class support for interaction with the underlying system.
That could have been a possibility.
Is Java a better thing to code against? That depends on your skill set
This has nothing to do with skill sets. Really. For example, I can program in Java, C and C++ and have done programming at the application and system level, on both Unix and Windows (all the way down to the dinosaurs of Motif and raw Win32 API). But for application level programming, I'm sorry, productivity is up with a managed language (and the inverse is true for systems programming and a systems programming language.)
I can arm an application-level app (be it a UI or a back-end system) using a managed programming language a lot faster than with C or C++.) And there are things for which I'm much more productive using the later (say, having to implement a network protocol stack, flip bits or, I dunno, communicating through the serial port.)
Productivity is not simply about skills, but about using the appropriate tool for the appropriate task. There is no silver bullet nor golden universal hammer.
and before anyone says 'but we need to make it as easy as possible', if that was the case, the language used would have been Basic :)
Don't see what the problem with Basic is either. There is a lot of people that write crap code in Basic, but the same can be found with Java, Delphi or C/C++. It is an excellent tool when you need to write an application that shuttles data from one point (a db) to another (a screen) and where having to deal with the details under the hoods is not carrying a particular ROI for the given task.
I would have a problem seeing Basic being used when a lower-level language is more appropriate... and viceversa. There are no universal tools in programming.
Don't forget the VM is the OS as far as Java is concerned.
Exactly. That's the idea.
Google could easily have put that work into the Linux kernel (or the Android API layer) without needing to put a VM layer on top of it all.
And Ericson could have done the same with their telecommunications systems. Instead they implemented and deployed the Erlang VM with quite a lot of success. Having a VM opens a plethora of advantages. VMs have been explored for almost 3 decades now, with them being successful stories in the industry for last 18-15 years. Ruby, CPython, Erlang, Java, .NET CLR and so many flavors of systems written in Smalltalk, Lisp and Prolog, each a testament of how effective VMs can be.
There are times when you embed functionality at the kernel level. At others, you abstract it out to an operating environment running on top of it (in many cases in the
Dalvik on the other hand started (and has remained so) with support to a subset of Java. Why? Because it caters to the masses of J2ME developers already in existence; another strategic move, and a better response to iPhone's reliance on Objective-C.
This confuses me, see if they wanted a strategic language for Android that gained a absolute heap of developers, J2ME wasn't it.
Why not? The number of former J2ME developers is decent, and the transition to developing on a mobile platform is that much more cost-effective for the masses of J2SE/JEE developers out there. Google simply said "here, you know Java? Then you can use your skills almost without changes and be productive almost immediately".
It was C/C++ as used by Symbian.
Why would C/C++ be a better strategic language for Android? Do we have any ratio of C/C++ developers with Symbian experienced over the number of J2ME developers (and the potential J2SE/JEE developers that could be trigger happy and more than ready to do mobile stuff)?
Also, consider that it's not the quasi-Java language that Android programmers use that is the platform. It's the Dalvik VM. It is not beyond the realm of possibilities that the same VM will support subsets of Ruby and Python for mobile development, benefiting from a core of "blessed" libraries, sandboxed on a VM (which is more appropriate for application programming).
Add some symbian->Android conversion tools, libraries or frameworks and you'd have had a massive amount of development loveliness. To point this out, on many Android forums one cry I used to read a lot was "how can I port my existing C++ code to Android, why did they make it all Java".
One could also make the same argument with iPhone and Objective-C. There is a matter of application control that Google is pursuing here, and I have a suspicion that Google is not that kin of C and C++ given they are looking - for better or worse - for system programming language alternatives such as Go.
I think Google went Java because it was their 2nd (or is it 1st) choice language, and the guys doing the phone API happened to want to make it Java, probably no other reason than that.
That's all the reason they needed to be honest.
Now they should start improving the Qt abilities and getting a richer software ecosystem going instead of trying to lock it all down to Dalvik-code only. (ie make it easier and more supported, to write in C/C++ and maybe Python too)
I beg to differ. With a Dalvik VM, it might be a lot easier to create a Jython or JRuby subset to run on a common managed application core than to write it down on C/C++ and having a separate Python environment (the later with code managed independently of Dalvik and the former not being managed at all). With a VM, you can establish a lot of different application policies common to all run-times, enforced at run-time, with the OS unencumbered by them.
It is a model that has worked well on all flavors of Java, and on all things run by a VM (Erlang, Ruby, etc.) Google could have also gone the way you described, but I suspect they decided to go the way they did for the reasons mentioned above.
Obviously you would not get all the amenities you'll have on Python (.ie. ability to call C libraries.)
Why not, since Dalvik implements JNI?
Possibly because of the same restrictions placed already by Dalvik on the type of libraries one can execute under the java.* and javax.* namespaces.
I mean, this is all speculation from my part, but if Dalvik - by design - restricts on what is available under the java/javax namespaces (for a variety of reasons), it will also follow that it will put restrictions on executing arbitrary native code via JNI (as Google App Engine does now.)
Android is all cool and stuff, it's also FLOSS and great, and whatever.
However, it has its shortcomings which make it less than a desirable phone operating system for me. First of all, MeeGo, Maemo and their cousins allow me to run any vanilla GNU/Linux GUI applications. They are most often inconvenient to use on a phone, but they are sometimes better than what's available on the platform. On Android I'm limited to apps written for Android. Thanks but no thanks.
Also, programming for Android? You need Java or another language that compiles for JVM.
Just a small (but very important) correction It's not the JVM, but the Dalvik VM. Bytecode is different, architecture is different, and Dalvik by design will not run J2ME things that can run on a JVM.
Want to program in Python? Good luck. You can't, and you'll never can, because Jython isn't portable to Android.
Considering that Google App's engine primary language (for a while) was Python, I doubt that Python (or a subset of it) will never be supported on Android. To run Python on a VM, you. do. not. necessarily. need. Jython. You simply need (a yet to be developed) Jython-like equivalent for the Dalvik.
Obviously you would not get all the amenities you'll have on Python (.ie. ability to call C libraries.), but then again, you do not get all the Java amenities on Dalvik anyways. Now, the status quo is all the result of strategic considerations.
Google App engine supports Python and Ruby (and even Scala IIRC) because the web development bestiary is that much diverse. It caters to the widest possible set of development shops, a good strategic move.
Dalvik on the other hand started (and has remained so) with support to a subset of Java. Why? Because it caters to the masses of J2ME developers already in existence; another strategic move, and a better response to iPhone's reliance on Objective-C.
The Oracle-Google legal wrangling might actually give Google a reason to start supporting a different programming model should it comes to that. Given its historical support for Python, it could come to that as it is not infeasible (given Google's engineering resources), nor foreign (given its history with Python.)
There is nothing technical that prevents a subset of Python from ever running on Dalvik, ergo my objection to your position, which I quote - "You can't, and you'll never can, because Jython isn't portable to Android"
Want to program Ruby? Haha. With non-Android distros I can write an app, run it on my desktop without any additional software installed, and then copy it to the phone as is. And it will run.
Again, nothing prevents this from occurring. More power to you if you can write Ruby apps on non-Android distros, but you seem to be missing the point about the nature of Android and the mobile development marketplace. It locks on a Java variant because it is strategically sound to lock and focus on the masses of J2ME developers (not on virtually non-existing mobile python/ruby masses.)
More importantly And there is nothing on Dalvik that prevents it from EVER and FOREVER running something else should market forces end up driving that need.
All hail teh Google
This is just to show that money neither buys class nor precludes one from committing stupid, senseless (and this tough economy, insensitive) acts of excessive tackiness and expensive attention whoring.