And yes, XML DBMS are a throwback to IBM IMS and other hierarchical DBMS products.
Ah yes, IMS tables. I hated those things with a passion. Every time I saw one of those I sat and wondered "Who the hell came up with THIS idea?!" That being said, XML databases are not quite the same thing, IMS databases pretty much required you to navigate the parent record before descending to the sub record. Not to mention that the flat storage meant that both the parent record and child record must take up the same number of bytes. Sure, separating parent and child into two tables makes sense, but IMS was FASTER. (Makes you want to throttle someone, doesn't it?)
XML databases work on a slightly different principle. For one, there are very few restrictions on the parent/child relationships. You can have as much or as little data at each level as long as it's well formed XML. This is useful for getting rid of many arbitrary SQLDB decisions such as separating customer information (Address, phone numbers, etc.) from the customer record, and allows for things like arbitrary attributes to be attached without changing the schema. In addition, XML databases allow you to query at any level, not just at the parent tag. Thus I can find all customer records where the guy's name starts with "Bob" and he has at least one address on "Drury Lane". You can do the same thing in SQL, but it has various performance considerations, and can result in duplicate records being returned. (Since SQL results do not necessarily conform to an underlying record.)
The "arbitrary XML" part. You must have existing mappings set up to process the XML. New forms of XML thus require a great deal of work on the part of the DB developer.
XML databases such as Xindice OTOH, allow you to create a table and insert XML in whatever format you chose. XPATH queries take a bit of getting used to, but you can query on tags, attributes, CDATA, or whatever else you chose at whatever level in the XML hierarchy you choose. Thus I can query for the list of addresses for all records that have a firstname attribute that is LIKE "Bob". Or I can dive down to the individual address level and query for all records that have an address of "Drury Lane" (important for tracking down the Muffin Man when you need a giant gingerbread cookie).
It's not like you can't do this stuff with SQL databases, it's simply a different method of accomplishing the task. Depending on the data you're working with, an XML database may very well be a more efficient method of storage and queries.
So, it's not slow, it just appears slow? That's a great defense.
I do believe sir, that you are placing words in my mouth. As I recall, my exact words were: "JAVA IS NOT SLOW!" Where this idea that I claimed it "appeared" slow came from is beyond me.
Take gaming out of it, Java apps are still slow, especially ones that use GUIs. Server-side web apps in Java tend to be slow, or at least not noticeable *faster* than other languages. That's, at best, a dead heat, but it's pain to develop in relative to those other languages. And on the GUI app side, people using 2ghz+ computers are still having to defend (rightfully so) that 'Java is just as fast as other stuff' (when it's noticeably not).
You do realize that this is a set of unsubstantiated claims? You have listed no benchmarks other than to say that "Java is slow". Benchmarks showing that Java is just as fast (sometimes faster) than C/C++/C# have been available for quite a while. Would you care to show the benchmarks that show otherwise?
For anyone that bothers to defend Java in this respect with "well, it's the coders' fault! just use API XYZ123!", why on earth does Sun make a language that is SO EASY to make slow stuff in? Why isn't the default way of making Java stuff FAST?
Good point. Why does Microsoft make it so easy for developers to write games in the GDI instead of DirectX? Microsoft should really fix this so that programmers can't use the GDI. From now on, all Windows Desktop programs should be written in DirectX so that they are "fast" as specified by "mgkimsal2".
Or perhaps developers could learn to use the right tool for the right job? I wouldn't write a game for the GDI, so I certainly wouldn't write a game for Swing. I'd write games for DirectX and BufferStrategy APIs, respectively.
MS VB basically defaults to apps that run (and APPEAR to run) quickly. You can work at messing up a VB app to make it run slow, but it's not easy to do.
That's because VB is a RAD tool while Java is not. You have to work at making C/C++ programs run quickly and effectively. Same with Java. Someone could create a VB for Java, but that would effectively kill the whole point of ditching VB for a more powerful language.
I'd be more impressed with Azureus if, after running for some time, it didn't tell me that it has too many open files and start popping up an endless series of dialog boxes telling me so.
That's a new one. Have you let them know about it? They're chucking out versions so fast I swear I have to update every time I open the program.:-)
I'm certainly not. Although one might wonder since I'm arguing with a coward.
Azureus: Redraws slowly when you perform opaque resizes.
Can't really say that I've noticed this. Not that Azureus is the type of application I resize much.
Consumes about 50MB of physical RAM doing nothing.
Nothing? You do realize that Azureus preallocates rather large buffers? That memory isn't going nowhere, it's used to increase performance! Why do you think it downloads faster than the original client? (Actually, early versions would allocate this memory on the fly, but that lead to some memory leakage problems that would eventually require you to restart the program.)
Creates fixed-sized dialogues without concern for viewability of text.
Ok, you've identified a UI issue. Explain to me how this is Java's fault and not the developers'? I've seen many a similar bone-headed mistakes in C programs as well. Or were we just supposed to forget hideous GUIs like GNUTella?
Routinely informs me that I've used it for 90,000+ hours.
Seen that screen once. And I run Azureus fairly often to download multi-gigabyte files. Either way, it's not like it's that annoying, and it certainly has nothing to do with Java.
G2GUI Sancho
Besides the fact that you've again identified problems of the developers as "Java problems", I really have no friggin' idea what these programs are, nor do I care. Pulling out a random bad program does not demonstrate that a platform sucks. Intelligently explaining the underlying problems of the platform (which you have failed to do) does.
Allow me to point out a few very bad C programs:
XEdit: The scrollbar is completely non-intuitive and requires the middle mouse button to scroll It is difficult to understand how the "Search box" functions Ctrl+C, Ctrl+V don't work Filenames have to be typed instead of chosen via a GUI Slow responsiveness Does not resize without an add-on "Window Manager" program GUI flashes on every update
FileMatrix: Uses thousands of highly confusing tabs Text in many areas does not fit in component Confusing use of competing colors Information overload
You can find a whole bunch more C/C++ programs like these on Interface Hall of Shame. I therefore declare that the C language platform is slow and sucks.
Now let's consider IDEA.
How about we take two minutes and consider that IDEA is a developers tool, not an end users program? Visual Studio.NET isn't exactly the smallest and snappiest program either. But both it and IDEA provide a lot of features that DEVELOPERS need. The tradeoff for this power and flexibility is high memory requirements. Since you don't get something for nothing, deal with it.
I can, on a 2.1GHz Thoroughbred B, watch it draw menus, all widgets on resize, paint text when scrolling, and construct dialogues when you load them.
I think you need a new graphics card or something. I run a PIII 733 w/512MB of RAM and a GeForce2 graphics card and I have NEVER seen GUIs that slow. If you can watch things paint on the screen, then there is a serious problem with your graphics card. Either that or your simply a troll who likes to spread FUD.
Plus Microsoft has had a similar "minimise animation" thing since way back in Windows 95. Except nobody ever gushed about how wonderful it was, because it wasn't from Apple.
Microsoft *was* praised for it when Windows 95 came out. The only part they were nailed over was that it didn't always work right. The "animation" would sometime point to the wrong point on the screen, thus confusing the user. The Genie effect builds on this by moving the actual window itself. (Isn't OpenGL great?) Since you can see the actual window at all times, you're less likely to lose track of it.
This is, of course, a huge advantage over having to look at the top of the window, because it's much easier to gauge the depth of a shadow than to notice an OBVIOUS CHANGE OF COLOUR.
The obvious change of color was a hack that people have been indoctrinated to understand. There is nothing intuitive about it. The shadow OTOH, is a natural cue that humans use in everyday life. You don't have to gage the depth of the shadow, because you tend to intuitively understand it. i.e. The window on top *looks* like it's on top.
Sorry, but Java is SLOW. Waiting for a Java program to start up is like listening to paint dry in a thunderstorm.
Ok, should I even *ask* why you are comparing startup time to execution speed? Mozilla and OpenOffice take a long time to load as well, and you don't hear people calling them "slow" do you? NO! People say, "it takes a lot of time to start up". Yeash.
FWIW, Sun has been improving the startup time, just as Mozilla and OOo have been improving theirs. Right now you tend to see about a 10 second startup time for the first Java app, and 2 second startup times for all future apps. Sun has added some code to the upcoming 1.5 VM which should significantly improve this situation.
In my experience, C or C++ is faster across the board, regardless how piss-poor the coder is.
You mean, in your bias C or C++ is faster across the board. From your first paragraph, it seems obvious that you've never used any serious Java apps. OTOH, it may very well be the result of a new syndrome that's been forming. People don't know they're using Java! A perfect example of this is the #1 BitTorrent app, Azureus. It looks and works so good that no one questions what is under the hood!
I might be in a minority but how many people don't maximize the application that they're working in?
It has an interface much like Mac OS X (except a little more 3Dish). Under OS X, you get used to not maximizing windows. Maximizing does unpredictable things, or just gets in the way when it doesn't.
the application that they're working in? Also, I avoid my mouse as much as possible and LG looks pretty mouse intensive.
That's very difficult to determine without trying it. OS X is pretty mouse intensive, but has hotkeys for most stuff. Granted, many of the OS X ones are rather masochistic combinations of "Apple" and "Option" keys, but it doesn't have to be that way.
The original poster was correct. Java's main use back in the 1.0 and 1.1 days was webpage Applets. Microsoft took a two pronged approach to this threat:
1. Microsoft released J++ as a "better" Java. (It actually was at the time. Took me quite a while before I switched back to Sun's JVM.)
2. Microsoft came up with a new type of embeddable COM object known as "ActiveX". Microsoft was trying to outdo Java by offering the full power of the Windows platform inside webpages. Somehow we were all supposed to be happy that we could write these object in C/C++, and that they could take over your system at a whim.
It wasn't until after a judge told Microsoft that they couldn't ship Java, that Microsoft started their "COOL" project. The "COOL" project was widely considered a Bad Idea (TM) (much like digital watches) and was widely derided as a adolescent move by Microsoft. Sadly, Microsoft foisted its COOL platform on the world anyway, and now we have.NET.
- reading vertical text on side of windows is uncomfortable.
It seems to work for books just fine. Most people are quite adapted to handling vertical text when they're quickly looking for something.
- how is spinning a window around to look at properties better than opening up a separate properties dialog???
For one, it provides a "link" between the action and the result. A common problem in windowing systems is that users perform an action, then have difficulty understanding the response. Anything you can do to eliminate the "magic" of desktop items and make them more like real world objects will be of help to the user.
In addition, the window flip provides a much more natural "mode" than a properties box. Many properties boxes attempt to make up for a lack of modal nature by locking out the underlying application and forcing the properties box on top. This leads to confusion on the part of the user as their application appears to have locked up. Things get particularly bad when popup boxes somehow get hidden in the OS. (e.g. obscured by another window or somehow behind the parent window)
- java?
Why not? Back in the day, OSes were written in ALGOL, Fortran, LISP, and just about everything else. Generally, this would link the OS to its language for a complete development environment. It wasn't until Unix became popular, that C became "standard". It was actually a very poor choice for a language, but the computers of the day really cried out for the performance benefits.
- i would be suprised if human factors has been involved in project to this point.
It strikes me that they already have been involved.
If/when this comes to market, it will look and behave much different than shown.
Who has shown it? In fact, name one company that has succeeded in creating a usable 3D desktop? You probably can't, because all the other implementations are too far out to left field. Sun took the approach of incremental change and appears to have succeeded.
But how many apps/desktop environments *really* follow the newly born standards!?!?
Every version of GNOME that Sun has released has followed the standards. Talk to RedHat about releasing crap like RedHat 8.0 which "invent" things to replace incomplete implementations of the standards. There's nothing more frustrating than building an installer than works fine on Solaris/GNOME, but deletes all the system level icons from the "Hat" menu on RedHat/GNOME. That's right folks, in RedHat 8, you could have user specific icons, or you could have system-wide icons. Apparently RedHat didn't think you'd want both.
I know Mr. AC is trying to be funny, but this crap really pisses me off. For one, JAVA IS NOT SLOW. It gained that reputation back when it lacked a JIT compiler. Sun corrected that problem pretty fast, but the idea just won't go away. Granted, some of the APIs are such that they can appear to be quite slow to those who don't know what the hell they're doing. I'm always hearing from people who say "My game only runs at 10 FPS! Whaa! Java Sucks!" To which I usually reply "Are you using BufferStrategy, the core of the 2D gaming API?" The Deer-in-the-Headlights looks on their faces are priceless. To which they then mumble something about thinking Swing was somehow the way to write games.
Secondly, the Looking Glass project uses OpenGL. I don't care what language you're using, OpenGL performance is limited by the video card and bus, not by the CPU. If your 3D apps are slow, it's because you don't know what the f*** you're doing. That goes for C, C++, Python, Ruby, and yes: JAVA.
Looks pretty, but wont computers at this level be more concerned with process cycles than spending time on a fancy GUI?
I don't know why everyone thinks this will be a problem. All of the 3D work will be pushed down to the 3D card. (This is what Mac OS X does to obtain its "Genie" and other effects.) As long as you have a GeForce2 or better, you should be fine.
On the subject of GPL, I'm not sure I understand why Sun would Open Source this. On the consumer market, it really is a deal-making product for them. The only thing I can see is that they don't have the resources to develop this fast enough and want to leverage the Open Source community. Given that this approach has worked for OpenOffice and Netbeans, it may not be such a bad move by Sun.
Perhaps for you. I run VLC on Windows 2000 and it's far more stable than Windows Media Player. Not to mention that Windows Media Player is always choking on some file or another, while VLC plays them without complaint. Granted, VLC wouldn't be needed if the people doing the encodings knew how to NOT corrupt the file six ways to Sunday.
For example, I downloaded a little video called "TOS vs. TNG: The Final Battle". While it was a mildly amusing home-brew video, Windows Media Player choked about 80% through the file. If I fast forwarded past the point of the error, I'd get video but no sound. When I loaded it in VLC, it was able to play it through without error.
Re:Plenty of colors for the dirty deed.
on
Reverse Graffiti
·
· Score: 1
The difference between a "legitimate" billboard and someone marking their pissing grounds is mostly the means available. In this case, the advertiser is being cheap and hoping to gain some kind of hoodlum credibility.
While I understand your feelings on this issue, I was primarily referring to buildings which pay graffiti artists to create a mural on one of their side walls. Many of these show a lot of artistic talent, but I still can't come to grips with it. I *want* to like these seemingly pretty pictures, but in my gut I somewhat feel that it's like mixing water and oil. i.e. Places of business are simply the wrong forum for this type of expression.
Maybe it's just me. People are paying for these services, so obviously *someone* likes them. I just can't shake that feeling that it somehow has a detrimental effect. *shrug* Perhaps it's merely indoctrination about graffiti being "bad".
(No offense to the artists themselves. You people have done some amazing work irrespective of its location.)
Re:"Clean Me" on the back of cars
on
Reverse Graffiti
·
· Score: 1, Funny
People really shouldn't be doing that anyway because it's very possible to scratch the finish on the car and do actual damage. Sure, it's not as bad as keying it, but it's still uncalled for.
Running your finger along a dirty window is going to scratch the finish? A little skin oil perhaps, but scratches? On what finish? The Mr. Clean Window Wax?
That sounds like a really smart idea. The only problem I can see is that you're limited in choice of color. Many "professional" graffiti artists like to create very colorful works that help "brighten" the area. I still haven't figured out if I *like* professional graffiti, or if it even helps improve the area, but new options for those who do like it are always welcome.
It's often difficult to find time sensitive information that doesn't quite make it into the annals of history, but I did find the original Newswire on Usenet. While there's not much left on it anymore, it was generally considered to be true at the time. (Especially since that's exactly the type of prank McNealy would pull.)
I'm still not sure that I want web apps to completely take over the role of most desktop apps. Messing around with a display-document structure is a complex and processor intensive procedure. Suddenly you need the PC equivalent of a super computer just to run your Word Processor.
Of course, that doesn't mean that I'm against the core idea of document based programming and rendering engines. In many ways, user interfaces are merely an interactive document. Technologies such as XUL and XAWT promise to bring faster development time, network-centric deployment options, and more modular designs. I'm just not sure of who's going to break down the final barriers first.
I myself spent some time on a project called "Appliweb" which attempted to solve this problem via a combination of XML and Java. Since both are portable across nearly all platforms, it had the potential to break down some of the final barriers. The problem, however, was that the Java GUI libraries simply weren't designed to do what I was trying to do with them. GUIs could be created in an editor quite easily, but complex documents always had "quirks" that would have to be directly adjusted in the XML. It would seem that someone would need to write an entire GUI interface based on proper bean patterns and document structure. To date, I haven't noted anyone who's completely succeeded.
I believe that was Windows 2000. It was a big deal because Microsoft was attempting to parade how stable and "Unix-like" Windows 2000 was. Allegedly. Scott McNeally responded by paying a bunch of bug exterminators to drive around a conference center where Microsoft was making some of its announcements about Windows 2000. Supposedly, the exterminators bugged out when it dawned on them why they had been payed to drive around.
Slashdot Mirror
And yes, XML DBMS are a throwback to IBM IMS and other hierarchical DBMS products.
Ah yes, IMS tables. I hated those things with a passion. Every time I saw one of those I sat and wondered "Who the hell came up with THIS idea?!" That being said, XML databases are not quite the same thing, IMS databases pretty much required you to navigate the parent record before descending to the sub record. Not to mention that the flat storage meant that both the parent record and child record must take up the same number of bytes. Sure, separating parent and child into two tables makes sense, but IMS was FASTER. (Makes you want to throttle someone, doesn't it?)
XML databases work on a slightly different principle. For one, there are very few restrictions on the parent/child relationships. You can have as much or as little data at each level as long as it's well formed XML. This is useful for getting rid of many arbitrary SQLDB decisions such as separating customer information (Address, phone numbers, etc.) from the customer record, and allows for things like arbitrary attributes to be attached without changing the schema. In addition, XML databases allow you to query at any level, not just at the parent tag. Thus I can find all customer records where the guy's name starts with "Bob" and he has at least one address on "Drury Lane". You can do the same thing in SQL, but it has various performance considerations, and can result in duplicate records being returned. (Since SQL results do not necessarily conform to an underlying record.)
Whats so hard?
The "arbitrary XML" part. You must have existing mappings set up to process the XML. New forms of XML thus require a great deal of work on the part of the DB developer.
XML databases such as Xindice OTOH, allow you to create a table and insert XML in whatever format you chose. XPATH queries take a bit of getting used to, but you can query on tags, attributes, CDATA, or whatever else you chose at whatever level in the XML hierarchy you choose. Thus I can query for the list of addresses for all records that have a firstname attribute that is LIKE "Bob". Or I can dive down to the individual address level and query for all records that have an address of "Drury Lane" (important for tracking down the Muffin Man when you need a giant gingerbread cookie).
It's not like you can't do this stuff with SQL databases, it's simply a different method of accomplishing the task. Depending on the data you're working with, an XML database may very well be a more efficient method of storage and queries.
So, it's not slow, it just appears slow? That's a great defense.
I do believe sir, that you are placing words in my mouth. As I recall, my exact words were: "JAVA IS NOT SLOW!" Where this idea that I claimed it "appeared" slow came from is beyond me.
Take gaming out of it, Java apps are still slow, especially ones that use GUIs. Server-side web apps in Java tend to be slow, or at least not noticeable *faster* than other languages. That's, at best, a dead heat, but it's pain to develop in relative to those other languages. And on the GUI app side, people using 2ghz+ computers are still having to defend (rightfully so) that 'Java is just as fast as other stuff' (when it's noticeably not).
You do realize that this is a set of unsubstantiated claims? You have listed no benchmarks other than to say that "Java is slow". Benchmarks showing that Java is just as fast (sometimes faster) than C/C++/C# have been available for quite a while. Would you care to show the benchmarks that show otherwise?
For anyone that bothers to defend Java in this respect with "well, it's the coders' fault! just use API XYZ123!", why on earth does Sun make a language that is SO EASY to make slow stuff in? Why isn't the default way of making Java stuff FAST?
Good point. Why does Microsoft make it so easy for developers to write games in the GDI instead of DirectX? Microsoft should really fix this so that programmers can't use the GDI. From now on, all Windows Desktop programs should be written in DirectX so that they are "fast" as specified by "mgkimsal2".
Or perhaps developers could learn to use the right tool for the right job? I wouldn't write a game for the GDI, so I certainly wouldn't write a game for Swing. I'd write games for DirectX and BufferStrategy APIs, respectively.
MS VB basically defaults to apps that run (and APPEAR to run) quickly. You can work at messing up a VB app to make it run slow, but it's not easy to do.
That's because VB is a RAD tool while Java is not. You have to work at making C/C++ programs run quickly and effectively. Same with Java. Someone could create a VB for Java, but that would effectively kill the whole point of ditching VB for a more powerful language.
I'd be more impressed with Azureus if, after running for some time, it didn't tell me that it has too many open files and start popping up an endless series of dialog boxes telling me so.
:-)
That's a new one. Have you let them know about it? They're chucking out versions so fast I swear I have to update every time I open the program.
Are you on crack?
I'm certainly not. Although one might wonder since I'm arguing with a coward.
Azureus:
Redraws slowly when you perform opaque resizes.
Can't really say that I've noticed this. Not that Azureus is the type of application I resize much.
Consumes about 50MB of physical RAM doing nothing.
Nothing? You do realize that Azureus preallocates rather large buffers? That memory isn't going nowhere, it's used to increase performance! Why do you think it downloads faster than the original client? (Actually, early versions would allocate this memory on the fly, but that lead to some memory leakage problems that would eventually require you to restart the program.)
Creates fixed-sized dialogues without concern for viewability of text.
Ok, you've identified a UI issue. Explain to me how this is Java's fault and not the developers'? I've seen many a similar bone-headed mistakes in C programs as well. Or were we just supposed to forget hideous GUIs like GNUTella?
Routinely informs me that I've used it for 90,000+ hours.
Seen that screen once. And I run Azureus fairly often to download multi-gigabyte files. Either way, it's not like it's that annoying, and it certainly has nothing to do with Java.
G2GUI
Sancho
Besides the fact that you've again identified problems of the developers as "Java problems", I really have no friggin' idea what these programs are, nor do I care. Pulling out a random bad program does not demonstrate that a platform sucks. Intelligently explaining the underlying problems of the platform (which you have failed to do) does.
Allow me to point out a few very bad C programs:
XEdit:
The scrollbar is completely non-intuitive and requires the middle mouse button to scroll
It is difficult to understand how the "Search box" functions
Ctrl+C, Ctrl+V don't work
Filenames have to be typed instead of chosen via a GUI
Slow responsiveness
Does not resize without an add-on "Window Manager" program
GUI flashes on every update
FileMatrix:
Uses thousands of highly confusing tabs
Text in many areas does not fit in component
Confusing use of competing colors
Information overload
You can find a whole bunch more C/C++ programs like these on Interface Hall of Shame. I therefore declare that the C language platform is slow and sucks.
Now let's consider IDEA.
How about we take two minutes and consider that IDEA is a developers tool, not an end users program? Visual Studio.NET isn't exactly the smallest and snappiest program either. But both it and IDEA provide a lot of features that DEVELOPERS need. The tradeoff for this power and flexibility is high memory requirements. Since you don't get something for nothing, deal with it.
I can, on a 2.1GHz Thoroughbred B, watch it draw menus, all widgets on resize, paint text when scrolling, and construct dialogues when you load them.
I think you need a new graphics card or something. I run a PIII 733 w/512MB of RAM and a GeForce2 graphics card and I have NEVER seen GUIs that slow. If you can watch things paint on the screen, then there is a serious problem with your graphics card. Either that or your simply a troll who likes to spread FUD.
HAND.
fuck you! it is slow, every time i go to a web site that has some kinda java deally on it it takes for ever compared to website without them
Perfect example of an idiot with his mind stuck in 1998. Sad, really.
Plus Microsoft has had a similar "minimise animation" thing since way back in Windows 95. Except nobody ever gushed about how wonderful it was, because it wasn't from Apple.
Microsoft *was* praised for it when Windows 95 came out. The only part they were nailed over was that it didn't always work right. The "animation" would sometime point to the wrong point on the screen, thus confusing the user. The Genie effect builds on this by moving the actual window itself. (Isn't OpenGL great?) Since you can see the actual window at all times, you're less likely to lose track of it.
This is, of course, a huge advantage over having to look at the top of the window, because it's much easier to gauge the depth of a shadow than to notice an OBVIOUS CHANGE OF COLOUR.
The obvious change of color was a hack that people have been indoctrinated to understand. There is nothing intuitive about it. The shadow OTOH, is a natural cue that humans use in everyday life. You don't have to gage the depth of the shadow, because you tend to intuitively understand it. i.e. The window on top *looks* like it's on top.
Sorry, but Java is SLOW. Waiting for a Java program to start up is like listening to paint dry in a thunderstorm.
Ok, should I even *ask* why you are comparing startup time to execution speed? Mozilla and OpenOffice take a long time to load as well, and you don't hear people calling them "slow" do you? NO! People say, "it takes a lot of time to start up". Yeash.
FWIW, Sun has been improving the startup time, just as Mozilla and OOo have been improving theirs. Right now you tend to see about a 10 second startup time for the first Java app, and 2 second startup times for all future apps. Sun has added some code to the upcoming 1.5 VM which should significantly improve this situation.
Uh, have you SEEN Java games that use OpenGL? It's a disgrace. I can't believe people like you bother to defend it.
I have, but apparently you haven't. Let me introduce you:
Wurm Online
Cosmic Trip
Alien Flux
In my experience, C or C++ is faster across the board, regardless how piss-poor the coder is.
You mean, in your bias C or C++ is faster across the board. From your first paragraph, it seems obvious that you've never used any serious Java apps. OTOH, it may very well be the result of a new syndrome that's been forming. People don't know they're using Java! A perfect example of this is the #1 BitTorrent app, Azureus. It looks and works so good that no one questions what is under the hood!
I might be in a minority but how many people don't maximize the application that they're working in?
It has an interface much like Mac OS X (except a little more 3Dish). Under OS X, you get used to not maximizing windows. Maximizing does unpredictable things, or just gets in the way when it doesn't.
the application that they're working in? Also, I avoid my mouse as much as possible and LG looks pretty mouse intensive.
That's very difficult to determine without trying it. OS X is pretty mouse intensive, but has hotkeys for most stuff. Granted, many of the OS X ones are rather masochistic combinations of "Apple" and "Option" keys, but it doesn't have to be that way.
The original poster was correct. Java's main use back in the 1.0 and 1.1 days was webpage Applets. Microsoft took a two pronged approach to this threat:
.NET.
1. Microsoft released J++ as a "better" Java. (It actually was at the time. Took me quite a while before I switched back to Sun's JVM.)
2. Microsoft came up with a new type of embeddable COM object known as "ActiveX". Microsoft was trying to outdo Java by offering the full power of the Windows platform inside webpages. Somehow we were all supposed to be happy that we could write these object in C/C++, and that they could take over your system at a whim.
It wasn't until after a judge told Microsoft that they couldn't ship Java, that Microsoft started their "COOL" project. The "COOL" project was widely considered a Bad Idea (TM) (much like digital watches) and was widely derided as a adolescent move by Microsoft. Sadly, Microsoft foisted its COOL platform on the world anyway, and now we have
- reading vertical text on side of windows is uncomfortable.
It seems to work for books just fine. Most people are quite adapted to handling vertical text when they're quickly looking for something.
- how is spinning a window around to look at properties better than opening up a separate properties dialog???
For one, it provides a "link" between the action and the result. A common problem in windowing systems is that users perform an action, then have difficulty understanding the response. Anything you can do to eliminate the "magic" of desktop items and make them more like real world objects will be of help to the user.
In addition, the window flip provides a much more natural "mode" than a properties box. Many properties boxes attempt to make up for a lack of modal nature by locking out the underlying application and forcing the properties box on top. This leads to confusion on the part of the user as their application appears to have locked up. Things get particularly bad when popup boxes somehow get hidden in the OS. (e.g. obscured by another window or somehow behind the parent window)
- java?
Why not? Back in the day, OSes were written in ALGOL, Fortran, LISP, and just about everything else. Generally, this would link the OS to its language for a complete development environment. It wasn't until Unix became popular, that C became "standard". It was actually a very poor choice for a language, but the computers of the day really cried out for the performance benefits.
- i would be suprised if human factors has been involved in project to this point.
It strikes me that they already have been involved.
If/when this comes to market, it will look and behave much different than shown.
Who has shown it? In fact, name one company that has succeeded in creating a usable 3D desktop? You probably can't, because all the other implementations are too far out to left field. Sun took the approach of incremental change and appears to have succeeded.
But how many apps/desktop environments *really* follow the newly born standards!?!?
Every version of GNOME that Sun has released has followed the standards. Talk to RedHat about releasing crap like RedHat 8.0 which "invent" things to replace incomplete implementations of the standards. There's nothing more frustrating than building an installer than works fine on Solaris/GNOME, but deletes all the system level icons from the "Hat" menu on RedHat/GNOME. That's right folks, in RedHat 8, you could have user specific icons, or you could have system-wide icons. Apparently RedHat didn't think you'd want both.
I know Mr. AC is trying to be funny, but this crap really pisses me off. For one, JAVA IS NOT SLOW. It gained that reputation back when it lacked a JIT compiler. Sun corrected that problem pretty fast, but the idea just won't go away. Granted, some of the APIs are such that they can appear to be quite slow to those who don't know what the hell they're doing. I'm always hearing from people who say "My game only runs at 10 FPS! Whaa! Java Sucks!" To which I usually reply "Are you using BufferStrategy, the core of the 2D gaming API?" The Deer-in-the-Headlights looks on their faces are priceless. To which they then mumble something about thinking Swing was somehow the way to write games.
Secondly, the Looking Glass project uses OpenGL. I don't care what language you're using, OpenGL performance is limited by the video card and bus, not by the CPU. If your 3D apps are slow, it's because you don't know what the f*** you're doing. That goes for C, C++, Python, Ruby, and yes: JAVA.
Looks pretty, but wont computers at this level be more concerned with process cycles than spending time on a fancy GUI?
I don't know why everyone thinks this will be a problem. All of the 3D work will be pushed down to the 3D card. (This is what Mac OS X does to obtain its "Genie" and other effects.) As long as you have a GeForce2 or better, you should be fine.
On the subject of GPL, I'm not sure I understand why Sun would Open Source this. On the consumer market, it really is a deal-making product for them. The only thing I can see is that they don't have the resources to develop this fast enough and want to leverage the Open Source community. Given that this approach has worked for OpenOffice and Netbeans, it may not be such a bad move by Sun.
Am I the only one who sees a bunch of garbage on that page? I certainly don't see anything related to a media player.
vlc is crash-prone -- at least on Windows.
Perhaps for you. I run VLC on Windows 2000 and it's far more stable than Windows Media Player. Not to mention that Windows Media Player is always choking on some file or another, while VLC plays them without complaint. Granted, VLC wouldn't be needed if the people doing the encodings knew how to NOT corrupt the file six ways to Sunday.
For example, I downloaded a little video called "TOS vs. TNG: The Final Battle". While it was a mildly amusing home-brew video, Windows Media Player choked about 80% through the file. If I fast forwarded past the point of the error, I'd get video but no sound. When I loaded it in VLC, it was able to play it through without error.
The difference between a "legitimate" billboard and someone marking their pissing grounds is mostly the means available. In this case, the advertiser is being cheap and hoping to gain some kind of hoodlum credibility.
While I understand your feelings on this issue, I was primarily referring to buildings which pay graffiti artists to create a mural on one of their side walls. Many of these show a lot of artistic talent, but I still can't come to grips with it. I *want* to like these seemingly pretty pictures, but in my gut I somewhat feel that it's like mixing water and oil. i.e. Places of business are simply the wrong forum for this type of expression.
Maybe it's just me. People are paying for these services, so obviously *someone* likes them. I just can't shake that feeling that it somehow has a detrimental effect. *shrug* Perhaps it's merely indoctrination about graffiti being "bad".
(No offense to the artists themselves. You people have done some amazing work irrespective of its location.)
People really shouldn't be doing that anyway because it's very possible to scratch the finish on the car and do actual damage. Sure, it's not as bad as keying it, but it's still uncalled for.
Running your finger along a dirty window is going to scratch the finish? A little skin oil perhaps, but scratches? On what finish? The Mr. Clean Window Wax?
That sounds like a really smart idea. The only problem I can see is that you're limited in choice of color. Many "professional" graffiti artists like to create very colorful works that help "brighten" the area. I still haven't figured out if I *like* professional graffiti, or if it even helps improve the area, but new options for those who do like it are always welcome.
It's often difficult to find time sensitive information that doesn't quite make it into the annals of history, but I did find the original Newswire on Usenet. While there's not much left on it anymore, it was generally considered to be true at the time. (Especially since that's exactly the type of prank McNealy would pull.)
But for Linux, it is harder for an average user to "give birth" and "raise" a Linux system, even though it never gget sick.
That's why we need the pain meds for Linux. Just catch a needle in the spine and you'll never remember what happened after that.
I'm still not sure that I want web apps to completely take over the role of most desktop apps. Messing around with a display-document structure is a complex and processor intensive procedure. Suddenly you need the PC equivalent of a super computer just to run your Word Processor.
Of course, that doesn't mean that I'm against the core idea of document based programming and rendering engines. In many ways, user interfaces are merely an interactive document. Technologies such as XUL and XAWT promise to bring faster development time, network-centric deployment options, and more modular designs. I'm just not sure of who's going to break down the final barriers first.
I myself spent some time on a project called "Appliweb" which attempted to solve this problem via a combination of XML and Java. Since both are portable across nearly all platforms, it had the potential to break down some of the final barriers. The problem, however, was that the Java GUI libraries simply weren't designed to do what I was trying to do with them. GUIs could be created in an editor quite easily, but complex documents always had "quirks" that would have to be directly adjusted in the XML. It would seem that someone would need to write an entire GUI interface based on proper bean patterns and document structure. To date, I haven't noted anyone who's completely succeeded.
The software can be downloaded on the SimIndiana site, but requires Windows, and registration on the site, to use it.
See? They should have written it in Java.
NT 4 shipped with 65K defects?
I believe that was Windows 2000. It was a big deal because Microsoft was attempting to parade how stable and "Unix-like" Windows 2000 was. Allegedly. Scott McNeally responded by paying a bunch of bug exterminators to drive around a conference center where Microsoft was making some of its announcements about Windows 2000. Supposedly, the exterminators bugged out when it dawned on them why they had been payed to drive around.