7 ms·

> There is a sweet spot between low-level performance and control and high-level metaprogramming that is not yet occupied by any language: Maybe Nimrod?

by Dewie 13y ago

danieltillett 13y ago
I have it on my to do list to spend sometime trying out nimrod. It seems like such a cool language.
nly 13y ago
C++. Too many other languages get wrapped up in ideology. D comes pretty close. I can't get past Rusts unreadability. I'd like to give Nimrod a try... especially since it can be compiled to C and presumably integrated in to C++ projects. [Edit] Read Nimrod tutorials and ported a few toy programs. It's encouragingly clean and doesn't seem to shy away from features... I wonder if Alex Stepanov knows that, in Nimrod, "if you overload the == operator, the != operator is available automatically and does the right thing" ;)
- 5hoom 13y ago
  It's an interesting time for native development with all these languages making some serious attempts to dethrone C++ when in comes to combining high/low level in one language. I'm still using C++ myself until the dust settles a bit, but I've found that my C++(11) code is trending towards being less stateful and more functionl-ish. It's cool to see things changing in this space after feeling like it would be old style C or C++ forever.
- Rusky 13y ago
  Curious- what makes Rust unreadable for you? Abbreviations? Cryptic symbols?
  - nly 13y ago
    Yes on both counts. The problem is that I can type faster than I can think. I don't believe that terseness inherently improves readability or encourages better design. I have felt this way since Perl. Consider this from the tutorial: fn draw_all(shapes: &[~Drawable]) { vs C++: draw_all (const vector<unique_ptr<const Drawable>>& shapes) { Transcribing that took a few seconds of thought, and all the terseness of a few symbols has accomplished is to obscure a poor choice of API and ownership semantics. That's just one symbol... how horrific can we make something without noticing with just a few more params and symbols?
    - lucian1900 13y ago
      To me, the C++ version seems entirely unreadable, though. Especially the cdecl inheritance of & going in the wrong place. In some instances Rust has removed syntax or its prevalence (@ turned into Gc/Rc; ~[] no longer grows, but Vec does). To each their own.
      - nly 13y ago
        The & being on the wrong place is a matter of style. I wrote it that way because it seems to be the popular convention. I'd usually write this myself: draw_all (vector<unique_ptr<Drawable>> const& shapes) { Now the const and ref at together.
        pcwalton 13y ago
        I think lucian1900 was referring to & going on the right (`vector &foo`) instead of on the left (`&vector<foo>`).
        nly 13y ago
        I don't see why either is right or wrong, but 'foo' is the reference and vector is the type. It seems logical to me the C++ way, but I'm not overly fussed.
        lucian1900 13y ago
        Different parts of the type are in different places, merely for the space saving of being able to replace "var" or "let" with the type, like "int". While it made sense when C was created, this is horribly wrong this many years later.
    - pcwalton 13y ago
      Why is that a poor choice of API and ownership semantics? That's entirely natural. You use a range in order to provide the maximum convenience to your callers, and you use unique ownership to provide efficient memory management and reduce the amount of copying of data that has to be done when the backing store is resized. (Also, your equivalence is not quite correct: `&[T]` is more like a Boost range. In particular your transcription makes it look like the original code only accepted Vec<T>, which is not the case.) > That's just one symbol... how horrific can we make something without noticing with just a few more params and symbols? You've pretty much covered all the type-level symbols in Rust, except for * for unsafe pointers.
CountHackulus 13y ago
D is excellent for metaprogramming and performance. D's static language is D.
- eukaryotia 13y ago
  Looking at the lexer[0], it probably works on D and maybe C++. [0] https://github.com/eudoxia0/cmacro/blob/master/grammar/lexing.l https://github.com/eudoxia0/cmacro/blob/master/grammar/lexin...
lucian1900 13y ago
Or perhaps Rust.
SixSigma 13y ago
Forth

> There is a sweet spot between low-level performance and control and high-level metaprogramming that is not yet occupied by any language: Maybe Nimrod?

by Dewie 13y ago

> There is a sweet spot between low-level performance and control and high-level metaprogramming that is not yet occupied by any language: Maybe Nimrod?

danieltillett 13y ago

I have it on my to do list to spend sometime trying out nimrod. It seems like such a cool language.

nly 13y ago

C++. Too many other languages get wrapped up in ideology. D comes pretty close. I can't get past Rusts unreadability. I'd like to give Nimrod a try... especially since it can be compiled to C and presumably integrated in to C++ projects. [Edit] Read Nimrod tutorials and ported a few toy programs. It's encouragingly clean and doesn't seem to shy away from features... I wonder if Alex Stepanov knows that, in Nimrod, "if you overload the == operator, the != operator is available automatically and does the right thing" ;)

5hoom 13y ago
It's an interesting time for native development with all these languages making some serious attempts to dethrone C++ when in comes to combining high/low level in one language. I'm still using C++ myself until the dust settles a bit, but I've found that my C++(11) code is trending towards being less stateful and more functionl-ish. It's cool to see things changing in this space after feeling like it would be old style C or C++ forever.
Rusky 13y ago
Curious- what makes Rust unreadable for you? Abbreviations? Cryptic symbols?
- nly 13y ago
  Yes on both counts. The problem is that I can type faster than I can think. I don't believe that terseness inherently improves readability or encourages better design. I have felt this way since Perl. Consider this from the tutorial: fn draw_all(shapes: &[~Drawable]) { vs C++: draw_all (const vector<unique_ptr<const Drawable>>& shapes) { Transcribing that took a few seconds of thought, and all the terseness of a few symbols has accomplished is to obscure a poor choice of API and ownership semantics. That's just one symbol... how horrific can we make something without noticing with just a few more params and symbols?
  - lucian1900 13y ago
    To me, the C++ version seems entirely unreadable, though. Especially the cdecl inheritance of & going in the wrong place. In some instances Rust has removed syntax or its prevalence (@ turned into Gc/Rc; ~[] no longer grows, but Vec does). To each their own.
    - nly 13y ago
      The & being on the wrong place is a matter of style. I wrote it that way because it seems to be the popular convention. I'd usually write this myself: draw_all (vector<unique_ptr<Drawable>> const& shapes) { Now the const and ref at together.
      - pcwalton 13y ago
        I think lucian1900 was referring to & going on the right (`vector &foo`) instead of on the left (`&vector<foo>`).
        nly 13y ago
        I don't see why either is right or wrong, but 'foo' is the reference and vector is the type. It seems logical to me the C++ way, but I'm not overly fussed.
        lucian1900 13y ago
        Different parts of the type are in different places, merely for the space saving of being able to replace "var" or "let" with the type, like "int". While it made sense when C was created, this is horribly wrong this many years later.
  - pcwalton 13y ago
    Why is that a poor choice of API and ownership semantics? That's entirely natural. You use a range in order to provide the maximum convenience to your callers, and you use unique ownership to provide efficient memory management and reduce the amount of copying of data that has to be done when the backing store is resized. (Also, your equivalence is not quite correct: `&[T]` is more like a Boost range. In particular your transcription makes it look like the original code only accepted Vec<T>, which is not the case.) > That's just one symbol... how horrific can we make something without noticing with just a few more params and symbols? You've pretty much covered all the type-level symbols in Rust, except for * for unsafe pointers.

CountHackulus 13y ago

D is excellent for metaprogramming and performance. D's static language is D.

eukaryotia 13y ago
Looking at the lexer[0], it probably works on D and maybe C++. [0] https://github.com/eudoxia0/cmacro/blob/master/grammar/lexing.l https://github.com/eudoxia0/cmacro/blob/master/grammar/lexin...

lucian1900 13y ago

Or perhaps Rust.

SixSigma 13y ago

Forth