I suspect that you have never actually used a phone-dispatch car service in NYC. You have no visibility into their ETA. Call back and ask... the answer is always the same "5 minutes".
I've used it tons of times. I grew up around here. You're right, you don't have much visibility into the ETA. I THOUGHT that was an advantage of Uber, but it's not -- I've sometimes called Uber and they blatantly lie, bait-and-switching about ETAs (eg, 3 min before I click, then it becomes 12min). Also, dealing with the ETA is easy. Wait 6 minutes, if they don't show up, call a different car service. The problem will take car of itself.
The "best" part about Uber is they penalize you for waiting too long to cancel your Uber so if the guy takes three times as long as promised and you cancel then you are charged the cancelation fee.
Classes do not imply inheritance. Classes are a means of defining an interface, albeit a heavy one.
The statement that it is better to separate data and behavior is far from self-evident IMO, and I would be very interested to understand why this is such a deeply held belief. Seriously, why?
> The statement that it is better to separate data and behavior is far from self-evident IMO, and I would be very interested to understand why this is such a deeply held belief. Seriously, why?
Data is and always has been more valuable and more important than behaviour. It's not unheard of to preserve accounting data that's decades old, even though the accounting system itself changed completely many times. The converse, preserving old programs to run on brand new data is much more rare.
The whole hoopla around big data should make it clear where the real value is. Behaviour is merely a way of transforming data, and coupling the two rarely works well in the long run. The only times it's actually advantageous is to preserve invariants that ensure input or output data is well formed. For instance, data structures that ensure or preserve orderings, etc.
It's not always true, by any stretch of the imagination. Closures couple data and behavior and most (though not all) functional programmers consider closures to be pretty central to FP. I'd add that closures are hard to use in that way without allocating, which is why I think one potentially reasonable argument against coupling data and behavior is performance-driven, but that's a more subtle argument that ignores compiler performance (and there are times where you lose more from all the extra code taking up your icache than you gain in speed due to not allocating; plus, as C++ and Rust demonstrate, you can have closures without allocation if you're willing to heavily restrict them).
The use of closures in functional programming is an implementation detail, not a fundamental aspect of the underlying theory, and closures only "couple" data and behavior in the very literal sense that it is a function that happens to point to some data under the hood, not in the syntactic or semantic sense we're referring to when we say that OOP classes couple behavior and data.
A closure in a pure language can't couple to data any more than a lambda expression without free variables (from the programmer's perspective), because they can have the exact same type and semantics.
In other words, there's no semantic difference between "f = \x . x + 2" and "f = let y = 2 in \x . x + y" even though the latter is a closure in the absence of inlining.
Purity seems to be totally orthogonal to this question, to me. I'm referring to the ability to return thunks from within called functions, such that the data are totally encapsulated in the closure (are not passed in explicitly and cannot be retrieved manually). That seems to be coupling data and behavior to me, since you can't run the function without the data it was coupled with at construction time. Whether that's fundamental or not is, of course, a subjective question, but I have a hard time thinking of a language that bills itself as functional that doesn't provide that capability natively (Rust and C++ make it difficult, but neither really bill themselves as functional).
> Purity seems to be totally orthogonal to this question, to me.
Ah, well there's the confusion. A language with semantically impure closures emphatically does not reproduce the semantics of the lambda calculus unless you restrict yourself to only pure, immutable variables. But if you reproduce the lambda calculus, there's no need for closures as we know them. It's just an implementation that happens to work well. You could supercompile the lambda-abstraction at the application site and avoid having a closure. It's just not a good idea.
But I agree, in a language with mutable variable capture, you can reproduce the semantics of OOP by providing a bundle of functions closed over mutable references to the "object" data.
> a language that bills itself as functional that doesn't provide that capability natively
I'm not sure exactly what capability you're referring to. Could you clarify a little bit?
I'm referring to "information hiding" by providing a function that uses currying in order to close over data that cannot be accessed from the caller. For example:
(* foo.ml *)
let bar =
let foo = lambda x . lambda y .
if y == 0 then { getFoo : lambda z . 0 }
else { getFoo : lambda z . (x * z - x + z) / y }
end
in foo 3
(* bar.ml *)
include foo.ml
let y = bar 5
bar.getFoo(4)
It sure seems to me that bar is hiding the 3 from bar.ml (and there are much more complicated examples where foo.ml really can't get at the captured type, for instance), and at the same time it's capturing the value of 5. The function getFoo on bar is bound to it (the record type can desugar to more curried lambdas, if necessary, it's just tedious and this illustrates my point better).
None of this seems to have anything to do with mutation, to me, though it certainly seems to have both information hiding and binding logic and data. The fact that it can be compiled not to use closures (using whole-program compilation) is immaterial; the same is true for the same program specified with objects in mutable languages (SML has both mutation and closures, and MLton does exactly that).
Personally speaking, it's just a lot easier. I could go on about various theoretical justifications, but at the end of the day it's just easier. This probably has something to do with the fact that you don't really gain anything by defining data and behavior together, but you do lose flexibility by coupling those possibly orthogonal concerns.
If you are running this from your own AWS account doesn't it have the problem of not anonymizing the traffic - since it can all be tied to your identity?
A VPN isn't always about anonymity. For instance: encrypting traffic in a coffee shop where any and all of your traffic can be sniffed.
Another popular use-case is streaming (paid-for/ad-supported) content from a different region of the globe that is blacked out in your region (and the rights-holders wonder why people still torrent).
If you work with AWS infrastructure in a VPC, sometimes it makes sense to use a VPN to access/manage VPC instances that don't have a public IP (e.g., app servers behind an ELB). Of course, one could also just tunnel through an exposed SSH server in the VPC, but a VPN server can offer a little more convenience and flexibility.
It's more like all non-HSTS traffic, unless you're paying extremely close attention. Otherwise a man in the middle attacker can just pretend the server doesn't support HTTPS and serve the page via HTTP.
And even when you're using HTTPS you're still leaking DNS queries etc.
Even when you're using SSL/TLS the traffic can still be seen on the network. The difference is that a sniffer will see cipher text rather than plain text.
Seems like mostly FUD. No mention of specific issues in any clients. And please have a look at other high throughput systems (like Cassandra or VoltDB) before claiming that a load balancer is the proper way to connect clients to a distributed system.
Try to be more careful about the term "FUD". I know it isn't written anywhere that this is the case, but in reality, "FUD" implies a bad-faith effort to convince people to avoid something; it means the person spreading the message doesn't care if it's true or not.
There is a big difference between that kind of "FUD" and simply being incorrect or under-informed about things, even if you think people should have an obligation to be better informed before relating their opinions.
Why no to Cassandra? I don't have the reference on hand, but I believe the issues identified by aphyr have since been addressed. It is important to do your own due diligence, especially when referencing work that is more than a year or two old.
This is why every time I see a new Jepsen article come out my immediate reaction is actually of mild disappointment that he isn't going back and retrying Cassandra to see if it works now: by only evaluating the product enough to do an article on how bad things are, and then only evaluating fixes when he is pretty sure the authors are being dumb (redis), it turns the entire experience one into a trail of destruction rather than one of helping anyone (whether it be the database vendor or the audience) build better things. If nothing else, at least linking the article to Cassandra's own testing with Jepsen would make it live up to the feel of the database quality review site people are looking for: it also would serve to reward communities like Cassandra's that have embraced the kind of analysis and testing that Aphyr wanted.
My money is on: He'll happily retest Cassandra if paid to do so. He may even accept a reduced rate to test if the specific concerns mentioned before are gone without testing everything else again.
It seems to me that one of the core differences between MySQL/Postgres and distributed stores like Cassandra / Hbase is that with the former your data and your write workload have to fit onto a single host. If either one cannot fit then you have to partition at the application level or use a real distributed data store. Partitioning at the app level is an operational burden and complexity that would be best avoided, but there are always exceptions.
While I agree that the author and others in the same role clearly do not feel apart of the culture, could you really expect them to? They don't have any equity, they don't make very much, they are monitored and evaluated like telemarketers, yet the management expects them to buy into the "change the world" mantra. I think you have to admit that it's demeaning. Why would they feel anything besides anger or jealousy?
