TechNom (nobody) @ technom @programming.dev

Posts

0

Comments

160

Joined

2 yr. ago

They aren't talking about using recursion instead of loops. They are talking about the map method for iterators. For each element yielded by the iterator, map applies a specified function/closure and collects the results in a new iterator (usually a list). This is a functional programming pattern that's common in many languages including Python and Rust.

This pattern has no risk of stack overflow since each invocation of the function is completed before the next invocation. The construct does expand to some sort of loop during execution. The only possible overhead is a single function call within the loop (whereas you could have written it as the loop body). However, that won't be a problem if the compiler can inline the function.

The fact that this is functional programming creates additional avenues to optimize the program. For example, a chain of maps (or other iterator adaptors) can be intelligently combined into a single loop. In practice, this pattern is as fast as hand written loops.

I don't think that this is a hard rule. They probably look for the same signs that we do - plausible sounding utter gibberish. They just don't want the drop in quality due to that. If an author creates content with AI, but takes their time to edit and improve it, I think that the Gentoo team may give it a pass.

This is a problem with how Haskell is packaged for Arch.

People favor Arch Linux for configurability, not lack of bloat. With the level of configurability that Arch offers, any DE can look bloated. On the other hand, if you are a new Linux user or someone who just wants to use the computer without so much personalization, anything Linux offers is lightweight enough. Even a decade old system has enough hardware to handle modern Linux distros effortlessly. This is probably what a regular user wants anyway.

For anyone looking to learn git, the official book and site are thorough and exceptional. You can even download the eBook for free. While there's no harm in using other sources to learn git, don't use them as an alternative to the canonical source.

Uuuh, am I no true Scotsman?

That's a terrible and disingenuous take. I'm saying that you won't understand why it's useful till you've used it. Spinning that as no true Scotsman fallacy is just indicative of that ignorance.

You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools.

And you keep repeating that falsehood. Isn't that the real no true Scotsman fallacy? How do you even pretend to know that nobody needs it? You can't talk for everyone else. Those who use it find it useful in several other ways that I and others have explained. You can't just judge it away from your position of ignorance.

People are quick to judge without considering the circumstances. Wasn't the customer's attitude equally wrong? Aren't you implying that the service person should have let her bully him?

Only users who don't know rebasing and the advantages of a crafted history make statements like this. There are several projects that depend on clean commit history. You need it for conventional commit tools (like commitzen), pre-commit hook tools, git blame, git bisect, etc.

You can have both. I'll get to that later. But first, let me explain why edited history is useful.

Unedited histories are very chaotic and often contains errors, commits with partial features, abandoned code, reverted code, out-of-sequence code, etc. These are useful in preserving the actual progress of your own thought. But such histories are a nightmare to review. Commits should be complete (a single commit contains a full feature) and in proper order. If you're a reviewer, you also wouldn't want to waste time reviewing someone else's mistakes, experiments, reverted code, etc. Self-complete commits also have another advantage - users can choose to omit an entire feature by omitting a commit.

Now the part about having both - the unedited and carefully crafted history. Rebasing doesn't erase the original branch. You can preserve it by creating a new branch. Or, you can recover it from reflog. I use it to preserve the original development history. Then I submit the edited/crafted history/branch upstream.

I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It's good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don't know how to edit them.

Because their name is Elon Musk.

Leap years are not as bad as timezones, if you think about it. Timezones try to imperfectly solve a local problem - how to match your clock with the position of the sun. Leap years try to reasonably solve a global problem - how to keep your calendar aligned with the seasons.

I wonder if these trillion dollar companies offer support contracts for astroturfing on social media on their behalf. I can't think of any other way so many people are supporting their sociopathic attitude.

The devs don't take an issue with the ticket being filed. They're irritated by one particular reply which sounds like "My million dollar product depends on this bug fix. Please do that for me". MS isn't offering a solution. They're asking for one.

To be fair MS offers an amount for the fix. Most companies just bully the devs instead. However, I don't think it's quite fair (though legal) to offer one time payments for a core library that they use.

Those same companies tell you that their products that you paid for don't belong to you. You are just buying a license to use them. Sadly, this asinine concept is spreading even to hardware markets.

I think it's fair to ask them to take their own bitter pill. They should also invest without owning.

The hack is still not fully understood and is being analyzed. It doesn't help that Github suspended everything, including the original maintainer's account (who is believed to be a victim of social engineering).

Anyway, you will eventually see a post mortem. I'm willing to bet that it's going to be as phenomenal as the hack itself. The case and its investigation is going to be a classic case study for all security researchers and security-minded users. Anyway, I doubt that the attackers will ever be found. Jia Tan, Jigar Kumar and others are going to remain as ghosts like Satoshi Nakamoto.

They really ought to have version masking like in Gentoo portage.

You don't have any evidence, much less anecdotal evidence. Things don't become true just because you insist.

So you're just spouting some cooked up theory. Not a practical scenario.

If that's so trivial to trigger, people would be doing so everywhere. Have you seen it in the wild or heard of anyone doing so?