More charitable is that the user thought it would do X and it ended up doing Y. They may have even been happy with X even, if they knew that was going to happen, because the whole thing would have been less confusing.
> I'm at a little bit of a loss here. I totally understand sending me encrypted emails if I've gone through the steps to set the CNAME that indicates that I want to do that, but it doesn't seem like that's how the service works. As far as I can tell, the act of uploading a OpenPGP-compatible key seems to trigger their service to send it as an end-to-end encrypted message.
A similar example is how Windows changed their OS to require a PIN, which can be a password if you figure how to. It then asks you for this when doing completely unrelated to your OS online stuff sometimes, like some of the weird flows to do with using Teams or whatever, and I am not expecting it was asking me for my PC pin because it before that just asked me for my Online username. It is a UX issue.
The difference here is you are not throwing a match for outside money. You are actually doing something in your interest and probably not against the rules (??) so you are just playing the game (the new game) as intended.
Might be an interesting variant of chess where 2 players just decide how much of the point they get each via negotiation, and if they disagree, they go to "court" by playing the chess game.
Because it averages out. If it's a true coin flip, half the time you'll get 1 point and half you'll get 0. So it averages to an expected value of 0.5 points. 2 draws (at 0.2 points per draw) would only yield you 0.4 points. So if there's a good chance you'd draw twice anyway, it's a higher payout.
It only makes sense if you are playing multiple games against the same opponent. Let's say you get 2 points for a win, 0.5 points for a draw, and 0 points for a loss. If you draw both games you both get 1 point. But if you win one and lose the other, you'd each earn 2 points instead.
Australia "what countries have you been to and when" is fun, if you have traveled a bit. I thought being to Tunisia during arab spring and China and Russia might be issues! Overall it was hours of paperwork. Wife's grandmothers maiden name kinda crap in there too IIRC. Upside is Citizenship was relatively easy after this (because you have done PR already). Just had to learn some stuff about what happens in Canberra :-).
You need someone who is price conscious enough to forgo the cloud. Either because they are spending millions and want to be spending 100,000 or they are some small solo dev who is being tight. Taking the former example, if they are spending millions, they probably would be looking at Kubernetes for this. Even if more complicated, it is more industry standard. For example getting SOC2 compliance there are guides and so on, and there are training courses, and you can pull in a consultant. I am interesting on who the target is for this.
In Haskell it is easy. If you "forget" the last argument to a function, you get returned a function where you can provide that later on. A bit like saying "you can fill this in later". That is a "curried" function.
Example
add 1 2 // add is curried, you can use it like this, the "normal" way, returns 3
p = add 1 // since add is curried I can also provide just the first argument
p 2 // and then apply the last argument to the intermediate results, returns 3
What is the point of using curried functions in JS? I am not really sure. It is not very ergonomic and I wouldn't like to use them in general. Maybe for some specific things it could be useful.
In Haskell curried form is the default and the syntax and semantics really suits it. In JS non-curried is the default and it just looks odd, and you need libraries to support it. That library you mentioned doesn't look nice to use.
There is a sliding scale and even at the Haskellers have a limit of how much point-free they can take.
In JavaScript use of the style is problematic in another way: unlike Haskell in JS the length of the argument list is variable, which means that if someone adds another argument to either the caller or callee it can break the code in subtle and unexpected ways.
For this reason it’s good practice to always wrap functions being passed as arguments to another function in a lambda expression.
i.e instead of writing: g(f), you should usually write: g(x => f(x)) unless you have good reason to believe that g(f) is safe. This makes it difficult to use point-free style at all in JS.
For example arr.map(f) is generally unsafe in JS because if `f` adds an extra default argument of type number then your code will break and even TypeScript won’t let you know.
Honestly, a lot of these 'advanced' features aren't a good choice in most codebases IMO. The vast majority of 'enterprise' coding is CRUD and glue, where execution speed doesn't matter and being as simple and explicit as possible is the highest virtue. And the significant number of professional coders who worked hard to get their heads around things like pointers and printf format specifiers are still plenty productive in those kinds of codebases.
Things like currying are fun but like anything that encourages gratuitously deep call trees, they wreck your locality of reference (as a developer) and force you to 'decompile' the code in your head in order to understand it. I'm sure that a top level developer would be able to write curried JS in such a way that it was clear and readable to another top level developer, but that's not the point. The code's not for you, it's for newbie who gets stuck with it when you move on.
What if you forget, not in quotes, to give the second argument? Why on earth would you want to get a type error in a completely different part of the code because you got a function instead of an integer? Wouldn't it be desirable to have the compiler just tell you that you forgot the second argument where you forgot the second argument?
Is it really valuable to be able to do:
p = add 1
...instead of:
inc = (\x -> add 1 x)
...or, heaven forbid:
inc x = add 1 x
...?
I mean, I get the idea, they're following the lambda calculus, but this is one of the things that should have been dropped when they started to expand the lambda calculus to a general purpose programming language.
> Because possibly you return the partial assuming it's a number, and try to use it somewhere else, possibly even in another file.
Sorry, I must've been more explicit instead of implying certain usage patterns. What I meant here is that I have a hard time imagining this happening because I would start working on a function by writing its type signature. Unless my types check out, I won't be able to mark this function as "done" and jump to another part of code. So the situation "you return the partial assuming it's a number" simply can not happen, that's exactly what type checking is for. By the time I use it in another place, it has to already have been type checked.
Sure, but that usage pattern is not without cost. You're basically eschewing relying on type inference across function boundaries.
I think writing out type signatures is The Right Way, but it does take time, and The Right Way doesn't always happen on complicated projects with close deadlines.
But I don't think this is a problem in practice for whatever reason. Haskell does have a lot of "big scary type error, wtf" type problems, but not from currying. Or at least it did have when I last used it 5 years ago, it may have improved in the compiler error message front.
Also it is better than JS anyway (low bar):
> function add(a,b) {return a + b}; add(1);
<- NaN
Almost as if an astronaut can come, do their thing in a whirlwind and leave for another company 2 years later, while the remaining plebs have to figure it all out.
Yeah, a lot of the codebase was like that. Some lone wolf mad genius that occasionally left pieces of pure brilliance behind, but more often than not, just wrote code that was incredibly idiosyncratic and unnecessarily reinvented. Like he'd spend several files making a color gradient visualization system with his own scales, with an enthusiastic but limited understanding of color theory, that ended up producing mostly reasonable but occasionally insane color scales. We spent several days of back and forth discussions with him before understanding what he was actually trying to do (which isn't what his code was actually doing) and then replaced it with a one liner out of a standard visualization/color lib.
The entire codebase was like that. It stood out to me as the work of someone who was very smart but worked alone and never had to work with a team, and never considered what someone trying to retrace his mental process would have to go through. He left zero documentation or comments, built the whole thing in a rush, sold it to another company, and we were the ones hired later to clean up his mess.
Some of it was very good. He was really good at efficiently encoding low level network traffic over packet encodings he invented or heavily modified. Seemed like he would've been a brilliant signals engineer or cryptologist. But having to work with his ordinary business logic code was pretty nightmarish, if interesting from a reverse engineering and psychology point of view.
It's just not how I would ever want to write code meant for mere mortals. But then again, he's a multi millionaire now and I'm a rando nobody living paycheck to paycheck, so I'm in no place to judge lol.
> But then again, he's a multi millionaire now and I'm a rando nobody living paycheck to paycheck, so I'm in no place to judge lol.
If he had not made such a big mess, you might not be getting this paycheck to clean it up. I think they call this “creating scope for other people” at big companies, real staff engineer stuff. =)
If you have just got your first job, this is what the old era was like, when the Federal Reserve was going brrrrr. You just quit and find another job, do the leetcode, get 4 offers, get your 500k-1M TC. Apparently.
