https://hirrolot.github.io/posts/why-static-languages-suffer-from-complexity
Is it applicable to Nim? I mean the last part implements print/echo
If you look at the hacker news thread on this article, Nim is mentioned a few times: https://news.ycombinator.com/item?id=29996240
Static languages enforce compile-time checks; this is good. But they suffer from feature biformity
I'd argue that their point is somewhat muddied in that it originally appears they're arguing about static complexity, but in reality it's uniformality in compile/run time that they want. Nim's biformity with regard to compile/run time is pretty minor in practice since we can run most of the native language in the compile time VM.
The author states that "programming languages ought to be rethought". I think Nim is a rethinking in the way the author wants, but they probably have no idea it exists.
I do agree with the central point of the article, that having compile time work done in a sub-language and/or with different syntax/semantics is a bad thing (even though it is dressed up in a "static/dynamic" context). That's one reason why I like Nim so much.
@Hlaaftana
This is so true. It seems like no one seems to know about Nim and are constantly surprised that such a language can exist! I do my bit by commenting when I can. I think this is one of Nim's final barriers to mainstream adoption - people knowing about it!
Ha, serendipity, I mentioned just this example (type safe printf) a few days ago here, in the context of macro docs.
It was an interesting article. Cool to see Idris and Zig mentioned, even though the author suggests that Zig suffers from the colored function issue in async when I'm pretty sure that one of its selling points is that it doesn't.
It would have been nice to see Nim in there too, but someone high up in Nim command needs to turn off the cloaking device so we can be seen.
I had a small discussion with author of the initial article. He said that he would be interesting in static proc solution, not templates. because via macros and templates it is possible to check it even in rust.
I was trying to implement it, but I suppose that blocker is the issue: https://github.com/nim-lang/Nim/issues/1083
Doing it without macros is not a reasonable request, I added macros to Nim for a reason, they enable the otherwise impossible. So what if Rusts years later also has added macros and did it worse than Nim. So study the topics you blog about. Study Nim's macro system. And Haxe's. And Scala's. And Julia's. And Elixir's.
Maybe some of these systems allow for more than just compile-time printf implementations. Maybe any other mechanism that is equally powerful in its code introspection and code generation capabilities ends up being isomorphic to a macro system...
It was an interesting article. Cool to see Idris and Zig mentioned, even though the author suggests that Zig suffers from the colored function issue in async when I'm pretty sure that one of its selling points is that it doesn't.
Zig allows end-user to switch all async function to be one flavor or the other. But you can't choose to mix some one flavor and some the other. That's actually something we should explain about the GCs ...
not template or macros. because via macros and templates it is possible to check it even in rust.
What a peculiar perspective. Why is he 'banning' macros and templates if these make it possible in Rust? Is this code golf?
Rust's macros, as @Araq states, are just worse. There's a reason they have to be annotated with !. Oh no, we got ourselves a macro here! They're deliberately made to stand out as an anomaly in the language and treated like some kind of magic.
The central thrust of the article was about biformity between compile time and run time, and Rust is an exemplar of this: declarative substitution macros and painful procedural macros that don't use the native AST but a token stream derivation. Oh and macros have to be published to a separate crate to be used... for some reason.
With all this special casing it's no wonder the author brings up biformity.
Incidentally, Rust only got format strings last week. Nim has had them for years.
The author needs to study the topics he blogs about
At least the author reflects on this in the HN comments: "maybe I'm naive". Not to dismiss the author entirely, it was an intersting article, but the conclusion was strongly asserted based on partial knowledge.
So, within the case statement CTRL+K, CTRL+[ is hopefully close enough to what you want.
The rainbow tabs extension is also nice for Nim with VSCode.
I dislike the "static" word, it's too vague. Would be better to call it "typed vs untyped".
They say using typed vs untyped language. Is like free shape sculpting vs using bricks.
There are place for both. Each way has advantages and disadvantages.
I like free shapeless way for small experiments, thinking without restriction building prototypes, moving fast.
And use stricter, typed approach when building something larger, or working with team, defining interfaces, building reliable systems.
I dislike the "static" word, it's too vague. Would be better to call it "typed vs untyped".
That would be completely unhelpful. static means that type checks are performed before the program is run, dynamic means the checks are performed during execution. To make that clearer, in a hypothetical compiled Python (or JS or whatever) a line with a type error will only reveal that error if the code path is executed. In an interpreted (but still statically typed) Nim, that line could never be executed because the type checker rejects the program containing it.
Also, dynamically typed languages are not untyped. Julia is dynamic and has a rich type system, including parametric types.
@bpr is right. Calling pre-run-time things "static" is an ancient tradition. (Just web search, for example: static analysis).
I do think the less abbreviated "statically typed" is more clear in this context and using two words not much burden. Consistent use of that term might please @alexeypetrushin... but good luck getting people to never abbreviate. Lol. :-)
@xigoi - as I've mentioned before when this came up, it is not hard to adapt vim-like '%' paren/brace/bracket matching to indent blocks to navigate "down/forward". However, back/upward is tricky because a large set of things terminate at a single end-of-line. It's the equivalent of all the Lisp closing parens piled up and reduced to nothing. :-)
In a vim context the user could probably provide a numeric prefix like "3b" to go back/up/out three levels (assuming whatever back/up is bound to 'b').
Also, to really be analogous with the bracket matcher/warper you would want to warp to the ':' or '='. This is tricky because you could have, e.g.:
proc foo(a=1, # a: some parameter
b=2 # some other parameter
): int = # ensure a!=b and #[ nested :also= works ]#
some:
notImplausible:
nested:
stuff()
@xigoi & I were discussing some ideas along those lines in navigating/selecting in indent based languages..A step beyond just "graphing paper"-esque "indent-area grids" like Moe in Nim or folding.
The idea is to move around said indent grid in its "natural strides". It seems obvious enough that it ought to be present in someone's source code editor of choice. I didn't find one. Maybe someone here knows one?
i skimmed.
static things are just going to be more complicated because they are trying to include all these forms of proof checking and it can be incredibly cumbersome to communicate to the type system what should be allowed.
but
nowadays i tend to think a cooperative compiler is wiser. basically treat the compiler as a runtime like lisp does where you run code in a notebook style. send stuff to be compiled to native code through the API and get back the compiled blobs which is what Terra/Lua does and Red was hoping to do. this basically turns the compiler/linker in to a scripting system where you're free to swap around type checkers or whatever instead of trying to make some massive static type engine that is trying to be compatible with everything at once (and becomes incomprehensibly complex and slow in the process.)