Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D.
D's only issue is that it does not have general adoption, which I'm willing to assert is only because it's not on the forefront of the cool kids language of the week. Which is a good thing. New does not always Mean, improved. D has a historical nod to languages of the past, and is trying to improve the on strengths of C/C++ and smooth out the rough edges, and adopt more modern programming concepts. Especially with trying to be ABI compatible, it's a passing of the torch from the old guard to the new.
Regardless of your thoughts on D; My opinion is I'm sold on D, It's here to stay. In 10 years D will still be in use, where as the fad languages will just be foot notes in Computer Science history as nice experiments that brought in new idea's but were just too out there in the fringes limiting themselves to the "thing/fad" of that language.
I think a lot of languages that get popular have to have a thing. Like a thing they do well, and hopefully change the world a little...
Python had math and has lots more maths now.
R also has math and started to kill Python, but now Python has Tensorflow and PyTorch.
Scala has Spark.
Java has Tomcat, and everything that followed, which is probably 20% of the world's mass by volume.
Go has Docker
Ruby has/had a railroad or something?
JS has well, f... I don't know where to start here.
Probably its most useful feature is rather subtle. It's very easy to express diverse ideas in code in D without having to resort to contortions. It's something people realize after having worked with D for a while.
It is not the result of having feature X (you can always find feature X in other languages or a way to make X work), it's the combination of various X's.
For example, some algorithms express naturally in a functional manner, some imperative, some OOP, etc. It isn't necessary to buy into a manner for the whole program, just use the manner that fits the particular part of the program.
You might like to use FP here and there, but don't want to deal with monads. You can use OOP for the AST, but don't want to box integers into an OOP class. You like dynamic typing for one type, but it's a bad fit for another. You can garbage collect for a quick prototype or a seldom used part of the code, and carefully manage memory for the release or the hot spots. (The Warp preprocessor I wrote did that. https://github.com/facebookarchive/warp)
There's a lot less time hammering square pegs into round holes.
I've seen more than enough presentations on "How To Do Technique X In Language Y" and everyone says how clever that is but the contortions are just too awful to contemplate.
The flip side is that D won't be satisfying to a purist adherent of any of those paradigms.
I really like how purity in D is so... practical. I like that a for loop is totally allowed in pure code as long as it modifies no data outside the pure block. One of the most annoying things in Haskell was to translate some algorithm that looks very natural in a for loop into some other sort of combination of map or reduce or something even more complicated.
(Yes, I know Haskell can also fake for loops more cleanly with monads, but they still feel awkward and unnatural.)
My recollection from the last time I worked with D was that pure could be more complicated and strict than expected when using standard libraries functions, e.g. using trigonometry sets hardware global state, thus impure. I don't remember if there was a good workaround to convey intent of purity despite that.
I think you're a new engineer - R has always been math, from the bottom up. Python is the relative newcomer to math.
Go was exciting before Docker existed.
JS has the browser, and then had Node.
Scala has functional programming and the JVM. Spark is not really a "Scala thing" (although it is written in Scala). You can use other languages with Spark.
Tomcat is hardly the first thing that comes to mind with Java.
Python was not popular because of maths. Python was very popular long before the scientific computing stuff. Python was chosen for that for two reasons: ease of extension using C, and being extremely easy to read and write.
There's a reason that Python is commonly referred to as 'executable pseudocode'.
But yes, Ruby had Rails, JS had web browsers, Perl made string handling easy, Java was appealing to managers (don't let your moron employees write undefined behaviour: CHOOSE JAVA!), etc.
> D's only issue is that it does not have general adoption, which I'm willing to assert is only because it's not on the forefront of the cool kids language of the week. Which is a good thing.
The reference compiler not being open source makes a language not cool with the cool kids. (Not that I'm blaming anyone).
I'm not sure that "it's going to stay", as you say, but at the very least it's been hugely influential on C++ (if constexpr, anyone?) and even for just that it is and has been valuable for everyone working in C++ land.
I think D will hit some sort of critical mass soon, probably through the form of a corporate sponsor ( a la google and Go).
Obviously, it's entirely possible that D will indeed fade away, but that would be a real shame.
The way D is designed is very holistic: the combination of ranges, UFCS and CTFE (and modules) all made me really hate using C++. I've ended up being more productive (even with toys that I never touch again) in D than with that dynamically typed languages like python and js.
Walter, Andrei, and Herb proposed "static if" in N3329 (after it's big success in D) which was ultimately rejected. Ville Voutilainen explicitly revived it in N4461 with changes. Ville then iterated on that proposal a few times (P0128R0 and P0128R1). Finally, Jens Maurer took that and made some syntax changes with commitee input resulting in P0292R1 which was the accepted proposal. "static if" from D absolutely was the inspiration for "constexpr if". Each proposal references the last in a chain going back to Walter, Andrei, and Herb's proposal.
I'm not sure I understand what you're trying to say. IIUC the causality in your last sentence is opposite to what've you been arguing? Maybe it's just a typo, but either way you're going to have to provide evidence.
C++ has been gaining constexpr features for years. These have nothing to do with D at all, except in the sense that all languages everywhere influence each other slightly. Certainly constexpr wasn't drawn directly from D.
if constexpr was the obvious logical next step. It has been suggested and proposed for years. Yes people formally proposed static if, which was heavily inspired by D's static if, but that proposal was rejected because it was poorly designed, and C++'s new if constexpr is about as different as it's possible for two compile-time conditional compilation constructs to be.
I want to say it's somewhat good, but sometimes it just doesn't work out too well, and experience may vary between developers. But I totally agree, if some of it's quirks were sorted out... Sidenote: I'm really sorry I can't mention any off the top of my head, it's been a year or more since I last touched it. I did enjoy using dub, but ran into some odd issues from time to time. If it breaks, you can't use it properly basically.
Interesting. I prefer to write in high-level strongly dynamically typed garbage-collected languages when I can.
But of course I can't always do so and get the performance I want. My approach is generally to prototype in languages like Python, but implement in C89. See: https://www.youtube.com/watch?v=WNTOpl30MIQ . That's 10s of thousands of times faster than our initial prototype and...
We profiled all sorts of things in order to make it that fast. Right down to cache misses, branch mis-prediction, etc, how concurrency on the CPU interacts with I/O.
Not going to start a flame war. Everyone has their opinions, However there are languages that come and go, and then are swift to become popular, but then are left to rust, because people stopped having smalltalk about them.
For what definition of dead?
Sure, not so many use it for new projects, but it is still being maintained. There is an upcoming major release which will output ES2015.
I've got some tens of libraries/apps written in CS, no plans to migrate them. Works as well today as it did 3 years ago.
> I've got some tens of libraries/apps written in CS, no plans to migrate them. Works as well today as it did 3 years ago.
You might have a different view to the above then. Sounds like you're using it for the kinds of things it's good for, perhaps. (Languages can fall into vogue and (infuriatingly) go viral for all the wrong reasons... with everyone fighting it and not understanding why)
Not sure I'm using it for anything special... But one reason I chose it is my preference for minimal syntax, which is not a fashion thing and has not changed since I did Python 8 years ago. It also fixes some bugs in JS, like defaulting to globals on omitted `var` or implicit conversions on `!=`.
I do wish to have gradual static typechecking available though. This may unfortunately force me over to TypeScript or ES2015+Flow.
Heh, that's kind of funny. If that's the main criteria for "death", then Coffeescript is in good company. Except for Visual Basic, which is basically a cockroach refusing to be killed by Microsoft, everything else is alive and vibrant.
Possibly horrible by geek purity standards, but waaaaaay more used than D :)
I think it says a lot that the only top 5 in the "Loved" tab that's also present on the whole "Wanted" tab is Swift. Not that I use Swift, but it's the one with a mainstream use case today pretty much.
It will be interesting to see how it looks in 5 years.
To paraphrase: On a long-enough timescale all languages are fads.
The ultimate power that can actually be manifested in physical reality (as far as we know) is still Turing Machines[1]... the rest is mostly ergonomics.
[1] Well, QM may add a "little bit" of efficiency, but it doesn't add any oracular power, per se. AFAIUI, at least.
Yes it most certainly is. All the power system applications written in the 60's and 70's were done so in Fortran as they had to be fast and run numerical analysis on massive matrices. However, a lot of it is being rewritten in more modern languages like C++ or C depending on the application.
Probably some, but in the industry I'm referring to, nobody is going to let you write a critical system in some new relatively unknown language. Options are Fortran, C, C++, or Java. Julia is cool, but still really new in the cosmic scale.
> nobody is going to let you write a critical system in some new relatively unknown language.
Whose permission do you seek who will "let you" or not "let you" write a critical system in some new relatively unknown language? What if you work for yourself or are creating a startup?
Obviously a startup with no history is a totally different context. The parent commentator did mention "industries". Power in particular (think nuclear power especially!) are... necessarily conservative.
Ha! I can't say I've ever programmed in Fortran[1], but surely it too will perish... eventually. Idle meta-thought: It's actually kind of interesting how hard it is to replace "legacy" in programming... I wonder if there's something we could/should be doing to make it easier to do on a large scale?
[1] I think it's spelled that way these days, but of course given the context of the thread, maybe you're talking about old-school FORTRAN.
I think you answered yourself why D is not more popular with the "cool kids". C++/Java/C# are overengineered, verbose, horrible languages to use. Java is a bastard of C++, and C# is the better looking bastard.
Yes we use them, and even like them in a weird Stockholm Syndrome way, but they're not fun to work with. We use them because we need them, not because we enjoy them.
Disclaimer: the personal pronoun "we" as used here means the author plus zero or more people.
Name another language + tooling ecosystem where you can do ALL of: * Perform automatic refactoring of a 100k+ LOC project and be confident that absolutely nothing breaks. * Reliable edit and continue in the debugger. * Fast incremental compile times. * Easily pull in third party libraries without messing with include-dirs, link-dirs and whatnot, and automatically get the documentation built in and ready for autocompletion.
I won't list all other things you can do but no other popular language even come close to the tooling of Java or C#. C and C++ has too many different build systems and too much lazy evaluated templates and typecasts for the IDEs to handle well. Python, Ruby, JS, PHP...well they are all dynamic so good luck with fancy IDE features.
Erlang as some pretty dope tooling, but still Java has a much larger selection and some low-level tools that are just fantastic for performance (JMH is one of my favorites).
XML? That's probable Spring. I hate that thing. But Java's tooling for monitoring is crazy good. The benchmarking harness that gives back the assembly code generated for hot code, unmatched on any other non-native language. The editors and how good hinting and auto-complete are, I don't know of another language that integrates so well.
Java really raised the bar on tooling and other languages/platforms have really had to drive hard to get just a close comparable place.
Java had a full court press advertising campaign with powerful partners at a time when 'web' was the new thing and it was going to be that language. The superior support and tooling was a result and sustains it to this day.
Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D.
D's only issue is that it does not have general adoption, which I'm willing to assert is only because it's not on the forefront of the cool kids language of the week. Which is a good thing. New does not always Mean, improved. D has a historical nod to languages of the past, and is trying to improve the on strengths of C/C++ and smooth out the rough edges, and adopt more modern programming concepts. Especially with trying to be ABI compatible, it's a passing of the torch from the old guard to the new.
Regardless of your thoughts on D; My opinion is I'm sold on D, It's here to stay. In 10 years D will still be in use, where as the fad languages will just be foot notes in Computer Science history as nice experiments that brought in new idea's but were just too out there in the fringes limiting themselves to the "thing/fad" of that language.