HN user

noblethrasher

2,892 karma

https://github.com/noblethrasher

http://stackoverflow.com/users/3927/rodrick-chapman

rodrick@rodlogic.com

Posts25
Comments931
View on HN
uwspace.uwaterloo.ca 6y ago

The Aesthetics of Science Fiction Spaceship Design (2010)

noblethrasher
194pts100
www.youtube.com 6y ago

The Simple Essence of Automatic Differentiation – Conal Elliott

noblethrasher
2pts0
anthonydgreen.net 7y ago

An Exhausting List of Differences Between Vb.net and C#

noblethrasher
2pts0
www.usenix.org 7y ago

End-To-End Arguments: The Internet and Beyond

noblethrasher
1pts0
gbracha.blogspot.com 7y ago

The Miracle of (Smalltalk's) become: (2009)

noblethrasher
1pts0
www.youtube.com 8y ago

Vector Functional Programming: A Tour of the Q Language

noblethrasher
2pts0
people.csail.mit.edu 9y ago

“A closure is a poor man’s object; an object is a poor man’s closure” (2003)

noblethrasher
289pts227
openvault.wgbh.org 9y ago

The Machine That Changed the World: Interview with Alan Kay (1990)

noblethrasher
69pts6
www.drdobbs.com 10y ago

Designing Safe Software Systems Part 2 (2009)

noblethrasher
11pts2
news.ycombinator.com 10y ago

Happy Birthday, Alan Kay.

noblethrasher
4pts0
www.metafilter.com 10y ago

WinFS – What It Could Have Been and Why It Failed (2013)

noblethrasher
3pts0
www.youtube.com 10y ago

Google Tech Talk: Object Capabilities for Security

noblethrasher
1pts0
www.youtube.com 10y ago

Alan Kay: Computer Applications: A Dynamic Medium for Creative Thought

noblethrasher
2pts0
news.ycombinator.com 11y ago

Ask HN: What are the empirical facts about programming?

noblethrasher
1pts2
blogs.msdn.com 11y ago

F# 4.0 Preview

noblethrasher
249pts71
www.azarask.in 11y ago

Solving the Wrong Problem

noblethrasher
69pts15
www.nytimes.com 11y ago

Discovering Two Screens Aren’t Better Than One

noblethrasher
22pts47
math.stackexchange.com 12y ago

Is an SD card a fair coin... to me?

noblethrasher
2pts1
www.forbes.com 12y ago

Google and Facebook Hedge Against the Data Backlash

noblethrasher
2pts0
www.kleenecode.net 12y ago

AJAX OnBlur Commits: Cool Vs Usability

noblethrasher
1pts0
news.ycombinator.com 13y ago

Ask HN: Why does the emergency alert system require OS updates from carriers?

noblethrasher
1pts0
kickingbear.com 14y ago

How I'd build the Apple TV

noblethrasher
2pts0
blogs.smithsonianmag.com 14y ago

The Future as Seen from the Past...

noblethrasher
1pts0
news.ycombinator.com 17y ago

Ask HN: Getting published in an academic journal without holding or seeking a PhD?

noblethrasher
48pts30
blog.mozilla.com 17y ago

User Interface Design: Notifications and (avoiding interruption of) Flow

noblethrasher
17pts0

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.

Coq 8.13 5 years ago

Also, Thierry Coquand, who is behind CoC, and is also one of the developers of the software that became Coq.

Speaking of stupid efficiencies:

“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.”

—Adam Smith, The Wealth of Nations

https://www.pitt.edu/~syd/ASIND.html

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.

[1] https://lamport.azurewebsites.net/tla/book-02-08-08.pdf

I didn't say "states", I said "nominal states". These are the states that you would bother to name. They'll correspond to classes in an OOP language or discriminated unions in an ML-stye FP language.

Using your example, you'd have two states: `PrepareDeleteUser` and `DeleteUser` where the latter is only reachable from the former. PrepareDeleteUser will check that the all preconditions are satisfied (e.g. that the current operator has permission to delete the user). Now, you may not choose to reify these states so directly (i.e. you'll just have a deleteUser function that does a check for the preconditions), but they must exist in a robust application nonetheless.

In REST we name our states so we can drive the state machine by using the names (following hyperlinks). Why? Because, among other things, this keeps the client decoupled from the server by letting the client be in control of when to effect a state transition, but keeps the server in charge of what transitions are possible.

I need to attend to some real-life concerns at the moment, but I hope to get back to this discussion soon.

Cheers!

REST doesn't care about the size of the set of verbs, only that the set be constant. HTTP as one particular implementation of REST just happens to have nine verbs.

I tried to implement an IMAP server a few years ago, but otherwise I don't know much about it. However, I do recall that Mark Crispin admitted that he wasn't a very good API designer, and that much of the complexity of IMAP was due to it being intertwined with the complexity of MIME. But, I can't find the sources for those claims at the moment.

HTTP is one particular implementation of REST that happens to have nine verbs. Another implementation might only have two or three. But no RESTful architecture will have much more than nine.

Why?

Because your application is going to have thousands of nominal states, and each one is going to need to support all of the verbs because of the uniform interface constraint.

Why a uniform interface?

A lot to say about this, but basically, the set of verbs is an abstraction of the state machine that is your application. If you have a million states and a million verbs, then you have no abstraction. If you have ten states and a hundred verbs then you have too much abstraction (i.e. you ran afoul of YAGNI). A good degree abstraction is somewhere in between, but if you care about scale (which is the raison d'être for REST), then the size of set of verbs is going to have a logarithmic relation to the size of the set of nominal states.

You can have as many verbs as you want, but they all need to be valid at every state of the application (i.e at every hypermedia target), because you still want a uniform interface.

Responding with a standard error code is okay for verbs that are not supported at a particular state, but it's the uniform interface constraint that forces you to keep the set of verbs small.

Also, HTTP has nine verbs: GET, POST, PUT, DELETE, HEAD, CONNECT, OPTIONS, PATCH, and TRACE.

That’s disgusting, and I’m really sorry to have read that happened to you or anyone else.

My policy is that anyone that completes the technical screen (2 – 4 hours of work) gets an on-site interview.

Just this morning, I had to spend about 20 minutes debugging a candidate’s code to get it to both build and run, but he’s still getting invited for an on-site.

True, but what made the Mono REPL particularly remarkable was that it launched with much of the functionality of a notebook, with things like inline graphics.