It's a common misconception that us mac users use black dildos. We mac users actually use iDildo's, which have attractive titanium-covered finish and play mp3's that you can download for 99 cents from Apple.
We also write Applescript for our iDildos, such as
tell application "dildo"
vibrate end tell
While PC users tend to make fun of us for not using more conservative beige-colored dildos, we smile and think nothing of it as we watch them fiddle for hours on end just trying to get their dildos to work.
Join us all and share the horror
on
Open Source Music
·
· Score: 2, Interesting
It kind of sounds like
this, but there's less emphasis on the listener's freedom and more acceptance of commercial involvement.
One fault I find with the author's assessment is that he is evaluating the language only from the standpoint of the one who is writing in it. I think a better language assessment would also evaluate a language from the viewpoint of the poor bastard who actually has to read someone else's code written in that langage. Does the language have the tendency to produce code that is readable and understandable by the person who didn't write it? Or does the language have the tendency to produce code that is readable/understandable by only its original author?
For example, Perl allows the programmer who writes a perl program try to make their code as terse and unreadable as possible, fitting everything on one line by exploiting some bizarre behavior of the perl interpreter. While this "expressiveness" might be wonderful to the person who's writing the code, it's really going to be a problem for a second person who might want to contribute to it or maintain the project after the original author threw in the towel or got hit by a bus.
Another example is operator overloading. Perhaps operator overloading is useful to the first person writing the code, as it provides a nice little shortcut where they can do foo + bar as opposed to something like foo.add(bar). But if there's another person who's decided to work on this project, and they're not very familiar with the code and they are trying to get the idea of how it works, how can they tell whether foo+bar is a mathematical operation or some sort of concatenation? Yes, if they look over the code enough, they can understand it. But perhaps that extra amount of fuss and the extra amount of time wasted trying to make sense of things will convince that person it would be easier to write their own stuff than try to reuse someone else's.
A final area I wish the author focused on is documentation. Does the language support some sort of embedded and standardized documentation that make it easier for the first programmer to provide information that would help a second programmer make sense of the code, or is documentation at the discretion and mercy of the first programmer and whatever bizarre and non-standard documentation system they might use?
I would suspect that projects using languages that make it harder on the person who has to read the code have higher incidences of duplication of effort and a great NIH (Not Invented Here) tendency.
The big ideas are in the brains of HCI researchers who can't program (because they spend most of their time doing research), and the people with the linux programming ability are a bunch of traditionalist unix geeks who think that HCI is a load of BS and who don't want to listen to some 'GUI expert' telling them how to program.
For Linux UI innovation to succeed, it is first necessary to get rid of the 30 years of unix culture that has been holding it back.
In honor of Lord Vader's contributions to the Washington National Cathedral, he will be remembered as Saint Anakin, who performed the miracle of telepathetically choking sinners.
They are actually adding a feature called "e-mail backwarding". It's like e-mail forwarding, only the complete opposite. Instead of being limited to sending the message to anyone, you now have the full ability to send the message to no one.
Once you learn the quirky syntax of ODRL this will all make sense.
Linux and Apache were things designed for the server.
The server is not the desktop. A methodology that works on the server doesn't nessarily work on the desktop.
Bruce, stop targeting the desktop and governments
on
Too Much Free Software
·
· Score: 1
If the attitude of Free Software developers towards end user issues will be "quit whining about what you are getting for free" or "Free Software does not entitle you usable interface", then those people need to stop whining about why Free Software isn't used in governments and to quit feeling entitled to Aunt Tilly's desktop.
The problem with you people is that your entire strategy for approaching everything came from what you did on the server, and you stupidly think that server methods of development are going to equally apply equally to an entirely difference set of users with an entirely different set of design constraints and an entirely different definition of what "failure" really is. Looking at applications and UI's as individual little parcels that can be mixed around and changed, no matter how different they look or act, just doesn't work on the desktop. Most UI people understand this, most programmers don't, or rather, don't want to no matter how many times they are told. Sometimes I think that Free Software was never really a bazaar, but a cathedral where programmer arrogance and ignorance are worshipped.
And in regards to the window/manger desktop issue, while they're technically different beasts, from the end-user's standpoint, they're the same damn thing. And if the user can tell the difference, someone's not done their job of integrating stuff. It is so painfully clear that the people who are the leaders (if you can say OSS/Free Software has leaders) have absolutely no understanding at all of any aspect of designing user interfaces and this has dearly cost efforts to produce an open(and better) alternative to Microsoft Windows.
Again, if the goal of Free Software is not replacing Microsoft Windows, that's all well and good. Just please stop targeting Grandma and quit complaining about Microsoft's monopoly.
They need the faster chips to support the next generation of pornography. Once you view 64-bit porn, you'll wonder how you ever got by with the 32-bit variety.
The UI for the zaurus is very badly designed. The people at Trolltech really didn't think about many of the human factors issues involved in hand-held computing. The result feels like a full-size desktop PC interface artificially shrunkend into a 3x5" mobile device.
Contrast this with palm, where things like minimizing the number of taps needed to perform a task was actually taken into consideration.
While I find writing GUI apps in python and running them on the Zaurus cool and useful for specific applications, I would absolutely never use it for a PDA in situations where I had only 10 seconds to get down a cute girl's phone number.
For the first several weeks of python coding, the use of whitespace bothered me, and then I got used to it.
I fully switched from Perl to python when I realized that all the Perl programmers who try to make all their stuff fit on one line and who pride themselves on showing off their knowledge of Perl's terse syntaxes and weird implicit behavior at the expense of other people who try to understand their code bothered me far, far more.
If you're extremely patriotic, collect all the cow shit you can and store it in your back yard. You too can help reduce America's dependency on foreign oil.
Of course, it depends whether you count IIS as a breaking and entering tool.
I still can't get ndc (name daemon control, bind) to work on OSX, though named runs just fine.
In other words, due to a lack of control you can't be master of your domain.
Don't worry. Happens to most guys.
It's a common misconception that us mac users use black dildos. We mac users actually use iDildo's, which have attractive titanium-covered finish and play mp3's that you can download for 99 cents from Apple.
We also write Applescript for our iDildos, such as
tell application "dildo"
vibrate
end tell
While PC users tend to make fun of us for not using more conservative beige-colored dildos, we smile and think nothing of it as we watch them fiddle for hours on end just trying to get their dildos to work.
It kind of sounds like this, but there's less emphasis on the listener's freedom and more acceptance of commercial involvement.
And to think all this time I've been deleting those "Hot Lesbian Witches Are Waiting For You!" messages from my e-mail account.
What was I thinking?!??
KDE would never implement Clippy.
The would implement Klippy.
It's nothing more than a smear campaign by Ming the Merciless designed to break up the alliance with the Hawkmen.
Jeez, you people shouldn't believe everything you read on an internet rumors site.
One fault I find with the author's assessment is that he is evaluating the language only from the standpoint of the one who is writing in it. I think a better language assessment would also evaluate a language from the viewpoint of the poor bastard who actually has to read someone else's code written in that langage. Does the language have the tendency to produce code that is readable and understandable by the person who didn't write it? Or does the language have the tendency to produce code that is readable/understandable by only its original author?
For example, Perl allows the programmer who writes a perl program try to make their code as terse and unreadable as possible, fitting everything on one line by exploiting some bizarre behavior of the perl interpreter. While this "expressiveness" might be wonderful to the person who's writing the code, it's really going to be a problem for a second person who might want to contribute to it or maintain the project after the original author threw in the towel or got hit by a bus.
Another example is operator overloading. Perhaps operator overloading is useful to the first person writing the code, as it provides a nice little shortcut where they can do foo + bar as opposed to something like foo.add(bar). But if there's another person who's decided to work on this project, and they're not very familiar with the code and they are trying to get the idea of how it works, how can they tell whether foo+bar is a mathematical operation or some sort of concatenation? Yes, if they look over the code enough, they can understand it. But perhaps that extra amount of fuss and the extra amount of time wasted trying to make sense of things will convince that person it would be easier to write their own stuff than try to reuse someone else's.
A final area I wish the author focused on is documentation. Does the language support some sort of embedded and standardized documentation that make it easier for the first programmer to provide information that would help a second programmer make sense of the code, or is documentation at the discretion and mercy of the first programmer and whatever bizarre and non-standard documentation system they might use?
I would suspect that projects using languages that make it harder on the person who has to read the code have higher incidences of duplication of effort and a great NIH (Not Invented Here) tendency.
But that's just my opinion.
The big ideas are in the brains of HCI researchers who can't program (because they spend most of their time doing research), and the people with the linux programming ability are a bunch of traditionalist unix geeks who think that HCI is a load of BS and who don't want to listen to some 'GUI expert' telling them how to program.
For Linux UI innovation to succeed, it is first necessary to get rid of the 30 years of unix culture that has been holding it back.
It's probably best to keep the squeaky koosh toys away from the Klingon-speaking patients.
One picture is worth a thousand words.
Literally.
Every time I've run a firewall on my nokia, it becomes totally unusable for calling people. But then again, I do get fewer telemarketers.
In honor of Lord Vader's contributions to the Washington National Cathedral, he will be remembered as Saint Anakin, who performed the miracle of telepathetically choking sinners.
They are actually adding a feature called "e-mail backwarding". It's like e-mail forwarding, only the complete opposite. Instead of being limited to sending the message to anyone, you now have the full ability to send the message to no one.
Once you learn the quirky syntax of ODRL this will all make sense.
I have to wonder how they expect to have legacy-free machines while there are still people running around with huge phallic vibrating instruments?
Easy. Throw out serial or ps/2 dildo. Replace with firewire or usb dildo.
Linux and Apache were things designed for the server.
The server is not the desktop. A methodology that works on the server doesn't nessarily work on the desktop.
If the attitude of Free Software developers towards end user issues will be "quit whining about what you are getting for free" or "Free Software does not entitle you usable interface", then those people need to stop whining about why Free Software isn't used in governments and to quit feeling entitled to Aunt Tilly's desktop.
The problem with you people is that your entire strategy for approaching everything came from what you did on the server, and you stupidly think that server methods of development are going to equally apply equally to an entirely difference set of users with an entirely different set of design constraints and an entirely different definition of what "failure" really is. Looking at applications and UI's as individual little parcels that can be mixed around and changed, no matter how different they look or act, just doesn't work on the desktop. Most UI people understand this, most programmers don't, or rather, don't want to no matter how many times they are told. Sometimes I think that Free Software was never really a bazaar, but a cathedral where programmer arrogance and ignorance are worshipped.
And in regards to the window/manger desktop issue, while they're technically different beasts, from the end-user's standpoint, they're the same damn thing. And if the user can tell the difference, someone's not done their job of integrating stuff. It is so painfully clear that the people who are the leaders (if you can say OSS/Free Software has leaders) have absolutely no understanding at all of any aspect of designing user interfaces and this has dearly cost efforts to produce an open(and better) alternative to Microsoft Windows.
Again, if the goal of Free Software is not replacing Microsoft Windows, that's all well and good. Just please stop targeting Grandma and quit complaining about Microsoft's monopoly.
Or perhaps the GUI is the right thing to use, and we have the we have the wrong people developing GUI's.
Don't believe that bullshit "fried chicken" story for a second. Their secret blend of eleven herbs and spices is really a recipe for mustard gas.
They need the faster chips to support the next generation of pornography. Once you view 64-bit porn, you'll wonder how you ever got by with the 32-bit variety.
You squeeze the glowing cyber balls and your computer elicits a coughing sound.
The UI for the zaurus is very badly designed. The people at Trolltech really didn't think about many of the human factors issues involved in hand-held computing. The result feels like a full-size desktop PC interface artificially shrunkend into a 3x5" mobile device.
Contrast this with palm, where things like minimizing the number of taps needed to perform a task was actually taken into consideration.
While I find writing GUI apps in python and running them on the Zaurus cool and useful for specific applications, I would absolutely never use it for a PDA in situations where I had only 10 seconds to get down a cute girl's phone number.
I bet that there must be a surface structure under those spots.
Most likely it's a gigantic cloud city run by Billy Dee Williams.
It was the same case for me.
For the first several weeks of python coding, the use of whitespace bothered me, and then I got used to it.
I fully switched from Perl to python when I realized that all the Perl programmers who try to make all their stuff fit on one line and who pride themselves on showing off their knowledge of Perl's terse syntaxes and weird implicit behavior at the expense of other people who try to understand their code bothered me far, far more.
If you're extremely patriotic, collect all the cow shit you can and store it in your back yard. You too can help reduce America's dependency on foreign oil.