Live data from Hacker News

The Next Big Programming Language You’ve Never Heard Of

wired.com

61–70 of 75 posts

Re: The Next Big Programming Language You’ve Never Heard Of

#62
post #49

The phrase "C++ is an extremely fast language -- meaning software built with it runs at high speed" needs to be changed to "It's possible to build high speed software with C++". I take any performance claims made by a particular language with a pretty big grain of salt (particularly those made vs Java/JVM) unless they're accompanied by some reasonably sophisticated benchmarks and source that actually show a performan…

I hear that argument a lot, and yet I have never seen real-life software that runs comparably in Java and C++. For example, a few weeks ago, I was looking at some (fairly simple) data processing code backed by SQLite. The Java version was too slow for the amount of data that needed to get analyzed and reanalyzed repeatedly. A rewrite in C++, with no special trickery, ran 3x faster. After isolating everything in Java…

I think the point is that claiming speed is a property of languages is simply a category error, like saying programming languages are green or noisy. These can be properties of programs (well, properties of a given execution of a program) but have nothing to do with languages.

Re: The Next Big Programming Language You’ve Never Heard Of

#63
post #31

Earlier quoted context omitted.

I'll bite: a relevant technical question would be: is D really that much better than C++11 that you should abandon C++ (with all of the consequences that would have on tooling/libraries/etc.)? I think D made more sense pre-C++11.

Having used both, I'd say yes. C++11 does some wonderful things, many many improvements that were a long time coming, but D put those improvements into the core language and their standard library. This makes D much more readable and hackable than C++11. Not to mention the metaprogramming support is significantly easier to use (though not more powerful, as they're both technically turing complete).

D's metaprogramming is significantly more powerful. For example, string literals can be template arguments and can be manipulated at compile time and turned back into D code.

Re: The Next Big Programming Language You’ve Never Heard Of

#64
post #29
post #20

I think most programmers I know have heard of D. When I took at look at it years ago, I concluded that the main problem was that it tried to please everyone. There's simply 'too many' features without a core theme to drive programming.

In a fun and meta sort of way you are saying D has not tried to please you. There are structural problems with this kind of criticism btw I have upvoted your comment, I do share the vision of a small elegant language yet sufficiently powerful language. At the same time I if some parts of D were to be thrown out I would find a way to complain about it. In fact one of my gripes is that it does not have compile time sum…

You're right in that people often comment that D has too many features, and btw please add X, Y and Z features!

Re: The Next Big Programming Language You’ve Never Heard Of

#65
post #58

Let me put on my tinfoil hat for a second. Two companies that love user data are making "languages" for us to write our applications with (Facebook with Hack and React, Google with Dart and Go) The NSA worked backdoors into RSA encryption. Could the Facebook/Google compilers provide a similar backdoor for them to syphon data? /tinfoilhat

D is all up on https://github.com/D-Programming-Language so I think it'd be kind of hard to sneak things into it.

Re: The Next Big Programming Language You’ve Never Heard Of

#66
post #35

The problem with low level languages is they don't live in isolation. As someone who worked on a large project in Ada, you'll need to at some point use the OS and its libraries which for Unix is in C. Want to network or get a OS semaphore? C. Many languages support this call to the C library functionality, but it always seems to force a lot of things back into the C way of doing things. Maybe with a runtime (Java!, o…

Alexandrescu talked about D at Boostcon a few years back, and as I recall he was planning to make it compatible with C system libraries.

D has been compatible with C libraries since the beginning.

Re: The Next Big Programming Language You’ve Never Heard Of

#67
post #49

Earlier quoted context omitted.

I hear that argument a lot, and yet I have never seen real-life software that runs comparably in Java and C++. For example, a few weeks ago, I was looking at some (fairly simple) data processing code backed by SQLite. The Java version was too slow for the amount of data that needed to get analyzed and reanalyzed repeatedly. A rewrite in C++, with no special trickery, ran 3x faster. After isolating everything in Java…

I think the point is that claiming speed is a property of languages is simply a category error, like saying programming languages are green or noisy. These can be properties of programs (well, properties of a given execution of a program) but have nothing to do with languages.

For languages with exactly one useable implementation, the distinction is rather academic. In the case of C++, as far as I know, every production-quality compiler produces code which runs circles around code produced by any Java compiler.

In addition, some languages have features which cause them to be more difficult to optimize. (See, e.g., the restrict keyword in C99.)

Re: The Next Big Programming Language You’ve Never Heard Of

#68
post #59
post #55

Earlier quoted context omitted.

The proof is in the pudding. Implement FFT using a JIT that over any length of time/samples is faster than FFTW [1] or an h.264 encoder faster than x.264 [2] . [1] - http://www.fftw.org/ [2] - http://www.videolan.org/developers/x264.html

The proof is not in the pudding in this case. You say "In my opinion JIT is always going to be slower than native (AOT)" and I say that you're wrong. The optimizations that can be done ahead of time are a subset of the optimizations that can be done at runtime. That it's hard to write a really good JIT compiler has nothing to do with it. Neither has the size of the problem. Always is a dangerous word. But I can hear…

The proof is in the pudding as to the state of the art today. What might be possible is a different question. I thought you said that JIT is faster than AOT today and that's something you have to prove (and I don't think you'll be able to, simply because it's not).

> The optimizations that can be done ahead of time are a subset of the optimizations that can be done at runtime.

I don't think so. It's the other way around. That's because ahead-of-time you can do anything that takes any amount of time, including running the program. As long as your actual problem is predictable you can always do a better job AOT. In fact the process that a lot of performance driven AOT development goes through is running the program through sample data, analysing the results, including looking at the generated code, and figuring out ways to make it run faster. If the fastest solution for a specific problem involves generating native code then your AOT program can generate native code (if you want to say that's cheating than go ahead :-) ). The mere ability to produce your native code upfront is a performance advantage and there is no disadvantage. In theory including compilation time in run-time, over long periods, makes that delta as small as you want but it's still a delta and also we've not approached the theoretical bound in real world programs.

To be absolutely honest, when taken to the extreme there is no AOT or JIT. The thing is that people usually refer to JIT as spending some limited effort during run-time to generate some native code for some specific code sections. At the extreme JIT and AOT merge.

Re: The Next Big Programming Language You’ve Never Heard Of

#69
post #32

Earlier quoted context omitted.

Apparently it's being used at Facebook. If they actively injected life into the D ecosystem to the same extent Google does with Go, the momentum might pick up substantially. Look at how late Go arrived--it was announced in 2009--and how popular it already is. Now, that doesn't mean Go or D can necessarily become the next big thing, i.e. the C++/Java killer. But even if they got as far as Python or Ruby, that would be…

If Facebook did for D what HHVM is for PHP, maybe people would use it. They haven't.

Yet.
Post reply on HN