IS THERE A VANITY FAIR OF THE PROGRAMMERS?
|
|
Making sense out of an apparent separation between programmers' world and webmasters' cries
|
F or the happy few who've got time to waste, Stendhal would say.
I've never been able to settle down with a return null solution
whenever a
discussion proves unable to bring about a defined result, so I'm used
to keep
thinking about an undefined result at least as long as it relinquishes
something. I've been involved, as a bystander and marginally with a few contributions welcomed with some contemn, in one of the most engrossing discussion I've been involved so far and at least as far as our subject may be concerned.
An expert Java programmer,
was
performing javaScript initializations (initializations, not simple calls) of
functions
in within other functions (without the new operator) : this would basically mean, in the simplest shell we can device (the original was slightly more complex, involving three of such attempts and a few this keywords):
function fooONE()
arrayInside=new Array()
function fooTWO(){
return arrayInside
}
and a series of possible variations on the theme. A procedure
that although
legitimate in a language like Java (whereas a class includes its own
methods/functions/subroutines - call'em the name you like), may be
questionable in javaScript: emulating a class with a function, and
initializing
functions in within it, exhibits no affirmed legacy in JavaScript so
far. We
could argue on whether we'd keep ourselves bound by what has been bequeathed, or
if we'd
rather experiment: and probably the correct answer is we'd experiment and defy
orthodoxy wherever it dares show its leer, but we can't trash tradition in the process
with sort of a claim the more no javascript tradition compliance the
more the
glory. Otherwise, we may argue something has a longstanding tradition in language A: which doesn't make of language B an immediate candidate doomed to keep up with it and surrender even its proper syntax to make it the alike of the one we're more used to.
If I study Java, I'm not expecting it to ape JavaScript, but you'd find many who want javaScript to do it either Java way, or no way. In the same context, we could have seen these two following attempts:
- Initializing an array object in the body of this pseudo-class with
the
intention, apparently, to retrieve its entries at a later time
For the more experienced, this
array may
get assigned to a property such as:
this.stuff=fooTWO
- An apparently unexplainable attempt to override the toString method built in inside
javascript
with another personally defined method (that is: when invoked the toString method on an object, it was an action defined by an user-crafted method that took place instead of the built in toString method).
An attempt to retrieve the array values, might either
produce an error (triggering an alert to retrieve the array in a fashion like
alert(classFunc.method()) would give an error), or alternatively an attempt to
get the
array by a property name in case something like this would have been present:
this.someName=method
such as for
instance
alert(classFunc.someName) would return a string
version of
the...
entire function.
Something, obviously, of no real meaning to the eyes of somebody
involved in
scripts whose main purpose is to retrieve actual data: the array, not
the
string version of the function which holds it. Under this perspective, maybe we could make an hypothesis: the attempt
to
override the toString method was meant to avoid precisely this behaviour, and
to force
the object to return the actual array with its entries. That's just an
hypothesis, since so far it is not clear to my
eyes yet why overriding a built in method should be necessary, if such
wasn't the
goal or the intention in the given settings: you override a built in method only if you
believe this candid
violence on the language would be absolutely necessary to achieve
something critical,
otherwise you're just contented with defining your own methods
without meddling
with the superpowers: the built in stuff. So, under this hypothesis, the attempt would make sense,
although it
is not unconceivable being puzzled by a procedure whose intention is
to force
javaScript to be what it is not.
JavaScript has already a prototype keyword that lets you define class-
like
objects and by which you can build your own methods, so it raises not
little a
wonder why we should compel the language to obey logics that do not
belong to
the language, or cannot belong to it, but
by means of perpetrating such a thorough overhauling in the
conception: and all this in order to fetch an array.
Grows stronger and stronger the unavoidable suspicion that they do not do it because and when and if it is absolutely necessary, but they override toString and the alike built in methods by route, in order to make status symbol; is there a Vanity Fair of the Programmers? The snob posture they say no spells yes.
BROWSERS IN WONDERLAND
|
|
There is an object which doesn't exist: the browser how it is in real life. You meet it everyday but do not ask of it around too much: they'd tell you it doesn't exist.
|
When we hit this shore, I feel the necessity to state a couple of
points.
Of course you can use a cup to drink coffee and a dish to eat food,
and you can
use a cup to eat food and a dish to drink coffee: the former is dumb,
the
second is a remarkable inventor. But like Scott Fitzgerald once said: «let me tell you about rich
people: they
are different from me and you», I can more humbly tell you: «let me
tell you
about people concerned making real web pages: they are different from me and
you».
Whenever you're making web pages, you develop an habit which simply
prevents
you from experimenting too much. When you make web pages you get bitten
so many
times and so many times smitten by web browsers quirks and tantrum crisis that, simply, you do not
trust
anything.
- One day you have a layer and you nest a table in it, then you move it around
and you
write onto it: all of a sudden you see NS4 (but not NS6) dispatches
the layer correctly (although with some dis alignment)
but doesn't write in it at all: you then start changing html tags little by
little
until you find that if you set an align
property in within the table tag (but will not apply to td tags) NS4
cannot
write.
Maybe there is an explanations to it, but in my house I call it a bug.
I don't
complain, I work around it: but I don't call it a new achievement in the conception.
- Next day you see that NS4 cannot move right a <div> layer unless a z-index
has
been set. Not
that the z-index should have something to do with left and top
positions, of
course. None
the less it may not, and you brace up to listen to folks who'd tell
you that
makes sense.
- Next day you find that an image in a layer can get a swapping source (src property) on
NS4 only
if you assign
no name to it, although it would accept an id: and none the less,
you'd be able
to address
the image by its numerical index
images[2].
- Next day you find that IE5, so good at dealing with layers heights,
cannot
resize the height
of a layer if an image is in the layer (even if the resize would not
constrain
the image to
fit into unnatural downsized boundaries, but on the contrary would
let abundant
leeway).
- Another day, you find that NS4 can dynamically rewrite an html document with the document.write() method and write in it a new script tag which leads to an external javascript file.
NS4 loads such file correctly (you can put at work all its functions, that is), but only as long as you do not execute this procedure (once you've seen it works on a simple page) in within a frameset, for in such case a frame invoking a variable held in a script dynamically retrieved in the fore said fashion in another frame, would be unable to read it.
Does this make sense? You'd find persons that would tell you it doesn't make sense attempting it in the first place (right or wrong, your browser ya know...); but I still wonder: for, if I do it, why it's quite successful in one case and fails miserably in the second, and it is successful in both cases on IE? And if we find folks busy attempting making javaScript look a way it will never be, as if programming were a matter of lipstick, why then precisely my attempt should have been the illegitimate one?
- Next day you discover that if you set the background color of a layer, NS4 would accept the layer-background-color of course, but in some circumstances if you set the color to something different than #000000 like (case in point) #0000ff it may smash the whole page settings; and if you do not believe please just do grab to this file, get its html source, and in the style definition of the class named fader do change both colors from #000000 to #0000ff and then please do reload the page with something like NS4.51. Please don't be demure: just do: after all, you can still blame my design style, or find a minor fault, or if you lucky even a typo proving me an inferior scripter, when facing a dismal shortage of explanations: I will be a passable gentleman, and I won't complain, nodding.
- Next day you find that NS6, the last generation quantum big leap forward, crashes if you set a timeout interval lower than 250 milliseconds and you let it go for a while: something that NS4 does not, and which took to you about three days to work out, for first you carefully inspect the whole functions to delete fragments little by little until you pinpoint what was possibly offending it; scornfully finding no possible perpetrator, then you move to carefully sift the html codes and remove with surgical attentions all the properties one by one to clasp the culprit in between a tag pair; and only eventually, when your eyes are consumed by the screen radiations, only then you find yourself with one solution left: the invocation of the function, which went with a setInterval timeout.
Does this make sense? You'll find lots of chaps that will be ready to swear it does very much, oh yes very very much so.
This latest browser has already reached a second subversion (6.2) imitating its ancestor that step by step went to something like 4.75: I would be able to quote several webmasters who're sincerely making guesswork on what the improvements would have been, when we deal with subversions, since the quirks they denounce still there and still the same.
Will Netscape 6.983 fix it? Nobody knows: we all follow with apprehension the ongoing saga of the Browser in Wonderland, where the problem is to override toString methods simply beacuse it makes look your "developer" labeled plate so brilliant: you know, you've to polish it periodically by raping your language: this proves you smart.
- Next day you find that the built in text() method of NS4 would read the inner texts in within anchors, for instance, but only if the anchors do not surpass a certain amount. I've been unable so far to determine it: I only know that if you shorten the links for instance in this by now outdated file online, the method text() would work; add the links back and it does not: frisk around attempting to remove links from whatever section.
CAN BOOKS MAIM A PROGRAMMER'S PAYLOAD?
|
|
On whether we'd still regard useful Mr. Gutenberg invention or we'd relish science from an unknown spring
|
Let me include here a divagation: take it like a music, just follow the rythm, just be hip, in the sense Norman Mailer gave to the term. Do you know what: I still prefer
books.
Books
have a nice smell, you can scribble all over them, you can hold them,
you can
consume their pages, you do not have to bundle them in messy printed
pages, at times you wish you'd married a couple of them,
and at times they're even translated into your own language: you assuming me a native english tongue? I'm a dago.
Well you know what? you are to find many a folk who despises you precisely as a book reader, and finds that if you study books, that's not a good lot, but a squalid limit: for you must know some programmers are culture dandies without a bookshelf, they would undertake a Johnatan Swift Battle of the Books without the books, and dwell only where they can inhale a daily dose of sophistication; for, they say, the less you read the nimbler your wits.
I only wish that these esoteric circles that keep alive the fire of a JavaScript for the initiated, a Covenant revealed only to the just and which saves only the Apostles, and who forget what Plato said «God gave the word to men in order to reveal things, not in order to conceal them» would allow us to believe them intelligent not just once but possibly twice: the former time for they know every answer and you'd better not tamper, and the latter time for they still remember those long years, now obviously over, when they didn't at all.
I still remember that moving image by Chaplin, the man got rich that at the end of the movie leaned down to grab a cigar stump from the dirty ground, to mean the man that even rich doesn't forget where he came from. After all also De Gaulle knew it: you do not seize power, you lift it from the ground.
A NEW JAVASCRIPT SYNTAX
|
|
Should we be afraid of Virginia Woolf?
|
I discover today on a web documentation these two
syntaxes:
var t=[]
ya know what is it? It is an array I bet: in Java would be.
In javaScript we have been used to initialize an array like
var t=new Array()
Seems it can be done that way too (although you'd count on the
fingers of one
hand the pages
where you find that, and won't use all of your fingers even
assuming you
missing one). Another thing you find:
this.param = passed || "";
which means (I assume): this property can be equal either to an argument called "passed" or,
if no
argument passed,
to an empty string. And they default to this a syntax, not a fluke every now and then I mean.
I can do the same, but I'd say to you:
this.param=(passed)?passed:"";
This is more querulous, more prone, even prostrated, to a mainstream
syntax,
although no one doubts the other formula is shorter and would thus
save to you
even a couple of picoseconds when downloading. Seems the better language is the one which shrinks so much you cannot recognize it any longer.
I would like to use the || syntax thereof, in javaScript: it is appealing to every
unbiased
eyes: but there is something that keeps all of us, we dumb
webmasters, from
experimenting: how would NS4
IE4, IE4 on Mac, IE5, NS6 take it? of course they probably take it
right, the
programmer would say; the webmaster would say: sure, wait I boot my 4
computers
and I test it everywhere: you know how it has been lampooned, «write once, debug
everywhere».
THE WEBMASTER'S CORNER
|
|
What precisely makes webmasters wary and programmers audacious?
|
Would then you be surprised if I reveal to you no webmaster would
ever attempt
to use such syntaxes with great confidence? He/she is too well aware
of how
quirky browsers can be with even more straightforward stuff, he/she
will thus
have pretty valid and good reasons to keep the distance from stuff
which
promises troubles at first sight.
Thus there comes the webmaster with his/her sounder advice, more
trivial, more
dumb, and none the less advice that did not come out of immaturity
but by a
ripeness that developed after years of fights and bloodshed against
real browsers of a real web.
Webmasters, they always assume (wrongly) that if you want an array,
you want
the array not a stringed version of a function
which holds it. They would not advice you to reverse back to front a
javaScript
interpreter to force it to give to you a non-string version of it by
overriding
the toString method: they'd tell you try in a plainer way, since all you want is an array:
there is such a
way and would hit the target as well and -what most counts- safely (I read on Jon Bentley robustness is a requirement: but as we know, we should not read so much).
So if you
can get it by a prototype, the embattled webmasters would suggest to
you not to venture to initialize functions in within other functions
since
they have seen texts in within anchors that didn't work the expected
way. Webmasters do understand that this perspective appears coarse and deeply vulgar, and they kindly apologize;
although they
also know it didn't come out of ignorance. They would not claim their
approach
is original: it is not, for they have learned that the more you limit
your
attempts the safer the outcome, and that even things that should
work, they do
do not work. They won't have a problem learning a new approach, if this would be a striking leap forward: they have learned painstakingly more difficult things since at times many of them are self made and got avail of a significant amount of data readily available on books meant for those who have not seen (yet) «things that you humans do not even imagine». Programmers that experiment look at them with despise.
They
consider them dumb and a nuisance.
But I am ready to bet my only two cents that if webmasters would
listen more to
programmers the former would certainly experiment more; and if programmers
would
give heed to webmasters, the former would one day cease making browsers so full
of unmended quirks,
and get smarter webmasters as a longed for consequence.
|