namingthingsiseasy

In case you weren't aware, there are extensions that you can use to restore the older (better) UIs. Here are a couple:

• https://addons.mozilla.org/en-US/firefox/addon/wikipedia-vector-skin/
• https://addons.mozilla.org/en-US/firefox/addon/classic-wikipedia/

There are probably some for other browsers as well. I don't use them though. I instead wrote myself a tampermonkey script to change it:

if (!window.location.search.contains('useskin')) {
  var new_url = window.location.protocol
      + "//" + window.location.hostname
      + window.location.pathname;
  if (window.location.search == "") {
    new_url = new_url + "?useskin=monobook";
  } else {
    new_url = new_url + window.location.search + "&useskin=monobook";
  }
  new_url = new_url + window.location.hash;
  window.location.replace(new_url);
}

You can compare the available wikipedia styles on this page to see which one you like best: https://en.wikipedia.org/wiki/Wikipedia:Skin?useskin=monobook

I think most of the arguments here are kinda ridiculous and poorly thought out. A lot of them also sound pretty imaginary and made-up. For example:

To assert that frontend languages are not programming languages is to assert that what one is doing when writing them is not programming, but something else. Something different.

Something—perhaps not explicitly spoken, but undeniably implied—lesser.

Basically, he's arguing that everyone who thinks HTML/CSS isn't a programming language is wrong, and then the only reason they feel this way is because of a prejudice against front-end developers. I think this is really just a wild leap in logical reasoning, personally.

(No mention of Javascript/Typescript here by the way.)

If you wanted to find the dev specialization with the most people who aren’t cishet white males, you’d pick frontend.

Do we honestly believe the language around frontend is different purely by mere coincidence?

... yes? His argument that HTML/CSS should be considered programming languages is honestly quite weak. Couldn't that be the reason instead?

Certain pursuits are validated with importance, dignity, and honor.

Doctors; lawyers; architects; CEOs; software engineers.

... we relegate others to the role of the sidekick - even though their labor is no less important, and they do at least as much to push the work toward success.

Nurses; paralegals; interior designers; executive assistants; frontend developers.

Who the hell is making these groupings?? Front-end developers compared to nurses? Software engineers to doctors? And software engineers being held in the same light as CEOs... wtf???!?!?

(Surely it’s a coincidence the first group tends to be more male than the second.)

Once again, he's attributing his feelings with prejudice when really, I think his arguments are just very poorly thought out.

Other forms of development are generally considered serious work. They’re important. They’re real computer science. (Computer science itself being a higher level of things we’ve decided are real, serious, and important—maybe not quite as much as medicine or law, but then again, maybe so in some circles.)

Again, I don't see anyone arguing or claiming this. I'm sure the author would argue that just because we don't say it aloud, but it's just implied, but I honestly just think no one says it because it's just silly.

Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.

Though critical to the project, frontend work will quite often be disregarded by those who consider it beneath them (usually men, and usually only tacitly, never explicitly). It’s not serious enough; not important enough; not real enough. Too squishy. Like soft skills.

Once again, just unfounded accusations of bias. "You didn't say it, but I'm telling you that you said it anyway."

Their [software engineers'] output is easily measurable. A new API feature; a more efficient database; crises averted and crashes prevented. They go on charts and get presented to board members.

Board members couldn't give less of a shit regarding what software engineers do. We're considered a cost that they'd love to get rid of as much as any other position. Look at all the AI hysteria going on right now, like Nvidia's CEO telling people not to go into software because it won't exist anymore. Again, I have no clue where this guy is getting his ideas from.

If our job title does include the word “engineer,” it will almost certainly specify what we’re engineering. It’ll be UI engineer, or frontend engineer, or maybe the newer (and arguably more fitting) design engineer.

But it’s probably not “software developer” or “software engineer” without any other qualification. Because that, tacitly, is not what we do.

Completely disagree. Front-end development is a subset of software engineering. He even admits this as much:

Sure, this is nuance of language and these titles serve to disambiguate. I get that.

but then he goes on to dismiss that by saying "that's not really it though, it's really because we're not considered real engineers":

by definition, somehow what we do isn’t seen as software engineering. It’s different than that. It’s softer than that.

By what definition exactly? He just explained the reason for the difference in terms above, but then goes on to say that's not really it - the real reason for everything bad is (what he perceives as) negative bias.

There's a couple interesting ideas in here. He makes a good point that layoffs on the front-end are more likely to hit underrepresented classes, though there's not much that can be done about that. Layoffs are happening everywhere, and DEI is probably not what's on CEOs' minds when they make those decisions. And sure, there are unrealistic expectations at times, but that happens everywhere, not just in the software industry, but in pretty much any labor scenario.

But overall, I think this guy has major issues with his self-perception. Pretty much all of his arguments are predicated on very poorly thought-out or straight up imaginary ideas. And blaming everything that's wrong with his perception of front-end development on the white male hierarchy is just... I can barely even find words for it... nonplussing? I think he figured it out by the end of the article:

Maybe I’m feeling sorry for myself. Maybe I’m just a little depressed right now. Maybe I have an inferiority complex and I’m projecting it on everyone else.

I'm pretty sure it's all of those.

I wish this guy the best. Shit is hard right now. But I'd be a fool to say that I agreed with more than 10% of what he's trying to argue.

Nice post! I didn't get to watch too much, but in the few Lifestealer games that I saw, he looked very strong. I wonder why he wasn't picked up more. Sven looked very overrated in my opinion - a pick rate that was not very deserving given his winrate. Luna was also picked a lot in the carry role and looked pretty solid.

I'd also say that Falcons' ability to win came mostly down to how efficiently they were able to farm the map. Skiter got a lot of farm pretty much every game and carried them very reliably. A huge part of the reason why they lost so few games in my opinion.

Also, it was pretty surprising how unsuccessful Gaimin Gladiators were. Pretty much all of their core heroes have been nerfed very hard in the latest patches, so it's not too surprising, but it looks like they're going to have to take some time to figure out some new drafts/strategies to adapt to the current meta.

I could be wrong on this, but I think Kelvin is basically required for thermodynamic measurements. Entropy measurements, for example, depend on ratios between temperatures relative to absolute zero. You could still manage using centigrade of course, but you would have to offset all of your temperature measurements by 273.15

Probably a lot of other physical applications that also depend on having an absolute zero reference, but that's the only one I can think of for now.

Yeah, that second paragraph is more what I was thinking (terrible phrasing on my part). The issue is that fighting these contracts in court is risky - you might lose, and even if you don't, it's a big commitment to fight a legal case against a large company no matter which jurisdiction you're in.

To put it another way, look at it from a game theory perspective - there's plenty of benefit from putting these terms in, and no downside whatsoever. So the optimal move for vendors is to put garbage like this into the contact.

Perhaps! But only if they allowed third party app stores. Because as it stands right now, they're basically inventing a cost that they pass on to developers, and then rewarding themselves handsomely for the cost that they would have never needed to pay if they allowed others to compete in this area. It's still a tactic they could not get away with if they were not a monopoly.

These EULAs are often just corporate wishlists

Then I really wish there were regulations over what kinds of things you're allowed to put in a contract. If there were punitive measures for putting things in contracts that anyone should know is not enforceable, then maybe companies would think twice before putting language like this in.

It's not wrong, but it's just terribly short-sighted. You're giving greed-crazed companies total control over a device that you own and nobody else should be able to touch.

Shiny things come at a cost. Sure, it may look convenient and super cool to have all these features, but it's important to understand the trade-offs. And this is just the tip of the iceberg - we don't even know what kinds of malice these companies will think of 5-10 years from now when these machines are even more widespread and probably come with even more invasive anti-user hardware capabilities.

It's not wrong... it's just very very naïve.

Despite that success, and the App Store’s role in making it possible, Spotify pays Apple nothing.

That's because Spotify doesn't owe you anything. If I release a piece of software for Apple, Android, Linux, Windows, etc., I don't owe these OSes anything for that. Apple makes plenty of money selling hardware, that's good enough for them.

These delusional bastards really need a few slaps around their heads to get this concept to sink in.

According to this, the fine includes a punitive damage:

Vestager said that the lump sum of €1.8 billion had been added as a deterrent since the basic amount of the fine, which she compared to a "parking ticket," would have been quite small.

The total fine of €1.84 billion amounts to 0.5% of Apple's worldwide turnover, according to Vestager.

Still not enough in my opinion, but hopefully if this sticks, future damage awards will be even higher. In any case, there will be a lot more fines and regulations coming down on Apple into the future (thanks in large part to the DMA), so even though this is just a single instance, they will hopefully add up pretty significantly in the coming years.

Oh goody. I've been wanting to use this since my slashdot days... today is my first chance!

Your post advocates a

[x] technical
[ ] legislative
[ ] market-based
[ ] vigilante

approach to fighting (ML-generated) spam. Your idea will not work. Here is why
it won't work. [One or more of the following may apply to your particular idea,
and it may have other flaws which used to vary from state to state before a bad
federal law was passed.]

[ ] Spammers can easily use it to harvest email addresses
[ ] Mailing lists and other legitimate email uses would be affected
[ ] No one will be able to find the guy or collect the money
[ ] It is defenseless against brute force attacks
[ ] It will stop spam for two weeks and then we'll be stuck with it
[ ] Users of email will not put up with it
[x] Microsoft will not put up with it
[ ] The police will not put up with it
[x] Requires too much cooperation from spammers
[x] Requires immediate total cooperation from everybody at once
[ ] Many email users cannot afford to lose business or alienate potential employers
[ ] Spammers don't care about invalid addresses in their lists
[ ] Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

[ ] Laws expressly prohibiting it
[x] Lack of centrally controlling authority for email^W ML algorithms
[ ] Open relays in foreign countries
[ ] Ease of searching tiny alphanumeric address space of all email addresses
[x] Asshats
[ ] Jurisdictional problems
[ ] Unpopularity of weird new taxes
[ ] Public reluctance to accept weird new forms of money
[ ] Huge existing software investment in SMTP
[ ] Susceptibility of protocols other than SMTP to attack
[ ] Willingness of users to install OS patches received by email
[ ] Armies of worm riddled broadband-connected Windows boxes
[x] Eternal arms race involved in all filtering approaches
[x] Extreme profitability of spam
[ ] Joe jobs and/or identity theft
[ ] Technically illiterate politicians
[ ] Extreme stupidity on the part of people who do business with spammers
[x] Dishonesty on the part of spammers themselves
[ ] Bandwidth costs that are unaffected by client filtering
[x] Outlook

and the following philosophical objections may also apply:

[x] Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
[ ] Any scheme based on opt-out is unacceptable
[ ] SMTP headers should not be the subject of legislation
[ ] Blacklists suck
[ ] Whitelists suck
[ ] We should be able to talk about Viagra without being censored
[ ] Countermeasures should not involve wire fraud or credit card fraud
[ ] Countermeasures should not involve sabotage of public networks
[ ] Countermeasures must work if phased in gradually
[ ] Sending email should be free
[x] Why should we have to trust you and your servers?
[ ] Incompatiblity with open source or open source licenses
[x] Feel-good measures do nothing to solve the problem
[ ] Temporary/one-time email addresses are cumbersome
[ ] I don't want the government reading my email
[ ] Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

[x] Sorry dude, but I don't think it would work.
[ ] This is a stupid idea, and you're a stupid person for suggesting it.
[ ] Nice try, assh0le! I'm going to find out where you live and burn your
house down!

My advice would be to learn C first (or at least develop a good understanding of it). It's extremely important to understand how memory works in C so that you can understand pointers in C++; and also important to understand how functions work so you can understand classes and methods in C++. I would go through The C Programming Language. It's fairly concise and while you don't have to go through it cover to cover, you should at least understand the chapters on structs, pointers and functions (up to chapter 6, I believe).

(Note that the wikipedia link that I posted above has a link to the full text of the book in pdf format.)

The reason why I think it's important to understand C is because when you learn C++, then you'll understand how the language abstracts over a lot of the lower-level functionality in C. new in C++ supplants malloc in C for example, and your understanding of functions in C will map to more complicated concepts like constructors, destructors, copies, methods, and operators in C++. At this point, I would probably start learning how classes in C++ work. They're basically structs with private member variables and methods defined in the scope of the class. learncpp.com, is the best reference that I'm aware of (it's very thorough, which makes for a pretty slow read, but you'll understand it very well). I would probably start with chapter 14 (introduction to classes), and then go back to the earlier chapters to fill in the gaps, but this is more dependent on how you think you learn best.

Be aware though, that if you don't have existing experience with OO development, then C++ is (in my opinion) not a great language to start learning it, because a lot of it is hacked on top of C and implemented in arcane ways in order to maintain compatibility with C. The first language I learned was Java, and it was really helpful to have that as a background for when I learned C/C++. I'm only familiar with Javascript on a procedural programming level, so I'm not aware of its OO functionality or how well that will translate to C++, but hopefully it works out.

Good luck!