int main(char** argv, int argc) { Really? :-)
[deleted]
D as a Better C
71–80 of 193 posts
Re: D as a Better C
#72I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter. D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `a…
The D standard library is generally designed to generic code: you often aren't supposed to see the type returned by a function. Also, you can use auto too + Template constraints would help you here.
I understand. That's why I mention it as one of the downsides of D. It's probably subjective, but I like to see the types of function signatures. It serves as documentation, and makes it easier for me to say, "What does this function return, and what can I do with it?"
Re: D as a Better C
#73Earlier quoted context omitted.
It sounds like OP's issue isn't that auto exists or that people write code using it, it's that the documentation uses auto, which makes it hard to figure out the types of things when you look them up.
That could be solved by turning function calls in example code into hyperlinks to the relevant documentation, which is a good idea in general.
OP here. Yes, that would be very helpful.
Re: D as a Better C
#74Earlier quoted context omitted.
(Disclaimer: one of the Nim core devs here) Happy to see you paint Nim in a (sort of) positive light, I hope I can help with this one negative. > I liked Nim better in almost every way but one: the compiler was fickle and would just fail silently sometimes. Can you give some examples and elaborate on what you mean by "fail silently"? Did you at least get a segfault?
Unfortunately, I don't have any examples off-hand. It was a month ago. I'll see if I can dig the repo back up and reproduce the error. As for how it failed, it did not segfault. It just stopped and dumped me back out on the terminal with no output at all. (I'm on OSX 10.12.6.)
That's a pity. Let me know if you dig it up.
Next time please create an issue on GitHub[1], you don't have to worry about creating a small example either, as long as you give us all the code to compile it.
Re: D as a Better C
#75Earlier quoted context omitted.
> D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. I don't believe that one second, every language strives to be popular and reach large adoption, since more developers == more maintainers == bigger ecosystem == more reach into enterprise.
That's not so simple, because large adoption at a too early stage causes the language definition to freeze before it reaches maturity. Simon Peyton-Jones from the Haskell community explaining exactly that: "What happens if [a language] become successful too quickly? You can't change anything!" https://www.youtube.com/watch?v=re96UgMk6GQ&t=1395
Is this the same as what I've read of as the (humorous) Haskellers' motto: Anything but success! or Avoid success at all costs? or something like that? :) Meaning maybe that they do not want to dilute the purity of their language for industry success?
Edit: A quick google finds this, which is enlightening:
Re: D as a Better C
#76Earlier quoted context omitted.
Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc). In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a fami…
Have you looked at Rust? It uses Option types, has generics, also uses return values for error handling but has a lot more syntactic sugar to make it cleaner than in Go.
I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change. But for my side projects, that bar wasn't worth jumping.
Re: D as a Better C
#77Is "BetterC" only for DMD? I see that LCD (the LLVM front end) also appears to have "--betterC" flag.
Re: D as a Better C
#78Re: D as a Better C
#79Earlier quoted context omitted.
This seems like it would be great for a list comprehension. I believe the main appeal to using comprehensions is that it speeds up the iteration process at run time so wouldn't a list comprehension be just as useful here if not more so then?. You could also use the functools and itertools library for really fast iterations, possibly, depending on what it is you are trying to achieve. If you are specifically talking l…
But would that be faster than numpy? numpy in typical setup would use SIMD or other math kernel (mkl, blas, etc).
It wouldn't.
Pure Python code is never going to out-perform a low-level optimized C library. Especially not when comparing iterative vs vectorized code.
Re: D as a Better C
#80Earlier quoted context omitted.
You can easily get best of both worlds with Lisp derived languages.
It's been my understanding that Lisp and its relatives aren't designed to compete against C for speed either. Is this wrong?
Common Lisp has some very fast implementations (I think SBCL is the fastest) and it was designed to be a systems language. It can be optimized to be as fast as C.