What is a software engineer?
in [JavaScript]
|
Prev: html form in javascript variable
Next: Microsoft and attributes--will they ever figure them out?
From: The Natural Philosopher on 18 Nov 2009 04:59 kangax wrote: > Garrett Smith wrote: > > [...] > >> Perhaps future revisions of ECMAScript will include stronger wording for >> Host objects, so that implementations will have at least some >> conformance guidelines, though it seems too late for WebIDL, which >> also takes liberty to implement special behavior on Host object, >> defining a very large number of additional internal properties. > > ES5 (currently draft) puts few restrictions on host objects that weren't > there in ES3. This makes for a somewhat saner state of affairs. `typeof` > should now return more consistent results: "function" for any callable > object — native *or host*; and anything but "undefined", boolean", > "number" or "string" for host object that's not callable (doesn't > implement [[Call]]). > > [[Class]] values of host objects are now more or less under control. To > cite 8.6.2: > > "The value of the [[Class]] internal property of a host object may be > any String value except one of "Arguments", "Array", "Boolean", "Date", > "Error", "Function", "JSON", "Math", "Number", "Object", "RegExp", and > "String"." > A software engineer is someone who does NOT spend two weeks arguing the finer details of a language, or what a software engineer is. HE rewrites in code so simple, there is nothing to argue about.
From: John G Harris on 18 Nov 2009 11:51 On Wed, 18 Nov 2009 at 09:59:58, in comp.lang.javascript, The Natural Philosopher wrote: <snip> >A software engineer is someone who does NOT spend two weeks arguing the >finer details of a language, or what a software engineer is. > >HE rewrites in code so simple, there is nothing to argue about. "if that's too dull for you, the door is over there ->" he said : he's a manager. Unfortunately there are many managers who used to be engineers who pontificate about what it is to be an engineer. John -- John Harris
From: Garrett Smith on 18 Nov 2009 13:25 John G Harris wrote: > On Wed, 18 Nov 2009 at 09:59:58, in comp.lang.javascript, The Natural > Philosopher wrote: > > <snip> >> A software engineer is someone who does NOT spend two weeks arguing the >> finer details of a language, or what a software engineer is. >> comp.lang.javascript is the correct place to discuss how the language works. That happens to be important to people who use the language. Understanding a problem and how to solve it is a fundamental skill for a software engineer. This NG discusses mainly problems related to scripting HTML pages in a browser. This particularl eg of this thread is centered around discussion of type checking, where it is useful, where an abstraction is useful, where it fails, what the specifications state. Realize that c.l.js is an unmoderated NG; flippant remarks can and do create disruption. >> HE rewrites in code so simple, there is nothing to argue about. > > "if that's too dull for you, the door is over there ->" he said : he's a > manager. Unfortunately there are many managers who used to be engineers > who pontificate about what it is to be an engineer. > What he has described as his "management" techniques sound like not very good characteristics for a manager (or code quality, or pride, or healthy working relationships). -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: The Natural Philosopher on 19 Nov 2009 05:55 Garrett Smith wrote: > John G Harris wrote: >> On Wed, 18 Nov 2009 at 09:59:58, in comp.lang.javascript, The Natural >> Philosopher wrote: >> >> <snip> >>> A software engineer is someone who does NOT spend two weeks arguing the >>> finer details of a language, or what a software engineer is. >>> > > comp.lang.javascript is the correct place to discuss how the language > works. That happens to be important to people who use the language. > > Understanding a problem and how to solve it is a fundamental skill for > a software engineer. > > This NG discusses mainly problems related to scripting HTML pages in a > browser. This particularl eg of this thread is centered around > discussion of type checking, where it is useful, where an abstraction > is useful, where it fails, what the specifications state. > > Realize that c.l.js is an unmoderated NG; flippant remarks can and do > create disruption. > >>> HE rewrites in code so simple, there is nothing to argue about. >> >> "if that's too dull for you, the door is over there ->" he said : he's a >> manager. Unfortunately there are many managers who used to be engineers >> who pontificate about what it is to be an engineer. >> > What he has described as his "management" techniques sound like not very > good characteristics for a manager (or code quality, or pride, or > healthy working relationships). Believe me, I had to fire that guy. The only guy I ever had to fire. My staff begged me to do it. He completely destroyed the morale of people working damned hard to tight deadlines. It transpired that he was actually writing a science fiction fantasy online with a bunch on internet geeks. Writing plain code was just too boring.
From: Thomas 'PointedEars' Lahn on 24 Nov 2009 21:22
Garrett Smith wrote: > Richard Cornford wrote: >> Garrett Smith wrote: >>> The eval call, as used there, has potential to modify variables >>> in the calling context's scope chain. Using new Function or >>> a call to eval in global context and scope avoids that. ES5 >>> would "fix" that: >>> >>> | 10.4.2: In Edition 5, indirect calls to the eval function use >>> | the global environment as both the variable environment and >>> | lexical environment for the eval code. In Edition 3, the >>> | variable and lexical environments of the caller of an indirect >>> | eval was used as the environments for the eval code. >>> >>> That would be a significant change, but one that would be of >>> use to jQuery here. >> >> It would be of use to anyone who wanted to dynamically import script >> source text. It is a pity that much of the dynamic importing of script >> source text that goes on at present is already largely inadvisable. > > Importing script source text is possible by assigning a property to a > globally-accessible identifier. Given an |items| object: > > "if(typeof items !== 'undefined') {" > + "items.myNewItem = { name : 'a' };" > +"}"; > > What is inadvisable? 1. There is no `items' object. There is, at most, a property with that name that stores a reference to an object. 2. What does this have to do with importing "script source text"? Would you not want to use source code in a template in the same context in which you included it, as in other languages? The global meaning should be optional. 3. The spacing. `if' is not a function. 4. The assignment, if `items' refers to a host object. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk> |