[Israel.pm] [OT] Joel on us

Issac Goldstand margol at beamartyr.net
Mon Dec 6 07:02:17 PST 2004

----- Original Message ----- 
From: "Offer Kaye" <offer.kaye at gmail.com>
To: "Perl in Israel" <perl at perl.org.il>
Cc: <spolsky at fogcreek.com>
Sent: Monday, December 06, 2004 3:01 PM
Subject: Re: [Israel.pm] Joel on us

> On Mon, 6 Dec 2004 14:20:22 +0200, Gaal Yahas wrote:
>> >
>> > http://www.joelonsoftware.com/items/2004/12/04.html
>> The Sapir-Whorf hypothesis
> Obligatory link:
> http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis
>> And this
>> short article has absolutely nothing in the way of evidence for the
>> declaration it makes.
> Not only that, I'm not even sure Joel is right. I would translate
> /Davka/ as "Because!". In fact, AFAIK young people in the U.S. use
> "because" in exactly the same sense (and tone of voice!) as Israelis
> do. Perhaps it is less prevalent, but it is still there.

I would say "just because"...

> As for /Rosh Gadol/ - what's wrong with the word "initiative"? E.g.:
> "All I wanted to say was that methodologies encourage ראש קטן and I
> need everyone on my team to be ראש גדול."
> "All I wanted to say was that methodologies encourage a lack of
> initiative and I need everyone on my team to have initiative."

Um.. Open minded/closed minded?  He's right - there isn't a perfect example, 
but initiative is a symtpom of rosh gadol.  It's the general open-mindedness 
which better defines it.   Unfortunately, the translation loses its "umph":
"All I wanted to say was that methodologies encourage close-mindedness and I 
need everyone on my team to be open-minded."

/me goes into .NET sucks mode
In any case, the point he makes in the next paragraph is pretty straight on. 
I'm occasionally shocked at some bugs that come up as a result of MS's 
twisted way of translating any application to Web.  It makes sense - it 
really does.  It just teaches people to do things *their way* instead of the 
"Web" way.  Take an example of hello world:

If I was making a hello world app in Perl (CGI), I might make 2 files:
... snip ....
<form action="hello.pl">
<input type="text" name="yourName">
... etc ...

use CGI;
my $q=new CGI;
print $q->header.$q->start_html."Hello ".$q->param('yourName').$q->end_html;

If I gave this to a .NET person to do, they'd do it with one .asp page, with 
3 server elements: lblHello, txtName and btnSubmit.  and the code would be 
something like:

btnSubmit onClick {
lblHello.value="Hello " + txtName.value;

There's nothing wrong with this.  It would be perfectly correct to do the 
equivalent using CGI to make one page to handle both scenarios, but some 
important differences (which the .NET people overlook) include:

1) In .NET, I'm looking at the widget, rather than the request.  Let me 
In CGI, I would probably make a hidden variable saying "mode=sayhello" in 
the form to know I'm after the submit.  In .NET I'm relying on the fact that 
btnSubmit was clicked and it's onClick being called.  In the case of a 
single step (eg form --> final submit) on a given page, this isn't so bad, 
as we can do something like:

Page_Load {
if (Postback) {
lblHello.value="Hello " + txtName.value;

but if it's possible to have more than one way of getting to a postback of 
the page, things get hairy.  And many .NET people don't even think about 
using a hidden variable.  Why? Because...

2) In .NET the abstraction/translation of the web page to a 
Window/dialog/etc is complete.  Down to the wysiwyg editor which uses 
absolute positioning with CSS to place elements on the screen (talk about 
evil, eh?  That's called raping CSS ;-)).  Now, there's a certain amount of 
truth in the translation of the webpage to a normal GUI window, and the 
framework can be used very nicely in the hands of a competant programmer. 
The difference (this goes back to the Sapir-Whorf programming languages 
application) is that a .NET programmer is thinking:
a) I have 2 widgets on the screen which should be hidden
b) I want set the visible property of the controls in question to false
c) btnSubmit.visible=false; txtName.visible=false;
 while a real web programmer is thinking
a) I have 2 widgets on the screen which should be hidden
b) I don't want to include the fields in question in the HTML form
c) btnSubmit.visible=false; txtName.visible=false;

The difference is subtle, but definately there.  I suppose that it pretty 
much boils down to the fact that the .NET programmer doesn't really think 
about the HTML aspect of the form.  It would never occur to them to write 
the 2 page example I did in CGI above, because of another faulty thought 

a) I want to use the value from the textbox
b) I want to check the value property of the checkbox
c) lblHello.value="Hello " + txtName.value;

a) I want to use the value from the textbox
b) I'll need to get the value submitted in the HTTP request
c) .NET can use a standard HTML form and let me do something like String 
d) But .NET gives me a shortcut of using a "server-side" textbox, which I 
then need to read a different way (because it screws up the DOM name/id of 
server-side controls to do its magic)
e) lblHello.value="Hello " + txtName.value;

There's nothing *wrong* with thinking the former way, as long as you know 
it's an environment (.NET) based shortcut of the second. But to a novice 
.NET programmer, it's *all they think of*.  And once we get to the 
limitations of the abstraction, it gets stupid.

3) This really shouldn't be it's own number.  It's the same idea as (2), 
with a different spin - and an unacceptable outcome  Let's say I had a 
checkbox and a text field.  I want the textbox to be enable when the 
checkbox is checked and vice versa.  We're not worried about data validation 
and can assume that at the "normal" form submit (beyond this simple 
check/text widget), we'll validate data server-side and/or client-side as 

a) I want to change the textbox element based on the checkbox element
b) To change the textbox element, I want to set it's enabled property
c) i can get the checkbox status from cbxShowText.value
d) Furthermore, I can track when the checkbox is changed by using the 
cbxShowText onClick (Actually, I think the event is selectedIndexChanged or 
something like that)
g) cbxShowText onClick {

Whoa!  That's not what we expected to see...  Behind the scenes, MS is 
taking care of an important set of steps:
e) Set a javascript handler to set the form to submit when the client side 
cbxShowText.onClick is triggered
f) Read the form values from the postback call.  Determine which element 
triggered the postback and hook the onClick event handler

But it could have been done so much simpler!

a) I want to change the textbox element based on the checkbox element
b) To change the textbox element, I want to set it's enabled property
c) i can get the checkbox status from cbxShowText.value
d) It's a huge waste to send this all to the server, because the server 
couldn't care less about the state of the box until validation, which is 
only at the main form submit
e) I'll write a javascript handler client-side to toggle the disable 
property of the DOM node of the textbox, which will be called every time the 
onClick event of the checkbox is triggered. (I won't bother writing the 
code, because it's irrelevant)

This is a much more serious problem, since the .NET way is:
1) Wasting the server's resources
2) Wasting the client's resources (a full page reload instead of changing 
the existing page)
3) Wasting everyone else's resources (if I need to have a full HTTP 
request/response that wastes bandwidth - especially for a stupid little 
thing like this inside a *massive* (50k) form)

Now the first way wouldn't be so bad if I were doing something more creative 
with it.  Maybe if I had a completely different form to show based on which 
of a few checkmarks were selected.  It's kind of a tough call, because there 
aren't so many "good" uses.  But once it's there, it'll get abused by 
everyone.  The bottom line is that it's the freedom with which .NET makes 
the 2 hidden steps (e,f) available so easily, that tempts so many 
programmers to abuse the same wonderful constructs so in such utterly 
horrible ways.

Anyway, I've rambled enough, and I'm sure I'll get flamed for my efforts 
anyway, so I'll just quit now...


More information about the Perl mailing list