Hello,
First of all, I don't want to hate on other languages, or anything. I don't have anything against other languages' syntaxes, and I'm OK with people using them. But I have a friend who has recently "turned against me" – when I started using Nim, he started being really angry (no, really, he just started saying I'm stupid, etc) that I'm not using a """"normal"""" (multiple quotes intentional) language. His main argument is Nim's syntax, even though he's never really tried to code in the language. He's pretty much a C# fanboy, he says the syntax is perfect and "it can run on many platforms" (I strongly disagree with that).
My main argument is that if he'd finally start coding in an ergonomic language like Python or Nim, he'd finally feel how easy it is to write and read code in it. What he dislikes the most, is the indentation-based syntax, and a few other "weirdnesses" you don't see in typical languages.
First of all, he states that not having such an indentation-based syntax allows for more freedom, even though he doesn't indent his code badly. I think this argument is just stupid, taking into account all of his programming practices.
But the main deal is about the syntax features themselves. I'm going to use this code sample to describe the problems he has with the syntax:
type
Box[T] = object
value: T
proc box*[T](value: T): Box[T] =
result = Box(value: value)
First of all, he really dislikes the lack of brackets, and the "misuse" of them. As I said, he's really used to C#, and thinks the generics syntax is stupid. His problem with it is the use of squared brackets [T] instead of angled brackets <T>. I thought it was a weird decision too, but later found out it didn't really clash with the rest of the language and worked really well. Pretty much all of his jokes now rely on this argument, even though it's a preference and he shouldn't hate the language just because his preferences are different.
Next up, an "invalid" argument. He says macros are dumb, and you could just write code normally without them. I sort of agree with him, but no. Macros are really useful, especially when you have to write a ton of repetitive code when you want to embed a scripting language for your application, or something similar.
His last argument is that Nim is not very popular. I left it for last, because it's not an argument – you can't judge something by how popular it is.
I tried approaching him with a quote from Araq:
Nim's target audience is the enlightened/misguided programmer who doesn't understand why there should be more than one programming language.
And yet, he keeps being stubborn about his opinion.
How can I convince him to at least stop hating the language so much, or to change his decision and try out the language?
I never seen C# outside of MS Windows and related.
Just say that indentation brackets on Nim are written like #{ and #} ;P
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.
I had a similar gang of "friends" a couple of years ago. We used to hang out on an IRC network that they ran, eventually I decided to just leave it because having them complain about Nim every time I wanted to discuss one of my projects became far too tiring.
Many of the languages they were proponents of were niche too, one example was ooc. They didn't stay loyal to these languages for long and the language's themselves were abandoned by their authors.
So yeah... you likely won't be able to get through to your friend. If possible, just ignore them.
First, I'd like to thank you for all the answers. You really gave me some good knowledge about how I could approach my friend. However, he's found another argument I really can't beat with my own knowledge. He says Nim's unreadable for programmers coming from other languages.
My main contr-argument was that you can always read the documentation; heck, the tutorial for the language is well-written and easy to understand. But he keeps bragging that he doesn't want to read any docs; he just wants to understand code in any language.
For me, that really shows his ignorance and lazyness. It's not really hard to deduce Nim's language features, some may be easier to deduce than others, but if I wouldn't know Nim and read the codebase of, for example, nimforum, as @Araq suggested, I'd at least try to understand the code using my knowledge from other languages. I probably wouldn't understand what proc` means, or ``*, or how generics are written, but by looking at more source code I'd be able to deduce what at least 2 of those 3 examples do (can you guess which is the hardest to deduce?). But the fact is, every developer is different, some may be too lazy to even look at something's source code, or too lazy to try and deduce the functions of different operators. You cannot develop software without the use of documentation, and that's what he doesn't understand and keeps bragging about.
Again, thank you for all the answers, and happy new year!
Pardon me but it seems that you should change friends rather than language.
What your friend said about Nim being incomprehensible for people who don't know Nim is simply ridiculous BS.
If I were in your place -and - for whatever weird reason - wanted to keep that friend I's simply tell him "You are right. Thanks, I've seen the light. But as I'm a weird guy I'll play a bit more with that language Nim although c# is so so much better". That should help as it would address and sooth both major factors, namely your friends cluelessness and his urgent desire to be "right". (But then, neither am I in your place nor would I hesitate a split second to tell such a moron Adios...).