If you really cared about that, you wouldn't have picked Rust. Nim or Haskell are terser languages.
> Every language we’ve built defaults to sequential execution with parallelism bolted on.
False and misleading statement. Array languages have been around for a long time, but you didn't care to learn them.
> Formal verifiability. Move beyond type checking to compile-time proofs.
Good luck with your tokens budget for proof providing. LLMs won't solve that for you. If you believe that proofs are as simple as matching API calling inerfaces you're wrong.
> Declared effects. Every function explicitly states what it reads, writes, and depends on, machine-enforced.
Good functions are pure functions that have no effects. Good design tries to minimize the number of effects needed and maximize the footprint of pure functions mapped over inputs and outputs. If you insist that every function needs an explicit effect annotation, you don't know the topic and you haven't worked with effect systems much.
Just juggling with balls in the air gets boring very quickly, and the added numbers don't make it much different. Learning statics and flows from contact juggling, but performing them with standard juggling balls is so much more fun. And then you discover statics with hoops: https://www.youtube.com/watch?v=PF6UuPsw2i4
Re. "CAD/BIM", technically speaking CAD doesn't imply BIM, and the industry's promotion of BIM is akin to AI promotion among software engineering teams - the benefits aren't clear upon detailed review of the advertised capabilities. The CAD part, on the other hand, is generally recognized as the essential tooling for the profession and I'm surprised to hear that it just is a "wonderful aspiration".
"The profession" actually is a wide variety of trades, not just architects and contractors. Electricians, plumbers etc. where CAD is not yet widely spread.
Which hopefully will change in the near future, with open source BIM tool chains, boosted by generative/agentic AI.. Finally, a huge source of confusion and execution hiccups will be overcome.
Generalizing with "everything", "all", etc exclusive markers is exactly the kind of black/white divide you're arguing against. What happened to your nuanced reality within a single sentence? Not everything is black and white, but some situations are.
The person he's replying to argued against putting things on a spectrum. Does that not imply painting everything in black and white? Thus his response seems perfectly sensible to me.
He argued against putting things in a spectrum in many instances where that would be wrong, including the case under the question. What's your argument against that idea? LLM'ed too much lately?
Developers chase the user base. If and when the users choose Linux developers will target Linux.
Proton as a project let's valve hedge on the heir apparent OS without upfront developer cost. If the Linux player base grows, developers will follow and valve is poised to remain dominant.
if you don't find currying essential you haven't done pointfree enough. If you haven't done pointfree enough you haven't picked equational reasoning yet, and it's the thing that holds you back in your ability to read abstractions easily, which in turn guides your arguments on clarity.
if only there was a difference between native languages aiming at lossy fluency (feels better) and programming languages aiming at deterministic precision.
If you really cared about that, you wouldn't have picked Rust. Nim or Haskell are terser languages.
> Every language we’ve built defaults to sequential execution with parallelism bolted on.
False and misleading statement. Array languages have been around for a long time, but you didn't care to learn them.
> Formal verifiability. Move beyond type checking to compile-time proofs.
Good luck with your tokens budget for proof providing. LLMs won't solve that for you. If you believe that proofs are as simple as matching API calling inerfaces you're wrong.
> Declared effects. Every function explicitly states what it reads, writes, and depends on, machine-enforced.
Good functions are pure functions that have no effects. Good design tries to minimize the number of effects needed and maximize the footprint of pure functions mapped over inputs and outputs. If you insist that every function needs an explicit effect annotation, you don't know the topic and you haven't worked with effect systems much.
reply