electrograv

Just because the universe may operate with computer-like regularity and grid-like data structures does not mean "the universe is a computer simulation." At best it means the fundamental laws of physics are "computer-like".

Whether "resembles a computer simulation" equals "is a computer simulation" is a metaphysical/philosophical question.

Finding uncanny resemblance between our own reasoning concepts and the universe is not new - and this uncanny mirroring between abstract mathematical concepts and the laws of physics has been known for quite some time. It's a mystery, not an answer. See: "The Unreasonable Effectiveness of Mathematics in the Natural Sciences" by Eugene Wigner:

http://www.dartmouth.edu/~matc/MathDrama/reading/Wigner.html

With Go, although you can pass error codes up the stack if you want, you have to do it explicitly. This forces you to think twice before doing so.

This is a key difference: exception handling subtly encourages ignoring errors and letting outer scopes handle them, while error codes force you to deal with your problems within the immediate scope, and then decide what to do from there explicitly.

For an achievement to "count", I'd make the bold claim that it has to actually work.

* However, I do agree that often to make progress you absolutely have to push your engineering "comfort zone" and try dangerous things, in order to learn from your mistakes. But this does not change my definition of "success", it just acknowledges realities of R&D.

For example the equivalent of 9pt on a 900p display allows actually reasonably split-screen editing. On an actual 900p display though, it's much too blocky to be easily read without straining the eyes. At 1600p though, it's crystal clear.

    In C++: "Foo *foo = new Foo()" 
    In C: "Foo *foo; foo = malloc(sizeof(*foo));"

You're right that there's no need for flamewars. I agree with most C programmers in style, as I am a C programmer at heart. I program C++ code that looks like simpler, cleaner C code.

Why does it look simpler and cleaner? Because I don't have to typedef my structs or stutter "struct" everywhere. Because I have templates to reduce that "necessary code duplication" where it matters for performance. I have constructors and destructors for the cases where I need compiler-enforced init/destroy function calls within a {} scope. I have references so I can almost entirely eliminate the worry of null pointer values in my code.

The point is that C is not the subset that most people want. Being a smaller subset of C++, it has a lot of appeal to me. But ultimately, there are genuinely useful C++ syntax features that can make your life much easier in producing reliable, clean code.

Absolutely C++ can be abused (i.e. inheritance for anything but interfaces), and absolutely C++ has some annoying quirks. That doesn't bother me too much, because at the end of the day C++ leads to cleaner code and higher productivity for me due to these relatively "syntactic sugar" features that I use.

http://en.wikipedia.org/wiki/The_Unreasonable_Effectiveness_...

It certainly is a mystery. I persnally believe this mystery is logically equivalent to the question "what is existence?" Whether this question is answerable or not, I can't say.

Use an algorithm to cross-check homework submissions, checking for structural copying. If a high correlation is found, as with human intervention, you suspect cheating but cannot prove it.

So, only for the potential cheating students, issue an extra quiz at some scheduled time, and discard the homework score. These quizzes should be all issued in parallel batches and last an hour or so, so solutions can't possibly be copied among cheaters. Make sure the quiz is actually harder than the homework, conceptually.

In other words, rather than trying to punish potential cheaters, just keep testing them until you're sure they're not cheating. This is better IMO than producing a 10x size problem set and selecting random subsets, because the number of suspected cheaters will probably be a small-ish percentage. Therefore, rather than having to write a ton of etra test material for everyone, you only have to write a few extra quizzes for a subset of the class.

Ask yourself the following questions, keeping in mind that different people will answer differently and that's okay: Do you have a passionate desire to do what you do (whether your motivation be to build a better future, change the world, or create cool technology, etc.)? Or is programming really just a way to make money (i.e. "just a job") to afford the things you really enjoy? (Or some balance in between the two, usually.)

IMO for those who are truly passionate about their work, their work is NEVER "just a job". Thus while #17 is true for a great many people, it's not true for the few who tend to accomplish the most - at least judging empirically from historical results.

For these people, it's much more than "just a job". For every highly successful person who made a huge impact on the world, it's never "just a job." Just ask Elon Musk, or countless others, if they consider their career "just a job."

Maybe your library is flawed. Maybe JS is fundamentally flawed. I'm not making any comments one way or another about what's flawed in this picture or how to fix it, just that seeing this comment indicates room for improvement.

Imagine the ideal design/architecture for a given application on all levels. Does it involve the users of this code or API explaining everything in lengthy comments? Or does it involve a clean, beautiful, and elegant set of interactions that is both transparent and intuitive as to what is going on? The latter, I argue, needs no comments. The former, I argue, is indicative of design flaws or inadequate function names.

So why do we see necessary comments in real life, then? Because real life system designs are rarely ideal. I still like to try to get as close as I can, though.

If there was ever 'code smell', it's when you see "x = y; // verbose way of saying sets x to y". And this is exactly your example - a verbose description of "$.resize.delay = 16;" If renaming variables and functions in this case doesn't make you feel better, I don't see why a comment would.

But yes... of course comments are important and needed in some cases, which I admit. However when they do, as other posters here have mentioned, it's usually annotating why, not how/what. I can't think of many reasons why it's not a bad sign if you find yourself explaining how something works - the only one that comes to mind is with hand-optimized code.

I'd argue that the following line is a better solution in every way than adding a comment as you suggest:

    setResizeEventFireRate(60); //just pseudocode of course

Granted, in real-world scenarios, there will always be many cases where you are forced to add comments, sometimes extensively (hand-optimized code, inherently complex systems, etc).If anything though, this only confirms how important it is to aim for self-documenting code.

Real-world production code is rarely a pretty thing, and the fact that you have to start adding comments everywhere is a reflection of this. You'd be surprised how clean and elegant code becomes when your only goal is to make it as self-descriptive as possible.

Then you're entirely missing the point of this article and of the product it writes about.

This class of video card (Radeon 7970, or Geforce GTX 680) cost $500-$600 each. They cater to those who want the absolute best GPU performance they can get -- and are willing to pay heavily for it.

Your quoted comment characterizes how you don't at all understand the target market of these cards. "I'm pleased to say that I have no idea how fast my CPU or GPU are" is the last thing you'd ever hear from an owner of this class of video card.

The author misses vitally key issues (like the inherent dangers of circular references in reference counting "GC"). I wouldn't even call myself slightly knowledgeable in GC, yet blatant holes in the clumsy analogies of this article are obvious to me. As someone who is not even slightly knowledgable in GC, it scares me that people are learning from someone who has massive information holes in the explanation -- holes in topics that every programmer on earth should know.

On top of all that, the only "Cons" that are mentioned of RC are absurd: "It's annoying if you forget to release your references." Wow. Profound stuff there - bugs and incorrect code is annoying. This isn't even a problem if your language supports RAII, in which it's impossible to "forget" in the first place.

I have worked consistent 70 hour weeks, where most of those hours are in sprint high-productivity coding mode, AND without getting burnt out or tired. The secret is simple: I was getting 9-10 hours of solid sleep every night.

Sadly it's far too easy to stay up late at night browsing the web, losing sleep for no good reason in particular.

True. Although, if you think about it, that's still pretty cool "sci-fi" tech, and opens up a lot of exciting futuristic possibilities. For example, you can still have a 2D HUD giving all the context-sensitive information you need, and you can still have ghost-like 3D images overlaying the real world to help you out.

In fact, I have no problem waiting for nonadditive AR glasses for everything except video-games, because in real-world use I want to be able to discern reality from augmented data.

You might as well just replace "username and password" with "enter your username and what's your favorite food?" or "enter your username and where'd you grow up as a child?"

Pretty secure, huh?

Unless I'm missing something, specialized non-VIM IDEs tend to be much better at auto completion (especially in C++), jump-to-definition, refactoring, etc. IDE users (who typically are ignorant to VIM) can use these features with extreme productivity. On the other hand, VIM users tend to be rather ignorant of how incredibly productive you can be and how nice it feels to have these powerful context-sensitive tools at your fingertips (and sorry, but CTAGS is useless). Regardless of what IDE you use, nobody can deny IMO that having an editor look up APIs and function lists for you in a context-relevant manner is productivity-boosting versus the alternate of scanning headers manually.

So in this sense I think both VIM/EMACS and IDE users are ignorant to other editor paradigms. What I don't like is how each party tries to claim that their method is the best, without having truly tried both.

I've used both extensively (used VIM for years) and I prefer IDEs by far, but that's just my personal preference.

This type of criticism doesn't really help, because the vast majority of people seem to think both (metro, and iOS) look fine, if not great. What matters is how usable these phones/OS'es will turn out to be once people start trying them.

My first attempt to tap into a channel with this system would be to tap into two points at some distance apart, then measure then changes in current at each point. Since the receiving resistor is flipped randomly and the sending resistor is flipped with the data, it seems to me intuitively that all you need to do to crack this is use a bit of basic electromagnetic physics to derive a formula to extract the data from propagation delays of the effective resistance experienced by the circuit measured at two distant points. I could be wrong though.

Unless you claim that the LED stops producing the >100% efficiency levels at room temperature, I don't see why you're claiming it can't cool anything down.

My Thinkpad is only a few years old, and the cooling system is acting up, I'm also having keyboard issues (even after replacing it) and just isn't worth bothering with. My old Macbook Pro on the other hand still practically runs like new, and never had to be repaired for anything.

I wish people wouldn't make claims based on speculation.

My intuition for the cause, is that the more surface area of the screen, the harder it is to consistently manufacture the panels without defects. But I'm not convinced because I'd imagine such incredibly high resolutions on laptop panels must be pretty demanding technology as well.

I just want 2880x1880 30" monitors for my office :)

Not to mention the PC MacBook Air clones, which in addition to questionable battery life, screen resolution, etc., ALL fail to have an actually usable trackpad. They've tried to emulate various multitouch gestures, but it all feels absurdly clunky and impossible to actually use. I tried one in a store and every time I tried to scroll with two fingers, it would intermittently zoom in like crazy. When it did actually scroll, it was laggy and choppy.

I know this is a bit off topic, but seriously, does anybody know what is up with PC track pad drivers? Why are they so laughably bad. Actually, it's not even laughable it's so pathetic... I'd cry (if I was a PC manufacturer).

Seriously though, I'm genuinely worried/curious about this. I am still looking for a Windows laptop that rivals the MacBook Air, because I do programming both on Windows and Mac (I by no means have an emotional attachment to any OS or HW vendor, so I'm pretty unbiased when it comes to these things). I'm still confused as to why this does not exist in any usable sense.

The self-contradictory ramble continues. He mentions how Apple knows how to design a user experience, rather than being design-blind and spec-obsessed, then goes on say that Apple has hardware spec issues, and that's a "dilemma". What...?

To top it all off, Apple is actually leading as far as hardware specs go (unless by "good specs" you mean "cram every feature you possibly can into the chasis without regard for user experience whatsoever"). The retina display is one obvious example. I wouldn't even consider a tablet without one at this point. The iPad 3's GPU is yet another example of Apple's hardware advantage. The fact that they bested NVIDIA, a company dedicated to designing the best GPUs, is extremely impressive.

Imagine you're a consumer walking into a store to buy a laptop/tablet/phone. From your perspective, who is leading the pack in every way that actually matters to you? I don't see a dilemma here for apple.

Obviously, all these self driven car stories are still ages behind google's AI car tech. I suppose it's unfair that google's car has spoiled the relative excitement of all these other stories, because they seem extraordinarily boring in comparison.