Wilson's post raises some serious questions about IE 7.0, not the least of which is this: If IE 7.0 Beta 1 doesn't include the fixes that most Web developers need, why did Microsoft release IE 7.0 Beta 1 only to a small group of Web developers and other testers, not to the general public as originally promised?
Let's see: if beta 1 does lack a lot of fixes that most Web developers need, restricting the beta to a small group of testers has a major benefit: it allows the MSIE authors to still make these fixes before web developers at large will start the effort of creating MSIE 7.0 compliant websites. If this isn't obvious, you are either too stupid or too malignant to be a software reviewer. In other words, we're wasting our time, as usual.
You must realize that for projects of this complexity, teamwork is Right Out - such a project is invariably carried out by a single genius who can overlook the entire design and implementation at once, and finds any effort to communicate with mere mortals an incredible pain. The "documentation" will be the combined work of a few bystanders who happened to catch a few words from our genius and have attempted to make sense out of them on paper. No surprise if it ends up looking like a incoherent, highly anecdotal bunch of scribblings, written in ancient Greek or worse.
This is a very nice summary of what's wrong with PHP: it's too easy to bypass security awareness. (Of course, insecure web apps can easily be written in any language, but PHP does lower the threshold to the extent where we have to assume that apps can't be trusted even when they are very popular. It's not as bad as C with its memory leaks, but close.)
Re:"Review Pictures" job would get old really fast
on
The Man Behind MySpace
·
· Score: 1
Excuse me - we, Europeans, call it "football". The phrase "you insensitive clod" comes to mind.
Read about the Crusades, in which "noble" men came to the holy land to massacre people and honestly believed that every kill was an act of redemption (as I happened to read earlier today).
The Christian church usually grows fastest when backed by those in power, e.g. when important leaders convert to Christianity (emperor Constantine, Chlodwig of France, etc.), or when Christian invaders enslave (Africa), suppress (Latin America) or annihilate (Northern America) the non-Christian population.
It's all well to take Jesus as an example, but you can't generalize from his life to how Christianity fares in general.
Testing a very simple program which just adds two 32 bit integers can take years
You're hopelessly optimistic: you assume determinism. The hard bugs are the irreproducible ones, that depend on subtle timing / synchronization issues. Or on dependencies that shouln't even be possible in the first place. Two weeks ago I was examining a program that crashes consistently unless - as it turned out after an hour of debugging - enough value has been assigned to environment variables prior to invoking it. I put an end to the crashing by assigning a very long string to an environment variable with some arbitrary name. As far as I can tell, the program in question doesn't even *use* environment variables.
If you don't want to use software that has bugs, better get out the pencil and paper.
I don't think so. Pen and paper work isn't exactly flawless, either. The automation of computation is a major leap forward.
5. Developers who aren't given training and experience in the proper use of debuggers, memory checkers, etc. (how many college hires out there really know how to use dbx to track down a bad pointer in the free list?)
That reminds me:
7. Using the wrong tool for the job, e.g. a programming language that orces you to be concerned with irrelevant nonsense (such as memory allocation issues) instead of the issues specific to your development task.
I think I'd have a lot less of a problem with the notion of intelligent design if the designer could be a sufficiently advanced product of biological evoltuion.
I still wouldn't buy it. Nothing man-made and complex was ever created by a single designer - it always evolved over time, with dozens or sometimes even thousands of designers involved, and painstaking trial-and-error testing as an essential ingredient. Only some of the one-step ideas happened in a flash (the Moebius strip is said to be one) - these are analagous to single mutations with immediate and clear phenotypical effects.
You claim they are not nonverbal, since, being symbols, they require "higher thought processes". Good point...
But are they verbal? They are not words. Their meaning is almost self-evident: understanding them only takes a bit of tilting of the head, not even that in the article. Verbal languages are characterized by the fact that their meaning is established by convention; the meaning of words and sentence constructs must be taught.
So the thought processes for smileys are somewhat higher than for direct face reading, but much lower than what is required for verbal language.
I think your conclusion is indisputable: normal social, emotional relationships can be established even when the only means of communication is the exchange of lines of ASCII text. Anyone who has been using IRC or a similar text-only environment is aware of that. The medium is not fundamentally limiting.
But I don't think this contradicts the point of the Slashdot article. It claims that e-mail is often misunderstood; e-mail messages often fail to communicate the intended emotional/social connotations. This is definitely a problem with isolated messages, especially between people who have not previously established a personal relationship. Your article rightly claims that the problem can be resolved. But that takes more than a single message.
It is about "face reading": reading a person's emotional state by looking at their face. It turns out that researchers have found over 40 specific, culture independent signs people make with their face to convey an emotional state. The signs are involuntary: people are trained at suppressing them, but the suppression only kicks in after fractions of a second.
So face movements form a universal "language" that everybody writes, and the researchers can give you a crash course if you need one.
Clearly a universal and well-established form of human communication. Many of our tiny little muscles in the face appear to have no other use than for this communication.
I don't doubt that the same could be done, or has been done, for the rest of the body.
In e-mail, all that remains of out facial movement language is the smiley! But conveying emotions is extremely important in communication: intentions depend on emotions, and communication is often about getting each other to act in a specific way. Words exist to describe emotions, of course, and situations that bring about certain emotions in the writer can be described in the hope that they will bring about the same emotions in the reader. But this takes a great deal of slowly acquired skill with words, and it will always be much slower and more indirect than use of the facial movement language we are born with.
No, I haven't seen research to prove this, but it seems obvious enough to me.
I mean, are there really people who think that it would even be possible to prevent kids from growing up without seeing porn?
As you already suggest, this may be the wrong question to ask. Th right question is: why shuld we care? Isn't 50% of all children simply not interested in seeing porn? I know I've always found it disgusting to watch. It is not something that would affect my life, since I find it ridiculous and totally not worth watching.
In short, isn't it more interesting to wonder why we should the fuck care about who is watching porn and who isn't? Aren't there far more influential experiences in life (violence, relationships among family / close friends /...) that everybody takes for granted?
28 less 28 xs 31 sudo 32 rm 35 vim 58 q 66 make 69 fg 120 ls 121 cd ~ % which xs xs: aliased to xterm -geometry 80x55 -e ssh -X !* & % which q q: aliased to exit
I'm a software developer and support guy, too. I'm Dutch. I just checked my browser history; roughly 70% of the sites I visit are American (Google, Sourceforge, Microsoft MSDN, Sun Java, W3C, Apache, etc,. etc.), I'd say about 10% is Dutch, the rest is from other countries. For womy work (software) American dominance is higher, for e.g. news or entertainment it is lower.
I always install American English versions of all software I use because most of what I read about it (e.g. when Googling for help) is in English anyway, so using a Dutch version would only be confusing. Most of what I learnt in school (and hence, most of what I want to know today) did not originate from my country. An all-Dutch Internet would be virtually useless to me.
Separating the Internet by country is just a stupid idea. A national Internet might still be useful for the US or China, but my country is just too small.
I tend to agree with these remarks but they should have been worded differently. When I used ImageMagick and PerlMagick regularly (some 5 years ago), like you I found ImageMagick lacking in user friendliness, but I feel it is the result of lacking development resources.
In essence IM is very much like similar libraries such as netpnm and GD: it has its own internal image format, a slowly-but-ever increasing range of image processing functions that operate on that format, an a slowly-but-ever range of format converters that read and writing images in various formats, sometimes by means of external executables such as Ghostscript or the netpnm utilities.
One difference with GD or netpnm is that ImageMagick doesn't separate its input filters, output filters and image manipulation functions out into separate executables. It implements them as options instead: executables such as convert and mogrify can use pretty much every input filter, output filter and image manipulation function that the library supports, by the appropriate selection of filename extensions and/or command line options. This is "not the Unix way". It is also a terrible hindrance to proper documentation: with 10 netpnm executables in a pipe that all execute a single manipulation, I know immediately what is going on by reading the man page of each of them, but when I want to combine 20 IM convert options, the convert manpage gives me very little information on how their effects will be combioned.
But a more significant difference is that the GD and netpnm authors stopped development at some point, leaving us with a finished set of utilities the exact operation of which is known. ImageMagick always felt to me like an eternal work in progress, propelled by small, incremental steps that gradually incorporate more and more image processing functionality, but with little attention to other issues. As I recall it, the interface kept growing options without ever becoming more organized. Performance was terrible and might change from version to version (but IM was always a terrible memory pig). As you mentioned, there was no real documentation (which the author was the first person to acknowledge). And the worst, as far as I'm concerned: compatibility would sometimes break; the exact syntax or semantics of options might change from verison to version, so I'd sometimes have to change my PerlMagick calls (in undocumented ways) and require specific ImageMagick versions installed in order to keep my applications going.
These are not signs of user hostility but rather of a lack of effort in user interface design. A CLI is a user interface and convert(1)s is just about the worst I've ever seen. PerlMagick's library call interface isn't much better. This is because IM just grew functionality, feature by feature, and never saw a focused design effort to present all that functionality in a way that would be maximally useful and clear to end users, let alone that it would define a clear organization for these interfaces and guarantee their compatibility. But the development effort spent on IM is very small so I don't think you can blame any one of the developers for this problem.
Not only that, trusting other people with the machine you depend on for your work requires trust. Trust is built by personal relationships - i.e. sharing lunch or at least anecdotes. The central guys, as competent as they may be, will simply be too far away from most end users.
Once the remote admin thing is in operation, and end end user can see them working on their own machine, and fixing things, the air my clear. But my feeling is that the hurdle will be too big for most users. And I certainly wouldn't want any admin to look over my shoulder when I'm unaware of it.
Yiou don't need to pay to use VB.NET at an introductory level. You don't even need to pay for an IDE: Visual Studio Express and SharpDevelop are free. (I haven't checked if MonoDevelop supports VB.NET.)
What is more, tools such as Lutz Roeder's Reflector (free) allow you to generate C#, VB.NET, Delphi and Python source code from a CLR.exe or.dll, in other words, 100% automatic translation between them.
Slashdot Mirror
No, not seriously at all.
Personally I stopped reading at this point:
Wilson's post raises some serious questions about IE 7.0, not the least of which is this: If IE 7.0 Beta 1 doesn't include the fixes that most Web developers need, why did Microsoft release IE 7.0 Beta 1 only to a small group of Web developers and other testers, not to the general public as originally promised?
Let's see: if beta 1 does lack a lot of fixes that most Web developers need, restricting the beta to a small group of testers has a major benefit: it allows the MSIE authors to still make these fixes before web developers at large will start the effort of creating MSIE 7.0 compliant websites. If this isn't obvious, you are either too stupid or too malignant to be a software reviewer. In other words, we're wasting our time, as usual.
*Yawn*
Documentation?
You must realize that for projects of this complexity, teamwork is Right Out - such a project is invariably carried out by a single genius who can overlook the entire design and implementation at once, and finds any effort to communicate with mere mortals an incredible pain. The "documentation" will be the combined work of a few bystanders who happened to catch a few words from our genius and have attempted to make sense out of them on paper. No surprise if it ends up looking like a incoherent, highly anecdotal bunch of scribblings, written in ancient Greek or worse.
This is a very nice summary of what's wrong with PHP: it's too easy to bypass security awareness.
(Of course, insecure web apps can easily be written in any language, but PHP does lower the threshold to the extent where we have to assume that apps can't be trusted even when they are very popular. It's not as bad as C with its memory leaks, but close.)
Excuse me - we, Europeans, call it "football". The phrase "you insensitive clod" comes to mind.
Read about the Crusades, in which "noble" men came to the holy land to massacre people and honestly believed that every kill was an act of redemption (as I happened to read earlier today).
The Christian church usually grows fastest when backed by those in power, e.g. when important leaders convert to Christianity (emperor Constantine, Chlodwig of France, etc.), or when Christian invaders enslave (Africa), suppress (Latin America) or annihilate (Northern America) the non-Christian population.
It's all well to take Jesus as an example, but you can't generalize from his life to how Christianity fares in general.
Philip Greenspun has answered this rather clearly, imho.
You're hopelessly optimistic: you assume determinism. The hard bugs are the irreproducible ones, that depend on subtle timing / synchronization issues. Or on dependencies that shouln't even be possible in the first place. Two weeks ago I was examining a program that crashes consistently unless - as it turned out after an hour of debugging - enough value has been assigned to environment variables prior to invoking it. I put an end to the crashing by assigning a very long string to an environment variable with some arbitrary name. As far as I can tell, the program in question doesn't even *use* environment variables.
If you don't want to use software that has bugs, better get out the pencil and paper.
I don't think so. Pen and paper work isn't exactly flawless, either. The automation of computation is a major leap forward.
That reminds me:
7. Using the wrong tool for the job, e.g. a programming language that orces you to be concerned with irrelevant nonsense (such as memory allocation issues) instead of the issues specific to your development task.
I still wouldn't buy it. Nothing man-made and complex was ever created by a single designer - it always evolved over time, with dozens or sometimes even thousands of designers involved, and painstaking trial-and-error testing as an essential ingredient. Only some of the one-step ideas happened in a flash (the Moebius strip is said to be one) - these are analagous to single mutations with immediate and clear phenotypical effects.
It's not chance, it's environmental pressure - those are the six mutations that enabled the bacteria to survive.
Am I wrong?
Now read the comment again.
Imagine somebody coming up to you, looking you in the face,
and saying:
Fortunately, nobody ever misunderstands spoken conversations.
Would you respond in the same way?
I didn't think so.
So - oh, irony - robertjw rather contradicts his own point.
I like what you say about emoticons.
...
You claim they are not nonverbal, since, being symbols,
they require "higher thought processes". Good point
But are they verbal? They are not words. Their meaning is almost
self-evident: understanding them only takes a bit of tilting of the head,
not even that in the article. Verbal languages are characterized by
the fact that their meaning is established by convention;
the meaning of words and sentence constructs must be taught.
So the thought processes for smileys are somewhat higher than for
direct face reading, but much lower than what is required for verbal language.
I think your conclusion is indisputable: normal social, emotional relationships
can be established even when the only means of communication is the exchange
of lines of ASCII text. Anyone who has been using IRC or a similar text-only
environment is aware of that. The medium is not fundamentally limiting.
But I don't think this contradicts the point of the Slashdot article.
It claims that e-mail is often misunderstood; e-mail messages
often fail to communicate the intended emotional/social connotations.
This is definitely a problem with isolated messages, especially between
people who have not previously established a personal relationship.
Your article rightly claims that the problem can be resolved.
But that takes more than a single message.
The other week I was pointed to a fascinating article about nonverbal communication,
m
written for the New Yorker by Malcolm Gladwell:
http://www.gladwell.com/2002/2002_08_05_a_face.ht
It is about "face reading": reading a person's emotional state by looking at their face.
It turns out that researchers have found over 40 specific, culture independent signs
people make with their face to convey an emotional state. The signs are involuntary:
people are trained at suppressing them, but the suppression only kicks in after
fractions of a second.
So face movements form a universal "language" that everybody writes,
and the researchers can give you a crash course if you need one.
Clearly a universal and well-established form of human communication.
Many of our tiny little muscles in the face appear to have no other use than
for this communication.
I don't doubt that the same could be done, or has been done, for the rest of the body.
In e-mail, all that remains of out facial movement language is the smiley!
But conveying emotions is extremely important in communication: intentions
depend on emotions, and communication is often about getting each other to
act in a specific way. Words exist to describe emotions, of course, and situations
that bring about certain emotions in the writer can be described in the hope
that they will bring about the same emotions in the reader. But this takes a great
deal of slowly acquired skill with words, and it will always be much slower and
more indirect than use of the facial movement language we are born with.
No, I haven't seen research to prove this, but it seems obvious enough to me.
Microsoft have included object-based scripting for a long time (the Wi ndows Scripting Host).
d e/sas_wsh_qlcc.mspx?mfr=true
.NET-based scripting shell.
http://www.microsoft.com/technet/scriptcenter/gui
But it's pre-.NET (you can do COM with it for instance).
I don't know if they also provide a
I mean, are there really people who think that it would even be possible to prevent kids from growing up without seeing porn?
...) that everybody takes for granted?
As you already suggest, this may be the wrong question to ask. Th right question is: why shuld we care? Isn't 50% of all children simply not interested in seeing porn? I know I've always found it disgusting to watch. It is not something that would affect my life, since I find it ridiculous and totally not worth watching.
In short, isn't it more interesting to wonder why we should the fuck care about who is watching porn and who isn't? Aren't there far more influential experiences in life (violence, relationships among family / close friends /
28 less
28 xs
31 sudo
32 rm
35 vim
58 q
66 make
69 fg
120 ls
121 cd
~ % which xs
xs: aliased to xterm -geometry 80x55 -e ssh -X !* &
% which q
q: aliased to exit
I'm a software developer and support guy, too. I'm Dutch. I just checked my browser history;
roughly 70% of the sites I visit are American (Google, Sourceforge, Microsoft MSDN, Sun Java, W3C, Apache, etc,. etc.), I'd say about 10% is Dutch, the rest is from other countries. For womy work (software) American dominance is higher, for e.g. news or entertainment it is lower.
I always install American English versions of all software I use because most of what I read about it (e.g. when Googling for help) is in English anyway, so using a Dutch version would only be confusing. Most of what I learnt in school (and hence, most of what I want to know today) did not originate from my country. An all-Dutch Internet would be virtually useless to me.
Separating the Internet by country is just a stupid idea. A national Internet might still be useful for the US or China, but my country is just too small.
s/Jordanians and Syrians/Americans/
I tend to agree with these remarks but they should have been worded differently.
When I used ImageMagick and PerlMagick regularly (some 5 years ago), like you I found
ImageMagick lacking in user friendliness, but I feel it is the result of lacking development resources.
In essence IM is very much like similar libraries such as netpnm and GD: it has its own internal image format,
a slowly-but-ever increasing range of image processing functions that operate on that format,
an a slowly-but-ever range of format converters that read and writing images in various formats,
sometimes by means of external executables such as Ghostscript or the netpnm utilities.
One difference with GD or netpnm is that ImageMagick doesn't separate its input filters, output filters
and image manipulation functions out into separate executables. It implements them as options instead:
executables such as convert and mogrify can use pretty much every input filter, output filter and image
manipulation function that the library supports, by the appropriate selection of filename extensions
and/or command line options. This is "not the Unix way". It is also a terrible hindrance to proper
documentation: with 10 netpnm executables in a pipe that all execute a single manipulation, I know
immediately what is going on by reading the man page of each of them, but when I want to combine 20
IM convert options, the convert manpage gives me very little information on how their effects will be combioned.
But a more significant difference is that the GD and netpnm authors stopped development at some point,
leaving us with a finished set of utilities the exact operation of which is known.
ImageMagick always felt to me like an eternal work in progress, propelled by small, incremental steps
that gradually incorporate more and more image processing functionality, but with little attention to other issues.
As I recall it, the interface kept growing options without ever becoming more organized.
Performance was terrible and might change from version to version (but IM was always a terrible memory pig).
As you mentioned, there was no real documentation (which the author was the first person to acknowledge).
And the worst, as far as I'm concerned: compatibility would sometimes break; the exact syntax or semantics of options
might change from verison to version, so I'd sometimes have to change my PerlMagick calls (in undocumented ways) and
require specific ImageMagick versions installed in order to keep my applications going.
These are not signs of user hostility but rather of a lack of effort in user interface design. A CLI is a user interface
and convert(1)s is just about the worst I've ever seen. PerlMagick's library call interface isn't much better. This is because
IM just grew functionality, feature by feature, and never saw a focused design effort to present all that functionality
in a way that would be maximally useful and clear to end users, let alone that it would define a clear organization for
these interfaces and guarantee their compatibility. But the development effort spent on IM is very small so I don't think
you can blame any one of the developers for this problem.
Not only that, trusting other people with the machine you depend on for your work requires trust.
Trust is built by personal relationships - i.e. sharing lunch or at least anecdotes. The central guys,
as competent as they may be, will simply be too far away from most end users.
Once the remote admin thing is in operation, and end end user can see them working on their own
machine, and fixing things, the air my clear. But my feeling is that the hurdle will be too big for most users.
And I certainly wouldn't want any admin to look over my shoulder when I'm unaware of it.
Yiou don't need to pay to use VB.NET at an introductory level. You don't even need to pay for an IDE: Visual Studio Express and SharpDevelop are free. (I haven't checked if MonoDevelop supports VB.NET.)
VB.NET:
You're misinformed. Unlike Perl, VB.NET has an option to enforce strong typing.
What is more, tools such as Lutz Roeder's Reflector (free) allow you to generate C#, VB.NET, Delphi and Python source code from a CLR .exe or .dll, in other words, 100% automatic translation between them.