While that is true, informing the JavaRacnh people of that would have been helpful in explaining to them why this was unfortunate but necessary.
Now it just looks like a lawyer got out of control. Sending cease and desist letters to friendly supporters is not a smart thing to do (ok, it's an extremely stupid thing to do and the responsible marketing/legal drone should be kicked out for incompetence and doing major damage to the Java/Sun brand).
This will find its way to the press and it will result in lots of bad publicity for SUN. In other words its already costing them and it will even cost them more in the near future.
Sun needs to get it's marketing department in better shape, there've been several major fuckups lately: - this ugly incident - the convenient get Java thingy on sun.com and java.sun.com still points to jre 1.3.1 rather than jre1.4.0 even though it's been out for weeks, has better/more features, etc. - Days after launching jre 1.4.0 a feature/marketing article on sun.com informs us of how great 1.3.1 is, never even mentioning 1.4.0. - Java webstart is launched without any compelling webstart applications.
I mean what company invests millions in developing a product and then starts marketing the old product?? That is just nuts. It's been pointed out to them by among others me on several occasions. But they just don't get it.
Small correction, in windows the low level video driver runs in kernel mode (mostly for performance reasons). The rest lives in user land just as in UNIX. When under unix your xserver barfs you lose your data just like when the similar thing happens in windows. In windows you reboot, the user friendly but slow and annoying way of reinitializing properly, in linux you are left to fix things manually (and usually you can).
As someone else pointed out, most of the GUI in window is explorer.exe. You can kill it and it will just relaunch itself. Usually it will forget about any taskbar icons (though the associated processes still run). Luckily it crashes very rarely these days and if it does a simple logout, login fixes it properly (similar to restarting X). All the cases I had to reboot my XP machine were related to driver issues. Both my video card and audiocard come from vendors that went bankrupt: 3dfx and aureal. Consequently the XP drivers are a bit flaky you can compare that to running unsupported x drivers and kernel modules on linux.
If under linux your X driver fucks up the screen, just shutting it down may not always fix it either since the hardware only resets properly at boot time. If that happens (and I've seen it happen under linux), you are left no choice but to reboot. What good is it if you can still telnet to the box if you were busy playing unreal?. Poor hardware support is much more of an issue under linux than it is under windows.
Either way whether X crashes (and it does) or explorer.exe crashes it is usually the end of all your running apps. You may lose unsaved data and you'll need to restart the apps. It's a pain either way and in my experience both systems are plagued by it. If I run nothing but dos boxes and wordpad in XP I can probably keep it running for months or even years but that's not why I have a PC. I like to push the drivers to the limit by running 3D games and other potentially not so stable stuff. I'm pretty sure I'll experience the occasional X crash and hw lockups under linux too given the same usage pattern.
Finally I doubt the GUI is the main issue bothering windows based servers. Probably the issue is more related to memory leaks and such in IIS. A stripped linux distro with apache is notoriously stable, nobody is denying that. But that's because apache is a good product and IIS is not. Anyway we're comparing apples and oranges now since we were discussing the minor annoyance of the desktop environment crashing which is a reality users have to live with on both linux and windows.
Nothing in the linux architecture prevents the problems that have plagued windows. So it is not surprising that when linux desktops were much less feature rich they were generally more faster and bugfree. With less LOC and a similar amount of defects/KLOC you get less bugs, it has nothing to do with code quality.
With both KDE and Gnome growing in size there are more bugs to squash, more design issues to work out. Linux does not have a 16 bit dos legacy so it does not have to face BSOD's however also the more UNIX like kernel design gives you some stability.
However, memory bloat, usability bugs and stupid design are not unique to the win32 environment and are generally very portable. It is very easy to make the same mistakes when programming a KDE application as it is to do when programming an win32 application.
For the past few years, a fully featured linux desktop (i.e. not twm or some other lightweight wm) has been typically slower than a fully featured win32 desktop on my machine. Windows XP typically boots faster than it takes me to get a KDE 2.x desktop up an running from pressing the power button.
I've had several versions of Mandrake on my machine over the past few years. I found them to be buggy and unreliable (reminding me of the days I ran win95). I've experienced segfaults of the installer, corrupted rpm databases (mostly because of rpm drake crashing) and other very significant show stopper bugs on what Mandrake considered release worhty. In case you are wondering, I have an off the shelf Dell machine. Life isn't exactly wonderfull on win32 but a win2k machine feels a lot more mature and stable than a Mandrake machine.
If I want a stable linux environment I generally do not install Mandrake but Debian. However "user friendly" is not a well understood concept in the Debian world and nothing is straightforward in Debian (though given enough time you can figure it out). However, I'm comfortable with a commandline and know how to work my way through the piles of howto's, newsgroup messages and such to get a working KDE 2.2.2 installation running ontop of XFree 4.2, with sound support and a working DSL connection (none of which is easy if you start out with a potato cd and an obscure isa network card). I even enjoy doing so but I wouldn't recommend Mandrake or Debian to windows users. Well I actually did recommend Mandrake to a windows user a few months back and of course the installer blew up in his face (segfaulting halfway). He gave up on it after that.
In order to do something (anything) with structured text stored in ascii one has to parse it. If the structured information is somehow more than the syntactical structure parsed by your parser, you lose that information when you save (because your parser does not know how to parse it).
This is the main reason why there's a reverse engineering option in many case tools. You have a nice diagram, you generate code (ascii!!!), all the nice info you had in the diagram is lost because it is not part of the syntax of your programming language and after you change the generated code you have an outdated diagram and source code that simply does not contain all the necessary information to reverse engineer it (e.g. any constraints you defined in rose). Why throw away all this information? Because developers want emacs/vi/whatever to edit their code! Don't get me wrong, emacs is a wonderful text editor, so is vi. But they are text editors, not structured information editors. They don't enforce syntactical correctness, they don't allow for new syntactical concepts, they don't store meta information, etc.
That's why in addition to ascii, advanced development tools like rational rose, visual age, togetherJ, intelliJ, netbeans, etc have some sort of internal program database while running. Visual Age doesn't even bother to generate ascii anymore and uses the internal DB for storage and on the fly compilation.
The advantage of this is that you never really lose the design information (unless you export to ascii) and as long as you stay within the tool your fine. That's also why it's easy to implement stuff like refactoring (essentially refactoring is a transformation of the structured data) since you already have a queryable structure. Of course these tools save their data in some format (maybe even ascii), however the data these tools store contains all the relevant data these tools generate so nothing is lost. Netbeans for instance uses program comments to specify non editable parts of code generated by the gui builder and Visual age uses some binary format.
We can do that for them. Just share it with your gnutella client and gnutella will do the rest. Just make sure that you have a client that supports some of the interesting new features (super peer, distributed downloads). Limewire does it all. If enough people share their isos, there'll be plenty of bandwidth
Some of the better pieces on program/project metrics include extensive case studies on multiple representative cases. The other ones usually aren't worth reading.
Yours doesn't include any evidence whatsoever, just fictional examples that merely highlight how little you know about the subject. There's a lot of myths and misconceptions and myths about good programming practices and lots of people that spread them.
Your estimate of productivity of 1 programmer per day ("5000 lines of code") is way off. Multiple, very good case studies have shown this to be between 1 - 10 LOC/day on large projects including all development phases. Unlike junior programmers, experienced software engineers typically agree with this number (I've heard several claim it was actually closer to 1 LOC than 10 LOC in their organization).
I agree with you that LOC is not an ideal productivity measurement given the difference in programming language, programming style, program quality etc. There are many alternatives (e.g. function point analysis). However, LOC is simply the easiest to measure.
In some of the more advanced software developing organizations I've visited (i.e. CMM level 2 and upwards) metrics (of all sorts) are used to steer the process. Consequently, the programmers in those organizations have nine to five jobs because management is able to acurately estimate the workload for a project. Also these companies have coding standards and review processes to enforce those. In addition, they measure defects/kloc so they know how good their code is.
Good programmers get noticed in such environments because of their low defect rates, good quality code and good productivity.
"Why we must buy faster CPU instead of them fixing bugs that causes sluggish performance especially on UI?"
Because CPU's are dirt cheap. The amount of money you need to buy a modern CPU (low end) gives you one, maybe two hours programming time of a junior programmer. A professional programmer earns much more per hour and is good for maybe around 5 to 10 minutes of his/her time. So don't waste his/her time and buy a new CPU with the hardware to insert it into. You can pick up good second hand hardware for a price that is just about the same price of most commercial software packages (if you insist on being a cheap bastard). If it is your hobby to run new software on old hardware that's your problem.
There's no such thing as a standard X application other than applications that only require an X server (almost any X application requires more than just that). That's the whole problem: some applications require kde 1.2 others absolutely need kde 2.x others require neither but need Gnome 1.2 or Gnome 1.4. There's no linux distribution being shipped today that supports all four of these. so any requirement with regards to just these four desktop environments you make already limits the amount of linux distributions you can target with your application. Gnome 2.0 and KDE 3.0 are around the corner and in a year there will be two additional desktop environments to take into account.
It's not that simple and all application vendors are faced with this problem. Most vendors solve it by simply requiring red hat linux to be installed, reliefing them of the need to test with other distributions. Differences between distributions include version differences in among others kernel, compiler, libraries, x windows, desktop environment. Each of these may have version specific bugs that may or may not influence other packages. It's nearly impossible to test for all possible combinations. In addition, all distributions are updated frequently and typically have a lot of changes between versions. It's nearly impossible to keep up with that.
Support also is difficult since there are so many distribution specific problems that may prevent a program from working as intended. Imagine a user calling and asking "I can't load any site with AOL 7 on linux" or a similarly vague question. A good heuristic to approaching such a client would be to figure out whether the network is configured correctly. On windows that is easy since all versions of windows have a control panel with network settings and there are only minor differences between the different versions. On linux each distribution allows multiple ways of configuring the network and there are likely to be significant differences between each distribution and even among different versions of the same distribution. Almost certainly a proper solution to any problems with the configuration will require editing text files and work on the commandline. Not a problem for advanced users but a nightmare for the average AOL helpdesk staff and AOL user.
I think you are missing the point about expert systems. Expert systems are about specifying sets of rules. Clips is a system that provides an engine for interpreting such rules. There's no way you can somehow avoid specifying those rules for your system.
If your problem is simple enough, maybe an expert system is overkill and you can program it with some if statements in a cgi script.
Specifying the rules in an expert system is not that hard at all and certainly won't take you several months. Making the expert system interact with a bunch of cgi scripts shouldn't be that hard either.
A system you might want to look at is JESS (Java Expert System Shell) which is based on CLIPS: http://herzberg.ca.sandia.gov/jess/
"Do you realize how much current is charged up inside that box ?"
An imac (the old type) has the entire PC in once case together with the CRT so I think that is a non issue. The DA conversion needs to be done anyway so you might as well do it inside the monitor.
You obviously never used the google toolbar. It does a little more than just provide a search field in a toolbar. It also contains various interesting features like a context menu option on each link to use the google cache to retrieve the page. Nifty stuff like site search, backward links (i.e. who is referring to this page), colouring all occurences of your search term in the page you're looking at and easy access to google directory and groups.
The google sidebar or the google option in mozilla's search pane is not really an alternative.
If your argument was valid, games would still be implemented in assembly code. They're not so that means there's something wrong with the argument.
The problem is that good performance is just one of the many qualities you want from your system. You also want good maintainability, perfect security, the best usability, and optimal programmer productivity.
When you balance it all you will find that C no longer meets the requirements for most real world projects. It is inherently insecure, there are better languages from a point of view of programmer productivity and C code is notoriously hard to maintain due to complex syntax, preprocessor directives and other typical C issues. On top of that, in most cases the performance gain of using C is grossly overestimated and not based on any factual evidence.
IMHO 95% of C development because of performance reasons is not based on any factual evidence for performance gains. I've noticed people use C just to be sure rather than that they are experiencing actual performance problems. To make things worse: there appear to be a lot of myths about performance and most C programmers I've seen are rather stubborn and not particularly sensitive to perfectly good argumentation.
Also there are much more safe languages than C that can be just as fast as C. Somebody already mentioned ADA, lets also mention Eiffel. Not using those in system that needs to be secure is almost criminal given the near certainty of buffer overflows.
Once again, I have seen http servers, mail servers, ldap servers written in 100% Java performing at a very acceptable level. I too would like to see fast implementations of zlib, I don't see how this cannot be done in another language than C.
Maybe 1% of the code actually requires some of the dirty trickery in C (I'm very sceptical of this need) but that doesn't mean you need to implement the other 99% of the code in C as well.
You list a few interpreted and just in time compiled languages. It is commonly known that these are slower than compiled languages than C (even though they are getting awfully close performance wise). However you can do stuff like bounds checking and garbage collection in statically compiled languages as well.
These are the standard excuses I've been hearing for years. The amount of buffer flow related security issues has been a fact of life during all these years so obviously relying on programmer discipline/skill won't get us anywhere. It has never been a solution and it will never be a solution.
The JVM indeed has the problem that it is implemented in C which involves the risk of it having buffer overflows (and other C related bugs). However you can't introduce new bufferflows by programming in Java and the jvm could theoratically be reimplemented in a language that has a bit more elaborate memory protection.
Indeed bug free programs don't exist. However, minimizing the damage does help. The wide majority of programs implemented in C that we depend on might just as well be implemented in a more safe language. This includes large parts of the kernel and device drivers. I'd say it is time to give a bit more priority to security. In principle, if security is of any concern, the use of C should be avoided since it involves unnecesary risks.
The reason C is still being used is programmer lazyness. They are too lazy to learn/invent better languages (just like they are too lazy to adopt the code practices you suggest). The buffer overflow issue is so stupid, a simple run-time check completely eliminates it.
My suggestion simply is to stop developing in C. Stop new development in C, keep maintaining the old stuff and use more modern languages for new development. It can't be that hard, we can start with the smaller stuff like bind, openssh or telnet. I've seen well performing servers of all kinds written in Java. If needed, there are more lightweight languages than Java that are still secure.Most of the stuff that runs ontop of a linux kernel currently implemented in C (and therefore a security risk) could be implemented in C.
At 300 MB/s there's nothing to decode because the video is already uncompressed and surely the cost of the necessary hardware for a point to point connection of 300 MB/s will drop if there's enough hardware being deployed (just like 100 mbit hw is dirt cheap these days).
Besides, 300 MB/s would be a worst case scenario assuming no compression whatsoever. I'd be surprised if it weren't possible to cut that by at least a factor 2-5 using lossless compression (bringing it within range of gigabit ethernet and other relevant standards (maybe even ieee1394 or a successor of it)
The whole issue is not to use insecure languages like C. Such languages allow all sorts of memory manipulation and typically depends on the programmer to secure. The situation is made worse by the lack of something pretty essential: good libraries for string manipulation. While 3rd party libraries are available you can't assume these to be present so many developers still use char*.
Code reviews help, testing helps, good programming helps. But neither of these practices has succeeded in eliminating this type of bugs. It is just not good enough, witness a zillion bugs and security breaches on all major OSes (including the ones deemed secure, and yes I am talking about BSD) throughout the last decade. These OSes only differ in how the issues are dealt with. The occurance of the issue is a fact of life for all of them.
There's no C developer that can claim his program is completely free of buffer overflows (many foolishly do however). There may be some undetected errors in the program, the progrm may depend on third party code that contains bugs (e.g. the compiler or one of the standard libraries). Most likely bugs in all three categories are present.
Automatic checks are indeed the solution to the problem and modern languages build these checks into the run-time environment, where they belong. Buffer overflows are a non-issue in Java, for instance. The exception of this is native code and the JVM itself (written in C).
To eliminate buffer overflows, getting rid of the C legacy is the only solution. Java is probably too controversial as an alternative right now (though arguably it is quite up to the task as far as server side development is concerned) but there are other alternatives. Rebuilding serverside services like ftp, dns, ssh, smtp, pop, etc. is mandatory since each of these services has widely used C implementations that are frequently plagued by buffer overflows. The only way to guarantee that there are none left is to reimplement them.
Maybe to transport it over a longer distance than analog cables allow? While I agree that maybe it is a bit silly to do a AD conversion after a DA conversion has already taken place it does make me wonder why monitors don't do their own (presumably optimized) DA conversion and receive their signal in a digital form only.
It has always puzzled me that my monitor has to tell my PC what signal it needs (you needed to look up the proper refreshrates yourself before plug and play monitors arrived). Surely, modern gigabit network interfaces are fast enough to transfer the signal digitally? A 1600*1024 screen amounts to about 1.6 million pixels. In 24 bit color this requires about 4.7 MB for one screen (uncompressed). At 60 screen refreshes per second that's 300 MB/s. That is pretty much for a 1 gigabit line, so lets use two lines or do some compression (at this rate most frames will have a lot in common).
What would be the advantages? Simpler video cards in the PC. Better performing displays since the DA conversion can be tuned to the specific display. Better connectivity to e.g. alternative types of displays (beamers, tv's, etc.). Longer distance between PC and display and input devices (might as well tunnel USB signals over it too!), postprocessing of the signal in the monitor (digitally resize, display signals from 2 PCs on one screen and switch between them or show scaled versions,....), use mpeg4 compression and stream it over the internet or capture it on DVD-R.
There's a lot to be said in favor of getting rid of the analog transmission of video signals between PC and display. There's already standards for the digital transmission of audio (e.g. spdif) so why not do the same for video?
Java gaming is going to happen, just not on the PC for the moment. Right now, mobile phones are being shipped that have a JVM on board. It will be a matter of time before someone figures out how to use that for games. The same applies to PDAs.
These kind of platforms require the kind of safety and security Java offers. Particularly being unable to corrupt manually is a very nice feature since you typically don't reboot your phone.
As for 3D gaming on the PC there's some stuff to consider. You have game engines, game code that uses these engines, standalone games and low level APIs such as directX or opengl. If you look at the quake and unreal engines (responsible for most of the succesful 3d games of the past four years) you will find that they include their own scripting languages in which most of the game functionality is implemented.
In addition both John Carmack (quake) and Tim Sweeny (unreal) have considered using Java for that job in the past (way before stuff like hotspot compilers was around). For various reasons they chose not to. I recall Tim Sweeny saying in an interview he needed a more domain specific language than Java to script the objects in the game. Performance was not so much a concern (after all they ended up using a scriptlanguage).
I don't believe we're going to see much Java games in the next few years. The existing game engines are simply to good and to mature to compete with. However do foresee a shift from the low level details of rendering 3D stuff, doing 3D sound, etc. to game functionality. Already many games just use third party engines for their games. Developing your own engine only makes sense nowadays if you're able to sell it to others. One engine for one game just isn't economically feasible anymore. Likely the game engines will continue to be written in C/C++. However its just a matter of time before there will be gameengines that can also expose their API to Java or.Net. Thus allowing gamedevelopers to use a higher level, less error prone language than C for the game functionality.
In some countries there are laws against collecting data that can be related to individuals without the individuals permission. Also in most countries, upholding a "click to agree" license in court would be tricky at best.
These two combined probably makes netscape's actions illegal in some countries. Why are people making a fuss about it? After all netscape's intentions are probably pretty harmless.
However, there's no way of knowing for sure and would you really want your queries for porn of a very dubious nature logged by AOL? What if you're a chinese and you enter "falung gong" in the search field? In China that information about you is likely to get you some very special attention of the local authority.
In short, privacy matters. You own your data and stealing it (i.e. taking it without your knowledge) violates your privacy since you are not in control of what is stored and who has access to it.
Suppose you want to apply for a job at AOL (ok that's a bit extreme, I know) and the nice guy who does the interviews does a query on the netscape DB to see what kind of searches you've been doing and subsequently shows you the door. So, first they invade your privacy and then they use that information against you.
This kind of scenario's is of course not very likely but Murphy's law tells us that if it can happen it will happen. Allowing companies to secretely log privacy sensitive data will at some point have negative consequences. All that data will just be sitting there waiting to be used by whomever has access to it. The data is valuable (that's why it's being collected) and customers of that data will want to use that data for whatever is in their interest.
That's why you don't want any spyware on your computer.
Now probably Netscape's intentions are pretty harmless. Probably netscape's programmers are just as clueless about privacy as most other computer users.
I consider neither language to be ideal. However, I am pleased to see powerfull language features gaining acceptance among ordinary programmers (few of which ever use lisp). One of the reasons Java is so popular is that it provides some interesting features and is simple to use at the same time.
Syntax easthetics is of course matter of taste but many would argue lisp is quite insane with all its parenthesis. The Java language was cleverly designed to look like C++ and be as clean as Pascal. Perl on the other hand evolved from a simple scripting language to an everything and the kitchen sink language. During its evolution nobody bothered to pay attention to the syntax (other than to stay as close to the more or less quick & dirty syntax of the earlier versions of perl).
I would say that being able to do something in lisp and practice of doing something in a certain way in lisp are two different things. AOP can be implemented rather easily on top of lisp but I don't know of many projects where lisp was used in an AOP style of programming.
The confusing thing about AspectJ is that it is really not Java but rather a different language that happens to share a lot of the syntax and is able to compile to bytecode (just like e.g. Jython).
Currently the compiler merely does some preprocessing and then uses the Java compiler but the long term plans are to create a separate, incremental compiler (to improve performance on large projects).
It is also worth pointing out that there's a difference between AOP and AspectJ. AspectJ is one of the many aspect oriented languages. Other examples include IBM's HyperJ and Karl Lieberherr's Demeter Java (do a search on google if you are interested).
AspecJ happens to do most of the weaving statically but this it could just as well do it at run-time. The only problem with that is that this would affect performance since you need to do all sorts of reflective stuff in order to make it work.
The best way of describing what AOP does is to think of your OO system as a graph of objects calling each other. Aspects insert functionality on the paths in this graph that augment e.g. return values or exceptions or introduce new data.
You could for instance insert an aspect that would simply count all accesses of public methods (not particularly useful but the point is that you can). In order to that you would need a static aspect (i.e. all insertion points get the same aspect instance) with an integer and some increment functionality. In addition you would write a pointcut (i.e. a pattern identifying insertion points in the graph) that gives you all the public methods. The AspectJ compiler does the rest.
The whole point of AOP is that counting the public method accesses is a concern that is different from the other functionality in your program. More importantly, in a regular OO program it is a crosscutting concern since you would need to insert functionality in each public method to make it work.
By making it an aspect you separate the concern from the other concerns that your program addresses. Should you for example discover that you would need a long rather than an int, you only have to update the aspect rather than each public method in your program.
Well designed OO programs also exhibit some separation of concerns. Typically you will find stuff like design patterns being used to do so. The price you pay is a more complex design. AOP potentially offers you a cleaner and easier to maintain solution than design patterns. However case studies will need to proof this (this is the primary motivation for creating AspectJ).
and unsurprisingly the inventor of AOP (Gregor Kiczalez) also wrote a book on the meta object protocol (meta programming in CLOS). It's funny how people try to dismiss stuff by comparing it to stuff they do know. Aspects are of course easy to implement in Lisp (just as most other language features we know). The original, quite interesting, paper on AOP at Ecoop '97 even used CLOS for the examples. Lisp is a very powerfull language, however it is also very hard to use.
Kiczalez realized that if he'd stick to lisp, AOP would never work because ordinary C++/Java programmers would never be able to understand it (just like they never grasped meta programming, reflection and whole bunch of other advanced language concepts). Hence he made an implementation of AOP based on Java. One of the design goals was interoperability with Java so that the transition would be as easy as possible.
Now the difference between the visitor pattern and AOP is that the visitor pattern affects the design of your program (i.e. the places where visitors are used must explicitly call a visitor) whereas the usage of aspects is transparent.
There's definately more to it, I was just trying to give you the general idea. You have stuff like inheritance between aspects, abstract aspects, mechanisms to get access to whatever the aspect code ends up being weaved with. The aspectJ language is full of very powerfull features.
Slashdot Mirror
While that is true, informing the JavaRacnh people of that would have been helpful in explaining to them why this was unfortunate but necessary.
Now it just looks like a lawyer got out of control. Sending cease and desist letters to friendly supporters is not a smart thing to do (ok, it's an extremely stupid thing to do and the responsible marketing/legal drone should be kicked out for incompetence and doing major damage to the Java/Sun brand).
This will find its way to the press and it will result in lots of bad publicity for SUN. In other words its already costing them and it will even cost them more in the near future.
Sun needs to get it's marketing department in better shape, there've been several major fuckups lately:
- this ugly incident
- the convenient get Java thingy on sun.com and java.sun.com still points to jre 1.3.1 rather than jre1.4.0 even though it's been out for weeks, has better/more features, etc.
- Days after launching jre 1.4.0 a feature/marketing article on sun.com informs us of how great 1.3.1 is, never even mentioning 1.4.0.
- Java webstart is launched without any compelling webstart applications.
I mean what company invests millions in developing a product and then starts marketing the old product?? That is just nuts. It's been pointed out to them by among others me on several occasions. But they just don't get it.
Small correction, in windows the low level video driver runs in kernel mode (mostly for performance reasons). The rest lives in user land just as in UNIX. When under unix your xserver barfs you lose your data just like when the similar thing happens in windows. In windows you reboot, the user friendly but slow and annoying way of reinitializing properly, in linux you are left to fix things manually (and usually you can).
As someone else pointed out, most of the GUI in window is explorer.exe. You can kill it and it will just relaunch itself. Usually it will forget about any taskbar icons (though the associated processes still run). Luckily it crashes very rarely these days and if it does a simple logout, login fixes it properly (similar to restarting X). All the cases I had to reboot my XP machine were related to driver issues. Both my video card and audiocard come from vendors that went bankrupt: 3dfx and aureal. Consequently the XP drivers are a bit flaky you can compare that to running unsupported x drivers and kernel modules on linux.
If under linux your X driver fucks up the screen, just shutting it down may not always fix it either since the hardware only resets properly at boot time. If that happens (and I've seen it happen under linux), you are left no choice but to reboot. What good is it if you can still telnet to the box if you were busy playing unreal?. Poor hardware support is much more of an issue under linux than it is under windows.
Either way whether X crashes (and it does) or explorer.exe crashes it is usually the end of all your running apps. You may lose unsaved data and you'll need to restart the apps. It's a pain either way and in my experience both systems are plagued by it. If I run nothing but dos boxes and wordpad in XP I can probably keep it running for months or even years but that's not why I have a PC. I like to push the drivers to the limit by running 3D games and other potentially not so stable stuff. I'm pretty sure I'll experience the occasional X crash and hw lockups under linux too given the same usage pattern.
Finally I doubt the GUI is the main issue bothering windows based servers. Probably the issue is more related to memory leaks and such in IIS. A stripped linux distro with apache is notoriously stable, nobody is denying that. But that's because apache is a good product and IIS is not. Anyway we're comparing apples and oranges now since we were discussing the minor annoyance of the desktop environment crashing which is a reality users have to live with on both linux and windows.
Nothing in the linux architecture prevents the problems that have plagued windows. So it is not surprising that when linux desktops were much less feature rich they were generally more faster and bugfree. With less LOC and a similar amount of defects/KLOC you get less bugs, it has nothing to do with code quality.
With both KDE and Gnome growing in size there are more bugs to squash, more design issues to work out. Linux does not have a 16 bit dos legacy so it does not have to face BSOD's however also the more UNIX like kernel design gives you some stability.
However, memory bloat, usability bugs and stupid design are not unique to the win32 environment and are generally very portable. It is very easy to make the same mistakes when programming a KDE application as it is to do when programming an win32 application.
For the past few years, a fully featured linux desktop (i.e. not twm or some other lightweight wm) has been typically slower than a fully featured win32 desktop on my machine. Windows XP typically boots faster than it takes me to get a KDE 2.x desktop up an running from pressing the power button.
I've had several versions of Mandrake on my machine over the past few years. I found them to be buggy and unreliable (reminding me of the days I ran win95). I've experienced segfaults of the installer, corrupted rpm databases (mostly because of rpm drake crashing) and other very significant show stopper bugs on what Mandrake considered release worhty. In case you are wondering, I have an off the shelf Dell machine. Life isn't exactly wonderfull on win32 but a win2k machine feels a lot more mature and stable than a Mandrake machine.
If I want a stable linux environment I generally do not install Mandrake but Debian. However "user friendly" is not a well understood concept in the Debian world and nothing is straightforward in Debian (though given enough time you can figure it out). However, I'm comfortable with a commandline and know how to work my way through the piles of howto's, newsgroup messages and such to get a working KDE 2.2.2 installation running ontop of XFree 4.2, with sound support and a working DSL connection (none of which is easy if you start out with a potato cd and an obscure isa network card). I even enjoy doing so but I wouldn't recommend Mandrake or Debian to windows users. Well I actually did recommend Mandrake to a windows user a few months back and of course the installer blew up in his face (segfaulting halfway). He gave up on it after that.
In order to do something (anything) with structured text stored in ascii one has to parse it. If the structured information is somehow more than the syntactical structure parsed by your parser, you lose that information when you save (because your parser does not know how to parse it).
This is the main reason why there's a reverse engineering option in many case tools. You have a nice diagram, you generate code (ascii!!!), all the nice info you had in the diagram is lost because it is not part of the syntax of your programming language and after you change the generated code you have an outdated diagram and source code that simply does not contain all the necessary information to reverse engineer it (e.g. any constraints you defined in rose). Why throw away all this information? Because developers want emacs/vi/whatever to edit their code! Don't get me wrong, emacs is a wonderful text editor, so is vi. But they are text editors, not structured information editors. They don't enforce syntactical correctness, they don't allow for new syntactical concepts, they don't store meta information, etc.
That's why in addition to ascii, advanced development tools like rational rose, visual age, togetherJ, intelliJ, netbeans, etc have some sort of internal program database while running. Visual Age doesn't even bother to generate ascii anymore and uses the internal DB for storage and on the fly compilation.
The advantage of this is that you never really lose the design information (unless you export to ascii) and as long as you stay within the tool your fine. That's also why it's easy to implement stuff like refactoring (essentially refactoring is a transformation of the structured data) since you already have a queryable structure. Of course these tools save their data in some format (maybe even ascii), however the data these tools store contains all the relevant data these tools generate so nothing is lost. Netbeans for instance uses program comments to specify non editable parts of code generated by the gui builder and Visual age uses some binary format.
We can do that for them. Just share it with your gnutella client and gnutella will do the rest. Just make sure that you have a client that supports some of the interesting new features (super peer, distributed downloads). Limewire does it all. If enough people share their isos, there'll be plenty of bandwidth
Some of the better pieces on program/project metrics include extensive case studies on multiple representative cases. The other ones usually aren't worth reading.
Yours doesn't include any evidence whatsoever, just fictional examples that merely highlight how little you know about the subject. There's a lot of myths and misconceptions and myths about good programming practices and lots of people that spread them.
Your estimate of productivity of 1 programmer per day ("5000 lines of code") is way off. Multiple, very good case studies have shown this to be between 1 - 10 LOC/day on large projects including all development phases. Unlike junior programmers, experienced software engineers typically agree with this number (I've heard several claim it was actually closer to 1 LOC than 10 LOC in their organization).
I agree with you that LOC is not an ideal productivity measurement given the difference in programming language, programming style, program quality etc. There are many alternatives (e.g. function point analysis). However, LOC is simply the easiest to measure.
In some of the more advanced software developing organizations I've visited (i.e. CMM level 2 and upwards) metrics (of all sorts) are used to steer the process. Consequently, the programmers in those organizations have nine to five jobs because management is able to acurately estimate the workload for a project. Also these companies have coding standards and review processes to enforce those. In addition, they measure defects/kloc so they know how good their code is.
Good programmers get noticed in such environments because of their low defect rates, good quality code and good productivity.
"Why we must buy faster CPU instead of them fixing bugs that causes sluggish performance especially on UI?"
Because CPU's are dirt cheap. The amount of money you need to buy a modern CPU (low end) gives you one, maybe two hours programming time of a junior programmer. A professional programmer earns much more per hour and is good for maybe around 5 to 10 minutes of his/her time. So don't waste his/her time and buy a new CPU with the hardware to insert it into. You can pick up good second hand hardware for a price that is just about the same price of most commercial software packages (if you insist on being a cheap bastard). If it is your hobby to run new software on old hardware that's your problem.
There's no such thing as a standard X application other than applications that only require an X server (almost any X application requires more than just that). That's the whole problem: some applications require kde 1.2 others absolutely need kde 2.x others require neither but need Gnome 1.2 or Gnome 1.4. There's no linux distribution being shipped today that supports all four of these. so any requirement with regards to just these four desktop environments you make already limits the amount of linux distributions you can target with your application. Gnome 2.0 and KDE 3.0 are around the corner and in a year there will be two additional desktop environments to take into account.
It's not that simple and all application vendors are faced with this problem. Most vendors solve it by simply requiring red hat linux to be installed, reliefing them of the need to test with other distributions. Differences between distributions include version differences in among others kernel, compiler, libraries, x windows, desktop environment. Each of these may have version specific bugs that may or may not influence other packages. It's nearly impossible to test for all possible combinations. In addition, all distributions are updated frequently and typically have a lot of changes between versions. It's nearly impossible to keep up with that.
Support also is difficult since there are so many distribution specific problems that may prevent a program from working as intended. Imagine a user calling and asking "I can't load any site with AOL 7 on linux" or a similarly vague question. A good heuristic to approaching such a client would be to figure out whether the network is configured correctly. On windows that is easy since all versions of windows have a control panel with network settings and there are only minor differences between the different versions. On linux each distribution allows multiple ways of configuring the network and there are likely to be significant differences between each distribution and even among different versions of the same distribution. Almost certainly a proper solution to any problems with the configuration will require editing text files and work on the commandline. Not a problem for advanced users but a nightmare for the average AOL helpdesk staff and AOL user.
Actually windows media can be done as well, apparently there's a netscape plugin for it.
I think you are missing the point about expert systems. Expert systems are about specifying sets of rules. Clips is a system that provides an engine for interpreting such rules. There's no way you can somehow avoid specifying those rules for your system.
If your problem is simple enough, maybe an expert system is overkill and you can program it with some if statements in a cgi script.
Specifying the rules in an expert system is not that hard at all and certainly won't take you several months. Making the expert system interact with a bunch of cgi scripts shouldn't be that hard either.
A system you might want to look at is JESS (Java Expert System Shell) which is based on CLIPS:
http://herzberg.ca.sandia.gov/jess/
You could use it in a servlet or as an applet.
"Do you realize how much current is charged up inside that box ?"
An imac (the old type) has the entire PC in once case together with the CRT so I think that is a non issue. The DA conversion needs to be done anyway so you might as well do it inside the monitor.
You obviously never used the google toolbar. It does a little more than just provide a search field in a toolbar. It also contains various interesting features like a context menu option on each link to use the google cache to retrieve the page. Nifty stuff like site search, backward links (i.e. who is referring to this page), colouring all occurences of your search term in the page you're looking at and easy access to google directory and groups.
The google sidebar or the google option in mozilla's search pane is not really an alternative.
If your argument was valid, games would still be implemented in assembly code. They're not so that means there's something wrong with the argument.
The problem is that good performance is just one of the many qualities you want from your system. You also want good maintainability, perfect security, the best usability, and optimal programmer productivity.
When you balance it all you will find that C no longer meets the requirements for most real world projects. It is inherently insecure, there are better languages from a point of view of programmer productivity and C code is notoriously hard to maintain due to complex syntax, preprocessor directives and other typical C issues. On top of that, in most cases the performance gain of using C is grossly overestimated and not based on any factual evidence.
IMHO 95% of C development because of performance reasons is not based on any factual evidence for performance gains. I've noticed people use C just to be sure rather than that they are experiencing actual performance problems. To make things worse: there appear to be a lot of myths about performance and most C programmers I've seen are rather stubborn and not particularly sensitive to perfectly good argumentation.
Also there are much more safe languages than C that can be just as fast as C. Somebody already mentioned ADA, lets also mention Eiffel. Not using those in system that needs to be secure is almost criminal given the near certainty of buffer overflows.
Once again, I have seen http servers, mail servers, ldap servers written in 100% Java performing at a very acceptable level. I too would like to see fast implementations of zlib, I don't see how this cannot be done in another language than C.
Maybe 1% of the code actually requires some of the dirty trickery in C (I'm very sceptical of this need) but that doesn't mean you need to implement the other 99% of the code in C as well.
You list a few interpreted and just in time compiled languages. It is commonly known that these are slower than compiled languages than C (even though they are getting awfully close performance wise). However you can do stuff like bounds checking and garbage collection in statically compiled languages as well.
These are the standard excuses I've been hearing for years. The amount of buffer flow related security issues has been a fact of life during all these years so obviously relying on programmer discipline/skill won't get us anywhere. It has never been a solution and it will never be a solution.
The JVM indeed has the problem that it is implemented in C which involves the risk of it having buffer overflows (and other C related bugs). However you can't introduce new bufferflows by programming in Java and the jvm could theoratically be reimplemented in a language that has a bit more elaborate memory protection.
Indeed bug free programs don't exist. However, minimizing the damage does help. The wide majority of programs implemented in C that we depend on might just as well be implemented in a more safe language. This includes large parts of the kernel and device drivers. I'd say it is time to give a bit more priority to security. In principle, if security is of any concern, the use of C should be avoided since it involves unnecesary risks.
The reason C is still being used is programmer lazyness. They are too lazy to learn/invent better languages (just like they are too lazy to adopt the code practices you suggest). The buffer overflow issue is so stupid, a simple run-time check completely eliminates it.
My suggestion simply is to stop developing in C. Stop new development in C, keep maintaining the old stuff and use more modern languages for new development. It can't be that hard, we can start with the smaller stuff like bind, openssh or telnet. I've seen well performing servers of all kinds written in Java. If needed, there are more lightweight languages than Java that are still secure.Most of the stuff that runs ontop of a linux kernel currently implemented in C (and therefore a security risk) could be implemented in C.
At 300 MB/s there's nothing to decode because the video is already uncompressed and surely the cost of the necessary hardware for a point to point connection of 300 MB/s will drop if there's enough hardware being deployed (just like 100 mbit hw is dirt cheap these days).
Besides, 300 MB/s would be a worst case scenario assuming no compression whatsoever. I'd be surprised if it weren't possible to cut that by at least a factor 2-5 using lossless compression (bringing it within range of gigabit ethernet and other relevant standards (maybe even ieee1394 or a successor of it)
The whole issue is not to use insecure languages like C. Such languages allow all sorts of memory manipulation and typically depends on the programmer to secure. The situation is made worse by the lack of something pretty essential: good libraries for string manipulation. While 3rd party libraries are available you can't assume these to be present so many developers still use char*.
Code reviews help, testing helps, good programming helps. But neither of these practices has succeeded in eliminating this type of bugs. It is just not good enough, witness a zillion bugs and security breaches on all major OSes (including the ones deemed secure, and yes I am talking about BSD) throughout the last decade. These OSes only differ in how the issues are dealt with. The occurance of the issue is a fact of life for all of them.
There's no C developer that can claim his program is completely free of buffer overflows (many foolishly do however). There may be some undetected errors in the program, the progrm may depend on third party code that contains bugs (e.g. the compiler or one of the standard libraries). Most likely bugs in all three categories are present.
Automatic checks are indeed the solution to the problem and modern languages build these checks into the run-time environment, where they belong. Buffer overflows are a non-issue in Java, for instance. The exception of this is native code and the JVM itself (written in C).
To eliminate buffer overflows, getting rid of the C legacy is the only solution. Java is probably too controversial as an alternative right now (though arguably it is quite up to the task as far as server side development is concerned) but there are other alternatives. Rebuilding serverside services like ftp, dns, ssh, smtp, pop, etc. is mandatory since each of these services has widely used C implementations that are frequently plagued by buffer overflows. The only way to guarantee that there are none left is to reimplement them.
"Why would you like to do this?"
....), use mpeg4 compression and stream it over the internet or capture it on DVD-R.
Maybe to transport it over a longer distance than analog cables allow? While I agree that maybe it is a bit silly to do a AD conversion after a DA conversion has already taken place it does make me wonder why monitors don't do their own (presumably optimized) DA conversion and receive their signal in a digital form only.
It has always puzzled me that my monitor has to tell my PC what signal it needs (you needed to look up the proper refreshrates yourself before plug and play monitors arrived). Surely, modern gigabit network interfaces are fast enough to transfer the signal digitally? A 1600*1024 screen amounts to about 1.6 million pixels. In 24 bit color this requires about 4.7 MB for one screen (uncompressed). At 60 screen refreshes per second that's 300 MB/s. That is pretty much for a 1 gigabit line, so lets use two lines or do some compression (at this rate most frames will have a lot in common).
What would be the advantages? Simpler video cards in the PC. Better performing displays since the DA conversion can be tuned to the specific display. Better connectivity to e.g. alternative types of displays (beamers, tv's, etc.). Longer distance between PC and display and input devices (might as well tunnel USB signals over it too!), postprocessing of the signal in the monitor (digitally resize, display signals from 2 PCs on one screen and switch between them or show scaled versions,
There's a lot to be said in favor of getting rid of the analog transmission of video signals between PC and display. There's already standards for the digital transmission of audio (e.g. spdif) so why not do the same for video?
Java gaming is going to happen, just not on the PC for the moment. Right now, mobile phones are being shipped that have a JVM on board. It will be a matter of time before someone figures out how to use that for games. The same applies to PDAs.
.Net. Thus allowing gamedevelopers to use a higher level, less error prone language than C for the game functionality.
These kind of platforms require the kind of safety and security Java offers. Particularly being unable to corrupt manually is a very nice feature since you typically don't reboot your phone.
As for 3D gaming on the PC there's some stuff to consider. You have game engines, game code that uses these engines, standalone games and low level APIs such as directX or opengl. If you look at the quake and unreal engines (responsible for most of the succesful 3d games of the past four years) you will find that they include their own scripting languages in which most of the game functionality is implemented.
In addition both John Carmack (quake) and Tim Sweeny (unreal) have considered using Java for that job in the past (way before stuff like hotspot compilers was around). For various reasons they chose not to. I recall Tim Sweeny saying in an interview he needed a more domain specific language than Java to script the objects in the game. Performance was not so much a concern (after all they ended up using a scriptlanguage).
I don't believe we're going to see much Java games in the next few years. The existing game engines are simply to good and to mature to compete with. However do foresee a shift from the low level details of rendering 3D stuff, doing 3D sound, etc. to game functionality. Already many games just use third party engines for their games. Developing your own engine only makes sense nowadays if you're able to sell it to others. One engine for one game just isn't economically feasible anymore. Likely the game engines will continue to be written in C/C++. However its just a matter of time before there will be gameengines that can also expose their API to Java or
In some countries there are laws against collecting data that can be related to individuals without the individuals permission. Also in most countries, upholding a "click to agree" license in court would be tricky at best.
These two combined probably makes netscape's actions illegal in some countries. Why are people making a fuss about it? After all netscape's intentions are probably pretty harmless.
However, there's no way of knowing for sure and would you really want your queries for porn of a very dubious nature logged by AOL? What if you're a chinese and you enter "falung gong" in the search field? In China that information about you is likely to get you some very special attention of the local authority.
In short, privacy matters. You own your data and stealing it (i.e. taking it without your knowledge) violates your privacy since you are not in control of what is stored and who has access to it.
Suppose you want to apply for a job at AOL (ok that's a bit extreme, I know) and the nice guy who does the interviews does a query on the netscape DB to see what kind of searches you've been doing and subsequently shows you the door. So, first they invade your privacy and then they use that information against you.
This kind of scenario's is of course not very likely but Murphy's law tells us that if it can happen it will happen. Allowing companies to secretely log privacy sensitive data will at some point have negative consequences. All that data will just be sitting there waiting to be used by whomever has access to it. The data is valuable (that's why it's being collected) and customers of that data will want to use that data for whatever is in their interest.
That's why you don't want any spyware on your computer.
Now probably Netscape's intentions are pretty harmless. Probably netscape's programmers are just as clueless about privacy as most other computer users.
I consider neither language to be ideal. However, I am pleased to see powerfull language features gaining acceptance among ordinary programmers (few of which ever use lisp). One of the reasons Java is so popular is that it provides some interesting features and is simple to use at the same time.
Syntax easthetics is of course matter of taste but many would argue lisp is quite insane with all its parenthesis. The Java language was cleverly designed to look like C++ and be as clean as Pascal. Perl on the other hand evolved from a simple scripting language to an everything and the kitchen sink language. During its evolution nobody bothered to pay attention to the syntax (other than to stay as close to the more or less quick & dirty syntax of the earlier versions of perl).
I would say that being able to do something in lisp and practice of doing something in a certain way in lisp are two different things. AOP can be implemented rather easily on top of lisp but I don't know of many projects where lisp was used in an AOP style of programming.
The confusing thing about AspectJ is that it is really not Java but rather a different language that happens to share a lot of the syntax and is able to compile to bytecode (just like e.g. Jython).
Currently the compiler merely does some preprocessing and then uses the Java compiler but the long term plans are to create a separate, incremental compiler (to improve performance on large projects).
It is also worth pointing out that there's a difference between AOP and AspectJ. AspectJ is one of the many aspect oriented languages. Other examples include IBM's HyperJ and Karl Lieberherr's Demeter Java (do a search on google if you are interested).
AspecJ happens to do most of the weaving statically but this it could just as well do it at run-time. The only problem with that is that this would affect performance since you need to do all sorts of reflective stuff in order to make it work.
The best way of describing what AOP does is to think of your OO system as a graph of objects calling each other. Aspects insert functionality on the paths in this graph that augment e.g. return values or exceptions or introduce new data.
You could for instance insert an aspect that would simply count all accesses of public methods (not particularly useful but the point is that you can). In order to that you would need a static aspect (i.e. all insertion points get the same aspect instance) with an integer and some increment functionality. In addition you would write a pointcut (i.e. a pattern identifying insertion points in the graph) that gives you all the public methods. The AspectJ compiler does the rest.
The whole point of AOP is that counting the public method accesses is a concern that is different from the other functionality in your program. More importantly, in a regular OO program it is a crosscutting concern since you would need to insert functionality in each public method to make it work.
By making it an aspect you separate the concern from the other concerns that your program addresses. Should you for example discover that you would need a long rather than an int, you only have to update the aspect rather than each public method in your program.
Well designed OO programs also exhibit some separation of concerns. Typically you will find stuff like design patterns being used to do so. The price you pay is a more complex design. AOP potentially offers you a cleaner and easier to maintain solution than design patterns. However case studies will need to proof this (this is the primary motivation for creating AspectJ).
and unsurprisingly the inventor of AOP (Gregor Kiczalez) also wrote a book on the meta object protocol (meta programming in CLOS). It's funny how people try to dismiss stuff by comparing it to stuff they do know. Aspects are of course easy to implement in Lisp (just as most other language features we know). The original, quite interesting, paper on AOP at Ecoop '97 even used CLOS for the examples. Lisp is a very powerfull language, however it is also very hard to use.
Kiczalez realized that if he'd stick to lisp, AOP would never work because ordinary C++/Java programmers would never be able to understand it (just like they never grasped meta programming, reflection and whole bunch of other advanced language concepts). Hence he made an implementation of AOP based on Java. One of the design goals was interoperability with Java so that the transition would be as easy as possible.
Now the difference between the visitor pattern and AOP is that the visitor pattern affects the design of your program (i.e. the places where visitors are used must explicitly call a visitor) whereas the usage of aspects is transparent.
There's definately more to it, I was just trying to give you the general idea. You have stuff like inheritance between aspects, abstract aspects, mechanisms to get access to whatever the aspect code ends up being weaved with. The aspectJ language is full of very powerfull features.