However, not every user is goign to be able to make that switch. Not every user is going to fit the interation model.
True, however there are a basic set of attributes about humans that are extremely pervasive and these attributes are almost always enough to design an interface around. So it is possible to create an interface that is the most productive solution for everybody with only very rare exceptions. I do agree however that there needs to be some degree of customizability but that it should not affect the way things are done but more asthetic concerns. (I mightn't like Aqua and would prefer a nice lime green but when I click the lime green button it does exactly what the aqua button would have.)
However, being that the financial health of the company is paramount (to the company at least) the overriding factor is going to be, and must bem what the user demands. Alien interfaces will discourage upgrading and reduce profitiablity. Incremental changes tends to produce a better profit margin.
Sadly this is true - in terms of a business model you are usually better off appealling to subjective ratings rather than objective ratings - ie: keep the customers happy even if they are less productive. Incremental changes are particularly bad because they extend the length of the learning time for the changes, but allows you to sneak improvements in under the users nose which in a business sense is often required.
Re:will you macheads ever understand
on
Zarf in Mac OS X Land
·
· Score: 3, Insightful
I've already given arguments against all of your points above so let me raise the bar a little with some actual, quantitative proof. Tullis, Thomas S. "Predicting the Usability of Alphanumeric Displays," Ph.D diss., Rice University, 1984 - page 137. Tullis' dissertation shows using objective methods that an interface that optimizes productivity is not necessarily an interface that optimizes subjective ratings. In other words, it shows that you do not know what is best for you because you are being mislead by your subjective opinions.
What you have failed to realise is that there is always some relearning time when moving to a new interface regardless of whether or not that interface is good or bad. If you "cannot STAND the layout/workings/look/feel of a UI" then you are experiencing that change over period. If you take the time to learn the interface you will most likely find (assuming it is a good interface) that you are more productive and are not affected by stress from the interface but instead actually come to like it).
Now my challenge for you - find a study which shows that customizable interfaces are more productive using objective measures.
If efficiency was king we sure as sh** wouldn't be using linux now would we? To type in any standard linux commnad takes, on average, about 2-3 times as long then a simpler GUI interface. But, we LIKE to. *I AM GEEK HEAR ME TYPE*. I want to be able to do just about anything to my OS b/c that's how *I* want to do it. Not Steve, or Bill, or some 'efficiency expert'. If i want to convert my OS to only accept Hex commands thats my right!
Without meaning to sound offensive - if that's what you want, use Linux. When you want to be productive use the right tool for the job (sometimes Mac, sometimes Windows, sometimes Linux....). Also note that I've not come across anyone who used OS X for a long period of time, tried out the way it does things and actually wanted to go back. Now, part of that is that people get annoyed with it and leave, however the other part of it is that people don't know what they want until they've tried all the options. When I first tried OS X I hated the way it did things and went back to OS 9 (admittedly this was the public beta not the final release). Later when it was properly released I gave it another go and this time tried doing things it's way - now I can't imagine how I lived without it.
I understand your point, too much customization can be a bad thing for the average user, but not allowing users hardly any control over there GUI is not the solution either. And, god I hate to say this, microsoft actually did the right thing when they allowed WinXP to be changed to 'classic' windows format ( -1, flamebait). Happy medium people.. happy medium.
I would agree that some *limited* customisability is a good thing - but it generally shouldn't be in the way you do things, but in the way things look. For instance a user who has sight problems will likely appreciate a high contrast look to their computer, graphics professionals wanted to neutralise the colour scheme of OS X so it didn't affect the perception of colour. Neither of these things affect the way that things are done with the program though.
I would have to disagree that WinXP being able to be changed back to 'classic' windows format is a good thing in principle though. Backwards compatibility should not prevent you from improving your interface. The only time that you'd provide the ability to change back to the old interface is when you don't think your new interface is any good (or if you think users will revolt but that consideration doesn't come into the area of user interface design).
Now, it just so happens that there are some elements of WinXP that really are worse than the classic Windows way - the constantly changing start menu is a particularly bad idea (and proveably so). For these options even I change them back to the old look, however this is an indication of poor user interface design and not a count against customisability. (Probably comes as a surprise that I'm using XP too.... I have an OS X machine upstairs...)
You know, I've got both Galeon and Mozilla customized so that when I click my middle mouse button on a link, that link opens in a new tab. This isn't the default behavior. According to you, I am suffering reduced productivity because I now spin up new tabs with a single button click.
I said a good interface.....
The beauty of a customizable interface is that it can adapt to the way you want to work. I frequently want to open links in a new tab, so it saves me time and effort to turn a menu operation into a single middle-click. You cannot convince me that I am not better off.
I'm not going to try to - this modification should have been the default in the first place. (Remember I said a good interface) One of the choice off-hand comments in "The Humane Interface" is "On the other hand, if a program's interface is as dismal - to voice an opinion - as that of Microsoft Word 97/98, the situation is reversed. Almost any change the user makes is an improvement, to exaggerate only slightly."
Raskin makes a couple of other points that are significant here: By providing preferences, we burden users with a task extraneous to their job function. A user of, say, a spreadsheet has to learn how to use not only the spreadsheet but also the customizing facilities. Time spent in learning and operating the personalization features is time mostly wasted from the task at hand.
...
Customization sounds nice, democratic, open-ended, and full of freedom and joy for the user, but I am unaware of any studies that show that it increases productivity or improves objective measures of usability or learn-ability. Adding customization certainly makes a system more complex and more difficult to learn.
...
It is important to recognize that users will customize an interface in such a way that it appeals to their subjective judgement. As has been observed in a number of experiements, an interface that optimizes productivity is not neccessarily an interface that optimizes subjective ratings. (For example, see Tullis 1984, p. 137).
So, we can plainly see that all of the evidence indicates that a good user interface should not need to be customized. You can provide all the anecdotal, heresay evidence you like but the actual tests that have been done show that you are wrong and that customizability is generally a bad thing.
Re:will you macheads ever understand
on
Zarf in Mac OS X Land
·
· Score: 4, Informative
Jeff Raskin is an dumb ass and for the most part "usability experts" are people who get some vicarious thrill from telling others how to work. Friggin CIS majors.
There are many quantitative methods of proving that customisability is not a feature of good UI design in most cases. The best way would be to get a large random sampling of people and let them use a program, half with customisability enabled and half with it disabled. After a few months give them a task and see which group finishes it first. When this kind of test is performed it consistently finds that a well designed interface which is not customisable is better than the customisable interface.
There is no reason that the UI could not be shipped exactly as it is, defaulting to that scheme for most users while allowing power users to change things to their liking.
There's no reason why it can't be done but there is a very good reason why it should - it's bad design. In fact, it's bad design on two very basic counts. The first is the fact that when you customise a good interface you invariably make it less productive and just don't realise it. Secondly, it is extremely poor user interface design to have two modes - one for new users and one for power users.
Computers should be flexible and shouldn't needlessly constrain you, however you are much better off taking the time to relearn a few habits to become more productive, even if you feel constrained while you are relearning.
Basically, go away and read the book then you have something to argue. Right now you're spouting off with no evidence to back yourself up. Not everything is as it first appears.
Re:will you macheads ever understand
on
Zarf in Mac OS X Land
·
· Score: 4, Insightful
Why should someone bow to steve's or bill's decisions to what is the best easiest and funnest way for us to do things, when they have had enough experience to know for themselves what is the best way?
Because they (or rather the user interface designers that work for them) most likely know more about user interfaces than you do. Contrary to popular belief (particularly with Linux users) customisability is very poor user interface design and this is pointed out in Jeff Raskin's book "The Humane Interface".
When it comes down to it, you are far better off adjusting your habits to something that is more productive instead of continuing to use less efficient techniques to save relearning time. A new OS doesn't come out that often, take some time to appreciate it's new features and benefit from them or there's simply no point in upgrading.
I would have to disagree - Apple will never go back to beige on the desktop, because beige on the desktop almost killed them. They need to plan it carefully and it will have to wait until OS X is firmly seated into the Mac world but they can maintain a dual appearance - colour for the consumers and small-form for the servers.
Apple is currently building up their main business plan but rest assured they will spread into a range of areas once they have that plan running smoothly. Timing is of the essence.
This itself is part of the problem. Everyone expects a very complex system to be EASY. Computers inherently are NOT easy!
From The Humane Interface by Jeff Raskin:
Complex tasks may require complex interfaces, but that is no excuse for complicating simple tasks.
There are many tasks that can be done on a computer which are inherently simple and the UI should reflect that.
I don't think however that you need to dumb-down the distro. Linux should do this, IMHO:
On install, after you pick the install type (Workstation, Server, etc.), pick the install type (basic or advanced).
Again from The Humane Interface:
As a user of a complex system, yhou are neither a beginner nor an expert, and you cannot be placed on a single continuum between these two poles. You independently know or do not know each feature or each releated set of features that work similarly to one another.
Raskin then goes on to explain in further detail that the Beginner-Expert Dichotomy is false. He adds almost at the end of the section: a well-designed and humane interface does not have to be split into beginner and expert subsystems.
There is substantial proof that UNIX can be user friendly and it comes in the form of OS X. Despite what some other posters have said, OS X adheres to UNIX traditions extremely well (they changed/home to/Users). The only other major changes were using NetInfo for OS management instead of plain text files and the system init procedures. Both those changes were made for technical reasons (right or wrong) and are not used directly by the great majority of users.
The real problem that Linux has with being user friendly is that it is being created by people who are hopelessly unqualified to do user interface design (note that I fit this category) and that it has no standard for the way a user interface should look and feel. Now, the GNOME and KDE projects are making great headway and I'll bet that they've picked up a lot of talented designers over the years so that the brains trust is now adequate to solve the first problem. However, these people need to take the plunge and completely change the interface if it is required (a point echoed by Raskin).
The second problem will be extremely difficult to solve - it does not have to involve ridding the world of either KDE or GNOME but does involve treating them as largely different OS's that are compatible. There should be pressure on developers to develop both a KDE interface and a GNOME interface so that the user experience with either desktop is consistent. Another option would be to define a set of APIs that maps to both GNOME and KDE as native interface elements depending on which is currently in use.
This is the kind of thing that Linux has to do to be userfriendly and hence be successful on the desktop. If you think that these suggestions are unrealistic or impossible, you're saying that Linux can't make it on the desktop - I however disagree. Linux has achieved many impossible things before and in time I think it will achieve end to end user friendliness if the developers are serious about achieving that.
Initially, Microsoft could clearly make it more important to be compatible with Microsoft, but I think in short order, the standard C# will matter because it will be a base on linux and windows.
I think you're overestimating the impact of Linux here as the lack of compatibility with Linux browsers would tend to indicate. However, it raises a good point which I think we'd agree on. While "official" standards are ideal because they are well documented and changes are controlled by some central authority, it is the defacto standard that really matters as a standard is useless if the majority of implementations don't follow it.
The really interesting thing about that is that it brings us around to saying that it's the implementations that matter and that the official standard holds a very precarious position in the whole set up. If the most popular implementations of Java were to divert from Sun's specifications then Sun's specifications would be worthless. Sun's only protection against this is that they own the name Java (we saw this actually eventuate in the court case between Sun and MicroSoft). The same applies for C# of course, if MS takes the language/system in a direction that Linux users don't like (and Linux actually has enough market share to hold influence) then MS's C# specification will be worthless and Linux will control C# because they control the source to the defacto standard.
Apologies for treating Linux as some collective company but otherwise the argument gets awfully confusing. Think of Linux in the above paragraph as the collective of developers for Linux's C# implementation.
ECMA going bad is a concern, but it is less likely to go bad in Microsofts favor as Sun is likely to go bad in Suns favor, so it adds a buffering layer.
Well, Sun is always looking after their best interests so the concern is more that their goals change, but that's not hugely important. What is interesting is that one of the big reasons the ECMA would go bad is that MS pressures them into it. Further more, because MS controls what will undoubtably be the most popular implementation and the mindshare as to who owns C# (or.Net) with consumers, MS controls the standard regardless of what the ECMA does. The worst the ECMA could do is refuse to allow MicroSoft to call their implementation C# which would have little effect because the general concensus is the.Net is a Microsoft thing not an ECMA thing. MS would not be overly hampered by having to change the name and with the right publicity almost everyone would switch over.
w3c does patent disclosure which I think is critically important for example and standards are stronger the more it matters to folks. JEDEC now has incredibly strict disclosure requirements so that folks can standardize on SDRAM for example feeling pretty safe in doing so.
Agreed, patent disclosure is what I am more concerned about than whether a technology is controlled by a company or a standards body. I can keep using any published specification as long as it is patent free and I don't infringe on trade marks. If I want to use an actual implementation then copyright is an issue but once licenced always licenced (for that version and unless the licence specifies otherwise). It's obviously not always pleasant to continue using a technology after it stops being supported but there are all kinds of legacy systems still in use that use technologies that have long since gone out of fashion.
I think it is useful to ask, just how badly can Sun/Microsoft/GPL'ed software screw you if they do go bad? A lot of GPL'ed software allows the FSF to screw them if they went bad, by up-licensing to a BSD style perhaps. Unlikely but possible
Risk analysis is always essential, but you need to do it right. Both impact and chance of occurrance as you suggest. However, there is a point where the benefits of a new technology outweigh the risks of it's controller going bad. For each company that will be different I suppose and some people will always be paranoid, others will always be naive and gullable - hopefully we can land somewhere safely in the middle.
OpenGFS we see exactly good guys gone bad happening, and it has happend in a bunch of other areas as well.
I guess the only way you can be certain about the direction of anything is to own the intellectual property yourself. If you want something done right, do it yourself.....
So yeah, either could go bad, but we only care if Sun does, because they can do real damage.
Agreed, but now look at some other standards organisation, say the organisation that certified C# (ECMA?). Wouldn't the same argument apply?
For the record, I make no claims about the sainthood of Sun, I'm more intrigued as to why standards are seen as infallable when history shows that they quite often don't work out well (HTML anyone - or pretty much any other web standard). Just thinking out loud mainly.....
OS X runs some non-UI, almost no OS interaction (dynamic allocations, that's it) code in the program I work on more than three times slower than the same executable in Mac OS 9.1. There's something seriously disturbed in that OS still...
No, there's something seriously disturbed in your code - it's written for OS 9 and running on OS X. As has been documented all over the web, the way you did things in OS 9 is not nessecarily the way to do it in OS X as the OS has different strengths and weaknesses.
You also happen to be wrong: Unless you see a license listed as OSI approved, it is unlikely to be really open source. Folks need to remember:
Shared Source != Open Source
Community Source != Open Source
There are incredibly important distinctions between these.
Okay, here's an interesting thought that just sprang into my head. If Java is not a real standard because it only comes from Sun and not a standards organisation, then why is opensource a standard (standard definition of the term opensource at the least) when it is completely controlled by the OSI?
I don't mean this as a flame or troll, but who decides who gets to be a standards organisation? People argue that if Sun were to collapse (or just abandon Java) then the Java "standard" would become worthless and the Java developers would be left high and dry. What happens if the OSI for some reason collapses (quite possible through some form of law suit which bankrupts them or through a variety of other means)? Wouldn't that make the term opensource completely worthless as a standard?
The other argument people have is that Sun has full control of Java and that's a bad thing but doesn't this same argument apply to the OSI? The OSI controls the term opensource. If your answer is that the OSI has community input into it's decision making process, so does Java (the Java Community Process).
I will conceed that the OSI is far more community based than Sun (obviously) but I find it astonishing that noone (including myself) has realised that even non-profit organisations run by community processes can go bad and leave you high and dry. If you want an example of this happening, look at a number of churches (at many levels of the church organisation and please note that this is not a criticism of all churches nor religion etc, just noting the fact that churches can struggle to keep in touch with their aims and can loose their way). I think religion is probably an even tighter binding phenominon than opensource, so if churches can loose their way, what's to stop opensource communities from doing the same?
Consider all those video editors that need to see their movies while surfing the web ? ( or consider us geeks that want to see our PearlHarbor divx over and over again while coding )
My housemate just minimizes the window into the dock and watches it in there. The dock can be resized to make the movie larger if required. Not the ideal option obviously but pretty cool.
I hope Apple sees that there are many Linux desktop users that switched to have MacosX that really want/need those things. I hope they just add some options for the WindowManager for us power-users. Hide it from the casual users, but let power-users do what they want;-)
Go away and come back when you have read "The Humane Interface" by Raskin.:) The idea that a configurable interface is a good thing is completely false - you should just create the ideal interface in the first place and users generally fail to realise that their changes make them less productive (read the book, it argues this much better). Also, the idea that you need separate interfaces for beginners and power users is false because when you start using the program you are a beginner and when you first start using the power user interface you are also a beginner and have to relearn the entire interface again, wasting all the time you spent developing habits in the beginner interface.
Again, read the book, my arguments are not high quality but the book is far more detailed and convincing.
But After a month OSX still surprises me here and there and I've grown accustom to the OSX Desktop.
Precisely my point (or Raskin's actually) - you are becomming more accustomed to the interface and learning the habits that you require to be productive on that interface. Switching OS's (or interfaces) always makes you feel like the second interface is less productive in one way or the other and for a while it really is. Eventually though, you "unlearn" the habits you developed on the old interface and learn the new ones at which point the old interface feels less productive (and is for you). Telling which interface is actually more productive once learnt is really quite in depth but is covered in "The Humane Interface" quite well.
Four years as a senior software engineer on Apple's OS teams.
If your claims are true then please send me a copy of the law suit threat you get for breach of contract on this one. C'mon, you really expect us to believe that a long time Apple engineer would stroll up to/. and give away one of the company's biggest secrets without being sued for it?
Sorry to be rude but you're either an incredibly foolish Apple engineer or you're lying.
Internally Apple has a different Darwin source tree than the one that has been released to the community.
This would go against what is being publicly stated by Apple in the Darwin FAQ. To quote: Most of the projects in the Darwin repository are the same live source trees used by Apple engineers for the Mac OS X product build. This means that as we work on Mac OS X internally, the changes we make are immediately visible on the Darwin source code repository.
Now, granted that does say most, not all, however signs of an Intel port would have to show up in more that just a few of the modules. Also, it is possible that Apple is lying about this however you'd have to question why they'd risk the reputation of the company on this. Finally, if ex-apple engineers like yourself are so open to explaining that OS X works on Intel, why are all the rumour sites saying the exact opposite?
However, the Java built-in libraries have enough built-in bloat to make further promises of speed indistinguishability just plain misleading ("it works fine, just avoid this list of 50 poorly implemented classes"). No, Java the language isn't slow, but Java the set of Sun library implementations has many, many deficiencies.
I would again have to contest this. WorldBook makes very heavy use of graphics (as does the stuff I work on) and it still managed to perform well and didn't seem to have any problems with bugs. There are bugs in almost every library and I have not found there to be any more in the Java APIs despite constantly working with the latest betas and early access releases.
I took some of my company's Java apps that ran well under Windows and tried them under OS X and they were dog slow. At one point I managed to get ProcessViewer to report CPU usage over 100%! Highlight some text in your browser - that's what it does. Two simple math coordinate checks, a couple calls to drawRect and drawChars, written about as efficiently as Java allows but with every set of mouse movements I saw the CPU usage shoot through the roof.
I would be very suspicious that when you wrote your custom class you optimised it based on your knowledge of Windows and not of Mac OS - the two graphics subsystems work very differently so your optimised code is likely to have actually been the worst possible code for OS X. If you want to benefit from Java's cross-platform abilities you actually have to use them. The API is the key to getting cross-platform compatibility because it is reviewed and optimised for each OS it is ported to. Your code doesn't have a hope of knowing as much about the system or being better optimised. I spend all day running the exact same Java application on Mac and Windows (95 and XP) and it runs the same on both at about the same speed because I take advantage of the APIs.
I know JBuilder runs fine on my machine (I suspect some Mac-specific code or vm settings) but Java isn't at all guaranteed to run well across platforms.
JBuilder is not heavily tweaked for OS X, it's just well written Java code. Poke around JBuilder's files and you'll find it doesn't do much more than a simple 'java -classpath blah com.borland.JBuilder' For the record I find Java runs perfectly fine on everything from a P100 right up to the 1.2Ghz Athlon and from a Rev B iMac (300Mhz) up to the 400Mhz G4 laptop I currently use. Perfectly fine in this case means comparable to programs written in C. Yes there's a longer launch time in most cases (again, OS X makes huge inroads into this and 1.5 will likely adopt this technology to reduce loading times and memory requirements significantly).
On Mac, it looks sweet except for text rendering.
I don't know about you, but I quite like the smooth, easy to read look that Java's text gets on OS X with it's antialiasing.
The bugs are actually probably more annoying because they are the let-downs "Oh, look it has this great gui widget" and then ten days later "Oh crap that widget has a horrible bug and I'm completely reliant on Sun to fix it
I really haven't seen that many bugs in the Java APIs that you would consider it worse than other libraries. If you are consistently having trouble with JTree then it may be worth extending the class to fix the bugs where possible (and you'd be amazed at how much you can achieve this way) or develop your own solution (as a last resort). Consider that with C/C++ you don't get *any* graphical abilities for free (all provided by 3rd party libraries which are completely platform specific etc, etc), you really aren't that badly done by if you have to implement a couple of custom widgets in Java.
When it comes down to it, the solution is to write good code. I can be pretty certain (but not 100% sure obviously) that you are not writing good *Java* code because you are so anti Java. You simply have not accepted the languages strong and weak points and so can't take advantage of the strengths. You also seem to come from a background in another language (C/C++ would be likely) and you don't seem to be willing to adapt to the "Java way" because you are hooked on the "C/C++ way" (or whatever previous language you prefer).
I apologise for any offence in the above statements, I can see from your posts that you are neither stupid nor irrational and in fact are quite intelligent with a fairly open mind. However, changing programming languages is really difficult particularly when they seem as similar as Java and C++. You have to realise that Java is only asthetically similar to C++ but is in fact based on a very different grounding principle. C++ looks for speed and efficiency at the cost of safety (buffer overflow anyone?) and platform independance, whereas Java focuses on safety and cross-platform consistency at the expense of speed (yes there is a speed penalty to be taken but in most cases it is an acceptable trade off and great gains are being made). Further to this, C++ is a procedural language which has had object oriented "stuff" added on top whereas Java was designed from the start to be object oriented (with some procedural elements).
Basically, there is nothing stopping you from developing your own API for Java but I'm pretty certain that you can't do a better job than Sun has - if it was so easy and/or the Java API is so bad, why hasn't anyone created an alternative?
MacOSX provides just such an API. Although Objective-C is the `preferred' language of Cocoa, there are Java bindings. Note - this API is NOT Swing - it is a MacOSX extension API.
Yes and no. The Cocoa APIs are an extension that is not cross-platform, however if you use the Swing libraries on OS X, by default they use native widgets. So you can write a 100% pure Java application that uses native widgets on OS X. I would expect that this kind of thing will flow back into Sun's JVM around 1.5 or so.
I'm not trying to criticize Mac users here at all, I'm just saying that impressing people at MacWorld doesn't prove much at all.
Go and look at WorldBook on OS X and you will also be impressed. More importantly though, noone realised it was a Java application. It looked and acted just like a C/C++ application.
Sun is like Microsoft - they make as many features as possible, worry about the bugs later and let hardware catch up to overcome their crippling defects caused by overzealous and misinformed OOD.
Okay, I can't take this any more - Java is not slow or buggy and can produce applications that are indistinguishable from C/C++ applications. The proof of this is simple - rewind the clock back a year to MacWorld where WorldBook Encyclopedia was demoed as part of the keynote with everyone watching and they were all impressed. Months later I was informed by the "head Java dude" at Apple on his Australian tour that WorldBook is completely written in Java - but noone knew.
Most people think that Java is slow, buggy and doesn't look platform native because they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java. It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code). Sure there are some things that Java can't do that you need native code modules to handle but that facility is available.
The worst thing is that young programmers are led to think that Sun's code is actually *good* which spreads their poor, inefficient form to the next generations.
Java's not perfect, but I seriously don't think that it's Java that corrupts young programmers. You can write good code in almost any language - I see an awful lot of really bad Java code written by C programmers but I'm not about to claim that C is corrupting old programmers.
This is a feature of Java WebStart - application developers can specify a minimum JRE to use and WebStart will automatically download it when it is not already present. Note that while Web Start has just become standard with JRE1.4, it will run even on JRE 1.1 and I would imagine this clause is in the separate Java Web Start download as well.
Given time I can come up with several examples, but lets go with one here: Basic is an open standard with lots of (varied) implementations. PICK is a language (among other things) that ended up looking rather like Basic after several evolutionary changes. Why did PICK evolve towards Basic? PICK was arguably better on several levels. But it was a closed, proprietary standard.
BASIC never tried to provide cross-platform compatibility (in some cases it achieved it at the source level, but it was not the intention). Java and C# attempt to provide cross-platform compatibility so having a coherent standard instead of a great array of similar but different implentations is very important. Take the example I gave earlier of HTML - try to create a web site that looks the same in every browser and you will not be able to use anything but very basic HTML and this is with the benefit of an international standard.
By supporting embrace and extend you are supporting not following standards and yet your argument centres around the fact that C# is a standard. What is not included in a standard is just as important as what is in it - again look at HTML, Explorer started supporting invalid HTML and it has lead to an absolute mess. Same thing with BASIC in fact. Try programming in BASIC on a Commodore 64 and on a BBC Microcomputer and you will find that they are in fact quite different languages.
In this case the real winners are the programmers of five years from now when idea convergence and the natural workings of the marketplace of ideas create a better technology.
But will it actually create better technology or will it just fragment better technology between many different incompatible standards? What benefit is a cross-platform language that works differently in every implementation?
First rule of civil debate: Attack the message, not the messenger. Personally I believe that I am fully capable of making such distinctions by using a rich and approprite set of heuristic comparisons which I need not detail here. Can you accept that and choose to disagree with me solely on the basis of my ideas and opinions? If so then you are trading in that 'marketplace of ideas' I keep blathering about. Otherwise you are only trading in insult and antipathy. I have nothing to offer in exchange there
Second rule of civil debate: look for meaning not just words. Read this carefully: if your only argument for C# is that it's open and you believe that it is a better option than Java then you are obviously not capable of making an informed decision as to the merit of the programming language because if I were to create an open language that wasn't even Turing complete, your argument would show that it was better than Java when this is clearly not the case. In other words, you message is flawed - C# is not better than Java because it is open - it may or may not be better depending on what features it provides and what you are aiming to achieve.
Also (referring to part b), if you feel that Java is less open than C# then you are also mistaken as both C# and Java have publicly available specifications (Java definitely for the entire system and I will assume so for C# but note other messages stating that it is not the full spec) then I will challenge you to produce a programming language which is incompatible with C#, publicise it widely and see how long before you have a trademark infringement case (or some other legal argument) brought against you. Java is just as open as C# only that in once case the specification is reviewed by a community based organisation and the other by the EMCA. You were aware that Java is controlled by a board of people who include community members as well as Sun (and Sun does not have a controlling stake in the board) right? You were aware that you can licence the Java HotSpot engine (an actual implementation not just a specification) on the condition that you agree to some NDA agreements and that you will fold improvements back into Sun's version right?
If you want to see embrace and extend working in Java, check out what Apple is doing with Java and then take note of the fact that those improvements are being folded back into the main distribution to keep everything compatible. With C# there is no obligation that improvements be folded back into the original so you wind up with a bunch of incompatible versions and that definitely does not benefit developers or end users.
At least so long as we can pick and choose, in the marketplace of ideas....
Nice to know that with a convicted monopolist inventing the technology you will always be able to pick and choose between competitors isn't it...... Oh wait, there are no reasonable competitors to MS as ruled by a court of law.
Finally, you're arguments for embrace and extend apply just as much to Java as they do to C# - you can embrace and extend but if the owner of the trademark doesn't approve you have to rename it. Java is an open standard, go to http://java.sun.com and grab a copy of the *full* specification if you desire as well as specifications for new additions that are under review. If you think that standards only work when they come from non-profit standards organisations then perhaps you should look at the mess that is HTML these days and rethink how well international standards work.
If your only argument for C# is that it's open I think you a) have no clue about how to decide upon an appropriate programming language and b) are sorely mistaken about what is open and how useful it works.
So in that way, I was learning from professional programmers,
which in turn, could possibly (most likely) generate more professional
programmers,
Not quite - you are learning from the code of professional programmers, not the programmers themselves. The big difference doesn't show up in your code but in your documentation, design and process skills. Initial coding is only a very minor part of the battle of creating great software, the rest is in the design and maintenance and looking at code will teach you very little about documentation requirements.
You can certainly pick up some aspects of design from code directly, but don't fool yourself into thinking you are competent at design if you have only learnt from code - it really is an artform. Probably the biggest failing of open source software is in it's documentation (ie: there is extremely little and documentation is almost always behind). I am definitely not one to support producing copious amounts of wasted paper but I am well aware of how much difference a solid design, fully planned before any code is written, can benefit productivity in the long run.
So by all means participate in open source development and learn from the code, you will learn vast amounts about code that way but don't stop there. Go out and get a degree in software engineering (or something else that focusses on design and maintenance since you already know how to code well), read as many books and white papers on software design as you can or better yet, do both (and whatever else you can find).
I know there
are always people better than me, and things to learn
That's the spirit! There is some really cool stuff coming out in white papers these days both relating to code and design - keep an eye out for Genetic Software Engineering from the Software Quality Institute they're doing some really cool stuff.
Maybe if we all go out and study up on design and management (yes, yes, but it's important even in opensource) the next survey will show that open source developers are brilliant at code, design and make the best managers.... Or maybe that's pushing it.....
Money, of course. They're hoping to rake in licensing fees.
Does anyone else find it ironic (or possibly just stupid) that someone would try to rake in licencing fees from a video codec that is predominently used to pirate movies....
Slashdot Mirror
True, however there are a basic set of attributes about humans that are extremely pervasive and these attributes are almost always enough to design an interface around. So it is possible to create an interface that is the most productive solution for everybody with only very rare exceptions. I do agree however that there needs to be some degree of customizability but that it should not affect the way things are done but more asthetic concerns. (I mightn't like Aqua and would prefer a nice lime green but when I click the lime green button it does exactly what the aqua button would have.)
However, being that the financial health of the company is paramount (to the company at least) the overriding factor is going to be, and must bem what the user demands. Alien interfaces will discourage upgrading and reduce profitiablity. Incremental changes tends to produce a better profit margin.
Sadly this is true - in terms of a business model you are usually better off appealling to subjective ratings rather than objective ratings - ie: keep the customers happy even if they are less productive. Incremental changes are particularly bad because they extend the length of the learning time for the changes, but allows you to sneak improvements in under the users nose which in a business sense is often required.
What you have failed to realise is that there is always some relearning time when moving to a new interface regardless of whether or not that interface is good or bad. If you "cannot STAND the layout/workings/look/feel of a UI" then you are experiencing that change over period. If you take the time to learn the interface you will most likely find (assuming it is a good interface) that you are more productive and are not affected by stress from the interface but instead actually come to like it).
Now my challenge for you - find a study which shows that customizable interfaces are more productive using objective measures.
Without meaning to sound offensive - if that's what you want, use Linux. When you want to be productive use the right tool for the job (sometimes Mac, sometimes Windows, sometimes Linux....). Also note that I've not come across anyone who used OS X for a long period of time, tried out the way it does things and actually wanted to go back. Now, part of that is that people get annoyed with it and leave, however the other part of it is that people don't know what they want until they've tried all the options. When I first tried OS X I hated the way it did things and went back to OS 9 (admittedly this was the public beta not the final release). Later when it was properly released I gave it another go and this time tried doing things it's way - now I can't imagine how I lived without it.
I understand your point, too much customization can be a bad thing for the average user, but not allowing users hardly any control over there GUI is not the solution either. And, god I hate to say this, microsoft actually did the right thing when they allowed WinXP to be changed to 'classic' windows format ( -1, flamebait). Happy medium people.. happy medium.
I would agree that some *limited* customisability is a good thing - but it generally shouldn't be in the way you do things, but in the way things look. For instance a user who has sight problems will likely appreciate a high contrast look to their computer, graphics professionals wanted to neutralise the colour scheme of OS X so it didn't affect the perception of colour. Neither of these things affect the way that things are done with the program though.
I would have to disagree that WinXP being able to be changed back to 'classic' windows format is a good thing in principle though. Backwards compatibility should not prevent you from improving your interface. The only time that you'd provide the ability to change back to the old interface is when you don't think your new interface is any good (or if you think users will revolt but that consideration doesn't come into the area of user interface design).
Now, it just so happens that there are some elements of WinXP that really are worse than the classic Windows way - the constantly changing start menu is a particularly bad idea (and proveably so). For these options even I change them back to the old look, however this is an indication of poor user interface design and not a count against customisability. (Probably comes as a surprise that I'm using XP too.... I have an OS X machine upstairs...)
I said a good interface.....
The beauty of a customizable interface is that it can adapt to the way you want to work. I frequently want to open links in a new tab, so it saves me time and effort to turn a menu operation into a single middle-click. You cannot convince me that I am not better off.
I'm not going to try to - this modification should have been the default in the first place. (Remember I said a good interface) One of the choice off-hand comments in "The Humane Interface" is "On the other hand, if a program's interface is as dismal - to voice an opinion - as that of Microsoft Word 97/98, the situation is reversed. Almost any change the user makes is an improvement, to exaggerate only slightly."
Raskin makes a couple of other points that are significant here:
By providing preferences, we burden users with a task extraneous to their job function. A user of, say, a spreadsheet has to learn how to use not only the spreadsheet but also the customizing facilities. Time spent in learning and operating the personalization features is time mostly wasted from the task at hand.
Customization sounds nice, democratic, open-ended, and full of freedom and joy for the user, but I am unaware of any studies that show that it increases productivity or improves objective measures of usability or learn-ability. Adding customization certainly makes a system more complex and more difficult to learn.
It is important to recognize that users will customize an interface in such a way that it appeals to their subjective judgement. As has been observed in a number of experiements, an interface that optimizes productivity is not neccessarily an interface that optimizes subjective ratings. (For example, see Tullis 1984, p. 137).
So, we can plainly see that all of the evidence indicates that a good user interface should not need to be customized. You can provide all the anecdotal, heresay evidence you like but the actual tests that have been done show that you are wrong and that customizability is generally a bad thing.
There are many quantitative methods of proving that customisability is not a feature of good UI design in most cases. The best way would be to get a large random sampling of people and let them use a program, half with customisability enabled and half with it disabled. After a few months give them a task and see which group finishes it first. When this kind of test is performed it consistently finds that a well designed interface which is not customisable is better than the customisable interface.
There is no reason that the UI could not be shipped exactly as it is, defaulting to that scheme for most users while allowing power users to change things to their liking.
There's no reason why it can't be done but there is a very good reason why it should - it's bad design. In fact, it's bad design on two very basic counts. The first is the fact that when you customise a good interface you invariably make it less productive and just don't realise it. Secondly, it is extremely poor user interface design to have two modes - one for new users and one for power users.
Computers should be flexible and shouldn't needlessly constrain you, however you are much better off taking the time to relearn a few habits to become more productive, even if you feel constrained while you are relearning.
Basically, go away and read the book then you have something to argue. Right now you're spouting off with no evidence to back yourself up. Not everything is as it first appears.
Because they (or rather the user interface designers that work for them) most likely know more about user interfaces than you do. Contrary to popular belief (particularly with Linux users) customisability is very poor user interface design and this is pointed out in Jeff Raskin's book "The Humane Interface".
When it comes down to it, you are far better off adjusting your habits to something that is more productive instead of continuing to use less efficient techniques to save relearning time. A new OS doesn't come out that often, take some time to appreciate it's new features and benefit from them or there's simply no point in upgrading.
Slashdot moderation really needs a "Bastardry" option for this comment.... I just can't decide if it's +1 or -1.....
Apple is currently building up their main business plan but rest assured they will spread into a range of areas once they have that plan running smoothly. Timing is of the essence.
From The Humane Interface by Jeff Raskin:
There are many tasks that can be done on a computer which are inherently simple and the UI should reflect that.I don't think however that you need to dumb-down the distro. Linux should do this, IMHO: On install, after you pick the install type (Workstation, Server, etc.), pick the install type (basic or advanced).
Again from The Humane Interface:
Raskin then goes on to explain in further detail that the Beginner-Expert Dichotomy is false. He adds almost at the end of the section: a well-designed and humane interface does not have to be split into beginner and expert subsystems.There is substantial proof that UNIX can be user friendly and it comes in the form of OS X. Despite what some other posters have said, OS X adheres to UNIX traditions extremely well (they changed /home to /Users). The only other major changes were using NetInfo for OS management instead of plain text files and the system init procedures. Both those changes were made for technical reasons (right or wrong) and are not used directly by the great majority of users.
The real problem that Linux has with being user friendly is that it is being created by people who are hopelessly unqualified to do user interface design (note that I fit this category) and that it has no standard for the way a user interface should look and feel. Now, the GNOME and KDE projects are making great headway and I'll bet that they've picked up a lot of talented designers over the years so that the brains trust is now adequate to solve the first problem. However, these people need to take the plunge and completely change the interface if it is required (a point echoed by Raskin).
The second problem will be extremely difficult to solve - it does not have to involve ridding the world of either KDE or GNOME but does involve treating them as largely different OS's that are compatible. There should be pressure on developers to develop both a KDE interface and a GNOME interface so that the user experience with either desktop is consistent. Another option would be to define a set of APIs that maps to both GNOME and KDE as native interface elements depending on which is currently in use.
This is the kind of thing that Linux has to do to be userfriendly and hence be successful on the desktop. If you think that these suggestions are unrealistic or impossible, you're saying that Linux can't make it on the desktop - I however disagree. Linux has achieved many impossible things before and in time I think it will achieve end to end user friendliness if the developers are serious about achieving that.
I think you're overestimating the impact of Linux here as the lack of compatibility with Linux browsers would tend to indicate. However, it raises a good point which I think we'd agree on. While "official" standards are ideal because they are well documented and changes are controlled by some central authority, it is the defacto standard that really matters as a standard is useless if the majority of implementations don't follow it.
The really interesting thing about that is that it brings us around to saying that it's the implementations that matter and that the official standard holds a very precarious position in the whole set up. If the most popular implementations of Java were to divert from Sun's specifications then Sun's specifications would be worthless. Sun's only protection against this is that they own the name Java (we saw this actually eventuate in the court case between Sun and MicroSoft). The same applies for C# of course, if MS takes the language/system in a direction that Linux users don't like (and Linux actually has enough market share to hold influence) then MS's C# specification will be worthless and Linux will control C# because they control the source to the defacto standard.
Apologies for treating Linux as some collective company but otherwise the argument gets awfully confusing. Think of Linux in the above paragraph as the collective of developers for Linux's C# implementation.
ECMA going bad is a concern, but it is less likely to go bad in Microsofts favor as Sun is likely to go bad in Suns favor, so it adds a buffering layer.
Well, Sun is always looking after their best interests so the concern is more that their goals change, but that's not hugely important. What is interesting is that one of the big reasons the ECMA would go bad is that MS pressures them into it. Further more, because MS controls what will undoubtably be the most popular implementation and the mindshare as to who owns C# (or .Net) with consumers, MS controls the standard regardless of what the ECMA does. The worst the ECMA could do is refuse to allow MicroSoft to call their implementation C# which would have little effect because the general concensus is the .Net is a Microsoft thing not an ECMA thing. MS would not be overly hampered by having to change the name and with the right publicity almost everyone would switch over.
w3c does patent disclosure which I think is critically important for example and standards are stronger the more it matters to folks. JEDEC now has incredibly strict disclosure requirements so that folks can standardize on SDRAM for example feeling pretty safe in doing so.
Agreed, patent disclosure is what I am more concerned about than whether a technology is controlled by a company or a standards body. I can keep using any published specification as long as it is patent free and I don't infringe on trade marks. If I want to use an actual implementation then copyright is an issue but once licenced always licenced (for that version and unless the licence specifies otherwise). It's obviously not always pleasant to continue using a technology after it stops being supported but there are all kinds of legacy systems still in use that use technologies that have long since gone out of fashion.
I think it is useful to ask, just how badly can Sun/Microsoft/GPL'ed software screw you if they do go bad? A lot of GPL'ed software allows the FSF to screw them if they went bad, by up-licensing to a BSD style perhaps. Unlikely but possible
Risk analysis is always essential, but you need to do it right. Both impact and chance of occurrance as you suggest. However, there is a point where the benefits of a new technology outweigh the risks of it's controller going bad. For each company that will be different I suppose and some people will always be paranoid, others will always be naive and gullable - hopefully we can land somewhere safely in the middle.
OpenGFS we see exactly good guys gone bad happening, and it has happend in a bunch of other areas as well.
I guess the only way you can be certain about the direction of anything is to own the intellectual property yourself. If you want something done right, do it yourself.....
Agreed, but now look at some other standards organisation, say the organisation that certified C# (ECMA?). Wouldn't the same argument apply?
For the record, I make no claims about the sainthood of Sun, I'm more intrigued as to why standards are seen as infallable when history shows that they quite often don't work out well (HTML anyone - or pretty much any other web standard). Just thinking out loud mainly.....
No, there's something seriously disturbed in your code - it's written for OS 9 and running on OS X. As has been documented all over the web, the way you did things in OS 9 is not nessecarily the way to do it in OS X as the OS has different strengths and weaknesses.
Okay, here's an interesting thought that just sprang into my head. If Java is not a real standard because it only comes from Sun and not a standards organisation, then why is opensource a standard (standard definition of the term opensource at the least) when it is completely controlled by the OSI?
I don't mean this as a flame or troll, but who decides who gets to be a standards organisation? People argue that if Sun were to collapse (or just abandon Java) then the Java "standard" would become worthless and the Java developers would be left high and dry. What happens if the OSI for some reason collapses (quite possible through some form of law suit which bankrupts them or through a variety of other means)? Wouldn't that make the term opensource completely worthless as a standard?
The other argument people have is that Sun has full control of Java and that's a bad thing but doesn't this same argument apply to the OSI? The OSI controls the term opensource. If your answer is that the OSI has community input into it's decision making process, so does Java (the Java Community Process).
I will conceed that the OSI is far more community based than Sun (obviously) but I find it astonishing that noone (including myself) has realised that even non-profit organisations run by community processes can go bad and leave you high and dry. If you want an example of this happening, look at a number of churches (at many levels of the church organisation and please note that this is not a criticism of all churches nor religion etc, just noting the fact that churches can struggle to keep in touch with their aims and can loose their way). I think religion is probably an even tighter binding phenominon than opensource, so if churches can loose their way, what's to stop opensource communities from doing the same?
My housemate just minimizes the window into the dock and watches it in there. The dock can be resized to make the movie larger if required. Not the ideal option obviously but pretty cool.
I hope Apple sees that there are many Linux desktop users that switched to have MacosX that really want/need those things. I hope they just add some options for the WindowManager for us power-users. Hide it from the casual users, but let power-users do what they want ;-)
Go away and come back when you have read "The Humane Interface" by Raskin. :) The idea that a configurable interface is a good thing is completely false - you should just create the ideal interface in the first place and users generally fail to realise that their changes make them less productive (read the book, it argues this much better). Also, the idea that you need separate interfaces for beginners and power users is false because when you start using the program you are a beginner and when you first start using the power user interface you are also a beginner and have to relearn the entire interface again, wasting all the time you spent developing habits in the beginner interface.
Again, read the book, my arguments are not high quality but the book is far more detailed and convincing.
But After a month OSX still surprises me here and there and I've grown accustom to the OSX Desktop.
Precisely my point (or Raskin's actually) - you are becomming more accustomed to the interface and learning the habits that you require to be productive on that interface. Switching OS's (or interfaces) always makes you feel like the second interface is less productive in one way or the other and for a while it really is. Eventually though, you "unlearn" the habits you developed on the old interface and learn the new ones at which point the old interface feels less productive (and is for you). Telling which interface is actually more productive once learnt is really quite in depth but is covered in "The Humane Interface" quite well.
Four years as a senior software engineer on Apple's OS teams.
If your claims are true then please send me a copy of the law suit threat you get for breach of contract on this one. C'mon, you really expect us to believe that a long time Apple engineer would stroll up to /. and give away one of the company's biggest secrets without being sued for it?
Sorry to be rude but you're either an incredibly foolish Apple engineer or you're lying.
Internally Apple has a different Darwin source tree than the one that has been released to the community.
This would go against what is being publicly stated by Apple in the Darwin FAQ. To quote:
Most of the projects in the Darwin repository are the same live source trees used by Apple engineers for the Mac OS X product build. This means that as we work on Mac OS X internally, the changes we make are immediately visible on the Darwin source code repository.
Now, granted that does say most, not all, however signs of an Intel port would have to show up in more that just a few of the modules. Also, it is possible that Apple is lying about this however you'd have to question why they'd risk the reputation of the company on this. Finally, if ex-apple engineers like yourself are so open to explaining that OS X works on Intel, why are all the rumour sites saying the exact opposite?
I would again have to contest this. WorldBook makes very heavy use of graphics (as does the stuff I work on) and it still managed to perform well and didn't seem to have any problems with bugs. There are bugs in almost every library and I have not found there to be any more in the Java APIs despite constantly working with the latest betas and early access releases.
I took some of my company's Java apps that ran well under Windows and tried them under OS X and they were dog slow. At one point I managed to get ProcessViewer to report CPU usage over 100%! Highlight some text in your browser - that's what it does. Two simple math coordinate checks, a couple calls to drawRect and drawChars, written about as efficiently as Java allows but with every set of mouse movements I saw the CPU usage shoot through the roof.
I would be very suspicious that when you wrote your custom class you optimised it based on your knowledge of Windows and not of Mac OS - the two graphics subsystems work very differently so your optimised code is likely to have actually been the worst possible code for OS X. If you want to benefit from Java's cross-platform abilities you actually have to use them. The API is the key to getting cross-platform compatibility because it is reviewed and optimised for each OS it is ported to. Your code doesn't have a hope of knowing as much about the system or being better optimised. I spend all day running the exact same Java application on Mac and Windows (95 and XP) and it runs the same on both at about the same speed because I take advantage of the APIs.
I know JBuilder runs fine on my machine (I suspect some Mac-specific code or vm settings) but Java isn't at all guaranteed to run well across platforms.
JBuilder is not heavily tweaked for OS X, it's just well written Java code. Poke around JBuilder's files and you'll find it doesn't do much more than a simple 'java -classpath blah com.borland.JBuilder' For the record I find Java runs perfectly fine on everything from a P100 right up to the 1.2Ghz Athlon and from a Rev B iMac (300Mhz) up to the 400Mhz G4 laptop I currently use. Perfectly fine in this case means comparable to programs written in C. Yes there's a longer launch time in most cases (again, OS X makes huge inroads into this and 1.5 will likely adopt this technology to reduce loading times and memory requirements significantly).
On Mac, it looks sweet except for text rendering.
I don't know about you, but I quite like the smooth, easy to read look that Java's text gets on OS X with it's antialiasing.
The bugs are actually probably more annoying because they are the let-downs "Oh, look it has this great gui widget" and then ten days later "Oh crap that widget has a horrible bug and I'm completely reliant on Sun to fix it
I really haven't seen that many bugs in the Java APIs that you would consider it worse than other libraries. If you are consistently having trouble with JTree then it may be worth extending the class to fix the bugs where possible (and you'd be amazed at how much you can achieve this way) or develop your own solution (as a last resort). Consider that with C/C++ you don't get *any* graphical abilities for free (all provided by 3rd party libraries which are completely platform specific etc, etc), you really aren't that badly done by if you have to implement a couple of custom widgets in Java.
When it comes down to it, the solution is to write good code. I can be pretty certain (but not 100% sure obviously) that you are not writing good *Java* code because you are so anti Java. You simply have not accepted the languages strong and weak points and so can't take advantage of the strengths. You also seem to come from a background in another language (C/C++ would be likely) and you don't seem to be willing to adapt to the "Java way" because you are hooked on the "C/C++ way" (or whatever previous language you prefer).
I apologise for any offence in the above statements, I can see from your posts that you are neither stupid nor irrational and in fact are quite intelligent with a fairly open mind. However, changing programming languages is really difficult particularly when they seem as similar as Java and C++. You have to realise that Java is only asthetically similar to C++ but is in fact based on a very different grounding principle. C++ looks for speed and efficiency at the cost of safety (buffer overflow anyone?) and platform independance, whereas Java focuses on safety and cross-platform consistency at the expense of speed (yes there is a speed penalty to be taken but in most cases it is an acceptable trade off and great gains are being made). Further to this, C++ is a procedural language which has had object oriented "stuff" added on top whereas Java was designed from the start to be object oriented (with some procedural elements).
Basically, there is nothing stopping you from developing your own API for Java but I'm pretty certain that you can't do a better job than Sun has - if it was so easy and/or the Java API is so bad, why hasn't anyone created an alternative?
Yes and no. The Cocoa APIs are an extension that is not cross-platform, however if you use the Swing libraries on OS X, by default they use native widgets. So you can write a 100% pure Java application that uses native widgets on OS X. I would expect that this kind of thing will flow back into Sun's JVM around 1.5 or so.
Go and look at WorldBook on OS X and you will also be impressed. More importantly though, noone realised it was a Java application. It looked and acted just like a C/C++ application.
Okay, I can't take this any more - Java is not slow or buggy and can produce applications that are indistinguishable from C/C++ applications. The proof of this is simple - rewind the clock back a year to MacWorld where WorldBook Encyclopedia was demoed as part of the keynote with everyone watching and they were all impressed. Months later I was informed by the "head Java dude" at Apple on his Australian tour that WorldBook is completely written in Java - but noone knew.
Most people think that Java is slow, buggy and doesn't look platform native because they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java. It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code). Sure there are some things that Java can't do that you need native code modules to handle but that facility is available.
The worst thing is that young programmers are led to think that Sun's code is actually *good* which spreads their poor, inefficient form to the next generations.
Java's not perfect, but I seriously don't think that it's Java that corrupts young programmers. You can write good code in almost any language - I see an awful lot of really bad Java code written by C programmers but I'm not about to claim that C is corrupting old programmers.
This is a feature of Java WebStart - application developers can specify a minimum JRE to use and WebStart will automatically download it when it is not already present. Note that while Web Start has just become standard with JRE1.4, it will run even on JRE 1.1 and I would imagine this clause is in the separate Java Web Start download as well.
BASIC never tried to provide cross-platform compatibility (in some cases it achieved it at the source level, but it was not the intention). Java and C# attempt to provide cross-platform compatibility so having a coherent standard instead of a great array of similar but different implentations is very important. Take the example I gave earlier of HTML - try to create a web site that looks the same in every browser and you will not be able to use anything but very basic HTML and this is with the benefit of an international standard.
By supporting embrace and extend you are supporting not following standards and yet your argument centres around the fact that C# is a standard. What is not included in a standard is just as important as what is in it - again look at HTML, Explorer started supporting invalid HTML and it has lead to an absolute mess. Same thing with BASIC in fact. Try programming in BASIC on a Commodore 64 and on a BBC Microcomputer and you will find that they are in fact quite different languages.
In this case the real winners are the programmers of five years from now when idea convergence and the natural workings of the marketplace of ideas create a better technology.
But will it actually create better technology or will it just fragment better technology between many different incompatible standards? What benefit is a cross-platform language that works differently in every implementation?
First rule of civil debate: Attack the message, not the messenger. Personally I believe that I am fully capable of making such distinctions by using a rich and approprite set of heuristic comparisons which I need not detail here. Can you accept that and choose to disagree with me solely on the basis of my ideas and opinions? If so then you are trading in that 'marketplace of ideas' I keep blathering about. Otherwise you are only trading in insult and antipathy. I have nothing to offer in exchange there
Second rule of civil debate: look for meaning not just words. Read this carefully: if your only argument for C# is that it's open and you believe that it is a better option than Java then you are obviously not capable of making an informed decision as to the merit of the programming language because if I were to create an open language that wasn't even Turing complete, your argument would show that it was better than Java when this is clearly not the case. In other words, you message is flawed - C# is not better than Java because it is open - it may or may not be better depending on what features it provides and what you are aiming to achieve.
Also (referring to part b), if you feel that Java is less open than C# then you are also mistaken as both C# and Java have publicly available specifications (Java definitely for the entire system and I will assume so for C# but note other messages stating that it is not the full spec) then I will challenge you to produce a programming language which is incompatible with C#, publicise it widely and see how long before you have a trademark infringement case (or some other legal argument) brought against you. Java is just as open as C# only that in once case the specification is reviewed by a community based organisation and the other by the EMCA. You were aware that Java is controlled by a board of people who include community members as well as Sun (and Sun does not have a controlling stake in the board) right? You were aware that you can licence the Java HotSpot engine (an actual implementation not just a specification) on the condition that you agree to some NDA agreements and that you will fold improvements back into Sun's version right?
If you want to see embrace and extend working in Java, check out what Apple is doing with Java and then take note of the fact that those improvements are being folded back into the main distribution to keep everything compatible. With C# there is no obligation that improvements be folded back into the original so you wind up with a bunch of incompatible versions and that definitely does not benefit developers or end users.
Nice to know that with a convicted monopolist inventing the technology you will always be able to pick and choose between competitors isn't it...... Oh wait, there are no reasonable competitors to MS as ruled by a court of law.
Finally, you're arguments for embrace and extend apply just as much to Java as they do to C# - you can embrace and extend but if the owner of the trademark doesn't approve you have to rename it. Java is an open standard, go to http://java.sun.com and grab a copy of the *full* specification if you desire as well as specifications for new additions that are under review. If you think that standards only work when they come from non-profit standards organisations then perhaps you should look at the mess that is HTML these days and rethink how well international standards work.
If your only argument for C# is that it's open I think you a) have no clue about how to decide upon an appropriate programming language and b) are sorely mistaken about what is open and how useful it works.
Not quite - you are learning from the code of professional programmers, not the programmers themselves. The big difference doesn't show up in your code but in your documentation, design and process skills. Initial coding is only a very minor part of the battle of creating great software, the rest is in the design and maintenance and looking at code will teach you very little about documentation requirements.
You can certainly pick up some aspects of design from code directly, but don't fool yourself into thinking you are competent at design if you have only learnt from code - it really is an artform. Probably the biggest failing of open source software is in it's documentation (ie: there is extremely little and documentation is almost always behind). I am definitely not one to support producing copious amounts of wasted paper but I am well aware of how much difference a solid design, fully planned before any code is written, can benefit productivity in the long run.
So by all means participate in open source development and learn from the code, you will learn vast amounts about code that way but don't stop there. Go out and get a degree in software engineering (or something else that focusses on design and maintenance since you already know how to code well), read as many books and white papers on software design as you can or better yet, do both (and whatever else you can find).
I know there are always people better than me, and things to learn
That's the spirit! There is some really cool stuff coming out in white papers these days both relating to code and design - keep an eye out for Genetic Software Engineering from the Software Quality Institute they're doing some really cool stuff.
Maybe if we all go out and study up on design and management (yes, yes, but it's important even in opensource) the next survey will show that open source developers are brilliant at code, design and make the best managers.... Or maybe that's pushing it.....
Does anyone else find it ironic (or possibly just stupid) that someone would try to rake in licencing fees from a video codec that is predominently used to pirate movies....
http://www.gamers.org/~quinet/lilo/breakout.html
http://www.gamers.org/~quinet/lilo/index.html