Comment by miffy900

No Swift was developed as a strategic moat around Apple's devices. They cannot be dependent on any other party for the main language that runs on their hardware. Controlling your own destiny full stack means having your own language.

Yes, that's what I said.

Neither C++ nor C pass classes by reference by default (what even is a C "class" other than a struct?).

They are, as far as "Have one source of truth" is concerned. That is what parent is talking about.

They don’t, by default. That’s something you have to implement yourself.

It’s a common misconception that comes from the standard library data structures, which almost all do implement CoW

You're re-stating his exact problem while trying to refute him.

Natural languages are ambiguous, and that's a feature. Computer languages must be unambiguous.

I don't see a case for "complex" vs "simple" in the comparison with natural languages.

I fully accept that formalism is an important factor in programming language design. But all HLLs (well, even ASM) are a compromise between machine speak (https://youtu.be/CTjolEUj00g?si=79zMVRl0oMQo4Tby) and human speak. My case is that the current fashion is to draw the line at an overly simple level, and that there are ways to wrap the formalism in more natural constructs that trigger the parts of the brain that have evolved to hanle language (nouns, verbs, adverbs, prepositions and so on).

Here's a very simple, lexical declaration made more human friendly by use of the preposition `my` (or `our` if it is packaged scoped)...

  my $x = 42;

Literate programming is not about programming in natural languages: it's about integrating code (i.e. the formal description in some DSL) with the meta-code such as comments, background information, specs, tests, etc.

BTW, one side benefit of LP is freedom from arbitrary structure of DSLs. A standard practice in LP is to declare and define objects in the spot in which they are being used; LP tools will parse them out and distribute to the syntactically correct places.

Exactly. I mean think about the programming languages used in aircraft and such. There's reasons. It all depends on what people are willing to tolerate.

> Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible.

I 100% agree with your statement. My case is that a simple language does not necessarily result in simpler and more readable code. You need a language that fits the problem domain and that does not require a lot of boilerplate to handle more complex structures. If you are shoehorning a problem into an overly simplistic language, then you are fighting your tool. OO for OO. FP for FP. and so on.

I fear that the current fashion to very simple languages is a result of confusing these aspects and by way of enforcing certain corporate behaviours on coders. Perhaps that has its place eg Go in Google - but the presumption that one size fits all is quite a big limitation for many areas.

The corollary of this is that richness places an burden of responsibility on the coder not to write code golf. By tbh you can write bad code in any language if you put your mind to it.

Perhaps many find richness and expressivity abhorrent - but to those of us who like Larry's thinking it is a really nice, addictive feeling when the compiler gets out of the way. Don't knock it until you give it a fair try!

Well sure - being in a rut is good. But the language is the medium in which you cast your idiom, right?

Here's a Python rut:

  n = 20  # how many numbers to generate
  a, b = 0, 1
  for _ in range(n):
    print(a, end=" ")
    a, b = b, a + b
  print()

Here's that rut in Raku:

  (0,1,*+*...*)[^20]

I am claiming that this is a nicer rut.