Code is so incredibly hard to mentally grasp and every mental overload should be omitted to reflect on the logic.

There is a reason why there is one code basis and this should always be curated by a linter to uniformly enforce a standard.

There is still plenty of room for style and code organization.

I witnessed first hand many trench wars around seemingly small things like curly brackets in IF statements dealing with the question of one white space or none, because it appealed to personal preferences and before ESlint people would go to great length reformatting hundreds of LoCs just to get their right feeling of code syntax.

Weird. And git -diff was massive, as well as the code reviews.

(Un)Happy times. :D

>Maybe we'd have editors and viewers where you could configure the syntax however you wanted

I took this to mean that, in this fantasy universe, you could make any source file look however you want. Like tabs vs spaces and pure html vs html-with-css, this is about separating meaning from presentation. Is there a good reason to force the same visual representation on everyone?

But if the syntax was separate from the underlying representation, couldn't you just have your editor open it the way you want?

I’m all for keeping consistent flat utf-8 files. I’d hate for my code ultra simpleminded, possible to pen test with a pen and paper, python and sql code to be wrapped in a god awful xml or json or proprietary db markup and object hierarchical model of what code should look like.

Like I imagine trying to check in a jupyter notebook but worse.

For instance tabs vs spaces was decided and text editors accommodated this and despite what may be someone’s personal preference a uniform decision was made.

Humans can learn. We should use accessible formats and push for standards and keep those readable.

It would definitely be the norm that there were languages that were dark or light mode, and both sides would be convinced they were right.

<visual-group>…</visual-group>

Also, I wish that at least in current editors there would be a way to render \n\n as a half-height line. Full-height empty lines are too bold.

Automatic wrapping doesn't work because you want to break at specific points

You really want to have a set of buttons that switch between:

  - a line of arguments
  - a block of arguments
  - a line/block of only non-default valued arguments
  - arguments sorted by name
  - …

How does it know that x, y, width, and height are semantically grouped and best put on the same line? It doesn't. (from the other comment)

Look higher, parameters can be grouped at the declaration level. <params><related-params name=“coords”>…</>…</>. Now you can render a nice frame around these in block mode. Or not, depending on local renderer settings.

Everyone will hate it.

There’s always a way to make everyone hate something, especially if the solution is clueless about its problem. It doesn’t mean it should be done this way. Experiment and evolution could make it work, we just have to let people try instead of dismissing it so confidently.

That said, if you use classes, descriptive names, and appropriate comments, it won't matter how you group because your code will be self explanatory.

Finally, with today's wide-screen monitors on desktop, line length is less of a worry. Problem only arises when reading code on mobile devices.

The last workplace I was at had a soft wrap around 80 characters, but we upped that to 100 when functions and methods became almost vertical.

1. Breaking at specific points is something that can be specified by the pretty-printer of the _viewer_ you are using. Think of existing auto-formatters and imagine that they're working over the view instead of the persisted form.

2. The AST can have pointers into advisory data (or the other way around, if desired, the "program data" can include the AST, but also other things as well) to note that there is an anonymous region here (C# and friends already have conventions for this _for the source code_ that Visual Studios understands - look at `#region` comments). This would let viewers choose their preferred representation for a region.

You could then decompile to some alternative syntax, but you'd lose any idiosyncratic formatting represented by the compressed diff.

I don't see why it couldn't be done though, I think it just hasn't been a priority. Heck, you could have 100 different users collaborating in 100 different "languages", and so long as they serialized to the same AST and back, none of them would ever have to see the atrocious syntax which the other users prefer. Their editors and browsers could just render everything according to their users' preferences.

Edit: it appears that Unison has an issue for this feature: https://github.com/unisonweb/unison/issues/499

Note that I said 'statements', not 'expressions'.

A lot of the confusion here (and maybe yours, too) stems from this difference. In Rust, (almost) everything is an expression by default, and you turn it into a statement by adding a semicolon. This allows you (and the type checker) to very neatly distinguish between expressions and statements, which is great. It's a very nice and elegant approach imo.

What if the AST is persisted as S-expressions, but then you have a different syntax to edit it? Algol-ish, Pascal-ish, C-ish, Python-ish: choose your poison (or even support multiple poisons and let the developer pick the one they prefer?)

This was actually the original plan with Lisp. Lisp was originally supposed to have two syntaxes, S-expressions and M-expressions, with M-expressions being Algol-like. However, the implementation of M-expressions was delayed, and people got so used to using S-expressions directly, they decided M-expressions were unnecessary and they were never implemented in mainstream Lisp. They were implemented in the Lisp 2 project, but that ended up being an evolutionary dead-end; various attempts at the idea have happened since but none of them really took off.

Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need. However, S-expressions can make the language more foreboding to complete beginners, and even among experienced programmers, a decent percentage find them seriously off-putting. Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today.

Many editors are already altering what is stored on disc before presenting it to you - type annotations, code folding, git info. I think we could do a lot if our default storage was the semantic representation of the code.

And you will have easier time getting your changes merged into dotnet/runtime than into Python.

I may recall incorrectly but AppleScript may be an example: some file formats are serialized ASTs. The editor displays it as textual code. A downside of this is that you can’t save a syntactically invalid file.

Sure it's an intuitive way of representing your data. Is it the most appropriate though? See an example [0] about using Projectional Editing in order to use mathematical notations for formulas.

[0]: http://voelter.de/data/pub/gemoc2014-voelterLisson-MPSNotati...

There are visual programming languages that chain together blocks, instead of raw text.

> The hard problems of programming don't usually have much to do with syntax.

I guess it depends on how you define hard. You are clearly talking about "a singular issue that needs to be solved", which really only effects a single developer / team and, to a lesser extent, those that use that solution. But if you consider something like syntax, you're now talking about something that much a much smaller impact _per developer_, but has that impact on _every_ developer. The syntax issue may have a much larger impact overall.

    % echo "nums 1 10 | filter even | to_words | map uppercase" | refab imagine 
    TWO
    FOUR
    SIX
    EIGHT
    TEN

    % echo "with file '/tmp/top-ten-most-populous-cities.txt' do; cities = read; cities.each { |city| (city.name, city.utc_offset) }" | refab imagine
    Tokyo, 9
    Delhi, 5.5
    Shanghai, 8
    São Paulo, -3
    Mumbai, 5.5
    Mexico City, -6
    Beijing, 8
    Osaka, 9
    Cairo, 2
    New York, -5
    

Of course the execution is non deterministic and at the moment only works for simple things, but you can imagine as LLMs get more capable and more integrated with tools this will matter less and less.

[1] https://github.com/lgastako/refab

I recently started writing a game in Godot. I don't know GodotScript, and I've found I don't like it very much in trying to learn. I turned to aider.chat to see if I could describe the functions, data structures, and systems I wanted and have it write them. I also tried writing in a more familiar language (...one with braces...) and having it translate those files.

It does pretty well, but it doesn't feel like software engineering. It's too hands-off and doesn't activate the same neurons. All the problem-solving and puzzle-solving is gone, and the successes are quite boring, and the failure modes are more irritating even if they're necessarily quicker to solve.

It's a weird experience. I'm moving so, so much faster than I would have on my own, but I don't enjoy it. It feels like cheating - I'm not actually ashamed of what I'm doing but I also won't take credit for writing the code.

However, what I'm getting at is this: If I could write the code in a syntax or even language that I prefer and have copilot or whatever translate it in near-real-time (without active prompting), that would be the best of both worlds. I'd still be a little sad at myself if I didn't learn the new language, but I also think this method would facilitate learning better than what I'm doing with aider (because I could see what my code turns into as I'm writing it, and learn that "translation").

Here is an example of GPT's output for Python with braces that was generated after just spending 10 seconds for the prompt:

  def preprocess_braces(code: str) -> str:
      lines = code.split('\n')
      processed_lines = []
      indent_level = 0
      indent_str = '    '  # 4 spaces for indentation

      for line in lines:
          stripped_line = line.strip()
        
          # Check for opening brace
          if stripped_line.endswith('{'):
              processed_lines.append(indent_str * indent_level + stripped_line[:-1].strip() + ':')
              indent_level += 1
          # Check for closing brace
          elif stripped_line == '}':
              indent_level -= 1
          else:
              processed_lines.append(indent_str * indent_level + stripped_line)
    
      return '\n'.join(processed_lines)

  # Example usage:
  code_with_braces = """
  def example_function() {
      if True {
          print("Hello, world!")
      }
      for i in range(5) {
          print(i)
      }
  }
  """


  processed_code = preprocess_braces(code_with_braces)
  exec(processed_code)  # This will execute the transformed Python code

  print("Processed Code:\n", processed_code)

What’s the problem with having no redundancy? By the same logic, we should require numerals to be spelled out in words so the compiler can check if the programmer didn’t accidentally write a different number.

  def fahrenheit_to_celsius(x): {
      return (x - 32 [thirty two]) * 5 [five] / 9 [nine];
  }

yes, because in Python two programs with different indentation are not the same. what's the problem that you can't use tools intended for code without significant whitespace with code in Python?

I've seen both misplaced braces (akin to mis-indenting blocks in Python), indentation not matching braces and other problems of the same sort in non-Python code. Readers of the code would misunderstand the code when badly indented, and might introduce bad braces as well (not everybody uses automatic formatters and linters either, esp as they will sometimes "quickly" edit code in their non-usual dev environment). Not to mention that some "braced" languages allow having single-line blocks without braces.

It's also not true that this is the only way Python encodes structure: new blocks generally only start with a ":", and you've got control flow keywords that allow for new blocks to start. One could argue that's a great feature disallowing you from introducing confusing spacing without actually having a new block started.

While I am fond of applying many of double-entry-accounting principles in programming to increase trust in what we write, I believe that's much better done with unit-tests, which can more clearly demonstrate the expectations for any code and read more like documentation.

Do you think all syntax in programming languages should have some sort of extra validation built-in? Eg. you should type in a constant twice (declare it as `const int a = 5` and then you have to set the value later as `a = 5` or you get an error?)?

As I said above, people will always find an "objective" excuse why their preference is better. But I've seen bad-block-boundaries in Python as much as I've seen it in other languages which use explicit block boundaries like braces (and I've done more Python over the last ~20 years). I've heard this argument a gazillion times, but hundreds of bugs due to that have simply failed to materialize while working on large projects with tens and hundreds of people.

Getting indentation right is _really_ not that hard, just like getting braces right is not that hard. I've yet to find someone who prefers their code to not be indented at all, and only rely on braces — at least not in a team setting where you can't simply reformat all of it.

This must surely be a bad thing? How would this signal an unfortunate indentation change between:

  if foo:
    bar()
  bar2()

  if foo:
    bar()
    bar2()

>Python encodes structure in only one way, using indentation

Except when you write a multiple line string using """ notation.

Or when you put things inside parenthesis, which i have seen as the preferred solution for method chaining.

Point is, python claims indentation is all that is needed, and then very quickly breaks it's own rule.

As someone who has been diffing endless amounts of python through various diff tools, this is totally a non issue.

While we're on the topic, if we store only syntactically valid programs, we can express diffs in terms of semantic refactoring rather than textual changes. This would enable stuff like preserving refactoring across merges, thereby bypassing conflicts that would arise under text merges. There are limits to this of course as you can still come up with conflicts, but anything to ameliorate the nightmare of manually fixing a textural merge.

Such editors would remove some categories bikeshedding, but would add brand new categories of bikeshedding.

* Why did/didn't you add an empty line (EDIT: or whatever no-op visual equivalent) after that `if` block? My editor needs blocks to be separated a certain way to be able to display them nicely grouped in logical blocks! This representation of AST is so limited that we can't store such differences in style, we need editors that work at some super-AST level!

* What do you mean my code is an unreadable mess with hundreds of operations? All I see in my editor is a nice single operation "copy fields from class X to struct Y". If your editor can't detect such an obvious thing from the AST and display it nicely, then find a better one.

* Some codebases not even bothering with functions because the founding engineers use a specific IDE that just lets them group code arbitrarily (no no that's not reinventing functions, that's what progress looks like!), and you can't use your favorite editor because that's not on the scope of that editor, so the editor's author politely tells you to use that other editor you dislike if you really need such a thing.

* I can probably come up with more scenarios if I spend more time thinking about it. And there's probably also more petty scenarios that I can't even imagine.

I'm not saying such editors wouldn't be nice. Everyone has their own preferences, and some people might work better this way. Just, don't expect them to reduce the amount of petty bikeshedding in projects, much less eliminate it.

I'm not sure what you mean. Could you give an example?

If the current line starts on the same line that the previous expression started on, then a semicolon is inserted at the beginning of the current line. There are also some messy rules about opening and closing braces being inserted.

So, this:

  do expr1
     expr2
     do expr3
        expr4

  do { expr1
     ; expr2
     do { expr3
        ; expr4
        }
     }

[0]: https://amelia.how/posts/parsing-layout.html

Try it like this:

  if (x) 
  { if (y)
    { if (z)
      { foo; } } }

There is a rhyme and reason to it, and consistency.

I've written some C programs that way, though not recently and can't point to any online examples.

However, I also wrote, and maintain, the Yacc grammar file in TXR Lisp in this style (just the actions in the grammar portion). For whatever reason, it works well in grammar files.

https://www.kylheku.com/cgit/txr/tree/parser.y

{} are braces

This is English English

Swahili looks unfamiliar to me. Because I didn't grow up in southern Africa. Don't conflate subjective familiarity with objective simplicity - any "unfamiliar" concept only reflects on you, not your subject.

This is a red herring. Haskell, CoffeeScript, Nim, Lean, etc. are expression-oriented and use indentation like Python, while C(++), Java, JavaScript, etc. are statement-oriented and use braces.

And in Python \n is not an alias for end-of-line, it’s a separator for statements.

Skill issue. I just press my “paste with correct indentation” hotkey and move on.

Is the syntax not about 80% the same? And isn't most of that "same simple syntax" commonly used daily?

> Many people here argue that braces do provide some structure that helps in understanding and navigating the program. Python files over 100 lines with a lot of if-statements become syntactically unreadable.

That's probably True. But poor programming discipline and syntax that eases reading problematic code also contribute to this issue.

> So taking them away does not help. For me it actually promotes better coding style and hygiene.

> Generally, minimalism (except for the Lisp-style one) is not always good. The quote was about perfectionism, not minimalism.