grumpyprole

There was once a time when nobody used C++ in production.

The "killer app" of K is KDB.

Fedora and Debian (stable) are not really directly comparable, they have different goals. Fedora is essentially a beta channel for RedHat, equivalent to Debian Unstable/testing. Fedora will ship a more up-to-date desktop, but Debian will be better for servers and/or users who don't need the latest Gnome.

I had always assumed it was because they had exposed far too many internals over the years, making a JIT that was backwards compatible with the majority of existing code, an extremely difficult undertaking.

> As we all know, because these widely-used compilers treat TCO as an optimization, C programmers have become problematically insistent on using tail recursion instead of loops.

I think you are misunderstanding. To put it another way: because, in C, the optimisation is not guaranteed, recursion is rarely used in practice. This is a shame as many problems do have a recursive structure and are best solved using recursion. It's probably the best decision for C, but not for a high-level language.

My work laptop, a Lenovo X1 running Windows 10, was completely busted out of the box. Sleep doesn't work, massive throttling issues running zoom (only improved a bit with firmware updates), WSL 100% CPU bugs, display port MST bugs, the list goes on and on. IT say all my issues are normal and known. About five years ago, I had a Linux Laptop for work, that was rock solid and I miss it very much.

Yes, but they've made the convenient lightweight syntax not bounds check. Defaults matter in languages. Other languages make you use an esoteric function e.g at_unsafe to skip bounds checking.

OCaml 5 essentially has it, as "effect handlers". It's how lightweight concurrency is implementated.

Whether or not one thinks C++ is a "good" language, I always thought that (original) Minecraft busted the myth that blockbuster games had to be written in C++.

I had a power button fail on an S21, only a few places were willing to quote and the cost to replace was over £300, more than the phone was worth. I now use the always on screen, so I can unlock without the power button, hopefully prolonging it's life!

As if the colour mattered at all! The phones are so slippery and fragile, one is pretty much forced to wrap them permanently in a case.

8088 did not have a barrel shifter, so multi-bit shifts would have been expensive and non-interruptible over multiple clocks. Perhaps game devs just avoided them out of habit.

> I believe that your interpretation of what’s actually happening is what’s baloney.

I'm actually quoting Prof Andrew Appel of Princeton: https://www.cs.princeton.edu/~appel/papers/ssafun.pdf

You seem to think that functional programming and in-place updates are mutually exclusive. This is not the case, e.g. Haskell supports mutation as a tracked and controlled side-effect. It can even give static guarantees that a function is pure even it uses mutation internally. Recent research even suggests that compilers can add the in-place updates for us: https://www.microsoft.com/en-us/research/publication/fp2-ful...

Functional programming is basically maths, it solves the problem of how to compose software safely. I struggle to understand why anyone who really cares about their craft would not want this. In fact, many want it so badly they are willing to make sacrifices for it (performance, esoteric languages).

There's nothing baloney about SSA form. I'm sorry to say it, but C is just not close to the metal any more. Even if you are able to hand optimise something so it works well on one architecture, it likely won't be optimal for another.

As for Haskell, it does pretty well being 100 times faster than Python with 100 times less the number of people working on it.

This is like saying "the benefits of functional programming are overstated". If you are happy with mutable collections, you've happy with mutable variables, pervasive side effects and essentially the status quo. Many of us are not happy with the level of software quality out there and the status quo, Rich Hickey included.

We should build compilers that insert these checks for us (if they cannot statically determine them unnecessary). The ability to omit these checks doesn't IMHO justify undefined behaviour.

It's painful for the compiler too, it has to turn the parents imperative code into SSA (essentially A-normal form) so it can optimise it!

I'm sorry I still don't buy it. Can you please show me a use case where ignoring null pointer or overflow checks makes your product non-viable or uncompetitive?

Some of these checks could be removed by languages with better compilers and likely more restrictions. That is the better approach. As a user, I don't want to run code that is potentially unsafe and/or insecure.

This is of course a popular opinion and pretty much the C++ philosophy. Unfortunately a lot of the benefits of functional programming cannot be fully realised unless you are "all in". The paper "The Curse of the Excluded Middle" is somewhat blunt but it makes some good points: https://queue.acm.org/detail.cfm?id=2611829

Well done to the author on this project. A beautiful architecture and code base with not an "object" in sight. Projects such as this demonstrate how complex interactive applications can be built without pervasive mutable state. Pure functions are everywhere, which makes it much easier to reason about, test and reuse this code

Well investors tend to care more about future growth potential than past performance. History tells us that the outlook for expensive proprietary platforms is usually not so good.

I do. But Apple has a problem if their position is the same as yours.

Nice if you can afford it! With Apple's current prices, most of us don't have that luxury.

I don't disagree that Java has cruft, but Go didn't fix data races, nulls or lack of sum types. It's not a "fun" language for me.

I do wonder whether these apps are using any of the hardware acceleration available in our hardware. These days PCs are second class to mobile phones.

> They're old and obsolete

Just like that iPad will be in a couple of years.

Spot on. An iPad won't last long enough to become some omes beloved object.

Yep, or C doesn't need arrays just use pointers! And C doesn't need strings, just use a pointer to the first byte and assume it's ASCII!

Unlike the PC industry, Apple is/was able to move their entire ecosystem to a completely different architecture, essentially one developed exactly for low power use. Windows on ARM efforts will for the foreseeable future be plagued by application support and driver support. It's a great shame, as Intel hardware is no longer competitive for mobile devices.