Interestingly enough, a professor of organic chemistry[1] created a new Common Lisp implementation[2] just so that, among other things, he can use a very high level functional(ish) language in his research. His CL implementation is specifically designed to allow more seamless interoperability with libraries written in C and C++.
Java's (Oracle's) strategy is to spend most the innovation on the runtime, and in that regard, it's probably the most advanced platform. The net effect is that you can write some pretty naïve and boring OO-style code that will almost always perform superbly. This is a good thing, and something that I envy as a C# programmer.
Interestingly enough, the aforementioned quote was just an epigraph for a section whose penultimate point is that “mathematics is nature’s way of showing how sloppy your writing is”, followed by the ultimate point that “formal mathematics is nature’s way of showing you how sloppy your mathematics is”.
TLA+ really is quite nice. I write most of my TLA+ specifications longhand and only bother with the toolbox when I think that refinement might be useful. Even then, it's mostly for SANY rather than TLC.
After noodling with with the spec for half an hour or so, I’ll usually have enough insight/confidence to start coding/debugging.
“In the progress of the division of labour, the employment of the far greater part of those who live by labour, that is, of the great body of people, comes to be confined to a few very simple operations, frequently one or two. But the understandings of the greater part of men are necessarily formed by their ordinary employments. The man whose whole life is spent in performing a few simple operations, of which the effects too are, perhaps, always the same, or very nearly the same, has no occasion to exert his understanding,or to exercise his invention in finding out expedients for removing difficulties which never occur.
He naturally loses, therefore, the habit of such exertion, and generally becomes as stupid and ignorant as it is possible for a human creature to become. The torpor of his mind renders him, not only incapable of relishing or bearing a part in any rational conversation, but of conceiving any generous, noble, or tender sentiment, and consequently of forming any just judgement concerning many even of the ordinary duties of private life. Of the great extensive interests of his country he is altogether incapable of judging; and unless very particular pains have been taken to render him otherwise, he is equally incapable of defending his country in war.
The uniformity of his stationary life naturally corrupts the courage of his mind, and makes him regard with abhorrence the irregular, uncertain, and adventurous life of a soldier. It corrupts even the activity of his body, and renders him incapable of exerting his strength with vigour and perseverance, in any other employment than that to which he has been bred. His dexterity at his own particular trade seems, in this manner, to be acquired at the expense of his intellectual, social, and martial virtues.
But in every improved and civilized society this is the state into which the labouring poor, that is, the great body of the people, must necessarily fall, unless the government takes some pains to prevent it.”
Most of what I have to say comes from Fielding’s dissertation, along with spending the past several years trying to take it as seriously as possible. Other good sources are McCarthy’s Situation Calculus and all of the stuff that Lamport has written on on TLA+ (especially Specifying Systems[1]).
The big idea behind scalability (IMO) is that we want the pain of maintaining a system to grow logarithmically with respect to the size of the system. Now, size can mean many things (number of customers, lines of code, etc.), but pain is almost always complexity. A potent cure for complexity is symmetry, because every time that we discover a new symmetry, half of the complexity goes away. One way of finding symmetry is to look for invariants.
Roughly speaking (very roughly), having lots of possible states is good (the more states, the more powerful/featureful the system), but having lots of state transitions is bad (especially with respect to security). REST “verbs” help to control complexity by imposing invariants on state transitions. For instance, one good invariant to enforce is that a GET transition mean that a state can always be a start state, whereas a POST must always have an antecedent state. Thus, a REST verb is just label for a set of invariants, and we’re free to choose whatever set of invariants we want. Obviously, the more invariants you have, the weaker they are since an invariant is supposed to be unchanging; i.e. if the size of set of invariants is close to the size of the set of states, then you effectively have no invariants.
https://users.cs.duke.edu/~rodger/articles/AlanKay70thpoints...