quelltext

> The number of times I have seen junior programmers try to solve the halting problem would make you weep.

In what context?

What you describe is an example professors used during my education to motivate theoretical CS studies, i.e. you don't want to be THAT guy.

However, while this is true, I haven't yet seen many junior programmers on the job trying to solve the halting problem. I don't quite understand why that would be common. But maybe you are talking more about online communities and side projects?

Need for Speed in the 80s?

FWIW, I agree with your argument (I guess).

Regular expressions are complex and oftentimes a tool might be necessary to get a better idea of what an expression will match. However, if we were to make the language to describe them more verbose that'd still not solve this issue. Having a concise way to describe them is a good thing. Those who grok them can do so quickly without having to read several lines of a more descriptive language and those who need assistance can still plug them into a tool.

Yeah, don't think it's a given (and you have more context to determine that). It's just what comes to mind when hearing/reading about a buried knife (i.e. something you don't typically bury & could be evidence in a crime case).

Doesn't that regex detect correct spellings instead of wrong ones? I.e. it matches tier, tie, etc.

Or it was a murder weapon.

Looking at the URL here. Wasn't the whole point of naming it COVID-19 to not have it relate to / blamed on a geographic location.

Calling it the Wuhan Virus is not great.

SG interiors are ACed to ice age levels though.

IIRC the SARS outbreak in 2003 was "contained" within that year.

Sorry, I didn't mean to imply everything can be well tested, but where it can tests make sense even if they don't cover everything (vs. the attitude that testing is pointless unless you can cover all relevant code paths).

Also, I don't think there's as much value in unit tests than other more holistic types of testing, i.e. functional/integration tests.

TBH I read your linked article and still don't quite know what a test harness (in that context) is and in what way it's better and differs exactly in the concrete. Guess I'll have to read up on it elsewhere.

> Tests are a usability dead end -- I know this may be contentious, but I believe test suites are another realm of excessive moralizing en lieu of better tools and better processes. Too often they function as a security blanket that simply encases the parts of the code that are unit testable, while leaving the vulnerable, untestable bits fluttering in the wind. Approaches such as generative testing seem more promising.

I'm not quite sure what the author is arguing for here in particular.

Anything that makes writing tests a bit easier, e.g. suggestions for additional test cases, would be cool, but ultimately tests are about writing down your assumptions/expectations about the code.

No, they are not formal proofs and sometimes they are not perfect but they still provide a lot of value. So far I haven't found a good reason not to write tests (since I outgrew my newcomer attitude) and yeah integration tests are usually what I focus on most. For any case where testing whole systems today is hard, there are some fundamental challenges (e.g. end to end web UI test). I don't quite see how tooling will get rid of the need for tests.

I have a few friends from Germany who started out in Hauptschule and later had to work hard to get their Abitur after the fact. It's possible, though really hard.

They tell me there are options to move on from Hauptschule to Realschule, etc. if that's really what you want and have the drive. The problem is the environment. Everyone around you isn't going to college, they're all going to work in some factory or as a salesclerk, and you're a nerd if you try to advance.

One other factor here is I think that it's usually the parents who decide your future early on. Yes, there's recommendations by your school, but AFAIK this is not definite and can be overridden within reason.

However, if the parents never get the Abitur or have many friends who did, they'll be intimidated, even if your grades are perfect and you got the recommendation to go on the university track. So often they put you in the same school track they took since they know what to expect.

It hinders social mobility. On the other hand not everyone wants to go to college, not everyone wants to study and rather get their hands dirty in a job that doesn't require a degree. Forcing those who don't to stay in school (if there's a single track) till the end with a lot of struggling towards the end (and then the stigma of not completing would be bad as well) maybe graduating with bad grades... that doesn't sound ideal either.

> "Managers would never get away with breathing down employee's necks, personally monitoring their screens or logging toilet and water breaks,"

They wouldn't? Isn't that reality for a lot of workers?

FWIW they do mention it's 2 business days on their docs and have been for quite some time if I remember correctly.

https://stripe.com/docs/payouts#2-day

Not sure if that was the case in the past though or when it would have changed. I don't have any reason to doubt your story, so it's possible.

What you describe would be a calendar days setup I guess and I agree that changing that silently (on the same account) would piss me off. There might be good reasons for them to change it but not without reaching out to affected users. Or did you only see this new behavior on a different/newer account?

I'd say you should raise that with their support team! It should be fairly easy to find evidence of that change for Stripe, right? And you should also be able to find evidence of the old behavior (a bit of search work in the balance history but doable).

EDIT: I tried to go back on the wayback machine and it said business days for quite some time before last year (https://web.archive.org/web/20170905023631/https://stripe.co...).

Still possible that your account is much older and you were grandfathered and then finally moved over to the new behavior long after this was standard for everyone. I'd really just check with them.

> According to the rest of the discussion on this page, Visa and other payment networks refund the interchange fee to payment processors (including Stripe) on refunded transactions.

So far said that the refund fees on the brand side specifically increased or came into existence. I don't know if they did or not. I imagine though that transaction fees rising (which people do mention in the discussion) has an effect here. If you were able to make a given margin before while still allowing refund fees to be returned. Now transaction fees increase. As a PSP you can either choose to increase your processing fees or find other ways to make even. If you can achieve that by not returning fees on refunds (and make a bit more money along the way) that makes sense to me.

My main point is that rising fees in general can be a reason here even if the card brands didn't specifically add a new cost to refunds per se.

What were those simple rules?

I'm curious of whether they really required Radar custom rules specifically or whether Radar rules would just have been more convenient than writing your own rule evaluator?

True, but you can still use the less granular risk_level. So yeah, you don't get the full detail but you can still use the data they learned.

> So as mentioned before, this feels really dirty because they are taking your private data and are profiting from it by selling it back to you and others in the form of insurance -- and there's nothing you can do about it.

No, you and everybody else processing on Stripe has left that data there whether it's used for Radar's ML or not. I absolutely don't see anything dirty with them monetizing the software they built on that data.

My understanding is that what Radar does that you cannot is the ML to calculate the risk scoring and they give that to you for free: https://stripe.com/docs/api/charges/object#charge_object-out...

EDIT: It appears that risk_score is indeed not available but risk_level is. You are still able to use your own logic to say for instance "don't capture if card country and tokenization IP country don't match and risk_level is elevated".

I honestly don't think it affects my answer much. They offer a less granular but still useful version for free.

AFAIK Radar also for free applies these learnings to the charges and blocks high risk ones for you.

> If Stripe had an API endpoint where developers could get the risk level of a transaction before the payment intent was put into motion then we could in theory build our own risk management tool at our app level by saying "if $risk_score > X then deny transaction".

But you can. The majority of what Radar custom rules allow you to do you can implement fairly easily on your own. You can take the risk scoring into account by separating auth (then looking at the risk score and make your own decisions) and capture (see link above). Granted it's a bit annoying you have to do a separation of auth and capture while with Radar custom rules you don't have to but it's not that big a deal.

There are possibly some pieces you cannot completely reproduce but for the most part you can build your own rules on your own. Even if one were to follow your reasoning of them using your transaction data to learn, Stripe doesn't owe you the part of Radar that allows you to write custom rules. That's an entirely tangential feature: Those are rather simple if statements that have little to do with the ML part of Radar.

I also encourage you to question your entire argument here. You'd have processed with Stripe if they used that data for anti-fraud ML or not. They didn't take that away from you or lured you into anything.

The actual work is in their engineers building the ML system, maintaining it (also: computing cost), tuning it, updating it, adding new data, cleaning up data (like extracting info from unstructured data on transactions).

I don't even think they owe their users the free version to be honest, but it's in their interest as well to make sure merchant exposure to fraud is reduced, and so you get it.

Blaming them for trying to make some money with an add-on system that simplifies writing custom rules like "if card country not IP country" or ones that combine the risk score, seems a bit rich.

And just to too this off I do have my qualms with some Stripe fees that seem outrageous, but Radar/Radar for teams, really?

I'm not sure what you are selling on Stripe but if it in anyway relates to software I'd expect some degree of understanding for the monetization approach.

Uhm, safety nets etc. do not really offset this. That's because Europe also has higher taxes though/autodeductions.

When someone in Germany casually says 50k per year pre tax, they typically mean pre deductions (tax and social/health insurance) and the effective received money is more around 25k per year.

People in the US underestimate how much of ones salary a European has to give up for that safety net.

I'm sure you're not the only one, but yes AOP is something a lot of people interested in programming languages have likely heard of at some point.

AFAIK no C++ does not have checked exceptions like Java does. There's no static check enforcing that a caller needs to handle (or also declare throwing) an Exception declared to be thrown by the called method.

My point was that if one wants a language that is explicit about what error types a method can cause (see the top-level comment I replied to) then checked exceptions aren't far off and in fact on the same track.

The problem you describe may be an issue with checked exceptions but it would equally be one in any language with the aforementioned feature.

> We're not going to handle each of those cases differently, if we were going to we could always catch the specific exception type explicitly.

But you don't have to handle them differently. You can though and your method signatures will tell you what type of errors you might have to deal with. Some make sense to handle on the spot others don't.

You don't get that with runtime only exceptions. With those you really don't know and can get all kinds of errors and so you expect all and then just catch all and deal with it or blow up/abort whatever is going on (which let's be honest is what most web services do). Is that good? Yeah, sometimes. It certainly is easier to do that instead of thinking about possible failure modes when you know you'll only end up logging the error and give up anyway. I'm not trying to be cheeky, it really is overkill to make full use of checked exception in some cases.

Granted I haven't seen many great examples of checked exception usages so far but I wouldn't dismiss them because they don't mesh with what you're used to or with what's common in a given domain.

I fail to see how this is different.

Say you have a function f1 returning an Either a b value then another method f2 which calls f1 but doesn't handle the error case will simply flatMap or bind or whatever the language of choice is calling it and return yet another Either a b value until at some point up the call hierarchy someone actually decides to unwrap and if necessary do something with the error case. The function signatures have the same problem as the parent comment mentioned.

flatMapping over an Either and returning the result is no different than adding "throws SomeException".

Then Option types (since they were mentioned as well somewhere) are a bit of a different story all together. They make sense for describing absence/presence if values/results and are definitely useful. However they don't compete with Exceptions in any real way since they don't really work for error handling beyond the most basic cases (i.e. where handling the error somewhere doesn't matter/need to happen).

Checked exceptions really aren't much different from dedicated return type for errors. The Either type in Haskell and its Monad is really not doing anything fundamentally different: Bubbling up errors until the point where someone cares/needs to handle them (though I have to say I hate the whole Left / Right convention thing, just define a dedicated type with proper constructors for value vs. error already).

In fact I'd say checked exceptions are a richer formalism since they essentially provide something akin to intersection types for errors.

The fact that there are also RuntimeExceptions comes up a lot as an argument against Java/checked exceptions but that doesn't convince me. Haskell also has runtime errors that can happen (division by 0) that are outside the Either or Option/Maybe world. The problem is maybe rather that people are lazy and the trend became to decide that everything should be a RuntimeException because who needs all that noise and checked exception handling, right? I'm fairly certain that people who rejected checked exceptions would also reject the more functional approaches.

My argument is that no consensus around using checked exceptions correctly ever developed and so they never really had a chance to shine.

Having said that, sure I think having more usage of idioms we find in FP for error handling/propagation or early aborting is great. It's better than just raising runtime exceptions. However we are still in a world where no widely known language actually enforces (!) error handling in that fashion. It's all convention in the end.

And so my point was that if you want a language that tries to encourage error handling, with known failure modes communicates in the method signature then Java's checked exceptions sound pretty close.

Sure they are not perfect but the question is whether it's worth exploring better formalisms along the lines of first class errors with dedicates language support or piggybacking on the existing type system features and introduce conventions? The latter sort if works but I find it less ...exciting.

Probably because it's Kebap in Turkey as well.

I think they may have simple misunderstood what your example was about (G, not asm(...)).

On the other hand their criticism contradicts their earlier point about widely used public/stdlib function names best having short names.

Because it forces (or at least strongly encourages) you/users of such a stdlib/API to explicitly think about and handle the null case and the non-null case if you want to access the contents directly / unwrap. At least that's the idea.

I am probably in the minority here but I think Java was on the right track with checked exceptions.

For some reason "Apple engineer" is used a lot (see title) in discussions around this on both ends (i.e. "he was an engineer and thus knew his stuff/was credible, and he voiced some concerns to friends/family, so let's agree with it being Tesla's fault" vs. "he was an engineer and should have known/anticipated the system's caveats"). The thing is you cannot have it both ways, so I think (and I think we agree) we should not appeal to the driver being an engineer at all.

I mean, I get what you're saying, but they have a point. At least I learned a curious new fact, i.e. that he doesn't have a PhD, not that it matters, but still I thought he did given his work.