What is a software engineer?
in [JavaScript]
|
Prev: html form in javascript variable
Next: Microsoft and attributes--will they ever figure them out?
From: David Mark on 14 Nov 2009 15:38 What is a software engineer? I talked to a group recently and presented this pattern: var myEval = function(str) { return window.eval ? window.eval(str) : eval(str); }; I know a lot of programmers of various degrees of proficiency read this group. Can anyone not see the problem with this in the second it takes to read it? Even if you don't know the language, but know that the code must be executed in various environments (which may or may not feature an eval method on host objects), logic dictates that this is about as bad as a design can get (designed to give varying cross-browser results). Would you hang your hat on this? I've been asked by these engineers to "prove" that this is a bad idea (I say the proof is right there in the code). They say they've never _seen_ it fail. For this one, I don't know what that means (it's obviously designed to fail). So when did programming becomes a process of gathering empirical evidence, as opposed to understanding logic? Seems like browser scripting would be the worst discipline for such a change in strategy. How about this one:- if (typeof xyz == 'array' || xyz instanceof Array) { ... } First test is _never_ true in an ECMAScript implementation. Same engineers want "proof" of that too. (proof that something does not exist!) Second test is known to be inconsistent due to frames. Is it really possible to program JS and not know these things? By the same token, what if you had wrappers for get/set/hasAttribute that made little or no attempt to deal with the broken MSHTML implementations (e.g. jQuery), built a CSS selector engine on top of them and found out years later that you made a *huge* mistake. You can see all of the support tickets that have come up over the years because of this mistake. Would you leave all of the bugs in place for the sake of some perverse form of backwards compatibility? These are all lynchpin functions. It boggles my mind that people could rely on (and waste time maintaining) code like this for absolutely everything, with the only understanding being that it "just works" (despite the fact that it is patched constantly, especially when new browsers emerge).. I guess thousands of similarly challenged engineers can't be wrong. ;)
From: Eric Bednarz on 14 Nov 2009 16:33 David Mark <dmark.cinsoft(a)gmail.com> writes: > What is a software engineer? In the Netherlands at the time of writing, anything from a computer science graduate to a HTML/CSS code monkey who can copy and paste [insert javascript[insert naming controversy here] library name here]-code.
From: David Mark on 14 Nov 2009 17:09 On Nov 14, 4:33 pm, Eric Bednarz <bedn...(a)fahr-zur-hoelle.org> wrote: > David Mark <dmark.cins...(a)gmail.com> writes: > > What is a software engineer? > > In the Netherlands at the time of writing, anything from a computer > science graduate to a HTML/CSS code monkey who can copy and paste > [insert javascript[insert naming controversy here] library name > here]-code. And at the time of this writing, a "proof" seems to be any bullshit pattern you can observe and report with your installed browser(s). It's like, if you saw it on the monitor, it must be true. Or more like if _anyone_ ever reported it. It is my contention that browsers (especially modern browsers) are not mysterious, illogical creatures to be observed. Neither are the people that make them. :)
From: Thomas 'PointedEars' Lahn on 14 Nov 2009 17:12 David Mark wrote: > What is a software engineer? I talked to a group recently and > presented this pattern: > > var myEval = function(str) { > return window.eval ? window.eval(str) : eval(str); > }; > > I know a lot of programmers of various degrees of proficiency read > this group. Can anyone not see the problem with this in the second it > takes to read it? > > Even if you don't know the language, but know that the code must be > executed in various environments (which may or may not feature an eval > method on host objects), logic dictates that this is about as bad as a > design can get (designed to give varying cross-browser results). > > Would you hang your hat on this? I've been asked by these engineers > to "prove" that this is a bad idea (I say the proof is right there in > the code). They say they've never _seen_ it fail. For this one, I > don't know what that means (it's obviously designed to fail). So when > did programming becomes a process of gathering empirical evidence, as > opposed to understanding logic? Seems like browser scripting would be > the worst discipline for such a change in strategy. Without trying to justify their response, when analyzing this problem I think it is important to take a step back and understand that very much depends on one's position in the learning curve and one's level of experience in the field. It is also a matter of the methodology chosen to employ in order to learn (a new programming language), which is strongly related to the two former aspects. If you do not know the difference between native objects and host objects (perhaps because you chose to learn by example only), and the possible difference in behavior that this involves, you do not get the idea of using an alternative to a type-converting test. And if you have never seen the type-converting test to fail, but you have seen some environments to expose an eval() method (and never a non-function `eval' property) on Window instances and others to have no such property, but an eval() method elsewhere instead, you can get the idea that this test was a good idea. Of course, that eval() is primarily a method of the ECMAScript Global Object and that therefore the wrapper is either unnecessary or error-prone, can already be ascertained by reading the first page of the Netscape/Mozilla.org Core JavaScript Reference¹, so the person's position in the learning curve and level of experience must be assessed as being rather early and low. As Richard stated more aptly before, the main problem with people learning JS/ES is extreme, objectively unjustified overconfidence; the languages are so dynamic in nature and the results of their application in a browser immediately visible that they appear too easy to learn from so-called tutorials (written by usually equally inexperienced individuals) instead of the -- to some apparently more painful -- process of RTFM. (This goes especially with the ignorance of the difference between ECMAScript, JavaScript, JScript, and the many other ECMAScript implementations and their versions, which is seldom, if ever, even mentioned in tutorials and books intended for learners.) Quick successes with superficial tests in a handful of browsers, inexact or bogus (script-kiddie) terminology employed by people at approximately the same position of the learning curve, suggest to the uninitiated that this simple appearance would be true, that the complexity the other people are talking about does not exist at all, and that those are just blowing up their egos. So these people tend to become victim to the fallacy of shifting the burden of proof, asking "show me where it fails", falsely assuming that failure would be the exception without recognizing for an instant (until told, but sometimes not even after that) that the approach is destined to fail (as Specifications are written to adhere to them) and that its working is the (fortunate?) exception instead. > How about this one:- > > if (typeof xyz == 'array' || xyz instanceof Array) { > ... > } > > First test is _never_ true in an ECMAScript implementation. That is not quite correct. The first test could result in `true' in a conforming implementation of ECMAScript if `xyz' referred to a host object. But I doubt the person writing it was aware of that or even intended to meet the case. > Same engineers want "proof" of that too. (proof that something does not > exist!) Second test is known to be inconsistent due to frames. Is it > really possible to program JS and not know these things? As for the frames argument, if you never used this code cross-window or cross-frame, you probably would never notice the difference. That is what happened to me, and I am not too proud to admit that it took me reading replies in this newsgroup a few months ago to see the problem, even though my code uses the `constructor' property instead as I considered it more compatible. And the library providing the testing function (but AFAIK not using it for crucial functionality) existed in that form since approximately *5 years* before that! > By the same token, what if you had wrappers for get/set/hasAttribute > that made little or no attempt to deal with the broken MSHTML > implementations (e.g. jQuery), built a CSS selector engine on top of > them and found out years later that you made a *huge* mistake. You > can see all of the support tickets that have come up over the years > because of this mistake. Would you leave all of the bugs in place for > the sake of some perverse form of backwards compatibility? Probably not; at least I would try to implement a version that eases the transition to a better approach. However, if you are inexperienced enough it is too easy to attribute problems newly discovered only in one or a few runtime environments to a bug in those environments. The misconception so built is understandable, but not acceptable, of course. HTH :) PointedEars ___________ ¹ However, the current Reference says "JavaScript functions not associated with any object" which is wrong, and "In the ECMAScript specification, these functions are referred to as methods of the global object." which is misleading with regard to the former sentence. Because in Netscape and Mozilla.org JavaScript, among other implementations, too, these functions are methods of the global object, and knowing that is a requirement for writing a sufficiently reliable feature test for those methods. -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: David Mark on 14 Nov 2009 17:30
On Nov 14, 5:12 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > What is a software engineer? I talked to a group recently and > > presented this pattern: > > > var myEval = function(str) { > > return window.eval ? window.eval(str) : eval(str); > > }; > > > I know a lot of programmers of various degrees of proficiency read > > this group. Can anyone not see the problem with this in the second it > > takes to read it? > > > Even if you don't know the language, but know that the code must be > > executed in various environments (which may or may not feature an eval > > method on host objects), logic dictates that this is about as bad as a > > design can get (designed to give varying cross-browser results). > > > Would you hang your hat on this? I've been asked by these engineers > > to "prove" that this is a bad idea (I say the proof is right there in > > the code). They say they've never _seen_ it fail. For this one, I > > don't know what that means (it's obviously designed to fail). So when > > did programming becomes a process of gathering empirical evidence, as > > opposed to understanding logic? Seems like browser scripting would be > > the worst discipline for such a change in strategy. > > Without trying to justify their response, when analyzing this problem I > think it is important to take a step back and understand that very much > depends on one's position in the learning curve and one's level of > experience in the field. It is also a matter of the methodology chosen to > employ in order to learn (a new programming language), which is strongly > related to the two former aspects. > > If you do not know the difference between native objects and host objects > (perhaps because you chose to learn by example only), and the possible > difference in behavior that this involves, you do not get the idea of using > an alternative to a type-converting test. And if you have never seen the > type-converting test to fail, but you have seen some environments to expose > an eval() method (and never a non-function `eval' property) on Window > instances and others to have no such property, but an eval() method > elsewhere instead, you can get the idea that this test was a good idea. > > Of course, that eval() is primarily a method of the ECMAScript Global Object > and that therefore the wrapper is either unnecessary or error-prone, can > already be ascertained by reading the first page of the Netscape/Mozilla.org > Core JavaScript Reference¹, so the person's position in the learning curve > and level of experience must be assessed as being rather early and low. Yes, the (unjustified) thinking goes that calling eval as a method of the Global object (or a host object) will set the - this - identifier and scope accordingly. But the logic is broken in any event as - eval - certainly won't do that. Unless the aim is for cross-browser chaos, it's a one-liner in need of a do-over. [...] > > > How about this one:- > > > if (typeof xyz == 'array' || xyz instanceof Array) { > > ... > > } > > > First test is _never_ true in an ECMAScript implementation. > > That is not quite correct. The first test could result in `true' in a > conforming implementation of ECMAScript if `xyz' referred to a host object. Fair enough. Should point out that - for host objects - it could just as easily be 'mickeymouse'. > But I doubt the person writing it was aware of that or even intended to meet > the case. Definitely not. It's paired with instanceof Array and roughly the same mistake I fixed (by proxy) in jQuery two years ago. |