5 ms·

In the last years, simplistic languages such as Python and Go have “made the case” that complexity is bad, period. But when humans communicate expertly in Engli

In the last years, simplistic languages such as Python and Go have “made the case” that complexity is bad, period. But when humans communicate expertly in English (Shakespeare, JK Rowling, etc) they use its vast wealth of nuance, shading and subtlety to create a better product. Sure you have to learn all the corners to have full command of the language, to wield all that expressive power (and newcomers to English are limited to the shallow end of the pool). But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend. We need to match the impedance of the tool to the problem. [I paraphrase Larry Wall, inventor of the gloriously expressive https://raku.org https://raku.org]

grey-area 8mo ago
Not sure how I feel about Shakespeare and JK Rowling living in the same parenthesis! Computer languages are the opposite of natural languages - they are for formalising and limiting thought, the exact opposite of literature. These two things are not comparable. If natural language was so good for programs, we’d be using it - many many people have tried from literate programming onward.
- librasteve 8mo ago
  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 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;
  - j_w 8mo ago
    How is that snippet any better than: x := 42 Or let x = 42 Or x = 42 It seems like a regression from modern languages.
    - bmn__ 8mo ago
      "my" is 33% shorter than "let" Example 1 and 3 are not declarations, so apples ↔ oranges
      - yossi_peti 8mo ago
        Example 1 is a declaration in Go. Example 3 is a declaration in Python.
      - j_w 8mo ago
        my $x = 42; let x = 42 Well, when you add in the '$' and ';' tokens the "let" example is still shorter. Also as another person replied to you, those other two examples are declarations in other languages. So 0 for 3 there.
  - grey-area 8mo ago
    Have you looked at all the previous attempts? Your example is not compelling I’m afraid but you should try building a language to see. Also read literate programming if you haven’t already.
- palata 8mo ago
  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.
- tom_m 8mo ago
  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.
- h3lp 8mo ago
  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.
  - grey-area 8mo ago
    Well I think the ambition was to have as much as possible in natural language, with macros calling out to ‘hidden’ code intended for machines. So I do think there is a good link with later attempts to write using natural language and make computer languages more human-friendly and he was one of the first to have this idea. Neither strategy has had much success IMO.
integralid 8mo ago
>But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend. It's exactly the opposite. Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible. It's easy to introduce a lot of complexity and clever hacks, because as the author you understand it. But good code is readable for people, and that's why very expressive languages like perl are abhorred.
- librasteve 8mo ago
  > 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!
- valenterry 8mo ago
  Then you should write assembly only. Like `MOV`, `ADD`... can't really get simpler than that. Problem is, that makes every small part of the program simple, but it increases the number of parts (and/or their interaction). And ultimately, if you need to understand the whole thing it's suddenly much harder. Surely you can write the same behaviour in "clever" (when did that become a negative attribute?) or "good" way in assembly. You are correct. But that's a different matter.
deleted 8mo ago
[deleted]
spongebobism 8mo ago
Perlis's 10th epigram feels germane: > Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.
- librasteve 8mo ago
  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.
  - zephen 8mo ago
    seq = [0,1] while len(seq) < 20: seq.append(sum(seq[-2:])) print(' '.join(str(x) for x in seq)) > I am claiming that (0,1,+...*)[^20] is a nicer rut. If it's so fantastic, then why on earth do you go out of your way to add extra lines and complexity to the Python?
    - librasteve 8mo ago
      err - I cut and pasted the Python directly from ChatGPT ;-)
      - zephen 8mo ago
        But it doesn't do the same thing at all as the raku. It doesn't build a list, rather it dumps it as it goes. It has an explicit print. It uses a named constant for 20 rather than a literal. etc, etc...
    - jaen 8mo ago
      Complexity-wise, this version is more complicated (mixing different styles and paradigms) and it's barely less tokens. Lines of code don't matter anyway, cognitive load does. Even though I barely know Raku (but I do have experience with FP), it took way less time to intuitively grasp what the Raku was doing, vs. both the Python versions. If you're only used to imperative code, then yeah, maybe the Python looks more familiar, though then... how about riding some new bicycles for the mind.

grey-area 8mo ago

Not sure how I feel about Shakespeare and JK Rowling living in the same parenthesis! Computer languages are the opposite of natural languages - they are for formalising and limiting thought, the exact opposite of literature. These two things are not comparable. If natural language was so good for programs, we’d be using it - many many people have tried from literate programming onward.

librasteve 8mo ago
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 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;
- j_w 8mo ago
  How is that snippet any better than: x := 42 Or let x = 42 Or x = 42 It seems like a regression from modern languages.
  - bmn__ 8mo ago
    "my" is 33% shorter than "let" Example 1 and 3 are not declarations, so apples ↔ oranges
    - yossi_peti 8mo ago
      Example 1 is a declaration in Go. Example 3 is a declaration in Python.
    - j_w 8mo ago
      my $x = 42; let x = 42 Well, when you add in the '$' and ';' tokens the "let" example is still shorter. Also as another person replied to you, those other two examples are declarations in other languages. So 0 for 3 there.
- grey-area 8mo ago
  Have you looked at all the previous attempts? Your example is not compelling I’m afraid but you should try building a language to see. Also read literate programming if you haven’t already.
palata 8mo ago
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.
tom_m 8mo ago
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.
h3lp 8mo ago
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.
- grey-area 8mo ago
  Well I think the ambition was to have as much as possible in natural language, with macros calling out to ‘hidden’ code intended for machines. So I do think there is a good link with later attempts to write using natural language and make computer languages more human-friendly and he was one of the first to have this idea. Neither strategy has had much success IMO.

integralid 8mo ago

>But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend. It's exactly the opposite. Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible. It's easy to introduce a lot of complexity and clever hacks, because as the author you understand it. But good code is readable for people, and that's why very expressive languages like perl are abhorred.

librasteve 8mo ago
> 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!
valenterry 8mo ago
Then you should write assembly only. Like `MOV`, `ADD`... can't really get simpler than that. Problem is, that makes every small part of the program simple, but it increases the number of parts (and/or their interaction). And ultimately, if you need to understand the whole thing it's suddenly much harder. Surely you can write the same behaviour in "clever" (when did that become a negative attribute?) or "good" way in assembly. You are correct. But that's a different matter.

deleted 8mo ago

[deleted]

spongebobism 8mo ago

Perlis's 10th epigram feels germane: > Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

librasteve 8mo ago
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.
- zephen 8mo ago
  seq = [0,1] while len(seq) < 20: seq.append(sum(seq[-2:])) print(' '.join(str(x) for x in seq)) > I am claiming that (0,1,+...*)[^20] is a nicer rut. If it's so fantastic, then why on earth do you go out of your way to add extra lines and complexity to the Python?
  - librasteve 8mo ago
    err - I cut and pasted the Python directly from ChatGPT ;-)
    - zephen 8mo ago
      But it doesn't do the same thing at all as the raku. It doesn't build a list, rather it dumps it as it goes. It has an explicit print. It uses a named constant for 20 rather than a literal. etc, etc...
  - jaen 8mo ago
    Complexity-wise, this version is more complicated (mixing different styles and paradigms) and it's barely less tokens. Lines of code don't matter anyway, cognitive load does. Even though I barely know Raku (but I do have experience with FP), it took way less time to intuitively grasp what the Raku was doing, vs. both the Python versions. If you're only used to imperative code, then yeah, maybe the Python looks more familiar, though then... how about riding some new bicycles for the mind.