The presenter, a filmmaking friend of Conran's, closed the screening with a joke about Pete Townshend meeting Eric Clapton in a London bar and commiserating about some new kid named Hendrix, "who's gonna kick our asses."
As far as I know, Hendrix died long ago, while both Townsend and Clapton are alive and kicking.
However, if you're writing a GUI application, the APIs are totally different.
if you can live with java and swing, it's not that difficult to write applications that for the most part feel like native Mac OS X applications and still run without modifications on other platform.
some guy wrote an article (pdf) how to basically do it. apple's MRJ toolkit is a pain, but fortunately there also is MRJ Adapter.
sure, you have to learn the structure of application bundles and how to write in an Info.plist. still, you can stay away from xcode and cocoa without much trouble.
A bunch of "visionaries" who see that we've used this same model for some time and therefore are convinced it is horribly limiting[...]. They never have any but the most vague suggestions of a better model. They certainly never take the time to explore its limitations longer to ensure it really is workable (much less actually an improvement).
i don't know about the others, but at least jef raskin guides some coders into implementing the humane environment (THE). so far, it is an open source pything editor thingy, so it actually has some practical use.
nevertheless keep the warning from the homepage in mind:
Important observation: You cannot make an interface better without making it different (that's obvious). If it's a lot better, it will be a lot different. This means that it will feel unfamiliar to anybody familiar with present interfaces. Therefore, it has to be used for a while (after you read the manual) before you unlearn your present habits and can begin to appreciate it. You are in a worse position for learning it than a novice who has only to acquire new habits and has nothing to unlearn!
personelly, i haven't figured it out, and rarely use python. still i think that it adds a lot of credibility to raskin's claims.
I think you are forgetting something though... C and C++ are the most powerful higher level languages [blah blah...]
Back in college I would defend C/C++ against [blah blah...]
A hammer cannot only be used to drive in nails [blah blah...]
<rant>
you know, 10 years ago, there were a lot of people like this. and they made my live pretty bad because i somehow had to arrange with them, and use the same sucky languages and tools.
nowadays, live isn't perferct. however, its easy to find a job where java is the lowest-level language (that is, if you find a job). the mainstream languages and tools are catching up to advanced (underground) stuff like eiffel. idiotic problems like bounds checking, missing i/o error handling etc are a thing of the past - even for the mainstream. systematic testing is becoming more and more of a must, and companies get more disciplined about QA. sure, java's exceptions handling is imature, the syntax as ugly as ever, and assertions are a joke. but it's way better than the whole C and C++ macho stuff.
and most important, people like the parent poster are collected in zoo, maybe doing some embedded systems, far out of my sight. i sometimes read about them, but i never actually see them anymore.
maybe the guy really is from PR and doesn't know how to carefully phrase sentences targeted at a technical audience, but these also hit my eye:
"It was recognized just after [the June 2003] launch that there were some serious shortcomings in the code that had been put into the launch load of software," said JPL data management engineer Roger Klemm.
i know this is common within the software industry, but if this happens on such a project, it looks like plain incompetence to me.
Klemm said that with the leftover directories and their files removed, the system is now functioning well. But just in case, the team is working on an exception-handler routine that will more gracefully recover from an allocation failure.
allocation errors are the easiest to predict. even if you don't handle them gracefully (which often can be near to impossible), most of the time you can log them. of course, a reliable, redundant log facility is one the most crucial components of such a system...
writting this from my armchair, of course i can't really judge their competence and claim i could have done better. still, the article makes me suspicious.
Seriously though, the key lessons to take away from this are.
1) Gather all of the clues you can.
2) Take those clues and build a model.
you forgot this one:
0) predict failure scenarious in the design phase, think them through, and design accordingly.
when you read the article, you will notice that a lot of plans and tools already existed that allowed them to trace the problem. this is one of the major difference between armchair coding and reliabilty engineering.
Sun's insistence on continuing tight control of the Java code has damaged Sun's long-term interests by throttling acceptance of the language in the open-source community, ceding the field (and probably the future) to scripting-language competitors like Python and Perl.
looks like ESR is confusing java with javascript. bear with him, it's a common mistake.
If they didn't even test their website with the most common Mac browser, then I wonder how well QA-ed their Mac port is.
eiffel uses "design by contract", which is a very powerful concept to avoid bugs or at least find them quickly at runtime. my impression always has been that because of this, eiffel developers hardly perform any additional quality assurance measures.
one of the stories that destroyed eiffel's reputation for years (decades?) was how very early compilers treated hello world: it compiled for minutes, produced an executable that was 2MB of size and crahsed when executed. now, this has long been fixed, but people keep telling it over and over.
it almost reminds me of those computer science lectures where one proves that a program is correct, and then walks home without ever implementing and executing it.
concerning ugly colors and waste of bandwidth, slashdot already has a decent solution for that: go to your user page, click "preferences", go to "Customize Slashdot's Display" and enable "Light (reduce the complexity of Slashdot's HTML for AvantGo, Lynx, or slow connections)".
i really support the retooling, but until then, i stick to "light display".
they should call it "freedom fries" to
indicate that the cluster can compute stuff that
will prevent terrorist attacks. that will give them
a lot of funding.
these are some (quite) old papers that didn't change the world, but at least influenced my thinking a lot:
the humble programmer (1972; dijkstra, e.w.; communications of the acm, vol. 15 (10), 859-866)
cool stuff. read it. it's not really technical.
learning by doing with simulated intelligent help (1988; carroll, j.m. & aaronson, a.p., communications of the acm. vol. 31(9), 1064-1079)
this is interesting because back then they already collected a lot of evidence why crap like
clippy is not going to work. it's also one of the rare examples of a paper where researches
explain why their great idea isn't so great after all.
the errors of tex (1989; knuth, d.e., software practice and experience, vol. 19(7), 607-685)
it's a classification of the various bugs in tex. nice to know that people smarter than me
make the same mistakes.
exception handling: issues and a proposed notation (1975; goodenough, j.b.; communications of the acm, vol. 18 (12), 683ff)
if there are still people around who thing the try/throw/catch thingy was invented by C++;
unfortunately it's difficult to read
the trouble with unix: the user interface is horrid (norman, d.a.; datamaton)
i can't find my dead-tree-copy right now. there seems to be an
online version,
but it lacks the rebutal by some unix dude, which AFAIR is printed in datamaton.
there are mostly 2 things intersting about this: first, this is the same norman that
moved on to be a founding member of the usability genre ("design of everyday things"
and stuff). second, while most of the problems pointed out in the article have been
fixed by now, the same kind of design mistakes are made over and on again by the unix
comunity still today.
my favourite part: norman points out that unix doesn't produce error messages. the unix
dude replies that's ok because if it would, it could break all the programs that expect
the output to match a certain pattern. (years later, someone smarter than him invented stderr.)
mathematics of programming (1986; hoare, c.a.r; byte august 1986, 115ff)
this is a horrible paper. i never managed to read it to the end. however it is interesting insofar
as that it's quite obvious why nobody reads this kind of papers. basically, it full of selfsatiesfied
mathematical brainwanking and shoulderpadding. so IMO its main point is to show why
developers and mathematicians are not working together anymore (like they did until the 70ties)
The screenshot you posted is terrible, take a look at the JuK screenshot
here. Looks
much nicer doesn it?
yeah, i can see it now! just don't have any music tracks, and the interface is a lot
less cluttered. why didn't we think of that before? it so obvious!
</sarcasm>
As far as I can tell, why just interpreted the
errorlevel.
actually, amiga programs have 2 exit codes: a general one roughly indicting about the
exit state (0=ok, 5=warn, 10=error, 20=major problem), and a detailed one containing the
amiga equivalent to unix' errno. the why command basically
translates the datailed error code into a string constant, comparable to unix'
strerror().
in practice, why is pretty useless. for example, it tells you that it
could not open a file, but never tells you the name of it (because the name naturally
is not part of the string contant why uses).
(for details, see struct Process.pr_Result2 and the autodocs on
Fault() and SetIoErr().)
By the way [the Nike logo] fits its "Just Do It" slogan perfectly. The mozilla lizard and Linux
penguin don't have the same advantages as the Nike logo.
i dis-disagree! the linux penguin is a near-perfect representation
of its target group: massive guts, balding head, and the same
dazed look like a programmer thinking about a particular difficult
problem to solve.
Reverse Murphy's Law:
"Things never go as bad as they could have."
Tyler Durden: It could be worse. A woman could cut off your penis while you're sleeping
and toss it out the window of a moving car. Narrator: There's always that.
Personally, I don't trust anyone with automatic updates.
neither do i. but the semi-automatic update tools like in mac os x are also no solution.
one feature i'm wishing for is a "delayed update": the os-vendor should make updates available as soon as possible, but i as a user might choose to "see" them only after, say, 2 weeks.
take for instance, mac os x: in the past 2 years, apple has released buggy updates that
accidentally formatted your harddisk (under certain circumstances, and only if you had 2 of them)
deleted your email (only if german was set as preferred language)
destroyed your ibook battery (which was kinda cool if you got a replacemend 2 months before the guarantee ended).
the only one that effected me was the battery-killer, but still, that's a kinda scary history.
Slashdot Mirror
The presenter, a filmmaking friend of Conran's, closed the screening with a joke about Pete Townshend meeting Eric Clapton in a London bar and commiserating about some new kid named Hendrix, "who's gonna kick our asses."
As far as I know, Hendrix died long ago, while both Townsend and Clapton are alive and kicking.
Now who kicked some ass?
Commodore for killing the Amiga.
Works for me.while most articles are german, there is an english edition.
topics include information society, privacy, computer games, influence of american politics on europa, technological advances and so on.
however, beware of the wide range of article quality. most authors are freelances. some obviously suck, but they are easy to identify.
soon i can install mac os x on my mighty pizza box mac with its powerful 68040 cpu. hah, apple! me not gonna buy new hardware!
if you can live with java and swing, it's not that difficult to write applications that for the most part feel like native Mac OS X applications and still run without modifications on other platform.
some guy wrote an article (pdf) how to basically do it. apple's MRJ toolkit is a pain, but fortunately there also is MRJ Adapter.
sure, you have to learn the structure of application bundles and how to write in an Info.plist. still, you can stay away from xcode and cocoa without much trouble.
i don't know about the others, but at least jef raskin guides some coders into implementing the humane environment (THE). so far, it is an open source pything editor thingy, so it actually has some practical use.
nevertheless keep the warning from the homepage in mind:
personelly, i haven't figured it out, and rarely use python. still i think that it adds a lot of credibility to raskin's claims.
I think you are forgetting something though... C and C++ are the most powerful higher level languages [blah blah...]
Back in college I would defend C/C++ against [blah blah...]
A hammer cannot only be used to drive in nails [blah blah...]
<rant>
you know, 10 years ago, there were a lot of people like this. and they made my live pretty bad because i somehow had to arrange with them, and use the same sucky languages and tools.nowadays, live isn't perferct. however, its easy to find a job where java is the lowest-level language (that is, if you find a job). the mainstream languages and tools are catching up to advanced (underground) stuff like eiffel. idiotic problems like bounds checking, missing i/o error handling etc are a thing of the past - even for the mainstream. systematic testing is becoming more and more of a must, and companies get more disciplined about QA. sure, java's exceptions handling is imature, the syntax as ugly as ever, and assertions are a joke. but it's way better than the whole C and C++ macho stuff.
and most important, people like the parent poster are collected in zoo, maybe doing some embedded systems, far out of my sight. i sometimes read about them, but i never actually see them anymore.
sometimes life is good.
</rant>
allocation errors are the easiest to predict. even if you don't handle them gracefully (which often can be near to impossible), most of the time you can log them. of course, a reliable, redundant log facility is one the most crucial components of such a system...
writting this from my armchair, of course i can't really judge their competence and claim i could have done better. still, the article makes me suspicious.0) predict failure scenarious in the design phase, think them through, and design accordingly.
when you read the article, you will notice that a lot of plans and tools already existed that allowed them to trace the problem. this is one of the major difference between armchair coding and reliabilty engineering.
they will. but it won't be the same women, it it won't be for the same price.
If they didn't even test their website with the most common Mac browser, then I wonder how well QA-ed their Mac port is.
eiffel uses "design by contract", which is a very powerful concept to avoid bugs or at least find them quickly at runtime. my impression always has been that because of this, eiffel developers hardly perform any additional quality assurance measures.one of the stories that destroyed eiffel's reputation for years (decades?) was how very early compilers treated hello world: it compiled for minutes, produced an executable that was 2MB of size and crahsed when executed. now, this has long been fixed, but people keep telling it over and over.
it almost reminds me of those computer science lectures where one proves that a program is correct, and then walks home without ever implementing and executing it.At one point, Amazon was actually offering a discount if you bought Doom 3 together with Half-Life 2, which I thought was pretty amusing.
even better, amazon already has almost 50 customer reviews of doom 3. (4.5 stars out of 5.)i'm a happy g5 user, but the apple laptops just suck right now.
btw, what happened to the protests of frustrated owners of broken ibooks? did they show up somewhere at the expo?concerning ugly colors and waste of bandwidth, slashdot already has a decent solution for that: go to your user page, click "preferences", go to "Customize Slashdot's Display" and enable "Light (reduce the complexity of Slashdot's HTML for AvantGo, Lynx, or slow connections)".
i really support the retooling, but until then, i stick to "light display".they should call it "freedom fries" to indicate that the cluster can compute stuff that will prevent terrorist attacks. that will give them a lot of funding.
cool stuff. read it. it's not really technical.
this is interesting because back then they already collected a lot of evidence why crap like clippy is not going to work. it's also one of the rare examples of a paper where researches explain why their great idea isn't so great after all.
it's a classification of the various bugs in tex. nice to know that people smarter than me make the same mistakes.
if there are still people around who thing the try/throw/catch thingy was invented by C++; unfortunately it's difficult to read
i can't find my dead-tree-copy right now. there seems to be an online version, but it lacks the rebutal by some unix dude, which AFAIR is printed in datamaton. there are mostly 2 things intersting about this: first, this is the same norman that moved on to be a founding member of the usability genre ("design of everyday things" and stuff). second, while most of the problems pointed out in the article have been fixed by now, the same kind of design mistakes are made over and on again by the unix comunity still today.
my favourite part: norman points out that unix doesn't produce error messages. the unix dude replies that's ok because if it would, it could break all the programs that expect the output to match a certain pattern. (years later, someone smarter than him invented stderr.)
this is a horrible paper. i never managed to read it to the end. however it is interesting insofar as that it's quite obvious why nobody reads this kind of papers. basically, it full of selfsatiesfied mathematical brainwanking and shoulderpadding. so IMO its main point is to show why developers and mathematicians are not working together anymore (like they did until the 70ties)
in practice, why is pretty useless. for example, it tells you that it could not open a file, but never tells you the name of it (because the name naturally is not part of the string contant why uses).
(for details, see struct Process.pr_Result2 and the autodocs on Fault() and SetIoErr().)
(kick me, that was nasty.)
Narrator: There's always that.
once again, there's a simple solution to that: sneakemail.
of course, your sneakemail address in WHOIS will be spammed to death eventually, but if you create a new one every year, the damage is quite limited.
take for instance, mac os x: in the past 2 years, apple has released buggy updates that
- accidentally formatted your harddisk (under certain circumstances, and only if you had 2 of them)
- deleted your email (only if german was set as preferred language)
- destroyed your ibook battery (which was kinda cool if you got a replacemend 2 months before the guarantee ended).
the only one that effected me was the battery-killer, but still, that's a kinda scary history.