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.
11 karma · joined September 14, 2012
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.
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)
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.
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 ?)
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.
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.
Numeric arrays in PHP are AS SLOW as associative array, that's pure fail and one of the reasons PHP::fannkuch is so slow.
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.
PHP is naturally (due to it's C libs) non-OO and will thus only implement OO "that" far.
Lastly, OO is not a silver bullet and is best used only in front-end, and languages that were designed with it in mind.
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.
PHP OO is a HORRIBLE IDEA. if you're doing OO PHP, shoot your other foot right now and go learn PHP before using it java-style.
Why is it that every time somebody on HN explains that a technology is not suitable for a use case, it gets downvoted by fans of said technology ?
Additionally, it does _not_ avoid excess mod operations, _and_ the implementation is _broken_ because it won't print fizzbuzz for the 15.
Lastly, using lambda's and whatnot's just because you can is yet another form of inefficiency and completely obfuscates what the machine will do.
I mean to suggest that 1) it should be a much shorter read 2) it's inefficient, and wrong 3) one does not simply lambda everything.
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.
But it does nothing about what's below, what actually makes that GUI possible, backend and all that.
In that sense, I believe Bret is addressing something on another level entirely, something that _is_ the future, i.e. a dev environment for people who design stuff.
Not a failed half-step up from C, like java,lisp, or all the existing programming language.
An unbreakable waterproof abstraction that will enable the less skilled to create awesome stuff.
Then we will be able to take all the <insert any 1.x levels of abstraction language here, from java to ruby> programmers, and send them to a layer where they belong, instead of leaving them to rot in a system that is both inadequate for speed and inadequate for productivity.