Hacker News Reader

Comment by 12_throw_away | Hacker News Reader

I wish there were even more of this sort of thing, even though I'm an anti-braces zealot - it's crazy to me that, here in 2024, code is still so tightly linked to specific textual representations. Maybe there's an alternate reality where IDEs and development tooling got better and better post-smalltalk/lisp, instead of ... whatever we have now. Maybe we'd have editors and viewers where you could configure the syntax however you wanted. And sure, it would be persisted to disk in some canonical representation, maybe text, maybe a DB ... but you'd never need to worry about it, because all your tooling (VCS, diffs, refactoring tools, etc) would work with the AST, and you'd never need to worry about tabs or spaces ever again.

View on HN

I think having a single syntax is the best way. I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc. It all being standard is really helpful. A standard Autoformatter like black or gofmt even though I might might not choose all the options, the uniformity is super valuable.

> I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc.

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

That is true. That seems like a lot of complexity though.

This may be controversial, but I find 2-character indented Javascript, coming from my 4-character indented Java, for the projects I work on, as much of a shock as moving between braces and Python. Particularly if it has been subjected to an opinionated formatter that just doesn't match my personal style. Completely unreadable, I mumble under my breath. And then my eyes adjust to it for a bit, and after an... hour? (maybe) of coding in the (ahum) "hostile" style, it's familiar (again) and we're on our way.

This is why I prefer tabs for indentation. I get to see 4 spaces, the blue haired frontend kid gets to see 2 spaces, and Linus gets to see 8. Everybody's happy.

8?? His neck must be sore.

Sounds good in theory, but I never saw a project that used tabs and didn't look like a complete mess when viewed with the non-blessed tab width.

Pretty sure the Linux source tree looks fine at a tab width of 2 instead of the blessed 8.

Emacs even "helpfully" auto-converts <tab width> spaces to one tab, no matter where.

It's fine as long as you don't use tabs for visual alignment. Especially C projects tend to do this, and/or have a weird mix of tabs and spaces (e.g. indent by four spaces, but all eight spaces are tabs). That's just silly.

But if you just always indent by n tabs, and align with spaces for visual alignment, then it's not a problem. This is what e.g. gofmt does.

If you can also get your colleagues to do things like putting their `&&` style logical operators on new lines, then tabs for indents works really well.

(This isn't the best example of what I'm getting at, but it's easy to grasp. A stronger example would be the use of ternary operators with multiple lines of JSX. There are many "micro-syntaxes" or "micro-layouts" that help readability and form common patterns in code bases which don't play well with tabs-for-indents, so when you use tabs, you have to train your team to develop and accept novel versions of these "micro-layouts".)

The problem with tabs is that you can't really do alignment with them, unless you have elastic tabs (which are pretty much nowhere). I love the idea of tabs for indentation and spaces for alignment, but even bringing up the idea of using both gets one branded a heretic, so that's out. Which pretty much leaves only spaces if you want to allow for alignment.

For what it's worth, this is how the built in and mandatory Go formatter works and it's "fine".

I'm really sceptical of the idea of mixing two different invisible characters in the same file, which is why the tabs+spaces idea makes me feel slightly icky. But another option is just not using alignment spaces at all - if you want to align two parameters/statements/etc, you always split them onto their own lines and use indents directly instead of alignment.

In other words, instead of:

    def my_func(self,
                param):

You always do something like:

    def my_func(
        self,
        param,
    ):

I tend to agree that you shouldn't be "aligning" things with spaces anyway. If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred.

However, regarding "mixing two different invisible characters in the same file" - you can, and should, configure your text editor to display tabs in a visually distinct way from spaces. Kate (my favorite) shows them as chevrons. Geany and Notepad++ show them as arrows. Not only does this make it easier to scan vertically along an indentation level, but doing so also makes it glaringly obvious if a pesky space has snuck in, resulting in a jarring misalignment.

> If nothing else, it causes diff pollution when the length of a line changes and you have to add or delete spaces to adjacent lines to keep things even, even though no semantic change to those lines has occurred.

While I agree with this in general, I find making the code nicer to read to be more important that avoiding diff pollution. Especially when that diff pollution can be avoided with a simple "ignore whitespace" in most cases.

I get that if I'm truly mixing one and the other, but if I'm consistently using tabs for indentation, I mostly want them to be invisible - I don't want visual noise on every line. I guess if the syntax highlighting makes them subtle enough it could work, but I think that sort of visual distinction only really works if the visually distinct character only rarely shows up.

I tend to prefer the former, but it suffers from the indentation being way to large if the method name is really long.

That being said, there are other cases where I want to align things and "a specific size indent" doesn't work

SQL

    SELECT this_column,
           that_column
    FROM tablename
    WHERE this_column = 1
      AND that_column IS NOT NULL

Comments

    /* 
     * Blah blah blah
     * Note: this is interesting because (enough text to want newline)
     *       and also that blah blah
     */

There's lots of places where "alignment" makes sense.

For the SQL case, you can just use a different formatting that puts aligned items into blocks, something like:

    SELECT
      this_column, 
      that_column
    FROM tablename 
    WHERE
      this_column = 1
      AND that_column IS NOT NULL

(The AND token could go either where it is, or at the end of the previous line, depending on your preferences - I prefer the clarity of putting the operator first here over the alignment of the column names, but I can see both sides.)

It might not be your preference, but that's always going to be the case with formatting.

With the comments, that's a good point. I'd generally prefer to use double comments for anything that spans multiple lines, but if you're creating a formatter you need to handle any syntax thrown your way. You could try formatting it without the leading space, but that would be very unusual, or keep the leading space and have it as the one exception to the rule. Or just not format comments, I guess.

I agree. To me ESlint in the JavaScript domain is an unsung hero.

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

I finding reading other people's rust generally delightful because everyone is the same machine controlled style guide (cargo fmt + clippy). It's definitely reduces the mental burden of reading code.

I recommend Prettier over ESLint - Prettier tends to produce more consistent results and is a lot faster (because it's doing less work). Moreover, ESLint are deprecating the styling rules at the moment (although they'll be made available in a different package).

You can configure ESLint to use prettier, but in my experience it's usually easier to just run ESLint separately to prettier.

The whole point is that you don't have to parse different syntax, because you choose your syntax at the editor level.

Your justification for a single syntax is "I don't want to have to look at python and have to parse spaces, curly braces, square braces, etc." But the comment you just replied to said:

>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?

> Is there a good reason to force the same visual representation on everyone?

Leaky abstractions. If there are two different visual representations then sometimes someone using one representation will need to think about the other.

I think this is the best case against a more abstract notion of source code. I don't think you'll ever achieve the dream of heterogeneous representations on a single team unless you somehow get an autoformatter like black to work with both.

There's also questions like:

* Would such bytecode/binary be considered "source code"? If no, then bye bye Open Source Definition (OSD). Distributing such thing would not be considered open source.

* If it is considered "source code", then is it considered "obfuscated" source code? If yes, then bye bye OSD. Distributing such thing would not be considered open source.

* If it is not considered "obfuscated" source code, then what's the difference compared to, say, JVM bytecode? Is it only that an IDE exists that can modify such bytecode in a fancy way?

* In that case, if such an IDE is created that modifies JVM bytecode directly, and a program is created using that IDE modifying the JVM bytecode[1] directly, and such "source code" is distributed, the would that bytecode be open source? Since, after all, it's "the preferred form in which a programmer would modify the program" (and therefore not obfuscated).

[1]: Or maybe some superset that is mostly JVM bytecode but it has some opcodes for higher level niceties.

You are right. It would be cool if that was an option, but it just seems like a lot of unnecessary complexity to actually make that happen. In addition if you ever want to look at code with a colleague on the same computer then the syntax becomes an issue again.

+1 for ruff for python as a formatter & linter that allows single quotes without shaming you.

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.

I like to draw the comparison that in an alternate universe where the ASCII .txt file format had simply included a color byte with every letter byte, we'd now be having coding format guidelines that also go into great detail prescribing manual syntax highlighting. The fact we don't and avoided endless bike shedding over syntax highlighting, instead leaving it to automatic tools and the presentation layer not the code itself, is purely an historical accident. Well, what does that say about other code formatting details which programmers currently do waste time manually doing and worrying about?

I had never considered the bikeshedding that would occur if there was a color byte… We struggle with spaces versus tabs, how many spaces, braces (or not), semi-colon (or not).

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.

That one person who absolutely insists that enums are blue and everyone who can’t see it is a failure of a programmer

I had never considered that, but you're absolutely right. I would totally be the sort of person to manually idiosyncratically syntax highlight my code if it were feasible. I'm sure glad I don't feel compelled to do that...

An other option is to have the color be semantically significant in which case you can't idiosyncratically syntax highlight. That's what colorForth does. It's weird.

Some programming languages such as ColorForth require colours in order to work, that the meaning of a word depends on what colour it is written with.

There's always someone who mentions this, and it just doesn't work.

Do you group things like:

  do_stuff()
  more_stuff()

  other_stuff()
  moar_function()

Or:

  do_stuff()
  more_stuff()
  other_stuff()
  moar_function()

Or:

  do_stuff()
  more_stuff()
  other_stuff()

  moar_function()

Grouping code by a single blank line can make a big difference. This is a bit of a silly example, but there's tons of not-so-silly examples. You can't really represent that in an AST.

Line length is another. infinite line length doesn't work as screens aren't infinitely long. Automatic wrapping doesn't work because you want to break at specific points. An example is something like:

  window = XCreateWindow(display, XRootWindow(display, screen),
      center_x, center_y, size, size,
      4,              // border width
      vinfo.depth,
      CopyFromParent, // class
      vinfo.visual,
      CWColormap | CWBorderPixel | CWBackPixel | CWOverrideRedirect,
      &window_attr);

Cramming as much as possible on as few lines as possible is just not going to work well.

There's tons of cases.

That's why no one does it. Because it just won't work. Everyone will hate it.

I agree about horizontal space adding to readability and I use that method fairly often.

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.

You want to wrap in logical locations at times. That's my point. To repeat: cramming as much as possible on as few lines as possible is just not going to work well. Wrapping at column 80 vs 100 or whatever has nothing to do with that. That XCreateWindow() would be:

  window = XCreateWindow(display, XRootWindow(display, screen), center_x, center_y, size, size,
      4, vinfo.depth, CopyFromParent, vinfo.visual, CWColormap|CWBorderPixel|CWBackPixel|
      CWOverrideRedirect, &window_attr);

And that's just not better. It's much much worse. Only a human can judge where it makes sense to break things (or not break things).

Completely forbidding "paragraphs" would be atrocious. Almost everyone will hate it. Just like everyone hates walls of text in comments.

And in the end a huge amount of complexity is added throughout the entire stack (from editors to grep to sed to code hosting) for very marginal gain with significant trade-offs.

Line length is a worry because of readability. This is unrelated to the width of monitors. Having to read and visually parse a 200-character line is no fun. In addition, since most lines are relatively short, you also don’t want to have your source code window extra wide just in case, if instead you can use that space for other useful information and controls.

Also, why does your comment have a paragraph break after each sentence except after the third? Because of semantics and the related readability. The same is true for source code. Readable layout does not depend on syntactical structure alone.

> today's wide-screen monitors on desktop, line length is less of a worry

did you buy a large monitor just to full-screen a single text file?

Two points:

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 can't specify it in the viewer, because it won't know where to break. How does it know that x, y, width, and height are semantically grouped and best put on the same line? It doesn't. Auto-formatters can't format this. Or rather: they can only format it in dumb ways.

And including tons of extra info in the AST means you've just got the same as a text file, but in a more awkward and obfuscated format.

Also what you want can already be done right now. Converting your source code to AST and then formatting it how you want is already easy to do. But your coworkers will hate you, because you will lose all these small details that are actually quite significant. And there is no way to get them back once they're lost, so your coworkers all using some formatting tool is not going to help.

You're thinking about the AST as the-AST-for-LanguageX not the-AST-for-LanguageX-withAdvice. Including an AST node called `Region` or a decoration for "Region" that multiple AST nodes can point to (or vice-versa a list-of-region indicies pointing into the AST tree) _that is serialized and stored in the same kind of way that #region is for C# code_ would allow for multiple people to look at the code structured in the correct way while displaying that structure in different ways (color coding vs. block outlining vs. extra newlines vs ... you get the idea).

Grouping code … You can't really represent that in an AST.

<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
  - …

And a hint on a default representation, with some default heuristics.

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.

Well, a few days ago there was a post about the Unison language, where code is stored in AST form and text is just a representation.

https://news.ycombinator.com/item?id=40882133

Last time I looked, [Unison code] -> [entry in the AST DB] was a one-way process. Adding a function means writing it (with whatever style you like) and seeing if what you wrote constitutes a new function or an existing one. You can't fluff db entries back up in to human friendly code.

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

if they were truly represented by the same AST, I can't believe the differences between these "languages" would be anything more than swapping symbols out.

True. Perhaps "styles" or "syntaxes" would be better. It's all that stuff we spend time building consensus around, but that doesn't affect program behavior. If our tools respected our style preferences on a user-by-user basis, we could drop the consensus requirement altogether.

I've long dreamt of a system that compiles to native code, but stores a compressed SSA form (similar to SafeTSA or LLVM bitcode) in the binary for efficient runtime re-optimization based on profiling, somewhat similar to current Android Runtimes. One could then have several levels of debugging symbols, one that gives names to local variables represented by CFG nodes, and another that adds a compressed diff between some standardized decompiler output and the original source.

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

You mean Java or .NET?

I'm not aware how to get byte-for-byte identical source out of a Java class file or .NET assembly.

Last I checked, Java AoT compilation precluded runtime re-optimization, though I presume they've fixed that by now.

Last I checked, they both used stack-based bytecode, which typically takes longer to JIT and results in slower native code than a compressed SSA / control flow graph (see the SafeTSA papers).

.NET assemblies are that :)

Though SSA is deferred to JIT/ILC instead. In either case you get the access to all the actual low-level bits when you need to. No other portable target lets you do that.

If you add an extra blank line, or add a trailing space to a line, can you really get that back out from a .NET assembly? Normal disassembly at a minimum results in a loss of formatting.

I can understand braces (to an extent...). What really confuses me are new languages that still require semicolons at the end of expressions/statements.

Why is that so much more different from requiring '\n' instead of ';'?

Maybe I like the ‘\n’ for me and the ‘;’ for the compiler.

There should be only one source of truth.

Because when reading as a human you're typing `\n` anyway which fits in with the whole "Can't the computer just figure out what I'm seeing?" thing. While it's technically correct (the best kind of correct) that it's '\n' vs ';', in practice it's really ';' vs ';\n'. I can only speak to my personal experience but seeing two expression on one line is so rare that I can't even think of an example of the last time I saw it.

The problem is not two expressions on one line, it’s one expression on two lines. e.g.

    foo
        .bar()

now you need to either add syntax to specify that you’re “continuing” (python), play tricks for the parser (Go), or have unreliable magic biting you in the ass half the time (javascript).

I understand it's likely stupid in Python since it's whitespace significant, but are those Go parser tricks really such a big deal or even very tricky?

It's not that difficult; just place the "." at the end of the line:

  foo.
    bar()

And that will work fine. At least in Go.

You can endlessly argue what location is better for the ".", but it really doesn't really matter. Regardless, you don't really need to do parser tricks.

That's exactly what I mean by parser trick. You're relying on the idea that if the parser sees an incomplete expression it won't end the statement then and there.

It also looks like shit, because now you have to check the end of the previous line to know whether it's a method call or a function call which was indented in incorrectly.

With gofmt it's always indented correctly.

Sure but that doesn't quite answer my question: is the parser trick really that bad?

I do see what you mean, of course, and am aware of the arguments but I've never found lack of non-whitespace expression terminator even remotely confusing. I can clearly see indentation in my periphery signalling that it's multi-line. I can also say that in ~13 of using exclusively using semicolon-less languages, I've never had or even heard of a problem caused by someone misunderstanding where an expression ends.

Anyway, this is getting pretty bikesheddy, lol but ya, to each their own, obviously.

What confuses me is languages that can split statements over multiple lines as long as certain conditions are met (such as the break occours inside braces). I rather have a semicolon at the end of the statement to make it more explicit.

This is where I stand. Semicolons convey intent, much like parens in math equations. Sure, the code makes it clear (if you understand the rules) what "the code does", but having semicolons (and parens) make it clear that "what the code does" and "what the writer intended the code to do" are the same thing.

Plus I don't think I've ever seen a case where semicolons made the code harder to read (or write).

But why a semicolon? Sentences have been terminated by periods for hundreds of years until programmers decided to be special snowflakes.

Speaking from a Rust-perspective, having semicolons at the end of statements makes perfect sense and is a brilliant design decision.

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.

Does the difference ever come up in a meaningful way? Is there a syntax that without the trailing semicolon is ambiguous between the two, and the difference changes the behavior?

All the time. A block (in the general sense so that includes function) which ends with an expression will have that expression’s value as its own value (/ return). A `;` converts the trailing expression into a statement, which does not have a value, and thus the block returns `()` (the something representing nothing).

Method chaining is also common in Rust, because builders are common, and chains of iterator adapters are common, and chains on monadic structures (option/result) are common, … having every line break implicitly insert a `;` would be horrid.

Wait, so this is legal:

    fn five() -> i32 {
        5
    }

and this isn't?

    fn five() -> i32 {
        5;
    }

I can't tell if I'm amazed or terrified.

this is what those end up being, it's pretty straightforward?

    fn five() -> i32 {
        return 5;
    }

    fn five() -> i32 {
        5;
        return ();
    }

semicolon changes the expression from returning the result of the expression to running the expression and returning the unit type. if you accidentally do that and specified a non-unit-return-type in the function signature, the type checker tells you about it:

    error[E0308]: mismatched types
     --> src/main.rs:1:14
      |
    1 | fn test() -> i32 {
      |    ----      ^^^ expected `i32`, found `()`
      |    |
      |    implicitly returns `()` as its body has no tail or `return` expression
    2 |     5;
      |      - help: remove this semicolon to return this value

which is also pretty clear about the solution

Yes.

> I can't tell if I'm amazed or terrified.

The rule is very simple and obvious, and the compiler will yell at you if you get it wrong.

It's also very useful and even critical of how expression-oriented the language is: an `if/else` or a match statement must typecheck, all branches have to have the same type. It's obvious if you're using it as an expression, but it doesn't go away if you're using it for the side-effect (as an imperative conditional/switch) and then things can get more dicey as the expressions in each branch can have different types. `;` solves that by making every branch `()`-valued.

Okay, this is really neat design. I went to check whether if..else works in an expression context and it does:

    fn five() -> i32 {
        let a = if (true) { 3 } else { 6 };
        return a + 2;
    }

Pure fun!

Ya if you want fun match/case also works like that.

And though for abs while don’t (they always return ()) `loop` itself does, you can `break` with a value and that’s what comes out the loop.

    let x = {
        3
    };
    let y = {
        3;
    };
    assert_eq!(x, 3);
    assert_eq!(y, ());

i think it'd also mean having to parse whitespace or newlines without something like that?

Thanks, I hate it. Is there any time where you want to use this? Like if Rust worked like other languages and just figured out if it was an expression or statement are there times where you would need an override?

I'm playing around with this in the compiler explorer and I'm now even more confused why you want this.

   let x = {
     println!("Don't mind me in the struct definition");
     3
   }
   assert_eq!(x, 3);

idk there are a lot of uses for it

    let dx = {
        let prev_x = x;
        x = get_x();
        x - prev_x
    };

often, it's slightly better cpp style scoping blocks if nothing else? there are tons of other little QoL things it enables though, but they're all going to be little ergonomics things that only seem worth it if you've used the language for awhile

Also common to set up "capture clauses" for lambdas as Rust does not have that in the language, IME most common with threads:

    spawn({
        let a = a.clone();
        let b = &b;
        move || {
            // do something with the a you cloned and the b you borrowed
        }
    })

One of the things going on here is consistency.

It's not so much that this ability is specifically put in for some reason. It's just something that falls out of several other things.

Rust chose a "curly braces and semicolons" syntax because that's the sort of syntax that is normal in the sorts of PL spaces Rust wants to be used in. I am not sure exactly why being expression-oriented was chosen, but if I had to guess, it would be due to that just generally being considered a better option among many people at the time it was chosen.

So okay, you want expressions, and you want semicolons. Therefore, "you separate expressions with semicolons" is a pretty natural outcome. And since we're expression oriented, "a block is an expression that evaluates to the final value" is near tautological. And since it's an expression, it can go anywhere an expression can go.

Not being able to do this would mean creating specific restrictions against it, and then having to memorize when things don't follow the usual rules. That's more complicated than just letting expressions be expressions.

(also your let is missing a semicolon)

> I'm playing around with this in the compiler explorer and I'm now even more confused why you want this.

It works with RAII to create a temporally isolated resource scope, think context managers / using / try-with-resource; it provides a scratch space where you limit collisions with the rest of the function and avoid the risk of mis-reuse of those values; and before non-lexical lifetimes it was critical to limit borrow durations. It's also routinely used in combination with closures, to prepare their capture. Similar to C++ capture clauses, but without special syntax.

It's essentially a micro-namespace inside the function.

This kind of thing is useful for memory management. Anything you allocate within the scope that isn't returned gets dropped at the end.

You can use this to e.g. acquire a Mutex guard, move/clone something out of the mutex, and ensure it gets dropped as quickly as possible.

    let x = {
        let items = vec![1, 2, 3];
        items[1] // copied out of the vec since usize implements the Copy trait
        // compiler inserts drop(items) here
    };
    // items is no longer valid
    assert_eq!(2, x);

It also comes up in if/else blocks, which have exactly the same syntax and semantics (i.e. they are expressions, not statements):

    let condition = true;
    let x = if condition {
        println!("condition is true");
        5
    } else {
        println!("condition is false");
        10
    };
    assert_eq!(5, x);

edit: and of course, function blocks work exactly the same way! It's neat.

Yes, but: - Is having everything be an expression by default a good design choice? A not uncommon idea in programming language design is that certain language constructs (for example, variable assignments) are better off as only statements, as their potential for confusion outweighs their usefulness. - Why should the burden of additional syntax be placed on the most common scenario? Statements (or the desire for statement-like behavior) tend to be far more common than lone expressions. Why not require lone expressions to be specially marked, rather than statements? - Do the benefits of this approach outweigh its costs? Is elegance a desirable trait, and what is its importance relative to other values, such as clarity (how accurately and easily is the writer's intention conveyed to readers) and user experience (what is the potential for this syntax to be forgotten or misused).

Personally, I much prefer the design Go uses (where semicolons are implicitly added at the end of newlines following an identifier, numeric or string literal, keyword, or operator).

I like semicolons, because it lets me use the brackets style I prefer (allman) instead of whatever the language devs think I should use. This is a really big issue for me trying to use Go, as they automatically insert a semicolon to the end of every line that doesn't end with a {, so the language forces you to use K&R, which I really dislike reading

That's not really true though, I've used golang for years and never had semicolons added automatically.

I don't mean it actually adds them to the file itself, its like it adds virtual ones during compilation. Try placing the { from the func main() { on a new line and it will fail to compile

Oh, I see, that's what you meant. Thanks for clarifying :)

The Go compiler inserts semi-colons. https://go.dev/ref/spec#Semicolons

If you follow those rules, you will see that this:

  if true;
  {
      fmt.Println()
  }
  else
  {
      fmt.Println()
  }

Will get rewritten to:

  if true;
  {
      fmt.Println();
  };
  else;
  {
      fmt.Println();
  };

And that won't work. That's why the braces need to be as "} else {". and "if .. {".

It used to be that the compiler gave some pretty confusing errors about semi-colons on this, but it seems that's been improved now.

JavaScript has similar semi-colon insertion by the way, but with some different (more confusing) rules.

That's really neat, it had escaped me till now. Thanks for the explanation (today I'm one of the lucky 10,000!)

In general, what helps parsers for disambiguation also tends to help human readers for disambiguation. In addition, some amount of redundancy helps to prevent errors when (for example) two statements were intended but they are parsed as one, or vice versa. Furthermore, consistency helps avoid errors, such as always ending a statement with a semicolon and not only when it would otherwise be ambiguous.

Non-human-readable primary representation may be not the best idea though. Would create a lot of friction when trying to process the data. Text is largely simple and obvious (yes I know there are complications but in 99% of cases you can ignore them without too much trouble) but DBs and ASTs are not. People read texts, but they can't read ASTs, at least not without assistance. So it'd be hard to use.

> Non-human-readable primary representation may be not the best idea though.

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.

> Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need.

I would argue that S-Expressions turned out to be extremely practical for developing Lisp software. A layer with different syntax makes it more complex to use.

> Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today.

Maybe, maybe not. People have discussed it endlessly, but there is no conclusion.

Currently some people in the Racket community try to make Racket more "popular" (widely used, ...) by providing a new syntax.

Not just practical, S-Expressions are a big part of Lisp's superpowers from a UI perspective. You can manipulate code as forms, not text. It's hard to overstate how much of an advantage that brings to a well-configured editor.

When you start thinking of your program as a nested data structure instead of a text document, you start thinking more clearly - you can manipulate this tree representation directly. This makes molding your program significantly faster, closer to the speed of thought. Wholesale refactoring a function might only take a dozen keystrokes to move the forms (not the chars) around.

I have a hard time going back to the syntactic busywork of manually placing ascii characters like a caveman.

S-exp is an interesting idea. Technically they are human readable, and certainly would be processable by text tools, with some effort. Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start, or it will just become a binary dump with extra steps instead. Definitely would be interesting for somebody to try.

> Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start

But lisp did not aim for that from the start, as the GP hinted McCarthy intended S-expressions as a data description form, m-expressions were supposed to be the executable language.

It’s all still bytes under the hood, albeit standard bytes. Personally I’ve not found the ability to open my css files in Word beneficial!

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.

> Personally I’ve not found the ability to open my css files in Word beneficial!

Imagine writing a blog about your favorite CSS features. I mean, if you use Word at all for writing, wouldn't that come handy?

But Word actually is not the primary goal here. grep or awk may be more important - I've created ad-hoc tools for ad-hoc quick-and-dirty tasks on code a number of times, and the fact that code is just text helped a lot. Taking that away would make me spend time on figuring out how to hook up text tools to that format.

> Many editors are already altering what is stored on disc before presenting it to you

True, but the difference is between being able to enrich commonly understood format, and not having a common format between different tools at all.

Yeah, I was definitely kidding when I was referring to Word.

I do feel sad that we're still restricted to tools like grep and awk that treat everything as dumb text, and I think it holds us back hugely. I much prefer the powershell model of everything is an object. You can easily extend it with C#.

I appreciate that the unix philosophy has gotten us to incredible places, but I do wish we could rip off some of the training wheels and take advantage of the computing power that we have available to us that was just unthinkable. My mobile phone is more powerful than could possibly have been imagined when we make restricted itself to tab as a delimiter, and I'm currently using it as a coaster to save my table from water marks.

The problem of powershell model it's a closed system. If it does X, it's awesome. If it doesn't X, but there's a tool that does X and doesn't speak the same language powershell speaks - you are out of luck. That's where simple exchange formats win - they can combine tools from different domains. If I have a system that can do X using SuperDuperObjectProtocol and then another one doing Y which uses EvenBetterDifferentObjectProtocol - doing X+Y is a project that could take months if not years. If they both input and output some common easy format - like text or JSON or CSV - I can likely hooks them up in a lazy afternoon. It's not the question of processing power - all the super-comupters in the world would not make the task of hooking up SuperDuperObjectProtocol with EvenBetterDifferentObjectProtocol easier. It's the question of complexity, which always appears on the edges of domains.

I think that falling back to the lowest common denominator is an immense cause of complexity in software, and holds us back back. I think we'd be much better off if we didn't optimise for "person who wants to write a CLI in haskell who is using an 18 year old version of bash that only runs on Plan9"

So much opportunity for anti-competitive behaviour. The "canonical representation" of C# could just be a memory dump of Visual Studio. Your code is held hostage forever. Everything you create belongs to Microsoft. You have to drink a verification can to keep using your IDE. Basically Unity/Adobe/etc, but for code. No thanks.

https://github.com/dotnet/dotnet there, the entire source code of runtime, sdk, roslyn, etc.

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

You do realize I'm talking about the OP's alternative reality, not ours?

It's HN, so the sarcasm above is often expressed seriously, as unfortunate as it is. You are right, of course.

You just described a literal nightmare D:

Maybe no longer true today, but with the right tools, C# and VB.NET used to be auto translatable from each other and IL can be decompiled to either.

It was only ever true for "clr safe" code, or a subset of C#. In particular, since VB.NET didn't/doesn't have unsigned types, not all C# could be expressed in VB.NET, even after decompiling from IL. (Not sure what happens if you try and decompile to VB.NET code that uses unsigned, for example).

Seems like the biggest downside would be that sharing code becomes much harder. Currently it is easy to share code in as small of a portion as you'd like. If the canonical representation is an AST, it opens up a lot of problems around sharing pieces of a program. This seems like a very substantial downside.

Even simply "sharing" within your own systems, like copying blocks into notes or another program, would be a lot harder. Maybe I'm not knowledgeable enough here and this wouldn't be as thorny as it seems.

Also, I really don't want to have to load any and all code into a local editor just to view it and reason about it.

You can (sort of) do all of that with the Eclipse Modeling Framework[0].

Your AST is what EMF calls a "model". By default the "backend" and ecosystem surrounding EMF is skewed towards Java for historical reasons, but there have been some prototypes with other languages as well. You can serialize your AST in any way you like, although by default it relies on XMI files. You can implement your own textual concrete syntax, or rely on a database. The EMF ecosystem has tools for implementing textual or "graphical" concrete syntaxes. You can combine them (e.g. usually a specific subset of your AST gets edited in a certain way that's best for your targetted end users). The ecosystem also has tools for performing comparisons and plugging them into your editing means.

Of course all of this tooling requires a lot more work than an LSP server.

[0]: https://eclipse.dev/modeling/emf/

I believe, this was an idea in ALGOL, not sure which iteration.

I think, the reason it was never implemented was that more translation = more complicated debugging. It also means that programmers have a more distorted and incomplete model of the program they are writing, i.e. more bugs.

NB. Lisp, as originally envisioned by McCarthy, had one more translation layer (the translated version had square brackets instead of the parenthesis), but it didn't take off for, basically, the same reason.

So... while I understand the benefits you see from doing what you suggest, I think that at the same time the downside makes this not worth pursuing.

In the .NET universe, you can mechanically convert between C# and VisualBasic. This is more or less done by going through CIL ( Common Intermediate Language - .NET assembly essentially ). So, it is more or less what you are saying.

.NET decompilers are common. I have built a few toy languages and compilers on .NET. For one of them, I could decompile CIL into my language. So, I could view .NET libraries from other sources in my language.

I think this is essentially the same idea you are proposing.

It only works if the languages are similar though. Going between F# and C# does not always work as well for example.

> you could configure the syntax however you wanted. And sure, it would be persisted to disk in some canonical representation, maybe text, maybe a DB ... but you'd never need to worry about it, because all your tooling (VCS, diffs, refactoring tools, etc) would work with the AST, and you'd never need to worry about tabs or spaces ever again.

You are describing an entire industry of IDE Smell with an IDE monoculture.

Programs are tightly coupled to textual representations because a compiler is a textual representation transformer. If you deviate from the accepted textual form then the compiler is generally clueless to do anything - that is, it can’t read your intent.

That actually exists for C. It's pretty neat.

https://en.wikipedia.org/wiki/Indent_(Unix)

First we gotta solve the tabs/spaces dilemma, maybe then we can start to tackle the rest.

Edit: I do agree and find your AST suggestion profound though!

There are tabs people and there are infidels

I was ready to throw some vitriol into your heretical comment and then I remembered I am also a tab person. Nothing to see here, sorry!

I mean my original comment was highlighting that it’s unsolved and it instantly started infighting so I think my point has been proven

People should recognize that tabs vs. spaces is more a question of editing (e.g.: What happens when you press Backspace behind an indentation? Does the caret move at uniform speed on key repeat or does it suddenly jump in places?) than of stored representation. You could even have an editor/viewer that lets you choose the display-width of spaces at the start of lines.

Do tab users not realise they could configure their editor to auto-indent and delete multiple characters so they could move to the most superior spaces format?

I don’t know of an editor who can fully emulate Tab behavior using a spaces representation (and vice versa), but it would certainly be possible.

This is what Unison is supposed to do. As far as I know there is currently only one (Haskell-like) textual representation, but the program is stored in a binary representation of the AST, and once you've entered your code, it's all operations on that AST from then on, and adding different frontends should be not difficult.

Code is linked to textual representations because code... is text? The entire point is that there are algorithms to go from "print()" to something that actually makes the computer work. How else could it even possibly work?

I think we don't have any sort of flexible AST sort of thing because they're mostly not necessary. The hard problems of programming don't usually have much to do with syntax.

And if you're going to downvote, kindly explain why, thanks. I just want to know exactly how this thing is supposed to work...

The parent’s post describes how it could work.

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.

You could always have an AST node to encapsulate the invalid code. Of course any affected code would be stuck in the source format it was written in until it was fixed.

> code... is text

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.

Code is as much Text as Vector graphics is Text.

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...

Thanks to LLMs, we are quite close to achieving this. I can write code in Python (sometimes even plain english), and GPT can convert it to Go or even Haskell if I like. The conversion is accurate 95% of the time on the first attempt in my use cases, and I expect this to improve further with more powerful models in the near future.

I can confirm that it is a suitable use case for GPTs. I do GPT-assisted programming language design and experimentation. In some cases, GPT-4 can even generate a basic interpreter that allows me to test my new language.

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)

This code is incorrect though, as it doesn't account for braces in strings and comments. There are other issues too, but that is the big one.

> This code is incorrect though, as it doesn't account for ...

Isn't this the fundamental problem with code generated by a statistical text generation algorithm?

In other words, "code" is short for encoding a solution. And to have a solution to encode is to understand the problem to solve.

Without understanding, statistical code generation is little more than a popularity contest.

The model doesn't "understand" anything, but if you, the programmer, understands it well enough, that can be enough to direct it to find a solution.

You can do a lot with ChatGPT or Claude if wrong code is easy to spot (which will obviously depend on what you're working on). If you can easily spot mistakes these things can often come up with a fix once you point it out. I've had some real success converting small-scale production C++ code into Python using Claude. Stuff that isn't really deep or complicated, but it's still faster and less annoying using an LLM to assist. I am sure there are large domains where it's crap, but for relatively simple stuff (CRUD logic, simple file parsing) it does remarkably well.

> The model doesn't "understand" anything, but if you, the programmer, understands it well enough, that can be enough to direct it to find a solution.

This is exactly my point.

Whether a programmer uses past experience exclusively to author source code or a statistical code generator (LLM) and then their learned ability is orthogonal to my original premise.

  Without understanding, statistical code generation is
  little more than a popularity contest.

I disagree with everything you said.

Code is not short for encoding a solution. Code is any kind of program whether correct or not.

You can have a solution without understanding it. You can for instance know the rough shape a solution should have and try to guess at the details. And get it correct some of the time.

And current models do have some form of understanding, although it is sometimes incomplete. They are clearly able to solve many problems after all.

Just this morning I asked GPT-4o to write some code for me. And the code was correct, except for one stupid mistake GPT-4o made which caused a compilation error. I just fixed that myself, but I think it is likely if I gave GPT-4o the error message it could have fixed it too. And I was thinking if I set up a chain-of-thought agent with function-calling, GPT-4o probably could have discovered and fixed the compilation error itself without my involvement. Provide it with unit tests it may even get the code to pass the tests (even if it takes a few iterations)-which could address issues like the braces in strings and comments issue you mention, assuming the unit tests cover them. And if they don’t-if you notice an issue via code inspection or exploratory testing, GPT-4o (in my experience) often does a decent job of “here is the code and here is a description of the bug, modify the code to fix it”. Of course, sometimes chain-of-thought agents get stuck and fail to progress, but something that quickly gives you the right answer 80% of the time can be a big productivity boost.

In my case earlier today, it helped that it was a relatively simple function and I gave it a rather detailed natural language spec of what I wanted it to do. I totally could have written it all myself, but writing a natural language spec and getting GPT-4o to translate it to code is (depending on my mood) less mental effort than just writing the code directly.

You can take it a step further, LLMs can already "execute" arbitrary non-existent languages, with non-existent data. Here are a couple of examples using a tool I wrote[1]:

    % 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

For what it's worth, the tool isn't specialized for this, 'imagine' is just one of many prompts it can execute.

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 hope we never work together. 95% accurate will cause problems that you won’t notice when you inevitably get lazy.

This is how I feel about cars that can drive themselves 99.9% of the time. The remaining 0.1%, the most difficult of corner cases, are to be handled by the human who has no experience driving even in good conditions.

I'm a strong advocate for writing tests first, maintaining a robust QA process, and ensuring all merge requests undergo peer review. Since I started using GPT-4 for coding, the quality of my merge requests has remained the same. The difference is that I can now produce about twice as many merge requests, as GPT-4 handles the boilerplate writing, Stack Overflow searches and helps to start get going in case of a mental blockade or missing idea.

By what metric do you measure quality? Plenty of gpt users were dumping low qualify contributions prior to gpt, now their contributions are the same idiotic trash but appear more competent…

I largely agree, but I don't think the current experience is the right one.

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").

Reply on news.ycombinator.com