TechNom (nobody)

I wish there was something more interesting to do there.

You are not expected to remember a v6 address - or even v4 for that matter. They are designed for machines. DNS is designed for humans.

What do you do on the yggdrasil network?

Python decided to use a single convention (semantic whitespace) instead of two separate ones for machine decodeable scoping and manual/visual scoping. That’s part of Python’s design principle. The program should behave exactly like what people expect it to (without strenuous reasoning exercises).

But some people treat it as the original sin. Not surprised though. I’ve seen developers and engineers nurture weird irrational hatred towards all sorts of conventions. It’s like a phobia.

Similar views about yaml. It may not be the most elegant - it had to be the superset of JSON, after all. But Yaml is a semi-configuration language while JSON is a pure serialization language. Try writing a kubernetes manifest or a compose file in pure JSON without whitespace alignment or comments (which pure JSON doesn’t support anyway). Let’s see how pleasant you find it.

I think assembly was easier back then. Some architectures still are. But many architectures like x86 got incredibly complicated.

I looked at the post again and they do talk about recursion for looping (my other reply talks about map over an iterator). Languages that use recursion for looping (like scheme) use an optimization trick called ‘Tail Call Optimization’ (TCO). The idea is that if the last operation in a function is a recursive call (call to itself), you can skip all the complexities of a regular function call - like pushing variables to the stack and creating a new stack frame. This way, recursion becomes as performant as iteration and avoids problems like stack overflow.

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.

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.

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?

This is definitely into the territory of misinformation.

I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in

I already addressed this before. Regular crashes are almost always (I can’t remember any exceptions) due to panics or aborts chosen by the user - especially due to unwraps. Using that to equate Rust programs’ stability to ‘any other compiled language tools I use are written in’ is very disingenuous - because it’s just as easy to handle those errors and prevent a crash at all.

If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust

You are unnecessarily conflating issues here. ‘Most modern languages’ are not a replacement for what C, C++ and Rust can do. Go most famously had to retract their ‘systems programming language’ tag, for example. If a GC language meets your requirements - then by all means, use it. But it’s not without reason that many companies have rewritten even their web backends in Rust. Memory safety without GC is a very big feature that a lot of professionals care about. It’s not something to dismiss as trivial.

And while at it, you neglecting what segfaults represent. It’s just a benign example of memory safety bug. It’s benign because it gets caught causes the program to crash. There are a whole lot of them that causes the program to continue running - causing serious vulnerabilities. This is why even the US government and agencies recommend memory safety languages and especially Rust if performance and other limitations matter.

If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.

I really don’t want to repeat the reason twice in a single comment and 3 times including in my previous comment. But the only way you are going to make Rust crash as much as ‘any other prolang’ is to neglect idiomatic Rust. That isn’t surprising because crashing anything is possible if that’s your intention.

You said bugs caused by ‘memory problems’. And that Rust programmers vastly overestimate them. Those aren’t generic logical bugs that you get in Go or Java. And Rust never claimed to solve logical bugs.

I don’t know if you’re talking about panics and abort or about crashes caused by memory safety errors. The latter class is very unlikely in safe rust, other than as rare compiler bugs. Panics and aborts are your call. You can easily write code that doesn’t panic or abort.