Pfff... it's like my teenage daughter who's never driven a car brags to her friends how Mazda is better than Toyota, because "she switched".
"Using Emacs" means actively reading, writing, evaluating Lisp code. How many packages have you written? If not too many, I'm afraid, you're only "riding it", not "using" it, just like my daughter has been riding in one car and now in a different one.
There's a huge fundamental gap between Emacs and VSCode. In Emacs, the editor is the Lisp runtime. Every piece of the editor is a live Lisp object you can inspect, redefine, and compose at runtime. There's no boundary between "editor" and "extension" - they're all just functions and variables in the same image. VSCode doesn't offer anything remotely close to that.
Without understanding that gap, there's no understanding of what Emacs actually is. There's no "switching" between Emacs and an editor/IDE. "IDE" is a much smaller category than what Emacs actually is. You switched editors while not realizing you gave up something that isn't an editor.
A bit harsh, but 100% on point. THIS is why emacs is fundamentally different to the core of what emacs is vs all other editors - you’re driving a Mazda, but you’re your own mechanics with that Toyota
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
