skysight-inc/HackerNews huggingface dataset:
The first-mover advantage [0] is very present in popular success stories like the iPhone(1) and it's an easier (less effort and risk) strategy. The strategy having a better product like Facebook and Google Search is not that appealing.

To further elaborate, if you're first you can have an unpolished product which grants you gratification sooner and with less effort. If you want to enter an existing market you have to gain customers with much effort and risk (the competition can react).

Side note: the better toaster was sold first in the 50s and doesn't stop anyone of selling worse toasters :D [2]

[0] https://en.wikipedia.org/wiki/First-mover_advantage
(1) The first iPhone was the first smartphone as defined today.
[2] https://www.youtube.com/watch?v=1OfxlSG6q5Y
The units here are poorly designed - for example, I'd expect the LocationProvider to be responsible for choosing how to get the location, not the caller - and this makes them hard to test. The solution is fixing the design, not throwing out unit tests entirely.

The standard reference on this is http://www.growing-object-oriented-software.com/ .
But ironically that's what causes the failure of the alternative platform they've moved to.
This title is wrong. It's not the tool's or technique's fault.

Unit Testing is not overrated. It can have been overrated by some of us sometimes or most of the time, depending on who you are.
> Refactoring usually changes interfaces.

No, refactoring shouldn't change public interfaces. The very definition of refactoring is rewriting code without changing interfaces.

> Things are factored differently.

internally

> In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.

https://en.wikipedia.org/wiki/Code_refactoring

You got the definition of refactoring wrong, please get it right, it's important. If you are breaking a public API, you are not refactoring anything.

Any piece of code meant to be private shouldn't be unit tested at all, only the behavior of a public interface.

Now internally you might call a third party lib, but that third party lib is then a separate "unit" itself.

I don't like the term "unit" because it's yet another word that is easily misunderstood and lost its original meaning with time.

unit testing should really mean "public interface behavioural integrity testing" or something like that.
Intel needs a Satya Nadella. Every time you think CEOs are overpaid, think about what he did to Microsoft (bad CEOs should not be CEOs regardless of their compensation).

Over the last 10 years, Intel lost mobile (never seriously competed, probably NIH from the old guard not wanting to embrace ARM SoCs), gave up on modems (bad management probably, they were into wireless tech early), could not compete in the GPU space, lost their performance prime to AMD, lost fab edge to TSMC, lost laptop processors to Apple and maybe cloud to Graviton and co.
Would have lost AI too but they bought Habana so the jury’s out on that one.

That’s gross mismanagement from a company with no excuses. They need a Satya with a fresh look on what the company is actually adept at. Regroup and attack.
> The second cohort is a multiple in size of the first.

That's a weird way of looking at it. The people who do $job provide food, energy, building materials etc and taxes so some people can specialize on medical research.

It would be terribly inefficient if we just switched over the majority of the population to medical research. I doubt they'd make much progress, and at the same time pulling them from their normal jobs would create a lot of problems that would make some 10 million excess deaths projection pale in comparison.
A couple of ways of looking at unit tests:

* a 'journal' - at the date this test was written, this is how we expect the system to behave

* an ELI5 - if I'm trying to use this method, why am I passing all these complex objects?

Unit tests declare expected behaviour, and should make the developer think about their methods.

For example, why pass complex objects to just to print a string or a count or similar? And why pass those objects? could a method be generalised to take a lambda, or an interface instead? Could the method be pure? And so on.

Unit testing isn't overrated, just a bit misunderstood.
Try reformatting a large code base without unit test. You'd pull out your hair trying to rename a variable.
unit tests are the equivalent of repl for languages that are not designed. you need unit tests to close the feedback loop. you can't simply write code for days without having any feedback. some code simply does not have an obvious immediate visible feedback on the ui
You Can't Use Prebuilt LLVM 10.0 with C++17
The API and the packaging standard is the main contract between users. Once everyone has agreed to the fact that they need to package their applications into containers, the orchestration can be done in any way. Google's Cloud Run uses Kubernetes API + Container packaging but doesn't actually run on GKE, it's running on their regular old compute engine and users don't even come to know.
I use unit tests for complex units of code and depend on frameworks to do simple things correctly. Like I don't need to write unit tests for inserting things into a database. Unless there are complications around it.
It's a perennial but: unit tests are more about how you think and rigourously approach a problem than preventing regression. I'd say if you wrote unit tests and then deleted them, your code would be better for it. Indeed, I often don't commit some of the tests I've written in order to write the code! I'll ship some subset of them. It's a notebook.

They serve as a form of living documentation for the code and help increase velocity in a build under the right conditions.

For example, you do need to know a certain function does what you think it does because the rest of the system isn't even in place yet. You might have to approach this from the outside, via integration, but the speed of doing this is quite slow. Versus a unit test.

This is not to mention refactoring!

The piece seems to be more about the value of mocking and how far to go with isolation. Which is a slightly tangential issue. I agree that in particular styles of object orientated programming this becomes absurd.

This article, which is linked provides a more convincing case, on the grounds that unit testing foregrounds the system as software as opposed to the software as a useful and functional thing in the world, meeting user needs.

However, it omits the being about to _react_ to user needs is actually a central party of agility. Unit testing allows maximum reactivity to changing requirements without regressions in the code and makes this code navigable. Changing customer needs means your carefully built functional tests are going to be just as useless and rotted. This has been the case with large test suites of functional tests - say in something like Cucumber - I've seen. Better test at a lower level, which moves slightly less rapidly.

https://www.sacrideo.us/the-fallacy-of-unit-testing/
Something like sqlite can actually be unit tested to 95% or so. If you stretch the definition of 'unit test' a bit (don't mock i/o).

Try that with a networked application that takes user input though...
That doesn't give A any jurisdiction over B or C. They're simply retaliating.

It's important to talk about the same thing.
We probably traded off getting some very contagious diseases but sticking together to living off by ourselves. In the long run it seemed to have been a good decision for our species.
If you also didn't know Idris 2 was out, check here [1] for what's new.

[1]. https://idris2.readthedocs.io/en/latest/updates/updates.html...
There were hundreds of proto-twitters before twitter. It isn't about being the first to think of something and attempt an implementation.
One argument made for unit testing which this post doesn't address is that it's easier to understand and debug unit test failures.

To which I say: yes it is, but quality debugging tools (which don't exist in many domains, and aren't used nearly as much as they could be where they do exist) can mitigate this issue. I'm talking about tools like https://rr-project.org and (self-promoting!) https://pernos.co.
Yeah, but those QA dashboards monitored by management....
This isn't what jurisdiction means.
Hiten Shah explains how to find product-market fit
> What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing).

A contract system like clojure's spec sounds close to what you're describing.
How do you find yourself in so many of these on-the-verge-of-a-facepunch situations?
It's terrible, like why is the repo title all the way on the left and not centered?

I guess UI designers need to justify their job somehow. Just like the Reddit redesign, it's damn awful :(.
Cost includes the impact on further tests and maintenance.

The cost of testing and debugging increases as you go down the development/release cycle.

If you have unit tests then that helps integration tests (less issues, easier to investigate), system tests, etc. all the way down to dealing with bug reports from the field.

> but most units are not that complex and should not require unit tests.

That is a very bold claim...
Weird that you started using a functional approach, noticed that it’s easier to unit test, and drew the conclusion that unit testing is what led to more readable code. Consider that functional code is the source of readability. Also we don’t typically call it “dependency injection” in the functional world
I think it's a critical mass of people experiencing the "unit tests pass but the code is broken" problem. When unit tests are used to test glue code you end up testing your mocks and nothing else. Mocks are often done using a framework which encourages one off implementations per unit test. This introduces a maintenance burden where all the mocks have to be kept in sync.

Unit tests are very useful but we somehow landed ourselves in a place where we have lots of line coverage in our unit tests but little confidence that the code actually works.

There are at least 3 different applications at work where they unit tests are green while the code is broken or red when it's not. The cause is almost always the mocks. They either presume too much, making then fragile or they are flat out incorrect. Despite having a lot of test coverage there is little confidence for the developer that their change is correct.

In a sense the writers of the tests were "doing it wrong". The burst of articles on unit tests and their failure modes are a reaction to the prevalence of this in our industry.
This! Not just for the systems development side of things, but just as much for normal usage. I tend to do work for fairly small organizations (<500 ppl), but with layer upon layer of bureaucracy and management, not to mention cultural and geographic differences.

The main goal of the systems I work on is to provide technical documentation of complex industrial processes. If things break, it can be pricey and/or dangerous. Having good information is a must.

However, if a user sees that something is off or just plain missing in the sometimes 30+ year old documentation, the easiest way to deal with it is to make a note of it and adapt to it for his or her work. Reporting the problem back in order to get it fixed is....difficult. There probably is a process for it, you probably don't have an account where you can log the time spent on it.

Having a quick and low-threshold way to report problems would be of enormous value in the long run.
There isn't pure functions the moment you touch any kind of IO.

Plus the same problem arises with modules instead of objects, which traditionally are even harder to customize.
opinions on blog posts are overrated
Exactly. The same applies to the individual, and exposure to bugs is beneficial to the immune system https://en.wikipedia.org/wiki/Hygiene_hypothesis
Perhaps the problem isn't mocking dependencies, but trying to hide the fact that GetSolarTimesAsync needs two pieces of data to work: a date and a location.

But the original signature is just this:

public async Task<SolarTimes> GetSolarTimesAsync(DateTimeOffset date)

That introduces a lot of complexity:

* The SolarCalculator needs to be able to work out its own location, so it needs a LocationProvider

* SolarCalculator needs to be IDiposable since it owns a LocationProvider

* The SolarCalculator will need more methods if it ever needs to calculate the times in a different location

* If fetching the location is slow, but the application needs to calculate times for multiple dates (eg to build up a table of times), then the SolarCalculator will need an method that takes in an array of dates to be efficient

But all that could be solved by making the function take all of the arguments it needs to return its value:

public SolarTimes GetSolarTimes(DateTimeOffset date, Location location)

No location provider needed, no IDiposable, just one efficient stand-alone method.

Unit testing this is now just:

var calculator = new SolarCalculator();
var actual = calculator.GetSolarTimes(new Date(...), new Location(...));
var expected = new SolarTimes(...);
actual.Should().BeEquivalentTo(expected);

...so, perhaps the issue isn't that unit testing is a bad idea, but that code which is hard to use in a unit test might also be hard to use in a wider application? And perhaps the fix is to make the code easier to use?
I’ve Seen a Future Without Cars
A Woman Who Needed to Be Upside-Down (2012)
Suppose you have a unit that makes a couple of api calls to set itself up, then performs a computation, then does some sort of storage. Thinking about how you would test this might lead you to an inversion of control approach, and you might isolate side effects. The storage provider might get passed in, both to make it easy to mock, and to reduce coupling and surprise.
Sick people are sort of viscerally gross, we're repulsed by wet coughs, even the sound of vomiting some people can't cope with, not even on a movie -- it's an evolutionary response, I think. Animals probably have similar feelings around sick people.
How to Manage Snap Updates
God I hate this stupid industry so much
I've read that 40% of all deaths as of the first week of June were in elder care homes, a lot of them in NY and NJ where C19 patients were _sent to the nursing homes_. It's not so much a partisan issue as it is absolute shit state government issue. The decision to decimate the elderly was made at the state level, without exception. Governor Cuomo in particular needs to go to jail, in spite of granting himself immunity for this.
Exactly, the 80-20 rule also applies to unit tests. I don't have 100% coverage on big projects, but everything I write that's meant to go in production is in TDD anyway, so there's always enough tests to prevent a junior from breaking my stuff, and I save a lot of time because thanks to TDD I don't need to manually test much, and most of the times not at all, I just wait for user feedback: it's always much easier to have code working in real conditions, if it already works in test conditions, not the other way around.
Thankfully using strongly typed languages and IDEs keeps my hair in place.
Getting Investment for Your Startup
Not especially useful advice if the long run is longer than your lifetime. npv of cashflows is not a useful metric for most popular stocks
Engineering a good code base is very hard and is unique to every project and the mentality especially in the .net community of "loosely coupled code is good" usually ends up over engineering and adds more complexity than necessary.

I've seen far too many cases where added complexity has killed the project's time budget because things just take so much longer to do. You need to maintain a healthy balance and actually evaluate if writing this particular system within the project in a way where we can "swap it out" later on is actually a use case.

Every project is unique and "unit testing all the things" might not be the solution for your project. Where I work we shifted our mentality when we highlighted this problem to only unit test bugs and write less decoupled code and in bigger services that are more mission critical we do integration testing instead. This works very well for us but as highlighted earlier, every project is unique and you should experiment what works for your particular team because what works for others might not work for you.
Please dumb it down for me how it does so.
> Yet we continue to treat it (economics, the global financial system) as some kind of inevitable force of nature, rather than as something that we invented and (to some degree) chose. I wish I knew why that is.

If you want a good guess; the economy is complicated, there is no consensus on how it works and the plurality position on how it works among the public is badly misaligned with reality.
The author agrees with you, in that he makes the same recommendation around testing the functionality rather than the functions.
> This is the very opposite of diversity.

And of course diversity for diversitys sake is the highest principle there is.

Also, all people with similar interests are carbon copies of one another.
Striving for very high test coverage seems like exactly the kind of thing you want for your database infrastructure.
> Who goes digging into old commit messages to understand what a piece of code does? I know I don't.

If long-term-ism in commit messages isn't something you care about (which is understandable), then consider short-term benefits. When working with my team, I'm able to read some of their recent commits and understand very clearly what's being worked on, without needing to dive into the code or have daily stand-ups which aren't producing any value on their own.

Think of it as an asynchronous way of describing what you're working on, and the broader context.
Also ARM chips for server use is rapidly starting to become a serious thing.

It's - of course - very small scale and early days at the moment, but the pricing is very positive and it's something people are starting to think about as a real viable option.
By the market position of Amazon and Microsoft versus what Google keeps trying to do, and there are enough candidates for that 3rd place.
It Wasn’t My Cancelation That Bothered Me. It Was the Cowards Who Let It Happen
To be fair, Intel enjoyed high highs and AMD low lows. It took them a while but now we actually have competition it turns out Intel are not so good after all. Funnily enough they moved beyond the Quad Core just as AMD started offering something decent.

My next processor won't be an Intel, especially with all the speculative execution crap that went on (and yes, I know it affected AMD too).

Intel's business practices are shitty, and quite frankly, they need to be torn down a few pegs and bleed a little, either they die out or they come back stronger.
Back in my day, Reddit was just one thing, they hadn’t developed subreddits yet.

Reddit was a better Digg, just as Digg was a better Slashdot. Like Digg before it, there was an “Eternal September,” and one of the consequences was that Paul Graham launched Hacker News to preserve the culture that was being diluted.

This is one of the reasons HN has a strongly opinionated culture and the appetite for firm moderation to maintain that culture: It’s not just a tool for YCombinator, it’s a deliberate attempt to maintain something that was repeatedly lost when previous “hacker” social media sites hit the mainstream.

Even if we look away from its more controversial aspects, at the root of the issue is a simple truth that all successful social media sites become their own worst enemy.

You and I can exchange arguments about whether Reddit 2008 was or wasn’t better than Reddit 2014, but fundamentally, I suspect we agree that “dilution” has a certain effect on culture.

The flip side of that, of course, is “Who are we to scoff at the newcomers?” I am not a more valuable user than someone who joined yesterday, and there is nothing wrong with a social media site evolving to serve newcomers with new tastes and interests.

My son loves exchanging Star Wars and other memes on Reddit. I love that HN doesn’t do memes. C’est la vie.
Interesting project, but since this seems to be limited to Rust, what’s the point of WebAssembly, instead of writing JS extensions directly in Rust?
It is relative easy to ask developers to implement ways to charge users; how accessible is it to the end users?
I don't understand this reasoning at all. You have some form of contracts, whether you specify them or not. If it's too messy to formalize, that's still going to be an issue when you're working on it in an untyped language. At best you're just sweeping all those ugly edge cases under the rug.

>Also, what stops something like

having a more precise specification. E.g. adding a commutativity requirement would eliminate your example.
b, to_s, to_i, to_a, to_c, to_h, to_r, etc.

Should have said methods but you get what I mean. And I've encountered ambiguous and pointless abbreviations all over the place.
"however many find it encumbering and superficial."

Author doesn't want to write unit tests. There are two factions of people on the internet, those that write unit tests and those that don't like to. Nothing has changed in the last 15 years.

Whenever I write many unit tests I feel happier and more confident. If I don't and catch up writing unit tests, I always find bugs in my code. Never haven't I found bugs when increasing test coverage from a low start.
Use Flatpak.

It just another bad move from Canonical in a long list of terrible failures, which weakend Linux fundamentally:
* Upstart vs Systemd
* Mir vs Wayland
* Snap vs. Flatpak
* Unity vs. GNOME and Gtk
* Ubuntu Phone vs. you should have teamed up with Nokia and Maemo before...

Looks like they don't learn. The fork and fight against the others and always lose.

Nowadays Ubuntu is upstreaming usefull patches to GNOME, again. Thank you! But imagine what GNOME and Gtk could be look like already, when Ubuntu had "helped" them earlier. I could be already a lot of better years ago? Mutter, Gtk, Terminal and Nautilus. GNOME is healthy! But they could so much better years ago.

Forking is good thing, when it aims initially for a merge.
SARS is a coronavirus and there's never been a vaccine for it.

How do you know there's a vaccine on the horizon?
Not sure, but there’s plenty of stories out there that one could probably be compiled.
Small warning: There’s a slightly shocking gif in this article, which possibly depicts animal cruelty. (Hard to say exactly what’s going on in it).
Dell XPS 13 2020 review: a fantastic but flawed laptop
Free recorder for Google Puppeteer (Jest puppeteer)
Hi,

I'm Thach - Smart Monkey's author.
I have added a functionality to Smart Money for exporting a project to Puppeteer code. Here is the video for demo: https://www.youtube.com/watch?v=eBzK85MOo-A

In the most of cases, you don't need to write any line of code for creating a test suite.

If you have any question, please comment!

Sincerely,
Thach
Understanding Your Digital Afterlife
The kill rate for the disease the example animal (lobster) the article spends most of its time discussing is ~50%. It isn't surprising that avoiding it is a highly consistent and avoidable behavior since the competitive advantage is so large.

Humans kick people out far before the stakes are that high. I'm reminded of how people with Leprosy were treated before there were drugs to treat it.

Generally speaking "hanging around with the least fit members of your species" is a losing strategy if you want to not starve long enough to reproduce so it should come as no surprise that evolution selects for the trait of avoiding the least fit members of one's species to varying degrees (depending on the specifics of the species and the type of "least fitness" in question).