Just one more turn before my family can send and receive phone calls on the landline.

Well. You’d have to demonstrate that a[1] is the first offset in an array, and it’s not a great curb appeal to anyone who has programmed computers before.

I don’t see a problem. That’s how people count.

It makes sense when you look at how the numberic for loop looks in Lua.

In Lua you specify the “beginning” and “end” of the iteration, both included. It doesn’t work like in C, where you have an initialization and an invariant. What makes it short in C would make it longer in Lua, and viceversa.

You could argue “why not make loops like C”, then. But that can be extended to the limit: “why have a different language at all?”.

i think i might prefer indexing starting at zero, but it really isn't important. with c it makes total sense for zero-based indexing. frankly though, for lua, how it works and what an array is, it makes more sense for one-based indexing, the only counter-argument being that 1-based indexing puts off people who learned a thing one way and are unable or unwilling to do it a different way. to even include it on a list of considerations for not choosing lua is a bit silly, but to highlight array indexing and only that as the only thing you'd need to know... well i don't know how to put it that wouldn't be impolite.

either way, at least you can't toggle between indexes starting at zero and one, (at least not that i can recall.)

> either way, at least you can't toggle between indexes starting at zero and one

You can, you just have to explicitly assign something to a[0]. Lua doesn't have real arrays, just tables. You have to do it for every table you use/define though, so if you mean "toggle" as in change the default behavior everywhere then I believe you are correct.

iirc that value at key zero won't be included in any array handling functions. if that behavior were toggleable we'd have the kind of nonesense that early APLs allowed before they realized that's a bad thing to stuff in a global variable you can write to at any time in your program.

You implemented type-checking. For a project this ambitious, I am surprised here.

“Generics” should mean that the compiler or interpreter will generate new code paths for a function or structure based on usage in the calling code.

If I call tragmorgify(int), tragmorgify(float), or tragmorgify(CustomNumberType), the expectation is that tragmorgify(T: IsANumber) tragmorgifies things that are number-like in the same way.

For a compiled language this usually means monomorphization, or generating a function for each occurring tuple of args types. For an interpreted language it usually means duck-typing.

This is not a bad language feature per se, but also not what engineers want from generics. I would never write code like your example. The pattern of explicit type-checking itself is a well-known codesmell.

There is not a good usecase for adding 2.0 to a float input but 1 to an integer input. That makes your function, which should advertise a contract about what it does, a liar ;)

There will be customers even though it is a useless feature tier.

Monetizing knowledge-work is nearly impossible if you want everyone to be rational about it. You gotta go for irrational customers like university and giant-org contracts, and that will happen here because of institutional inertia.

Fair. But there’s even an additional difference between snarky clickbait and “giving the exact opposite impression of the truth in a headline” ;)

I got a PIP because my manager mistakenly thought I was stealing equipment, and he just kept adding agile story points until I failed.

I was too pissed off to go to an ombudsman. It honestly didn’t occur to me. It just felt like “this guy hates me and wants me out.”

He called me two years after I was fired to inquire about missing equipment that I never had.

You made the mistake of allowing PIP to be invoked on you for a fake reason given by your manager, and you made the even more serious mistake of getting fired because you "stole equipment".

If you were innocent of that dangerous charge, you should have fought hard against it, and ensured the top management, HR head and Ombudsman became involved in the investigation.

Being fired for theft or such serious crimes, can and will leave a permanent black mark on your employment record with the HR, and it may get pulled up during BGV (Background Verification) invoked by a prospective employer evaluating your candidacy for hire, thus seriously affecting your career and life.

I think you should now reach out to that company HR and clear the conspiracy and black mark against you. Perhaps, you can hire a lawyer who deals with employment matters, so he or she can legally get the matter resolved in your favour.

Never thought of it this way; isn’t it always safe to assume env is in PATH?

Maybe `#! env <shell>` could be considered a DSL for hashbangs. My reasoning is that `/usr/bin/env` is the thing that seems to be hard-coded to a system path, in most cases.

Some environments (like containers) have no, or extremely incomplete PATHs.

I think POSIX requires env but doesn't mandate a location for it.

This has always been the hardest problem in computer science besides “Assume a lightweight J2EE distribution…”

This is annoying. It’s because errors were designed to be a bitset and not have pointers. I would also prefer that they were a `union(enum)`.

We are free to do that as a return type like `Result(T)` and just forgo using `try`, but yeah, I wish this was in there.

This is the most surprising comment to me. It’s that bad? I haven’t benchmarked it myself.

Zig has @Vector. This is a builtin, so it gets resolved at comptime. Is the problem with Rust here too much abstraction?

I think you misinterpreted GP; he's saying that with some hints (explicit chunking with a branch on the chunk size), the compiler's auto-vectorization can handle the rest, inferring SIMD instructions in a manner that's 'good enough'.