simplotek

> But, most importantly, the fundamental issue is that all classes are optional by default in Java (indeed, that's the problem at hand). Adding an Optional class doesn't really mean you can make any non-nullability assumptions about other classes, especially when using different libraries.

Perhaps it's just me, but I don't equate optional with nullable. An optional value is just the designer specifying that you may or many not specify that value, while nullable are objects which may or may not have been initialized yet.

Even though nullables have been used and abused to represent optional values, I'm not sure it's a good idea to conflate both. It would be like in C++ equating shared pointers with optional types.

> Assert usually throws an exception in most environments.

Not really. In C and C++, an assert() calls std:abort. In custom implementations it does whatever you'd like it to do. I've seen assert() call asm('int13;') out of convenience. I never see an exception once.

> I see stuff on HN and other tech boards about how terrible it is to work with C++ and how memory management will clothesline all novice and intermediate programmers. However, the Stroustrup book makes it seem like it's pretty manageable.

Plenty of people around here desperately want to vindicate their personal bets regarding other languages and framworks, and consequently you see a multitude of poorly thought-through strawmen put up to try to denigrate the other choice and, by process if elimination, leave their personal choice as the one true choice.

It's tiring. This obsession some Rust fanatics have regarding C++ drags on for over a decade, and it never changes. If they think it's so great, why waste so much time trying to drag down pseudo-rivals?

> Using these kinds of static analysis tools is pretty much essential in any professional C++ role. Could you argue that it would be better if this was a language feature instead of something that you need a static analyzer for?

Isn't Rust's shtick basically a language built around a static code analyzer? It would be weird if Rust fanatics complained about static code analysis in other languages.

> To me this looks like a deliberate leak from Amazon.

That was what I thought as well. Whether to sugarcoat propr or upcoming layoffs, this niewspiece sounds like a justification in the public's eye of why everyone at Amazon is getting the axe.

> No ... not like these. I can control any communication through these.

How do you control what other people say to you through emails they send you to your Gmail account?

I get the point you tried to make: Alexa is a listening device customers intentionally plant in their home. But if you do care about corporations listening in, you're missing the forest for the trees. Gmail alone is far more incidious and has the potential to reach far more personal information than Alexa.

> You could do "TODO fix the foobar because flange see Ticket 1234"

No, you should create Ticket 1235 - fix foobar, add additional info such as rationale and the definition of done, and add Ticket 1234 as related/blocks.

> I write TODO for something that would be too disruptive to do as part of the current change but nice to have done.

One more reason to not have a TODO item and instead track work on a ticket. Sneaking fixes/changes as part of other tickets mixes up the rationale for tickets and makes changes harder to track. If all you're doing is a cleanup then all the more reason why it should be in an independent PR tracked accordingly.

> Really? My company is on its third ticketing system.

Your company should get it's shit together, unless it's in the business of switching ticketing systems.

> If you’re regularly encountering or writing code that only works by accident or doesn’t handle important use cases, it isn’t the fault of a TODO.

You're confusing a symptom with the root cause.

TODO items are symptoms of a problem, one which can and does often manifest in code that is brittle and only works by coincidence.

> A TODO should document something that has been considered and would potentially be an improvement, but is not currently necessary.

Not really. A TODO is just a comment someone decided to add because at the moment they spotted something that might require some work, but couldn't be bothered to track it as a work item. Just that, nothing more.

> It isn’t supposed to be a flag that says “warning: I’m checking in broken code.” I

Except it actually is supposed to be a flag that states "yeah I know this is broken code but trust me I'll get around to really fix it at some time between not now and never"

I've lost count of the age-old TODO items I stumble upon on projects I've worked on that served no purpose other than either stating "I think this needs fixing but I can't be bothered to track work items in a ticket" or "I just need my PR to go through, trust me bro I'll do this right once I remember to fix my shit"

> I'm certainly not opening JIRA for it, so (...)

That's the universe telling you the TODO is useless noise that points to a workitem that no one, not even you, find it relevant enough to track or work on.

When that happens, do everyone around you a favour and leave out the TODO comment.

> Presumably your integration will automatically create a ticket from the TODO.

Creating the ticket tracking a work item is known for creating the ticket that tracks work items.

The process is also the epitome of automation, because it requires zero automation to filter TODO items and only requires clicking on a button to create the ticket.

There is no salvageable excuse for this nonsense. Work items are created in tickets. TODO items just track copouts and noise.

> What happens when the company decides to migrate from JIRA to something else?

Aren't you grasping at straws? How many times do you believe a project changes it's ticketing system? So far I saw that happening a grand total of zero times.

Meanwhile, I've repeatedly worked on legacy projects which have decades-old TODO/FIXIT items, which serve no purpose other than being noise and serving as topic in water-cooler shit chat.

> If you don’t fix it… and the code is working… what is the problem?

Because most of the time your hack only works by accident, or doesn't handle expected corner cases, or leaves out important use cases, or is a ticking time bomb.

> This is a good way to loose valuable knowledge.

It really isn't. If you have anything relevant to add regarding your hack, post it in the ticket. That's the first thing that will be read when someone picks it up. Otherwise you're just polluting the code with good intentions.

Every country has its fair share of idiots, and Brazil having a population of around 214M can easily have tens of thousands of idiots who believe and defend all sorts of braindead ideas.

This tweet is bullshit

To start off, the victimized fool was not suspended from Mastodon. The fool tried to join a specific Mastodon instance which is highly political.

Here's a link to the instance's about page.

https://octodon.social/about

> a feminist, anarchist, communist, cyberpunk culture and many trans and queer people, often with tech or scientific interests.

> "I'm not Twitter, I'll fuck up nazis, transphobes and bullies for fun".

Going into one of these instances publicly presenting yourself as a "capitalist" is a blatant and very transparent attempt at trolling regulars.

> The very public reasons he initially tried to take over Twitter were disagreement with some of the political censorship decisions they made.

You're disingenuously glancing over the fact that Elon Musk repeatedly said and did different things. As the Twitter thread I linked early clearly shows, Elon Musk was repeatedly giving assurances to marketing execs behind closed doors that he would continue moderating hate speech and extremist content on Twitter just as before.

The marketing industry is not manned by fools, and once Elon Musk fired basically all content moderators then the industry called Elon Musk out on his bullshit and promptly yanked ad spending on Twitter, explaining quite clearly that cutting moderation was a major liability.

It's amusing how people like you prefer to resort to puerile convoluted conspiracy theories to explain why ad companies stopped paying for ads on Twitter when the people who made that decision already stated in no uncertain terms how Elon Musk's actions turned Twitter into a liability.

> The Welsh language isn't part of the cultural identity of most English-speakers in Wales.

Do you understand what "protecting the culturage identity" means? From your comment, it looks like you didn't manage to connect the dots.

> If a social media needs a tutorial for people to be able to sign up or use it, it has already failed.

You mean like this?

https://help.twitter.com/en/resources/twitter-guide

https://help.instagram.com/454502981253053

> The media love twitter though. They hate it so much they can't stop talking about it

It's newsworthy. It's a leading social network which a billionaire was forced to purchase after trying to weasel himself out of the deal which he got into for dubious reasons, and now said billionaire is doing a corporate anihialation speedrun that threatens to evaporate 45 billion dollars.

Not to mention the impact on other notorious companies such as Tesla and SpaceX.

You require a massively disingenuous take on current events to come up to the conclusion that news coverage of Elon Musk's takeover of Twitter can only be explained in terms of irrational hate.

> The calls for advertiser boycotts started as soon as the takeover was announced (...)

You're casually glancing over Elon Musk's reiterated announcements that he would eliminate Twitter's moderation, and you're completely ignoring marketing execs stating publicly and in no uncertain terms that Elon Musk's decision and actions were a liability in terms of "brand safety/suitability".

https://twitter.com/LouPas/status/1588599808587345921

> I think Germans are more upset about how messy these things are than about the safety aspect. People just leave them wherever and occasionally some bored people do silly things with them like creating a huge pile of them or tossing them in canals, etc.

It's high time these so-called micro-mobility companies are held accountable for the abusive occupation of public space. Their business model is based on their ability to just go to a public area and dump a bunch of equipment on the ground. Street vendors are persecuted by municipal police for less eggregious occupations of public areas.

If locals have to pay for licenses to briefly occupy a couple of square meters of public areas to be able to do construction/renovation work, why are these companies allowed to throw around dozens of scooters at will?

> 1) tfs: shelves are named and can be worked with independently; git: stashes (...)

I don't think your comparison makes sense. Git stash is a way to quickly get to a clean local workspace that can be reversed as you see fit. You use local branches to track independent work.

> tfs: can't commit unresolved merge conflicts; git: commits just fine

Again, this doesn't make sense. In git, users determine whether a conflict is resolved or not. If you commit a changeset originating from a merge conflict, you have to explicitly state that the conflict was resolved and your changes are good.

> Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.

Honestly I didn't understood what point you tried to make. Merge conflicts happen because multiple sources of change touch the same document region in a way that can't be resolved automatically, thus needing human intervention. To the best of my knowledge, there is no cvs in the world that eliminates merge conflicts.

Regarding Git's support for feature branches, the fact that you don't understand the big win Git brought to the world with it's branching model is already a testament to how groundbreaking Git was at the time, and how everyone around was quick to roll out Git clones that follow the same approach. To see what I mean, spend a day working with a SVN repository trying to do work involving feature branches.

> git: if something happens to the branch label, the commits are gone.

Aren't you actually saying that if you delete a branch then the branch is deleted?

> Maths, science.

But those are already taught as the central subjects, aren't they? They are far from being ignored or neglected.

Again, which subjects should be prioritized offer cultural identity?

> Recent versions of git has started introducing commands with a more top-down design (e.g. git switch), but that's a very novel development

Isn't git switch syntactic sugar for git checkout? What's wrong with checking out a branch?

> In a nutshell, git has an unintuitive and unfriendly CLI with bad defaults.

I see this claim often, but it never is accompanied by evidence or any concrete example.

I've been using Git for years and I never noticed any semblance of unintuitiveness or bad defaults. Everything in the happy path is straight-forward, and all obscure things are a quick googling away.

Do you actually have any concrete example to back your claims? What's the absolute best example you can come up with of said unintuitiveness and unfriendliness?

> Making it compulsory up to the age of 16, to the detriment of other subjects (...)

Which subject do you believe should have a higher priority than defending the cultural identity of a nation?

> It's just a simple web app. How many people can it really take to run the thing?

Except it isn't? Content filtering and ranking based on properties such as individual preferences and localized content is way harder than dumping a SELECT * FROM tweets, not to mention compliance requirements.

> I still haven't seen evidence that he's a genius.

There's a wealth of evidence to make a case for the opposite, though.