People keep reinventing those and thread pools over and over in C++. I've been researching one of our older systems (slated for decommissioning in 2021, as is typical that did not happen). In trying to understand it I have found many areas of concern around how they deal with concurrency, in particular they created their own queue and thread pool. Based on past experience, there's 50/50 chance for each that they were created correctly (with proper concurrency controls), and less than that that the tasks submitted to the thread pool themselves make use of proper concurrency controls rather than assuming that they can read/write whatever they want as if the system were single-threaded.
> I don't know why, but a search on either Bing or Google for "posix shell" points to the older version.
Probably because it's only been out for a few months. I've found Google is fantastic at returning Python 2.6 and Python 3.7 or 3.8 documentation without jumping through hoops in my search terms (if it lists the official documentation at all rather than blogs and random tutorials), but lousy at getting anything current. I imagine they have the same problem with other new material.
It's an example of Combinatory Logic. For another example check out SKI combinators. SKI is actually kind of close to this but using three combinators instead of one it's a bit simpler to understand (IMO).
Note that the I combinator is redundant since `I = SK`, so all we really need is `SK`. There are alternatives like Iota with a single combinator, but they're essentially an obfuscated mix of S and K; so it's usually clearer to stick with SK.
Note that the first two rules of this Tree Calculus are precisely those of K and S.
Oops, sorry; I got part way through writing I = S K K, but went off to another tab to double-check, and forgot to update that expression when I came back!
TDD stands for "Test-Driven Development" not Design. Your design could change radically after creating the initial tests, they should not be used as a way to freeze your system unless there really is a true finished and complete state for it. (This is true for any test suite, not just those developed doing TDD.)
This thread is showing how people miss the mark when it comes to any of “best practices”.
TDD is test driven development but it should not freeze your system. If you make system testable it is the opposite of frozen. So if you design system to be testable it already should be more flexible.
The design here is one notch of abstraction above.
Also tests should not freeze anything as they should be removed if not needed. If you write 20 tests during development it doesn’t mean those 20 tests are needed for future maintenance.
> Which implies a cost of at least 2x in dev hours.
No, not really. I have no idea what led you to believe that.
Think about this for a moment: does TDD force you to comply with a target coverage metric? Is the TDD police going to knock on your door if you leave out a usecases? What about a whole component?
How many seconds does it cost you to add a test checking for the happy path?
> Of course it does. You only write production code to make tests pass. Hence 100% coverage.
No, not really.
TDD just requires red-green tests when adding features. You can add a test that only checks for the happy path.
More to the point, nothing forces TDD practitioners to succumb to the hypothetical slippery slope fallacy of having to follow a fundamentalist path 100% of the time. Why do you believe that nonsense if even unit test best practices stay clear of 100% test coverages?
I mean if you do whatever you want and call it TDD, of course it doesn't restrict you in any way. But then any discussions about the properties of TDD are pointless. Anything you do is "just the right amount of TDD". Anyone who does less is "not doing TDD". Anyone who does more is a "fundamentalist dogmatic obsession-driven..."
> I mean if you do whatever you want and call it TDD (...)
If you know what is TDD then you wouldn't make mistakes such as believing each and every single unit of code must have a test. That's specious reasoning and slippery slope sloppy thinking.
> But then any discussions about the properties of TDD are pointless.
Not really. You're just succumbing to slippery slope sloppy thinking. Adding a red test and working your way up to a green test is self explanatory. Being contrarian just wastes everyone's time.
Because test is code, it has bugs, it needs refactoring, needs to update dependencies, creates technical debt just like the code it is testing. We could even create tests for the tests to be sure our test suíte works. It is just a tradeoff of speed and increased complexity.
If you don't bother with tests, discussing TDD is like famine victims discussing nutritional levels reported in food labels.
> My tests are usually bigger than my implementation.
That's perfectly fine if you feel your tests are important. Getting back to the topic, TDD does not enforce coverage targets or even minimum coverage bars.
It’s currently just in name only. But that is likely to change soon in some form yet to be revealed when the new government is sworn in.
So legally it isn’t in government yet, however as it is officially part of the elected governments plans, you can make a sensible argument that it is part of the incoming transitional government that has been elected and while having now power due to not being sworn in yet, is indeed part of government by nature transition teams and the president elect having status in government by way of things like security briefings and other rights and privileges normally only held by the incumbent government like increased security protection…
It would be like saying a government in exile (a well established precedent of history) isn’t a government and none of the people in it are in government…
It is not going to become an actual part of the federal government, as a new agency, unless Congress makes it an agency. And if they do, then Musk likely would not make the transition to head it as that would involve too many conflicts of interest for him (at least if we still consider laws as things that matter in this country, that is definitely a concept that's quickly being discarded by both the elected leadership and the electorate so you may be right).
Ok, I’m really not sure why the simple answer isn’t getting across here.
His position as co-head of the nominal “department of government efficiency” only exists due to the legitimacy it has been granted by the recognition granted to it by the incoming administration… otherwise we would all be calling it some variety of the first buddy’s pet think tank and arguing over if the incoming administration would even pay attention to it or not… that is a government granted position of power, a position that it is pretty hard to argue is not part of the government that grants it legitimacy… therefore making it a position in government… even if it’s unpaid and advisory… it’s still practically in the government if not legally (for all the conflict of interest reasons you highlight)…
I’m not trying to make a civics or political science case here… I’m talking politics as the exercise of power by government upon the governed… he is currently having breakfast lunch and dinner with the incoming president, making arguments and shaping the cabinet, and contributing to the transition team… he’s involved with government… he’s “in” it.
His and Ramaswamy's roles will be advisory, and specifically targeting cutting government spending. This is not a pro-government thing except that they both have significant conflicts of interests which will influence which parts of government they suggest cutting and which they suggest leaving more or less intact.
Using regulatory capture to further your own economic interests is still pro government, it's just that it's a government aimed at meeting the needs of a very small number of oligarchs rather than the majority of the population.
> Musk said there are over four hundred federal agencies, that's more than the number of states.
That's a silly way to weigh your decisions and valuations. "There are more than four hundred federal employees, that's more than the number of states."
The number of agencies is itself mostly irrelevant, it's their individual size, effectiveness, and appropriateness that matters. Do all of them need to exist? Almost certainly not. But do we need to cut it down to one per US state? That's an arbitrary and useless target.
> But do we need to cut it down to one per US state?
I'm sure they could be reduced down to similar areas of operation. One of the first to be cut being The California High-Speed Rail Authority (CHSRA). Who has so-far spent 16 years building 119 miles of track at a cost of $14 billion. That's roughly $66,845 per yard.
That's a state agency, outside of the scope of DOGE except that it receives some (probably a lot of) federal funding. If you want this to be a serious discussion don't suggest cutting agencies because of the total count of agencies or cutting state agencies in a discussion about federal agencies.
No, he's leaning strongly anti-regulation, particularly those that impede his businesses. He's big on government because that's a major part of his revenue (DOD, NASA, and various TLAs). He's not big on the parts of government that slow him down or would cause his taxes to be higher for things he doesn't care about.
The real story is that he's anti-anti-competition. His competitors in particular already have deep ties with the government and its various departments. Companies like Boeing, Lockheed, etc. have engaged in deep regulatory capture to prevent competition from emerging.
These already established corporations have a revolving door with the government and that's the real impediment. That's what he's against.
So while you're right about his self interests, I think it's important to clarify that the decades long entrenchment of these various incumbent corporations is why this is all happening in the first place.
No, a more efficient government would help those easiest to help, and not help those who were expensive or difficult to help.
Unless you just mean we could do exactly the same things, but more efficiently. But that is not what is meant; it means stopping doing a lot of things.
reply