teo_zero

> Why bother going to all this effort for an internal combustion engine (crossbow)?

Because it sells well? Because it's what a significant portion of people want?

> Its pretty obvious where the future is headed for personal vehicles

"Where", yes. "When" is a big question mark. If the transition will take several years to complete, which many bet it will, it makes perfectly sense to offer a car that people is willing to buy in the meanwhile.

The Chinese brands that you mention also offer hybrids: indeed most BYDs I see in the streets have the "DMi" tag, which is BYD's codename for hybrid. And they are investing in fuel engines, too. Only short-sighted euro burocrats think that since EV are the future we should immediately stop selling and innovating fuel cars.

> it isn't recognised at all as hybrid vehicle in Germany

You surely mean that it is not recognized as plug-in hybrid vehicle.

Could you please elaborate what is crossbow and what is machine guns in your metaphor?

I imagine adding this feature has cost many hours of development. Aren't there lower-hanging fruits to please Excel's users? What about allowing user-defined shortcuts? E.g. to edit a cell it's still either the mouse or F2, neither of which is comfortable on modern laptops.

> Why use a for loop with a bound as an example instead of while loops with linked lists?

I'm the author of the example. I wanted to keep it as simple as possible, and this is the most common form of for loop. I was sure that HN readers would be clever enough to "map" it to whatever they have in their mind that satisfy the undecidability of the condition.

But since you're nitpicking, I haven't specified the types of i and n: i is uint8_t and n is uint32_t. Does it terminate? It depends on the value of n!

Whenever you write a succinct example or a metaphor to try to explain in a few words a complicated concept, someone will nitpick small details of your construction, thus focusing on the form and missing the spirit!

Forget if "i<n" is decidable or not: the sense is that there will always be some loops that the compiler can't determine if it's finite or not.

Forget if A and B can alias or not: the sense is having two independent actions that can be executed in the same loop or in two consecutive loops.

Let's see... what about the following example, that replaces all a's with @ and all e's with & in a zero-terminated string s?

  for (char *p=s; *p; p++)
    if (*p=='a')
      *p='@';
  for (char *p=s; *p; p++)
    if (*p=='e')
      *p='&';

If a compiler is allowed to assume that the first loop terminates, then it may optimize it to:

  for (char *p=s; *p; p++) {
    if (*p=='a')
      *p='@';
    if (*p=='e')
      *p='&';
  }

Is this explanation less insane?

> I'm not sure what this has to do with my comment

Because you explicitly mentioned details that belong in the implementation, not in the semantic:

> A halt/abort instruction that trashes [the] state would be undesirable

If you want to attach a debugger, then use a breakpoint, don't try to obtain the same effect within the code.

Take this example:

  for (i=0;i<n;i++)
    A[i]=0;
  for (i=0;i<n;i++)
    B[i]=0;

It can be conveniently transformed into this:

  for (i=0;i<n;i++)
    A[i]=B[i]=0;

They are exactly equivalent except if the first loop never terminates.

Now, the compiler could try to understand if the first loop does or doesn't terminate, and apply or not the optimization accordingly, but Turing tought us that is indeed a hard task!

Or it could decide to never apply it, for fear of those rare and usually pathological cases where the first loop doesn't terminate.

Or it could decide to apply it by default and accept that in those cases the program does something different than what the source code says. The latter is better known as UB.

The third option won, and that's why infinite loops are UB in the standard.

Expecting a piece of code to be compiled to a precise sequence of machine instructions is exactly what you should not do with high-level languages like C++. Their task is exactly to abstract the machine away. They give you the guarantee that the final observable result will be what you asked for, not that the means to obtain that result will be what you have in mind.

If you write a loop to zero out some memory, it can be compiled to a loop, or to a call to an optimized predefined function, or even to a sequence of single zeroing instructions, if the size is small enough.

Even a single statement as a=0 may be compiled to a "load immediate" instruction, or an "XOR with itself", or a "sub with itself", or a move from another register known to be 0.

> How about case-insensitive filesystems? [...] Negligible.

I don't buy this. Finding collisions is pretty easy. In one repository I have these files:

  rank2.cpp
  rank4.cpp
  rankN.cpp

The last two have the same case-insensitive Base84 encoding:

  mz{QkARW;1cB
  mz{QkaRW;1cB

> I really like this website design

Reading it on my phone, I beg to differ.

Doesn't pressing "back" in the browser repost the same message?

How do you decide who is going to pull the tokens?

And how do you decide who is going to throw that one die?

> this is just structs.

Yes. And structs are just bytes. Levels of abstractions don't do anything the underlying levels don't already do, they just give you means to express your intent in a clearer form.

But there are "cubic bazillions" of possible URLs that are being requested. Even if they boil down to "only" some millions actual commits, their rendered HTMLs are all different.

Tangent question: what about NPU performance? I always read about CPU vs GPU, but nobody talks about NPUs; I don't even know if llama supports them.

Why do phones and laptops get equipped with NPUs if there's no use for them?

This is for iPhones only. Do I assume correctly that the issue is solved for Android, instead?

> count undo as a partial game over

Not at all. Contrary to other games where undos are cheating, here they are part of the game. Without them it would be 80% luck and only 20% strategy.

> which is heavily implied

I can't find anything that implies this. It explicitly says:

> This uses undos deliberately rather than only as an emergency

while avoiding undos is mentioned at the end as "The Purist approach", which I read as slightly mocking.

I see it like a chess problem where you have to find the best sequence of moves, so you start off with an intial move, then backtrack, explore another idea, etc. Not like a chess match where of course you cannot undo any move.

If your first word is four greens it's actually pretty good: you get to know four letters to avoid with just one undo!

You might have misunderstood TFA. No push for trig reform, just a consideration on what internal representation is optimal in code.

Imagine it like someone suggesting (understandably) that you express memory sizes in hex: no push to make everybody stop using decimal numbers!

The C standard defines the functions sinpi(), cospi(), etc. that act on half-turns. If you have a modern compiler, all you have to do is to include math.h

Sure, it's your choice where to put your precious time. Exactly like Sheldon, you prefer not to dedicate any energy to question a judgment you have decided a priori. And like him, you might be missing out on some good stuff.

While you went this road of the medical metaphor, taking antibiotics at the first suspect of sickness without checking what's really going on, is a sure way to help develop antibiotic-resistant viruses.

Please note the key item is without checking. I'm not denying that many AI-generated documents are likely to be garbage. But refusing to read them just because of it will result in a lot of throwing the baby out with the bathwater.

Whenever I'm tempted to base my judgment on how something's been created rather than what the end result is, I think about the scene where Sheldon throws away the french toast Penny made for him, despite smelling good, just because "Monday is oatmeal day."

Even worse: cover letters, presentation letters, even CVs themselves are routinely read by AI, at least in the screening phase.

> using AI as an editor vs letting it write a whole essay for you. AI;DR is about the latter

I'm sure that's the intention, but the alarming trend, at least here on HN, is crying wolf at the first em-dash.

> the difference in positions is "this could be made better" vs. "but this is already so much better than before"

I would say "this could be technically better" vs. "this is already economically better than anything else"

> As for 3 instructions for array access, in a simple loop a compiler can convert index access to pointer increment.

In such a simple loop where you access one field in each iteration, yes. If you happen to access more fields, or the same field in different arrays, then you have more pointers to increment.

I can't help wondering why so many new languages provide two separate mechanisms to define mutable and immutable variables.

I see a value in defaulting to immutable unless explicitly stated, like in Rust. But having to choose between two different 3-letter words, like let and var, what stops one from always using var?

Coming to Jaithon in particular, I also wonder what the scope of immutability is, when it allows the following:

  let names:list[str]=[]
  names.push("whatever")

If a function takes a list[str] as input, how do I signal that it does or does not modify the list? And if it does, will it only shuffle the elements (e.g. sort) or will it also change the strings themselves (e.g. uppercase all elements)?

Const-ness is a complex topic, with more cases than can be captured by two keywords at variable definition.