> First of all, he states that not having such an indentation-based syntax
> allows for more freedom ...
He is right in that but only in one regard: Having explicit block markers (like
{ and } or `begin` and `end`) allows for (visually largely unstructured)
"streams" of code. If that were really, really needed, one could however
introduce a "3 spaces" symbol, say '°'.
It might be noteworthy that quite some studies, typically made in the context
of some entity seriously needing that question answered, have clearly shown
that readability _is_ important, in fact _very_ important. While I know of no
study addressing indentation based blocks vs marker based blocks it seems
reasonable to assume that both are clearly on the good side (remember: The
issue is (only) readability). The studies that were made all and consistently
demonstrated that "curly blocks" are clearly the worst approach (~ worst
readability) and introduce significantly more errors and are significantly
worse to maintain.
> First of all, he really dislikes the lack of brackets, and the "misuse" of
> them
I would (mildly) agree. It _does_ make sense to have `[]` meaning "something
array like" always (although I personally and subjectively - and unreasonably -
prefer [] over <>). More importantly however I reject your friends criticism
because It's basically just based on "it's not c# like and hence it's bad!".
That's, Pardon me, just stupid.
> Next up, an "invalid" argument. He says macros are dumb, and you could just
> write code normally without them.
Very wrong. Obviously your friend, like so many in the curly braces camp, fails
to understand the concept of readability which is closely linked to
maintainability and probability of errors. Probably your friend has become a
victim of the (utterly stupid) "fun" paradigm (Typical statements are "It's fun
to develop in XYZ" or "I'm a developer because it's fun") - that camp has been
found to be responsible to a very large degree for the major clusterf_ck we're
in today (e.g. funny bug of the month in SSL).
They are, Pardon my french, braindead morons. Here is the truth and the only
one in that regard: software development is an _engineering_ discipline - and a
very complex one at that. If the "fun" camp guys were also in bridge building,
railroads, air traffic etc. humanity probably would be largely extinguished by
now (the survivors living deep in the woods, far away from killing
"civilization" with tech).
Just like with bridges or railroads the relevant factor is absolutely _not_
whether those who designed and built it felt it was "fun" to do but whether the
result was reliable, meeting the needs, etc.
Macros not only allow for comfort but more importantly they allow for
"centralized code fragments". And that is directly linked to probability of
error as well as to maintainability. Just have a look at crypto code; you'll
almost invariably find (long) macros. Often the very core of an algorithm is
implemented in one or more macros. And I think even your friend would accept
that the people who gave us AES or Blake2 certainly aren't stupid.
Whenever some halfway responsible entity _really, really_ needed reliable and
bug free software they turned to languages like Ada, Eiffel, Ocaml, etc. (along
with _formal_ spec., modelling, and verification) as soon as and when such
options were available. Hell, even Pascal was used because it might not have
been a "nice" language but it offered many of the features high reliability
scenarios required.
So, to summarize it somewhat rudely: why would you even care about the opinion
of someone who doesn't have even the slightest clue what he talking about? You
are like some engineer debating with an idiot whose arguments basically are "my
(make shifted wannabe) crap is "cool" and "fun" while your (properly working
and reliable) bridges and railroad systems are boring and uncool!.
Btw, I myself am not at all against .Net (any more). For one it incl. Mono
(nowadays) offers reasonably good and wide linux support, too and isn't a pure
Windows world thingie any more. More importantly though, Microsoft (funnily
unknown to many) has invested tons and tons of money in safety, reliability,
and security research and has really done a lot of work and has created much
progress in that field. Just think of Z3 ( _the_ solver), Boogie (an "easy"
interface language for Z3), code contracts (i.a. for c#!), Dafny (a safety
targeting language that actually works) and more. With their async/await work
they have tried to make .Net also useable for servers but although they seem to
have done it well I personally and subjectively limit my .Net use for business
applications.
Well noted this comes from someone whose first (and then beloved) language was
C (and, I have to admit it, then I also was a "coolness" obsessed idiot) and
who taught C. In fact I still sometimes implement certain tricky things in C
because Nim does not (yet!) compare in some corners. I'll spare the long wound
odyssey over two decades in my quest to find a language that meets my (quite
complex) set of criteria like multiplatform, good readability and
maintainability, seriously strong static typing (plus the compiler Cerberus
like watching over it), async, multithreading, and quite some more. During that
journey I was desperate enough to try Modula3 ("modern Pascal"), Pascal itself,
Ada, Eiffel, Felix and had a serious look at quite some more (e.g. Zig, E,
Sather) - and all of them left something (of importance to me) to desire.
I would certainly _not_ think or say that someone not using Nim is an idiot.
Maybe he doesn't know or grok it (it's quite different things to have a look at
a language and maybe watch some videos -or- to seriously at least begin to
understand a language), maybe his needs are different (e.g. Windows
applications only), maybe he is used to excellent tool support, ... but I would
certainly call it sheer idiocy to go against Nim based on hardly more than
"It's not c#!".
Happy new year to everyone.
