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

D as a Better C

dlang.org

Post reply on HN
Print view View original

51–60 of 193 posts

Re: D as a Better C

#51

Post by sythe2o0 »

pjmlp wrote: post #24
saghm wrote: post #15

Earlier quoted context omitted.

Python is a high-level interpreted language, and C/C++ are low-level (even compared to other) compiled languages. While you might be able to optimize your Python code to run faster than it does now, it's never going to match the performance of C/C++, nor is it intended to. Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Then again, the ease of development…

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?

Re: D as a Better C

#52

Post by dom96 »

christophilus wrote: post #14

I 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…

(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?

Re: D as a Better C

#53

Post by kibwen »

pmoriarty wrote: post #42
messe wrote: post #19

Earlier quoted context omitted.

Python is interpreted, C and C++ are compiled. They target different niches. Python is more focused on ease of use than performance. Usually when writing scientific code in Python you're going to want to at the very least use numpy. It wraps various C functions for many time consuming tasks. To get the most out of numpy you're going to have to vectorize you're code, as python's looping constructs are notoriously slow…

It is up to the implementation of a language whether that language is compiled or interpreted. For instance, there are C interpreters and Python compilers. Neither language is limited to being one or the other. It's just that usually people use C compilers and Python interpreters, but there's nothing inherent in those languages that limits them to those. It's all up to the implementation.

This is true, but not always in a useful sense. There exist language features whose semantics are expressly dynamic, and if your language includes those features it will frustrate static compilation. For example, if your language includes `eval` (as Python does), then any precompiled binary would also need to include a complete Python interpreter. This is why efforts to compile Python (and other languages that are traditionally interpreted) often omit such features, and why languages that intend to be compiled tend to forgo them in the first place.

Re: D as a Better C

#54

Post by vram22 »

nindalf wrote: post #3
systems wrote: post #2

D is betting hard on memory safety, and apparently system programming honestly i think, had they gone in the direction of D as a better Python, and application development, they would have made bigger wins (in terms of popularity) ... better tooling, better ide, refactoring, better GC, better libraries ... better faster programs

The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…

>Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs.

Also fast compilation, which D also has.

Re: D as a Better C

#55

Post by _5ysi »

I like Walter's writing. He is very articulate; terse but in a polished way. Relies on you knowing a thing or two first though.

Re: D as a Better C

#56

Post by vram22 »

new299 wrote: post #6
nindalf wrote: post #3

Earlier quoted context omitted.

The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…

I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…

Have you tried out any of the options for speeding up Python apps, like Cython, writing parts that are in the perf bottleneck in C (if that is applicable), using ctypes / cffi to call C libraries for some tasks, etc.? You can use ctypes or cffi to call either existing libraries or ones you write.

Re: D as a Better C

#57

Post by messe »

pmoriarty wrote: post #42
messe wrote: post #19

Earlier quoted context omitted.

Python is interpreted, C and C++ are compiled. They target different niches. Python is more focused on ease of use than performance. Usually when writing scientific code in Python you're going to want to at the very least use numpy. It wraps various C functions for many time consuming tasks. To get the most out of numpy you're going to have to vectorize you're code, as python's looping constructs are notoriously slow…

It is up to the implementation of a language whether that language is compiled or interpreted. For instance, there are C interpreters and Python compilers. Neither language is limited to being one or the other. It's just that usually people use C compilers and Python interpreters, but there's nothing inherent in those languages that limits them to those. It's all up to the implementation.

> It is up to the implementation of a language whether that language is compiled or interpreted.

While that's perfectly true, it didn't seem necessary to go into it.

Re: D as a Better C

#58

Post by vram22 »

saghm wrote: post #13
nindalf wrote: post #3

Earlier quoted context omitted.

The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…

According to their respective Wikipedia articles, D is 8 years older than Go. Given that you're saying that Go had a lot of success breaking into the Python market, why couldn't D have instead if they had put their efforts there from the beginning?

>According to their respective Wikipedia articles, D is 8 years older than Go.

And Go itself is some years old now (created in either 2007 or 2009 - according to its Wikipedia article - maybe they mean initial creation and first release for public use, by those two year values). So Go is about either 8 or 10 years old. And that makes D either 16 or 18 years old.

>Go had a lot of success breaking into the Python market, why couldn't D have instead if they had put their efforts there from the beginning?

So when D was new or just a few years old (13 to 16 years ago, say), the Python market was a lot smaller that it is today or has been for the last few years. It might not have even been a target for them, for that or any other reason - another reason could be that Walter is from a systems and compiler background, so might not have been too interested in the domain of interpreted languages (just guessing here, maybe he will comment on this). But BTW, D can be used almost like a scripting language due to its speed of compilation. See rdmd command and the "Why D?" and "D as a scripting language" articles on the Infognition blog (a google away).

Re: D as a Better C

#59

Post by yorwba »

wtetzner wrote: post #49
WalterBright wrote: post #33

Earlier quoted context omitted.

There's some debate about where is the sweet spot in the use of `auto` between self documentation and minimizing refactoring costs. Fortunately, the programmer gets to decide which to use.

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.

Re: D as a Better C

#60

Post by no_wizard »

messe wrote: post #19
new299 wrote: post #6

Earlier quoted context omitted.

I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…

Python is interpreted, C and C++ are compiled. They target different niches. Python is more focused on ease of use than performance. Usually when writing scientific code in Python you're going to want to at the very least use numpy. It wraps various C functions for many time consuming tasks. To get the most out of numpy you're going to have to vectorize you're code, as python's looping constructs are notoriously slow…

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 lists (arrays) why not use Deque? It is set matched and python saves run time by automatically knowing each value will be a finite forward sequence

Post reply on HN