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

41–50 of 193 posts

Re: D as a Better C

#41

Post by StevePerkins »

jacquesm wrote: post #25
camus2 wrote: post #22

Earlier 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.

I would hold up Haskell as another counter example to your assertion.

Would you really, though?

I can definitely picture some proponents taking enjoyment from their programming language being perceived as inaccessible to the masses. Insofar as it makes them feel more elite for their knowledge of it.

But even then, the ego gratification depends on there being a wide audience of people who know "of" the language and its inaccessibility. If people don't know that you're elite, then well... are you?

Proponents of programming languages notwithstanding though, I don't believe for a moment that the creators of any programming language do not wish for it to obtain wide adoption.

Re: D as a Better C

#42

Post by pmoriarty »

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…

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.

Re: D as a Better C

#43

Post by [deleted] »

saghm wrote: post #15
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 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…

[deleted]

Re: D as a Better C

#44

Post by jononor »

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…

The trick to high-performance scientific calculations in Python is to use libraries like NumPy (possibly via Pandas), and their large set of vectorized operations. Then majority of the number crunching happens in optimized C/C++, with Python primarily 'orchestrating' these.

For the cases where the data-manipulation functionality desired is missing and pure Python is problematic performance wise, one can use Cython to bridge the gap.

Or if that is not enough, write those functions in C against the NumPy C API, and expose that as Python APIs.

Re: D as a Better C

#45

Post by zombinedev »

zxy_xyz wrote: post #40

Funnily, the D code looks more verbose than the C code.

Yes, in this example, but once you start looking at more interesting pieces of code it becomes close to impossible for C beat D without heavy use of macros on the code readability front. Check the runnable examples on the front page - http://dlang.org/.

Re: D as a Better C

#46

Post by ziotom78 »

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…

I am in a similar situation, as I develop a lot of scientific code. I've tested several solutions, and so far the most viable for me (though far from perfect) is Python+NumPy+Fortran, the latter exposed to Python using f2py (much easier than binding C/C++ to Python). Not sure if this might be a good solution for you, it depends whether the bottleneck in your code is in I/O or in raw calculations (in the former case you're not going to get any significant advantage from Fortran).

I've tested several other languages that might be good for my purposes. From what I have seen, Rust is not ideal because of the acknowledged poor support for multi dimensional arrays [1] and the strange semantics for floats (due to the need to be «correct» in presence of NaNs).

Two options that might become interesting once they gain a stable status are Julia [2] and Chapel [3]. The former might be exactly what you are you looking for; the latter is ok if you usually run your codes on HPC platforms. But be prepared to face some friction when sharing your work with colleagues or publishing papers: the little penetration of these two languages in the scientific world implies that people will face difficulties in using/understanding how your code works.

[1] Look for «array» in the page https://users.rust-lang.org/t/on-rust-goals-in-2018-and-beyo...

[2] https://julialang.org/

[3] http://chapel.cray.com/

Re: D as a Better C

#47

Post by WalterBright »

Ace17 wrote: post #35

Why remove RAII? It's not fundamentally incompatible with "Better C" semantics, especially if there are no exceptions.

RAII requires exceptions to be correct. I hesitate to say it it has RAII otherwise.

Exceptions have two issues:

1. D exceptions currently require the GC. There is a Pull Request to fix that, but it isn't incorporated yet.

2. More problematic is the Dwarf exception handling mechanism requires a language specific "personality" handler. This is supplied by the D runtime library. Trying to trick the C runtime library one into working with D isn't a solved problem at the moment.

Re: D as a Better C

#48

Post by zombinedev »

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…

If you're interested in high-performance scientific computing, then I guess you'll pleased to know that many use D for this domain, specifically for its high-performance and also high-level features that make prototyping as easy (if not easier) as in Python. In addition to good C/C++ interop, there are also libraries for interfacing with Python and R. Be sure to check http://blog.mir.dlang.io/, https://github.com/kaleidicassociates/lubeck, https://github.com/libmir, https://github.com/DlangScience and https://www.youtube.com/watch?v=edjrSDjkfko

Re: D as a Better C

#49

Post by wtetzner »

WalterBright wrote: post #33
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…

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.

Re: D as a Better C

#50

Post by WalterBright »

StevePerkins wrote: post #41
jacquesm wrote: post #25

Earlier quoted context omitted.

I would hold up Haskell as another counter example to your assertion.

Would you really, though? I can definitely picture some proponents taking enjoyment from their programming language being perceived as inaccessible to the masses. Insofar as it makes them feel more elite for their knowledge of it. But even then, the ego gratification depends on there being a wide audience of people who know "of" the language and its inaccessibility. If people don't know that you're elite, then well..…

You're right. The aim for D is total world domination.
Post reply on HN