Is D an Underrated Programming Language? 386
Nerval's Lobster writes: While some programming languages achieved early success only to fall by the wayside (e.g., Delphi), one language that has quietly gained popularity is D, which now ranks 35 in the most recent Tiobe Index. Inspired by C++, D is a general-purpose systems and applications language that's similar to C and C++ in its syntax; it supports procedural, object-oriented, metaprogramming, concurrent and functional programming. D's syntax is simpler and more readable than C++, mainly because D creator Walter Bright developed several C and C++ compilers and is familiar with the subtleties of both languages. D's advocates argue that the language is well thought-out, avoiding many of the complexities encountered with modern C++ programming. So shouldn't it be more popular?
The languages with the biggest gains this time around include JavaScript, PL/SQL, Perl, VB, and COBOL. (Yes, COBOL.) The biggest drops belonged to the six most popular languages: Objective-C, C, Java, C++, PHP, and C#.
The thing about new languages... (Score:5, Insightful)
... is that they need to be better than old ones. Not just objectively better, but measurably better. And not just measurably better, but with enough margin as to offset the cost of learning a new language... I'm not going to ditch C++ just to learn D unless someone is paying me to. Show me the money!
Re:The thing about new languages... (Score:5, Insightful)
And that's just on a personal level.
On a business level you've got to offset the risk associated with using a less known language with probably a much smaller toolstack around it, a smaller pool of available developers, and a less certain future. There has to be a very compelling reason for a business to not just go with c++ or java or .NET.
Re: (Score:2)
I'm wondering how you square this view with the abundance of Java.
Re: (Score:2)
And then there is a the question of portability. There is a C compiler for virtually anything powerful enough to support a compiler. C++ rules out some of the smaller microcontrollers but is available virtually everywhere else. Sure the code may need some work to remove platform specific assumptions, deal with missing library functionality on very small targets or deal with compiler bugs but that is still likely to be much easier than a complete rewrite.
Any new language that is intended to be compiled to na
Re: (Score:3)
The new trend, as per the aforementioned rust, is to target LLVM.
So there still may be places that the Gnu Compiler Collection can go that LLVM can't but port Clang and you get the rest for free.
Re: (Score:3)
Re: (Score:3)
I'm nowhere near smart enough to do C++ well.
This is a bit of an illusion. If it would benefit you to know C++ better, I'd encourage you to not give up easily.
First, it's an illusion because when you read some template code by an expert like Andrei Alexandrescu, it's easy to imagine that this code flowed out for him as easily as writing Python is for you. But writing that kind of code is a slow thoughtful process even for experts, and even they get it wrong sometimes.
Second, it's an illusion because you're comparing your limited experience with C++ p
Re: (Score:2)
You don't need a new paradigm. When C came along to small computers, it took over a very large part of the Pascal mindspace. C is a better system programming language, and Pascal has its warts (normally fixed by implementation-specific changes), but for most of the development community there really wasn't that much paradigm difference between the two.
Re: (Score:3)
length of an array was part of its type
The size of a statically allocated array simply is part of it's type. It's size is known at compile time, it can be allocated on the stack, or embedded in a structure without a pointer (keeping memory contiguous, without dynamic allocation, and without creating an incidental data structure.) All of which is indispensable for systems programming. It's a feature not a bug. Maybe it was a design error to make that the default array type, but simply having it is not a bug.
Gotta react to the market (Score:5, Funny)
I guess the users of languages don't like readable, simple, or maintainable code.
Confirmation!
Re: (Score:2)
A language like C++ has ugly s
Re: (Score:3)
Back when I was writing COBOL (over twenty years ago), it wasn't particularly maintainable or readable, and was not well-structured.
For some purposes, it was maintainable and readable, but if the problems got complicated its verbosity made it difficult to understand. In the meantime, when I used it it did not have functions, meaning that if you had to calculate anything separately you had to CALL or PERFORM different code in another statement, returning the answer in a variable.
COBOL doubtless has cha
Cute specs, call me when you turn 18. (Score:5, Informative)
FTA:
"D offers compilers for all three platforms (Windows, Mac and Linux) as well as FreeBSD."
"There's a D package registry that currently lists over 400 third-party packages."
That pretty much sums it up.
/ All three platforms!
Re:Cute specs, call me when you turn 18. (Score:4, Funny)
"We play both kinds of music. Country... and Western."
- The Blues Brothers
Re: (Score:3)
All three platforms, plus FreeBSD. So there's compilers for 133% of platforms! How can you compete with that?
Re: (Score:2)
Obviously the compiler has a floating point bug.
Non-Dice, Non-tracking link to D (Score:5, Informative)
Jeezus fuck. Its bad enough that we get Dicevertisments, but Diceverticements with Campaign ID's on them?
Anyway this is the direct link to the D Language [dlang.org]
Perl, my favorite language is rated higher... (Score:3)
... but I still think the rankings here are just about meaningless.
Re: (Score:2)
PERL has a staying power. Other scripting languages come and go in popularity. Ruby for example. But eventually the large base of PERL programmers turns out new generation of PERL programmers by mentoring and language selection from being in position of senior / principal engineers and architects. Python is still surprisingly staying up there, being propped by Google and few other corps., but if not for Google, Python would go the way of Ruby. There is a slight chance that Python will manage to stay long en
Re: (Score:2)
Re: (Score:2)
Yes, for C the effect is especially strong. It's not like it would not be easier to use other languages, like Swift or Java, but somehow C is up there all this time. There is a reason.
Re:Perl, my favorite language is rated higher... (Score:5, Informative)
When doing low level system programming, there aren't that many viable choices out there. C, C++, possibly ObjectiveC (not familiar enough with it to tell for sure). That's about it. Of those, ObjectiveC is, pretty much, a one platform language. C++ is used quite extensively, but it is way too complex, resulting in most C++ programmers not knowing what the 1@#$@!# they are doing. Also, some C++ features are not suitable for some low level scenarios. For example, you probably wouldn't want your kernel code to throw exceptions, or do iostream formatting, in kernel code.
C, on the other hand, is a very simple language. It has no expensive features (though, to be honest, that mostly means that if you need something expensive, you'll need to do it yourself). As such, it is without competition for what it offers. The most it loses in market/mind share is through scenarios that used to require low level system programming but no longer do.
As for D....
D advertises itself as supporting this mode. My employer chose to develop a low-level high performance low latency system in D. I've been programming it for the past half year. I'm not overjoyed. I don't hate D, but my personal opinion is that we'de have been better off going with C++ (though, to be honest, I love C++ like few of my peers do).
I have two main gripes with it on that front. D has a horrid GC (though no GC provides the latency requirements we need), and though it claims you can do without it, you really can't. At least, not without giving up on much of the language features and almost all of the standard library. When comparing to C++'s ability to use custom allocators with the standard library, D's phobos seems deathly pale.
D also claims to support RAII semantics. I happilly went about implementing a reference counting pointer, only to find out that there are cases where you cannot use a struct with a destructor, and there are cases where you theoreticaly can use one, but in practice find that the compiler will not call your destructor. All in all, RAII is an untested unutilized option in D.
Shachar
Re: (Score:2)
The whitespace convention that drives so many people bonkers (and among other things, prevents quick one-line commands) and other language features may be annoying, but the language has got to be one of the most readable duck-typed languages available. Since all but the most trivial code is read much more often than it's written, I'd call that Py
Re: (Score:2)
A lot of sysadmins, devops and product integration people using perl for quick filters so they don't have to learn awk or sed with:
cmd | perl -e 'stmt;stmt;stmt;stmt;stmt' | cmd
You cannot do the same thing in python easily and that is an issue as you mentioned. Another issue is that the whitespace is creating havoc in bigger team and multi-platform projects where people work with many different environments and editors and small whitespace changes are sometimes not so easy to catch and can have code changin
Should be, but it isn't. (Score:5, Interesting)
Should be, but it isn't.
Here are couple of reasons why (IMHO):
1. The main compiler is not free-software (as in freedom).
The compiler package (called 'dmd' [http://dlang.org/download.html]) has a non-free license,
and regardless of any wishi-washi explanations about front-end/back-end freedom, the fact is - it is not free, and will never be included in any distribution's main repository.
2. The free-software compilers (GDC, based on GCC and LDC, based on LLVM) are always lagging behind in features and compatiblity.
Walter Bright and Andrei Alexandrescu (the two lead developers) focus mainly on DMD, and so the free-software version will never catchup.
3. Building the compiler and the 'standard library' (which was itself a moving target up until recently) is done with really broken 'makefile' system, which requires one to put things in specific directories. Not fun for package maintainers, or for people wanting to build the lastest versions. Time to move to CMake (or autotools).
4. poor eco-system and package-manager. There is 'dub' (http://code.dlang.org/) but it is barely useable in the real-world. For example, the slightest error in the 'package.json' file of a package, and not only nothing works, but also the error messages are next to useless.
5. Less-than-great platform support. Despite claims to supporting Windows,Linux and FreeBSD - it seems some compilation/linking things are not functional on Linux (haven't tested FreeBSD). There's seem to be a big focus on Windows, and little motivation from the top-brass to give a 'push' to make it work perfectly on Linux.
6. A pet-peeve: The 'string' type is very annoying. Regardless of how marvelously it is engineered to fit perfectly within the D-language paradigm, using it is a pain, especially when needing to pass it around or modifying it.
An example is http://stackoverflow.com/questions/20747893/convert-auto-string-to-char-in-d
That being said,
The compiler 'dmd' is blazingly fast,
and once everything is setup correctly (and if one ignores the non-free issue), then programming in D is so much fun! It really feels like this: http://xkcd.com/353/
Re: (Score:2)
Failure by design?
D is the Betamax of programming languages, well thought out, feature rich but flown into the ground.
Re: (Score:2)
I tried it (Score:5, Interesting)
At least it has a Wikipedia page (Score:2)
The deletion ninjas on Wikipedia won't even let nim have it's own article. So D has a leg up on at least one "next-gen" language.
Yippee! (Score:2)
PL/I on TIOBE (Score:4, Interesting)
Re: (Score:2)
Man, that's a blast from the past. In my first year of university back in fall of '82, we used the PL/C subset of PL/1. Kind of a shitty language for introducing people to programming, but I'd been coding BASIC and assembler (Z-80) since I was 14, so it was mainly an issue of learning syntax for me.
Re: (Score:2)
Let me guess... WUSTL? I remember that we wrote PL/1 using the PL/C subset in '80 and '81. Go WUSTL Bears!!!
:D (Score:4, Funny)
Perhaps they should call it :D. At least it would seem more friendly.
If I were a big name researcher (Score:2)
I'd publish a paper, "C syntax considered harmful" with roughly the same kind of rationale as the "Goto considered harmful" paper.
Why D isn't more popular (Score:5, Insightful)
I've looked at D before. It looks promising, and I've considered using it. The reason I don't is a bad reason, but it's the most common bad reason: legacy code.
I have two hundred and sixty four thousand lines of code in my personal project/library archive (my own code, not counting custom versions of external packages like openssl and portaudio), all in C/C++, all with a unified build system, that's been ported and debugged on serveral platforms. Every new project I start uses those core libraries and header files. When I think about switching to a new language, my biggest concerns are how new code will integrate with my existing, how the new language will make use of my existing libraries, and how to remain productive in a dual language environment. The long term gain might eventually make it worthwhile - but it might also just cost me time should the new language die out or not support a platform I need it to.
I simply can't justify the gamble.
Re: (Score:2)
The reason I don't is a bad reason, but it's the most common bad reason: legacy code.
Note that this is not the only reason you list, you also mentioned the doubt that the language will stick around. Which is another good reason.
c++11 does it in (Score:3, Interesting)
'D' was somewhat appealing until C++11 was released and support started. That removed any core feature advantages 'D' had.
The whole mess of 'D' having automatic garbage collection as part of the language turned systems programmers who the language is supposed to target and also makes the language much more difficult to implement. Yes the compiler is easier to write but 'D' is much heavier than C++ feature wise erasing any advantage it may have had on the compiler side.
So other than compilation speed what 'D' offers is marginally nicer than C++ but brings along with it a bunch of baggage, limited platform support and some very questionable engineering decisions.
I personally would rather see C++ resyntaxed so that it's easier to compile. Unfortunately that would break source compatibility and have a bunch of other issues as well.
Re: (Score:2)
I still think legacy code and legacy expertise are the biggest obstacles, and they are formidable.
Re: (Score:3)
You can use D without automatic garbage collection, but most of the system libraries depend upon it. The two main language designers are working on an architectural change so you can use the system libraries with or without garbage collection as you choose.
I really wanted to like D, but the dependence on the garbage collector is a deal-breaker. That's a pretty big oversight for a language trying to compete with C++. It makes me wonder how well they've thought out using different subsets of the language without paying for what you don't want, which is one of the reasons for using C++.
Yes it would be nice to have a C++ with a cleaner syntax, but C++11 is already a huge improvement, and C++14 will be even better. If we can finally get concepts, it'll be amazi
Being an excellent language isn't enough (Score:2)
The problem with D isn't the language, which is excellent. Unfortunately, superior languages loose out to inferior ones all the time. (Yes, I'm aware that superior and inferior are subjective terms.)
Language quality is nice, but there are several factors that are more important when it comes to market success. These factors include: third party tools (compilers, debuggers, IDEs, profilers, etc.), third party libraries (both quantity and quality are important here), momentum (C++ and Java are pretty well
D has problems, and not just a few (Score:5, Informative)
I'm an undergrad Computer Science student, and last year I used D for my Compiler Design course in which I wrote just over 18000 lines of D code (including tests and documentation). My experience with the D programming language has meant that I'll probably never use it again for any serious work. The truth is D has some very deep-seated problems within the language, standard libraries, and even the community, which (IMHO) will prevent it from seeing widespread use before a version 3 sees the light of day. To elaborate a tad:
1. Walter and Andrei refuse to make any breaking changes, despite major players in the D ecosystem begging them too.
The language and libraries are riddled with inconsistencies, 'gotcha's', and general ugliness that require breaking changes to fix, and proposals or pull-requests relating to such things are almost categorically rejected on the basis of "lol breaking change". In one case, a well-known community contributor wrote an entire breaking patch to remove virtual dispatch by default (for performance reasons), posted it, got approval from the community, and finally got approval from Walter who merged it (despite it being a breaking change), only to have it all reversed the next day when Andrei found out about it because he "would never have agreed to it". Several medium to large companies that have actually adopted D have literally begged Walter and Andrei to break code and fix the language issues now before it's too late, to no avail. Some examples of such language issues include:
- A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but '@property', and '@nogc' are annotations)
- Huge portions of the standard library are missing attributes like 'pure' and 'nothrow', which directly impacts user code that attempts to include them
- Simply too many attributes, with no attribute inference (template functions/methods infer attributes, but these cannot be virtual and so cannot be overridden in sub-classes)
- Many others - see this example: https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d
Some of these may seem nitpicky, but they give the language the overall feel of one that is incomplete, hacky, and inappropriate for industry use.
2. Can you turn the garbage collector off? Sure! But don't try and use the standard library if you do!
Most of the standard library is written assuming the garbage collector will clean up after it. Turning it off and using the library therefor means memory leaks ahoy, and leaving it on makes real-time solutions difficult due to the 'stop-the-world' nature of D's GC. There is an effort underway to remove this dependence on the GC, and a short term solution was implemented with the @nogc attribute. That is, yet another attribute, and yet another breaking change that will be rejected when the proposal pops up in a few years to remove the then unused attribute.
3. The documentation poor.
In many cases, the documentation is either out of date, or extremely lacking. At last check, there were still pages referencing deprecated features, or features that have yet to be properly implemented. In the cases that the documentation is correct, it usually lacks basic things such as usage examples and proper explanations of function overloads (and their parameters). To top it all off, the actual presentation of the documentation is incredibly poor when compared with something like Scaladoc.
4. Instead of fixing things, the developers keep tacking on new features, and patches don't get reviewed.
Walter and Andrei are focused on new features, and seem to leave much of the bug-fixing to the community. That's great, until the community proposes a breaking change and instantly gets shot down. On top of that, there are god-knows how many patches and pull-requests that have been awaiting review for *years* without having even been looked at. Such things result in low contributor moral, and have resulted in several community mem
Little blue flowers (Score:2)
I haven't heard of D (I'm not a programmer), but it would be great if the trademark/symbol was little blue flowers, for the love of PKD.
NO (Score:2, Interesting)
As long as it's a garbage collected language it goes in the heap with Java, C# and the rest of the garbage collected languages. If you want to compete with C and C++, you need real memory management.
Re: (Score:2)
Re: (Score:2)
Mod Parent "Edgy" (Score:2, Informative)
It's actually in process of feature freeze for 1.0 release right now and it's usable enough for Mozilla to be developing their new layout engine in it, but do tell us more about all you've ascertained by looking at their website's front page.
Re:COBOL (Score:5, Interesting)
I never understood what D offered that wasn't offered elsewhere.
Mainly, it's a systems programming language, meaning that it gives the programmer fine-grained control over memory and operations so that you can write operating systems, drivers, and high-performance applications. This is relevant because, aside from the two biggies (C and C++), there aren't a lot of other languages in this space. I mean, there's Objective-C (which sort of half-asses it), and recently Go and Rust arrived on the scene. All the other popular languages are pretty much for scripting (Python, JavaScript, PHP, etc.), or running atop a managed virtual machine (Java and C#).
As for what it offers... it's basically a re-invention of C++. No, no... it's deeper than that. It's the idea of C++ re-invented in such a way that you get most all the power and low-level control of C++ without so many of the dangers and difficulties.
Unfortunately, D has struggled to gain wider acceptance. It fractured it's community when D version 2 broke backwards compatibility with D version 1, and the forums (which run on a dedicated Usenet server, FFS) are filled with endless commentary about what does and doesn't work in the latest point release of the DMD compiler. Bright and Alexandrescu have certainly designed a compelling language, but they seem (from my distant vantage point) to be mired in implementation details... yeah there's a standard library and everything, but the surrounding ecosystem (standards, tutorials, tools, IDE's, API's, packaging, etc.) hasn't made the leap to that sort of functional minimum you see with (for instance) node.js or Haskell's "batteries included" experience.
TL;DR - D's a super awesome low-level language, but it's not yet a platform.
Re:COBOL (Score:4, Interesting)
I'll give you some context on where I come from, I'm professionally 100% C. Kernels, RTOSes, etc.
I played with D a bit, it's not for me, and I'm not here to sell people on it. I appreciate the effort you put into your response, but my original lack of understand on what D really offers remains. Responses like "high-performance applications" tend to flow over my like water over a duck's ass. (I'm the ass)
JavaScript isn't just for scripting anymore. The run-time performance is acceptable for some rather serious scalable software. And there are better static analysis tools now, although Java and a few others still beats JS at unit testing and validation.
There seems like there are a dozen new languages every year, D has been around for a while. I wonder if it hasn't taken off because of people like me not really getting why I would switch over.
Re: (Score:3)
JavaScript isn't just for scripting anymore. The run-time performance is acceptable for some rather serious scalable software. And there are better static analysis tools now, although Java and a few others still beats JS at unit testing and validation.
Yes, it is. The performance doesn't make it "not a scripting language".
The performance of most other scripting languages has also increased. That doesn't make them "not scripting languages" either.
The major difference between scripting languages and other languages is interpreted vs compiled. And the main reason for that is still dynamic typing vs static typing. Though by now the lines have been blurred quite a bit. Java isn't usually referred to as a scripting language even though it needs a bytecode
Re: (Score:3)
JavaScript is compiled to native instructions. But that's actually not even relevant here, see below.
But the real quality of a scripting language is if the CST (concrete syntax tree) can be directly used, or if it must be translated to an AST (abstract syntax tree) to be interpreted or compiled.
It has more to do with the internal structure and limitations of parsing and grammars than it does with the life cycle of your tools. The old idea that it is about edit-compile-link-run versus edit-run was always a s
Re: (Score:2)
From the applications world, the order of the day is often to get stuff done fast so that it ships. That often leads to a bad feeling from systems level programmers when they see "typical" application code. I like templates myself, when used sparingly, but have seen it misused and tortured so many times and systems bloated needlessly.
Systems programming generally wants to have control; details are important, speed and size are important, and there can't be any magic happening behind the scenes that the p
Re: (Score:2)
Re:COBOL (Score:5, Informative)
Here's a paradigm for you: "frog in a well". The frog looks up all its life and thinks that the entire world outside the well looks just like that patch of sky it sees. C programmers often view objects this way. (I am a C programmer, but I do not view objects that way.)
On a more concrete note, you better review your "all exceptions implementations cause a performance hit" claim. Modern exception handers are not the same as your grandaddy's exception handler. Apparently unlike you, I have verified that there is no discernable performance hit for exceptions with the compiler I use.
Re:COBOL (Score:5, Funny)
When Chuck Norris throws an exception, it is always fatal.
If that isn't a hit to performance, nothing is.
Re: (Score:3)
You're actually wrong. I do most of my programming in Java since most of my work now is in server side parallel code. However I would never make the mistake of calling it a systems language nor would I add exceptions to a system language. I have some experience with compiler and JIT design and I have programmed in assembly enough to know that exceptions are slow. One of the guys here described it well enough. Most implementations use setjmp or the equivalent. The rest of you just don't have a clue.
I have pr
Re: (Score:3, Informative)
Templates and template metaprogramming do not cause performance degradation, but generally produce faster code. Namespaces are useful, particularly with libraries, and give the option of using the shorter name where it's local and the longer name where it's not as heavily used. Object-oriented programming is very useful sometimes, doesn't slow things down particularly with a good implementation, and doing it in C is awkward. The fact that you can write C to do anything doesn't mean you should write C to
Re: (Score:3, Insightful)
No, it means the GP doesn't know what he's talking about.
Re: (Score:2)
It's the idea of C++ re-invented in such a way that you get most all the power and low-level control of C++ without so many of the dangers and difficulties.
What is the idea of C++? I've used it a lot and never thought that it might have a central organizing idea.
Re: (Score:2)
The central organizing idea is you keep piling more and more crap on C that you think might be useful for whatever 1% use case you are interested on but still does not cause enough of a performance hit for systems programming. C++ is the kitchen sink of programming languages. It is the Perl of systems programming.
Re: (Score:3, Insightful)
Re:COBOL (Score:4, Insightful)
Otherwise, it's likely that every feature you care about in C and C++ is available in D.
Re: (Score:2)
I guess the guy who downmodded me never tried programming in any other language. Try Python, LISP, Java, C# and then say what I wrote isn't true.
Re:COBOL (Score:4, Interesting)
AFAICT, it's an effort at C++ done right.
C++ has a whole lot of infelicities that it acquired for historical reasons and can't really get rid of. The really big problem was C compatibility. Remove the need for that and you can get all of C++'s benefits (except C compatibility, which is usually not important) with a lot less hassle. There's lots of other things over the development of the language that sure are not what people would do nowadays. When the first standard came out, it had lots of implications that were not well understood, such as exception safety and the fact that templates are Turing-complete. The more recent standards make it a much better language, but about the only C compatibility that has been ditched is the repurposing of "auto", which nobody used anyway.
The question is whether this is worth it. There's lots of good C++ compilers out there. There's lots of books and tutorials and websites on how to write good C++. There's tons of C++ code that isn't going to be rewritten any time soon. There's oodles of C++ developers (not all of whom are good). Given a choice between C++ and D, with no other considerations, I suspect D would be by far the better choice. Given the existing situation, it's unclear that D will ever be more than a niche language.
Re: (Score:2)
C compatibility is the least of C++s problems.
Re: (Score:2)
Ditching C compatibility makes C++ fast to compile, allows for a decent switch statement and better operator precedence, and frees up a lot of things to change the syntax to something less ugly.
Re:COBOL (Score:4, Insightful)
English isn't a particularly nice language. It has one big advantage over other languages though. Can you figure out what it is?
Re: (Score:3)
Pleasant diphthongs?
Re: (Score:2)
Arbitrary spelling that must be memorized for every word?
Ambiguous syntax?
Homonyms?
Homographs?
Vagueness in general?
Re: (Score:3)
Arbitrary spelling that must be memorized for every word?
This is the one thing that drives most non-native English speakers crazy. Interestingly I found that many native English speakers are not even consciously aware of this difficulty in learning the English language.
Stuff like
You have to polish my car until it is shiny.
But: The Polish car salesman made me a good deal.
Or
I read something in todays paper.
But: did you read that one article?
Then, for good measure you have words that sound the same but, of course, are spelled differently, like knight and night or we
Re: (Score:3)
SNOBOL.
Re:COBOL (Score:5, Insightful)
ok .. go ahead and name one language that isn't about domination and oppression. just one.
Esperanto.
Yaz
Re: (Score:2)
but could someone please throw some light on what would be a purported English advantage
I think "widespread usage" is what AC was getting at, keeping in context to contrast with D, which is ostensibly rather nice but obscure.
Re:COBOL (Score:4, Interesting)
That's your argument?
It wasn't an argument, it was a statement to illicit answers to an unsaid question. But let's pretend it was argument, since that is how you chose to interpret it.
There are technical merits that D has over C, I'm not likely to use D over C, but that's really orthogonal as my job requires I use C and it's not really up for debate. There are some niceties(?) that D has over C++, but I'm even less likely to use a language because it seems nicer. The features of D doesn't seem like anything that isn't solved (but perhaps in an ugly way) by C++11 and Boost.
D's biggest strength is also it's biggest weakness. It's not a huge leap for a developer that knows C++ (or C) to learn D. But if you're going to switch tools, why not go for broke and switch to a pure functional language that will completely alter the way you have to design your software, perhaps in the ML family?
Re: (Score:2)
it was a statement to illicit answers to an unsaid question.
Elicit. It took me several tries reading your sentence and reading all the way up the message chain before finally understanding what you were trying to say lol. The rest of your comment was interesting, though. Well, technically that part was interesting, too.
Re: (Score:2)
You're generally better off checking Gartner or RedMonk or even LangPop.
Re: (Score:3)
Re:COBOL (Score:4, Interesting)
Except D has compile-time evaluation of a significant subset of the language as its alternative to the C++ preprocessor. That, among other things, means large D projects compile orders of magnitude faster than equivalent size C or C++ projects. Fast compile times were one of the killer features touted when Google launched their 'Go' language, but D compiles as quickly or more quickly and is a lot closer to "C++11 with simpler syntax" than Go.
But if you're going to switch tools, why not go for broke and switch to a pure functional language that will completely alter the way you have to design your software, perhaps in the ML family?
Fair point. I can't argue with that.
Re: (Score:3)
Nah, more likely an increase in retirement rate amongst COBOL programmers, requiring fresh blood to maintain the ageing applications.
Re: (Score:3)
Rule number one in C++ : avoid the preprocessor unless you really have to use it.
Things like:
#ifdef UNTESTED_FEATURE
#include "crazy_new_untested_code.c"
#endif
Are a blight, and one of the first things that I remove from C++ code.
The preprocessor does not work on the same level as the compiler, and therefore has no knowledge of rather important aspects of the language like scoping or namespaces. If something can be done as a language-level constructor i
Re: (Score:3)
A preprocessor is the only way to ignore syntax errors.
Here's how to break your compile even when UNTESTED_FEATURE is undefined:
#endif
The preprocessor can't save you from developers who check in uncompilable code. I'd argue it makes the situation worse: overuse of the preprocessor makes breaking the build easier than ever and makes figuring out why it doesn't build no fun at all. Use a branch in your version control for that.
Here's your mystructure example in D:
struct mystructure { int one; static if(GREATFEATURE) int two; };
How simple is that? Sadly, C++ doesn't have static if yet, but the D implementation proves you don't ne
Problems in C++ (Score:2)
>What kind of complexities has modern C++?
1. C++ still doesn't let you query a C-style array to determine its size, even though that functionality is tracked in dynamic arrays anyway, and can be calculated from staticly defined arrays within their own scope.
So every function using C-style arrays must also pass in a size_t holding the array size. This hurts readibility by wasting room on the parameter list, and exposes you to buffer overflow errors.
Legal:
int arr[10];
for (int i : arr) cout i;
Illegal:
void
Re:Problems in C++ (Score:5, Insightful)
1. Dude ... if you want to query the size of an array, use a vector. No, it doesn't make your code less readable. And, no, you don't have to use .at() everywhere: C++ has this thing called operator overloading. Maybe you've heard of it. You can use array syntax with vectors. Use vectors.
2. I'd like to know what functionality you think you need string.h for when using C++ strings. I've found the standard library string type quite feature-complete.
3. C++ isn't an interpreted language; of course it won't have much reflection.
4. Forward declarations are not for saving the compiler time. They are for declaring a linkage interface with external code. If you ever even thought seriously about writing a C++ compiler you would know the language is not designed to make doing so easy.
5. C++11 is awesome. Any old language will have some cruft, but C++ has managed to keep it where you don't run into the cruft unless you're dealing with old code. That's the best you can hope for.
Re: (Score:3)
3. is nonsense. Nothing stops C++ from having all the benefits of reflection e.g Java offers.
4. is wrong
class A;
A* someVar.
That is a forward declaration and has absolutely nothing to do with linkage, it is mainly used to avoid circular dependecies in header files or simply to save compile time (by avoiding to include the header).
You mix up forward declerations with 'extern'al declerations.
Re: (Score:2)
If you tried to put Java reflection in C++, you would end up with Java slowdown in C++.
I guess there are cases where the compiler could be a little smarter rather than requiring forward declarations. I'm not sure whether that would be a good thing or would lead to more confusing error messages.
Re: (Score:2)
I'm pretty sure I do.
A kilobyte per class is definitely significant for many applications, and not just deeply embedded ones. And, reflection requires more than tacking on data to class manifests. The power of reflection comes not from just being able to see your own type information, but from being able to invoke methods you didn't necessarily even know about at compile time based on it. In a static language, this is for obvious reasons extremely hard to do. I'm not saying it would be impossible to do
Re: (Score:2)
I meant "statically compiled language", not "statically typed language". I should have specified. I'm taking it as a given that Java is slower than C++ and C for real codes, and this is not rationally disputable. Memory use is part of performance.
If you added reflection to C++, you could optimize some of the performance overhead away, though probably not the memory use. And, if you're going to do it right, you'll have to carry around metadata per-object, not per-class; you'll at least need one pointer p
Re: (Score:3)
>>1. Dude ... if you want to query the size of an array, use a vector. No, it doesn't make your code less readable. And, no, you don't have to use .at() everywhere: C++ has this thing called operator overloading. Maybe you've heard of it. You can use array syntax with vectors. Use vectors.
Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is t
Re: (Score:2)
1. You were complaining about not being able to get the size of a C-style array in C++. If you're using C-style arrays, you're not getting bounds checking, so why would you complain that you're not getting bounds-checking with vector? It's the same as what you had with C-style arrays. And, I'm aware .at() does bounds checking. That's why I never use it. The performance penalty is not at all trivial; you're talking like a 2x slowdown in array accesses. There is no need to force your program to suffer
Re: (Score:2)
Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is the proper methodology to use in pretty much every case, unless you are so confident in your bounds that its worth the trivial speed increase in access time.
Bjarne Stroustrup's solution:
template<typename>
class Vec : public std::vector<T>; {
public:
using vector<T>::vector
T& operator[](int i)
{ return vector<T>::at(i); }
const T& operator[](int i) const
{ return vector<T>::at(i); }
};
Page 97 of The C++ Programming Language.
Re: (Score:2)
At least these days every compiler supports #pragma once which cuts down the noise of the guards to a single line. Not ideal - I agree we shouldn't need this shit anymore - but it's a lot less annoying than it used to be. Still non-standard though of course, just that so far as I know at least gcc, clang and MSVC all support it. I don't use any other C++ compilers so I can't speak for anything else.
One thing we could very much do with in C++ -- an interface class. C++ abstract base classes are fine, but the
Re:Problems in C++ (Score:5, Informative)
Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is the proper methodology to use in pretty much every case, unless you are so confident in your bounds that its worth the trivial speed increase in access time.
This is usually just plain wrong. I have extremely seldom ever seen "at" used in production code. Why? Because it's usually duplicating a bounds check you've already done. If you're going to naively randomly access a location into a vector without checking if it's within bounds, sure, but that's kind of a nasty smell (also, are you handling the exception that may/will occur?). Most vector accesses occur something like looping from 0 until (but not including size), or using begin/end (either the free functions or the members). At best, the optimizer might be able to deduce you're never modifying the size of the vector during a loop and elide the repeated bounds check. At worst, you're evaluating "if ((_M_end - _M_start) <= i) throw std::out_of_range();" on every iteration.
Regarding point #4, forward declarations aren't to save compilation time or declare linkage. Yes, they can be used to do both, but the prime function is to, well, declare a name and just enough information to be somewhat useful before it is used (i.e. reduce very simple otherwise circular-references). I can forward-declare 'struct A', but I cannot instantiate/allocate it until it is defined (need to know the size, layout, etc.). You can declare a pointer to 'struct A', because well, you know the size of the pointer. Same reason you can't define "struct A { struct A a; };", but you can define "struct A {struct A* p_a; };".
Regarding "#ifdefs", yeah, there shouldn't really be a need for them in this day and age, but they won't go away due to legacy code. If you removed them, you'd break every single codebase in the world. Not going to happen. Additionally, due to the historical lack of variadic macros, there are numerous libraries that rely upon multiple inclusion of the same header to fake variadic macros. If you assumed a "#pragma once", you'd break various Boost libraries as well as even some STL implementations. Headers guarded with ifdef's can only safely be precompiled and reused if any and all preprocessor defines referenced are identical across all usages and inclusion order of every & all predecessor headers is exactly the same for all usages, otherwise you very well may violate the one-definition-rule.
Re: (Score:3)
No. 4 is rubbish. There is no reason why declaring a linkage interface with external code couldn't be done without code duplication. In C there is a reason to have forward declarations, to have a method to hide the interface, and hide the private code. See for example FILE. But in C++ you must declare your private methods of a class, which is total rubbish.
Re:What Kind (Score:5, Informative)
C++ templates, which enable generic programming, are complicated enough to be their own sub-language, and errors that are output by the compiler about any of the templated container classes can be nigh-incomprehensible on their own, and take up a few dozen lines to describe an error like "You need a random-access iterator here, not just a forward iterator".
There are other examples, but essays can be (and have been) written about unnecessary complexity in C++.
Re: (Score:2)
Re: (Score:2)
Why isn't Mindfuck more widely used? And what about Whitespace?
Re: (Score:2)
C++. C#?
Re: (Score:2)
Re: (Score:2)
There are a few things one can mention to get APK to come roaring out of his troll-cave, of which Delphi is the most prominent. Seriously, he loves it, even more than the HOSTS file. In fact, I'm surprised he didn't mention that he wrote his hosts file maintenance suite in Delphi, he usually does. We ought to compile a list of APK signal words so people can put trigger warnings before they use them.
TW: Delphi, may draw APK!
Re: (Score:2)
Not a .NET shill, but it didn't "catch up" to Java in terms of garbage collector. Java has been catching up to it, and only barely. Multithreading support is also a lot better in .NET land (just as safe, but vastly superior APIs and language support).
Still, I totally agree with your point. When playing in JVM/CLR land its often easy to forget how behind other runtimes are, mainly because until you're doing something massive (8-9 figure users), it just doesn't fucking matter unless the code is crap, so these