Yes, the belief that markets self regulate, was proved incorrect by the 2008 financial crisis.

Not always. There's no Minecraft for Mac, they even prohibited Macs running the iPad version. It's essentially been ported to Apples APIs but purposely withheld from macOS.

I'm talking about enterprise software, not games. Minecraft exists for Mac, grab the Java version.

Anyone on Bedrock Minecraft is probably there for the cross-platform multiplayer. The Java version doesn't substitute for that. (MS made Bedrock and Java incompatible so they can rent-seek on closed mod and server-hosting "marketplaces"; can't let people share things and have fun without paying a middleman after all, think of the wasted "productivity"!)

Yes, it will also have 5 mins of battery life when unplugged and have a power adapter the size of a shoe box. I tried a similar machine from Lenovo at work and quickly returned it.

My laptop is always either plugged into a dock at work, or plugged into a dock or just a power supply at home. I feel like there's an untapped market for 'same laptop, but slightly cheaper because there's no battery in it at all'.

Like you say most windows laptops have such garbage battery life already that it's not practical to use them unplugged.

> 'same laptop, but slightly cheaper because there's no battery in it at all'

So, a simple computer? You can even choose your keyboard, mouse and screens.

Not the same - I still want to be able to just use and carry round the one thing without needing a monitor, mouse, keyboard etc at every single location, but I basically never need to use it somewhere where there isn't a wall socket available.

When I bought a Thinkpad a few months ago there was an option to order it with a smaller battery (which I selected).

It seems ridiculous on the surface, since you'd think you'd just buy a desktop or something, but with a laptop with no battery, and hypothetically better everything else, it would eliminate the need for a bunch of other peripherals

Ah but then you'd need to hard shut down to carry it home. The battery should keep the ram active to commute while sleeping

Kind of an interesting idea. Only the portability but none of the mobile computing capability.

It does kind of seem like, outside a few select models, the PC market just gets the laptop part of laptops so so wrong. Bad touchpads, bad screens, no battery life, unpleasant industrial design usually, crammed with crapware and other bullshit. I hand it to the few companies that do try harder to remedy these.

Eh, I want some battery, it's nice when you need to move rooms or someone kicks the power cable out. Even 15 minutes would be enough for a chonkster machine like this.

I wonder if a big capacitor would be cheaper than a battery, probably not with how huge in scale battery production is at this point.

The early hybrid car of computers

The thing is, I think there's probably a niche for a workstation laptop like that, but this doesn't really check the right boxes.

For all that extra bulk it ought to be extremely robust and repairable, have the best specs possible, and be equipped with the kind of killer cooling system that a thin chassis can't deliver. Then the tradeoffs might make sense.

That's absolutely insane.

The Dell part or the windows preference part?

Both :)

Does this really test Claude in a useful way? Is building a highly derivative programming language a useful use case? Claude has probably indexed all existing implementations of imperative dynamic languages and is basically spewing slop based on that vibe. Rather than super flexible, super unsafe languages, we need languages with guardrails, restrictions and expressive types, now more than ever. Maybe LLMs could help with that? I'm not sure, it would certainly need guidance from a human expert at every step.

Most languages have poor support for structural types though. If you try and join two records together (like a SQL join), what will your favourite language infer then?

C# has anonymous types which is pretty much the same thing. Though I prefer to declare actual types for most usecases, I'll only use anonymous types for intermediate results and such.

I certainly don't mean to knock nominal types. But I think structural types are more fundamental. A language would only need a single "newtype" or "nominal" keyword to create nominal types from structural types.

Why structural is more fundamental?

C#'s anonymous type shares some flexibility of structural type system even though it still a nominal type.

  > A language would only need a single "newtype" or "nominal" keyword to create nominal types from structural types.

I think you also can add `structural` keyword & apply structural type system in generally nominal type system as well if we're talking about adding feature.

Claude is "very good" in applying >var< continuously :-D

What you are describing is structural types. It is indeed a mystery that these are so under used, especially as they are a cornerstone of type theory. Structural types are so useful that they creep into most languages in some way. Even in Java, the Kingdom of the Nouns, where the rulers refused to merge a pair class, functions essentially take tuple arguments and these tuples don't have to be named and defined. You can't return a tuple though, so there is an unfortunate asymmetry. In Haskell and OCaml, we like to describe functions in a structural way, so com.google.android.Predicate would be just "a -> Bool". You wouldn't have to convert your com.google.guava.Predicate. But even these languages lack structural records and variants and suffer for it.

By now I'm also convinced that structural typing is a better default. Nominal types are still useful to assign properties that are hard or impossible to encode with structure alone (e.g. string that is a valid email address) . But I haven't encountered any other examples yet, where I'm missing nominal types.

OCaml has structural variants in the form of polymorphic variants. On the product side, OCaml has objects, first-class modules, labelled tuples (since OCaml 5.4) which are all a form of structural records, with different trade-off in term of ergonomics.

It's overblown until it isn't. Hoare didn't pluck that number from thin air. This is now a solved problem in modern programming languages. If Odin doesn't have this and other essential memory safety features, it's certainly not worth the massive retooling effort.

But that's not really what I mean. What I am trying to say is that "solving" the problem doesn't really fully solve it after all.

Yes it's the burden of proof. That's why writing Rust is harder than C++. Or why Python is easier than anything else. As a user and customer, I'd rather pay more for reliable software though.

The JVM famously boxes everything though, probably because it was originally designed to run a dynamic language. An array list of floats is an array list of pointers. This created an entire cottage industry of alternative collections libraries with concrete array list implementations.

A float[] is packed and not a list of pointers in the jvm.

An ArrayList<Float> is a list of pointers though.

Arrays have a static fixed size though, making them far less useful in practice. Anything one builds with generics is boxed. Dotnet doesn't have this problem.

Currently you can get around this with Panama, even if the API is kind of verbose for the purpose.

Eventually value classes might close the gap, finally available as EA.

Valhalla is over 10 years in the works already and there is still no clear date when or if at all it would be released. It's very difficult to change (or fix) such fundamental things so late in the game.

Because it is a huge engineering effort to add value types without breaking existing binary libraries.

Doing a Python 3 would mean no one wanted going to adopt it.

Yes it is long process.

Some of the JEP in the last versions are the initial baby steps for integration.

They're famously working on changing that. I think we're all hopeful that we'll start seeing the changes from Valhalla roll in post-25.