Carmack On Mobile VR Development
I have been an Android developer for two years and a Java developer for almost 15, and even a former Google employee, and...in my estimation, Carmack is 100% right.
Despite how much more I like Java than lower-level languages, Google's software stack is a complete disaster. It's poorly designed, bug-riddled garbage that I have actually considered re-writing parts of, even in the middle of a high-pressure project. What makes matters so much worse is Android's distribution model: rather than the direct-to-consumer approach that Apple takes, Google distributes Android indirectly via its device vendors, who can provide arbitrarily modified or out-of-date versions of the infrastructure that you're expected to support when dealing with angry customers who don't understand why their network stack mysteriously doesn't work.
The NDK is not an answer. It's a wreck because JNI is a wreck. I've been using JNI since 2002, and almost nothing has evolved since then - it was never anything more than a token olive branch to luddite C++ developers in 1995, and probably never will be. Ultimately, Java is excellent for mature devices (like servers), but is not suitable for emerging devices (like all the mobile devices we're seeing now) because of its runtime overhead.
Despite Apple's many shortcomings, one of the key points they get right is that mobile development needs natively compiled, non-runtime (or thin-runtime) languages. And, of course, libraries that work. Apple isn't exactly the gold standard on that either, but at least they're miles ahead of "beta early, beta often" Google.
Whole Foods: America's Temple of Pseudoscience
While Whole Foods does sell a lot of homeopathy items, that is *hardly* its entire character as a store. I, along with no doubt many others, go there because it's a specialty grocery store that has a lot of interesting foods that you can't find other places, including (and especially) a big variety of craft beers and vegetarian stuff. Their produce and bulk sections are also hard to beat for variety and freshness, and the prepared-foods section is great when you're on your way home and don't feel like cooking.
I'm no Whole Foods shill, and it does have its share of silliness. But comparing it to the Creation Museum is completely ridiculous and has no place in serious discourse.
Ray Kurzweil Talks Google's Big Plans For Artificial Intelligence
Ray Kurzweil is no doubt a brilliant thinker and an engaging writer/futurist - I've read some of his books (admittedly, not "Singularity"), and they are fun and thought-provoking. However, disciplined and realistic they are not - his main skill is in firing our imaginations rather than providing realistic interpretations of the evolution of technology.
My favorite case in point is his elevation of Moore's Law into a sort of grand unified theory of computing for all time, and using some very dubious assumptions to arrive at the idea that we'll all have merged with machines into immortal super-beings within the near to mid future. I don't need to pick apart all the reasons why this is fallacious and somewhat silly to treat as a near-term likelihood - the point is, he's basically a sci-fi writer in a lot of ways, and I read most of his statements in the same spirit as I'd read a passage out of "Snow Crash."
That said, Google has some very capable people, and can, in all likelihood, mount our best attempt at human-like intelligence to date. They'll push the envelope, and may make some good progress in working through all the challenges involved, although the notion that they'll create anything truly "human-like" is laughable in the near term.
Can Reactive Programming Handle Complexity?
Amen to that. Their (remotely reasonable) use is probably limited to maintaining legacy systems from back when people thought the database should rule the application stack, and an "app server" meant Perl scripts in the cgi-bin folder.
Can Reactive Programming Handle Complexity?
Clearly, one-time structural updates during system upgrades are a different ballgame. The pattern described is for ongoing use in deployed production code, and my assertion is limited to that context.
For upgrading Hibernate-based systems (or any other O/R-based system), I'd totally agree that short SQL scripts are in many cases the only reasonably performant solution.
As an aside, I don't really like "classical" O/R (meaning, every field is a column and object relations are explicitly embodied in the DB layer) either because it is so brittle. It lacks any ability to "soft-upgrade" the data because the code is so rigidly tied to the DDL that you're forced to write tons of SQL or other migration scripts for every system upgrade. This, in turn, drags the deployment process into an hours-long affair and sharply discourages frequent upgrades. Despite being no fan of Agile overall, I have found that frequent, granular upgrades are usually better than months-long waterfall cycles, which I feel that classical O/R tends to promote.
Can Reactive Programming Handle Complexity?
That's certainly valid that proper organization is far more the key to good code than the use of any language - my comments should not be taken as an ad for Java or any other specific technology.
That said, certain language features lend themselves to good organization much better than others. Where SQL faces challenges is that (1) it's mostly a declarative language using set calculus, which (again, in my opinion) makes it ill-suited for non-trivial business logic, (2) because of the aforementioned, it can't be hooked up to a debugger in any normal sense, making maintenance and troubleshooting that much harder, (3) it's a separate "codebase" and technical competency than the "main" codebase (whether it's in Java, C#, Ruby or whatever), thus creating a competency barrier that must be crossed every time work needs to be done on that code, (4) it's not stored with the main codebase, but as a form of data, raising the issue of out-of-sync deployments with the app servers, and (5) far fewer developers know it well enough for complex uses than typical app-server languages, making staffing difficult.
Finally, I have personally always found large codebases much more manageable when written in a statically typed language (which SQL is obviously not). Not wanting to spark a flame war with Ruby or PHP fans, though, I will caveat my statement that those languages are also much better suited for business logic than SQL's declarative style is.
Can Reactive Programming Handle Complexity?
As background, I am the director of engineering in a small Java/Postgres-based shop. We run a cloud backend for our mobile apps.
This "methodology" reads from the first sentence like an extended infomercial for a consulting shop, or a company trying to create the aura of "thought leadership" to get more investment cash. The formula is simple and time-honored: (1) arbitrarily single out a well-worn software practice to receive a snappy marketing name and be held above all other practices, (2) claim it's new, and (3) offer to implement this bleeding-edge buzzword to clueless executives. For a small fee, of course. It's the same formula that gave us Agile.
In my opinion, what they've described here is a large step *backward.* Not only is this a relatively trivial use of the GoF Observer pattern, but bizarrely, it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare. It's how software was made back in the 90s when Enterprise SQL database vendors ruled the land. Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep.
This one is safely ignored.
Dropcam CEO's Beef With Brogramming and Free Dinners
...that we shouldn't want things like identities, families, and lives. It is a joy for us to be interchangeable work-bots. Dissention must be expunged so that we can be assimilated. Obedience is happiness!
Game Receives First R18+ "Adults Only" Classification In Australia
Ninja Gaiden 1 or 2 would have been a very different conversation. The way I see it, the Aussies found a way to rack up a symbolic victory to look good to hyper-sensitive parents without actually hamstringing a blockbuster game.
Adobe EULA Demands 7000 Years a Day From Humankind
I haven't seen one in a long time. My boss tells me that 7000 man-years isn't anything he shouldn't expect in a good, hard 3-day push.
Ask Slashdot: Open Vs. Closed-Source For a Start-Up
Focus, focus, focus on getting that product out the door; that alone will take everything you've got. Open-sourcing involves managing a team of people who are distributed in geography and in time zones, and may not care about the mission of your business. It's way more headache than you need right now; I'd definitely not try to add that to your already-full plate.
Open-sourcing isn't really a marketing tool. Once you have a harem of happy customers, they will provide all the buzz you need, and then if you're profitable, you might have some breathing room to think about helping society.
Improving Productivity (With Science)
The single biggest line item on my (and probably many people's) productivity costs is interruptions of the form, "hey, I need to answer a question that takes more than a goldfish brain's worth of thought. I'd like you to do that thinking for me."
The second would be, "As my work product, I took a big dump into our codebase. Given that I don't care about anything but going home at 5, and none of our leadership understands what I did anyway, especially since I have two monitors and therefore look smart, why don't you clean it up for me if you are interested in finishing your own work?"
I'd settle for just dumping some dead weight instead of any new technology. Really.
How Do You Accurately Estimate Programming Time?
This is one of those problems, such as "the O/R problem," that cannot be solved because it asks an invalid question. I might suggest using it as a koan for Zen meditation.
The actual length of time a project will take arises from the complexities of the existing codebase as well as the rabbit hole of requirements. We can talk about the idea of a "spec" all day, but I've never seen requirements really, truly, set-in-stone finalized before release. Too many decision points always come up that were impossible to foresee without looking at a partially-complete version of the product. Requirements, like code constructs, are an adaptive process that continues all the way through the lifecycle, which is why the industry is flailing around for alternatives to the unrealistic waterfall model.
Thus, the set of actions that lead a team from beginning to end of a project are always, at least partially (and usually mostly) defined only as a function of the current state, and thus can't be fully predicted without actually playing out those actions. They can theoretically be partially predicted, but it's impossible to determine how large a fraction of the whole the resulting prediction is. It's almost never large enough to be considered remotely reliable.
Engineers themselves usually have a gut feeling that time estimates are a waste of time because of the need for this adaptive process. When was the last time you attempted a true end-to-end time estimate on a project where none was asked for by management? More than likely, you instead made a judgment about which path was probably the more efficient use of time, and started down that path with only a rough, order-of-magnitude guess at its length. At each step, your decision to continue was based on (1) how long it had taken so far, and (2) whether you continued to see a fruitful-looking path ahead.
I would argue that the common notion of time estimation in the industry arises mostly from the desire of outside parties (management) to create the illusion that the leaders are in control. I say "illusion" because ultimately, the main power here lies in the structure of the problem, not in any one person's hands. But the reality of being at the total mercy of a complex logic puzzle that can't be reasoned with would make most people very uncomfortable, especially those who are not in engineering. But the illusion of a "classic" hierarchical department with management and labor calms everyone's nerves and allows the workday to roll on, so we engage in activities that support it, including this charade of guessing the future.
Thus, searching for a good method of time estimation in mathematical models may help a bit, but ultimately won't get us there because it is fundamentally an emotional process. Look to the "soft" elements of team dynamics and department culture to do the rest: do people need to feel involved? Use a method where everyone contributes a number. Is the manager very controlling? Let him/her make up a number. Either way, there will then need to be a process of reconciliation between the illusion and reality, which again, is a process that depends on the emotions of the business. Perhaps a leader apologizes. Perhaps a "tiger team" is formed to improve estimation, or there is a department offsite to talk about it. It may feel unsatisfying that none of these actually brings the estimate and reality together, but like I said at first, trying to do that is asking the wrong question.
Why Yahoo Turned Microsoft Down
That's really the crux of all of this. The fact that the founders of both went to Stanford is hard proof of what I've always said: they are all part of a secret railroad monopoly plan hatched by Leland Stanford in the 1800s.
That's why he orchestrated the Hoover presidency and built the linear accelerator facility, which looks like the all-seeing eye when seen from the air. Google is really just a corporate front for the Stanford band, whose shadowy aim is to take over the world from their trailer, where Leland Stanford is kept cryogenically frozen!
The world, I say!