Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.6

nim-lang.org

Post reply on HN
Print view View original

141–150 of 179 posts

Re: Nim 1.6

#141

Post by clusterfish »

dunefox wrote: post #47
clusterfish wrote: post #39

Earlier quoted context omitted.

Of course it is. It's descriptive and searchable. Because * / - + is the common ground that essentially everyone is familiar with. And that's about as much math notation as makes sense in general purpose programming languages. There is only one math but many programming languages. Multiplication is universal and fundamental. Creating JSON objects in nim is the opposite of that.

> Of course it is. It's descriptive and searchable. If I entered "nim json" into google I'd get thousands of results for the language and json in general, and no way to narrow it down to meaning the operator "JON". That's not really what searchable means.

> no way to narrow it down to meaning the operator

My google insider tells me you can add the word "operator" to your query to do that. Or any other similar word like "keyword" that anyone else thought to call it on stack overflow.

Re: Nim 1.6

#142

Post by feffe »

secondcoming wrote: post #132
boardwaalk wrote: post #70

Earlier quoted context omitted.

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

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 :-)

Re: Nim 1.6

#143

Post by davidkunz »

mumblemumble wrote: post #104
hadem wrote: post #100

Earlier quoted context omitted.

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

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)

Re: Nim 1.6

#144

Post by akubera »

secondcoming wrote: post #132
boardwaalk wrote: post #70

Earlier quoted context omitted.

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

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.

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!

Re: Nim 1.6

#145

Post by motomoto »

mumblemumble wrote: post #104
hadem wrote: post #100

Earlier quoted context omitted.

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

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

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

Re: Nim 1.6

#146

Post by secondcoming »

akubera wrote: post #144
secondcoming wrote: post #132

Earlier quoted context omitted.

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.

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

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.

Re: Nim 1.6

#147

Post by fanf2 »

aEverr wrote: post #90
ImprobableTruth wrote: post #85

Earlier quoted context omitted.

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

Re: Nim 1.6

#148

Post by timotheecour »

andybak wrote: post #8
zoidb wrote: post #5

Earlier quoted context omitted.

I have written a bit of both, recently re-wrote a command runner for a side-project https://gitlab.com/jarv/cmdchallenge in Nim and found it very pleasant and much less verbose, which was a nice change from GoLang while keeping type safety. A good example is parsing JSON https://nim-by-example.github.io/json/ as you can do a lot with fewer lines of code. I think the main disadvantage of Nim is that there is less out…

I really like the look of Nim but every time I dig into it I find a really strange syntax decision. For example: > The json module provides the %* operator which is used to create JSON objects I'm curious what the benefits are here of an operator over some more readable syntax. I have a dislike of languages where ascii noise seems to be favoured over readable english tokens.

Checkout the newer std/jsonutils: https://nim-lang.github.io/Nim/jsonutils.html

let a = (1.5'f32, (b: "b2", a: "a2"), 'x', @[Foo(t: true, z1: -3), nil])

let j = a.toJson

assert j.jsonTo(typeof(a)).toJson == j

Re: Nim 1.6

#149

Post by timotheecour »

Thaxll wrote: post #88
zoidb wrote: post #5

Earlier quoted context omitted.

I have written a bit of both, recently re-wrote a command runner for a side-project https://gitlab.com/jarv/cmdchallenge in Nim and found it very pleasant and much less verbose, which was a nice change from GoLang while keeping type safety. A good example is parsing JSON https://nim-by-example.github.io/json/ as you can do a lot with fewer lines of code. I think the main disadvantage of Nim is that there is less out…

That %* is really strange. Also in the example there is no notion of errors? Nim is exception based?

yes, invalid JSON would raise an exception.

Re: Nim 1.6

#150

Post by farresito »

mumblemumble wrote: post #104
hadem wrote: post #100

Earlier quoted context omitted.

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

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