Why isn't academia fixing these problems? Why us? Why are profs so lazy that they can't fix their issues? You guys are so entitled to your control that when it comes to benefitting society it goes to "nah, let the students handle the stress, we don't care if we rape them privacy wise". Sincerely Pathetic
It's the money. In the past the instructor would have given each student an oral exam, but with introductory classes with more than 200 students that approach doesn't scale.
> Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time)
It would make the paper more readable to newcomers to explain this. The author was too smug and as a newer person in the Rust community I wish people who cared enough about writing papers also cared about making them accessible :/
This is a really hurtful and dangerous line of thinking. Imagine if you went to a Doctor and they said "you came to me to fix the problem, therefore you must not be sick".
This implies to be depressed you MUST be the worst form of depressed, or nearly suicidal to be deserving of help.
Common advice when designing an API is to experiment with using the planned API before you implement it.
TDD is one way of doing this exploration, where the exploration is codified into actual code using the API and including assertions about the behavior you intend to implement.
sure! write a few tests pretending your thing is already implemented, to capture what you want it to do. at this point it's a step beyond writing no test and just typing `YourThing.Do()` in a text editor. does it make sense? is it awkward? should it even be `YourThing` or `SomeOtherThing`? what the "unit" is of what you're testing might change, or its API might. you're basically just trying to get a sketch of what it's like for the user.
now, at the end of this, you'll have a clearer idea of the external API boundary, probably a clearer vision of how it should work, _and_ code you can test against. you've potentially just saved yourself the labour of writing the thing, realizing it needs to be redesigned, and rewriting it.
I guess the hesitation I have is a do all that, and find out the real implementation should have just been something like adding a new field to an enum and adding/adjusting some if statements.
It seems like a giant waste to build an api, when the there is one I could just extend. But to confirm I can just extend that api, I'd need to first implement the change to see it works.
right, i'm talking about implementing something new. if you're trying to refactor or alter an existing codebase, it can be even easier: you add another test to an already existing suite.
i don't think i've ever sat down, written tests for a completely new implementation, only to find that i need to add a field somewhere. before i sit down to write tests, i do some preliminary thinking. i'm not saying, write tests without ever trying to think first. but do use tests to flesh out your change from outside of the black box.
On desktops and laptops, it Usually Should Just Work (tm). The general culprits for issues are proprietary graphics and wifi drivers as well as shoddy BIOSes with broken ACPI tables, but I never had to dig this deep.
For embedded systems, the situation is more complex, as the chipset needs to support it - suspend itself is not the problem in most cases, but wakeup is - for example, the Raspberry Pi does not have a dedicated interrupt (https://github.com/raspberrypi/linux/issues/1281). If you're working with an embedded chipset, your best bet is the manufacturer, they have to deal with that in the BSP.
Whenever I read comments like this, I think "Why is he trying to use a 10+ years old Ubuntu, or similar"?
Or do I just make way luckier buying choices? Suspend to anything has worked flawlessly out of the box for my devices since 10+ years.
Do you have a specific example of what is not an "obviously bad hardware combination choice", but yet still does not correctly support Suspend-to-RAM?
Right? I think there was something architecturally wrong with the app that the refactor fixed. It doesn't sound like react was the problem here. I sincerely don't believe that this sort of change and therefore the decrying of react for it makes much sense at all without seeing this guy's code.
