51–60 of 72 posts
I guess all roads do lead to Prolog. Why risk the naming confusion? Doing a search for "prologue language" yields millions of Prolog results on both DDG and Google.
It's no different than other languagages. If I'm searching for something about the express framework, I include "js" or "node" in my search terms. Same for rails, add "ruby". "go" is also a fun one…
Earlier quoted context omitted.
Unfortunately, it'd be impossible to work effectively with C code without `nil`. You can create objects set to `not nil`. To be fair, I've had a few points when creating a new type that I forgot to allocate a new instance properly, but option types wouldn't have saved me any work. It would've produced a similar stacktrace. I think the compiler produces a warning, but I'm still working down the warning's lists. You ca…
Having all references that are returned from C be treated as Option types would resolve this difficulty, no? Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed. Though yes, I'm glad to see this is being addressed :).
Perhaps, but there's more than just returns. Dealing with most C code there's a fair bit of pointer passing and manipulation. It's nice being able to deal directly with C code and not have to worry about the impedance mismatch, but still be able to move up the type system. It's more a pragmatic choice.
> Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed.
In this case, mostly its just me not using the type system well. :-) But that's the price I pay for a using a flexible language I can readily use in embedded work. NPE's really don't cause me any headaches compared to most of the other aspects of integrating heavily with C code in embedded systems.
NIM really is a full stack language and ecosystem. It has a first class compiler to JavaScript (though, I admit, I don't know how tuneable it is, so I think it just compiles down to ES5, it'd be nice to do a differential build where it would compile down to ES5 and/or ES2015/ES2016 at the users discretion) Only thing it needs now is a compile to CSS solution and you would never have to leave the language. Its a very…
Why?
It's really nice to see that the Nim ecosystem is gaining more and more traction. A good web framework is indeed quite an important step towards making a language/ecosystem more appealing to a more general audience. I've yet to encounter a small enough project with low risk where I could get away with trying something completely new, but I'm looking forward to trying Nim in the (hopefully very near) future. One negat…
Earlier quoted context omitted.
Having all references that are returned from C be treated as Option types would resolve this difficulty, no? Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed. Though yes, I'm glad to see this is being addressed :).
> Having all references that are returned from C be treated as Option types would resolve this difficulty, no? Perhaps, but there's more than just returns. Dealing with most C code there's a fair bit of pointer passing and manipulation. It's nice being able to deal directly with C code and not have to worry about the impedance mismatch, but still be able to move up the type system. It's more a pragmatic choice. > Lik…
NIM really is a full stack language and ecosystem. It has a first class compiler to JavaScript (though, I admit, I don't know how tuneable it is, so I think it just compiles down to ES5, it'd be nice to do a differential build where it would compile down to ES5 and/or ES2015/ES2016 at the users discretion) Only thing it needs now is a compile to CSS solution and you would never have to leave the language. Its a very…
Regarding GUI, there is also https://github.com/yglukhov/nimx which is based on OpenGL. > Nimx officially supports Linux, MacOS, Windows, Android, iOS, Javascript (with Nim JS backend) and Asm.js/WebAssembly (with Nim C backend and Emscripten).
NIM really is a full stack language and ecosystem. It has a first class compiler to JavaScript (though, I admit, I don't know how tuneable it is, so I think it just compiles down to ES5, it'd be nice to do a differential build where it would compile down to ES5 and/or ES2015/ES2016 at the users discretion) Only thing it needs now is a compile to CSS solution and you would never have to leave the language. Its a very…
Not to harp too much on your nitpick of the syntax, but I'm curious why `#[]` rates as more attractive to you than `{..}`? To me they are equally utilitarian, and I can't figure out why one would be strongly preferable. That said, I do find the placement of Nim pragmas to be cumbersome, resulting in really long lines or awkward line breaks. I wish we could place the pragma declaration on the line before procedures. p…
I find many of Rust's macros annoying for a similar reason, since they'll often be at the root of a module or function but for various complicated reasons can't have leading expressions - you can't make user macros that look like `macro_rules! your_macro_name {...}` or control flow like `match expr {...}` - so they're in an uncanny valley that's just as distracting.
It's really nice to see that the Nim ecosystem is gaining more and more traction. A good web framework is indeed quite an important step towards making a language/ecosystem more appealing to a more general audience. I've yet to encounter a small enough project with low risk where I could get away with trying something completely new, but I'm looking forward to trying Nim in the (hopefully very near) future. One negat…
Considering he's offerring his work up for free, it seems very nitpicky to me
Most personal projects of this scale are labors of love and I suspect most people wouldn't mind nitpicks given in good faith if it means exposing the project to a wider audience. Though I also suspect they will be triaged towards the bottom of the pile :)
Earlier quoted context omitted.
Simply, I'm not one to give praise through a rose colored lens. This is especially true in a place like HN, where its entirely possible the core maintainers of a project may read my feedback, and may or may not feel inclined to clarify, quantify, or at least acknowledge what I have to say about a project. I'm not bringing it down by being honest in how I feel. My praise for nim is genuine and forthright, and I've rec…
And where criticism is substantive, that's valuable. It isn't in this case, and it's hardly dishonest to keep subjective preferences in their place: within our own heads. There's a culture of reflexive criticism in intelligent communities, and I think it has negative side effects we haven't acknowledged. Yeah, it feels good to give one's full-throated opinion without bothering to edit oneself, but we build a better w…
Personally something that looks so silly stresses me out enough to either not use the feature or not use the language, so I’m kind of happy for the comment.
You may think that’s shallow, but if I have a hundred languages to choose from, a few of which check all the boxes, I’ll go with those.