Hacker News Reader

Comment by stephenr | Hacker News Reader

I'm sorry but if you can't immediately realize upon reading that 5 * 60 * 1000 is five minutes, you probebly shouldn't be trying to use window.setTimeout and definitely not window.setInterval.

Not every single thing needs to be wrapped in a jQuery "helper". Doing that just makes the developer using it more reliant on jQuery and less experienced/knowledgeable about straight JavaScript.

View on HN

I don't agree with your argument. The purpose of all programming languages and tools is to abstract away lower level behavior—not to make people lazier or dumber, but to make them more productive. Sure, it's never bad to know more about the lower levels, but that doesn't mean higher levels of abstraction are "dumbing down" things.

Programming is about solving problems, and if someone else has already solved a problem in a generalized and reusable way, at the end of the day you haven't created value by insisting on recreating that solution yourself. Please note that I'm referring to getting things done, specifically in industry; I'm not arguing that also understanding the lower levels is a bad thing. For example, I would love to thoroughly understand x86 assembly, and it would probably make me a better programmer (it couldn't hurt), but that doesn't mean I would refuse to use a high level language.

Being "reliant" on jQuery and its plugins isn't a bad thing if you're a web programmer that will always be able to use those tools. You can always go down another level and call someone "reliant." If you use pure JavaScript, then you're "reliant" on the browser's implementation. If you wrote the browser's JavaScript implementation in C++, you're "reliant" on the C++ compiler. Perhaps by the end of the day you're an x86 assembly expert, but now you're "reliant" on the assembler until you memorize the bit strings of all the hundreds of instruction.

But jQuery is a library, not a programming language. A web developer should not depend on jQuery precisely because it is not available in every javascript environment.

Where does plain old code reusability (which everyone in the software industry agrees is good) end and "libraries" begin? The jQuery library is just a bunch of open source JavaScript code. If you can distribute your own JavaScript code with your web creations, then you can distribute jQuery, and even if the jQuery team breaks things you can keep using an old version. Are you suggesting it shouldn't be relied upon because someone else wrote it, or are you against code reuse in general?

No, you can't always distribute jQuery - if a project is already using another library, it's not really acceptable to include jQuery.

Code re-use is great, when it makes sense. Requiring jQuery and a ~250 line script, so you can use "5 minutes" instead of (5 * 60 * 1000) is ridiculous, and any developer who does that would get a bollocking if they reported to me.

Clearly any semi-decent programmer can mentally translate 5 * 60 * 1000 into 5 minutes. So what? This is nonetheless a more intuitive and less error prone way to write times. This is about making readers of your code spend less cognitive effort figuring out what your code does, decreasing the chances of bugs (oops, I missed a 0 or screwed up a conversion factor), and making your code easier to modify. You seem to think this is a plugin for programmers too dumb to use milliseconds; it's not. Stop making excuses for bad code.

That said, sure, this isn't exactly a huge issue that's plaguing the javascript community. I probably won't use this plugin.

I'm not disagreeing with your general point, but this does seem a little overkill when you could achieve a similar effect with a few constants:

  5 * MINUTE
  3.5 * HOUR

etc.

Where are you getting these constants in JavaScript? You can't even trust the built-in "undefined" to actually contain "undefined".

(My point is: a library may be more appropriate in the JavaScript case, because of the lack of constants.)

is mytimelibrary.MINUTE what you're getting at?

For the small benefit of making timeout calls slightly prettier, I incur the small-but-probably-net-greater risk that there is some bug, subtle or otherwise, in this code, along with a motley assortment of other issues I usually gloss over but start being significant when we're talking about such small benefits, like adding a dependency and having to worry about the licensing situation. (Even just having to worry about something that turns out to be "public domain" is something to judge.) Net net I'd personally judge it a loss; YMMV, no sarcasm. I would generally analyze any NIH solution that solves such a small problem in the same way. It is, perhaps, one place where NIH is appropriate.

Each use of a non standard library makes code less "portable" - both in the sense that you need to include another library to support it, and in that it will be a speed bump to other developers reading and using your code.

So I generally have a non trivial minimum bar for using a library in my code - it has to do more than just a little syntactic sugar.

I was excited about this, not for a different way of notating time, but because setTimeout and setInterval make me hate life trying to deal with it's idiosyncrasies. Maybe I'm not that great at JavaScript or I had worse resources available, but last time I tried to use them, it was a very frustrating experience.

Reply on news.ycombinator.com