... shipping lanes invariably opening up as the arctic ice cap disappears.
I think you missed the underlying reason. This is just another facet of the elaborate internationally coordinated "global warming" hoax. Once they convince you the ice caps are melting then it is a slippery slope down to allowing Fluoride in our drinking water or believing men landed on the moon or even believing the Earth is round.
If a bank doesn't care about ACID, which means it doesn't care about losing completed transactions, which means losing track *OUR* money so they can get more profit.
Perhaps this is where you have gone astray. The opposite of ACID is BASE where the "E" stands for eventual consistency. The beauty of this is that it DOES NOT lose completed transactions and at the same time it allows for high availability.
Strict consistency (the "C" in ACID) is a much more stringent requirement than eventual consistency. In particular it conflicts with high availability. This is the essence of the CAP theorem. In many industries, including banking, eventual consistency plus high availability (NoSQL) is preferable to strict consistency plus lower availability (RDBMS). Of course there are many other factors involved in selecting a database architecture.
One way to see this is by noting the three typical things you can do at an ATM: deposit, withdrawal, and show balance, commute (in a sense) when you are only worried about eventual consistency but they don't commute when you require strict consistency. This is why relaxing the requirement to eventual consistency gives you higher availability (when the database is partitioned). Transactions can be logged and later merged when the partition has healed. It is true that "show balance" does not strictly commute with deposits and withdrawals but: a) this does not cause the system to lose track of your money, and b) no one expects it to strictly commute. There is usually a warning that it may take X hours or days before a transaction shows up on your balance. IOW the balance will eventually be correct after you stop making transactions.
The strict consistency alternative you think is better will mean that all ATMs have to stop working whenever the database is partitioned. For most customers this is totally unacceptable especially since the only value it adds is ensuring that the "show balance" function always includes all of the latest transactions. Even the average person on the street would tell you this approach is really "stupid". No one wants the ATMs to be broken most of the time just to be sure "show balance" is always perfectly up to date.
I also suggest you read CAP Twelve Years Later: How the "Rules" Have Changed by Eric Brewer. He concludes with:
In general, because of communication delays, the banking system depends not on consistency for correctness, but rather on auditing and compensation. Another example of this is "check kiting," in which a customer withdraws money from multiple branches before they can communicate and then flees. The overdraft will be caught later, perhaps leading to compensation in the form of legal action.
You can claim Eric Brewer is a fucking idiot as much as you want. Eventually all you will do is destroy your own credibility.
If you're storing data, you need to use a system that provides atomicity, consistency, isolation and durability. Using anything less is pure idiocy. [etc, etc]
They are using Riak which is currently being used by 25% of the Fortune 50 (fifty, not five-hundred).
The CAP theorem states there is a trade off between: Consistency, Availability, and Partitioning tolerance. Riak sacrifices consistency (although it does have eventual consistency) in favor of availability and partitioning. The people who wrote Riak (in Erlang) actually seem to be very smart. They say they are firmly in the "right-technology-for-the-right-job" camp. They are not crusading to replace all RDBMS with NoSQL.
The availability and partitioning tolerance of Riak are amazing. For certain applications these strengths greatly outweigh sacrifices in atomicity and consistency. Due to the CAP theorem, there is no one single database architecture that will be optimal for all applications. Granted, a completely different mindset is needed to use Riak if your previous database experience is all RDBMS.
From a cursory look, Riak seems to have some excellent documentation. I suggest you look at their page that explains the trade offs between using Riak and a traditional RDBMS. It also contains links to similar documentation.
RMS seat space
2. Bukkit contains Minecraft server code.
Correction: Bukkit contains decompiled, deobfuscated Minecraft server code. This code is already being made available. Why on earth would Mojang have to also make their original source code available? At worst, Mojang will have to LGPL the decompiled code they are already distributing as if it were LGPLed.
If I GPL a crippled version of my source code with all the comments stripped out, I am not obligated to give you the commented version for free.
If you buy a company, you need to make sure all contributing developers have signed a CLA [Contributor License Agreement] where they give their rights to the company you buy.
This may be the most nonsensical thing posted thus far. If company A is distributing my GPL or LGPL code then I don't have to sign a damned thing in order for company B to buy company A. Yes, company B should make sure there are no license violations going on in company A, but that is all. Once my code released under the GPL then I cannot revoke that license in order to try to screw company B.
This is where it gets tricky. Now THEY are the ones distributing your GPL code linked to their own code, not your reverse-engineered stand-in.
If this unfounded claim were correct then the takedown notice would be valid and the Minecraft owners would be complete and utter morons. Why on earth would they go to the trouble of replacing the decompiled code with their original source code? It makes no sense. It adds no value and it means they are now only distributing CraftBukkit in binary form which would be an obvious copyright violation of the LGPL code in CraftBukkit.
What is actually going on is the Minecraft owners are distributing source and binaries of CraftBukkit which includes decompiled code of their original Minecraft server as well as LGPLed code. At most, Minecraft would have to LGPL this decompiled code that they are distributing but since they are already acting like this decompiled code is LGPLed I see no problem here.
Reverse engineering might be illegal in the US (is it?), but it can logically speaking impossiblly be a copyright violation.
Decomplied != reverse engineered
Anyone can decompile. It takes work to reverse engineer. If decompiling removes all copyright obligations then copyright on source code is worthless. I just compile then decompile and distribute.
What I personally would generally include would be a comment along the lines of "this struct represents the KillAllHumans message body as per " where the struct is defined, and then a comment along the lines of "overlay our message structure over the buffer to extract our data". This way even if someone wasn't familiar with the bitset notation, they could probably infer it.
I agree, comments are for the information you add, although well thought out variable names go a long way to making code understandable:
struct KillAllHumans_Body {
}
I'll grant you that perl is very organic, probably the best "code as you think" language that I know of, but the vast collection of syntax and the functional density one can achieve (and some seem compelled to do so) makes it a pain to read if you didn't write it.
I am not disputing that it is easy to write obfuscated Perl but Perl style guidelines have come a very long way with Perl Best Practices by Damian Conway and the Perl::Critic module and the perlcritic program. There is a lot of Perl code written by other people that I find very easy to read. The key is to write clear code and use good variable and function names. The sigils provide context (and higher information density) which is what makes good Perl code easier to read than good Java or C code. YMMV.
Gregory Chaitin, one of the founders of algorithmic information theory once said in jest:
The LISP interpreter is about three-hundred lines of Mathematica code. Then I redid it in C, and it's a thousand lines of C, and the program is incomprehensible, which means that I'm a good C programmer!
Perl does tempt you to show off by writing incomprehensible (and perhaps incompressible) code. The style guidelines and experience can help you avoid this temptation.
IMO, the Camel Book is informationally dense. One reading was not nearly enough for me. I probably have read it all at least a half dozen times. I haven't used it in years because it is almost all on-line now and also part of the perldoc system.
[...] how do you iterate through an array of hashmap references [...]
for my $hash_ref in (@Array_of_hash_refs) {
}
IMO, with descriptive variable names this construct is both easy and clear. I think it is beautiful. If you want to access just one element then use:
$Array_of_hash_refs[$index]->{$key}
For nested data structures like this I prefer to make the top level structure a reference so this becomes:
$Array_of_hash_refs->[$index]->{$key}
Which I think is a little more consistent.
I've taught Perl in college and I admit there are some (perhaps many) people who will never master it. OTOH, I once wrote a CSM system in Perl in the time the Java folks said they would need to come up with an estimate for how long it would take them to do it.
In C, the first time I saw the size of elements of a struct specified (i.e. int something : 3) it threw me (and that's a hard problem to google). [...] (though a comment woulda been nice unknown dev!)
The first hit from Google(struct) is the Wikipedia(struct) entry which starts with:
A struct in the C programming language (and many derivatives) is a complex data type declaration that defines a physically grouped list of variables to be placed under one name in a block of memory, allowing the different variables to be accessed via a single pointer, or the struct declared name which returns the same address. The struct can contain many other complex and simple data type in an association, so is a natural organizing type for records like the mixed data types [...]
Furthermore, I really don't think a comment should be used to explain a language element that is clearly defined in The C Programming Language (K&R) by Brian Kernighan and Dennis Ritchie. A C programmer should assume the reader is familiar with what is in K&R, otherwise the comments become a language tutorial.
As for Perl, once I really learned Perl I found it to be extremely intuitive. It is a very powerful and very expressive language. All of the sigils (and related "line noise" characters) make the code much easier to read and they make it extremely trivial to define and understand complicated data structures. Larry Wall, the creator of Perl, got an undergraduate degree in natural and artificial languages and then went on to do graduate work in linguistics. The Wikipedia says:
Wall's training as a linguist is apparent in his books, interviews, and lectures. He often compares Perl to a natural language and explains his decisions in Perl's design with linguistic rationale.
Your comment about Perl seems to boil down to the fact that it is different from languages you are familiar with and you never bothered to learn it so it makes no sense to you. Your gripe about the C struct element seems to be similar, like everyone else in the world, you have trouble reading languages you are not familiar with. I have the same problem with Russian and other languages I have never learned.
BTW, have you ever noticed that nuclear missiles tend to be only targeted at countries that use a different alphabet? Perhaps it is only a coincidence but I think it may be related to your problems with Perl, an oversimplification that equates foreign with bad.
Lee Smolin's brilliant book The Trouble with Physics discussed this issue eight years ago. The book also includes the best introduction to string theory for a scientifically oriented non-physicist I have ever seen.
Smolin concluded the "trouble with physics" is the problem discussed in the article: the current system rewards small incremental steps over creative leaps. He discusses the risk to payoff ratios. He says the current system drums out most truly creative people.
Good points. I think the key concept is called Wing Loading which is the ratio of mass to wing area. For example:
Effect on stability
Wing loading also affects gust response, the degree to which the aircraft is affected by turbulence and variations in air density. A small wing has less area on which a gust can act, both of which [I think they are referring to low area and high mass] serve to smooth the ride. For high-speed, low-level flight (such as a fast low-level bombing run in an attack aircraft), a small, thin, highly loaded wing is preferable: aircraft with a low wing loading are often subject to a rough, punishing ride in this flight regime.
IOW, what matters is the ratio of the mass to the wing area and not just the mass (weight) with no context. For example, if you have two round rocks of roughly the same mass and tie a very light wing to one of them (which makes the masses equal). The one with the wing will be more affected by gusts even though the masses are the same.
Versata chose to steal the code instead of licensing it under the commercial license or the GPL. Just because the GPL allowed the thieves to legally look at the code or use it unmodified does not magically transform this into a nightmare scenario. They are not being forced to either abandon their project or release their own code. They could just buy the commercial license like any responsible grownup would do.
The claim that this is a GPL nightmare scenario is just a stupid lawyer trick to try to fool people into blaming the victim instead of the unscrupulous bastards who stole the code and who still refuse to pay for it even after they were caught red-handed.
Think for a moment what would happen if the unscrupulous bastards prevail. The implications go far beyond the GPL. Imagine you let me see your commercial code without authorizing me to use it or copy it, perhaps through an NDA. Then I steal your code and put it in my products which I sell to a bunch of people. I get caught red handed and I still refuse to pay. Instead I hire a sleaze-ball lawyer who claims this is a nightmare scenario for commercial software licenses and NDAs. If the UBs win here, my lawyer's job becomes much easier because she can use this case as precedent. ISTM a win by the UBs would create a world where simply letting someone see your code dissolves any rights you have to that code.
In addition to what DamnOregonian said, there is another problem with this quest to know what is ACTUALLY happening. For almost all people who voice this desire, "what is ACTUALLY happening" means a model That matches their intuition based on the non-relativistic 3+1 dimensional, classical world of their senses. This ain't gonna happen.
Maybe you misunderstand what the models in theoretical physics actually do. You say we will never understand the models well enough to make accurate predictions. While this may be true of some string theories, but that is a recent phenomenon and a strong deviation from the past. In general physics theories must make disprovable predictions or they are not taken seriously -- they are not physics, just metaphysics.
Whether you like it or not, the underlying theories of the Universe do not match our classical, non-relativistic intuition. But we can still model what happens and make predictions with these models. And people do develop intuitions based on these extremely non-classical models. Almost all progress in physics and math is based on a combination of intuition and turning a crank on complicated mathematical formalisms. Intuition is used for leaping ahead to a possible conclusion which is followed by the grunt work of turning the crank to make sure the intuitive leap was correct. Intuitive leaps are not always correct.
Elliptic paraboloids for sale.
