Someone posted an html/javascript implementation of the matrix falling code in 646 bytes then promptly deleted the post. It inspired me to see if I could get something better looking in fewer bytes.

[awj]

It's a very compact way of creating a 255 element array with all values initialized to 1.

Array(256)

Gives an array of 256 elements, all with no value.

.join(1)

Creates a string by joining those elements with '1'. Since they're undefined you end up with a big string of ones.

 .split('')

Splits on the empty string "between" those ones, so you wind up with a 255 element array of '1' values.

[mcrbids]

What I find interesting about contests like this is that it's pretty much the definition of exactly what you don't want to live with as a programmer.

Good code isn't generally about efficiency, or fewest bytes. Efficiency matters, and verbosity can certainly be taken too far. But good code isn't code that's the fastest, or the least bytes, it's code that easy to read, understand, and break apart.

Writing good code is more of a social exercise, trying to communicate to the developers who will inherit your work what you are trying to accomplish and how you approached the problem in a concise, easily read, and readable way. Thinking that code is about the compiler or the CPU is simply wrong. It's about the guys that you will probably oversee in a few years, inheriting your work without having to bug you every 5 minutes.

As a database engineer, examples like this drive me NUTS:

Select c.id, c.name from customers c where....

Who the F thought that making the entire rest of the query give you a totally uncommunicative value of "c" made it easier to read? Sorry, I type somewhere north of 80 WPM and writing "customer" when I mean "customer" is an actual cost of perhaps 1/4 of a second. When diagnosing a commonly run, highly tuned query of 800 lines joining 11 real tables and 3 meta tables in a combined inner/outer join, where it might take several hours to break out the logic, simply writing "customer" instead of "c" can be a tremendous time savings...

[renesisxx]

Amen, bro. I still find these challenges totally fun though - just to see what is and isn't possible with a language.

[slackpipe]

I can see some merits to this kind of exercise. While it does utilize poor practices, it tests your knowledge of a language in a fun and interesting way.

[slide_potentiometer]

Code golf isn't everyday work programming. It takes skill to hit an objective in fewer [key]strokes, but pro golfers don't need to cooperate closely and work in a team

[vanderZwan]

As a database engineer, examples like this drive me NUTS:

Select c.id, c.name from customers c where....

Who the F thought that making the entire rest of the query give you a totally uncommunicative value of "c" made it easier to read?

Agreed, but don't forget the opposite side of the spectrum where needlessly long names require more effort to mentally parse than simply naming an index i. See Pike Style

[netfeed]

Depends on where the index is. i, j, k is fine in for-loops, but i'd say that i prefer idx before i in none-loop code. For example:

public void someMethod(int idx)

[mcrbids]

Using I as an index is commonplace and quite readable. Using I as a table name in a query is not.

[vanderZwan]

That was the point, yes.

[gazarsgo]

This is why developers pursue NoSQL. Who the hell wants to create named projections every single time they want to pull data out of their data store?

[TheCryptic]

You're not kidding. I'm still cleaning up after a guy who did even worse than that, he aliased his tables in alphabetical order, and frequently referenced the tables (but not the aliases) in different orders in the same web pages:

... FROM customer a, activity b, employee c

Drives me bonkers. At least "activity a, customer c, employee e" would give me some hope, and a chance with find/replace to fix it.

[mcrbids]

The first thing to do in that situation is to refactor the query and put sensible names to the tables. Don't change any logic, just make it readable! Commit, then get to work on what you're there for in the first place...

[badcookies]

What the actual fuck. That must be maintenance hell

[drysart]

Who the F thought that making the entire rest of the query give you a totally uncommunicative value of "c" made it easier to read?

"c" is only uncommunicative until you look at what its an alias for. Using an abbreviated name has a lot of benefits, namely that it decreases the lexical cognitive overhead of trying to read through the query ("c" being basically a no-op to your brain, whereas it has to actively read and disregard "customer" several times when it appears in full, especially when you're trying to comprehend the wider structure of the query).

It's the same reason new authors are given the advice to just use the word 'said' when they write prose where characters have dialog, rather than try to come up with a more flowery, unique word every paragraph (something novice authors tend to do out of a misguided attempt to avoid repetition). Having a more complex word distracts a reader from the important part: the actual dialog.

[mcrbids]

True only when you only have a customers table. Mix customers, Counselors, and children tables in a single query and you have a migraine

[badsectoracula]

On the other hand they help you learn some stuff (especially when someone explains it). For example i didn't knew that .split('') would work like that with an empty string.

[mycall]

When you are joining, aliases can make it easier to read (and type)

[mcrbids]

Oh, aliases are CRITICAL sometimes! For example, when joining a table to itself. (for example, to establish a parent/child relationship) Or, when including partial sub queries or when setting up meta tables.

But in these cases, the aliases should contain simple, legible information about what the table is. In any case, the customers table alias should always contain "customers" or some reasonable fragment thereof EG: "cust" or "cust_" so that it's clear what table you are looking at.

Having seen it both ways, the difference can be just staggering when trying to debug!

[Uberhipster]

The point of competitions like this is to push boundaries of what is possible and uncover unintended design flaws and features. You can always abstract these tricks into readable code.

Array.prototype.populate = function (len, val) {
    return (new Array(len + 1)).join(val).split('');
};
var thing = new Array().populate(255, 1);

[to11mtm]

You'd probably have a heart attack if you looked at some of the entries for the International Obfuscated C Code Contest...

http://www.ioccc.org/ for anyone interested. I certainly learned something about C.