Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How true hackers write JavaScript

news.ycombinator.com

Post reply on HN
Print view View original

301–310 of 342 posts

Re: How true hackers write JavaScript

#301

Post by dang »

btown wrote: post #195
olavk wrote: post #116

There are some polarized opinions in this thread. Someone wrote That might be one of the most readable pieces of code that I've ever read. Apparently it improves readability immensely to rename 'forEach' to 'aeach'. To be honest the code is not very readable, but it is very simple and self contained. It would be very easy to dive into to fix a bug because there are no external dependencies or frameworks you have to u…

You could reach a happy medium if everything was well commented. Introduce a build step to strip comments if you have to. But you would get maintainability while still having full visibility into all the code that is executing.

It might be interesting to see an example of a comment that you (or anyone) thinks would add to maintainability. What isn't expressed in the code?

If there is such information, there are two possibilities: either we could easily modify the code to express it; or we could not. Each would be interesting, but for different reasons.

Re: How true hackers write JavaScript

#302

Post by dang »

Klathmon wrote: post #206
TeMPOraL wrote: post #151

Earlier quoted context omitted.

> There's also simply no reason to change it, it works. It works, and it's arguably simpler than the div-soup with extensive styling, which is the "kosher" way of doing this.

I'd argue it's far from ideal. Mainly because closing a large tree of comments can often hang the UI for a second or so while this JS runs to find and hide all the children that need to be hidden. But it is simple, and it does get the job done for the most part.

It's true that the code is slow on large threads. That's on our list to fix. The last time I profiled it, it was (surprisingly to me) forEach that showed up as the culprit.

Re: How true hackers write JavaScript

#303

Post by dang »

paulintrognon wrote: post #122
richrichardsson wrote: post #87

Earlier quoted context omitted.

Hard to read? The sum total of the script fits on 2-3 pages at most, no single function exceeds about 10 lines, if you have trouble reading and reasoning about that code then something is wrong.

functions will not be any line longer by writing ranks instead of rks, but it will greatly improve readability. You can have the exact same code wihtout abbreviations, and I can assure you that it will still be 2-3 pages long, with very short functions.

You can't evaluate readability without knowing the conventions that a system is working with. (That means knowing something about the people as well, btw.)

In this system, 'rks' communicates something that 'ranks' does not: that this is a local variable denoting a collection, and that it is a collection of the things that 'rk' denotes one of. So actually it adds quite a bit to readability.

If I were going to edit that code to make it more readable, the one change I'd consider is using 'r' (or maybe 'n', because these are integers) instead of 'rk'. One can argue either way whether the k adds information or just noise.

Re: How true hackers write JavaScript

#304

Post by Klathmon »

dang wrote: post #302
Klathmon wrote: post #206

Earlier quoted context omitted.

I'd argue it's far from ideal. Mainly because closing a large tree of comments can often hang the UI for a second or so while this JS runs to find and hide all the children that need to be hidden. But it is simple, and it does get the job done for the most part.

It's true that the code is slow on large threads. That's on our list to fix. The last time I profiled it, it was (surprisingly to me) forEach that showed up as the culprit.

I figured, and to be honest it's not that big of a deal. I swear it used to be much worse when the collapsing comments first came out, but as I made that comment I realized that I actually had trouble triggering it.

Either way, it's a minor annoyance on an otherwise fantastic site!

Re: How true hackers write JavaScript

#305

Post by zrobotics »

markbnj wrote: post #248
xigma wrote: post #137

Earlier quoted context omitted.

> 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…

> Having less characters makes code more readable (or rather "scannable") as well, it's just another tradeoff. It might, in a specific circumstance, while in another circumstance it might make the code significantly less readable. That is an indication that number of characters is probably not a good metric for adjusting readability.

Couldn't agree more, sometimes too long makes things so much worse. I don't know why this is more common in Java code bases, but I've definitely seen function calls that take 6+ lines (have to maintain that 80 column limit) due to horrible naming. By the time I finish reading that, I've already forgotten what the base class is even called.

However, I've also seen large classes with members like "stN" for "set N". WTF is N, and why can't we just type set, that one char doesn't save anybody any time at all. Or nested loops with i & j reversed, just to make it especially painful.

Re: How true hackers write JavaScript

#306

Post by krapp »

Izkata wrote: post #205
olavk wrote: post #172

Earlier quoted context omitted.

Well using divs would at least make you able to group the elements semantically so you could remove a single node rather than having a for loop which removes exactly three nodes. This would be significantly simpler in my opinion. And it would be less fragile since now you can redesign everything inside this node without the JavaScript breaking.

I expect the layout would also be simpler in another way: Give every "child" div a static indentation, nothing more. They'll nest and the indentation will stack the deeper the comments go. Right now there's already nested tables-within-tables, just to work around how table columns work in order to handle indentation (and each row's indentation is handled separately with a stretched 1x1 image with a width attribute th…

Or better still, use the HTML elements whose sole purpose is to display nested content: and

Re: How true hackers write JavaScript

#307

Post by dang »

h1d wrote: post #289
Jaruzel wrote: 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…

> who cares You will. > As long as the code works, anything else is just gravy. These attitudes are really making some projects collapse like hell. If you agree to it, you need to stop writing code unless it's just for you. > I'm sure you'd find less than stellar code everywhere If this makes you feel proud of writing shit code, you need to stop as well.

Please don't cross into personal swipes like that.

https://news.ycombinator.com/newsguidelines.html

Re: How true hackers write JavaScript

#308

Post by krapp »

erikpukinskis wrote: post #275
krapp wrote: post #118

Earlier quoted context omitted.

>JS is the assembly of the web, do you also criticize games written in assembly? No it isn't, any more than C++ is the assembly of your operating system. Assembly has the terseness that it does because of constraints that javascript doesn't have -- this javascript looks the way it does because the author wanted it to look like lisp code, not because it has to.

Assembly, used this way, just means “the words that create action at the layer below which you cannot go”. Also referred to as “metal”. Depending on where you are starting that could be JavaScript, or it could be Basic, or any of a number of things. In the browser it’s JavaScript. This only makes sense if you can see that there are machines within the machines, within the machines.

Fair enough, it's a metaphor, but a fragile one that breaks down easily, as I believe it has here. Using actual assembly to defend terse coding in javascript because javascript is "assembly for the web" doesn't work.

Re: How true hackers write JavaScript

#309

Post by jacques_chester »

dang wrote: post #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 cod…

"Everyone I know agrees with me" is not a trustworthy signal.

It doesn't mean you're wrong, of course. I am still learning to assume that smart people are smart people who, by and large, have smart reasons for things that on their face seem silly to me.

I think this is one of those times for me. Not knowing the bigger picture, I want to give you the benefit of the doubt. But as one piece of stylistic feedback, since bikeshedding is easy: Congress repealed the Taxation of Readable Variable Names Act around the time that autocompletion was invented. I am dumb and find those far easier to read at a first glance.

Edit: I guess this thread is one of those times that software reveals its true nature, which is that it has almost nothing at all to do with computers.

Re: How true hackers write JavaScript

#310

Post by krapp »

DanHulton wrote: post #179
krapp wrote: post #97

It works... every criticism beyond that is just an argument about taste, although personally I think it's unnecessarily terse. I've written uglier code and gotten paid for it. ¯\_(ツ)_/¯

Not necessarily. Sure, all code has to work, but unless you're going to ship a product and then never, ever return to it, it has to be maintainable as well. There are a few arguments in this thread about poor maintainability of this code, when coupled to the HTML it affects (which always must be considered, otherwise this code is pointless), and I tend to agree with them. Personally, I wouldn't mind some less terse n…

>but unless you're going to ship a product and then never, ever return to it, it has to be maintainable as well.

This is Hacker News... there's a good chance it will go more or less unchanged for a while.

Post reply on HN