Why shouldn't templates be used on video game consoles?

Question: I have overhead, several times, that templates should not be used on video game consoles; however, I never heard why, or understood why. Why shouldn't templates be used on video game consoles, and if they are to be used, what are some ways to avoid the negativity?
Answer: There's nothing really specific to consoles that make templates uniquely a bad choice on them. They can certainly be used as a force for good, in appropriate situations. And different people have different reasons to disparage templates. Here are some of the reasons that come to my mind:
Templates can bloat compile times and executable sizes. When you include a standard library header, under traditional C++ compilation models every single file that needs to include that header will end up parsing and instantiating all the templates in it. And that instantiated copy of the template is stored in every object file that uses it. This is less of a big deal in modern times, thanks to our tools—precompiled headers can speed up compilation for massive headers, and linkers can remove duplicate instantiations. Modern compilers can even take separate instantiations that have identical code (vector and vector, for instance) and merge them. But templates can still bloat executable sizes, and can lead to absurdly long compilation times. (This may be one of the cases that is more specific to consoles: the compilers used on consoles can often be less mature than the ones used for PC development.)
Templates are often overused, and lead to overgeneralized code. So you're thinking of writing a vector class. What design choices are you going to make? Well… we're going to need at least 2-vectors, 3-vectors, and 4-vectors. Mostly float vectors, but we'll probably use a few int vectors, and I can't say for sure that we won't need doubles in some cases. So let's make this a vector<T, Size>. Now how about matrices? Well, that's easy: matrix< vector<float, 4>, 4 >. Now one of the most fundamental types in your engine is one of the most complex. Sure, you've got a lot of "power" behind it, but if 99% of the code uses 4x4 float matrices and 4-vectors of floats, you've actually come out behind, because you don't have simple obvious code for the primary case. And if you want to make your vector<float, 4> use SIMD intrinsics, for example, suddenly you have to partially specialize, and write a full 4-vector of floats anyway.
Templates make your error messages incomprehensible. Both compilation errors and linker errors become orders of magnitude more fun to sort through when templates are involved. As a bonus, templates needing to be in headers (sans explicit instantiation) means that any change to a template means that every piece of code that uses that template needs to be recompiled when it changes. Sure, you can compile only one file that uses the template to speed up your compile-test-fix cycle, but you can't be sure that you've caught all the errors with only one instantiation of the template, since many template errors are deferred to the point where they're instantiated.
Templates purport to be future-proof, but rarely are. Properly designing a template to be future-proof is extremely difficult, and by some metrics impossible without being prescient. The standard library containers and algorithms are very carefully designed and are a cut above most templates, but even the standard library is discouraged in most console game engines. Standard library containers have immensely complicated implementations, don't support alignment well, use exceptions everywhere, are difficult to get to work with external allocators, and are difficult to debug. And they're working in a problem space that is usually cited as a good reason to use templates (container types).
Templated code is complicated. Doing the "right thing" when making a template leads to extremely complicated code, as anyone who has browsed a C++ standard library implementation knows. And complicated code is harder to understand, harder to optimize, harder to change, and atrophies more quickly. Templates are huge part of the language with very, very weird corner cases (pop quiz: what's strange about ADL with template functions with explicitly provided template arguments?). Simplicity is huge.
I've probably missed some and overstated others. There are good reasons to use templates, even in console games, but they are frequently (and for good reason) approached with an attitude that starts with suspicion and may eventually work around to grudging acceptance if good reason is provided. But the average console game simply isn't generic enough for templates to be a necessity (console games typically aren't libraries of code, for instance, expected to be used out-of-house), and there are very good reasons to avoid them.
Comment: Immature compilers are the worst thing to have to deal with. However, some of your points are just plain over-engineering. There's nothing specific to templates about your matrix example- it could be equally stated in terms of anything else. Stating that the Standard lib is discouraged as if it's some kind of argument is meaningless, too. Plenty of the downsides you've listed are quite specific to them and not any other template code. Fundamentally, I don't feel that your arguments contain (much) that's true of templates in general, instead of some suboptimal of them.
Comment: Powerful abstraction tools tend to apply to most problem sets :P But there are definitely limits and applying them where they're not appropriate is certainly one of those limitations.
Comment: This post is intended to be a recitation of the reasons I've heard for templates not being used. It's of course entirely possible to avoid code/compilation bloat, to use templates in exactly the right cases, to have a compiler with reasonable error messages, to make templates that are exactly future-proof enough, and to make simple template code. They're a popular feature on a popular language, they aren't *entirely* worthless. But they're a large hammer, and once you know how to use them, *everything* looks like a nail.
Comment: Abstracting over *data* is an incredibly powerful tool that applies to most problem sets. Abstracting over *type* is less so, especially in concrete problems. Templates are fundamentally a tool for simplifying code, so the key litmus test for them is simply to check that the process of writing code gets simpler when templates are used.
Answer: The answer to your question is one thing, but I think you probably meant something slightly different, so I'll answer both.
Using Templates
There is absolutely no reason to avoid templates on a console any more than anywhere else.
Templates by definition only really affect compile time, not runtime.  There is an opportunity for templates to be abused in such a way as to result in bloated machine code, as John Calsbeek's answer describes in some detail.  However, nothing is console specific about any of the potential problems with templates.
To put it bluntly, your choice to use a template or not should be 100% based on whether a template is the correct way to solve the design problem you're working on.  The target platform is entirely irrelevant.  There are numerous AAA engines targeting consoles that make heavy use of templates, in fact.
The problems that are solved well by templates are any pieces of code you write that need to be generic to types.  Containers are an excellent place to use templates.  Utility code that applies to many types -- algorithms, smart pointers/handles, and so on -- are excellent places to use templates.  Even some template meta-programming can come in massively useful for handling script binding, serialization, editor GUI property sheet binding, messaging, and even network packet formation (done right, these techniques will have zero or very near-zero runtime overhead and again, being on a console or not will just not matter).
Standard Template Library
The C++ STL is a somewhat different matter to templates in general.  What you probably heard was that the STL should be avoided on consoles.  In fact, even many PC games avoid much of the STL as well.  While the STL is a very good library for general purpose programming, it has various weaknesses for games.
The STL containers are often poor fits for games as they're designed to be rather broadly applicable rather than targeted at specific needs.  The std::vector container and maybe the std::deque are acceptable as-is, but the majority of the other containers are problematic.
Many implementations of std::map for instance are basic binary trees, and your worst case times with them hence don't suit real-time applications like games.  You're usually better off writing your own red-black tree container since that way you can know for sure you're getting a data structure with an acceptable worst-case lookup/insertion/removal time.
The worst offender of the containers is the std::unordered_map (hash table), whose implementation is defined by the standard to have various properties which are not really all that useful in most real code I've seen (including all game code I've seen).  Those properties basically mandate a suboptimal implementation.  In particular, std::unordered_map is required to not invalidate references to objects on insert/removal, which means that the map cannot use open-addressing, and hence is going to have sloppy memory usage.  The implementation is designed under the assumption that you might be storing expensive to move/copy objects, but in games you'll very rarely be storing anything besides numbers or cheap pointers/handles in these kinds of data structures.
Algorithms like std::sort are implemented in ways that work well in general cases, but which again have abysmal worst-case performance, and honestly just unacceptable average-case performance for the kinds of things that games sort.  Most games will only very rarely sort strings or such, but will sort plain integers very often.  Hence using a radix sort algorithm is quite likely going to be a much better choice.
The normal STL implementations also tend to make Debug builds abysmally slow due to the abstract nature of their implementation and the excessive debugging checks.  EA has an in-house STL implementation that goes out of its way to avoid every unnecessary method call in its internal implementation, so that even in non-inlined debug builds the containers will remain at least reasonably fast.  They submitted a paper to the C++ committe on the topic (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html) and apparently published it to GitHub (https://github.com/paulhodge/EASTL).
The allocator model of the STL is also a pain (for games or any other application), and games in general want to have very explicit control over memory.  Doubly so for consoles.  While this can be worked around with the STL allocator model, it's so painful and obtuse and difficult to use correctly that most games end up using custom container libraries that have non-STL-compliant (but vastly superior for their needs) allocator APIs.
So, it may be desirable to avoid using any normal STL implementation for console games.  Using a template library that is written with games, real-time simulation, and constrained platforms' needs in mind is a very different proposition, however.
Comment: "There is absolutely no reason to avoid templates on a console any more than anywhere else." Consoles tie you to specific old compilers that may (or rather, do) have template-related bugs and misfeatures you can't fix.
Comment: When you talk about `std::sort`, are you talking about a standard-mandated suboptimal implementation, or about a specific implementation, say in msvcrt or libstdc++?
Comment: Also, note that the part of EASTL that is public is a limited chunk (50%-60%).
Comment: @JohnCalsbeek: What "standard-mandated suboptimal implementation" are you talking about? Where are you getting this stuff from? Do you have links to something that says that the C++ standard **mandates** a "suboptimal implementation" of `std::sort`?
Comment: @NicolBolas No, sorry, I've heard absolutely nothing of the sort. I was asking the question because the claim that "algorithms like `std::sort` are implemented that work well in general cases, but … have abysmal worst-case performance" seems very strange to make as a general claim, and I wanted to check to see if the standard mandated something that meant the worst-case performance would be worse than usual.
Comment: @JohnCalsbeek: Every STL implementation I've seen used quicksort, which with a naive implementation can be pretty bad (e.g. sorting already sorted lists with poor pivot selection).  I don't know if the standard mandates quicksort or not, but it definitely does not mandate a particularly clever version of quicksort.
Comment: std::map is mandated to have O(logN) cost insertion and retrieval. They are generally implemented as red-black trees. std::sort, at least today, is generally implemented as introsort, which is NlogN, worst case. You also didn't get into any specifics about allocators, C++11 stateful allocators are extremely flexible and powerful. Most debugging checks I'm aware can be easily disabled based on setting macros. std::priority_queue should also be fine to use.
Comment: I've never seen an implementation of `std::map` that didn't use rb trees. Do you have an example of a major implementation that really uses basic binary trees? By basic do you mean unbalanced?
Comment: @Praxeolitic: I don't know if any use binary trees still. I haven't checked in some time; even a well-implemented RB-tree is still just a _bad choice_ of data structure for (most) needs, at least in games, so I still ban `std::map` usage.
Answer: John mentioned some interesting points but I'd like to clarify some points as I feel some points are biased.
Compile time
I agree that templates can increase compile times. Sometimes it becomes bad enough that you have to take some measures to keep the compile times down (inherit from base code [in a private namespace] that uses void* for data types which the derived template classes then cast to the appropriate type).
You can also force the template to instantiate. This is really useful if the template code is in a library, because then you can instantiate the most common types when compiling the library (which is compiled once) which are ready to use when using said code. Another benefit is that you can now have template code in your source files and not the headers (assuming you know all the types that the code is going to work with... this is usually true with game code as we almost always know what we are working with... it is a closed system). This is great when you know about the types but still want genericity because otherwise you may end up using costly runtime techniques.

As a bonus, templates needing to be in headers

I disagree with this. For one, the above template instantiation will negate that. Another technique is to split up your functions just like you with a header and source file but instead name the source file inl. Commonly, the inl file is included in the header which, after much experience with long compile times and recompile after every small change, I believe is bad practice for all but trivial template classes. What you should do is include the header in the inl file, so it looks exactly like a cpp file, and then include the inl file in your source files. This will reduce the compile times drastically.
Overuse
Templates, like any other technique can be overused. You get a hammer, everything becomes a nail. Although I don't see anything particularly wrong with the Matrix code John mentions.
Error Messages
I agree with John here, that the error messages become hard to read. I also think that that should not be the reason for you to not use templates where they make sense. The error messages from the standard containers are very hard to decipher because of the absolutely awful names that they have chosen. For proof, try to follow the standard vector header and then try to read EASTL's vector header. There is a world of a difference. Next, try EASTL in your code and force an error. The errors no longer seem as daunting as they usually are.
Standard containers
Don't use them (use EASTL instead). Most of the mentioned problems with containers disappear just by doing this. The common reason for not using standard containers is that games generally do not use exception safety and then there is alignment, both of which are solved by using EASTL.
Templated code is complicated
Yes it is. Then again, so is C++ to a programmer who just started using it. There are some corner cases, and some weird areas (not so weird when you understand why it is like that - e.g. when to use typename) but that is any language. C++ template meta-programming is a compile time turing complete language (sublanguage). It is extremely powerful and thus requires quite a bit of learning to do it right.
Static Polymorphism
You can avoid polymoprhism and its runtime disadvantages (memory usage, cache misses by extra indirections) by using templates and the curiously recurring template pattern.
Conclusion
Many will recommend to use templates when they make sense. That is a vague statement. How do you know when it makes sense? Only when you practice it will you start learning when it makes sense and when you went overboard.
Any relatively complex feature of a language goes through the same process. How do you know when to use composition over inheritance or vice versa? There are some rules but mostly it is experience. If you don't use it, you won't gain experience.
My suggestion is that if you are a younger developer (not age wise, but experience wise) then don't shy away from using techniques just because of the bad stigma attached to them. You will not learn how to use the techniques properly down the road, which is very important.
I will give you one last example about multiple inheritance and the diamond problem. I never used multiple inheritance because I was told that there is almost always an alternative and multiple inheritance has quite a few complex issues that result is bad code. Were they right? Yes! But should I have never used them? No! Because once I used it, I ran into issues that made me understand the language even more and the technique even more. Multiple inheritance has its uses (especially in meta-programming) and now I know where to use them.
Answer: While I have not heard the 'do not use templates on a console', I can maybe give a personal experience as to why people may say this.
Working on a very memory limited console, you of course want the compiler to strip out unused code to compact the exe as small as possible. This actually gave us issues on one platform where the compiler would improperly strip out (or just never compile to begin with) pieces of the templates used for the objects. It did not naturally see that those methods were needed so when the run time would execute, it would crash.
We fixed the issue, but this did cause us a bit of code bloat as we had to forcibly declare the template classes. This added a bit more to the code but it ensured that the code we did need would still be there but allow us to still run code stripping as a compilation option.
Hope this helps.
Comment: Interesting point, did not run into this issue myself, but will keep this in mind +1


2 Instances of Tomcat and JBoss on the Same Hardware with Different IP's

Question: I'm trying to setup 2 separate instances of Tomcat and JBoss on the same physical server.  Both instances will use the same ports but will have different IP's (IP#1, IP#2).  Right now I have the first instance of Tomcat and JBoss installed and they work fine.  When I grep the word localhost I see it being used in about a hundred locations within the Tomcat and JBoss internal files.  Since localhost is assigned to 127.0.0.1, and 127.0.0.1 is assigned to the first IP as loopback, do I need to replace "localhost" with the IP address in all of the Tomcat and JBoss files for each instance?
Answer: I may be incorrect, but I do not believe you can have both systems running on the same machine  with the same port number regardless of their ip address. Since they run locally they run off of the host machines ports the ip addresses would resolve to the host server and not be able to distinguish what traffic on the same port needed to be rerouted unless you used apache to proxy the requests to tomcat or jboss.
Use apache to redirect traffic to JBoss
furthermore, how are getting the two systems to run at the same time. One should be complaining about the other having control over the port.

2 Instances of Tomcat and JBoss on the Same Hardware with Different IP’s


Leading from the wrong (nondummy) hand in bridge

Question: While playing bridge you were supposed to lead from the dummy's hand, but you pulled a card from your hand by mistake. After putting it back in your hand, do you have to play the same suit when you play from the dummy hand?
Answer: From the Laws of Contract Bridge - 2014,
Law 55 - Declarer's Lead Out of Turn

When declarer leads out of turn from his or dummy's hand:
  A either defender, without consultation, may accept that lead as provided in Law 53; or
  B. either defender, without consultation, may require declarer to retract that lead. Then,
   1. if it was a defender' turn to lead, declarer restores the card led in error to his or dummy's hand without penalty.
   2. if declarer has led from the wrong hand when it was his turn to lead from his or dummy's hand, he withdraws the card led in error and he must lead a card from the correct hand.
If declarer adopts a line of play that could have been based on information obtained through his infraction, the offenders should adjust the score to redress the damage.

So, in direct answer to your question, and assuming no inappropriate information was obtained by declarer through the infraction, once a defender requires declarer to retract the card led in error declarer restores it without penalty and leads (any card of his choice) from the correct hand.
In a club (other than a Duplicate Club) a slightly more formal alternative law may apply using the services of a pre-appointed Arbiter, if such is available. I understand from your description that this is not the case fr your question.
Answer: In the shortened version:

No, they cannot force you to lead from the same suit in the hand that should have led. But they can "accept" your lead from the wrong hand (or reject it). If the next player plays, that is assumed as an acceptance (whether that player was alert or not about the play out of turn).

Declarer should not draw an "inference" from the opponents willingness or not to accept the lead.
In general, there is no "damage" to the opponents because your partner is dummy and cannot gain any advantage by knowing about you holding a certain card.


Why are null references shunned while throwing exceptions is considered okay?

Question: I don't quite understand the consistent bashing of null references by some programming language folks. What's so bad about them? If I request read access to a file that doesn't exist then I'm perfectly happy to get an exception or a null reference and yet exceptions are considered good but null references are considered bad. What's the reasoning behind this?
Comment: Some languages crash on null better than others. To a "managed code", such as .Net / Java a null ref is just another type of problem, whereas other native code might not handle this as gracefully (you have not mentioned a specific language). Even in a managed world, sometimes you want to write fail-safe code (embedded?, weapons?), and sometimes you want to bitch loudly ASAP (unit testing). Both types of code could be calling into the same library - that would be a problem. In general I think that code which tries not to hurt computers feelings is a bad idea. Fail-safety is HARD anyway.
Comment: Related: http://stackoverflow.com/questions/3989264/best-explanation-for-languages-without-null
Comment: @Job: This is advocating laziness. If you know how to handle an exception, you handle it. Sometimes that handling might involve throwing another exception, but you should *never* be letting a null reference exception go unhandled. Ever. That is every maintenance programmer's nightmare; it's the most useless exception in the entire tree. [Just ask Stack Overflow](http://stackoverflow.com/search?q=%2Bnullreferenceexception).
Comment: or to put it another way - why not return a code of some sort to represent error information. This argument will rage for years to come.
Answer: Null references aren't "shunned" any more so than exceptions, at least by anyone I've ever known or read.  I think you're misunderstanding the conventional wisdom.
What's bad is an attempt to access a null reference (or dereference a null pointer, etc.).  This is bad because it always indicates a bug; you would never do something like this on purpose, and if you are doing it on purpose, then that's even worse, because it's making it impossible to distinguish expected behaviour from buggy behaviour.
There are certain fringe groups out there who just really hate the concept of nullity for some reason, but as Ed points out, if you don't have null or nil then you'll just have to replace it with something else, which might lead to something worse than a crash (such as data corruption).
Many frameworks, in fact, embrace both concepts; for example, in .NET, a frequent pattern you'll see is a pair of methods, one prefixed by the word Try (such as TryGetValue).  In the Try case, the reference is set to its default value (usually null), and in the other case, an exception is thrown.  There's nothing wrong with either approach; both are used frequently in environments that support them.
It really all depends on the semantics.  If null is a valid return value, as in the general case of searching a collection, then return null.  On the other hand, if it is not a valid return value - for example, looking up a record using a primary key that came from your own database - then returning null would be a bad idea because the caller won't be expecting it and probably won't check for it.
It's really very simple to figure out which semantic to use: Does it make any sense for the result of a function to be undefined?  If so, you can return a null reference.  If not, throw an exception.
Comment: Actually there are languages that don't have null or nil and do not "need to replace it with something else". Nullable references imply that there might be something there, or there might not be. If you simply require the user to explicitly check if there is something there, you have solved the problem. See haskell for a real life example.
Comment: @ErikKronberg, yes, the "billion dollar mistake" and all that nonsense, the parade of people trotting this out and claiming it to be fresh and fascinating never ends, that's why the previous comment thread was deleted. These revolutionary replacements people never fail to bring up are always some variant of the Null Object, Option or Contract, which don't actually magically eliminate the underlying logic error, they just defer or promote it, respectively. Anyway, this is obviously a question about programming languages which *do* have `null`, so really, Haskell is pretty irrelevant here.
Comment: @ErikKronberg: Yes, I am "seriously arguing" that having to test for null isn't particularly different from (a) having to design every tier of an application around the behaviour of a Null Object, (b) having to pattern-match Options all the time, or (c) not allowing the callee to say "I don't know" and forcing an exception or crash. There's a *reason* why `null` has endured so well for so long, and the majority of the people who say otherwise seem to be academics with little experience designing real-world apps with constraints like incomplete requirements or eventual consistency.
Comment: @Aaronaught: Sometimes I wish there was a downvote button for comments.  There is no reason to rant like that.
Comment: are you seriously arguing that not requiring a test for null is as good as requiring it?
Comment: **Commenters:** comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this question with others, please use [chat](http://chat.stackexchange.com/rooms/21/programmers). See [the FAQ](http://programmers.stackexchange.com/faq) for more information.
Comment: Now please don't reply to this any more, take it to [chat] if it's that important and let people opt-in to the rant instead of assaulting them with comments on answers that have nothing whatsoever to do with your pet peeve.
Answer: The big difference is that if you leave out code to handle NULLs, your code will continue on quite possibly crashing at a later stage with some unrelated error message, where as with exceptions, the exception would be raised at the initial point of failure (opening a file for reading in your example).
Comment: Failure to handle a NULL would be willful ignorance of the interface between your code and whatever returned it.  Developers who would make that mistake would make others in a language that doesn't do NULLs.
Comment: @Blrfl, ideally methods are quite short, and thus it is easy to figure out exactly where the problem is happening. A good debugger can usually hunt a null reference exception well, even if the code is long. What am I supposed to do if I am trying to read a critical setting from a registry, which is not there? My registry is messed up and I am better of failing and annoying the user, than silently recreating a node and setting it to default. What if a virus did this? So, if I get a null, should I throw a specialized exception or just let it rip? With short methods what is the big difference?
Comment: @Job: What if you don't have a debugger? You do realize that 99.99% of the time your application is going to be running in a release environment? When that happens, you're going to wish that you'd used a more meaningful exception. Your app may still have to fail and annoy the user, but at least it will output debug information that will enable you to *promptly* track down the issue, thus keeping said annoyance to a minimum.
Comment: @Birfl, sometimes I don't want to handle the case where a null would be natural to return. For example, suppose I have a container mapping keys to values. If my logic guarantees that I never attempt to read values I didn't first store, then I should never get null returned. In that case, I'd much rather have an exception which provides as much information as possible to indicate what went wrong, rather then returning a null to fail mysteriously someplace else in the program.
Comment: To put this another way, with exceptions I have to explicitly handle the unusual case or else my program dies right away. With null references if the code doesn't explicitly handle the unusual case, it will try to limp on. I think it better to take the fail now case.
Comment: @Job:  Methods should _work_ first.  The industry term for something that doesn't handle unusual results in the name of keeping a method short is "busted code."  The industry term for having to correct a problem in production that was intentionally ignored during development is "professionally embarrassing."  To put it another way: I warn you that I'm about to hand you a red-hot poker and you grab it without finding the cool end, you run a good chance of getting burned.
Comment: @Winston Ewert:  If the container doesn't throw exceptions and you want them (and there's nothing wrong with that), subclass it, make it throw exceptions and use the subclass.  Then you've covered your bases.  Problem solved.
Comment: @Birfl, or I could use a language which throws exceptions by default and get the same effect without subclassing. I just don't see any case where I'd rather have invalid values like nulls returned rather then an exception.
Answer: Because null values are not a necessary part of a programming language and are a consistent source of bugs.  As you say, opening a file may result in failure, which could be communicated back as either a null return value or via an exception.  If null values were not allowed then there is a consistent, singular way to communicate failure.
Also, this is not the most common issue with nulls.  Most people remember to check for null after calling a function which may return it.  The problem crops up far more in your own design by allowing variables to be null at various points in your program's execution.  You can design your code such that null values are never allowed, but if null were not allowed at the language level none of this would be necessary.
However, in practice you would still need some way to signify if a variable is or is not initialized.  You would then have a form of bug wherein your program does not crash, but instead continues along using some possibly invalid, default value.  I honestly don't know which is better.  For my money I like to crash early and often.
Comment: @Jim Balter: I suppose I am confused as to how it would really help in practice though.  In any non-trivial program you will have to at some point deal with values that may not be initialized.  So, there must be some way to signify a default value.  As such, you still have to check for this before going on.  So, instead of a potential crash, you are now potentially working with invalid data.
Comment: Jim Balter: Right, I'm not actually advocating no-nulls, just throwing out the reasons I could think of in favor of it.
Comment: You also know what happened when you get `null` as a return value:  The information you requested doesn't exist. There's no difference. Either way, the caller has to validate the return value if it actually needs to use that information for some particular purpose. Whether it's validating a `null`, a null object, or a monad makes no practical difference.
Comment: @Jim Balter: Right, I still don't see the practical difference, and I don't see how it makes life easier for people writing real programs outside of academia.  Doesn't mean there aren't benefits, simply that they do not seem evident to me.
Comment: I've explained the practical difference with an Uninitialized class twice -- it identifies the origin of the null item -- making it possible to pinpoint the bug when a dereference of null occurs. As for the languages designed around null-less paradigms, they avoid the problem from the get-go -- they provide alternate ways to program.that avoid uninitialized variables; that may seem hard to grasp if you aren't familiar with them. Structured programming, which also avoids a large class of bugs, was also once considered "academic".
Comment: Consider an Uninitialized subclass with an identifying string, and all its methods throw exceptions. If one of these ever shows up, you know what happened. On embedded systems with limited memory, the production version of the Uninitialized factory can just return null.
Comment: I *am* advocating no nulls -- along with Tony Hoare, who invented null pointers in the first place, and a lot of other people who have given careful consideration to the issue. I recently read a thesis defining a variant of Java that does not contain nulls at all -- there are some very tricky issues about initializing recursive structures, but work is being done on it.
Comment: I already answered this, in two different ways: a) "If one of these ever shows up, you know what happened" -- if you encounter one of these, you have details as to what didn't get set, rather than the uninformative raw null value. a) "there are some very tricky issues about initializing recursive structures, but work is being done on it" -- it is possible to write arbitrarily complex programs with no uninitialized variables. Consider every program ever written in Haskell or any other pure functional language -- variables never change their values, so "uninitialized" is meaningless.
Answer: Tony Hoare, who created the idea of a null reference in the first place, calls it its one million dollar mistake.
The problem is not about null references per-se, but about the lack of proper type-checking in most (otherwise) type safe languages.
This lack of support, from the language, means that bugs "null-bugs" may be lurking in the program for a long time before being detected. Such is the nature of bugs, of course, but the "null-bugs" are now known to be avoidable.
This problem is especially present in C or C++ (for example) because of the "hard" error that it causes (a crash of the program, immediate, with no elegant recovery).
In other languages, there is always the question of how to handle them.
In Java or C# you would get an exception if you attempt to invoke a method on a null reference, and it might be okay. And therefore most of Java or C# programmers are used to this and don't understand why one would want to do otherwise (and laugh at C++).
In Haskell, you have to explicitly provide an action for the null case, and therefore Haskell programmers gloat at their colleagues, because they got it right (right ?).
It is, really, the old error-code / exception debate, but this time with a Sentinel Value in lieu of error-code.
As always whichever is most appropriate really depends on the situation and the semantics you are looking for.
Comment: Precisely. `null` really is evil, because it **subverts the type system**. (Granted, the alternative has a drawback in its verbosity, at least in some languages.)
Answer: You can't attach a human-readable error message to a null pointer.
(You can, however, leave an error message in a log file.)
In some languages/environments which allow pointer arithmetic, if one of the pointer argument is null and it is allowed into the calculation, the result would be an invalid, non-null pointer. (*) More power to you.
(*) This happens a lot in COM programming, where if you try to call into an interface method but the interface pointer is null, it would result in a call to an invalid address that is almost, but not quite, exactly unlike zero.
Answer: Returning NULL (or numeric zero, or boolean false) to signal an error is wrong both technically and conceptually.
Technically, you're burdening the programmer with checking the return value right away, at the exact point where it is returned. If you open twenty files in a row, and the error signalling is done by returning NULL, then the consuming code must check each file read individually, and break out of any loops and similar constructs. This is a perfect recipe for cluttered code. If, however, you choose to signal the error by throwing an exception, the consuming code can choose to handle the exception immediately, or let it bubble up as many levels as appropriate, even across function calls. This makes for much cleaner code.
Conceptually, if you open a file and something goes wrong, then returning a value (even NULL) is wrong. You don't have anything to return, because your operation didn't finish. Returning NULL is the conceptual equivalent of "I've successfully read the file, and here's what it contains - nothing". If that's what you want to express (that is, if NULL makes sense as an actual result for the operation in question), then by all means return NULL, but if you want to signal an error, use exceptions.
Historically, errors were reported this way because programming languages like C don't have exception handling built into the language, and the recommended way (using long jumps) is a bit hairy and kind of counter-intuitive.
There's also a maintenance side to the problem: with exceptions, you have to write extra code to handle the failure; if you don't, the program will fail early and hard (which is good). If you return NULL to signal errors, the default behaviour for the program is to ignore the error and just carry on, until it leads to other problems down the road - corrupt data, segfaults, NullReferenceExceptions, depending on the language. To signal the error early and loudly, you have to write extra code, and guess what: that's the part that gets left out when you're on a tight deadline.
Answer: As already pointed out, many languages don't convert a dereference of a null pointer into a catchable exception. Doing that is a relatively modern trick. When the null pointer issue was first recognised, exceptions hadn't even been invented yet.
If you allow null pointers as a valid case, that is a special case. You need special-case handling logic, often in lots of different places. That's extra complexity.
Whether it relates to potentially null pointers or not, if you don't use exception throws to handle exceptional cases, you must handle those exceptional cases some other way. Typically, every function call must be have checks for those exceptional cases, either to prevent the function call being called inappropriately, or to detect the failure case when the function exits. That's extra complexity that can be avoided using exceptions.
More complexity usually means more errors.
Alternatives to using null pointers in data structures (e.g. to mark the start/end of a linked list) include using sentinel items. These can give the same functionality with a lot less complexity. However, there can be other ways to manage the complexity. One way is to wrap the potentially null pointer in a smart pointer class so that the null checks are only needed in one place.
What to do about the null pointer when it's detected? If you can't build in the exceptional-case handling, you could always throw an exception, and effectively delegate that special-case handling to the caller. And that's exactly what some languages do by default when you dereference a null pointer.
Answer: Specific to C++, but there null references are shunned there because null semantics in C++ are associated with pointer types. It's quite reasonable for a file open function to fail and return a null pointer; in fact the fopen() function does exactly that.
Comment: Indeed, if you find yourself with a null reference in C++, it is because your program is *already broken*.
Answer: It depends on the language.
For instance, Objective-C allows you to send a message to a null (nil) object without problems. A call to nil returns nil as well and is considered a language feature.
I personally like it since you can rely on that behavior and avoid all those convoluted nested if(obj == null) constructs.
For instance:
if (myObject != nil && [myObject doSomething])
{
    ...
}

Can be shortened to:
if ([myObject doSomething])
{
    ...
}

In short, it makes your code more readable.
Answer: I don't give a hoot whether you return a null or throw an exception, as long as you document it.
Comment: And also *name* it: `GetAddressMaybe` or `GetSpouseNameOrNull`.
Answer: A Null reference usually occurs because something in the program logic was missed, ie: you got to a line of code without going through the required set-up for that block of code.
On the other hand, if you throw an exception for something it means that you recognized that a particular situation could occur in normal operation of the program, and it's being handled.
Comment: A null reference can "occur" for a great number of reasons, very *few* of them pertaining to anything being missed.  Maybe you are also getting it confused with a null reference *exception*.
Answer: Null references are often very useful: For example, an element in a linked list can have some successor or no successor. Using null for "no successor" is perfectly natural. Or, a person can have a spouse or not - using null for "person has no spouse" is perfectly natural, much more natural than having some "has no spouse"-special value that the Person.Spouse member could refer to.
But: Many values are not optional. In a typical OOP program, I'd say more than half of the references can't be null after the initialization, or the program will fail. Otherwise the code would have to be riddled with if (x != null) checks. So why should every reference be nullable by default? It should really be the other way round: variables should be non-nullable by default, and you should explicitly have to say "oh, and this value can be null, too".
Comment: is there anything from this discussion you'd like to add back to your answer? This comment thread got a little heated, and we'd like to clean this up. Any extended discussion should be taken to [chat](http://chat.stackexchange.com/rooms/21).
Comment: In the midst of all that bickering there could have been one or two points of actual interest. Unfortunately I didn't see Mark's comment until I pruned back the extended discussion. In the future please flag your answer for moderators attention if you would like to preserve the comments until you have time to review them and edit your answer appropriately.
Answer: Your question is confusingly worded. Do you mean a null reference exception (which is actually caused by an attempt to dereference null)? The clear reason to not want that type of exception is that it gives you no information as to what went wrong, or even when -- the value could have been set to null at any point in the program. You write "If I request read access to a file that doesn't exist then I'm perfectly happy to get an exception or a null reference" -- but you should not be perfectly happy to get something that gives no indication of the cause. Nowhere in the string "an attempt was made to dereference null" is there any mention of reading or of non-existing files. Perhaps you mean that you would be perfectly happy to get null as a return value from a read call -- that's a quite different matter, but it still gives you no information about why the read failed; it's much better to receive either an error object that details the nature of the error, or to have such an error object thrown (note the distinction, and possible confusion, between an Exception, which is a object, and an exception, which is an event that results in throwing such an object).
Comment: *"...but instead use **wrapper objects that can optionally contain a value**."* Which is clearly *nothing* like a *nullable type*.
Comment: In haskell there is no such thing as an uninitialized variable. You could potentially declare an IORef and seed it with None as an initial value but that's pretty much the analog of declaring a variable in some other language and leaving it uninitialized which brings with it all the same problems. Working in the purely functional core outside the IO monad haskell programmers have no recourse to reference types so there is no null reference problem.
Comment: If you have an exceptional "Missing" value, that is precisely the same as an exceptional "null" value - *if* you have the same tools available to handle it. That's a significant "if". You need extra complexity to handle that case either way. In Haskell, pattern matching and the type system provides a way to help manage that complexity. However, there are other tools for managing complexity in other languages. Exceptions are one such tool.
Comment: No, I don't mean a null reference exception. In all the languages I know uninitialized but declared variables are some form of null.
Comment: But your question was not about uninitialized variables. And there are languages that do not use null for uninitialized variables, but instead use wrapper objects that can optionally contain a value -- Scala and Haskell, for example.
Comment: Wrong, they serve the same purpose: a nullable variable of type T has one of two values, null or t, whereas an Optional has one of two values, Missing or Present(t); a binary decision can be made for either, but for an Optional, since the value is a valid object in both cases, a method of Optional can be called regardless of the value (Present or Missing, which are both subclasses of Optional). For examples of how this sort of thing can be used in Scala, see http://blog.tmorris.net/scalaoption-cheat-sheet/
Comment: "In haskell there is no such thing as an uninitialized variable" -- Yes, I said that explicitly in another comment here, and implied it in my comment above. "which brings with it all the same problems" -- not if one properly uses Haskell idioms.
Comment: Driveby downvote of a 5 year old answer, with no explanation, is a symptom of sociopathy.


Masturbating while thinking of someone

Question: If I am very hot and horny (sorry for language) and I want to have sex with somebody. Instead of this to stop myself for doing zinaa I'm going to masturbate. According to fiqh it is better to do the less bad one. So masturbating shouldn't be that bad in this situation. I know looking at sexual videos is haraam, but to stimulate myself is it also haraam to think about someone (in a sexual way) you know or have seen in real life to stimulate yourself or is this also haraam?
Comment: Possible duplicate of [Is it haram to visualize having sex?](http://islam.stackexchange.com/questions/12901/is-it-haram-to-visualize-having-sex)
Comment: You seem to be unmarried, so why don't you try fasting? It's very effective. Better still, find a good girl and get married lest this habit harms your character permanently.
Comment: Very likely an addiction. Please do see "[Hypersexuality, nymphomania and related medical conditions](http://islam.stackexchange.com/a/30120/9123)". I hope it helps. Masturbation is considered haram according to many scholars.
Answer: Masturbation in form of self-stimulation is forbidden in Shi'ah fiqh. While describing the believers, the Qur'an says,

"The believers are... those who protect their sexual organs except from their spouses... Therefore, whosoever seeks more beyond that [in sexual gratification], then they are the transgressors." (23:5-6)

The last sentence makes it very clear that any sexual gratification outside marriage is considered a transgression of the law of God.

Masturbating while thinking of someone


Unvisible Sending of NAGA coins from Myetherwallet

Question: It's the first time for me to send tokens out of myetherwallet.
Yesterday I send some NAGA coins from myetherwallet to the exchange HitBTC platform. Everything is going fine with creating transaction and the NGC should be on pending but they're not. I can't see them on the pending transactions and the coins are somehow still in my token wallet. As I tried to send them again, it says that I do not have enough NGC token to send.
So are they on the way? Why can't I see the transaction?
Regards
Kessy
Comment: Hi there. Was a transaction hash generated to first time you tried to send them? What is the address you're sending them from?
Comment: Hi Richard. The sending adress/my address is: 0xA468c4Da12928dBCCB6DE84F07753ba4076ACeEB
Comment: No, i tryed ti send them few times, but because of the fees, it didn't work. Later it works and it went as transaction complete or something like that.
Comment: I have problems too, cant see my NAGA coins (14) and there no transaction record.
Answer: I think you do not have enough ether to pay for the transaction gas.
The last few transfers show

37458 gas at 23 Gwei gives 0.000861534 Ether ($1.01)
37458 gas at 40 Gwei gives 0.00149832 Ether ($1.76)
37458 gas at 20 Gwei gives 0.00074916 Ether ($0.88)

And the balance in your address is  0.00014995 Ether ($0.18)
Comment: Thx Ismael, case solved. I sent them again with maximal gas :)
Comment: Hi Ismael, yes, now I dont have enough ETH to send it but before I sent to ETH out, I had enough to pay the gas so I made the transaction. It's so confusing. What's the best thing I can do to get this NGC out of this wallet?
Comment: To move the NGC tokens you need to pay for the gas, if you do not have enough ether you will not be able to move the tokens. Transfer some ether and move your tokens, then move the remaining ether to some other account.


What is the "theory" behind "odd time signatures"?

Question: There are a number of bands, Genesis, The Police, Crack the Sky, Gentle Giant, that have all incorporated unusual time signatures as their core sound - some entire "pop"songs, "Ordinary World - Duran Duran; Money- Pink Floyd; Texas Flood (intro)=- SRV, have even made it an integral component.  What is the theory behind not playing in the usual 4/4 time, because I would like to be able to write a song based on a different time signature..
Comment: Why do you think there is a particular theory behind them?
Comment: Minor point: time signature is a notational device which often (but not always) implies the meter. Your question is actually about the meter, not about how that happens to be denoted.
Comment: Ordinary World is in 4/4 throughout. Prove it to yourself by counting the beats.
Answer: While I really wouldn't consider Texas Flood as having an odd time signature (12/8 is really just a representation of a triplet swing feel over 4/4), many of the songs/bands you mentioned do use bizarre time signatures for effect.
Let's take Money by Pink Floyd as an example. It is in 7/4 which is nicely outlined by a strong bass line. The rhythm for the bass line is approximated with:

    | 1   2   3   4   5   6   7  |
    | Q   E E Q   Q   Q   Q   Q  |

Now, the easiest way (I think), to break this down is into two chunks: one 3/4 and one 4/4. Now, the order isn't as important when composing because 4/4 + 3/4 is effectively the same in the end as 3/4 + 4/4. But for this tune, it works better like so:

    | 1   2   3  | 1   2   3   4  |
    | Q   E E Q  | Q   Q   Q   Q  |

So we have a little snappier 3/4 section, with a 4/4 section that walks back up to the tonic which gives it a more stable feel than most strange times signatures. As with most oddly timed tunes, Money is very much riff based. Take a look at Take Five by Dave Brubeck for another good example of riffing during an odd time signature.
Basically, when composing your own tune, try to put together two shorter odd time signatures first to compose an interesting riff that feels stable and sounds interesting. Two odd meters can also combine to create a normalish meter as well (5/4 + 3/4 = 8/4 or 2 4/4).
Comment: Good, but grouping _Money_ into 4/4 followed by 3/4 feels more natural to me.
Comment: To me Money *feels* more like 1 2 3 4, 1 2 3 (4/1)  2 3 4, 1 2 3 (4/1) 2 3 4, 1 2 3... etc in other words the last beat of each phrase is also the first beat of the next phrase. Don't know if there is any 'official' terminology for that effect.
Comment: A strong argument for the 4+3 interpretation is the drum beat: `B S B S` `B S S` – basically the two simplest, most common drum patterns for ⁴/₄ and ³/₄, respectively. With 3+4, you would instead have blocks `B S B` `S B S S`, the latter of which would be really unusual – I've never heard a ⁴/₄ rock song with that groove.
Answer: I recommend listening to Dave Brubeck's Time Out.  That whole record is an exploration of odd time signatures and unusual ways of subdividing rhythms, but in a way that still swings.  Three of the more famous tracks, for example, are:

"Blue Rondo a la Turk": This is in 9/8, which is an old time signature dating back to the Baroque period, used when a composer wanted a triplet feel in 3/4 time.  What makes this song different is that instead of the usual 3-3-3 break-down, Brubeck subdivides the beat into 2-2-2-3, which gives it a totally different feel.
"Take Five": This is in 5/4, subdivided into 3-2.  You've heard this song a million times, even if you didn't know it.  It's in every commercial that's trying for a "sophisticated luxury" feel.  It isn't easy to make 5/4 sound mainstream, but this song does it.
"Three To Get Ready": This has a pattern of changing time signatures throughout the song.  It's two bars of 3/4 followed by two bars of 4/4, then back to two bars of 3/4, then 4/4, etc.  The drumming is interesting here: Joe Morello basically just brushes a 3/4 pattern on the snare during the whole song, but in the 4/4 bars it starts to syncopate, which then causes it to be "out of phase" in the 3/4 bars, gradually coming back into phase later.

Anyway.  It's a great record and a wonderful collection of odd time experiments.
Answer: I'm a big, big fan of odd time signature. The thing is, there is not really any theory that I know of, it's all notation and counting/feeling, and notation is convention. Basically, the idea is you have a X/Y time signature, meaning you have X elements of value Y (generally 1/4 or 1/8 notes). That's about it.
While Bryan's answer is perfectly valid, my approach is slightly different : I tend to think of them as patterns in themselves, or relating to other patterns, but not thinking of them as a composition of patterns. Let me explain.
If you have a 7/8 pattern, chances are the accentuations, the general groove, is related to either a 4/4 pattern minus a 1/8, creating a syncopation. Or it could be a 6/8 beat with an added 1/8.
Sometimes the pulse is at odds with the basic element  : the notation introduces the denominator as a basic element, which may or may not relate to the pulse of the music. In the case of a 4/4 "mangled" into 7/8, you probably will have a strong feeling of a 1/4 pulse with an abrupt ending at the end of the bar. This would in fact have to be written 3,5/4 except 1) there is no such notation, 2) if we were to invent it, it would only be confusing.
Sometimes, the pulse will depend on the instrument : you frequently have a drum beat in, say, 7/4, over two bars of 7/8 on the guitar, and I would not call that a polyrhythm.
Also, you can have a 4/4 measure which is in fact two odd beats put together (off the top of my head, I'd say the end of Holy Water rom Soundgarden's Badmotorfinger : 3/4 + 5/4 = two bars of 4/4), as Bryan pointed out. Once again, it's far easier to write and read this way.
As cliché as it sounds, it's all about the music. Try playing written patterns, try to find the pulse on a strange riff and write it down, play with others and I guarantee you'll have fun. I know I did and still do.
Comment: Boy do I sound clumsy. Writing about rhythm really *is* like fishing about architecture.
Comment: I think it's a good answer. Tool's schism would be a great song to learn to see some of this in action.
Comment: There's a good chance that just about any Tool song would be a good example. Intolerance, Third Eye, The Pot, Forty Six & 2... Also Them Bones by AiC, 2/3 of everything Soundgarden and possibly 98% of all King Crimson and Mahavishnu.
Answer: Things are getting way off-topic here (although it's a fascinating discussion). The initial question was: "What is the theory behind not playing in the usual 4/4 time"?
Who says 4/4 time is "usual"? Most musical phrases and thus time signatures are ultimately based on dance rhythms. Surely you've heard of the waltz? it's in 3/4 time. The minuet is in 6/8 time. There are many folk dances of many cultures that are not in 4/4 time. Folk dance rhythms and drumming rhythms in African cultures are in multiple different time signatures simultaneously; these are called "polyrhythms".
On the other hand, the most widely recognized ancestor of all the melodies in Western culture are the Gregorian chants. These have no rhythm and no time signature at all.
The use of odd-time signatures, and frequently changing time signatures from measure to measure, came into popular Western music in the late 1800s and early 1900s through classical music pieces written by composers including Bela Bartok, Igor Stravinsky, and others.
I've looked into it, and it's my conclusion that complex changing time signatures got into rock when rock musicians in bands like The Nice, Emerson, Lake and Palmer, Genesis and Yes were influenced by composers like Stravinsky, Bartok and all those that followed them. Rock musicians listened to serious classical music and they took some of those ideas and applied them to different forms. It did not necessarily require that the rock musicians involved actually read sheet music or study it in a classroom; they heard classical music on recordings and on radio broadcasts and they decided to use these ideas when writing their own original music.
Comment: "[Gregorian chants] have no rhythm and no time signature at all." - It most certainly does have rhythm. I'm actually not sure whether it can be truly called music if it doesn't have rhythm. What Gregorian chant does not have, is a meter. And because it doesn't have a meter, it does not have or need a time signature nor barlines.
Comment: @RolandBouman Well, yes, anything has a rhythm if it's happening in time, but I think Wheat meant that it has no specified rhythm and (we're fairly certain) would have been fairly different from performance to performance. The prevailing expert opinion seems to be that they more or less followed the natural rhythms of the text, but it's difficult to say.
Comment: @PatMuchmore perhaps it sounds like I'm nitpicking but I think the correct way to say it is that in this kind of music there is no *meter*: there's is rhythm but it is not a regularly recurring pattern.
Comment: @RolandBouman Right, it definitely has no meter. But the neumatic notation of Gregorian Chant also does not indicate rhythm beyond the occasional sign that we think meant to slow down. Until later innovations in the late Medieval period, there was no way to notate duration either absolutely or relatively beyond order of pitches. As such, modern scholars are fairly certain that any two performances of a particular chant would have been rhythmically quite different. Again, you're right that there would have to be a rhythm in any given performance, but there was no explicit, specific rhythm.
Answer: Time signatures are all about counting beats between accents. We count to a number, with the ONE having the strongest accent (this is oversimplifying a bit -- for example some reggae feels emphasise the third beat of a 4/4 rhythm more than the first).
Humans like rhythms based on an even number of beats, because we have two legs and two arms. If you listen to a piece in 2/2 or 4/4, while walking or running, you'll find yourself easily falling into step with the music, and when a bar finishes, you're back on the leg you started with.
12/8 shouldn't be considered "odd". It is almost always played such that you can count a 4/4 beat over the top of it, with the 12/8 beats being triplets.
It sounds as if 3/4 would be "peculiar" by my "two legs" logic above, and to a small extent it is. But even in 3/4, conventional composers tend to create phrases using 2, 4, 8, 16 bars. People tend to play/perceive 3/4 bars in pairs ("ONE two three TWO two three"), and again, if you walk to to this rhythm, you find yourself back on the original foot at the end of that pattern.
Now to the question, "what is the theory behind not playing in 4/4 time?"
It is simply a matter of counting to 5, 7, 9, 11, or whatever your chosen number of beats is, then starting again from 1, ensuring that you keep the beats even as you would with 4/4.
At first, try just tapping with your fingers. Thumb for the down beat, a finger for the others. At first you are likely to find it difficult. Most people, I believe, attempting to tap out a 5/4 rhythm for the first time, will feel a strong urge to pause for a beat after the 5, bringing it to a more conventional 6 beats.
It will help, of course, to count along to a recording of an existing piece, such as Take 5 (5/4), Money (7/8, 4/4 for the middle section), Radiohead's 15 step.
Watch out, also, for compositions which throw in the occasional bar in a different signature to the rest (15 Step might be an example).
Once you've got the hang of that, it's "simply" a matter of creating your own riffs and melodies that fit with one of those time signatures. The songs you've mentioned pull off the clever trick of sounding natural; people tend to be able to move their shoulders to Money without being thrown off by the time signature.
As with many things, the best way to get good at it is to try it, do a crappy job, then try it again, and keep going until you get a result you're pleased with.
Answer: I would argue that 4/4 time is not the "usual" time for music, it's just that your musical influence tends that way.  The music and composer dictate the time and the feel.  Listen to a seminal rock band like Rush.  They didn't sit down and say "let's make a complex time piece of music to really stimulate theorists."  They chose a melody and a feel and built from there.
If your compositions are pop-focused and you are specifically looking to write "hits" then there are formulae and workshops to learn that.
If your compositions are about getting music from your head into the world then go for it.  Create the music that feels right.  The right melodies, harmonies, and rhythms.  Then you may or may not have complex time.
Comment: Do you know for a fact Rush didn't try to write pieces that were complicated for the sake of complexity alone?
Comment: A quick sample of western music would suggest that 4/4 is very much the "usual" time for music, with 12/8 and 3/4 some way behind.
Answer: I read comments in here talking about 5/8 7/8 and 9/8 (with 9, I mean 4+5 and not 3+3+3) as metric structures "developed" and used by some progressive musicians. For somebody trained as a classical Western musician, it may seem so; but actually here in Turkey and throughout the whole Balkan area, including Asia minor (Turkey, Bulgaria, Greece, Albania, Macedonia; Kosova, etc.) we have all of these meters as part of our traditional folk musics and ordinary people dance to these meters in weddings! These meters are termed as "aksak" meters (means "irregular" in Turkish) and they are easy to internalise if you perceive them as combinations of 2/8 and 3/8. The music also reinforces this grouping idea with accentuation.
Then you have all these different combinations: (all of them exist whereas the most frequently used are the ones where 3 is at the end): 5/8 (2+3 or 3+2); 7/8 (2+2+3 or 2+3+2 or 3+2+2) and 9/8 (2+2+2+3 or 2+2+3+2 or 2+3+2+2 or 3+2+2+2).
Answer: Music can be expressed anyway you like.
Written notation and music theory are convention and language that attempt to represent the music.
That being said I will attempt to address your question, based on Western music notation and terminology.
The confusion and variety of answers to your question, "What is the 'theory' behind 'odd time signatures'?", seems to stem from various interpretations of the term "odd".
Some of the answers are interpreting the word "odd" to mean unfamiliar or simply different than mainstream 4/4.
Other answers being offered are focusing on the number of beats in the time signature and are using the word "odd" to describe what could also be termed as "irregular", which may be less ambiguous.
First let's look at the denotative meaning of "odd" as it pertains to music theory and time signatures.
By definition (music theory definition in terms of Western music notation) there are a finite number of ways (or combinations) to count the number of beats and to subdivide those beats.
If you are using the term "odd" as the opposite of "even" (and not odd as in strange or unfamiliar, or odd as in irregular), then this applies to the subdivisions of a single beat, or the pulse grouping.
In subdividing a beat into pulses there is only odd or even.
Even means dividing the beat into two equal parts (or groupings of two) and the term for this is called "simple".
Odd means dividing the beat into three equal parts (or groupings of three) and the term for this is "compound".
The terms for the number of beats (which is denoted by the denominator in a time signature) are:
duple = two beats
triple = three beats
quadruple = four beats
Taking all combinations of {simple, compound} with {duple, triple, quadruple} yields all the "regular" time signatures:

simple duple
simple triple
simple quadruple
compound duple
compound triple
compound quadruple

Examples time signatures (all of these are "regular"):

simple duple =  2/2 (cut time), 2/4, 2/8
simple triple = 3/2, 3/4, 3/8
simple quadruple = 4/2, 4/4, 4/8
compound duple = 6/8
compound triple = 9/8
compound quadruple = 12/8

Anything else that does not fit into the above categories has many names such as

complex, asymmetric, irregular, unusual, and yes "odd".

Examples of irregular:
5/8, 7/4, 7/8, etc...
For these types, all of these meters must at some point be broken down. A decision must be made as to how they should be counted and grouped, which determines what beats are stressed or accented.
Proof of this is the varying opinions on how to count Pink Floyd Money.
Some say,  it is 3/4 + 4/4.
Others say it is 4/4 + 3/4.
Another seems to say it is a crippled 8/4.
That is, the last beat is the next down beat... it just keeps losing one beat each measure.
They are all valid perceptions.
But if you want to be 100% sure, go ask Roger Waters.
If a composer is concerned and particular about how their irregular time signature is counted and stressed they can use an "additive" notation, which is yet another term to add to the list of terms for irregular.
For example, they will literally write 4/4 + 3/4 on the staff instead of writing 7/4.
The composer can also ensure a complex time signature is counted they way they intend by grouping the note heads.
And since we are talking terminology, there is also "irrational" time signatures such as
3/10 or 5/24. But I do not want to go there.
As for Rush, I agree with someone's statement that Rush does not say "let's make a complex time piece of music to really stimulate theorists."
I think Getty and Neil look at their poetry (lyrics), the rhythm and metrics of the words, and put it to music. And they have natural feel and economy of meter.
If their poetry only needs 7 beats in one stanza, but then needs 4 or 8 beats in the refrain, then so be it... they write it that way, instead of filling out the musical measure with extra notes. Of course their drummer has a clear command of meter and rhythm. They all do, they think that way, it is natural and not forced. Although I also think they are very "white", and for them maybe it is a way of being "funky". (Please do not take that as being racial. It is just a way of describing feeling in music. The Bee Gees are funky too, but that is some British, white, funk. I am merely suggesting that Rush's use of meter may be in their mind funky, but it is some white Canadian funk.)
But I digress.
As I said, my reply to your question is coming from Western music notation.
Other countries and cultures are not quite as "brain washed" as we are in the U.S.
In the U.S. since the age of recording, record producers, radio stations, and the music industry have influence the listener as to what is considered "good music". This industry only exposes the public to a very narrow spectrum of music in order to monetize and make profit.
The average American listener cannot hear beyond an 8 beat pattern and if it is not symmetrical we consider it "off beat".
That is not necessarily the listener's fault, but is a result of the brain washing.
Other cultures do naturally think in patterns that are much longer and have complex syncopation, all which Western music would classify as irregular.
Indian Jhaptal 10-beat pattern, counted 2-3-2-3.
African rhythms built on 25-beat patterns.
For the under exposed, unaccustomed listener it is hard for our brains to allow for this. We are always trying to find a cyclic half point in the phrase that is not there.
Answer: Depends on the genre IMO.  Swing, for example, is mostly 12/8, and I can't think of a boogie woogie title that isn't.  Rock music became increasingly 4/4 after the 50's, but there were lots of 50's titles that are in 12/8 (Blueberry Hill and That'll be the Day are a couple of well-known examples.)  Most blues music is in 12/8 as well, especially earlier blues.


Why does the verse in Tehillim (115,7) not say "they have hands…they have feet" similar to the previous verses?

Question: The verse in Tehillim (115,7) which we say in Hallel says: "Their hands - but they do not feel, their feet - but they do not walk." But in the previous two verses it says "they have a mouth…they have eyes…they have ears…they have a nose", so here too it should have said "they have hands…they have feet". Why is there a change of expression here?
Answer: The sefer חנוכת התורה here answers that this difference can be explained according to the halachah that it is permissible to benefit from broken pieces of an idol, but if one finds a hand or a foot by itself it is forbidden, because such things are worshipped by themselves.
Thus with all the other parts of the body such as eyes and ears it says "they have" because they need to be connected to the idol, otherwise they would not be considered an idol. But with the hands and feet it does not say "they have", not only because it was not necessary since even by themselves they are an idol, but in addition by not adding this phrase it alludes to the halachah that even when they are separate they are considered an idol and are forbidden.

Why does the verse in Tehillim (115,7) not say “they have hands…they have feet” similar to the previous verses?


Does a modified command invocation tool – which dynamically regulates a job pool according to load – already exist?

Question: Fellow Unix philosophers,
I programmed some tools in Perl that have a part which can run in parallel. I outfitted them with a -j (jobs) option like make and prove have because that's sensible. However, soon I became unhappy with that for two reasons.

I specify --jobs=2 because I have two CPU cores, but I should not need to tell the computer information that it can figure out by itself.
Rarely runs of the tool occupy more than 20% CPU (I/O load is also little), wasting time by not utilising CPU to a better extent.

I hacked some more to add a load measuring, spawning additional jobs while there's still »capacity« until a load threshold is reached, this is when the number of jobs stays more or less constant, but when during the course of a run other processes with higher priority are in demand of more CPU, over time less new jobs are spawned and accordingly the number of jobs reduces.
Since this responsibility was repeated code in the tools, I factored out the scheduling aspect into a stand-alone tool following the spirit of nice et al.. The parallel tools are quite dumb now, they only have signal handlers through which they are told to increase or decrease the jobs pool, whereas the intelligence of load measuring and figuring out when to control the pool resides in the scheduler.
Taste of the tentative interface (I also want to provide sensible defaults so options can be omitted):
run-parallel-and-schedule-job-pool \
    --cpu-load-threshold=90% \
    --disk-load-threshold='300 KiB/s' \
    --network-load-threshold='1.2 MiB/s' \
    --increase-pool='/bin/kill -USR1 %PID' \
    --decrease-pool='/bin/kill -USR2 %PID' \
    -- \
    parallel-something-master --MOAR-OPTIONS

Before I put effort into the last 90%, do tell me, am I duplicating someone else's work? The concept is quite obvious, so it seems it should have been done already, but I couldn't find this as a single responsibility stand-alone tool, only as deeply integrated part of larger many-purpose sysadmin suites.
Bonus question: I already know runN and parallel. They do parallel execution, but do not have the dynamic scheduling (niceload goes into that territory, but is quite primitive). If against my expectations the stand-alone tool does not exists yet, am I better off extending runN myself or filing a wish against parallel?
Comment: You may want to copy (rather than migrate) this over to serverfault as well ... get twice the number of eyes on it -- it's probably pertinent there as well as here.
Answer: some of our users are quite happy with condor. It is a system for dynamically distributing jobs to other workstations and servers according to their free computing resources.


How to create healthy bat living conditions in Vermont?

Question: I want to install bat houses at my property.  What conditions do bats prefer to live and what conditions do they NOT to prefer to live in?.
I live in Vermont on a 2 acre parcel, and have a section of property that sees about 6.5-8 hours of sunlight.
Comment: Part of sustainability is maintaining healthy and diverse ecosystems, and bats could well be part of that. Are you doing it to support a native species of bat, or at least for an ecosystem related reason? If yes, then I'd say the question is on topic here. What type of bat is it you're dealing with, as that may affect preferred living conditions?
Comment: What's the terrain like - all flat, hilly, rocks? Please [edit], and maybe add a picture or two (you don't have enough rep yet to post a picture, but put it on an image sharing site and add the link to your question).
Answer: Audibon Magazine distilled the following from Bat Conservation International:

Here are some tips for installing a bat house, from Bat Conservation
  International, a science-based bat conservation organization.

Design. All bat houses should be at least 2 feet tall, have chambers at least 14 inches wide, and have a landing area extending
  below the entrance at least 3 to 6 inches (some houses feature
  recessed partitions that offer landing space inside). Taller and wider
  houses are even better. Rocket boxes should be at least 3 feet tall
  and have at least 12 inches of linear roost space. Most bat houses
  have one to four roosting chambers—the more the better. Roost
  partitions should be carefully spaced three-quarters of an inch to 1
  inch apart. All partitions and landing areas should be roughened. Wood
  surfaces can be scratched or grooved horizontally, at roughly
  quarter-inch to half-inch intervals, or covered with durable square,
  plastic mesh mesh. Include vents approximately 6 inches from the
  bottom of all houses 24 to 32 inches tall where average July high
  temperatures are 85 degrees Fahrenheit or higher. Front vents are as
  long as a house is wide; side vents are 6 inches tall by a half-inch
  wide. Houses 36 inches or taller should have vents approximately 10 to
  12 inches from the bottom.
Construction. For wooden houses, a combination of exterior plywood (ACX, BCX or T1-11 grade) and cedar is best. Plywood for exteriors
  should be a half-inch thick or greater and have at least four plies.
  Do not use pressure-treated wood. Any screws, hardware, or staples
  used must be exterior grade (galvanized, coated, stainless steel,
  etc.). To increase longevity, use screws rather than nails. Caulk all
  seams, especially around the roof. Alternative materials, such as
  plastic or fiber-cement board, may last longer and require less
  maintenance.
Wood treatment. For the exterior, apply three coats of exterior-grade, water-based paint or stain. Available observations
  suggest that color should be black where average high temperatures in
  July are less than 85 degrees Fahrenheit; dark colors (such as dark
  brown or dark gray) where they are 85 degrees to 95 degrees; medium
  colors where they are 95 degrees to 100 degrees; and white or light
  colors where they exceed 100 degrees. A lot depends upon amount of sun
  exposure; adjust to darker colors in places where there's less sun.
  For the interior, use two coats of dark, exterior-grade, water-based
  stain. Apply the stain after creating scratches or grooves, or prior
  to stapling on the plastic mesh. Paint fills the grooves, making them
  unusable.
Sun exposure. Houses where high temperatures in July average 80 degrees Fahrenheit or less should receive at least 10 hours of sun. At
  least six hours of direct daily sun are recommended for all bat houses
  where daily high temperatures in July average less than 100 degrees.
  Full sun is often successful in all but the hottest climates. For
  maternity colonies in summer, internal bat house temperatures should
  stay between 80 degrees and 100 degrees as long as possible.
Habitat. Most nursery colonies choose roosts within a quarter-mile of water, preferably a river or lake. Greatest bat house success has
  been achieved in areas of diverse habitat, especially where there is a
  mixture of varied agricultural use and natural vegetation. Bat houses
  are most likely to succeed in regions where bats are already
  attempting to live in buildings.
Mounting. Bat houses should be mounted on buildings or poles. Houses mounted on trees or metal siding are seldom used. Wooden,
  brick, or stone buildings with proper solar exposure are excellent
  choices, and locations under the eaves are often successful.
  Single-chamber houses work best when mounted on buildings. Mounting
  two bat houses back to back on poles is ideal (face one house north,
  the other south). Place houses three-quarter inches apart and cover
  both with a galvanized metal roof to protect the center roosting space
  from rain. All bat houses should be mounted at least 12 feet above the
  ground; 15 to 20 feet is better. Bat houses should not be lit by
  bright lights.
Protection from predators. Houses mounted on sides of buildings or on metal poles provide the best protection from predators. Metal
  predator guards may be helpful, especially on wooden poles. Bat houses
  may be found more quickly if located along forest or water edges where
  bats tend to fly, but they should be placed at least 20 feet from the
  nearest tree branches, wires or other perches for aerial predators.
Avoiding uninvited guests. Wasps can be a problem before bats fully occupy a house. Use of three-quarter inch chambers reduces wasp
  problems. Wasp nests should be removed in late winter or early spring
  before either wasps or bats return. Open-bottom houses greatly reduce
  problems with birds, rodents or parasites, and guano does not build up
  inside.
Timing. Bat houses can be installed at any time of the year, but they are more likely to be used during their first summer if they're
  installed before the bats return in spring. When using bat houses in
  conjunction with excluding a colony from a building, install the bat
  houses at least two to six weeks before the actual eviction, if
  possible.


Correct plural form of "hoof"

Question: My research has shown that hoofs and hooves are correct plural forms of hoof.  That being said, which is preferable?  Which came first in the English language?
Comment: It looks like hoofs has been the preferred spelling until about 1975. Now they're about equal: http://books.google.com/ngrams/graph?content=hoofs%2Chooves&year_start=1700&year_end=2008&corpus=17&smoothing=3&share=
Comment: As for the "f" sounding like a "v", you only have to look at the two English words "off" and "of" where the former has the "f" sound and the latter has the "v" sound. For more examples just look to the Welsh language!
Answer: The Old English word was hof; its plural hofas would have been pronounced with a v sound—[hoːvas]. Hoofs may be older by spelling, but hooves is probably the older pronunciation. This is backed up by the Middle English spellings houes and hooves, pronounced [hoːvəs]. So you can make an equally compelling case for each.
I like hooves, elves, dwarves, &c. but it's a matter of personal preference.
Comment: @terdon: In Old English, the unvoiced *f*, *s*, and *þ* (unvoiced th) were pronounced *v*, *z*, and *ð* (voiced th) between vowels or voiced consonants. *hof* is a strong noun, so its plural ending is *-as* in the nominal case, and that rule comes into play. The earliest evidence for this phenomenon is somewhere in the latter part of the Early Old English period, around the year 900. [Wikipedia](https://en.wikipedia.org/wiki/Old_English) has a good table of information on the various sound changes that occurred over the history of Old and Middle English.
Comment: OK, now I'm intrigued, if you have the time, can you give us some more on why _hofas_ would have been pronounced [hoːvas]? Is that how the _f_ was pronounced? When would this be?
Comment: Thanks, I find these things quite fascinating, I really need to hang out on linguistcs.se more.
Answer: Well, as you can see in this NGram, hoofs is much older but has steadily been losing ground. Hooves seems to be the most common version today and has been for the past few decades:

The result is pretty much the same when comparing horse's hoofs to horse's hooves so it is not an issue of hoofs being used as a verb (as in he hoofs it). The pattern is also essentially the same for American and British English so it seems safe to assume that the variant hooves entered the language around the 1920s and has been gaining ground ever since.
Comment: I have noticed a few instances recently of N-Grams showing resurgences of outdated phrases over the past 10 years, and I think this is a common factor. It sort of limits usefulness of N-Grams.
Comment: Extending the graph to 2008 as @user814064 did shows _hoofs_ making a comeback though.
Comment: That does look suspiciously like **Google Books** coming on line though, with 75+ year old usages.
Comment: @PieterGeerkens you mean the 'comeback'? I guess that would make sense.
Comment: @PieterGeerkens I generally take N-Grams results after 2000 with an even bigger pinch of salt as for those over the last couple of centuries, as there are some very implausible spikes in the 2000-2008 period that suggests that what is reflected is the quality of data rather than any underlying trend.
Comment: @JonHanna I wonder if that is why the default end date for N-Gram searches is 2000
Comment: @Kevin I'm pretty sure it is.

Correct plural form of "hoof"


What are some common beginner mistakes when learning to play the piano?

Question: I'm starting to learn to play the piano by myself (I've had experiences with other instruments so I have some sort of musical framework), and I would like to know what technical nuances I have to know so that I won't start playing the wrong way.
Comment: One mistake is to not have a good teacher... Really, even if you *know* what you should and shouldn't do, and you *think* you're doing it right, you still might not because you haven't experienced how the right way *feels*.
Comment: This question might be a bit too broad for the format of this site. That being said, I recall one of the bad habits I had to unlearn from "teaching myself" piano was avoiding playing with my pinky fingers.
Answer:
The biggest mistake that many starting-out (and professional) keyboardists, including pianists, make is sitting at the piano incorrectly which results in playing with tension. Make sure you learn everything you can about correct bench height (generally, your forearms should be parallel with the keybed), sitting in a relaxed manner and relieving all muscle tension in your hands, head, arms, chest, legs, back, and wrists. Learning bad posture habits cause tension, which makes it more difficult to actually play the piano, and may potentially cause an injury later on. Learning good habits will enable you to be less tense mentally, which will facilitate faster music learning, better sound, and more easily attained technical ability. There are many myths out there about positioning at the piano.
Another mistake many beginner pianists make is not practicing every day. Perhaps take a day or two off a week (not in succession), but when you practice, you are programming your brain with short-term information. If you skip a day, you lose a good deal of that information, which can be difficult to regain. Also, if you take lessons with an instructor, try to have lessons every week instead of biweekly. It will encourage you to make faster progress.
Many pianists, when learning their first pieces, do not establish good practice habits. This is also linked to tension. If you find yourself making many mistakes during the course of the early stages of learning a piece, you could be practicing incorrectly. It only takes a few runs through the piece, or perhaps even only an especial troublesome passage, at a slower tempo to solve issues for good. Also, make sure you know and employ all the other important practice techniques, like practicing hands or voices separately; listening to a recording of yourself playing; or trying several tempos to find the best one for practice and performance.

Some final advice, also related to tension, which as you may have guessed is very important: Seek beauty, not perfection. When you make beautiful music, perfection gets thrown in. What I mean is, trying too hard is not beneficial; much better to take it back a notch, think about and examine the music closely, take a break, spend time with the music away from the keyboard, and of course practice things slowly, with relish, so as to observe and learn every musical instance. Then learning the piano will be enjoyable, and it won't be a breeze, but it will be easier and you will play better.
Answer: Playing too fast too early is the most common mistake I know. It leads to bad habits of movement: your fingers don't move enough, because they are to weak and then the whole hand and arm "helps out" but they cannot keep the velocity for long time, so they start to cramp. Which of course influences breathing and blood circulation in a negative way, and so on...
You surely know this already from your other instruments: practice slow and the fingers will learn "in the background". When feeling bored, look for details to (deeper) concentrate on.
In the case of the piano(forte), you may look at

a wide range of dynamic - try to get a sure sense for velocity
no control over timbre while the tone is "ON", concentrate on its boundaries, so

be precise in attack timing (even meter, balanced tempo), also simultaneity of the hands
get a feeling for releasing the keys, which makes also a kind of (semantic) timbre
Comment: The last sentence is invaluable in itself. Perhaps the OP knew this already, but it is something that should be **somewhere** on this site.
Comment: @11684 You are right, thanks for the hint. I expanded the last sentence (rather than deleting it), because I find that there are some piano-relevant aspects that should be mentioned.
Answer: This indeed does seem fairly broad, and my answer might not be the most relevant to someone just starting the piano and is based mostly on personal experience. I also have the feeling that a lot of issues are specific to the player - what is an issue for me might not be an issue for someone else, or at least not to the same extent.
In general, at least for me, most piano-specific issues (i.e. not related instead to, for instance, rhythm) I've had are generally linked to various forms of poor control.
For instance, I've had issues with smoothly controlling fingers 4-5 in various passages (usually somewhat faster ones) to allow for evenness. A somewhat similar issue also crops up when playing harmonic intervals sometimes, on the same fingers, as (at least for me) they seem somewhat weaker.
There's also the issue of positioning the rest of the arm properly - some "positions" (dependent on the specific passages) of the wrist/arm can lead to straining and discomfort, not to mention subpar playing. (This generally also seems to be linked somewhat to shoulders that are too tight.) This, however, seems to be a somewhat "general" issue that can occur pretty often - as mentioned, whether or not a specific positioning of the wrist/arm is going to be problematic depends a lot on the specific passage and the technical requirements of said passage. It does, however, tend to be more of an issue for me in fast passages, but beyond that I really can't get more specific.
Finally, there's the issue of excessive pedaling, which can crop up pretty frequently for some people.
Answer: It's been said in a comment, but deserves a fully-fledged reply:  your biggest mistake is thinking you can do this without a teacher.  Even if it's only a consultation lesson now and again - that's better than nothing.
Note the number of people who have tried to give you a piano lesson in their replies!