I disagree. Bitfields of somewhat unrelated fields is a sacrifice in clarity even if you understand bitfields perfectly well -- I'd argue anything requiring boilerplate sacrifices something in the way of being able to understand a code base.
530 karma · joined March 15, 2013
The other two optimizations I could see either having no impact on code maintenance, or maybe even improving it. The bitfields thing though I'd have to see super compelling benchmarks to be sold on.
For instance, if the number of blues is 25, and the (merciful) stranger says that the number of blues is not prime every day, no one ever has enough information.
And in fact, even that doesn't seem to be enough. The non-trivial part must be that at least one person knows more than they did before the statement, otherwise a merciful stranger could say 'The number of blues is less than <big number>' each day, where the big number is more than the population.
Unfortunately that stringent of a definition for non-trivial sort of ruins the problem since in the formulation is the idea that at least one person in the village gets (at least) one number closer to knowing the exact number of blues everyday, and as soon as they know the exact number of blues they are eliminated.
That being said I don't understand entirely why that is at play -- if past convictions under a statute were required to prosecute, then no one would ever be prosecuted for anything.
I'm pretty sure he did it. But the state has an obligation here to ensure a fair trial and that's what they are doing.
Right, I was referring to Go and Swift with the comment about GC. Since rust didn't have that problem, I mentioned why major adoption might not be forthcoming.
I understand that you can statically allocate all you want in Rust, but it's memory safety, particularly with regards to object ownership is one of its major selling points. Object ownership and lifetimes are trivial when everything is static.
The other arguable selling point to rust is its standard library, but much like C++ the standard library would be left aside in most embedded applications.
So it doesn't buy you much of anything at all, but it takes some work to setup, plus you are fighting the momentum that C/C++ has. Unless there is some other compelling reason to use it, I don't expect much adoption.
A lot of the things rust brings to the table aren't always relevant on embedded platforms. Dynamic memory allocation on embedded is the exception, not the rule. Everything is statically allocated, so memory management is relatively simple -- everything sticks around forever.
The things that make C/C++ good for embedded are sorta what make it unfortunate for general purpose use. The things that make Rust/Go/Swift good for general purpose use make it unfortunate for embedded use.
I think dynamic dispatch would be more permissible than you might think. You end up doing it in c manually in complicated code bases, might as well let the compiler dou the heavy lifting.
You want real time, you want a minimal OS and you probably want some of the nicer type capabilities over c.
uint16_t array[] = { 1, 2, 3, 4 }; cout << "Hello World " << 3[array] << endl;
are valid and well defined. Part of what makes memory access validation such a pain in the ass in C++ is that no attempts are really made at specifying rules for how you can come up with memory locations; just rules on which locations you can read and write from. You can do things like "((int)rand()) = 2", and nothing in the standard says this is an invalid thing to do, so long as you are lucky enough for rand() to point somewhere allocated.
But once it's in the old generation, you run right into the same issue with fragmentation and having to keep track of where deleted objects are so you can reuse that space. If the idea is that you just keep doing memcopies for all the live objects to reuse the space and avoid looking at dead objects, I'd think that that is it's own performance issue?
In C++, you have to know the difference between stack allocations and heap allocations.
If you aren't dynamically allocating anything; malloc and free performance has no bearing. As far as I know, Java has no reliable way to create an object purely on the stack (and it probably shouldn't.
And even if you are dynamically allocating a new object in C++, if it has non-pointer children, it allocates that memory too in the same allocation call.
It is true that a lot of allocations will slow down C++ a ton; but a lot of allocations can be avoided in C++ whereas in Java you don't get that fine of control.
Even then; there is nothing about the malloc+free contract that prohibits you from having an implementation that does some of the things the author talks about. You can make a version of free that marks memory locations to be freed at the nth call of free.
I'm curious on the source for this statement:
> Java's collector can free an unlimited number of objects in time independent of the number of objects freed.
That seems like it can't possibly be true in the generic case.
I don't know enough about this person to say one way or another whether he was a high ranking al qaeda member or not. But _even if he were_ I don't think insisting on a habeas corpus rights for detainees or decrying torture is a _damaging_ thing at all. It was up to the state; who originally imprisoned him and almost certainly tortured him to prove his guilt. They didn't even attempt to do this; and it likely had nothing to do with not wanting to reveal intel -- the 'court' he'd have been charged in had little to no due process, and the evidence was presented to a government tribunal, not to the defendant.
I think Smiths point there wasn't that there was some problem-meanness correlation, but that the justice system as it is structured doesn't even try to have a sensible metric by which to sentence by. I think framing it in terms of damage done to society is a reasonable one. Under such a metric, (unarmed) robbery should be treated with much less severity -- and daresay rehabilitative measures as opposed to just imprisonment -- than rape or murder. That seems reasonable, and not particularly evil as worldviews go.
Even here, you ask the candidate for their salary range, instead of just stating what yours is.
If the salary isn't posted, it's a negotiation. There isn't a hiring manager alive that will blow off a potential hire because they ask for 5-10% more than the initial offer. They might not give it to them, but they won't walk away because of the question. Naturally, as a hiring manager, you might very well offer 5-10% less than your maximum in order to either give you bargaining room, or come in under budget for the position.
It's lightly adversarial, sometimes unpleasant, often annoying, but a part of life unfortunately. Some places more than others for sure, but I think it'd be hard to escape it fully.
It is true that making sure you are on the same page salary-wise is a good idea, but it doesn't always have to be the interviewee to establish that.
I think a central hub for public comments, with source, and available PDF would be incredibly useful for CS as a field. For most papers I had access to, to get the source I'd have to go through at least one person. So I tried for quite a while to replicate the result before even trying to get access. If it was available, on say github, I'd have grabbed the source code as a resource to understand the paper, and with something like publicly available commenting, I think it'd have been a non-issue.
The problem is, I can see how such a system would be incredibly constructive to the field and the community, but it could be a liability to the authors, and would make publishers meaningless, so I doubt it happens anytime soon.
I got access to the source code, and the super complicated algorithm added almost nothing to the results, the glossed over / hand waved past data normalization worked so well that there wasn't a need for any further classification. This paper was pretty well received and cited, despite it basically not work.
I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.
If you are grabbing from an external repo, the spotty network is going to mess you up either way. If it's internal and your internet is that spotty, consider hosting a local npm cacheing server like this -- https://www.npmjs.com/package/sinopia.
My only issue with this technique is that 'npm start' and the rest aren't smart enough (please correct me if I'm wrong and there is a way to make it care!) to grab dependencies if you upgrade a dependency version and check that in.