From: Ry Nohryb on
On May 22, 5:13 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
> On 22/05/10 16:22, Johannes Baagoe wrote:
>
> > Dmitry A. Soshnikov :
> >> Is it relevant or this is from other song?
>
> > I think it is from another song. Ry Nohryb likes cute constructs that
> > minimise code lines. Most other contributors frown upon anything the
> > average programmer may fail to understand and maintain.
>
> Count me in as an average programmer, then. In order to understand the
> example, I had to rewrite it and rename the variables/arguments:
>
>   aQuery = (function () {
>       var list = [];
>
>       list.refresh= function () {
>           var set = document.body.getElementsByTagName('*'),
>               i = set.length;
>           list.length = 0;
>           while (i--) {
>               if (set[i].width === "100%") {
>                   list[list.length] = set[i];
>               }
>           }
>           return list;
>       };
>
>       list.refresh();
>       return list;
>   })();
>
> Unless I made a mistake during refactoring - which is entirely possible,
> I didn't test it or spend a lot of time on it - aQuery is a sparse array
> of all elements in the body with a "width" property of "100%". It also
> has a refresh() method which will update the array and return the aQuery
> object for method chaining.

Perfect.

> The "width" property looks suspicious. Not necessarily a bug, and it
> could be intentional, but I wonder how easy it is to find such problems
> in a "compressed" piece of code?

You've got it perfectly except that you've hardcoded document.body,
"width" and "100%", which in my mind were just regular parameters to a
generic "attribute query generator". (Before David Marks jumps in: I
know that not all html-elements' attributes are reflected in JS-land,
and that those that are, might be with a different name (e.g. class/
className))

> I enjoy playing around with terse and obfuscated code, too. For example,
> this is a working Perl program, written entirely with keywords:
>
>     not exp log srand xor s qq qx xor
>     s x x length uc ord and print chr
>     ord for qw q join use sub tied qx
>     xor eval xor print qq q q xor int
>     eval lc q m cos and print chr ord
>     for qw y abs ne open tied hex exp
>     ref y m xor scalar srand print qq
>     q q xor int eval lc qq y sqrt cos
>     and print chr ord for qw x printf
>     each return local x y or print qq
>     s s and eval q s undef or oct xor
>     time xor ref print chr int ord lc
>     foreach qw y hex alarm chdir kill
>     exec return y s gt sin sort split
>
> (from <http://www.perlmonks.org/index.pl?node_id=290607>)

LOL. Perl is exceptional. I love this one:
http://99-bottles-of-beer.net/language-perl-737.html

> Pretty impressive stuff, but perhaps not the most appropriate format for
> production code. There's a time and a place for everything :)

I too write tricky code is an as clear as possible way, but a little
snippet as that query generator is not exactly "tricky", or is it ?

In any case, we ought to do an obfuscated JS contest ! It would be
funny!
--
Jorge.
From: Ry Nohryb on
On May 22, 5:13 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
> (...)
> I enjoy playing around with terse and obfuscated code, too. For example,
> this is a working Perl program, written entirely with keywords:
>
>     not exp log srand xor s qq qx xor
>     s x x length uc ord and print chr
>     ord for qw q join use sub tied qx
>     xor eval xor print qq q q xor int
>     eval lc q m cos and print chr ord
>     for qw y abs ne open tied hex exp
>     ref y m xor scalar srand print qq
>     q q xor int eval lc qq y sqrt cos
>     and print chr ord for qw x printf
>     each return local x y or print qq
>     s s and eval q s undef or oct xor
>     time xor ref print chr int ord lc
>     foreach qw y hex alarm chdir kill
>     exec return y s gt sin sort split

$ perl (that above)
--> "just another perl hacker"
--
Jorge.
From: Johannes Baagoe on
David Mark :
> Johannes Baagoe :

>> perhaps javascript is different, and for a good reason.

> It is and here's the reason: most JS programmers are incompetent.

That seems, alas, to be the case.

> The trouble is that JS makes it easy for programming novices (or
> even non-programmers) to cobble together something that appears to
> work in their installed browsers. That creates overconfidence,
> which leads to foolhardiness, which leads to all of those errors
> you see in the console.

Quite, but what can we do about it? Is it better to simply acknowledge
the fact and say "Nothing fancy in production code", or do we attempt
to raise the general level of programming skills even in javascript?

I'm not suggesting that each and every clever construct should be
endorsed and used, of course. But there is at least one that seemed
very odd when it first appeared, and which has become an indispensable
idiom - Cornford's Construct, `(function() {/*...*/}) ();`.

So, perhaps, there is a case to be made for some ingenuity. It could
be argued that so-called "programmers" who can't follow simply aren't
fit to write programs for a living, not even Web applications which
hardly require less skills than, say, business reports in COBOL.
Perhaps that would be a better way to increase the general level of
quality of Web applications than insisting that only what morons can
understand should be used in production code.

--
Johannes
From: Dmitry A. Soshnikov on
On 22.05.2010 21:02, Johannes Baagoe wrote:

<snip>

> an indispensable
> idiom - Cornford's Construct, `(function() {/*...*/}) ();`.
>

Why do you call it so? Did Richard Cornford suggested first to use
exactly /this style/ of a function expression (with grouping operator)
to provide a local initializing scope? Wasn't it used before? I don't
believe. What's the date?

(Richard, answer yourself please, and confirm it, if it is true).

Dmitry.
From: Johannes Baagoe on
Dmitry A. Soshnikov :
> Johannes Baagoe :

>> Cornford's Construct, `(function() {/*...*/}) ();`.

> Why do you call it so?

I believe that it should have a proper name. By coincidence, a catchy
alliteration is available, like Duff's Device and the Muenchian Method.

> Did Richard Cornford suggested first to use exactly /this style/
> of a function expression (with grouping operator) to provide a local
> initializing scope?

It would seem so.

We have been through this several times before, most recently here:
http://groups.google.com/group/comp.lang.javascript/msg/b11277c67125d005
and more completely here:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/87d1112f5330d0a5/438e418534894bbd#438e418534894bbd

--
Johannes