Actually while this may be right for some very old or very cheap content, movies tend to be stored on much higher resolution material - Either way if 4k is not a problem, 8k will be, so it remains an increasingly important concern.
Yet another article written with total disregard for science.
Short article covering the usual bullshit about resolution and why apple retina is wrong, etc.
http://wordmunger.com/?p=1348
For those who didn't know, the eye can see over 10k pixels in an angle of a single degree (the fovea, right where we aim with our guns or bows, of course).
That means that in order for content and displays to provide you with the precision that real life offers, one should maybe consider a 40K TV instead.
In reality, the brain does a lot to interpolate and most humans aren't trained to make good use of their view anymore (how many of you are sharpshooters or combat pilots mhh?) and thus may not notice a difference at some times, especially when tired or in bad lighting conditions.
As I detailed in another comment somewhere, color accuracy is more important (IPS,OLED,..) than resolution because the brain cannot interpolate colors (quite logical indeed, how would you code that ? say that FFFFFF is more FFFA FFFA FFFC than FFFB FFFB FFFB ? good luck with writing anything else than random interpolation) and that means that focus on 4k TV should be secondary to focus on accurate sRGB TVs.
It doesn't mean, however that 4K or 40K is useless.
Well, first things first, you must be aware that JavaScript is a bad language, broken in many ways and mostly executed in a random fashion (i.e. almost no platform follows 100% ECMA, and even some ECMA directives are retarded, like ECMA4 didn't force chrome to return object properties in creation order by default, whereas ECMA5 fixes that to the default behavior we've always seen and expected).
In that sense, writing good JavaScript is like writing good PHP or good C++, it's a lot about avoiding the broken features (for both those languages, there are a lot of features one shouldn't use, it's even more true with js).
That means you should only learn from people who recognize how broken js is, and thus of course js: the good parts sounds like the right direction, whereas I think Resig is a religious zealot and shouldn't be listened to (the guy actually thinks broken js as a first language is a good idea).
Lastly, js is broken in many ways, don't use it when you don't have to, that means avoid node.js and use a good server side language instead.
tl;dr
js sucks, don't listen to people who don't ack that, learn to avoid the sucky parts instead.
And more downvotes from the zealots... HN is so predictable these days.
Dear Troll, I find you use of the word "zealot" to be amusing, ironic and predictable. In addition, during that entire rant you never once mentioned what you thought was a good language.
Now, to add to the real discussion. Aside from all the wonderful suggestions you received so for: once you have read all that you can and broken/learned first hand all you can, and if you are of the pattern persuasion I would look in to the functional language patterns. The Classical patterns, as found in most examples and resources these days, map poorly to JS. At least that is my opinion.
I haven't seen a perfect programming language yet, but the compromises offered by FORTRAN, C, Ada and lisp are really hard to beat, as the first three offer very competitive speed whereas the last one trades off about 50% speed for a lot of built-in metaprogramming.
It's really all about compromises, and JS fits no bill except "easy to learn for noobs", which imho is a non-issue for anyone considering long-term use.
(in case you didn't know, fortran has awesome arrays and awesome compilers, C has inline ASM and awesome compilers, Ada has increased execution security and lisp is lisp)
JavaScript is harder to learn for noobs, it's just easier to get "hello world" working than other languages. I don't think anyone with a good grasp of JS would ever recommend it to someone as a first language.
Well, this is an Ask HN thread and your answer boils down to "learn to avoid the sucky parts", which is good advice, but instead of further guidance on how to achieve this, the remainder of this post contains nothing but useless rants. (Useless for the OP, that is.)
Look at the top rated posts in the thread, all of them contain a ton of specific advice on avoiding the sucky parts.
Avoid the sucky parts by listening to people who recognize the suck.
And that's exactly why it is an addition to the existing answers, most of which do not focus on that core point, and some of which even advise to read documentation written by people who don't recognize the failures of JavaScript.
Database access latency will always be an important factor of _latency_ .
That doesn't prevent anyone from coding stuff that requires 20 times less application servers while using the same amount of database (+caching) servers.
The very idea that because the DB call takes a while to complete, we can waste even more CPU cycles is a complete misunderstanding of real world use cases.
But then, the very use of PHP means that you don't give a shit about execution time or server costs at all.
They're implemented using the same data structure and given the language semantics (keys can be any scalar type intermingled horribly), how would you improve that?
The best way to write PHP for the web is like any language: php echos or prints shit, that's it.
The way you're showing is that of the total noob trying to implement some php inside their evil dreamweaver website.
Besides, if you're handling markup (in the web context) on the server side, you've already failed, as most markup should only be generated client-side, diminishing server-load and bandwidth consumed while greatly improving cacheability.
I strongly disagree. Echoing well-formated HTML is much harder than simply tagging around it, and what's the benefit of echoing it? You like escaping characters?
1) your js should be echoing the HTML and getting data through JSON ajax
2) echo and print both work in command line, are explicit and work exactly as any language, whereas peppering your shit with php tags looks like shit and a maintenance nightmare.
If you have trouble escaping characters, you should consider the single quote, it's known to rock the boat.
Additionally, "'.$var.'" is the best, fastest, cleanest no surprise approach to inserting variables in markup, leaving double quotes just fine and dandy inside your markup.
And then, I'm pretty sure I'd rather have a string with 100% warranty of no execution or interpretation (that's single quote versus double quote for me) than any kind of dirty markup polluting my source code.
On the same subject, there is no valid reason for having naked markup inside your PHP, or between PHP tags because you're just begging for problems.
And I would expect multiple PHP tags to cause some minimal parsing overhead too.
Either way this matters not because the only sane way to use PHP in a web application is echo json_encode($return);
or header(file) + readfile
And even then the second example is only there because javascript can't be arsed to support file creation/download (i.e. server -> blob.gz -> js -> would you like to dload this shit ?)
Well, smoking cigarettes seems to work rather well for millions of successful people out in the wild - making your argument invalid.
It IS possible to make "business good" software in brainfuck, that's just not a reason to call it "not broken".
See, this is about science, logic, and whether or not a feature is properly supported by a language, not about whether or not somebody managed to build and sell a solution while using that feature.
First of all a modulo is ultra expensive, one does not simply modulo 15 when they already modulo 3 and 5.
The proper structure is if(3){if(5)}elif(5){}else{},unless anyone has a better proposition.
While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach.
Second the example written is code bloat à la java, writing tons of stuff for no reason.
Third Ruby is a beta prototype language that doesn't have any production ready implementation.
Lastly functional and procedural programming enable you to work at the highest level of abstraction you can think of, whereas OO tends to lock you at a specific abstraction level, which is pretty low and not adapted to most cases.
I have to admit it's impressive how such a simple test can show so many failures in people's deep understanding of programming.
This is another example of someone who I think looked at my code examples but didn't read the post. Fair enough, I guess.
> While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach.
Why? It is not computationally expensive, and it avoids excess modulo operations. All the dispatching work gets figured out at compile time and you end up with pretty much the same sorts of string concatenation costs you get in every other implementation.
Do you mean to suggest that it is conceptually expensive?
> Lastly functional and procedural programming enable you to work at the highest level of abstraction you can think of, whereas OO tends to lock you at a specific abstraction level, which is pretty low and not adapted to most cases.
I actually agree with this, although I sort of question procedural's place on the totem. I suppose stuff like Forth suggests you're right.
> Bloated, as in, takes way too much space for what it is.
> Additionally, it does _not_ avoid excess mod operations, _and_ the implementation is _broken_ because it won't print fizzbuzz for the 15.
If we're talking about the Haskell version here (I can't tell?), you're wrong on all counts.
• It is about as short as any reasonable impl I've seen of FizzBuzzBazz. Not long at all.
• And it does print out correctly for 15.
• And it does NOT do excess operations. It does exactly one modulo per factor.
Do you not understand how it works? I detail it pretty closely in the post; please look again.
The second ruby version _is_ long, but does not perform excess operations (unless you're complaining about Ruby's implementation of lambdas, which is out of scope). As I said both in my article and in this discussion; coding during an interview is tricky and that's not a bad effort.
Fianlly, the naive if-chain extensions are deliberately wrong to extend, but my initial research and experience is that most programmers don't realize that until they try it once. But then, they're lifted right from Rosetta Code so they're hardly unrepresentative of what people consider an "unacceptable" version of Fizzbuzz.
