grumpyprole

And to read rumour sites about the next model.

VSCode is pretty much this. But with typescript instead of Guile. After 30 years of Emacs, I switched .

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.

Both :)

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.

That's absolutely insane.

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.

> The big thing is that if you have a bare string, you don't know "where it's been". It doesn't carry with it information whether it's already been validated.

> For full-on parse-don't-validate, you essentially need a dependent type system

This is really misleading. You are missing abstract types in your arguments. If the only way to construct the newtype is a via a parser (smart construction) because the type constructor is not exported, then the newtype does carry the information that the string has been validated.

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.

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?

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.

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.

Less of the personal attacks please, you know nothing about me. I actually think it is you that is missing context here. Don Syme personally visited and presented at a variety of investment banks. He was the creator not a marketing type. I was present at one of his pitches and met him. One bank, Credit Suisse ended up adopting it. Any comparisons he made to C# where based around readability and time to market (C# is very verbose and boilerplate heavy compared to both Python and F#). This was all on the 2010-2015 timeframe. Python ended up winning in these markets. My point has always been that this now puts it in a difficult position, it's simply not radical enough to disrupt but still carries the perceived "functional programming" barrier to entry.

F# was pitched by Microsoft to be used in areas where Python dominates, especially for scripting in the finance domain and "rapid application development". So it doesn't make sense at all that C# and Java are a "better comparison".

Haskell. But there are other examples of "pure functional programming". And the state of the art is dependently typed languages, which are essentially theorem provers but can be used to extract working code.

It absolutely does make sense to compare it to the worlds most popular programming language, especially when dismissed as "functional programming". Who benefits from an OCaml comparison? You think F# should be marketed to OCaml users who might want to try dotnet? That's a pretty small market.

Both OCaml and Clojure are principled and well designed languages, but they are mostly evolutions of Lisp and ML from the 70s. That's not where functional programming is today. Both encourage a functional style, which is good. And maybe that's your definition of a "functional language". But I think that definition will get increasingly less useful over time.

I'd much rather code F# than Python, it's more principled, at least at the small scale. But F# is in many ways closer to modern mainstream languages than a modern pure functional language. There's nothing scary about it. You can write F# mostly like Python if you want, i.e. pervasive mutation and side effects, if that's your thing.

It all depends on the lens one chooses to view them. None of them are really "functional programming" in the truly modern sense, even F#. As more and more mainstream languages get pattern matching and algebraic data types (such as Python), feature lambdas and immutable values, then these languages converge. However, you don't really get the promises of functional programming such as guaranteed correct composition and easier reasoning/analysis, for that one needs at least purity and perhaps even totality. That carries the burden of proof, which means things get harder and perhaps too hard for some (e.g. the parent poster).

F# is hardly modern functional programming. It's more like a better python with types. And that's much more ergonomic than C#.

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.

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.

> C# is, imo, the best cross platform GC language. I really can't think of anything that comes close

How about F#? Isn't F# mostly C# with better ergonomics?

In hindsight, I think your description is indeed better!

No it's not pleasant at all. It's boilerplate heavy, non-local and indirect. It's presumably a large part of why pattern matching is arriving in Python.

True, but then concurrency via algebraic effects makes it look more modern than Rust.

The vast majority of which unfortunately still come with Intel processors, especially the premium models. I handed my work issued Lenovo X1 back to my employer as being unusable due to overheating and excessive thermal throttling. The M4 Macbook Pro I now have is such a huge positive difference, I have adjusted to macOS and enjoy Intel outside.

Sure it did ok with examples that are easily found in a text book like drawing a circle.