Nope, YOU are incorrect because HTML contains stand alone tags such as , etc. that are not legal in XML, except if you write them as or . This is what XHTML does, more or less.
Uh, no. HTML is an SGML based language ("an application of SGML). XML is a subset of SGML. XML and SGML are not languages. They are a set of rules on how to make markup languages.
Pigs are animals. Monkeys are animals. This does not make pigs monkeys. "Animal" is also not anything physical. It's a type of a living being.
What part about XML is not "agreed on"? You can go to www.w3c.org and read exactly what is agreed on and when. I use and have used XML in my daily work for a couple of years now and I have never had ANY problems with any products not understanding XML produced by other vendor's parsers.
'cause I don't want tohave to worry about "Microsoft XML" and "Sun XML"...
*sigh* Why couldn't you just read the story? This is not about MS XML and Sun XML. XML is and remains defined and agreed upon like before. This is about an XML based language used to transfer "ecommerce messages" (simplified explanation). Just like there is SOAP and XML RPC for remote procedure calling over HTTP, there are various languages for "ecommerce messages". BizTalk, supported by Microsoft, is just one of the many. The battle is about which of these will become the most popular. It's not about someone trying to embrace and extend XML.
What does HTML and the web have to do with XML? XML is used on the server for data markup. It is then processed and stored in databases, sent to other servers, or transformed into something displayable, like HTML. XML is not something you will have on a web page like a Java applet or a MIDI tune. To do the data crunching and processing, you use an XML parser with DOM or XSL transformations. It's needed because SGML was too loose of a specification to be practical. XML defines a set of easy to implement rules about how documents are built, how DTD's for the document types are described etc.
Now here's something for you to disagree with: XHTML should replace HTML as soon as possible so that we can get rid of the horrible beast! Hopefully IE5.5 and Mozilla and WAP 2.0 will make the transition faster.
This is not about XML! It's about BizTalk vs. Sun's e-business XML language. Nobody has any problems agreeing upon what XML is and how it works. The whole point of XML is to create new languages - hence eXtensible.
Besides, to those who bash Microsoft for embracing and extending others standards, it's worth nothing who wrote the original XML spec:
Editors:
Tim Bray, Textuality and Netscape
Jean Paoli, Microsoft
C. M. Sperberg-McQueen, University of Illinois at Chicago and Text Encoding Initiative
Eve Maler, Sun Microsystems, Inc. - Second Edition
It's just as much Microsoft's standard as it is Sun's and Netscape's and if anyone is going all out for XML, it's Microsoft. Which is not to say that Sun wouldn't be going all out for it; just take a look at java.sun.com today!
Nope, because Palm used to be owned by US Robotics, if memory serves. Nice try tho.:) I actually met one of the original designers of the Palm OS some time ago but it came up so fast that I didn't have time to think of anything smart to say. I more or less just dissed the memory management in the OS.:)
Well, the moderators are really blowing it here. Interesting or not, this is completely off topic. Recall, the topic was "Can you back up data on Audio/Visual media?"
Now awaiting the obligatory rationalization as to why it should still not be rated "Off Topic"...
Oh please. It's on topic because it's directly refering to a link in the posted story that around 70% of all web surfers will be unable to view because of a lame-ass browser based blocking.
The only reason people have problems with that post is that it is saying something positive about a Microsoft product.
Off-topic moderation is for Natlie Portman and Beowulf cluster postings - not for stuff like this. You will find 50 "Microsoft sucks" postings on your average "New Planet Found" story and I never hear anyone crying "moderators, wake up!" on those so relax a little and moderate the really BAD stuff and the really GOOD stuff. IMHO, my post didn't deserve "interesting" but it also sure has hell didn't deserve "off topic".
Ironically, should be inside.. so the *page* is incompatible with Internet standards. Meanwhile, IE continues to be more standards compliant than Netscape, which is recommended. Seriously, this is one of the lamest things I've seen in a long time. I mean, I have Netscape 4.76, IE 5.5 and a two day old Mozilla nightly build but I won't use any other browser than IE for recreational surfing because there is just no contest in terms of speed and stability. I don't think I've *EVER* seen my IE 5.5 crash and I've used it for months now.
If Mozilla would fix some of the REALLY bad bugs it has (such as considering form fields with display: none as "non successful" (check the HTML 4 specs), being unable to properly refresh DHTML pages, using native scrollbars in XUL widgets (combo boxes), taking a window 3 seconds to open, losing bookmark names when copy & pasting, etc.) and if Mozilla would get fast enough to actually be usable, I'd love to switch. Until then, I'll stick with the #1 browser out there.
Opera has a lot of potential too and I'm looking forward to their next major release but the current version has too many layout and JavaScript implementation bugs to be usable.
Netscape 4.. There's no point in even mentioning the ways it sucks and is non-standards compliant but for the sake of the argument, let's mention IFRAME's, DOM, 85% of the CSS1 standard missing in the implementation, *horrible* table rendering performance and correctness, form widgets being native and thus not z-orderable, Java VM being barely 1.0.2 compatible with a buggy 1.1 AWT implementation... Like I said.. it sucks in too many ways to even mention.
got the impression that the O(n^2) nature of IRC made scalability a problem (every change at every server needs to be propagated to every other server). Similarly, this was initially designed for sending 50 byte packets of gibber-gabber, not whole files.
As I understand DCC, which is used for actual file sharing, is peer-to-peer. It's the directory service part that will work using IRC. In that light, it will not be too heavy weight but you are right about IRC having scalability problems.
BugTraq will still publish MS security bugs/holes - they just cannot cut & paste the MS bulletins directly. Most UNIX bugs will not even HAVE bulletins to copy & paste. This is an absolute non-issue and definitely not news-worthy, unlike many other stories.
Why on earth should I have to do this. I don't recall having to "roll my own" strings in C or C++.
Uh, hello? C doesn't have strings. C has char arrays. Here, you can do the same in Java:
char[] myString = new char[40];
This is my point. If you say C strings don't take up as much space, I say: neither does C-like-char-array-strings in Java. Now calculate a hash-code for your C-string. What? Not so convenient anymore? For this reason, if you want convenience and the power of the unicode 16-bit string objects in Java, but the speed ans size of 8-bit char arrays in C, I suggest you roll your own string handler class that works much like strstr, strcpy etc. does in C, except it would be in Java. I bet 10000 people have already done this. I was merely saying that if you need speed and size, you can always do that. There's nothing inheritly big and memory hogging in the Java language itself. It's how you typically use it.
A little comment to my example above: I used char's, which are in fact what String objects are made of; 16-bit unicode chars. For C-like 8 bit chars, you would use "byte"'s...
The bloat he was referring to has NOTHING to do with the size of the runtime download, nor with the size of the developer files. He was referring to the memory overhead that java puts on programs.
Before you say "Use JNI, it's the VM not java", let me explain to you why you have your head up your ass.
I'm not saying "use JNI" because then I would be sacrificing portability so YOU take your head out of YOUR ass and stop putting words in my mouth and then giving counter claims to stuff I've never said. Very poor manners!
I'm pretty sure he was refering to API bloat, which you *could* argue is there.. Memory overhead is not really an issue, however, and you can get memory much cheaper than you can get coders to write the same stuff in C so that it would save a couple of megs of ram. Besides, you can optimize very well for size in Java too by not using heavy weight stuff like String objects for everything. If you plan on using a lot of strings, roll your own 8-bit string containers and write a separate handler class for it to minimize overhead for methods in the string container class. Just because you're not programming in assembly doesn't mean you have to - to quote you - have your head up your ass when you make design decisions.
It is a "True OO" language. It's is a "High Level" language. The higher level the language, and the more OO the language, the slower it runs and the more memory it takes up. That's a FACT.
Yes, you are very right there. There doesn't have to be a huge overhead in OO (as opposed to using structs with function pointers for instance) but the way you write an OO app usually means that you have a lot of method calls going on from object to object. If you want to write a very fast and also size optimized Java app, you can do it the same way you would in C. Yes it will be slower. Yes it will eat more RAM. But it will most probably also be fast and small enough, unless you're coding an OS, a game or a web browser.
As an obvious starting point, garbage collection. It's very nice and you can be lazy about keeping track of your objects, but it causes overhead.
Ah, you might think it's obvious and a big overhead, but it's not. First of all, garbage collection happens much more rarely than people think and it doesn't take nearly as long as people often think. In a large application, gc is more efficient than manual malloc & free. Why? Because complex apps have complex object life cycles that you have to track yourself if you have no gc. You might have references to memory from several places in an app with several threads and it's not easy to know when something can be freed. Having a *good* gc implementation do the work for you allows you to focus more on your own code. In many systems, you will find very gc-like structures for stuff like exception handling, with pointers pushed on a stack that is then cleaned up when you leave a method early due to an exception. Gc is much more convenient and not a big overhead at all. By re-using objects, you can also minimize (almost to zero in many cases) how often gc is called. That is, unless you have your head up your ass.
it takes to.long.to.get.to.my.method(half, of, the, time);
Huh? And how is this any different from if you have a pointer to a struct with a pointer to a struct with a pointer to a struct in C? If you feel like it, you can have everything declared global and even write code outside of methods. Yes, you actually can do that in Java even though most people don't know it:
public class TryMe {
static {
System.out.println("i am not in a method");
}
public static void main(String[] args) {
System.out.println("i am in main()");
}
}
And of course in a properly designed app you don't HAVE to type long stuff like that because the complexity is hidden in the objects. All that point shows, Taco, is that you can't code object oriented languages properly. Read up on your design patterns...
and then there's the fact that when Java was new and exciting I wrote a video game in it, only to have Sun cease-and-desist me for calling it "Java Invaders".
What does that have to do with Java? That has to do with *SUN*.
(oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here to, even tho that is definitely fair use).
And again.. SUN - not Java.
Other then that, my only problem with Java is that the VM in Netscape is crap.
And now Netscape instead of Java.. This is actually a reason many people think Java is inheritly unstable and slow tho so it's a little sad. The company I work for has several large scale sites running Java in business critical functions and have uptimes of months and months. No crashes, no speed issues, no Netscape VM's.
Oh, and their licensing.
J2SE is free for anyone to use. It's source code is downloadable so you can see how everything works. Granted J2EE has a pretty lame licensing scheme, as do J2ME but most "Linux people" don't know what J2EE *IS* and that most of it can be downloaded separately without the lame licenses.
And the fact that its bloated.
Yes, that really is a problem isn't it? A Java 2 SE runtime download is about 5 MB.. That's terrible! Takes 30 seconds on a decent network connection.. and who has hard drive space for that anyway?
And the fact that I don't have enough time to type in all the reasons it irritated me *grin*
I think you don't have any good reasons really. If those were your two cents, I'd be asking for change...
Non-networked? This is hardly the first networked PDA! I IRCed and surfed the net on my trusty Psion 3a back in 1995 and I think just about every PDA since that has had network support. There's even a port of Opera for the current Psion models that should also run on the upcoming Epoc PDA/phones such as the Nokia 9210 that uses Epoc Crystal as it's OS. Windows CE's, now known as Pocket PC's have just about every network tool imaginable available for them, including a pretty good web browser, email apps etc.
I just installed the Palm Mobile Internet Kit on my Palm IIIx today and I've run pdqSuite on it forever, surfed the net and read my email with Eudora while driving home from work.
Compaq iPaqs also run a port of Linux if memory serves, so it's not a first in that arena either.
While definitely cool, I'm not totally convinced that Linux is the right OS for a PDA tho. A modern OS like Epoc that is designed specifically for small devices seems like a much better choice and the SDK's are pretty good. (http://www.symbian.com/)
There's a lot of backing for Epoc from Ericsson and Nokia - and Psion, obviously and Palm OS is also looking strong with just about every PDA & phone maker from Nokia to Sony coming out with models running it in the near future. The common denominator on all of these seems to be that they all run Java. The next version of the ARM cpu runs Java bytecode, Siemens, Nokia and Motorola have announced that they will support Java in their phones and virtual machines already exist for Windows CE and Linux.. The future will definitely be interesting in the PDA arena. It shouldn't be as black and white as the consumer PC market with Microsoft having 90% of the marketshare.
Hotspot works by JITting only parts of the code - the parts that get run a lot (hotspots) - and tuning & optimizing these for speed. For the rest of the code, it's an interpreter. Because of this, startup time is low (no need to JIT the entire Swing toolkit, XML parser, CORBA, etc. etc. when you start up a complex app that uses all of these) and execution speed is typically at least as good as for a JIT.
If you think Intel is going down, why don't you short some Intel stock? There are billions to be made and for shorting stock, you don't even need money! Coming to think of it, you'd think a lot of Slashdot readers should be shorting Microsoft stock. Talk about an opportunity to make money there!!
That is.. if you truly believe they are going down. Kinda makes you wonder...
Funny thing how nobody here mentions that it runs Java. In my opinion, that's one of most important features on this. It's no Java 2 ME either, with KVM that has such a crappy GUI toolkit it's hardly worth mentioning. No sir, it's a full Personal Java implementation and there's a good SDK for it, downloadable at www.symbian.com, where you can also get the C++ SDK for the Epoc OS. Now before anyone says "write once, debug everywhere", I can tell you that I've actually coded Java apps that were run on the Epoc OS (a Psion 5mx device) and I could code everything from scratch on my desktop and just move the code to the Psion and everything worked right away, without *any* changes to the code - no problems what so ever.
Now thing about what you can do.. RMI to do distributed & mobile apps (remote control your sauna, VCR & whatnot), JDBC to databases, games.
The real strength here is that they have good free SDK's for it so there will a flood of applications for the phone - and those apps will be compatible with all other Epoc devices, such as those made by Psion and Ericsson and perhaps a little later, by Motorola.
What is happening here is a clear division of the mobile industry into Epoc & Java vs. Windows CE. Don't miss what's going on! This is the next "browser war"!
It doesn't need to run KVM because it comes pre-packaged with a full Personal Java virtual machine that actually has a good AWT implementation, unlike KVM. You can download the Java SDK and the C++ SDK for the Epoc OS at www.symbian.com
Not so. You say "you are uniformed and hasty in your conclusions" and then you say stuff like I quoted above. I have extensive experience in large scale web site back end design and have been a lead engineer in several sites that have very heavy loads (such as large dot-coms and large e-commerce sites for more traditional "chimney" companies). I do know what I'm talking about here.
I know quite well that a site might need to pull data from a large number of data sources to build up a page (especially in personalizable portal-type front pages). This doesn't mean that you have to do a large amount of database queries, however. Caching is one crucial strategy if you're going for scalability and speed, for instance. Planning the site and page layout so that you don't need so much data for one page is also crucial. If there is no clear simple way to cache the data you need to produce something more complex then cache the result (yes, the HTML!) and only update the HTML every so often - as needed - based on some flag. Read the flag together with some other data that you must get from the database anyway. This is what I'm talking about.
I'm honestly majorly surprised that the performance test mentioned that the site used a page that required 16 queries. When I saw the performance results, I wasn't so surprised they were so poor. I'd like to see the source code for that page..
Perhaps the database was well designed from a data modelling point of view but not from a performance point of view. A good database design for a web site that needs to scale is such that it allows you to cache the data that is used most often. On a web site that gets 30 hits per second but where data only changes about once per 30 seconds, one should start thinking why the data is pulled from the database every single time. User profiles on personalized pages can be cached, data can be pre-fetched with one query, cached and then accessed from the cache when needed instead of doing several queries for a smaller result set etc. etc.. 16 queries is insanity!
One page may well be doing some extremely complicated processing, which has evolved over many iterations of the code - it's not hard to imagine that such a page could have 16 queries in it, especially if it's being written in an oo style.
I don't agree with that statement. In cases where you need data using 16 different queries, no doubt many of those could have been cached for a huge speedup. I've written code for back ends for several major sites and I've seen very complex funcationality indeed where only a few queries were needed per page - most data was pulled from caches. Also, OO helps you write code where you can fetch data lazily. For instance in a discussion forum, you might keep all root-level messages headers in a cache, the 1000 last accessed bodies in a cache, 10000 last accessed headers in cache, parent-child relationships in cache.. In this way, you don't have to go to the database 16 times every time users come to the front page of the discussion forum and are served the exact same page - 30 times per second.
Like you said, computer time is now significantly cheaper than programmer time. Well, memory is also cheap. Keep stuff in memory and use good old abstract data types to get your data fast.. RDBMS's are very overused these days.
Slashdot Mirror
Nope, YOU are incorrect because HTML contains stand alone tags such as , etc. that are not legal in XML, except if you write them as or . This is what XHTML does, more or less.
Uh, no. HTML is an SGML based language ("an application of SGML). XML is a subset of SGML. XML and SGML are not languages. They are a set of rules on how to make markup languages.
Pigs are animals. Monkeys are animals. This does not make pigs monkeys. "Animal" is also not anything physical. It's a type of a living being.
What part about XML is not "agreed on"? You can go to www.w3c.org and read exactly what is agreed on and when. I use and have used XML in my daily work for a couple of years now and I have never had ANY problems with any products not understanding XML produced by other vendor's parsers.
*sigh* Why couldn't you just read the story? This is not about MS XML and Sun XML. XML is and remains defined and agreed upon like before. This is about an XML based language used to transfer "ecommerce messages" (simplified explanation). Just like there is SOAP and XML RPC for remote procedure calling over HTTP, there are various languages for "ecommerce messages". BizTalk, supported by Microsoft, is just one of the many. The battle is about which of these will become the most popular. It's not about someone trying to embrace and extend XML.
What does HTML and the web have to do with XML? XML is used on the server for data markup. It is then processed and stored in databases, sent to other servers, or transformed into something displayable, like HTML. XML is not something you will have on a web page like a Java applet or a MIDI tune. To do the data crunching and processing, you use an XML parser with DOM or XSL transformations. It's needed because SGML was too loose of a specification to be practical. XML defines a set of easy to implement rules about how documents are built, how DTD's for the document types are described etc.
Now here's something for you to disagree with: XHTML should replace HTML as soon as possible so that we can get rid of the horrible beast! Hopefully IE5.5 and Mozilla and WAP 2.0 will make the transition faster.
This is not about XML! It's about BizTalk vs. Sun's e-business XML language. Nobody has any problems agreeing upon what XML is and how it works. The whole point of XML is to create new languages - hence eXtensible.
Besides, to those who bash Microsoft for embracing and extending others standards, it's worth nothing who wrote the original XML spec:
Editors:
Tim Bray, Textuality and Netscape
Jean Paoli, Microsoft
C. M. Sperberg-McQueen, University of Illinois at Chicago and Text Encoding Initiative
Eve Maler, Sun Microsystems, Inc. - Second Edition
It's just as much Microsoft's standard as it is Sun's and Netscape's and if anyone is going all out for XML, it's Microsoft. Which is not to say that Sun wouldn't be going all out for it; just take a look at java.sun.com today!
Nope, because Palm used to be owned by US Robotics, if memory serves. Nice try tho. :) I actually met one of the original designers of the Palm OS some time ago but it came up so fast that I didn't have time to think of anything smart to say. I more or less just dissed the memory management in the OS. :)
Now awaiting the obligatory rationalization as to why it should still not be rated "Off Topic"...
Oh please. It's on topic because it's directly refering to a link in the posted story that around 70% of all web surfers will be unable to view because of a lame-ass browser based blocking.
The only reason people have problems with that post is that it is saying something positive about a Microsoft product.
Off-topic moderation is for Natlie Portman and Beowulf cluster postings - not for stuff like this. You will find 50 "Microsoft sucks" postings on your average "New Planet Found" story and I never hear anyone crying "moderators, wake up!" on those so relax a little and moderate the really BAD stuff and the really GOOD stuff. IMHO, my post didn't deserve "interesting" but it also sure has hell didn't deserve "off topic".
Hey I agree with most of your points. However, IFRAMEs are not part of any standard.
h -16.5
Maybe you should check again: http://www.w3.org/TR/html401/present/frames.html#
I should have used "preview" on my previous post...
<html>
<title>Defective Browser:</title>
<body><h1>Access denied: incompatible browser.</h1>
Ironically, <title> should be inside <head>..</head> so the *page* is incompatible with Internet standards. Meanwhile....
Defective Browser:
Access denied: incompatible browser.
Ironically, should be inside
If Mozilla would fix some of the REALLY bad bugs it has (such as considering form fields with display: none as "non successful" (check the HTML 4 specs), being unable to properly refresh DHTML pages, using native scrollbars in XUL widgets (combo boxes), taking a window 3 seconds to open, losing bookmark names when copy & pasting, etc.) and if Mozilla would get fast enough to actually be usable, I'd love to switch. Until then, I'll stick with the #1 browser out there.
Opera has a lot of potential too and I'm looking forward to their next major release but the current version has too many layout and JavaScript implementation bugs to be usable.
Netscape 4.. There's no point in even mentioning the ways it sucks and is non-standards compliant but for the sake of the argument, let's mention IFRAME's, DOM, 85% of the CSS1 standard missing in the implementation, *horrible* table rendering performance and correctness, form widgets being native and thus not z-orderable, Java VM being barely 1.0.2 compatible with a buggy 1.1 AWT implementation... Like I said.. it sucks in too many ways to even mention.
As I understand DCC, which is used for actual file sharing, is peer-to-peer. It's the directory service part that will work using IRC. In that light, it will not be too heavy weight but you are right about IRC having scalability problems.
BugTraq will still publish MS security bugs/holes - they just cannot cut & paste the MS bulletins directly. Most UNIX bugs will not even HAVE bulletins to copy & paste. This is an absolute non-issue and definitely not news-worthy, unlike many other stories.
Uh, hello? C doesn't have strings. C has char arrays. Here, you can do the same in Java:
char[] myString = new char[40];
This is my point. If you say C strings don't take up as much space, I say: neither does C-like-char-array-strings in Java. Now calculate a hash-code for your C-string. What? Not so convenient anymore? For this reason, if you want convenience and the power of the unicode 16-bit string objects in Java, but the speed ans size of 8-bit char arrays in C, I suggest you roll your own string handler class that works much like strstr, strcpy etc. does in C, except it would be in Java. I bet 10000 people have already done this. I was merely saying that if you need speed and size, you can always do that. There's nothing inheritly big and memory hogging in the Java language itself. It's how you typically use it.
A little comment to my example above: I used char's, which are in fact what String objects are made of; 16-bit unicode chars. For C-like 8 bit chars, you would use "byte"'s...
Before you say "Use JNI, it's the VM not java", let me explain to you why you have your head up your ass.
I'm not saying "use JNI" because then I would be sacrificing portability so YOU take your head out of YOUR ass and stop putting words in my mouth and then giving counter claims to stuff I've never said. Very poor manners!
I'm pretty sure he was refering to API bloat, which you *could* argue is there.. Memory overhead is not really an issue, however, and you can get memory much cheaper than you can get coders to write the same stuff in C so that it would save a couple of megs of ram. Besides, you can optimize very well for size in Java too by not using heavy weight stuff like String objects for everything. If you plan on using a lot of strings, roll your own 8-bit string containers and write a separate handler class for it to minimize overhead for methods in the string container class. Just because you're not programming in assembly doesn't mean you have to - to quote you - have your head up your ass when you make design decisions.
It is a "True OO" language. It's is a "High Level" language. The higher level the language, and the more OO the language, the slower it runs and the more memory it takes up. That's a FACT.
Yes, you are very right there. There doesn't have to be a huge overhead in OO (as opposed to using structs with function pointers for instance) but the way you write an OO app usually means that you have a lot of method calls going on from object to object. If you want to write a very fast and also size optimized Java app, you can do it the same way you would in C. Yes it will be slower. Yes it will eat more RAM. But it will most probably also be fast and small enough, unless you're coding an OS, a game or a web browser.
As an obvious starting point, garbage collection. It's very nice and you can be lazy about keeping track of your objects, but it causes overhead.
Ah, you might think it's obvious and a big overhead, but it's not. First of all, garbage collection happens much more rarely than people think and it doesn't take nearly as long as people often think. In a large application, gc is more efficient than manual malloc & free. Why? Because complex apps have complex object life cycles that you have to track yourself if you have no gc. You might have references to memory from several places in an app with several threads and it's not easy to know when something can be freed. Having a *good* gc implementation do the work for you allows you to focus more on your own code. In many systems, you will find very gc-like structures for stuff like exception handling, with pointers pushed on a stack that is then cleaned up when you leave a method early due to an exception. Gc is much more convenient and not a big overhead at all. By re-using objects, you can also minimize (almost to zero in many cases) how often gc is called. That is, unless you have your head up your ass.
it takes to.long.to.get.to.my.method(half, of, the, time);
Huh? And how is this any different from if you have a pointer to a struct with a pointer to a struct with a pointer to a struct in C? If you feel like it, you can have everything declared global and even write code outside of methods. Yes, you actually can do that in Java even though most people don't know it:
public class TryMe {
static {
System.out.println("i am not in a method");
}
public static void main(String[] args) {
System.out.println("i am in main()");
}
}
And of course in a properly designed app you don't HAVE to type long stuff like that because the complexity is hidden in the objects. All that point shows, Taco, is that you can't code object oriented languages properly. Read up on your design patterns...
and then there's the fact that when Java was new and exciting I wrote a video game in it, only to have Sun cease-and-desist me for calling it "Java Invaders".
What does that have to do with Java? That has to do with *SUN*.
(oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here to, even tho that is definitely fair use).
And again.. SUN - not Java.
Other then that, my only problem with Java is that the VM in Netscape is crap.
And now Netscape instead of Java.. This is actually a reason many people think Java is inheritly unstable and slow tho so it's a little sad. The company I work for has several large scale sites running Java in business critical functions and have uptimes of months and months. No crashes, no speed issues, no Netscape VM's.
Oh, and their licensing.
J2SE is free for anyone to use. It's source code is downloadable so you can see how everything works. Granted J2EE has a pretty lame licensing scheme, as do J2ME but most "Linux people" don't know what J2EE *IS* and that most of it can be downloaded separately without the lame licenses.
And the fact that its bloated.
Yes, that really is a problem isn't it? A Java 2 SE runtime download is about 5 MB.. That's terrible! Takes 30 seconds on a decent network connection.. and who has hard drive space for that anyway?
And the fact that I don't have enough time to type in all the reasons it irritated me *grin*
I think you don't have any good reasons really. If those were your two cents, I'd be asking for change...
Non-networked? This is hardly the first networked PDA! I IRCed and surfed the net on my trusty Psion 3a back in 1995 and I think just about every PDA since that has had network support. There's even a port of Opera for the current Psion models that should also run on the upcoming Epoc PDA/phones such as the Nokia 9210 that uses Epoc Crystal as it's OS. Windows CE's, now known as Pocket PC's have just about every network tool imaginable available for them, including a pretty good web browser, email apps etc.
I just installed the Palm Mobile Internet Kit on my Palm IIIx today and I've run pdqSuite on it forever, surfed the net and read my email with Eudora while driving home from work.
Compaq iPaqs also run a port of Linux if memory serves, so it's not a first in that arena either.
While definitely cool, I'm not totally convinced that Linux is the right OS for a PDA tho. A modern OS like Epoc that is designed specifically for small devices seems like a much better choice and the SDK's are pretty good. (http://www.symbian.com/)
There's a lot of backing for Epoc from Ericsson and Nokia - and Psion, obviously and Palm OS is also looking strong with just about every PDA & phone maker from Nokia to Sony coming out with models running it in the near future. The common denominator on all of these seems to be that they all run Java. The next version of the ARM cpu runs Java bytecode, Siemens, Nokia and Motorola have announced that they will support Java in their phones and virtual machines already exist for Windows CE and Linux.. The future will definitely be interesting in the PDA arena. It shouldn't be as black and white as the consumer PC market with Microsoft having 90% of the marketshare.
Hotspot works by JITting only parts of the code - the parts that get run a lot (hotspots) - and tuning & optimizing these for speed. For the rest of the code, it's an interpreter. Because of this, startup time is low (no need to JIT the entire Swing toolkit, XML parser, CORBA, etc. etc. when you start up a complex app that uses all of these) and execution speed is typically at least as good as for a JIT.
If you think Intel is going down, why don't you short some Intel stock? There are billions to be made and for shorting stock, you don't even need money! Coming to think of it, you'd think a lot of Slashdot readers should be shorting Microsoft stock. Talk about an opportunity to make money there!!
That is.. if you truly believe they are going down. Kinda makes you wonder...
Funny thing how nobody here mentions that it runs Java. In my opinion, that's one of most important features on this. It's no Java 2 ME either, with KVM that has such a crappy GUI toolkit it's hardly worth mentioning. No sir, it's a full Personal Java implementation and there's a good SDK for it, downloadable at www.symbian.com, where you can also get the C++ SDK for the Epoc OS. Now before anyone says "write once, debug everywhere", I can tell you that I've actually coded Java apps that were run on the Epoc OS (a Psion 5mx device) and I could code everything from scratch on my desktop and just move the code to the Psion and everything worked right away, without *any* changes to the code - no problems what so ever.
Now thing about what you can do.. RMI to do distributed & mobile apps (remote control your sauna, VCR & whatnot), JDBC to databases, games.
The real strength here is that they have good free SDK's for it so there will a flood of applications for the phone - and those apps will be compatible with all other Epoc devices, such as those made by Psion and Ericsson and perhaps a little later, by Motorola.
What is happening here is a clear division of the mobile industry into Epoc & Java vs. Windows CE. Don't miss what's going on! This is the next "browser war"!
It doesn't need to run KVM because it comes pre-packaged with a full Personal Java virtual machine that actually has a good AWT implementation, unlike KVM. You can download the Java SDK and the C++ SDK for the Epoc OS at www.symbian.com
What? A DNA test to prove it was her kids? ;)
Not so. You say "you are uniformed and hasty in your conclusions" and then you say stuff like I quoted above. I have extensive experience in large scale web site back end design and have been a lead engineer in several sites that have very heavy loads (such as large dot-coms and large e-commerce sites for more traditional "chimney" companies). I do know what I'm talking about here.
I know quite well that a site might need to pull data from a large number of data sources to build up a page (especially in personalizable portal-type front pages). This doesn't mean that you have to do a large amount of database queries, however. Caching is one crucial strategy if you're going for scalability and speed, for instance. Planning the site and page layout so that you don't need so much data for one page is also crucial. If there is no clear simple way to cache the data you need to produce something more complex then cache the result (yes, the HTML!) and only update the HTML every so often - as needed - based on some flag. Read the flag together with some other data that you must get from the database anyway. This is what I'm talking about.
I'm honestly majorly surprised that the performance test mentioned that the site used a page that required 16 queries. When I saw the performance results, I wasn't so surprised they were so poor. I'd like to see the source code for that page..
Perhaps the database was well designed from a data modelling point of view but not from a performance point of view. A good database design for a web site that needs to scale is such that it allows you to cache the data that is used most often. On a web site that gets 30 hits per second but where data only changes about once per 30 seconds, one should start thinking why the data is pulled from the database every single time. User profiles on personalized pages can be cached, data can be pre-fetched with one query, cached and then accessed from the cache when needed instead of doing several queries for a smaller result set etc. etc.. 16 queries is insanity!
I don't agree with that statement. In cases where you need data using 16 different queries, no doubt many of those could have been cached for a huge speedup. I've written code for back ends for several major sites and I've seen very complex funcationality indeed where only a few queries were needed per page - most data was pulled from caches. Also, OO helps you write code where you can fetch data lazily. For instance in a discussion forum, you might keep all root-level messages headers in a cache, the 1000 last accessed bodies in a cache, 10000 last accessed headers in cache, parent-child relationships in cache.. In this way, you don't have to go to the database 16 times every time users come to the front page of the discussion forum and are served the exact same page - 30 times per second.
Like you said, computer time is now significantly cheaper than programmer time. Well, memory is also cheap. Keep stuff in memory and use good old abstract data types to get your data fast.. RDBMS's are very overused these days.