Comment by wiremine | Hacker News Reader

Comment by wiremine | Hacker News Reader

I learned Nim last year by rewriting some of the core Arduino functionality in C, and then wrapping them in Nim. (I also wanted to better learn C and better understand how Arduino's internals work, thus the convoluted approach)

A few observations:

* The community was very helpful and responsive. I identified a bug in compiling Nim to bare metal C, and it was fixed in 24 hours.

* The C/Nim bindings were a breeze to use, even for a relatively novice C programmer like myself.

* The language is fairly sparse, in a good way. It feels a bit like Go in that regard, but with better metaprogramming support.

* I personally like meaningful, Python-style whitespace, but I could see how that could be a turnoff. But I'd hope people can look beyond that and give the language a try.

* I could _actually_ use Nim to write code for an Arduino Uno, so the project was a success. The firmware sizes weren't that bad, either, which was my biggest concern. Nim's memory management is very flexible, and the ARC system seemed to work great without the need for GC. [1]

[1] https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

I have decided that meaningful whitespace is an anachronism.

20 years ago, I liked it a lot.

Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented. Which means that, assuming I am using an autoformatter, it creates one more thing that I have to do manually, because the editor can't accurately do it for me. And, since the whitespace is significant, it ends up being one more potential source of bugs.

I also don't love love love that (at least with the keys I know well) significant whitespace is more awkward to edit with vanilla vim than curly braces and parens are.

Some counterpoints:

Your auto formatter can’t figure out where you missed braces either.

Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs.

Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <.

A botched merge conflict resolution can repeat a block statement just fine, it will have the same effect. And repeating a statement inside a block isn't necessarily better.

Practically speaking, it’s almost impossible to miss braces. If you’re copying and pasting, you can place your cursor anywhere inside the desired pair of braces, paste, and the autoformatter will figure it out.

Ideally an autoformatter would also add braces around a one-line if statement as well.

it is very possible... I often paste parts of some code into a lambda and missing a brace here and there.

>Your auto formatter can’t figure out where you missed braces either.

I mean, it kinda does? You get a result that's wrongly indented if you miss a brace.

well yeah, then what? where would the missing brace be? you can't really tell since now the formatter clobbered your indentation, unless you remember, of course

When this happens to me with `cargo fmt` I don’t need to remember, I can just revert the formatting changes using undo in Emacs.

> Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs.

This is why, in languages where they are optional, a good autoformatter will automatically insert them. If you've got it set to run every time you save the file or run tests, it's likely to do so long before you have a chance to produce the next Heartbleed.

It's not perfect, of course, but it's as good a protection against this sort of thing as I've ever seen.

> Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <.

But, excluding plugins (which aren't available/consistent across all the editors where I use a vim editing mode), I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. Or quickly jump to the beginning or end of the current scope. Stuff like that. Versus, with curly brace languages, vanilla vim gives me an experience that approaches the ease of paredit.

> I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language.

I'm sure there are better ways, but you could v9G$ to select from the current line to the end of line nine. Or v9j select the next nine lines, v9k previous nine, etc.

But compare the ergonomics of:

  1. yi{

To:

  1. Find line number of start of scope.
  2. Decide on easiest way to get there, and either:
     - kk
     - 5k
     - 37G
  3. Find the end of the scope. 
  4. Decide how to grab it. Then:
     - y9G$
     - y3j
     - V, jjj, y

I hope maybe I've made my case that it's more awkward, right? That is not to say that I don't know how to do it. It's just that, in the one case, I can do the job in one thoughtless action that lives so deeply in my muscle memory that I barely even consciously remember what the actual keystrokes involved are. By contrast, in the other, it takes several steps, some of which are likely to be small pauses to decide how to do the next step.

You're both just making the case that you shouldn't use vim to write code.

More modern editors (e.g. VS Code) and modern IDE's (e.g. IDEA, CLion, Visual Studio) make either indenting absolutely trivial.

I think you may have misunderstood?

My main editor is IDEA, followed by vscode and emacs. But all three are set to vim mode. Vim itself has actually never been my primary editor; I generally only use it when I'm sshed into servers.

The thing that vim mode gets me is twofold: It (mostly) unifies the editing interface among all of those editors, and it allows me to edit code more quickly.

The thing I was talking about above is not indenting - my autoformatter does that for me. The thing I was talking about is (a sort of hacky version of) syntactically aware editing that allows me to quickly do large-scale operations without having to explicitly fiddle with the cursor.

You took the words right out of my mouth. I'm in the exact same boat. I use more than one editor but I always install the vim plugin. It provides an instant speed boost to using that editor efficiently and quickly. We don't switch editors _that_ often, but at the same time, remember trying to remember keyboard shortcuts for TextMate, then Sublime Text, the VSCode, then IDEA, etc.? With the vim plugins, editing text is now the same across all editors.

I think that by installing vim on all your editors, you are missing out on a lot of productivity.

You are basically giving precedence to text edition over code edition. When you use an IDE, you are editing code, not text, and that IDE's key bindings are optimized for that purpose.

I suggest you take the time to learn native key bindings to whatever tool you picked and see where that gets you, you'll be surprised after a few weeks.

I'd you're using Neovim, you can also make use of Tree-Sitter to navigate across the parsed syntax tree. There are many plugins to do that, e.g.

https://github.com/nvim-treesitter/nvim-treesitter-textobjec...

or

https://github.com/David-Kunz/treesitter-unit

(The latter is created by me)

Or you could use Neovim with Treesitter for selections that use the language grammars.

https://github.com/nvim-treesitter/nvim-treesitter#increment...

Unless you are a beginner, the "decide on easiest way to get there" shouldn't exist. It should be muscle memory.

> Your auto formatter can’t figure out where you missed braces either.

Correct, but I will notice the braces are wrong when the auto-formatter indents things differently than I expect.

And I'll notice the indentation is wrong when the indentation is different than I expect.

How does significant whitespace save you from bugs?

    if expr:
        doA()
        doB()

Is doB at the correct level?

Having text that's invisible change the flow of your program is crazy IMO.

I don't care that much in my own side projects but when working with others and resolving merge conflicts your example is my nightmare. It's so much easier to have brackets denote scope as you don't have to get the indentation right when actually resolving merge conflicts. It's easy to fix it up afterwards by automatic indentation in the editor.

Significant white space is a mistake IMHO :-)

The bugs being referred to are from optional brackets in C:

    void foo() {
        ...
        if (expr)
            doA();
            doB();
        ...
    }

which is unambiguous to the compiler, but could (and I expect would, especially when glancing through a lot of code) cause misinterpretation by a human reader. We can more easily hallucinate the brackets than the indentation.

I disagree with the idea that indentation spaces are invisible; rather they are much more visible than a pair of brackets. This actually becomes a problem when you embed/indent too much and 70% of the line is spaces. It's all you see!

Yes, but pretty much every coding standard I've seen mandates the use of braces always. You do it without even thinking. Your example wouldn't pass code review.

    if (expr) {
        doA()
        doB()
    }

Is doB at the correct level? It's the same thing.

I get what you say, and agree with you that autoformatter+braces are a cool thing. Problem with that is a lot of people don't use any formatter: not an autoformatter, not a format guide. They just "know" what is best, which usually end up in horrifying (R in my field) code. Sometimes they even feel _smart_ when chaining call after call after call to pull off some kind of one-liner with the help of braces, pipes and semicolons, and then twit the monstrosity with great pride.

Python, and others, had the wisdom to put a corset on those people with whitespace and indentation.

> Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented

This is precisely why I prefer significant space: it forces you to write tidy code. Sloppily written code that depends on the autoformatter to be properly indented makes me suspect the logic could be sloppily written too.

Besides, any humble plain text editor understands autoindenting, so there's no sensible reason to not indent properly.

I don't personally run into either of these issues at all working with Elm code (significant whitespace language) in vim.

Having your indentation wrong is basically the same as ending your parens in the wrong place isn't it? Not sure an autoformatter can fix it if you throw a close bracket in before you should?

For formatting, elm-format is opinionated (I don't love the 4 space indentation though) and pretty much everyone uses it. No issues with indentation that I can recall. Not sure if nim has it's own formatter (I haven't played w/ nim in a few years), but I believe python does?

The biggest win of significant whitespace to me is readability. Subjective of course, but I just find it easier to read and less noisy than C / JS syntax. Probably about the same effort to write. I also like bracket soup lisp languages though (w/ rainbow parens) so maybe I'm just weird. /shrug

If I don't add a brace, I'll get an immediate error that something doesn't add up.

If I mess up indentation, the program will carry on as if nothing had happened.

This is not really true in practice. It is the same thing as accidentally moving a line across a brace in a brace-delimited language.

The incorrectly-indented line will generally blow up at runtime or fail to compile, because it's in the wrong scope.

If you misplace a brace (which is the true equivalent of messing up indentation), the program will also carry on.

Definitely some subjectivity to this question, but I'm the opposite: to me the curly braces are the anachronism, a relic of a time when the programmer had to do lots of extra stuff to help the language parser/compiler.

For awhile it was awkward because it was up to the programmer to keep the redundant block delimiters in sync - the braces (for the computer) and the whitespace (for the human). The fact that modern editors and IDEs for those languages now do the housekeeping on behalf of the human is great, but it seems odd that it's needed at all, and it always feels especially cumbersome when returning to those languages that still require it if I've been away for awhile.

Oh it definitely can run on those devices! I wrote my own keyboard firmware from scratch in Nim, and the firmware sizes are vanishingly small compared to even simple "hello world" level stuff in Arduino. I did a talk on it for NimConf2021: https://www.youtube.com/watch?v=dcHEhO4J29U

This is great!

I've wondered if Nim could be the foundation for a sort of "next-generation" Arduino. It's easy to learn, compiles to small binaries, and can wrap a ton of existing C code.

My experiments taught me wrapping Arduino from scratch, while possible, might not be ideal. There's some cruft in that code base, and the abstractions could use some updating.

There is definitely room for this, it just needs somebody passionate enough to write a nice Arduino/embedded framework and document/promote it well.

Yes, yes Nim could be. Actually I’ve been working on that idea for a while now. I’ve been working on getting an Embedded Nim project going on GitHub. Come stop by! Also some discussions on Nim forum: https://forum.nim-lang.org/t/7731#49050

PS I’m wrapping Zephyr as a basis, but working on better Nim abstractions on top.

Reply on news.ycombinator.com