131–140 of 162 posts
Earlier quoted context omitted.
In the web3/blockchain space, HN is known as a prime example of a place you should go to ground yourself, because HN hates it with passion.
You say "web3/blockchain", I hear "homeopathy", "astrology", and "bioenergetic therapy". The HN crowd might be fad-gullible, but stupid-gullible? I don't think so.
I love Nim's syntax, but is there a specific reason why e.g. the SFML binding cannot imitate C++ RAII approach of handling resources? There is .close everywhere.
SFML binding probably will be updated to use RAII when ORC is made the default GC.
See this document for more info on Nim's destructors: https://nim-lang.org/docs/destructors.html
What’s the story like using Nim for WASM? I’ve always meant to take a proper look at Nim, and maybe WASM could be the perfect place for it.
Earlier quoted context omitted.
In the C world ALL_CAPS very often signify preprocessor macro identifiers (or some other "class" of identifier), but, yeah..they may all be "insane". ;-)
OMG, what if C did significant case because of that? I mean, it's fine to write "#import", why didn't K&R use a special syntax for macros, like $MACRO or something and left the uppercase as a convention?
FWIW, I do think that the late 1960s saw a broad "new prog lang" evolution away from case insensitive (often ALL CAPS due to low resolution dot matrix printers/display devices) stylistic tendencies in, e.g. LISP and FORTRAN, towards case sensitivity and lowercase. So, I suspect this was the salient driver - "We have lowercase now/text is more legible! Let's use it!". (Yes, mechanical typewriters/typesetting had it for decades to centuries, but programming was not done on those, but with printers and punch cards and just starting to be on CRTs.) There are analogies with Unicode in PLs these days (though there are obviously also other motivations these days/decades with the compute world i18n).
Looking at https://nim-lang.github.io/Nim/lib.htmlIt seems to have many of the batteries built in - HTML, JSON parsing, nice set of collections. I wonder how good SQL and especially noSQL support is.
My worry is that there must be rough edges. Plus pandas (not just numpy) is just so convenient at times.
Earlier quoted context omitted.
Go yes. Rust? I wouldn’t say that Rust is easier although I may be biased with my long C/C++ background. The ownership model is a pretty complex thing to learn. I guess maybe if you Box a lot? It does have an easier on-ramp story for getting started/adding dependencies and that may be important for getting started.
> I wouldn’t say that Rust is easier Rust is easier than C/C++, but not at first . After you learn the semantics of it, is very smooth sailing (at least until you get into the most exotic needs like build your own async runtime).
Earlier quoted context omitted.
I like Nim, and probably will learn it at some point. But no, Nim is not everything "python should/want to be". The name case insensitivity and the implicit imports on the global namespaces are perfect examples of stuff that are better in Python.
I've been using nim for a few years. I wouldn't have made either design choice (i always do qualified imports, it's just a few extra characters of typing). That said, there is a reason these superficial things always come up in HN threads. If you haven't used a language before, syntax is the only thing you can talk about. It's the equivalent of low effort political banter and the dopamine hit you get from junk food o…
This just feels like gatekeeping. I like nim, I've used it, talked to Dom and the author a few times in chat, filed some small bug reports. But even if I hadn't, I'd still hate the case insensitivity; I'm an experienced developer and I don't need to have used a language to know I will like or dislike some aspect of it.
I would like to use Nim for data wrangling tasks - for shipping compiled data munging CLI utilities. Looking at https://nim-lang.github.io/Nim/lib.htmlIt seems to have many of the batteries built in - HTML, JSON parsing, nice set of collections. I wonder how good SQL and especially noSQL support is. My worry is that there must be rough edges. Plus pandas (not just numpy) is just so convenient at times.
Earlier quoted context omitted.
If you have 'myvar' and 'myVar' in some code there are three things you could do. 1) The compiler gives you an error, this would be my preferred solution though I'm not aware of any language that does that. 2) These end up referring to the same variable with no error. Nim's solution. 3) These are actually different variables with no error. The common solution. Again, I would prefer (1) but I think that (2) is a safer…
The 3rd solution is terrible, because: ForMid = 4 # padding for middle box in px And: FormId = 3 # ID of the form in the user process Should definitely not be resolved as the same variable.
Earlier quoted context omitted.
If you have 'myvar' and 'myVar' in some code there are three things you could do. 1) The compiler gives you an error, this would be my preferred solution though I'm not aware of any language that does that. 2) These end up referring to the same variable with no error. Nim's solution. 3) These are actually different variables with no error. The common solution. Again, I would prefer (1) but I think that (2) is a safer…
As much as I hate it for correctness, 2 is better than 3 indeed. No sane developer encodes meaning in the case of the name of the variables, in the overwhelming majority of cases it's a typo.
all the time in Python.
date = new Date()
all the time in JS.
Those are just the two languages I spend the most time in, but, but I'm sure it's trivial to find numerous examples of cases carying meaning in case-sensitive languages. Especially ones which encourage camel casing.