That was just an excuse by Valve. The reality was that they were unable to finish numerous HL attempts due to the shortcomings of their organisational structure and somewhat absent/aloof/fickle top management.

Maybe they’ve finally recognized and fixed the real problem. Maybe not. We will see in future performance.

While I am sure that may be part of it.

How they have built games recently seem to backup what they said.

Aperture Hand Lab and HL:Alex was VR and partially pushing the Index.

Aperture Desk Job I can’t remember the name of was for the Steam Deck.

The way they have released games seem to backup what they are saying.

HL: Alex happened because "upper management" (aka the people with the actual power in their amorphous organizational structure) was engaged, and wanted a major title in VR. Major titles do not happen otherwise; excitement by the troops only goes so far, because there will always be setbacks and grind.

I wish there was a new generation of HP-48, just with a faster core and better screen. :(

I have a SwissMicro DM-42, which when setup properly is similar to a HP-48, just minus graphing capabilities. Still want a HP-48 refresh.

I want to second all recommendations of SwissMicros. I own DM15L (~$150), DM41X (~$220), and DM42 (~$250), and they are all absolutely excellent specimens. Not a single complaint. They are easily user serviceable, they have a very high build quality and feel like they will last decades (matching modelfkeyboards dot com build quality). The DM42 has a user-enabled N-stack so you can input algebraic expressions of any arbitrary length. The DM15L is an advanced calculator you (or at least I) can grok completely end-to-end, and packs it all into a compact form; I actually prefer to grab the DM15L before the DM42. The DM41X is also an excellent specimen. It includes the ability to {,un}load module files which are dumps of the old HP-41CX module cartridges. I love every single one of them, and cannot shill (for free) SwissMicros enough. You've beheld Swiss watches, now behold a Swiss calculator!

Check my post history, I hate ads. This isn't an ad.

The hp-50g is pretty nice (I know I know, unpopular enter key location), its USB power and SD card make it quite convenient. Of course the screen is the same as before, but the CPU is faster afaik

And then of course there are many HP calculator emulators and others for android

The 50g screen has only slightly (131×80 vs 131×64) higher resolution than the 48G series, but it has vastly better contrast, and, thanks to improved fonts and other UI improvements, the built-in software on the 50g also makes significantly better use of the limited screen real estate.

N.B.: Meta Kernel[1] provides many of the 50g UI improvements on the 48GX — 49g/50g OS is based on Meta Kernel — but installing Meta Kernel in RAM requires a memory expansion card that, at current used prices, costs nearly as much as a used 50g (plus a steady [semi-yearly IIRC] supply of CR2016 coin cells to sustain the RAM card when the calculator is powered off).

While I also prefer the aesthetics and keyboard layout of the 48 series, the 50g with its bundled software suite stands as one of the most hacker-friendly handheld computing devices of all time: while documentation and development tools for the 48 series were widely available, it wasn't until the 49g that self-hosted versions of these tools (System RPL (de)?compiler, Saturn (dis)?assembler, library creation and extraction tools) were bundled with the base OS.

[1] https://www.hpcalc.org/details/213

I'm guessing that you have newRPL. Have you tried putting DB48/DB50n firmware on it? That does have graphics (and RPL). I haven't had time to get familiar with mine, so I can't comment further on capability.

I used to think the same as you about 1-based indexing in Lua... until I tried using Lua in a game engine. I was constantly getting hit in the face with problems (e.g. coordinate systems and off-by-one errors), even after spending far too much time trying to abstract around this mismatch to make these problems go away.

In theory I was okay with the indexing. In practice it was an absolute PITA.

Plus there were other numerous papercuts; it felt like Lua was actively fighting me every step of the way. I went from liking Lua to absolutely despising it.

In the end I switched to C++11, which amazingly was much more productive. As in night-and-day difference.

If that rather benign comment makes you almost throw up...

One thing I've learned watching politicians the past few decades is that laws are guidelines. If the political will exists, politicians will find a way.

I agree with the observations of the author. I have found MA much more engaging than any book I've crossed paths with. Going from a pile of math textbooks to MA was going from good intentions to good results; it's quite amazing how much I've relearned over the past few months. This is the future, as far as I am concerned, with only refinements needed.

Also: I too really hope they expand into physics.

How about some basic hash table support in the standard library first? I know this is snarky, but ISO's priorities over the past couple decades... :(

I would rather not:

- It involves making too many decisions on behalf of users. C++ dodges the question somewhat by making hash tables templated, so you can customize them.

- There are a hojillion hash table libraries out there which are written in C—just pick one and use it.

The latter point is a very strong argument for a hash table implementation in the standard library.

I don’t see how that argument follows.

If everyone is reinventing the same wheel, then...

Furthermore, those wheels aren't necessarily interoperable the way something built into the standard library would be; it's not just a convenience.

Yep. Basic hash table. Spec out all undefined behaviour. Standardize abi. Etc. so many things to do with c to actually make it useful instead of c++ lite

> Standardize abi

What's with this strange desire to mandate One True Way to implement function calls in every language implementation? If I want to use rbx/r11/r10/r9 for argument passing and return results in rdx/rsi by default and have to use

     @if os.LINUX and cpu.X64
     import external func[[regseq("rdi,rsi,rdx,rcx|rax"), library("libc.so")]] fwrite(buff ptr, size int64, count int64, stream ptr) int64;
     @endif

to interoperate with one particular implementation of libc for one particular OS on one particular ISA, then that should be perfectly fine.

That in no way conflicts with the existence of a standard. A standard is just a common default, you can deviate from it. And this being C the ability to do so when needed would be expected.

I get why people want those things but you can’t spec out undefined behavior and end up with a version of C that people want.

Not sure what “standardize ABI” is supposed to mean… each platform has its own ABI, and most of those ABIs are already standardized. The standards are just not part of the C standard.

How does the Datalog approach compare with RETE?

The big deal about Datalog is that it is equivalent to SQL-with-recursion. Thus, it can compile to database queries.

Wow. That second paragraph sounds like _blatant_ war propaganda.

Unless there’s plentiful evidence for the above (it’s possible one-off, I suppose), I think you’ve gone full fruit-loop territory.

I humbly suggest you look in the mirror and ask what’s actually going on in your head, and why. This sort of distorted extreme thinking is what creates monsters.