If you are relying on running a jailbroken phone, then yes it is certainly easier. But still, it isn't a matter of porting an application framework to another OS -- you are really porting a big chunk of an OS to another OS.
I'm not saying it's not possible, but I am pretty sure it would be a quite significant amount of effort.
It won't be nearly that easy. The Android application environment makes no attempt to hide the underlying protected memory multiprocess kernel -- apps can create multiple processes for themselves, run services in the background, schedule events to be woken up in the background, connect to each other to communicate with IPC, etc. And of course there is the WebKit available through the WebView API that many rely on, etc.
Also the application model itself is very different than the iphone: in Android an app just stays running until the system decides to kill it, and the system maintains state about it while it is killed to help it restart in its same state. So you would need to have a lot of the persistent system services running (especially the activity manager) or app switching would be pretty broken.
And there is the global clipboard, too!;)
But it boils down to: Android is not just a Java application framework, it is a complete floor to ceiling operating system, and the application API reflects that.
Have you programmed in ML? Lisp? What about Prolog?
This is a good point -- learning languages that use the same paradigm as one you already know (such as procedural or OO) is fairly easy, but learning a new paradigm is hard.
But guess what? The typical CS coursework does teach you different language paradigms, because that is a fundamental part of computer science. For example, back when I was in school, the introductory "Artificial Intelligence" course was really a "functional programming with Lisp" class. There was also a specific course on ML, to educate on a lot of the new language concepts that were being introduced there. And one of our professors was doing research on multi-paradigm programming, so you could take his class to broaden your foundation even more.
All of this means that you get grounded in the theory and concept, which you can then take and apply to any specific language you need to use.
Btw, my suggestion for a rounded CS education: get a good CS foundation from your course work, but also make sure to do an internship and/or practical coding on your own. For example, there is a lot of opportunity these days to get involved in open-source projects, and being able to put this kind of experience on your resume (with code you have written that someone can actually look at) is a big plus.
Quite to the contrary: PalmOS on Linux will be highly backwards compatible with existing Palm applications according to Palm, probably more so than than Cobalt would have been. That's one of the big attractions of doing this.
Sorry, but this is completely incorrect. PalmOS for Linux will be the higher-level PalmOS COBALT system sitting on top of the Linux kernel. This is absolutely not Garnet being ported to Linux, it is Cobalt being ported to Linux. All of the compatibility code needed in Cobalt is still needed when moving to Linux, plus a little bit more to deal with some of the lower-level application APIs that are replaced by Linux.
The reason for doing this is that a large chunk of the work in writing Cobalt involved making the current PalmOS programming model sit on top of a modern, protected-memory operating system (like Cobalt and Linux are). We still need that new system architecture on Linux. If we just ported Cobalt, all you would end up with is PalmOS applications sitting in a big, isolated box, running in a single-threaded single-process world.
Btw, as far as compatibility goes, the backwards compatibility level of Cobalt is not that different than Garnet was when it was first introduced. The main difference is that it has taken a lot longer to get Cobalt devices out, so we haven't yet seen most of the expected application updates that will address many of the problematic apps.
PalmOS started out as Palm libraries on top of a third party kernel. With PalmOS 5, they added a 68k emulator into the mix. With that history, moving to a different kernel while preserving backwards compatibility should not be all that hard.
Because this history of the platform completely disregards Cobalt, it is quite wrong about when moving to Linux means. The 68k emulator is -purely- a 68k emulator -- it gives no help in providing compatibility for system APIs. All of that compatibility is a part of the system architecture, which also needs to be available to run existing applications.
For example, in Cobalt there is a header WindowCompatibilty.h that includes things like WinCreateWindowV50(). This is the API that PACE calls when a 68k app calls WinCreateWindow(), to have the Cobalt UI system create a window that is set up to run in a mode that provides the same behavior as pre-Cobalt versions of the system.
A lot of the problem is, the candidates may very well have excelled in what their college curriculum had taught them, but hey, bit masks are not exactly something most curriculums cover more than one or twice in passing.
I certainly do agree that it is important to have internship positions, for just this reasons. (I did in fact have one last year, but admitadely have been negligent in looking for someone this year.)
However there are also times when I need to hire a good experienced engineer... like now. And it is horribly difficult.
At any rate, you'll just have to trust me, most of the people I have interviewed aren't just experienced -- they are incompetent. They simply can't code. If that is the caliber of people we are pushing out of our schools, we are in trouble. (Fortunately I know it isn't.)
I 100% agree with this. Last time I was looking to hire people -- a couple years ago around the worst of the bust -- the available candidates were almost universally horrible. And it's not even something as "complicated" as subclassing -- most of the people I saw couldn't write code, period. More than once, we had people who struggled just figuring out hexadecimal conversions and bit masks.
To be fair, the job market I am interested in is *software engineers*. The market for IT or other parts of the industry may be quite different.
Now I have another position to fill, and I am dreading the prospect. Hopefully the situation has changed from a few years ago, but I doubt it; it seems like the only way to find good people is to lure them from other companies.
While I appreciate the concerns about increasing the cap, I also am in the position of having serious trouble finding good candidates. And on top of that, a few of my best engineers are here on visas and now having a horrible time getting their green cards and having to deal with all the other crap our government is doing to them. So I have the government apparently trying to drive away some of my best engineers, with a very doubtful prospect of even being able to replace them from the local "talent" pool.
That advice seems to come from a fairly narrow perspective. (Which is maybe the point of this whole thread, but whatever.)
First, XML is in now way shape or form a "Java-related Technology." It is less related to Java than JavaScript is (which itself is only related in name). The only similarity they have is their past/present status as Hot!! Web!!! Technologies!!!!
Second, it is quite strange to lump C with C++ in this way. In fact C++ is more similar to Java (or I should say Java is more similar to C++) than C is to C++. If you know one of either C++ or Java, you will find it fairly easy to learn the other. The rough spot for someone coming from a proceedural background is OOP programming itself; once you have the methodology down, it's mostly just syntax. Little different than the the original poster's previous experience moving between proceedural languages.
(In fact I could go farther and say that once you have C++ down it will be easier to move to Java... but C++ isn't a great language to learn OOP in, mostly because of its grungy syntax. However it has a lot of important concepts that don't exist at all in Java.)
I created such a system around the time Java was created (actually, it was started before Java was announced) called iHTML. It explored server-side languages that are both embedded in a document and allow DOM-like manipulation of a document (before there was a DOM, though). This isn't really interesting nowadays, though.
People who think there is a problem with the number of different Unicode encodings -- including the authors of this article -- completely misunderstand how unicode works. The different encodings are -not- different character sets -- in fact, they are different ways to write the -same- standard Unicode character set. The transformation between UTF-8, UTF-16, and UTF-32 is only a simple bit minipulation -- it is completely independent of the character set.
An implication of this is that UTF-8, UTF-16, and UTF-32 can all express the EXACT SAME NUMBER OF CHARACTER CODES. So, if you think UTF-32 is good enough for you, then UTF-16 and UTF-8 are just as good. The latter two simply use multi-word or multi-byte sequences to express the upper character values.
After using BeOS for a number of years, where all character strings are natively handled as UTF-8, I am a very strong believer in Unicode. Having a Western perspective I may be missing something, but none of the "problems" mentioned in this article are actually problems that Unicode has.
Of course, once you start using Unicode, the main problem you are going to run in to is having fonts with the characters you need. And if the Chinese, Japenese, etc. really need 50,000 of their very own characters, then this is going to be that much more of a problem. Unforunately, there is no easy solution to this -- but it doesn't have anything to do with the encoding you use, so changing to another encoding is not going to help here.
There are
guidelines, but after 9pm ("the watershed") more or less anything goes language wise.
And if you would read the report before commenting, you would see that it is the same situation in America -- despite some attempts by congress to apply the indecency rules 24 hours a day, the courts have ruled that they can not be applied from about 10pm to 6am. In addition, certain types of broadcasters are completely exempt from them.
And to say that the FCC is regulating religious content is insane. Again, look at the damn document. There isn't a single comment about religon, either as something allowed or not. It has nothing to do with the decency guidelines.
I wouldn't claim that American society is at all healthy about sex, but you are completely wrong about how the government can legally control content.
It really sounds like you should try BeOS, if you haven't already. I know that, personally, it is the only operating system I have found so far that feels like a sufficient "step up" from the Amiga, and I know a number of other past Amiga owners who feel the same way.
Of course, the BeOS isn't perfect... any more than the Amiga was. And it certainly isn't a direct descendant of the Amiga, design-wise. However, I find it has much of the same ephemeral feel that I liked about the Amiga -- many of its design trade-offs strike me as, "what I person designing the Amiga would have done, if it had been ten years later." One of the primary goals of the system, for example, is to provide a highly responsive and interactive interface to the user.
And best of all, using BeOS lets you enjoy the pleasures of a nice, marginal platform, just like the Amiga did... with the difference that Be's management seems to actually be -sane-.;)
Slashdot Mirror
If you are relying on running a jailbroken phone, then yes it is certainly easier. But still, it isn't a matter of porting an application framework to another OS -- you are really porting a big chunk of an OS to another OS.
I'm not saying it's not possible, but I am pretty sure it would be a quite significant amount of effort.
It won't be nearly that easy. The Android application environment makes no attempt to hide the underlying protected memory multiprocess kernel -- apps can create multiple processes for themselves, run services in the background, schedule events to be woken up in the background, connect to each other to communicate with IPC, etc. And of course there is the WebKit available through the WebView API that many rely on, etc.
Also the application model itself is very different than the iphone: in Android an app just stays running until the system decides to kill it, and the system maintains state about it while it is killed to help it restart in its same state. So you would need to have a lot of the persistent system services running (especially the activity manager) or app switching would be pretty broken.
And there is the global clipboard, too! ;)
But it boils down to: Android is not just a Java application framework, it is a complete floor to ceiling operating system, and the application API reflects that.
Dalkvik is not at all specific to the G1. The G1 is just running a standard ARM CPU.
This is a good point -- learning languages that use the same paradigm as one you already know (such as procedural or OO) is fairly easy, but learning a new paradigm is hard.
But guess what? The typical CS coursework does teach you different language paradigms, because that is a fundamental part of computer science. For example, back when I was in school, the introductory "Artificial Intelligence" course was really a "functional programming with Lisp" class. There was also a specific course on ML, to educate on a lot of the new language concepts that were being introduced there. And one of our professors was doing research on multi-paradigm programming, so you could take his class to broaden your foundation even more.
All of this means that you get grounded in the theory and concept, which you can then take and apply to any specific language you need to use.
Btw, my suggestion for a rounded CS education: get a good CS foundation from your course work, but also make sure to do an internship and/or practical coding on your own. For example, there is a lot of opportunity these days to get involved in open-source projects, and being able to put this kind of experience on your resume (with code you have written that someone can actually look at) is a big plus.
Sorry, but this is completely incorrect. PalmOS for Linux will be the higher-level PalmOS COBALT system sitting on top of the Linux kernel. This is absolutely not Garnet being ported to Linux, it is Cobalt being ported to Linux. All of the compatibility code needed in Cobalt is still needed when moving to Linux, plus a little bit more to deal with some of the lower-level application APIs that are replaced by Linux.
The reason for doing this is that a large chunk of the work in writing Cobalt involved making the current PalmOS programming model sit on top of a modern, protected-memory operating system (like Cobalt and Linux are). We still need that new system architecture on Linux. If we just ported Cobalt, all you would end up with is PalmOS applications sitting in a big, isolated box, running in a single-threaded single-process world.
Btw, as far as compatibility goes, the backwards compatibility level of Cobalt is not that different than Garnet was when it was first introduced. The main difference is that it has taken a lot longer to get Cobalt devices out, so we haven't yet seen most of the expected application updates that will address many of the problematic apps.
Because this history of the platform completely disregards Cobalt, it is quite wrong about when moving to Linux means. The 68k emulator is -purely- a 68k emulator -- it gives no help in providing compatibility for system APIs. All of that compatibility is a part of the system architecture, which also needs to be available to run existing applications.
For example, in Cobalt there is a header WindowCompatibilty.h that includes things like WinCreateWindowV50(). This is the API that PACE calls when a 68k app calls WinCreateWindow(), to have the Cobalt UI system create a window that is set up to run in a mode that provides the same behavior as pre-Cobalt versions of the system.
I certainly do agree that it is important to have internship positions, for just this reasons. (I did in fact have one last year, but admitadely have been negligent in looking for someone this year.)
However there are also times when I need to hire a good experienced engineer... like now. And it is horribly difficult.
At any rate, you'll just have to trust me, most of the people I have interviewed aren't just experienced -- they are incompetent. They simply can't code. If that is the caliber of people we are pushing out of our schools, we are in trouble. (Fortunately I know it isn't.)
I 100% agree with this. Last time I was looking to hire people -- a couple years ago around the worst of the bust -- the available candidates were almost universally horrible. And it's not even something as "complicated" as subclassing -- most of the people I saw couldn't write code, period. More than once, we had people who struggled just figuring out hexadecimal conversions and bit masks.
To be fair, the job market I am interested in is *software engineers*. The market for IT or other parts of the industry may be quite different.
Now I have another position to fill, and I am dreading the prospect. Hopefully the situation has changed from a few years ago, but I doubt it; it seems like the only way to find good people is to lure them from other companies.
While I appreciate the concerns about increasing the cap, I also am in the position of having serious trouble finding good candidates. And on top of that, a few of my best engineers are here on visas and now having a horrible time getting their green cards and having to deal with all the other crap our government is doing to them. So I have the government apparently trying to drive away some of my best engineers, with a very doubtful prospect of even being able to replace them from the local "talent" pool.
For what it's worth, Palm OS Cobalt already does have full support for multi-threaded programming in the Protein APIs.
That advice seems to come from a fairly narrow perspective. (Which is maybe the point of this whole thread, but whatever.)
First, XML is in now way shape or form a "Java-related Technology." It is less related to Java than JavaScript is (which itself is only related in name). The only similarity they have is their past/present status as Hot!! Web!!! Technologies!!!!
Second, it is quite strange to lump C with C++ in this way. In fact C++ is more similar to Java (or I should say Java is more similar to C++) than C is to C++. If you know one of either C++ or Java, you will find it fairly easy to learn the other. The rough spot for someone coming from a proceedural background is OOP programming itself; once you have the methodology down, it's mostly just syntax. Little different than the the original poster's previous experience moving between proceedural languages.
(In fact I could go farther and say that once you have C++ down it will be easier to move to Java... but C++ isn't a great language to learn OOP in, mostly because of its grungy syntax. However it has a lot of important concepts that don't exist at all in Java.)
I created such a system around the time Java was created (actually, it was started before Java was announced) called iHTML. It explored server-side languages that are both embedded in a document and allow DOM-like manipulation of a document (before there was a DOM, though). This isn't really interesting nowadays, though.
People who think there is a problem with the number of different Unicode encodings -- including the authors of this article -- completely misunderstand how unicode works. The different encodings are -not- different character sets -- in fact, they are different ways to write the -same- standard Unicode character set. The transformation between UTF-8, UTF-16, and UTF-32 is only a simple bit minipulation -- it is completely independent of the character set.
An implication of this is that UTF-8, UTF-16, and UTF-32 can all express the EXACT SAME NUMBER OF CHARACTER CODES. So, if you think UTF-32 is good enough for you, then UTF-16 and UTF-8 are just as good. The latter two simply use multi-word or multi-byte sequences to express the upper character values.
After using BeOS for a number of years, where all character strings are natively handled as UTF-8, I am a very strong believer in Unicode. Having a Western perspective I may be missing something, but none of the "problems" mentioned in this article are actually problems that Unicode has.
Of course, once you start using Unicode, the main problem you are going to run in to is having fonts with the characters you need. And if the Chinese, Japenese, etc. really need 50,000 of their very own characters, then this is going to be that much more of a problem. Unforunately, there is no easy solution to this -- but it doesn't have anything to do with the encoding you use, so changing to another encoding is not going to help here.
And if you would read the report before commenting, you would see that it is the same situation in America -- despite some attempts by congress to apply the indecency rules 24 hours a day, the courts have ruled that they can not be applied from about 10pm to 6am. In addition, certain types of broadcasters are completely exempt from them.
And to say that the FCC is regulating religious content is insane. Again, look at the damn document. There isn't a single comment about religon, either as something allowed or not. It has nothing to do with the decency guidelines.
I wouldn't claim that American society is at all healthy about sex, but you are completely wrong about how the government can legally control content.
It really sounds like you should try BeOS, if you haven't already. I know that, personally, it is the only operating system I have found so far that feels like a sufficient "step up" from the Amiga, and I know a number of other past Amiga owners who feel the same way.
;)
Of course, the BeOS isn't perfect... any more than the Amiga was. And it certainly isn't a direct descendant of the Amiga, design-wise. However, I find it has much of the same ephemeral feel that I liked about the Amiga -- many of its design trade-offs strike me as, "what I person designing the Amiga would have done, if it had been ten years later." One of the primary goals of the system, for example, is to provide a highly responsive and interactive interface to the user.
And best of all, using BeOS lets you enjoy the pleasures of a nice, marginal platform, just like the Amiga did... with the difference that Be's management seems to actually be -sane-.
-- Dianne