Wired don't really understand programming, which is ironic.
D is I think something well discussed here.
For the first time in about a decade - possibly two decades - there is a renaissance in programming language design focused on approaching real-World problems. D is a piece of the puzzle, but I think Wired don't quite get yet that it is now the entire solution.
The author isn't a programmer, and as I read more it became clear the audience isn't practicing programmers. (In other words I don't think this is HN material.) I'm not sure who the audience is supposed to be, though. I'm left with the sense that it's the non-technical manager of the programming team, and the article provides a justification for them to force D on the next project.
Wired's target audience is not in tech. There are other analogies in the mass (and not so mass) media. Wired articles don't really belong on HN as a class, although individual topics can be relevant if sometimes inaccurately reported or late news.
A podcasting example is "this week in tech" is for people outside tech to glance inside. Its moderately entertaining and nicely produced although I'd worry about my personal abilities if I ever learned anything from it, because its not aimed at a tech audience. Podcasts for people in tech to listen to are things like "Software engineering radio" although they sometimes run off the TPS report deep end of fads, or "functional geekery", or the former Relevance, now Cognitech, interview show. "FLOSS weekly", another interview podcast show, is kind of in between the two worlds, which is pretty unusual and interesting.
Edited to add some magazine examples. PC magazine is not for people inside tech to read, its for people outside tech wondering whats going on to hear a little gossip. The former sysadmin magazine (out of print for like a decade now?) was for people inside tech to read. The dear departed Perl Journal was for people inside tech. The print version of Linux Journal a decade or so ago was unusually more or less on the border. For noobs, magazines were kind of like internet websites printed out and mailed to you. Different from newspapers in that you only got one a month and they were somewhat more polished and edited and generally on nicer paper. My kids are young enough to not really understand newspapers or magazines so I've actually had discussions along these lines trying to explain. They're a little fuzzy about broadcast distribution vs streaming too, broadcast is like a stream but you have no personal pause or commercial skip button, this confuses the heck out of them.
Well outside of the link bait title, I've heard of D. I don't think it's going to be the next big language if you can't write a mobile application or a cloud backend with it. Sure it may be more efficient, but Android devices run Java and iOS devices run C/C++/Objective-C/Swift. On the backend, you've got other languages and technologies that more common that have a better chance of making it than D.
Android Studio will soon feature NDK integration. You can reuse C/C++ code on Win/Mac/Linux/Android/iOS, achieving native performance everywhere, and then use the recommended GUI toolkit on each platform [i].
However, C/C++ is intimidating, which is why I think compile-to-C programming languages like Nimrod [ii] are going to be the next big thing.
I can offer anecdotal evidence to the contrary. I am proficient in both C++ and Python and I am able to whip up something in Python much faster than in C++. Boost and C++11 closed the gap somewhat but the difference is:
* Python's approach of "batteries included", ruch standard library. Sure you can find a library in C++ for almost everything, but it is never as easy as "pip install" and subsequent import.
* I do not have to declare types. It works well for small programs where I can maintain implicit typing in my head but becomes an impediment for larger programs.
* Compilation time for any moderately sized C++ program and the lack of REPL quickly become a problem in fast iteration cycle. No IPython for C++.
* Small syntactic sugar things always help. As an example, In Python I can assign array, set, or dict literal to any variable. In C++11 even though I should supposedly be able to do some of that, it is not universally across platforms.
I'm proficient in C++ but when I write a tool for work it often ends up being 2x faster to write in D than if written in C++.
The lack of wrapping of OS primitives, harder to integrate libraries and inflexible language is a factor. C++ simply isn't very productive, even with years of practice.
Is Rust supposed to have a similar goals to D? Seems like a lot of (relatively) new languages are setting out to achieve c/c++ performance while having easier to understand/more expressive syntax.
Vaguely, yes. It's been a few years since I've written any D, but the initial impetus for the language was "Fix the broken aspects of C++." Rust's core concept is "memory safety with zero overhead."
This means they end up in very similar, yet different places: GC is the default in D, but isn't even a core part of Rust at all. D allows you to turn it off, losing some functionality, Rust allows you to add one in as a library.
Most people in Rust-land have an incredibly high amount of respect for the D team and all they've done, and continue to do.
Comments
Wired don't really understand programming, which is ironic.
D is I think something well discussed here.
For the first time in about a decade - possibly two decades - there is a renaissance in programming language design focused on approaching real-World problems. D is a piece of the puzzle, but I think Wired don't quite get yet that it is now the entire solution.
The author isn't a programmer, and as I read more it became clear the audience isn't practicing programmers. (In other words I don't think this is HN material.) I'm not sure who the audience is supposed to be, though. I'm left with the sense that it's the non-technical manager of the programming team, and the article provides a justification for them to force D on the next project.
I'm not sure most people on HN will have "Never Heard Of" D. It has 10,000 downloads a month!
Wired's target audience is not in tech. There are other analogies in the mass (and not so mass) media. Wired articles don't really belong on HN as a class, although individual topics can be relevant if sometimes inaccurately reported or late news.
A podcasting example is "this week in tech" is for people outside tech to glance inside. Its moderately entertaining and nicely produced although I'd worry about my personal abilities if I ever learned anything from it, because its not aimed at a tech audience. Podcasts for people in tech to listen to are things like "Software engineering radio" although they sometimes run off the TPS report deep end of fads, or "functional geekery", or the former Relevance, now Cognitech, interview show. "FLOSS weekly", another interview podcast show, is kind of in between the two worlds, which is pretty unusual and interesting.
Edited to add some magazine examples. PC magazine is not for people inside tech to read, its for people outside tech wondering whats going on to hear a little gossip. The former sysadmin magazine (out of print for like a decade now?) was for people inside tech to read. The dear departed Perl Journal was for people inside tech. The print version of Linux Journal a decade or so ago was unusually more or less on the border. For noobs, magazines were kind of like internet websites printed out and mailed to you. Different from newspapers in that you only got one a month and they were somewhat more polished and edited and generally on nicer paper. My kids are young enough to not really understand newspapers or magazines so I've actually had discussions along these lines trying to explain. They're a little fuzzy about broadcast distribution vs streaming too, broadcast is like a stream but you have no personal pause or commercial skip button, this confuses the heck out of them.
This is the article title on Wired. It may well be true for the typical reader of Wired.
And about 1400 questions on Stack Overflow, dating back to 2008.
http://stackoverflow.com/questions/tagged/d?page=1&sort=newe...
Completely unheard of! ;)
Well outside of the link bait title, I've heard of D. I don't think it's going to be the next big language if you can't write a mobile application or a cloud backend with it. Sure it may be more efficient, but Android devices run Java and iOS devices run C/C++/Objective-C/Swift. On the backend, you've got other languages and technologies that more common that have a better chance of making it than D.
Android Studio will soon feature NDK integration. You can reuse C/C++ code on Win/Mac/Linux/Android/iOS, achieving native performance everywhere, and then use the recommended GUI toolkit on each platform [i].
However, C/C++ is intimidating, which is why I think compile-to-C programming languages like Nimrod [ii] are going to be the next big thing.
[i] https://gradha.github.io/articles/2014/03/nimrod-for-cross-p...
[ii] http://picheta.me/articles/2013/10/about-nimrods-features.ht...
Article lost me here:
"But [C++ is] not as easy to use as languages like Python, Ruby, and PHP. In other words, it doesn’t let coders build software as quickly."
Anyone who is proficient in C++ can write code just as quickly if not faster than most other languages.
It's like saying knowing Spanish is better than knowing German because you can communicate faster in Spanish. It's an insult to the German language.
I can offer anecdotal evidence to the contrary. I am proficient in both C++ and Python and I am able to whip up something in Python much faster than in C++. Boost and C++11 closed the gap somewhat but the difference is:
* Python's approach of "batteries included", ruch standard library. Sure you can find a library in C++ for almost everything, but it is never as easy as "pip install" and subsequent import. * I do not have to declare types. It works well for small programs where I can maintain implicit typing in my head but becomes an impediment for larger programs. * Compilation time for any moderately sized C++ program and the lack of REPL quickly become a problem in fast iteration cycle. No IPython for C++. * Small syntactic sugar things always help. As an example, In Python I can assign array, set, or dict literal to any variable. In C++11 even though I should supposedly be able to do some of that, it is not universally across platforms.
I'm proficient in C++ but when I write a tool for work it often ends up being 2x faster to write in D than if written in C++. The lack of wrapping of OS primitives, harder to integrate libraries and inflexible language is a factor. C++ simply isn't very productive, even with years of practice.
Related: https://www.google.com.br/search?q=next+big+language
Is Rust supposed to have a similar goals to D? Seems like a lot of (relatively) new languages are setting out to achieve c/c++ performance while having easier to understand/more expressive syntax.
Vaguely, yes. It's been a few years since I've written any D, but the initial impetus for the language was "Fix the broken aspects of C++." Rust's core concept is "memory safety with zero overhead."
This means they end up in very similar, yet different places: GC is the default in D, but isn't even a core part of Rust at all. D allows you to turn it off, losing some functionality, Rust allows you to add one in as a library.
Most people in Rust-land have an incredibly high amount of respect for the D team and all they've done, and continue to do.
Walter is answering questions on this article over on proggit: http://www.reddit.com/r/programming/comments/2a20h5/wired_ma...
I was hoping this would be about Nimrod.
- Pythonic syntax with static typing
- Compiles to C, C++, Obj-C and JS
- Produces small executables without dependencies
- Performs comparably to C
- Docs and community need to grow