Wake FAQ
Wake has many new ideas. If you dislike a choice we made, there very well might be a good answer here for why we did what we did.
Why aren't variable names required?
A lot of people get worried about this. They claim that variables should be named after what they do rather than after what they are. They also claim that refactoring becomes more difficult if types aren't separated from the names of variables.
The first concern is unfounded. When we name a variable min or max, we aren't describing how its used. Its the function name, printFrom(min Num)To(max Num), that tells us how min/max will be used. What the code does is equally clear if you change it to printFrom(Num)To($Num).
The varnames min and max are clearer here because its best description of what they are. Therefore we believe that much of the code we write such as delete(File) and rename(Person)To(Text) are clearest in precisely that form, without any other labels that your brain must process.
Why don't variables always follow the type?
Some recent languages such as Go and Scala have had to, for syntactic reasons, require varable names to preceed their types, such as percentage: float instead of C/Java style float percentage. This has spawned some controversy over which method is the most readable.
We thought quite hard on which is the best, and we determined that both ways are awful for readability.
In English we put adjectives before our nouns, which usually corresponds to types and then variable names. Types are merely a description of your variable that is read by the compiler, so it makes sense to put them first when you have a double noun group such as Printer outputter. It also works with Java-style designs quite well where interfaces are often adjectives, such as Iterable<T> startingList.
But we already know that the Iterable<T> is a list. We could leave the variable name as simply starting since that's what makes it unique. Now we find ourselves with an adjective for a variable name. This should be written as starting Iterable<T> for optimal readability.
Many of our variable names are adjectives -- min, max, first -- or are compound words that begin with adjectives -- newItems, addingCategory, oldId. In these instances English speakers will have more concise and more readable code when putting the variable name before the type.
Moreover, if you still aren't convinced, not all code is written in English. Allowing both options is more universal for our increasingly global world.
What's with the unique every Blah is: class declarations?
Frequently the worry here is that files can only define one class. Let's start off by assuring you that this is not the case. Simply open another class definiton to close the previous one.
We do this for a couple reasons. Firstly, it becomes that much extra bracket management which we have proven is unnecessary by not having it. If it were necessary in other languages, we would've had to do it too. The exception to this is anonymous classes, which we have chosen not to add in favor of closures.
Secondly, indentation is valuable. By wrapping your entire class in a bracket encourages you to indent everything else in the file. This is a waste of indentation, brought on mostly by a likeness to features that require indentation such as methods, if statements, and more.
Thirdly, extra closing brackets in your methods will get accepted by parsers as the end of your class declaration. Depending on the language, the parser will report an error on the opening of the next method, or the extra closing bracket at the end of the file. We thought it important that the parse error is reported as close as possible to the source, which in Wake will usually be the end of the method that contains the extra bracket.