Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Re: Sorry, not corporate enough. (Score 3, Informative) 69

You're probably unaware that the GP specifically used 'HSBC' because they were caught laundering trillions of dollars of drug money and nobody was indicted.

He probably isn't unaware of that. He may well have actually read the indictment itself or a detailed summary of it, which made clear that the US case was very weak to the point of hardly working at all. In particular, not only did they fail to clearly establish that drug money was really moving (their case was "there is so much cash, some of it must be from cartels") but in particular they failed to show intent by HSBC execs to help drug cartels. Actually their case boiled down to HSBC didn't try hard enough, they weren't suspicious enough, etc. (I'm ignoring the Iranian transactions here which gets into issues of international jurisdiction, as you only brought up drugs).

The reason you think the are guilty is twofold. Firstly US anti money laundering laws are unbelievably extreme. The PATRIOT Act removed the need to have intent to be found guilty of money laundering. Bankers can now be found guilty of AML violations even if they genuinely tried hard and had no intent to break the law. Hence the accusations from the DoJ that were of the form "HSBC should have designated Mexico as high risk", etc. Secondly as part of the plea agreement HSBC had to act guilty and accept whatever the DoJ said about them. So you only heard one side of the story, the prosecutions side (except there was no court case). No surprises that you think the whole thing is cut and dried.

It's no crime to be ignorant of such things, but just try not to hold any policy positions on the subject.

Given that there was never any court case and HSBC was never able to defend themselves, pretty much everyone is ignorant in this case because we never heard the full story. But I'm pretty sure if DoJ had emails from HSBC execs that looked like the ones from BitInstant there would indeed have been prosecutions.

Comment Re:Why bother? (Score 1) 421

Compiler optimizations don't really help if your code is I/O or input-bound, which accounts for most of the code written today - so users rarely see the benefits. Occasionally you get a situation where one particular code path is CPU-bound and is hit often enough that optimizing it matters, but in that case it's usually still easier to use C++ for that particular bit, and some other high-level language for the rest.

Granted, with all the changes already in C++14, and more good stuff coming in C++17, C++ itself gets more high-level every year. Right now I'd say the problem is really more with the tooling than with the language... debugging C# or Java is still a much more comfortable experience than debugging C++. But it doesn't have to be that way.

Comment Re:Why bother? (Score 1) 421

Promises and async is indeed a good point. I've been writing async (UI) code in C# for the past two years, and have almost forgotten what a mess it was before tasks and await.

BTW, async/await is also proposed for C++, though it is a much more generalized construct there:

http://www.open-std.org/jtc1/s...

VC++ has a preview of the implementation in the current betas:

http://blogs.msdn.com/b/vcblog...

Comment Re:Revolution (Score 1) 628

But the rich will not recognize that until the mobs with pitchforks are breaking into their gated communities.

It only needs to happen in one place for others to recognize the urgency. Just like the communist revolution in the USSR prompted the rise of the welfare state in the West (and, with the collapse of the USSR, welfare state is also slowly evaporating).

Comment Re:Why bother? (Score 1) 421

This is subjective. But it certainly goes beyond "remembering whether to capitalize the first character of your methods and variables", at least if we're talking about idiomatic C# vs Java.

Granted, Java is catching up with lambdas and the associated library stuff in Java 8. But it is still hampered by type erasure, and libraries haven't picked up on their use yet, while in C# the patterns that only really make sense with lambdas have been idiomatic in libraries for a few years now.

Comment Re:Why bother? (Score 4, Interesting) 421

Perf of JVM vs CLR is a complicated topic. Generally speaking, JVM (HotSpot, specifically) has an edge when it comes to optimizing code, but CLR has an edge in that some of the language semantics generate more efficient code to begin with. User-defined value types (structs) and non-type-erased generics thereof make a big difference there.

HotSpot is better at optimization because it can afford to be slower - it can interpret the bytecode for rare code paths, and only kick in the full-fledged optimizer after it figures out that something is worth optimizing. CLR doesn't have a bytecode interpreter at all, it always JIT-compiles on first call - which means that the compiler has to be fast enough, and that in turn means shedding slow but effective optimizations.

Of late, .NET Native is an interesting piece of tech that precompiles .NET apps using VC++ compiler backend. So you get all optimizations in your .NET code that C++ normally gets. Of course, it's still slower due to the more deterministic but less memory-friendly sequencing and memory model, and all the extra runtime checks, but it's still faster than JIT (and, I strongly suspect, HotSpot, though I don't think anyone has profiled them yet).

Slashdot Top Deals

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Working...