Live data from Hacker News

How true hackers write JavaScript

news.ycombinator.com

291–300 of 342 posts

Re: How true hackers write JavaScript

#291
post #137

Earlier quoted context omitted.

I believe there is a difference between gold-standard perfect code and just making "beginners mistakes". It costs almost nothing more to write "event" instead of "ev" or "removeElement" instead of "remEl", but it makes the code much more readable. You might gain 1s for writting remEl instead of removeElement but you will loose more seconds in the future trying to remember what remEl stands for, or having to check wha…

> It costs almost nothing more to write "event" instead of "ev" or "removeElement" instead of "remEl", but it makes the code much more readable. No, it doesn't. Unless you're an absolute beginner, it takes you a couple of seconds to realize that in this codebase, "ev" (or "evt" or even "e") means "event". The same goes for "remEl". If that's consistent, then it's not a big deal at all. Having less characters makes co…

Unless you're a machine, don't know what to tell you.

Re: How true hackers write JavaScript

#292
Maybe I'll respond in a general way to what's come up here. This code isn't unreadable, or accidentally readable—it was written specifically for readability. Similarly, it isn't unmaintainable or accidentally maintainable—it is written specifically for maintainability. Unlike in most programming debates, we can actually prove this. Here is the proof: I've talked to everyone whose job it has ever been to read this code, and all agree that it is easy to read. I've also talked to everyone whose job it has ever been to maintain this code, and all agree that it is easy to maintain. The point is that readability and maintainability are determined by who is reading or maintaining, and the 'who' that matters for determining that is the team responsible for a system.

If that sounds strange or obviously wrong, it may be that you're taking certain widely-held beliefs about programming as if they were truths about programming. Also, the conventions of the larger codebase which this small program is drawn from carry a lot of information, and free us to work with concision and simplicity that aren't so common in production codebases.

I know this sounds weird, but hope that it will stir curiosity in one or two of you. By far the biggest mistake I made as a young programmer was staying within what one might call the shallowculture for longer than I needed to. The outstanding properties of the shallowculture are that it 'knows' how to program and 'knows' to dismiss uncommon approaches to programming as wrong and inferior. If you notice yourself reacting this way, my grizzled advice is to pause and start questioning. Look into it deeply, and you'll find that this seeming 'knowledge' is spurious. That will open up for you more satisfying ways of making software. For example, you'll find ways of avoiding the complexity bloat that is routinely lamented in Hacker News threads as a plague on our industry.

Re: How true hackers write JavaScript

#293
post #207

Earlier quoted context omitted.

I'm not saying a rewrite is necessary at all, but refactoring this code to use more modern standards would NOT increase the line count at all, my guess it it might cut it by 15%+ in total size if you leveraged the beautiful builtin functions. Compare these: function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} } Could turn into somethi…

> Not only is is shorter, but it's more readable too! And won't work on IE. Not just because of el.classList, but also because of the arrow notation. So by doing this change, you either have to ditch one of still used browsers, or introduce a stupidly complex transpilation chain into the mix.

I'm aware, but I'm responding to the myth of:

> Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly

That's just not true, and nowhere did that person say: "Because of legacy IE support requirements", they only mentioned "modern webdev standards".

Are you suggesting arrow functions, and classList aren't modern standards then?

Re: How true hackers write JavaScript

#294

Am I the only one who thinks this is unreadable? var on = !afind($(id), collapsed()); (on ? addClass : remClass)($(id), 'coll'); where function afind (x, a) { var i = apos(x, a); return (i >= 0) ? a[i] : null; } where function apos (x, a) { return (typeof x == 'function') ? posf(x,a) : Array.prototype.indexOf.call(a,x) } where function posf (f, a) { for (var i=0; i

+1,000. The best programming advice I ever got was to write code for other people to read (and understand at a glance), not for the machine to execute. This code is the precise opposite of that.

It is a precise embodiment of that: the code was written specifically for people to read, and those people find it very readable.

It is a mistake to assume a single standard here. Does a German speaker find a Sanskrit text readable, or a trombone player find a guitar piece playable?

Re: How true hackers write JavaScript

#295
post #98

I don't understand why people are dissing this. It does what it's designed to do, and fills a specific need for one website. It's not there as a teaching aid, nor is it meant to be shared for other people to use elsewhere. Not everything has to be gold-standard code full of perfect variable names, extensive comments and good whitespacing. If you have a day job that isn't primarily writing code, and/or you are likely…

> As long as the code works, anything else is just gravy.

“It works” is one of the lowest imaginable quality bars for software to meet, one notch up from “It compiles.” Through my career I’ve worked with way, way too much code where the developer stopped at step one (it works).

Re: How true hackers write JavaScript

#296
post #6

function onready () { recoll(); } document.addEventListener("DOMContentLoaded", onready); Just attach recoll() directly. There's no benefit of going via onready().

Originally there was something else in that function body. That's also why we didn't collapse it when we took that bit out.

Re: How true hackers write JavaScript

#297

While everyone's freaking out over the code I'm remembering the old code that was only 2 functions[0], which leaves me to believe this code was changed not too long ago. I wish we had a github or something of some of these front-end changes to HN just to see how things change over time. I figure it wouldn't be too much, but still. The original JS was inlined and contained two functions: hide and vote. [0] https://new…

We expanded it for collapsible comments a few years ago.

Re: How true hackers write JavaScript

#298

Criticisms and bizarre fawning over beauty that a couple of people have made aside, the one thing that bugs me the most is the inconsistent usage of ;

I should fix that, since sctb probably agrees with you and is too polite to say so.

Any suggestions for me as a shitty semicolonist?

Re: How true hackers write JavaScript

#299

I thought I was smart... BEFORE function vis(el, on) { if (el) { on ? remClass(el, 'nosee') : addClass(el, 'nosee') } } AFTER function vis(el, on) { if (el) { window[on ? 'remClass' : 'addClass'](el, 'nosee') } } ...sadly we have to add window when using the square brackets so it's not much shorter. Oh well.

Why not: function vis(el, on) { if (el) { (on ? remClass : addClass)(el, 'nosee') } } ?

Yes, that's better, especially since we do it elsewhere. Thanks!

Re: How true hackers write JavaScript

#300

Is this some Arc-to-JS transpilation?

Probably not yet, but I've heard this might be the case in the future.

We have Arc to JS working in production now, but only use it for moderation software. The generated output is inevitably more verbose and we wouldn't want to inflict that on every page load.
Post reply on HN