It would take similar effort (in sum) to fix the few problems in the Nim std library as it takes me to fix the problems each time I run c2nim.
Do you know about --nep1 and #mangle? I used c2nim to wrap hundreds of thousands of lines of code. Yes, it's some work, but the results are really good (and Nim being CS or not would hardly change anything).
Yes, I've used #mangle before. Very helpful.
--nep1 is interesting.
My complaint -- that the C library being wrapped could have conflicting identifiers -- is a minor one. I can always find ways around that. UPPER_CASE macros are the most common collision, and that's not a big deal since c2nim works better on the pre-processed output anyway.
But there is a larger issue here. You've injected too much novelty into Nim. This is a gigantic project. You've got to concentrate on making Nim as practical as possible, on its strengths:
There are no other languages like this. It's an amazing list, for a certain class of coder.
Partial-casing is a loss of focus. It's cool and interesting, but it makes the language less practical, not more. And it's an easy target for detractors -- an easy excuse to spurn the language.
Anyway, I do see your point. With --nep1, we're actually making disparate C APIs look similar within Nim. Maybe that's a fair justification for partial-casing?
I wrote:
Anyway, I do see your point. With --nep1, we're actually making disparate C APIs look similar within Nim. Maybe that's a fair justification for partial-casing?
Rethinking, actually it seems the other way round. If we had case-sensitivity, then c2nim --nep1 could be used to make the wrapped libraries look similar.
Maybe that's a fair justification for partial-casing?
I consider it to be largely orthogonal really. But coming back to ALL_CAPS macros. They are this way because C's preprocessor doesn't know anything about C's scoping rules or C's symbol table. ALL_CAPS are an archaic hack, and wrappers shouldn't expose them, they should rename them. Copying bad design is not good design.
Partial-casing is a loss of focus.
That's arguing like the feature doesn't exist yet and I need to spend lots of time to implement it. But it already exists... Changing it now would mean more work to me.
It's cool and interesting, but it makes the language less practical, not more.
That's just your opinion. That others can and do write new_nim_node already surely makes it a practical feature for them.
And it's an easy target for detractors -- an easy excuse to spurn the language.
Sure, but excuses to not consider Nim are numerous anyway, the casing hardly makes a difference:
The last one is as logical as saying that "Rusts inherited the memory races from assembler" but it was quite successful in spurning the language, afaict.
All good points, except this one, which is a real problem:
Changing it now would mean more work to me.
Why can't someone else do it? It seems like OderWat is almost volunteering. Maybe it would be too hard. But I would love to see you say, "Hey, OderWat. Would you look into adopting full case-sensitivity? If it seems feasible, or if you come up with a workable plan (e.g. a compiler flag to preserve partial-casing, and maybe a warning for similar identifiers), would you submit a pull-request?"
In other words, delegate work to other developers. You're doing too much.
It's cool and interesting, but it makes the language less practical, not more.
That's just your opinion.
I'm in the majority, by a wide margin. And note that GoLang has a different novelty, which I think is a good idea: The source code is fully UTF8. You can include UTF8 characters in the names of your identifiers. My point is that the identifier is the identifier. For some reason, you see the "identifier" as an abstract concept, with several representations. You are very definitely in the minority.
You're probably right too, but sometimes a good idea is just too far ahead of its time.
Why can't someone else do it?
Fair enough, somebody else can do it. My work is then only to review the patch. The problem is though, that on top of the "it's work for me" argument, I don't want the feature. I don't see the point. The conflicts that do arise are all about ALLCAPS and I don't want ALLCAPS in my language to begin with, it's hard to type and hard to read.
And note that GoLang has a different novelty
Come on, that's ridiculous. Java did that decades ago. The only thing that Go does new is the Uppercasing for export feature which is completely silly since it means a rename is used to turn something private into public. (Something which happens often.) (It also means you cannot export a Chinese identifier without giving it an ascii prefix ...)
I'm in the majority, by a wide margin.
Shrug, so are the people who don't like indentation based syntax. "Designing for popularity" doesn't work for me, I don't want to design TypeScript.
Shrug, so are the people who don't like indentation based syntax. "Designing for popularity" doesn't work for me, I don't want to design TypeScript.
Hate to tell you but at some moment your going to lose control over the project. Most languages when they become big, the original developer will be overworked or have too much going on in his personal life. And then the project goes over to a committee ( or the language dies if nobody takes over the development ).
Indentation based syntax is less of a issue. Your not going to run into conflicts or have much styling issues. Its easy to alter double space to quad space over all the source code / modules. Modern IDE's make the whole indentation vs brackets look less of a issue.
The same can not be said about partial casing / altering of variable / function naming etc. That is why there is a much bigger group of people arguing that currently its problematic for specific situations. And its a much bigger hurtle for people to jump over then indentation. Do not take my word for it. Look at the reddit posting when people talk about Nim and how much the discussion becomes a sticking point when people find out about this feature.
And again Araq, NOBODY is saying: "Hey, we do not like x feature, get rid of it". Everybody is saying: "There is a issue with this feature, Lets find solutions to deal with it". Nobody is going to remove this feature but people are looking for a solution that can fix the issues without altering that feature. The fact that you can not see that this is a issue for people and development teams is more worrying Araq. People are saying there are hot coal on the floor and your answer is: do not step on it :) That is not a solution lol :) :)
@Araq
and I don't want ALLCAPS in my language
Do you know
c2nim --nep1 h.c
cat h.c h.nim
enum TrafficLightState
{
OFF,
GREEN,
YELLOW,
RED,
RED_AND_YELLOW
};
type
TrafficLightState* = enum
OFF, GREEN, YELLOW, RED, RED_AND_YELLOW
I do not like ALLCAP myself too much. But disallowing what we do not like for other people may not be a very good decision. Why not include a hidden delay of 60 seconds in the compiler when an ALLCAPS is detected? :-)
And finally -- it may be fine for lazy coding that I can write fileName and filename in the same source code for the same object, but in the long term I prefer clean, accurate code, so I will use only one of these names everywhere. Of course, it would be bad to use fileName and filename in the same scope for different objects -- compiler or other tool should give a warning.
I'm in the majority, by a wide margin.
Shrug, so are the people who don't like indentation based syntax
That's silly. Python has similar syntax, and I always tell people that Nim is Python + Ada + C. People who complain about enforced indentation should be using a more verbose language, like Rust. I don't believe that a majority in this forum would oppose indentation.
[One] thing that Go does new is the Uppercasing for export feature which is completely silly since it means a rename is used to turn something private into public.
I agree with you. However, IDE support can handle the rename, and your argument for partial-casing is future IDE support which exists precisely nowhere. Simple search-and-replace can usually handle that renaming as well. And for Nim newbies, the * is line noise, even though it's fine when you get used to it. I have no preference, but I assert that UpperCase for exported symbols was a fair decision on balance.
I don't want ALLCAPS in my language to begin with
That's fine. Ban ALLCAPS, but note that c2nim --nep1 will change l to L, which is all-caps. If this is really important (which I doubt), then let c2nim replace ALLCAPS with something else unique. I am saying that THISWORD, ThisWord and thisWord can occur in the same C library (the middle one most likely as a type) so it should be handled gracefully. If you don't like that, then remove the FFI support from Nim, in which case Nim becomes just another toy language. You are trying to have it both ways: (1) Solid FFI, and (2) novel indentifier equality.
"Designing for popularity" doesn't work for me
But in this case, it is a majority of Nim users who disagree with you, not just random coders. We are your allies, your friends, your comrades at arms. And the only reason I mentioned popularity is because I wanted to give you a way to save face. But the reality is that your position is difficult to defend today. grep is not going away, and current IDEs are not able to deal with this novelty.
I guess I can work around any problems caused by partial-casing, but honestly I would like to see this project become more community-driven. That is the biggest concern I hear from colleagues when I suggest adopting Nim.
Oh, btw, I have found another area where partial-casing is restrictive:
bar.nim:
import typetraits
proc bar*[X]() =
echo "bar:" & type(X).name
import bar as nil
when isMainModule:
bar.bar[int32]()
foo.nim(4, 10) Error: could not resolve: bar[int32]
foo.nim(4, 6) Error: expression 'bar' has no type (or is ambiguous)
I think @araq is doing a great job and him being stubborn in some cases does makes perfect sense to me. We all can be happy that he has strong opinions about stuff. Nim language design itself is not really community or committee driven. It still is his language and he decides what Nim is about. I bet that is not easy! I think the crown in the logo can be related to that ;-)
Still I would be interested in the results if we would vote for full CS instead of partial CS in Nim.
You could call this a language bug (or a feature), but I say it's evidence that this whole partial-casing idea was not considered clearly.
I'm sorry but the fact that module names fight with proc names in the same scope is entirely different issue. Sure, you can avoid it by casing the proc or the module differently, but even with CS the style guide would be 'camelCase' for modules and 'camelCase' for procs, solving nothing whatsoever.
ALLCAPS
They have a place ... I still think all caps is perfectly reasonable for constants. Variable & constants mixing makes things more difficult if they all look the same. And marking variables like cFoo, vFoo is just silly.
honestly I would like to see this project become more community-driven. That is the biggest concern I hear from colleagues when I suggest adopting Nim.
I think this is the same issue that has showed up also about the website design. There is a consensus that the current design is lacking in "professional" appearance ( still think it looks like a hobby project ). Then there is the documentation ( not really integrated, lacking examples, not really searchable, not newbie friendly ) that came up several times. And the the whole cap/underscore issue.
On this point you can tell the GoLang / Rust communities are more active. While sure, plenty of people dislike the error / cap system of Golang but it has a purpose. Its designed around that idea and you can not really improve or make it more flexible. The whole cap issue from Nim, its already flexible but it can be enhance giving everybody a solution ( unlike goLang that is stuck to this one standard ).
I am very sure, that with a descent solution for a Partial casing, that it will actually help productivity & reduce potential errors ( especially in teams! ). And yet, again ... nobody mentions removing the current Partial casing, just enhancing it.
These points are not massive deal breakers but i always get the impression when people advocate for something, Araq reacts like people step on his toes. People are putting a lot of time in discussing things and looking for solutions. But the impression is that people just need to shut up or get ignored.
About Website Design / Documentation: There is stuff in the works and it may end up being all good eventually. Thinking that the main developer can fix all of that while also working a day job is just a bit blue eyed. Nim is in fact a hobby project. Being a bit more grateful to a person which spent nearly all of his free time in building Nim couldn't be wrong.
About partial CS: I in fact would love if it gets removed. I gave a suggestion on how to handle "rules" if you want other cases (translation of imports). But it may not happen :)
BTW: I can tell you for a matter of fact that @araq thinks about all of the input from the community :)
These points are not massive deal breakers but i always get the impression when people advocate for something, Araq reacts like people step on his toes. People are putting a lot of time in discussing things and looking for solutions. But the impression is that people just need to shut up or get ignored.
Well I can hardly comment on every bad idea out there that people spend time on. For example: import module {.snake_case}. Great idea. How exactly does that help with grep though? It doesn't.
Next idea: Trailing _ to make identifiers case sensitive. Ok, but that's just to avoid name clashes, the SI rules could stay exactly they are now if we use any prefix instead that it's not the "don't care" character. So let's use the Unicode middot instead: FOO· Problem solved without a new language rule.
Next idea: Introducing a strict mode so that you're forced to be consistent in a single file. That hardly improves anything. Feel free to castigate yourself in your own code as much as you want, but don't expect me to admire you for it. I'm the one who thinks consistency is a poor man's approach to correctness and enforcing consistency everywhere is way more expensive than simply training your brain to be a bit more flexible. In fact, it's simply "untraining" the brain damage that Unix introduced.
I guess I can work around any problems caused by partial-casing, but honestly I would like to see this project become more community-driven. That is the biggest concern I hear from colleagues when I suggest adopting Nim.
"Community-driven" is fine with me, but arguing all day long on the forum is not a design process. Want to improve Nim's development process? Write proper NEPs then.