Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nimrod: C + Macros + GC

nimrod-code.org

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Nimrod: C + Macros + GC

#81

Post by pjmlp »

andrewflnr wrote: post #60
Dewie wrote: post #59

Earlier quoted context omitted.

I don't know anything about systems languages, but it seems that there is a lot of effort getting put into C/C++ alternatives, and many bold efforts at that. But maybe that is just a historical bias, because so few remembers the failed (popularity vice) systems languages efforts of yesteryear?

I'm only 21, but I definitely get the impression things have picked up in that area in the last few years.

Before C became mainstream, Modula-2 and many Pascal dialects like Apple and Turbo Pascal could already fulfil the same role with better type safety and Go compile times in 16 bit systems.

However they lacked the bundling to a commercial OS like UNIX, hence C grew in importance, because developers tend to use the languages supported by the OS vendors.

Re: Nimrod: C + Macros + GC

#82

Post by pilif »

Reading the tutorial is indeed very pleasant. I have to say however, that from such a new language I would ask for more correct string handling as opposed to the let-me-sidestep-encoding-issues-and-still-call-it-UTF8 that's going on.

Defining characters as 8 bit is not quite correct (you will get char variables holding a fraction of a character), treating strings as arrays of characters by conversion also isn't (now you have an array of partial characters) and ignoring the encoding (just assuming UTF8) is a sure cause for annoying bugs - something the rest of the language goes great lengths to avoid.

I've only read the tutorial so far. Maybe the library fixes some of the issues - we'll see. The thing is just that if you start adding metadata to your sting types (they do encode the length (in what? Characters? Partial characters? Bytes?)), then why not also at least add an encoding (to help programmers not to mix strings of different encodings)? Why do everything right and then weasel out when you get to strings?

Sorry. I'm totally obsessive what string encodings is concerned :-)

Re: Nimrod: C + Macros + GC

#83

Post by pjmlp »

tomlu wrote: post #29
pmb wrote: post #20

Earlier quoted context omitted.

Nobody can explain to a dedicated C++ programmer why a new language is better than C++. I have tried for more than a decade many times and all I have ever gotten across has apparently been a "wah wah wah" noise like the adults in Peanuts. Because C++ is multi-paradigm, all paradigms are possible within it (although they may not be syntactically easy or have reasonable error messages, etc etc). Therefore, either C++ i…

I dunno - I have about 15 years C++ experience, and if anything the better I have become at the language the less I like it... Having said that any language with a GC is unlikely to supplant C++. I would have thought that anything that could get away with using GC is already not using C++. Ergo what will finally kill C++ in all its final domains is IMO some sort of better C. Maybe Rust, if they sort out their non-man…

Having used GC enabled systems languages already in the 90's, I am the opinion it is more a generation issue.

Technology changes fast, but humans take generations to be convinced of something.

Sometimes the only way for something to get adopted is when the luddites no longer have a word to say.

Re: Nimrod: C + Macros + GC

#84

Post by bjz_ »

xaa wrote: post #74
eru wrote: post #71

Earlier quoted context omitted.

What's redundant about the `var' syntax? Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.

In Nimrod, when you are declaring a variable with an explicit type, the syntax is: var x, y: int as opposed to the more concise C family way of doing it: int x, y; In C, there is no keyword needed to signal that this is a variable declaration. Similarly, in Nimrod, if you declare the return type of a function, you write it in addition to the "proc" keyword. IMO, the C++0x/D way of declaring a type inferred variable/f…

If you have type inference, this is usually not a problem. Also, it is much easier to parse, both for humans and compilers. Rust uses the former way, and it's extremely readable.

Even Herb Sutter, of C++ fame agrees:

> One of the things Go does that I would love C++ to do is a complete left-to-right declaration syntax. That is a good thing because the left-to-right makes you end up in a place where you have no ambiguities, you can read your code in a more strait-forward way, which also makes it more toolable.

(6:00) http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Ques...

Re: Nimrod: C + Macros + GC

#85

Post by sidww2 »

burntsushi wrote: post #66
sidww2 wrote: post #54

Earlier quoted context omitted.

I'm in CompBio and the sense I get is that it's a lot easier to get someone to try your tool if all you have to do is provide them the jar which they just have to click on and it runs. Whereas with compilation, you first have to make sure you have all the platforms covered and then force the potential user to select the right executable for the platform.

Just distribute the source. I'm in CompBio too and actively avoid software distributed as just jar files. Give me the source so I can fix your (probably) broken software. (Yes, I have a low opinion of the quality of software in my field.)

I don't think forcing potential users to compile a program is going lower the barrier much. A lot of the users could be biologists and they would likely not know how to compile the source. I do agree that the software should be open source.

Re: Nimrod: C + Macros + GC

#86

Post by deckiedan »

pilif wrote: post #82

Reading the tutorial is indeed very pleasant. I have to say however, that from such a new language I would ask for more correct string handling as opposed to the let-me-sidestep-encoding-issues-and-still-call-it-UTF8 that's going on. Defining characters as 8 bit is not quite correct (you will get char variables holding a fraction of a character), treating strings as arrays of characters by conversion also isn't (now…

Sounds like you'd be a great person to join the team as chief string theorist. :-)

Re: Nimrod: C + Macros + GC

#88

Post by burntsushi »

sidww2 wrote: post #85
burntsushi wrote: post #66

Earlier quoted context omitted.

Just distribute the source. I'm in CompBio too and actively avoid software distributed as just jar files. Give me the source so I can fix your (probably) broken software. (Yes, I have a low opinion of the quality of software in my field.)

I don't think forcing potential users to compile a program is going lower the barrier much. A lot of the users could be biologists and they would likely not know how to compile the source. I do agree that the software should be open source.

> A lot of the users could be biologists

In my experience, biologists are allergic to the command line. They need web interfaces.

In the case where they don't mind using the command line, providing Linux x64 binaries (along with the source) is plenty sufficient.

Note that I'm not saying they shouldn't distribute the jar if that's the kind of game they want to play. I'm saying they shouldn't restrict themselves to distributing a jar.

> I do agree that the software should be open source.

Me too. But it's not an ideological point. I wasn't kidding when I said that, in all probability, I'll have to fix whatever software I'm using. Or at the very least, read the source code to understand what it is that they've implemented. (You'd think it'd be clear from the methods section in their paper...)

/rant

Re: Nimrod: C + Macros + GC

#89

Post by rdtsc »

comicjk wrote: post #72
continuations wrote: post #15

This looks good. However according to the web framework benchmark its performance looks pretty underwhelming, below that of Python and Ruby: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7... Has anyone used this in production?

I'm in scientific computing so the floating-point performance is by far my biggest concern. In the tests I just ran, Nimrod and C are virtually identical in time (probably creating near-identical machine code). test.nim: var sum = 1.0 while sum int main() { double sum = 1.0; while(sum C time / Nimrod time, average of 10 runs: 1.00

Perhaps unrelated. What are you thoughts so far on Julia?

http://julialang.org/

Re: Nimrod: C + Macros + GC

#90

Post by qznc »

pilif wrote: post #82

Reading the tutorial is indeed very pleasant. I have to say however, that from such a new language I would ask for more correct string handling as opposed to the let-me-sidestep-encoding-issues-and-still-call-it-UTF8 that's going on. Defining characters as 8 bit is not quite correct (you will get char variables holding a fraction of a character), treating strings as arrays of characters by conversion also isn't (now…

I just stumbled over the way D handles this. The forum holds the discussion and reasoning, how D does it:

http://forum.dlang.org/thread/uuevnvallcardcdjwikz@forum.dla...

Post reply on HN