ByteJockey

This isn't a guaranteed full time job. For all intents and purposes, it's a short term contract with very little notice. Dev time is like anything else, if you buy in bulk (say... 2000 hours a year) and on a regular schedule, you can get some pretty good discounts.

I'm in the mid-west, and that's a little under my rate for short-term low-notice (read: emergency) contract work. I can't imagine anyone on either of the coasts is going to jump at it.

> The big philosophical difference to me is in what each side believes the proper role of government should be.

I think you're close here, but I don't think that's the root of it. That difference in position is important, but it comes from even deeper philosophical differences. I think this boils down to the argument over positive vs negative rights (freedom to vs freedom from).

A worldview built on negative rights has to have a much smaller legitimate role for the government than one built on positive rights. In the former, the government can never make anything better, only potentially rectifying wrongs (usually via punishing the offender). Within that framework, the goal of the government becomes to rectify the worst of the wrongs while disturbing things as little as possible. A worldview built on positive rights inherently leaves a bigger space for the government to behave legitimately, because this worldview sees the government as having a role in making things better.

Of course, there are very few people who adhere 100% to either of these, so reality is a bit more complicated.

I can't do VSCode anymore.

I want to make a big stand about Microsoft and free software and tracking and whatnot, but I can't here. I break those rules at work all the time during time crunches.

It's kinda petty, but the bits of screen real estate it steals around the sides of the screen are too distracting for me after having gone full vim for a while. You can hide most of it, but the activity bar keeps showing back up after doing something like opening the git/file explorer/etc panes.

The IntelliJ line is a bit better, you can hide everything pretty easy, but I don't always have a corporate license for those, so I tend to avoid depending on them.

Does PHP control nuget packages? No. No they do not. Neither does Python (the python package you linked to is managed by a Microsoft employee).

I thought transform boundaries were the big earthquake risk (not that there is none at convergent boundaries).

At least that's what I remember from my 8th grade earth science class. I could be really wrong.

Emacs has a great editor...

The evil package.

> forced to implement interop

I didn't read this as the EU forcing the apps to actually implement interop. I read it as forcing them to publish the details of their protocols and not ban people for using 3rd party clients.

Now, will market forces force them to implement interop? Maybe, but based on my reading an app that doesn't talk to other apps is still legal.*

*Do not base your entire business strategy off of a single HN post from someone who is not a lawyer.

You seem to be using "pollute" as a synonym for "releasing CO2", while Yoric does not.

I think the two of you are talking past each other.

> I live in a neighborhood where the median income is below the national average by about 10% and above the national average by about the same amount.

My brain is not parsing this sentence properly. Could you elaborate a touch?

I'm reading it as "the neighborhood median income is, at the same time, 10% below and 10% above the national average income", which is only possible if both the national average and your neighborhood median is 0. I presume I'm reading it wrong.

You can in firefox (just tried from the console).

It failed because the porn companies all went for VHS (for licensing reasons iirc).

Porn companies have decided basically every format war (including pioneering streaming).

Google controls JS to the point of being able to ignore the spec (e.g. that time they left TCO behind an experimental flag and it just went away despite being in the spec).

As long as node and chrome are so dominant, we're probably not going to see big shake-ups in JS that aren't driven by Google themselves.

JS is flexible, you can cover up a lot with polyfills, but not completely different syntax. Doing that without Google's buy in would create a rift in the internet that would either end with browser specific web pages, or with the complete loss of power for the committee that sets the ECMAScript spec as JS officially goes from being a language that is defined by a spec to a language defined by a canonical implementation (in this case V8).

I reckon you might be right about that last part, unfortunately. I wouldn't be surprised if somewhere deep down in the human brain it just defaults to trusting the person who looks most like your parents/siblings/children/etc. Absent some other compelling reason/conditioning of course.

I wonder if the melting pot doesn't deserve a reboot. Everything else seems to be getting one these days.

If you're looking for a download, someone posted a mega link higher up in the thread.

Convenience link: https://mega.nz/file/GKQQVbTY#1QmzfH7r2LAilAZU2RixI4yp-9IU6Q...

> concept of ingroupness based on shared ethnicity, language and culture, in contrast of ingroupness based on shared commitment to universalist ideas like freedom, rule of law and democracy.

Is the latter not also nationalism, if you believe that those ideals create a group that is worthy of self-determination? Maybe it deserves its own qualifier, such as ideo-nationalism, to distinguish it from ethno-nationalism, but does the motivation fundamentally change what it is?

> OTOH, it is likely that the real reason why countries really work is because of some level of nationalism

I think you're probably right here. The question I have is if you can make that nationalism about something other than ethnic groups?

You absolutely will (almost certainly).

But if you take the set of people who have written free operating systems, there's at least one big winner.

In languages like JS/Python, you can mock imports. Actually, sometimes you can mock things defined in the same file if you set things up right.

Basically, the logic not being inlined into the function is enough to provide this behavior in certain languages.

This is not true for other languages, which is why DI frameworks tend to be more useful there.

In go specifically, I just always throw the dependencies behind an interface and shove them into a struct. Then you just create a struct of mocks for your testing.

> Seems like you're saying a person who bought a thousand euro phone and couldn't get it repaired under warranty after a month of mild use is "risk-averse" if they dislike that experience.

I'm saying that a person who is risk-averse should probably avoid this. There aren't very many third party repair places yet, so you're completely at the mercy of a single company.

There's also an increased risk if said company is based outside your country (or supra-national political union, should you live in one). It's harder for a country to force a company in another jurisdiction into compliance.

Yup. FZF is where it's at. :Files to jump to a file, :Rg to search around for some content.

I also keep vinegar around for when I want to poke around at the contents of a directory.

> The device costs over a thousand fucking euros!

Well yeah. Buying something early is the most expensive time to buy it. The inefficiencies haven't been worked out of the manufacturing process yet, and there's not an established wide customer base to spread the R&D over yet.

Radios in the 1920s cost over 100 hours of wages for a lot of people. TVs in the 50s were stupid expensive. Computers in the early 60s were literally hundreds of thousands of dollars. And all of these things were pretty garbage compared to what you think of today. Hell, the computer from the early 60s could probably lose a math race to a seasoned abacus veteran.

In exchange for the high risk and high payment, you get to play with something that might be cool, and you get bragging rights (depending on your personality type, one of these might excite you more than the other).

> Any decent company would fix it, full stop.

Well, probably. I'm not going to defend samsung here. They're acting pretty garbage.

But the point about new tech being risky, is entirely fair. If something's still exciting, it's probably a good idea for the risk-averse to avoid it.

Most of these examples are about mammals. I'm pretty sure those aren't the majority of animals. I'm pretty sure it's insects. Well, for land dwelling animals, I'm not actually sure about ocean dwelling ones. With the amount of ocean we've mapped, do we actually know that side of this?

I think it's doubtful that they refuse to send packages there.

I could see them excluding the area from the normal time guarantee, or from free shipping or something.

They send it via the normal postal service or you pay the extra for the higher priced service.

Penicillin wouldn't have been a thing in the 20s, but I believe the others would have been around.

> most animals have consciousness, emotions, language, etc.

Ok, so some I could see (elephants, dolphins, etc), but if it's most I'm gonna need a source on that.

Bingo.

We did a similar thing except replacing the values with a UUID and storing the pair in a lookup table somewhere. Delete that row and none of the rest of the data is able to be tied back to a human being.

Bonus, most people didn't need that data, and it was no longer given out to everyone who grabbed the entire dataset.

> Having worked in insurance, this piece makes me wonder what languages are typically used to write software in insurance or other business medical type settings.

I'm not sure if it's different for medical insurance, but I worked with a company that did other types of insurance (mostly life with a smattering of others), and it was Java as far as the eye could see. Most things that pre-dated Java were done in COBOL.

> Very often in code like that you see "struct" types filled with function pointers.

Fair point. Though with the explicitness that's required to do this in C (you have to pass the actual struct pointer that would normally be the receiver, along with a general lack of inheritance) results in code that's much easier to understand than the patterns that the traditional OO languages have created for themselves. I suppose that's less of a criticism of OO itself and more of a criticism of the people who build languages that emphasize OO, and the general ecosystems that crop up around them.

> written in a "pre-OO" language

I would be remiss if I didn't point out that the "OO languages" go all the way back to Simula67, which predates C. Though at that point OO was still in its "academic" phase the way functional programming is today.

> Has anyone seen large scale development done successfully in an an "anti-OO" language like Rust?

Taking "anti-OO" to mean languages that specifically don't have OO capabilities (rather than languages where you can choose not to use OO). Any of the large C code bases?

Could be, I suppose. Though for most of those, I'd expect them to have approximately the same impact as voter id laws. The big exception being voter roll purges in states without same day registration, that one seems most likely to have an impact.

> given the narrow margins that we often tend to see.

Most elections really aren't that narrow (hence the high incumbency rate). The few that are just end up dominating the news cycles.

That seems more likely to be because the GOP has rigorously cultivated a base that's advantaged by the electoral college.

It's just weird how much culture warring happens over this when most people are ambivalent at best, and the types of voting restrictions we're talking about don't have much of an impact on turnout.[0] I suppose everyone has to have a hobby, but I guess I kind of expect this stuff to track things that are salient to the populace.

[0] https://academic.oup.com/qje/article-abstract/136/4/2615/628...

Convenience link to sci-hub for anyone wanting the full text: https://sci-hub.st/10.1093/qje/qjab019