allover

Tbf Microsoft have won back a lot of good faith with developers due to projects like VS Code and TypeScript, even for those of us who remember their past.

And we're yet to hear of any negative impact of their Github acquisition (afaik - correct me if wrong).

> "matchers" [...] let you test values in different ways

Example docs for Jest's matchers: https://jestjs.io/docs/en/using-matchers

Generally speaking, if you use a specific matcher, you get a better (more informative) error message when the test fails.

Because in the grand-scheme of things, the countries that have banned guns don't have the problems you have.

Crazy, I know.

I think you're missing that Europeans also recognise that giving every dumbass, desperate person or dormant psychopath a gun, is far more likely to get people killed NOW, than the chances that when the 'end-times' you imply come, all these same people are going to someone effectively unite and overthrow the regime.

It's a crackpot idea to think that 'arming citizens' helps the whole. And the fact you think it's 'arrogant' to spell out a basic truth that the rest of the world understands is dumbfounding.

More reasonable than the anti gun control people, but it's still an insane solution to the problem, in the grand scheme of things.

Um, why not both.

The rest of the world doesn't have the school shooter problem.

It's fixable, and the fix is bleedingly obvious. There's no excuse.

He said the drills are misguided though right?

Not that the US obsession with guns and lax gun control that enables school shootings is defensible.

Deaths of children. At school.

For literally nothing.

They are _avoidable_, that's why they are not overstated.

You're _honestly_ saying that fears over school shootings in the US are overblown because it makes for good news?

I don't think there's any need to sealion the author on this.

To your first question: JS's warts are well understood. You must already acknowledge this if you're a TS fan.

To your second: TS isn't 'actually' safe, to the extent something like Elm is (i.e. very small chance of runtime errors). This is also no secret - there are lots of examples out there if you care to search for them.

Not sure if the HN thread or my comment has thrown you, but I'm replying to 'kazinator'.

I know he's not defending it.

What I said is that he (kazinator) is inadvertently attacking somebody that's also not defending it (the author).

I agree, things shouldn't be this bad.

But unless you're going to take this up with Linus, you're just yelling at your fellow disappointed spectators.

You are now ignoring the fact that in the initial quote you objected to was the intentionally tongue-in-cheek:

> 'For a Git user interface this is relatively straightforward and concise'.

It kinda looks like you missed the joke and are now doubling-down on your disagreement.

The author does not think the proposed example is reasonable. You're in agreement.

> when they migrate from monolith to microservice: development is easier [...]

Not even that -- that idea is still highly debatable.

I would argue that it absolutely isn't easier, and the stepping-back-in-time of developer experience is one of the biggest problems with microservices.

Microservices in general, are way, way harder.

> Such an implementation would be GDPR compliant in not tracking any personal data, although your counsel might still say you need to list them as “analytics” cookies in a cookie banner (mine did).

Your council should also have advised you that you need active consent in your cookie banner, since GDPR raised the standard for consent, which is the stumbling block I'm facing. [1]

[1] See "In brief": https://ico.org.uk/for-organisations/guide-to-pecr/cookies-a...

As someone going through this right now, the main difficulty in being GDPR compliant with GA is the cookie problem.

You can either disable cookies to run GA in cookieless mode [1], which presumably will affect how GA performs, since they can't determine repeat visits (but this might be fine, depending on the type of site you have), or you need to gain active consent to enable analytics cookies [2], which isn't much good if you want metrics for all users, not just those that opt-ed in.

If someone has solved this reasonably, I'd love to hear how! For now it seems like cookieless is my only option.

[1] https://developers.google.com/analytics/devguides/collection... [2] https://ico.org.uk/for-organisations/guide-to-pecr/cookies-a...

I never cease to wonder if articles like this are incredibly cleverly put together, or incredibly stupid.

I feel like it would take me so much effort to string together these unrelated things and try to present them in a faux-scientific manner, with such succinct certainty, in the way this article does.

Like how they smartly concede that they're waiting for answers, ... and then they quickly breeze through making a bunch of connections, with references that don't back up what they're saying, as if these are all just 'known' things. It's kinda clever, and I would expect a lot of people to be fooled.

You will see it defended a lot on Hacker News, due to the disproportionate level of PL enthusiasts, and the Paul Graham thing. But yes, you're right that in reality, lisps have incredibly limited popularity. (You've met one more full-time Lisper than me and I've been in the industry for 10 years).

What is your bar for 'average users'?

If we're talking project-wide repos rather than entire-org repos, I'd wager the vast majority of projects can use monorepos without special git tooling, and will retain huge productivity benefits vs app/package-per-repo organisation.

> Sure, if a package absolutely needs exact dependencies for its entire tree

Not sure you're talking about the same thing as everyone else.

There's a big difference if you're maintaining a package vs maintaining an app.

If you're a "package" maintainer, you don't want to pin dependencies. Because the package consumer (i.e. people building apps using your package) should not have their exact versions dictated to them.

If you're an "app" maintainer, you absolutely need to check in your lockfile, because you should care about repeatable builds.

> But package lock is ignored for all users of your npm. Only root package’s lock file has effect. This makes it useless in most cases.

But package-lock is intended to be used at the project level. i.e. lock all package versions in the current project or app.

That isn't "useless in most cases", it solves specifically the case it is meant to solve.

> It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design.

But you're stuffed if you need to rebuild the docker image later, or for example, go back to an old commit/release, create a 'support' branch to retrofit a change and build a new image. You want repeatability all the way down.

> Code smells if a change works with one lockfile but not another generated around the same time.

This isn't true at all. You can't predict when a new, potentially breaking, version of a dependency might get published. It could happen a second after you generate your lockfile, or create your PR.

At time of PR creation we could have versions 1, 2, 3 and 4 of our transitive dependencies.

At time of merge we could have versions 1.1, 2.2, 3.3 and 4.x available.

Dependencies are outside of your control, so always "smell", that's why it's crazy to do anything other than pin the heck out of them.

> I don't really. If you only wanted to control your first-level dependencies

They didn't say "only", they said "things like".

But a lockfile is not like "any generated file", because for typical generated artifacts they should always be generated the same, for the same commit.

This is not true for a lockfile, where the whole point is to capture the specific versions at the point in time that the generation is done.

The benefit of the contributor committing the lockfile is that it encodes the exact combo of dependencies that worked at the time the related code changes were made (in the same PR).

This means other project maintainers aren't left scratching their heads trying to figure out why a PR worked on your machine but fails in CI.

> No,

I think you mean "Yes, but also ..."

I never said people would "choose" TS because it's in its heyday, I said it'd be an unlikely time for most to wish to justify a switch back.

TypeScript is kind of in its heyday though, it's fairly unlikely many teams would be comfortable making a bold decision to "switch back to JS", even if they want to.

Would need to be given more time for such a statistic to be meaningful, if it ever would be.

> Syntax, yeah, whatever.

The vast majority of the programming world simply doesn't seem to agree.

> "you don't know what you're missing".

I think I do. I've had the argument many times here, code-as-data, metaprogramming, structured-programming. Things I don't want, aren't worth the trade-off, and things I don't want to see colleagues inflicting on others.

I've already watched (almost) every Rich Hickey video (well his main "talks"). I love them, agree with the vast majority of what he says and it has shaped me as a programmer, but I don't agree with the final conclusion being to code using lisps ;)

> were it not for my using an Open Source solution [...], it would be impossible for me to hook up [...] and other devices to Homekit without a bunch of different gateways (because some Zigbee endpoints simply refuse to talk to anything other than their own peers).

And worse, in my "casual" case, because some sort of Philips/Apple agreement outright prevents it :/

E.g. add a "Hue compatible", but non-Philips bulb to your Hue hub. It will work in the Hue app and via Amazon Echo, but Homekit will refuse to see it.

A way to "trick" homekit to be able to use the bulb with it, is to create a Hue scene, and sync it to homekit, but that is terrible for per-bulb control. This stuff is apparently all Zigbee, but the usability situation is an absolute mess.

(Widely reported, for many years, not a bug).