Interesting that your first counterexample is Charlie Parker. I've been listening to a lot of Phil Schaap's Bird Flight recently (https://www.philschaapjazz.com/sections/bird-flight). It's funny to see how many of the episodes are Phil describing a recording session more or less like this:
"The Bird showed up two hours late to a three and a half hour recording session. They recorded one take each of six tracks, but the recording engineer was surprised when they started so he missed the first half of the first track. And that's how we got the five tracks on <INSERT CRITICALLY-ACCLAIMED ALBUM HERE>."
FWIW It's not at all clear to me how this requirement would be implemented in practice: "This syntax would explicitly be limited to orphan implementations."
Maybe I'm missing something, but the compiler can tell whether an implementation is an orphan. That's how you get an error message today if you try to write one. So I don't know what difficulty you have in mind.
The classic AVR instruction set does not include multiplication, you have to be targeting a device that supports AVRe+, such as an ATmega rather than an ATtiny. Try adding -mmcu=avr5 and it will show up pretty quick. Example: https://godbolt.org/z/x951M8fn8
The new ATtiny 0/1/2-series parts are full AVRxt cores with a few instructions removed due to lack of need for large memory access. The classic terminology differentiating product lines isn't particularly useful anymore. ATtiny can multiply now.
What an incredibly on-the-nose anecdote, I love it!
The term of art for this strategy is "size to the horizon". Imagine you're looking across an open plain. The trees and rocks closer to you are bigger and you can make out more detail. The ones further away are still abstract.
You have to know exactly what to do with the things right in front of you, but you have to keep only a general awareness of that which is distant.
On the one hand, we like to encourage learning here. On the other, we prefer not to copy-paste a bunch of possibly-irrelevant content. Well, forgive me for pasting in a StackOverflow answer that may be relevant here: https://stackoverflow.com/questions/11276259/are-data-races-...
> Are "data races" and "race condition" actually the same thing in context of concurrent programming
> No, they are not the same thing. They are not a subset of one another. They are also neither the necessary, nor the sufficient condition for one another.
The really curious thing here is that the Nomicon page also describes this distinction in great detail.
I apologize if my comment came off as snark. Your comment was nothing but pasted text which ommitted relevant detail, so it was not clear what the intent was. In context, to me, it did not seem to be illuminating. It actually seemed to be introducing confusion where there previously was none.
Data races are not possible in safe Rust. Race conditions are. The distinction is made clear in the Nomicon article, but commenters here are really muddying the waters...
Clearly there is still confusion since we don't agree (as does other the aforementioned poster).
I could have also belittled your comment as "bunch of possibly-irrelevant content" since most of the content was and still is unnecessary snark.
But then it would have said more about my own etiquette and capability to debate objectively than about the topic at hand.
Our definition of data race seems to differ, and because you don't seem to be able to separate objective discussion from personal attacks, I'll stop here.
> I could have also belittled your comment as "bunch of possibly-irrelevant content"
That doesn't really make sense because there are other witnesses, so everybody who knows about this topic can see immediately that you're wrong and the other person is right.
Test code is code. It's as much of a burden as every other piece of code you are troubled with, so you must make it count. If you're finding it repetitive and formulaic, take that opportunity to identify the next refactoring.
Just churning out more near copies is not a good answer.
Absolutely this! I was very guilty of over complicating test code to use abtractions and reduce boilerplate, but it certainly resulted in code which you could not always tell what was being tested. And, you'd result in nonsensical tests when the next developer added tests but didn't look deeply to see what the abstractions were doing.
I now find it is best to be very explicit in the individual test code about what the conditions are of that specific test.
> If you're finding it repetitive and formulaic, take that opportunity to identify the next refactoring.
It doesn't really matter how many helper functions you extract from your test code, in the end you have to string them together and then make assertions, and that part will always be repetitive and formulaic. If you've extracted a lot of shared code, then it might look something like "do this high-level business thing and then check that this other high-level business thing is true". But that is still going to need to be written a dozen times to cover all the test cases, and you're still going to want test names that match the test content.
There's a certain amount of repetition and formulaism that will never go away and that copilot is very good at.
LLMs are pretty good at anything that follows a pattern, even a really complex pattern. So unit tests often take a form similar to the n-shot testing we do with LLMs, a series of statements and their answers (or in the case of unit tests, a series of test names and their tests). It makes sense to me that LLMs would excel here and my own experience is that they are great at taking care of the low-hanging fruit when it comes to testing.
I agree. A very high impact change I made for an application my team is working on was allowing easy creation of test cases from production data. We deal with almost unknowable upstream data and cheaply testing something that was not working out has reduced the time to find bugs tremendously
I consider an ORM to be any SQL generating API, without which it would indeed be impossible to have a generic Admin class to make Admin views in Django.
What should I call a program that generates SQL, executes it, and stores the result in a tuple, object, or whatever data structure in the programming language that I'm using? Does it magically stop being an ORM the second I use a tuple instead of a class instance, or is it now an ORM plus another nameless type of program? Are tuples also objects?
Traditionally, though, SQL generation was known as query building. The query was executed via database engine or database driver, depending on the particulars. ORM, as the name originally implied, was the step that converted the relations into structured objects (and vice versa). So, yes, technically if you maintain your data as tuples end to end you are not utilizing ORM. Lastly, there once was what was known as the active record pattern that tried to combine all of these distinct features into some kind of unified feature set.
But we're in a new age. Tradition has gone out the window. Computing terms have no consistency to speak of, and not just when it comes to databases. Indeed, most people will call any kind of database-related code ORM these days. It's just funny that ORM no longer means object-relational mapping.
I think the core thing that ORMs do is create a 1:1 mapping between the data structures in the database (that are, or should be, optimised for storage) and the data structures in the application (that are, or should be, optimised for the application business logic).
ORMs create this false equivalence (and in this sense, so does Django's admin interface despite using tuples instead of classes). I can see the sense of this, vaguely, for an admin interface, but it's still a false equivalence.
I agree with you, but I do think there's a little fuzziness between full-blown ORM and a tuple-populating query builder in some cases. For example Ecto, which can have understanding of the table schema and populate a struct with the data. It's just a struct though, not an object. There's no functions or methods on it, it's basically just a tuple with a little more organization.
> It's just a struct though, not an object. There's no functions or methods on it
Object-relational mapping was originally coined in the Smalltalk world, so objects were in front of mind, but it was really about type conversion. I am not sure that functions or methods are significant. It may be reasonable to say that a struct is an object, for all intents and purposes.
A pendant might say that what flimsy definition Kay did give for object-oriented programming was just a laundry list of Smalltalk features, meaning that Smalltalk is (probably) the only object-oriented language out there, and therefore ORM can only exist within the Smalltalk ecosystem. But I'm not sure tradition ever latched onto that, perhaps in large part because Kay didn't do a good job of articulating himself.
ISA cards, like the soundblaster had the MIDI and joystick on the same connector. The joystick had up to 4 analog inputs, maybe that's what's meant here.
The PC game port is a nearest thing to intentional GPIO that PC has. Parallel port is almost always better for digital GPIOs, but it was not designed that way and the fact that it can be used like that (and extended several times into what in the end was SCSI-like protocol) is kind of an coincidence.
> The PC game port is a nearest thing to intentional GPIO that PC has.
Er, what? Not every IBM PC (clone) had a (sound) card with joystick ports, but almost every PC clone had (ISA, later PCI) extension slots. There were/are plenty of digital i/o adapter cards for those available, from plain, cheap 8255 based ones to those with slave CPUs (potentially more powerful than the host's CPU).
But then, perhaps I don't understand what you mean by 'intentional' GPIO.
"The Bird showed up two hours late to a three and a half hour recording session. They recorded one take each of six tracks, but the recording engineer was surprised when they started so he missed the first half of the first track. And that's how we got the five tracks on <INSERT CRITICALLY-ACCLAIMED ALBUM HERE>."