Is D an Underrated Programming Language?

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

Comments

COBOL

[OrangeTide]

What is the signal to noise ratio for these statistics?

I never understood what D offered that wasn't offered elsewhere. The nice thing (and terrible thing) about C++ is there are several compilers available for it.

Re:COBOL

[Anonymous Coward]

>I never understood what D offered that wasn't offered elsewhere.

That's your argument? What are you comparing D to, other D-like languages that struggle to gain adoption, or the languages they aim to displace? Because if you compare D to C++, for instance, you'll find it offers quite a lot. Maybe not enough for certain applications, but plenty. Unless of course you're going to argue that C++14 is coming, so why bother with learning a new language when you can just relearn C++?

Re:COBOL

[Anonymous Coward]

English isn't a particularly nice language. It has one big advantage over other languages though. Can you figure out what it is?

Re:COBOL

[slashdice]

That's the funny thing about languages like D or Go or Rust that try to replace C. C programmers don't use them. If they get any adoption its from elsewhere (rust seems to be hyped by haskell and rubes, Go by pythonistas)

Re:COBOL

[Anonymous Coward]

English isn't a particularly nice language.

sez u

Re:COBOL

[firewrought]

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

[Anonymous Coward]

COBOL seems to have doubled in the rankings - was there a major defunct project that released their code base, or something similar? Anybody know of a way to view the new projects that apparently led to COBOL nearly doubling in usage in a single year?

Re:COBOL

[Anonymous Coward]

Rust is actually proving itself quite capable and useful at what it intends to do, but I guess that doesn't matter. C programmers won't use it, because they don't want to be called rubes, just to be rubes. Even just an incremental improvement on C would be an incremental improvement, but again... the fear of being labeled a rube is far too strong.

Re:COBOL

[OrangeTide]

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:COBOL

[OrangeTide]

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:COBOL

[_merlin]

Nah, more likely an increase in retirement rate amongst COBOL programmers, requiring fresh blood to maintain the ageing applications.

Re:COBOL

[Anonymous Coward]

D or Go or Rust that try to replace C

A small correction to this:

First Go never tried to replace C, Pike just liked boasting about what Go "could" be used for. Most of it came with the disclaimer "as needed by Google". The rest where completely baseless "Go for real-time embedded systems? Just some tweaks to the runtime." - yeah an exclusively garbage collected language barely out of alpha at that time with a completely broken collector that made 32 bit systems cry would be real-time ready with "just a few tweaks" - next up Pike solves the travelling salesman in O(1) . As you mention Go is better suited to steal marked share from Python.

Second Rust just got to 1.0. Time will tell how well it will replace C++, hopefully they make better use of their first years than D.

Now the first years of D were from an outside perspective a comedy of errors. Having two incompatible standard libraries sounded just amazingly counter-productive. Add in the crippling reliance on the GC by the finally chosen standard library and the language looses a lot of points as a C and C++ replacement. Hey at least those issues are now mostly dealt with - years after the hype of it being brand new wore of.

I give Rust a better chance just because it seems to actually get the feature set right.

 

Re:COBOL

[david_thornley]

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:COBOL

[Anonymous Coward]

he is saying he is dead leave him alone.

Re:COBOL

[Anonymous Coward]

A past riddled with bloodshed, exploitation, and human suffering? In other words, a language fine-tuned for the present.

Yes, because no other language on earth can be described in the same way. Oh, wait, except for Mongolian, Japanese, Mandarin, Russian, Arabic, Turkish, French, German, Swahili, Mayan...

Re:COBOL

[Anonymous Coward]

ok .. go ahead and name one language that isn't about domination and oppression. just one.
that's human nature, not a feature of the language itself.

Re:COBOL

[Anonymous Coward]

What does Rust actually intend to do or to be?

At first it was "A work-in-progress programming language; not yet suitable for users", then it was "a safe, concurrent, practical language", and then "a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races."

The only thing I think it's good at is being unsure of what it's trying to do or to be. It changes for the sake of change itself.

Rust is like Perl 6. We hear how great it is, and about all of these amazing features it's supposed to support, but it's never really usable.

Re:COBOL

[Jane Q. Public]

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 interpreter. (But there's that static-vs-dynamic typing again.) On the other hand, JRuby compiles and runs as Java bytecode, but Ruby is still generally considered a scripting language. Go figure.

Re:COBOL

[Anonymous Coward]

To bad the syntax is horribly ugly. Most programmers, C or otherwise, don't want to deal with it.

Re:COBOL

[Anonymous Coward]

Have you actually tried to use Rust at all? Even if we ignore the constant change, even as 1.0 approaches, it's just not a pleasant language to use.

Try doing some basic string manipulation with it. It's so bad that even C++'s string handling, which isn't all that good, ends up looking great in comparison.

Its support for arrays and collections is just about as bad as its string handling. I couldn't believe it, but it made me want to use C++'s STL classes again!

The lifetime handling is a huge pain in the ass. Even when you understand how it works, it's still not easy to use. You're almost guaranteed to spent most of your time fighting against the compiler. It was so bad that it made me want to rush back to C++'s RAII, references and smart pointers.

If Rust wants to compete with C++, it can't just offer vague promises of supposed benefits. It needs to bring a substantial number of real benefits to the table. So far it hasn't done that, in my opinion and experience.

Re:COBOL

[Anonymous Coward]

+1

Re:COBOL

[MightyMartian]

Pleasant diphthongs?

Re:COBOL

[Anonymous Coward]

I haven't looked at D, but I don't want 'most all' of the power of C/C++. I want ALL of the power of C/C++. What new programmers consider to be 'dangers and difficulties', I consider to be indispensable tools. New programmers can stick to Java, or Python, or some other kiddie safe language. Leave C/C++ to the people who can handle and manage it. Putting kernel work, for example, in the hands of someone who needs to use D because they are worried about the 'dangers and difficulties' of C/C++ is a disaster to begin with.

Re:COBOL

[Anonymous Coward]

> If Rust wants to compete with C++ ...

It doesn't. C++ is meant to be general purpose, Rust is aimed at systems programming. They trade off a lot of convenience for verbosity to get more static guarantees about objects' lifetime and ownership, for example. You wouldn't care much about those when writing a GUI frontend to your database, but you might be interested if you're writing the DBMS serving the data to that GUI.

Re:COBOL

[Anonymous Coward]

GC for the win...

Re:COBOL

[__aaltlg1547]

Arbitrary spelling that must be memorized for every word?
Ambiguous syntax?
Homonyms?
Homographs?

Vagueness in general?

Re:COBOL

[__aaltlg1547]

SNOBOL.

Re:COBOL

[Yaztromo]

ok .. go ahead and name one language that isn't about domination and oppression. just one.

Esperanto.

Yaz

Re: COBOL

[Anonymous Coward]

I don't have any problems with Rust lifetimes, string handling and containers. Can you describe what you mean by all that stuff you wrote? I cannot deal with generalities.

Re:COBOL

[firewrought]

My original lack of understand on what D really offers remains. Responses like "high-performance applications" tend to flow over my [head].

As a C programmer, you maybe haven't bought into OOP, templates, exception handling, metaprogramming, or other such features that C++ brought to the systems programming scene. Maybe, like Linus Torvalds, you've tried C++ and think it's a horrible language.

I myself agree with you (or rather, Linus)... except I'm coming from the applications world (C# mainly), where those nice features (that C++ popularized well and implemented poorly) are bread-and-butter techniques. I want to do systems programming with objects, exceptions, namespaces, reflection, etc., *but* I'm not willing to weather C++ for them, nor am I willing to drop down to C. Ergo D, except it doesn't really have a viable ecosystem at this point. :-( (And, like you said, JavaScript/Java/C#/Python/etc are fast enough for the vast majority of applications.)

Re:COBOL

[phantomfive]

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:COBOL

[Anonymous Coward]

> ok .. go ahead and name one language that isn't about domination and oppression. just one.

Since you ask: Esperanto.

It might not work as expected (heh, expected!), but it was intended to dominate or harm anyone. Well, at least not until its creator decided to pump up some iron and become a slave trader, that is...

Now, English has a moderately good sounding pronunciation (not the American one, forget it), but could someone please throw some light on what would be a purported English advantage? BTW, there's "illicit" and "elicit" (and that's a problem in English -- it's hard to learn the structure of words... everything is too fractured and mended again in interesting ways...)

Re:COBOL

[phantomfive]

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:COBOL

[Jane Q. Public]

Here's part of your answer, and it's contained in OP: the simple fact that COBOL has increased in Tiobe's "popularity index" illustrates the silliness of the kinds of measures Tiobe uses to rate popularity.

You're generally better off checking Gartner or RedMonk or even LangPop.

Re:COBOL

[cheesybagel]

Most of the sugar you're talking about is overrated and nearly all of it causes performance degradation. If performance does not matter why are you using C anyway?

Namespaces... Mostly useless. Just use longer names. Reflection requires extra storage space to store identifiers and type information. i.e. the things you strip from C binaries with debugging symbols on. All exceptions implementations cause a performance hit. You are better off just returning an error value on each function call and checking it.Objects are overrated. Except for some graphics programing I find that paradigm to be mostly useless for software development.

Re:COBOL

[cheesybagel]

Most of what's in the C++ spec is superfluous and what is even worse it is poorly implemented.

Re:COBOL

[cheesybagel]

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:COBOL

[cheesybagel]

C compatibility is the least of C++s problems.

Re:COBOL

[Anonymous Coward]

C programmers use many other languages. They just don't stop using C, because it's immensely well suited for certain things. For example, building complex, purpose-built data structures without relying on libraries as crutches, or using templates, making it a headache to interoperate with other languages.

People who are searching for a single language that will do everything well are searching in vain.

That's why there's such a deep rift between those who prefer C and those who prefer C++, and why the arguments of C++ proponents about C++'s benefits fall on deaf ears. Those of us who regularly work in C will use multiple other languages, each of which is far superior to C++ in their particular domain. It's also why we're not that interested in styled C++ killers.

Also, C has been incrementally improved. First with C99 and most recently with C11. It's improvements are conservative and limited, and they rightly should be, but that doesn't mean they're insignificant. Atomics, threading, dynamically-sized arrays (not pointers to arrays using malloc()) that you can use with sizeof, compound literals (more useful than C++'s temporaries), _Generic for building routines overloaded by argument type, named initializers, anonymous structures/unions, etc.

That said, one language that has lots of people intrigued is Rust. It _doesn't_ try to be everything to everyone, and it's the closest thing yet that could excel in many of the domains where C is most useful.

Re:COBOL

[Anonymous Coward]

D and Go are both interesting low-level languages designed as nicer alternatives to C++ that are underrated.
But they are so little used they are only useful for personal projects and will become popular enough to be commerically useful.

Re:COBOL

[DuckDodgers]

The features of D doesn't seem like anything that isn't solved (but perhaps in an ugly way) by C++11 and Boost.
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:COBOL

[allcoolnameswheretak]

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 were and where. Yes, my username also became victim to this consequence.

IT IS MADNESS!!!

Re:COBOL

[DuckDodgers]

The only power of C and C++ that D doesn't provide is seamless integration with existing C and C++ code. And that's a big obstacle - in most cases, if you're doing serious C or C++ programming you've got thousands or millions of lines of code in libraries at your disposal. D can interface pretty easily with the C, but not as easily with C++.

Otherwise, it's likely that every feature you care about in C and C++ is available in D.

Re:COBOL

[Anonymous Coward]

In what dialect do "where" and "were" have the same pronunciation?

Re:COBOL

[geminidomino]

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

[david_thornley]

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

[cheesybagel]

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

[Darinbob]

"Most of the power" is just a poorly chosen but common phrase. If a language is Turing complete then it has all of the power. What is really meant there is "most of the features the author likes".

Re:COBOL

[Darinbob]

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 programmers don't know about. This is where things tend to fall down with some higher level features.

For example, exceptions. C++ does this behind the scenes. Unlike setjmp/longjmp in C you can't override what exceptions do, you have no API hooks to implement them yourself or tweak them. So the programmer is forced to work around the compiler in many instances, making sure that their fiddling with the registers isn't going to break exceptions or that an assembler routine screws it all up. And different C++ compilers will implement exceptions different, which is a bit of a hassle if you want to be portable across compilers. Finally the exceptions do cause noticable changes in performance (either speed or size, occasionally both).

But it's certainly possible to use a subset of C++ in systems level programming, but it gets harder and harder the more extra features that get brought in, especially anything that requires specialized runtime support. There are even specific subsets people have defined, like Embedded C++. With D I think it gets used ok here because there's just not as much concern about portability across compilers, but you still have to deal with runtime library overhead for some features and possible space/time tradeoffs.

Re:COBOL

[Kingofearth]

Code? Useless! Overrated! Real programmers program directly in binary.

Re:COBOL

[disambiguated]

C++ is an underrated programming language. The central organizing principle of C++ is that you only pay for what you use. Don't need garbage collection? Don't use one. Don't need exception handling? Don't use them. Don't need RTTI? Don't use it. Etc, etc. If you want to use it like C, but with a few syntactic niceties, you can. It may be a "kitchen sink" of programming languages, but that's a feature if you can use what you want without paying for what you don't want. Despite all the complaints and trash-talk, it's popularity is well-deserved.

Re:COBOL

[Anonymous Coward]

The idea of C++ is zero cost abstraction, with the corollary of if-you-don't-use-it-you-don't-pay-for-it-compared-to-C. It's sometimes taken to ridiculous extremes, like leaving ints on the stack uninitialized by default.

Re:COBOL

[Anonymous Coward]

You'll find that this can happen in the South. Where, wear, were, whir, will, and well can all have the same vowel sound, known as the Redneck Schwa.

This is not to be confused with the Redneck Dipthong, where single syllable words are stretched into two syllables by extending a single vowel into two unique sounds, such that where and wear become WAY-ur, or will and well become WEE-ul and WAY-ul, respectively.

Re:COBOL

[jones_supa]

All exceptions implementations cause a performance hit.

Hmm, never thought about that.

Does that mean that if I run a function inside an exception handler, it runs slower?

Re: COBOL

[Anonymous Coward]

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

http://www.mit.edu/~xela/tao.html

Re:COBOL

[Pseudonym]

Kial Esperanto uzas malfacilan Polan prononcon?

Re:COBOL

[Pseudonym]

Sorry, left out the cxu. So much for mian putron Esperanton.

Re:COBOL

[rdnetto]

Having worked with D a bit, the biggest difference between it and C++ is that D is garbage collected by default. You can disable the GC and use malloc, but this renders the standard library off limits. Apart from that, I would say that D not only has all the features of C++, it has features that C++ doesn't even have yet. e.g. concepts were proposed as an extension to templates for C++11, but still aren't part of the spec. In contrast, D has support for constraining templates similarly using syntax such as:

T square(T x)
        if (isIntegral!T)
{
        return x * x;
}

D also has excellent support for functional and meta-programming. e.g. the pure and immutable keywords. While C/C++ requires you to use macros for meta-programming, D lets you use existing D functions to generate the resulting code.

Re:COBOL

[eluusive]

That's completely false. The posters on the D Forum are made up of almost complete C and C++ programmers.

Re:COBOL

[Sudline]

Since the Rust and Swift language have been created, it seems than C++ is not the solution for anyone. The question is, why not use D rather than create a new language?

Re:COBOL

[Sudline]

I would said the main difference is scripting languages run at command line while desktop app languages use a GUI. JavaScript is now used on the desktop with a GUI, so it is now also a desktop application language.

Re:COBOL

[LordWabbit2]

COBOL has increased in popularity because all the people who know it are retiring, so the people who are willing to learn it are getting humongous salaries. There are literally billions of lines of COBOL code still churning away, working out your interest payments and processing your credit card transactions etc. I know of one company (retail) which have bought the SAP cool aid and are spending millions to convert their systems to SAP. SAP said it would take 5 years, well it's 5 years further down the line and they have only finished phase one, and that was a fvck up of note (and still not finished). There are another 3 phases to go, and they started on the "small" one first. So yeah, COBOL is going to be around for a LONG time, and anyone with 2+ years experience in it will coin it big time.

Re:COBOL

[Anonymous Coward]

Think of exception handling this way... It's not a perfect analogy, but should give you the idea.

Each time you have a try block, a setjmp point is created. See setjmp in your C library docs. It's somewhat expensive.
Every catch block will lead back to a setjmp point. See longjmp in your C library docs.

What happens, in the case of C++ anyway, is that all necessary destructors are called (and have to be tracked, somehow) for each object created in each try block.
The longjmp causes all of those destructors to be called and then restores the stack such that it represents the state right after the try block.

Re:COBOL

[Anonymous Coward]

Yes, it does.

The function will be part of a code base which must be larger than it was (to account for the exceptions) and will invoke the handler if an exception is thrown, or have an effective decrease in cache effectiveness even if not thrown.

Re:COBOL

[Tough Love]

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

[Tough Love]

No, it means the GP doesn't know what he's talking about.

Re:COBOL

[jgdnavy]

While I haven't read the links and haven't been following Rust, the extracts you give as an example of changing for the sake of change read to me as describing a language that is evolving to fulfill its purpose and perhaps a bit more. Thoses texts could very reasonably describe a language that was intended to meet the last description but the developers were being honest about the current state of the language.

Re:COBOL

[Torp]

... or simply something procedural but higher level, like, for example, Python?
D is a better C++, but not many people need a better C++.

Re:COBOL

[jones_supa]

Does it also mean that every line run inside an exception block has an C-style assert() test attached to it?

Re:COBOL

[Viol8]

Or maybe they thought your comment on superfluous was ignorant rubbish. C++ is badly implemented design wise but most of whats there is there for a damn good reason and if you don't understand why then you'd better stick to languages like Python etc.

Re:COBOL

[DNS-and-BIND]

That one is about stomping out all the world's other languages and making us all speak the same. What a loss of culture.

Re:COBOL

[Anonymous Coward]

Esperanto.

I would have added Lojban, but you asked for just one.

Re:COBOL

[Anonymous Coward]

Esperanto is promoted as a universal second language, jackass. Take your paranoid misinformation elsewhere.

Re:COBOL

[epee1221]

The first is how every language starts out. The second and third are the same thing and have been the goal since the beginning.

Re:COBOL

[Anonymous Coward]

Try doing some basic string manipulation with it. It's so bad that even C++'s string handling, which isn't all that good, ends up looking great in comparison. Its support for arrays and collections is just about as bad as its string handling. I couldn't believe it, but it made me want to use C++'s STL classes again!
So your entire objection to the language is that its standard library doesn't have the stuff you want?
...
Oh sod it, this is slashdot, where nobody knows the difference between a language and its library.

Re:COBOL

[Mal-2]

When Chuck Norris throws an exception, it is always fatal.

If that isn't a hit to performance, nothing is.

Re:COBOL

[cheesybagel]

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 programmed in Assembly, C, C++, C#, Caml, Java, LISP, Python, and a lot of languages you probably never heard about. I mostly use Java, C, and Python. Python when performance doesn't matter and I just need to get something working in a short amount of time. C when performance matters. Java when performance kind of matters but not enough to use C. C++ is kind of useful for game programming but for everything else it is a waste of time.

Re:COBOL

[cheesybagel]

When you have hard real-time needs like in operating system design and drivers the last thing you want to add is code that takes a lot of cycles to process and even worse that can take an unknown amount of time to finish. That's exception handling for you.

Re:COBOL

[cheesybagel]

When you use exceptions the compiler also disables a lot of optimizations it could use if you had used the standard C method of returning the error state on the function return value like inlining. With inlining and control-flow optimizations the jumps can be simplified and reduced dramatically. No such luck with the exceptions code which in addition will cause more code bloat and cache misses.

Now get off of my lawn.

Re:COBOL

[cheesybagel]

Great. So you think I'm a pure Python or high-level language programmer. The other guy thought I was a pure C programmer. You're both wrong. Plus I have probably programmed more C++ code than both of you combined.

Re:COBOL

[david_thornley]

Perl is generally considered a scripting language, but I write it in a text editor and run it just like C++, except that the compilation step is folded into the run step. This can happen in other languages not usually thought of as scripting languages, such as good Common Lisp implementation. There have been Python IDEs out for some time now. I don't see this as a useful distinction.

Re:COBOL

[david_thornley]

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 do everything, and you seem to be taking the attitude that things you can do awkwardly in C needn't have facilities in other languages to do better.

Exceptions do cause performance degradation, but modern C++ implementations have very little in a try block. Exceptions are, well, exceptional, and mean something's gone wrong, so it's reasonable to accept some degradation during exception handling. Returning an error value doesn't work as well. First, some functions don't have a possible return value that's invalid, so the programmer has to pass a variable for the desired value by pointer or reference. Second, returning an error value doesn't work well if you want to call a function in an expression (except in floating-point, where NaNs propagate). Third, having to check and return an error value every single time is tedious and easy to forget once, and once is all it takes for a serious bug.

I'm not advocating exceptions or reflection in systems programming, which (in my opinion) should not rely on much external infrastructure to run. Reflection has its own problems, in that it makes it difficult to reason about what the program does, and that makes some compiler optimizations impossible.

Re:COBOL

[david_thornley]

There is no language called C/C++*. There are languages called C and C++, which are considerably different languages that work best with different approaches and mindsets. Pretty much all languages have the full power of C, as long as they don't have to interface with bare hardware, so C is best used in low-level programming. Few languages have the full power of C++.

Kernel work should usually be done in C, or in a carefully selected subset of C++ (some but not all of the additional facilities are applicable there).

Re:COBOL

[david_thornley]

As somebody who has programmed in Python, Common Lisp, Java, and C# (among others), what you wrote isn't true.

Re:COBOL

[Anonymous Coward]

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.

And Java programmers... And DBA's... And ... And humans in general.

Re:COBOL

[david_thornley]

C requires macros for metaprogramming. C++ templates are themselves a Turing-complete language. What do you mean by "C/C++", and why do you get it wrong?

Re:COBOL

[Yaztromo]

That one is about stomping out all the world's other languages and making us all speak the same. What a loss of culture.

Esperanto has only ever been promoted as a universal second language. There has never been a push to make it the native language for anyone, anywhere. Hence, no loss of culture needed nor required.

Yaz

Re:COBOL

[OrangeTide]

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 simplification and never a rigorous definition.

Re:COBOL

[OrangeTide]

JavaScript originated in a GUI, because it was part of web browsers.

I learned C without a GUI, and had to use command-line.

But I think we can all agree that C is not a scripting language. I think your definition is neither rigorous nor correct.

Re:COBOL

[DuckDodgers]

Lots of people need a better C++. But they need a better C++ that's easily interoperable with millions of lines of existing C++ code, and that's damn difficult to manage.

Re:COBOL

[OrangeTide]

Some of the L4 kernels were an exercise in trying to get C++ to be usable in kernel land. The one I'm most familiar with is L4Ka::Pistachio, it does a fairly decent job. But there is a lot of C++ you just can't safely use. That's not to say you can design a kernel where more C++ functionality is possible, but I believe it is difficult to make it work. More difficult than writing a microkernel from scratch, which means to me that it's not worth doing if the primary goal was to write a kernel.

As a system software engineer, it's been a repeated hell to get C++ compilers and libraries to build and work correctly in a variety of embedded environments. Even big environments like Linux with a full user-space and proper virtual address space. I think part of me hates the tools and implementation of several C++ environments more than the language itself.

Re:COBOL

[cheesybagel]

No. My point is if you can have that kind of bloat you are better off using a higher level language. C++ is a jack of all trades master of none.

Object-oriented programming is abused. Too often it is just a poor fit to the problem and you are better off using a procedural approach. So called state of the art object-oriented code is often full of anti-patterns and code obfuscation in an attempt to coat in objects something which was better off implemented without objects.

I'll give you an example. You want a single variable for something. You implement a singleton after reading some Design Patterns book. So why did you not use a static variable declaration instead? You could have used one line of code instead you used a steaming pile of dung to achieve the same.

C++'s object orientation features aren't even good either. They come from a time when the models weren't well established and its bloated like heck. Even Java's model is less than perfect. Java interfaces are a great idea and quite useful but object inheritance is a waste of time in 99% of cases. To do something like interfaces in C++ requires jumping through so many hoops you start wondering why you are using it to begin with.

I like macro programming and code generation but C++ templates are one of the worst implementations of it around. LISP macros are a lot better than C++ templates for example. Other languages have actual facilities for code generation. C++ templates offer little over what the rudimentary C preprocessor can do.

C++ is crap.

Re:COBOL

[micahraleigh]

Languages don't dominate and oppress.

People do that.

Re:COBOL

[Anonymous Coward]

GHOTI is pronounced FISH utilising certain quirks of the English Language.

GH as in "rouGH"
O as in "wOmen"
TI as in "igniTIon"

There you go. GHOTI = FISH

Now... I don't know if that's an "advantage", that you can make any letter of the alphabet sound like any other letter.... but it sure as hell makes English a proper b'stard to learn and understand for those of us that wasn't born in a natively English speaking country. Mayhaps C and C++ is the same way.... B'Stard languages..... ;)

Re:COBOL

[rdnetto]

I said C/C++ because they both use same preprocessor. While I'm sure you could do some interesting things with C++ templates, I haven't seen any use of them that goes beyond generics while still being easy to comprehend. This could be due to my own inexperience though.

Re:COBOL

[Anonymous Coward]

Considering the acceptance LLVM is getting, and the relative ease you can interact with it (from any side or end), I believe the best bet (perhaps the final bet) the D community have to keep the language even remotely alive is to implement an LLVM front-end - exactly like clang is to LLVM, they need dlang (can't say it rolls off the tongue as easy, though).

If there was a D LLVM front-end, I think it could, possibly, (re-?)generate some interest in the language. Especially since it would pretty much *promise* forward-compatibility (of both platforms and ISA's).

Re:COBOL

[jergantic]

Then, for good measure you have words that sound the same but, of course, are spelled differently, like knight and night or were and where.

"Were"/"where" don't sound the same in any English pronunciation I'm aware of. "Where"/"wear"/"ware" do sound the same, as do "were"/"whir", at least in most accents where the "h" in "wh" is silent.

Your general point that English spelling is madness is correct, though.

I'd say most native English speakers are well aware of this. It's why hardly anyone can write a sizable amount of text without spelling errors except insufferable pedants, and even then only when sober and with a couple of rounds of proofreading.

Re:COBOL

[Tough Love]

You're actually wrong.

I'm not wrong about exception overhead. I know why this is so, plus I measured it to verify. What support do you have for your bald (and nonspecific) assertion?

Re:COBOL

[Tough Love]

Easy solution: if you dont' want exceptions because you are implementing hard real time stuff, then don't use exceptions then. In c++, if you compile with exceptions disabled then there is no overhead whatsoever. You would probably also have to avoid D's standard library.

There is nothing unusual about this (and I wonder why I need to explain it to you). The Linux kernel is programmed like that: there are standard libraries defined for C, but kernel code doesn't use them, because they do things like malloc that are unacceptable in kernel.

Frog. Well.

Re:COBOL

[Tough Love]

That's why the chinese made a proverb for it

Re:COBOL

[Yaztromo]

Kial Esperanto uzas malfacilan Polan prononcon?

C^ar Zamenhof estis Polan?

Yaz

Re:COBOL

[Yaztromo]

Sorry, left out the cxu. So much for mian putron Esperanton.

Don't be too hard on yourself. I prefer to blame /. for not supporting Unicode :).

Yaz

Re:COBOL

[brantondaveperson]

All exceptions implementations cause a performance hit. You are better off just returning an error value on each function call and checking it

...Which causes a performance hit, and also causes you to have to write a ton of boilerplate everywhere. Not seeing a win. The performance hit of exceptions is extremely tiny, and so only matters in the most performance-critical applications of all. The type of applications where throwing an exception would be unacceptable anyway.

Re:COBOL

[Anonymous Coward]

D has the primitives to do functional language programming, in a style much closer to C/C++. You are right in that learning a purely functional language will help you to think a different way about coding.

Here is a video of the creator of the language talking about using D to create functional style components.

https://www.youtube.com/watch?v=0cX1f41Fnkc

Re:COBOL

[Jane Q. Public]

JavaScript is sometimes partly compiled to native instructions, but part of it is bytecode-interpreted.

And the reason, I will repeat, is dynamic typing vs static typing. It isn't so much (as many have asserted elsewhere) weak typing versus strong typing. Ruby is strongly typed, for example, but it is also dynamically typed, which makes it notoriously difficult to compile.

JavaScript is a double whammy because not only is it dynamically typed but weakly typed as well. Fully-compiled versions of JavaScript have always been strict subsets of the language, and almost always require strict typing.

The problem is that in a dynamically-typed language, data types can often change due to runtime considerations, which compilers cannot reliably predict.

Re:COBOL

[Jane Q. Public]

COBOL has increased in popularity because all the people who know it are retiring, so the people who are willing to learn it are getting humongous salaries.

That isn't an "increase in popularity". It is just a slowing of its decline. There is a difference.

A moment's thought will let you prove to yourself that COBOL is not actually "increasing" in popularity: the number of new systems being built to run COBOL is essentially zero. It would be stupid to do so. Rather, they are only maintaining old systems. And old systems are gradually replaced over time, no matter how slowly.

Re:COBOL

[Viol8]

"Plus I have probably programmed more C++ code than both of you combined."

Oh thats highly unlikely my friend. I've been coding in C++ since the mid 90s.

Re:COBOL

[Anonymous Coward]

You don't need to use cxu there, because "kial" already is interrogative... (IMHO at least).

2nd, the pronunciation (la prononco) is not Polish; I've heard once the "o" must be said like in Hungarian (?sp). It just is not an American pronunciation... and nor French, btw. It's quite similar to Latin languages, like Italian, Spanish, Portuguese, but at least regarding the latter I can assure there are some differences. BTW, if you would hear any foreigner speaking English it would usually sound wrong -- even for fluent writers.

My daughter used to argue about English pronunciation -- ONE trip to a English speaking country and her pronunciation is much closer to normally spoken English. Teenagers... *rolls eyes*

This could be useful: http://en.wikipedia.org/wiki/Interrogatives_in_Esperanto

Re:COBOL

[Anonymous Coward]

I wouldn't call the move to version 2 a fracture, because users of version 1 simply aren't a community any more. Yes, it did break existing code and that is a pity, but sometimes there is no alternative to a breaking change if one does not want to be stuck with the consequences of original design decisions that turned out to be wrong. Much better to do this earlier in the development of a language than later. Compare with Python 3...!

[Sociomantic, a prominent user of D, do use version 1, but that's because as an early adopter they have a large code base written in that version. I imagine over time they will migrate. But still, one can't say that they aren't part of the community by virtue of using the older version, if one looks at their participation in the D community].

One can do things the English way - never complain, never kick up a fuss. And life is much more agreeable for that. Or one can do things the German way, which is to be intolerant of infelicity and complain all the time, and expect things to be fixed. Life is less agreeable in Germany as a result, but you know what? Things work there!

I do agree that the tutorials need to be improved, and also the organisation of the community. Both are a work in progress, but see this, for example:

http://arsdnet.net/this-week-in-d/jan-18.html
http://p0nce.github.io/d-idioms/

I think this problem is being worked on, and will be better soon enough.

IDEs do exist (see wiki at dlang.org) but are under development.

Is D low-level? Not really. You can do this, for example (from std.algorithm):
int[] arr1 = [ 1, 2, 3, 4 ];
int[] arr2 = [ 5, 6 ];
auto squares = map!(a => a * a)(chain(arr1, arr2));
assert(equal(squares, [ 1, 4, 9, 16, 25, 36 ]));

For me it is a language for getting work done, where I have the confidence I can do something low level if I need, but I can do what I can in Python only it will be fast, and robust, and if I need to scale it can easily make it parallel or use threads.

Re:COBOL

[ChrisMaple]

"Power" includes economy of expression. If 5 lines of language A requires 500 lines in language B, language A is more powerful.

"Power" includes things like directly accessing hardware.

Re:COBOL

[Anonymous Coward]

>without paying for what you don't want
Not true. The classic statement was don't pay ***more than 5% overhead*** for a feature you don't use

That '5%' number is a worst case too. For instance, if you don't use exceptions, would you mind a a few % slower program if the language supported them (for all the other people who do want or need them). Ditto RTTI, etc (and I'm not saying these features cost a 5% perf hit, and YMMV based on feature, compiler, etc). So *ideally* you pay ZERO overhead for C++ having features you don't use, but realistically you _do_ pay a small tax for C++ to have features you may not care about.

(and if you think >0% is unacceptable, why are you using t hat high falutin' assembly language when everyone knows you should be programming directly in machine code...)

Which is all fine and dandy, for most people. Systems programming tends to care more than most about such things. Certainly not all systems programming, but in general if your OS or video driver was 5% slower or used 5% more memory, plenty of people would be looking for ways to squeeze out that overhead (up to and including replacing C++ with something else, like, say, C :P)

I use C++. I've used it since 1987. I generally like it too. But I understand its strengths *and* weaknesses. It's a tool, and while it's a pretty popular and versatile tool, it's not the only. There's no such thing as the perfect tool for all people for all needs.

C++ can be highly performant. But no overhead for features you don't want? Not quite the case.

Re: COBOL

[Anonymous Coward]

Why it folks never correctly qualify "when I am writing a device driver (insert useful abstraction here) is too slow"? Young devs just get this idea that everything is too slow and they need to be hand tuning code. There are whole industries which are io bound not cpu bound and when they are cpu bound they deploy a grid of a thousand servers. I work in a big shop which has C++ devs doing systems programming and dozens of devs doing platforms in Scala. Scala for a platform? Yep with compiler plugins to transform business code at a high level of abstraction into distributed code running on a grid of a thousand servers. I haven't looked at a low level language this century: because I don't write device drivers and its complexity of a hundred devs writing business code I need to manage.

Re:COBOL

[LordWabbit2]

Soz to burst you bubble but new COBOL programs are written every day, my wife is a COBOL programmer working for a major bank and she's on new projects all the time. I do agree with you that a lot of COBOL systems are being replace though, but the main drive around that is a lack of resources to write new COBOL programs. I worked with COBOL a long time ago, and I have worked with lots of other languages since then, nothing has come close to the ease with which COBOL parses data. Just define your working storage and drop the chunk of data into the 01 level. Tada, parsed. Hate the rest of the bloody language though.

Re: COBOL

[Anonymous Coward]

Illicit and elicit are differently spelled, spoken and defined... So I don't really take your meaning in that case. But yes english has many contradictions, which just become exceptions.

Re: COBOL

[Anonymous Coward]

Bitch

Re: COBOL

[Anonymous Coward]

Another poster has confused the words, which is somewhat frequent in English.

Pardon me if I generalize, but I find somewhat harder to recognize words and their origins in English (compared e.g. to my language, Portuguese). People often misuse "their", "there" and "they're". Likewise, I wondered if said poster has a more or less similar pronunciation of those two words.

Being confusion-prone is a trait of English, IMHO. AT least, that is my impression.

I also thank the above replier for the clarification about the OP point.

Re: COBOL

[disambiguated]

I think power consumption has brought back an emphasis on performance. With desktop software we were at a point where even the most inefficient languages wouldn't make a noticeable difference, except maybe in memory usage. Inefficient software won't necessarily seem slower to the user, but they will notice the power consumption. Mobile chips are narcoleptic. The faster you can get stuff done, the faster the chip can go back into lower power mode.

And on the data center side, it is kind of surprising when you see the massive amount of power consumed. Energy is already a big chunk of the costs of running data centers, and energy is probably just going to get more expensive in the future. More efficient means fewer servers. Facebook is doing a lot of stuff in C++ nowadays, and I believe power consumption is one of the driving factors there.

Re:COBOL

[Jane Q. Public]

Soz to burst you bubble but new COBOL programs are written every day, my wife is a COBOL programmer working for a major bank and she's on new projects all the time.

Please read again. I wrote: "... the number of new systems being built to run COBOL..."

And I am sorry to hear your wife works for a bank that is still using COBOL. Still, you are mistaken if you think I don't understand how companies use legacy systems.

Also, I didn't say anything bad about the language. I just implied it is slowly fading. Because... it is.

Re: COBOL

[Tough Love]

It is more than a little impressive how successful some people can be at deluding themselves into believing that efficiency does not matter, even when it does. GP is a typical example. A common manager belief: "I must be brilliant because I got promoted into this position of managing lots of devs, so every little ass fart of an idea that I hold dear must be right". In any case, an engineer who dares to disillusion/correct tends to do so at the risk of their career prospects. Or maybe they would be happier and richer getting out of that shop anyway.

Re:COBOL

[cheesybagel]

So have I. So what. It's still crap.

Re:COBOL

[K. S. Kyosuke]

I'm not sure it's overall arbitrary. Sure, there's a lot of problems with it, lot of randomness, but the brain usually digests some rules from the chaos. It's sort of an 80/20 venture. (But it's certainly better than kanji, for example.) Plus, "polish" and "Polish" are two different words. That's because they have different etymology. I can assure you that different pronunciation of true homographs is most certainly not exclusive to English.

Re:COBOL

[OrangeTide]

JavaScript is sometimes partly compiled to native instructions, but part of it is bytecode-interpreted.

I don't have to use bytecode for JavaScript, there are some implementations that to not use bytecode, but use a tree to represent the processed source.

JavaScript is a double whammy because not only is it dynamically typed but weakly typed as well.

Objective-C is dynamically typed, but compiled to machine code.

I think you are chasing a definition for scripting language that depends highly on implementations you are familiar with rather than properties of the language itself.

Re: COBOL

[DasDad]

Before I point out that every other language can be accused of the same, may I ask what prompted you to come and crap your odious political banalities all over a completely unrelated thread? Did the campus meeting of Young Revolutionary Transgender Maoists get cancelled or something? Couldn't find a Trotskyite forum to go troll?

Re: COBOL

[DasDad]

Before I point out that every other language can be accused of the same, may I ask what prompted you to come and crap your odious political banalities all over a completely unrelated thread? Did the campus meeting of Young Revolutionary Transgender Maoists get cancelled or something? Couldn't find a Trotskyite forum to go troll?

Re:COBOL

[alva_edison]

If you actually care, this: http://www.zompist.com/spell.h... provides some slight counter arguments.

Re:COBOL

[Anonymous Coward]

Speak for yourself! I'll bet I can spell perfectly when I'm drunk no matter how much I am writing, and I'm the opposite of an insufferable pedant. I'd probably have excellent syntax as well. It's not boasting, it's just a fact. Now, whether I can form coherent thoughts when drunk, that's another question. But that question is rather academic since I hate to get drunk.

(Please proceed with pointing out the ironic errors. It's what we do best around here, let's get it over with.)

What Kind

[Anonymous Coward]

What kind of complexities has modern C++?

Re:What Kind

[khellendros1984]

C++ is essentially a mixture of languages at this point, with several ways to do many things. You can still write very C-like code using C data types, with the pitfalls of C (memory leaks, buffer overflows, etc). You can write more modern-style C++ programs using the container classes, iterators, and RAII techniques to avoid C's pitfalls. You can also end up with a program that's an ugly mash of C and C++.

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:What Kind

[Anonymous Coward]

Well, if write memory leaks and buffer overflows into your code, you are going to have memory leaks and buffer overflows in your executable, yeah. I think the idea is to not do that. >..

Re:What Kind

[91degrees]

No built in string. Complicated templates mechanism. A lot of C legacy crud. Antiquated #import system (the main issues is that this can lead to horrendous build times). Not sure if these are better in D, but they are problems that it would be nice to address.

Re:What Kind

[disambiguated]

The lack of a built-in string is a red herring. One of the design goals of C++ is that user defined types can be fully integrated with the type system so you don't need to have special built-in types can can't be implemented as a user-defined type. It doesn't have a built-in complex number type either, but again a special built-in type is not supposed to be necessary, by design.

I completely agree with the rest of your comment. Templates are complicated, but that is getting better with recent language changes. Concepts are going to help a lot if we can ever get them into the standard. Couldn't agree more on the legacy C crud and #include. Hopefully we'll get modules in C++ soon.

These things are all better in D, especially build times. D has it's own issues though.

Re:What Kind

[91degrees]

The thing about a String type is that it's a common means of sharing data, but there are dozens of incompatible implementations. Qt uses QString, I remember using a regex library that uses a UnicodeSting type, and I've worked with more than one toolkit that uses its own custom string class. Mixing and matching these can be a headache.

Complex types are less of an issue because they're a lot more specialised. You're more likely to want to read a value from a widget input field, parse it using a regex and then use the result in a third library than to do the equivalent with a complex number. I'll grant you, this is more of a perceived problem with std::string than a fundamental issue with C++ but still, I rather like the fact that any Java library I use will use java.lang.String if it needs a string.

Re:What Kind

[david_thornley]

If you have memory leaks and buffer overflows in C++, consider using C++ facilities like smart pointers and containers.

Re:What Kind

[Anonymous Coward]

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

If template compiler errors are confusing to you, use clang. It has vastly simplified template error messages (and will at times even suggest possible solutions)

Re:What Kind

[khellendros1984]

That's a wonderful idea if I were just working on my own projects. Clang++'s output *is* much cleaner than GCC's. However, it's more difficult to suggest as one of hundreds of developers in a corporate setting. Politics, legal hoops, inertia, verification that there are vendor-supported packages for that compiler on systems that haven't updated to gcc 4.x, etc.

Re:What Kind

[Salgat]

This is incredibly true. C++ has such a diversity of ways to program that its complexity is limited to what you decide to use from it. With just smart pointers, auto, and the STL you can get away with writing major projects that never use a new or delete, where typing is greatly simplified (no more crazy iterators, just for (auto entry : array)), and where containers efficiently hold and handle whatever you need them too. My favorite new feature of C++ is the rule of zero, where destructors, copy constructors, etc are often no longer needed. C++11 and 14 are amazing.

The thing about new languages...

[Lab Rat Jason]

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

[Anonymous Coward]

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:The thing about new languages...

[Anonymous Coward]

Whenever you take on an entrenched incumbent with thousands of satisfied users, it's not good enough to be a little better. You've got to have a different paradigm to overcome to advantages of the incumbent. Cases in point: Microsoft Zune was "a little better" (supposedly) than iPod. IBM OS/2 was "a little better" than Windows 95. etc

Re:The thing about new languages...

[Anonymous Coward]

Right. Why change when what we have is comfy and proven, even if it's been proven to be pretty terrible in ways that we could easily fix? Progress is for chumps and the younger generation.

Re:The thing about new languages...

[david_thornley]

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:The thing about new languages...

[Anonymous Coward]

That didn't stop many sites from going with Ruby on Rails, and the future of that particular framework (along with Ruby) are shaky at best. There doesn't need to be a "very compelling reason" necessarily, with the right kind of hype alone they could gain traction.

For people who are already C or C++ developers though...unless D offers something substantially improved without breaking the millions of lines of code they've likely already written, why bother? Just about every piece of hardware with a microprocessor in it has a C or C++ compiler and toolset, D is still pretty much on the fringe. It's a bit of a chicken-and-egg problem...in order for D to gain traction it needs to see more wide-spread use, but in order to see more wide-spread use, it needs to actually add something to the table that will gain traction. Nothing I've seen so far makes me think "I'm going to drop learning C++ and pick up D, this is obviously the future of systems programming." Most of the reaction is more like, "well that makes sense, shame that C++ doesn't do it that way...oh well, back to work."

Re:The thing about new languages...

[petermgreen]

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 native code (either at compile time or at runtime by a JIT) has a massive uphill struggle to come close to the portability of C/C++. AIUI GDC only got proper support for arm linux very recently and is still missing proper support (e.g. the libphobos standard library) for many architectures.

Scripting languages have things a bit easier because they usually piggyback on the existing C/C++ compilers. So the developers for the most part only have to worry about OS portability, not CPU portability.

Re:The thing about new languages...

[Anonymous Coward]

Pascal has more than a few warts, which you'll discover if you spend time googling (which I did coincidentally a few months ago). There are at least a half dozen anti-Pascal papers from people who know what they're talking about - Brian Kernighan, who ported his book "Software Tools" to use Pascal to reach a wider audience, was one.

And no consensus emerged among compiler vendors on how to fix them. Meanwhile Nicklaus Wirth moved on to his next language, unlike others such as Stroustrup and Larry Wall who stayed around to evolve their languages.

Re:The thing about new languages...

[ChunderDownunder]

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:The thing about new languages...

[__aaltlg1547]

I'm wondering how you square this view with the abundance of Java.

Re:The thing about new languages...

[Anonymous Coward]

Hmm?

Java is popular largely because of all that. There's a shit tonne of developers, a huge and mature tool stack, and it's used widely enough that it is probably not going anywhere soon even if oracle tries to kill it. It's a pretty safe language to choose for most projects.

Re:The thing about new languages...

[Anonymous Coward]

Pascal has more than a few warts

What are the warts in particular? I like Object Pascal as implemented in the latest Embarcadero Delphi compilers. Free Pascal 3.0 will (I hope) implement many of the same language features.

Re:The thing about new languages...

[Anonymous Coward]

The biggest one I remember (that several pointed out) was that the length of an array was part of its type, and a function that took an array argument had to specify the array length. So if you wanted to write a function that iterated over the elements of the array, you'd either have to mandate the array length of the caller, or you'd have to clone the function for each array size you supported. BK in particular called this a deal breaker, especially for shared libraries, since the library and client code would likely be written by people in different organizations.

Re:The thing about new languages...

[Anonymous Coward]

The biggest one I remember (that several pointed out) was that the length of an array was part of its type, and a function that took an array argument had to specify the array length

OK, that's no longer true. Dynamic arrays have been a feature in Pascal for a long time. You can find out their length with Length(array), their lowest index with Low(array) and their highest index with High(array). Free Pascal has a wiki page on dynamic arrays and so does Embarcadero. Delphi XE7 introduced some new ways of working with dynamic arrays.

Re:The thing about new languages...

[disambiguated]

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.

Re:The thing about new languages...

[Anonymous Coward]

You're stuck in the 80's man.... Such arrays limitations were removed decades ago!
Also all those articles you see "why Pascal is bad" were written were Cobol and Fortran were still mainstream languages.

I've worked as a Delphi/Object Pascal developer for 12 years, the language has evolved to a point where it got most features from C++ and other popular langs (generics, operator overloading, lambdas, etc). Also it generates native code like C++, and has compilers for pratically all platforms (desktops, mobile and even other stuff, like some embedded hardware).
The biggest reason why Delphi stopped being a popular language was that it was originally tied to just a single company (who then sold the compilers to another company), who insisted to increase the price. Currently the IDE sells for a couple thousand, meaning, no new programmers will use it when they can use any other language for free. It is still the best solution for making cross-platform GUI apps though.

And yes, there are some open source alternatives, like Free Pascal Compiler + Lazarus IDE, but sadly, not many people know about them.

Re:The thing about new languages...

[Joey Vegetables]

I can do C, Java, Python, and .NET (C#) just fine. I can also muddle my way through C++ when I must. However, I'm nowhere near smart enough to do C++ well. I can't memorize the many edge and corner cases in the language definition itself, never mind the specific compiler implementations. I can't easily follow C++ code from people whose styles are significantly different than my own. There is a HUGE need for a systems programming language that is close to the metal, allows for higher-level abstractions than C, but is safer than C++, especially for mere mortals such as myself. I'm not familiar enough with D, Go, or any of the other contenders to know whether any of these is a good candidate to fill the niche created by the insane complexity of real-world C++. (Yes, I know that modern C++ is a much saner and cleaner language, but all of the legacy cruft is still there, and therefore must be understood to do C++ development in a team.) I predict that anything that is even close to being an acceptable substitute will eventually displace it.

Re:The thing about new languages...

[Anonymous Coward]

(I am not the GP (or the GGP)), and as a disclaimer I am a Java dev and have only briefly toyed with D. So take this as you will, but your answer seems obvious.

Java was invented by one of the biggest computing companies in existence at the time. It may not have had it all from the very start, but the fact that Sun pushed it internally and externally meant that it quickly gained some of the best cross-platform tooling, support, standard libraries, and developers.

If your question was more along the lines of "why didn't Sun just use C++?", I'd answer that Java is nothing like C++, it just shares the syntax. It adds things like sandboxing (the JVM), automatic non-optional memory management, "write once, run anywhere", and other features that you may or may not like/trust but provide clear and obvious advantages over C++ in a lot of situations.

Where D falls down, as GGP hints, is that it is viewed as C++ but without the weird stuff. That just isn't enough unless you push it like crazy. C# would similarly be nowhere if not for Microsoft throwing everything at a language that is just Java but without some of the weird bits.

Re:The thing about new languages...

[Anonymous Coward]

One should remember that most complaints came before the language was standardized and that the language actually used didn't have (most) of the limitations mentioned by the early complaints.
That said the original Pascal language wasn't really a general purpose language - however it wasn't intended to be. For what is was intended - as a lightweight language to teach structured programming - it was a good match.

Personally the worst "wart" of Pascal is how the semicolon is used as a separator... Don't think it is intuitive. OTOH I don't really like it for ending a statement either, thought IMHO that's more intuitive.

Re:The thing about new languages...

[david_thornley]

Yup. Every popular Pascal system dealt with the warts, not necessarily in the same way.

The warts I happen to remember from long ago:

The language imposes an order on functions, unless you use forward declarations, which suck in Pascal. If you write and read top-down, and have no mutually recursive functions, this won't bother you.

There is no separate compilation facility, and therefore no way to use libraries that's not horribly clumsy.

There is no initialization. If you want a string variable (whatever that was in specific) to have a value, it has to be assigned in executable code, often meaning the compiled image has to have duplicate strings.

I'd be surprised if anything you're using and enjoying has those warts.

Re:The thing about new languages...

[disambiguated]

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++ programming to people who have been doing it for decades. C++ just takes longer to learn that the languages you mentioned. Even when you feel you're starting to get the hang of it, a few years later you'll look back and realize you're still learning a lot. It isn't a matter of intelligence so much as persistence and continuing to expand your knowledge rather than settling down on some habits that work well enough but don't really take advantage of the full language.

And finally it's an illusion because other languages that have the expressive power of C++ aren't really simpler except in syntax. Consider for example a generic version of the useless function mul(a,b) which returns a times b, in C++, D, and Standard ML:

C++

template<typename A, typename B>
auto mul(const A& a, const B& b) -> decltype(a*b)
{
return a * b;
}

D

auto mul(A, B)(A a, B b)
{
return a * b;
}

Standard ML

fun mul(a, b) = a * b;

It appears that SML is simpler than D which is simpler that C++, but that's really just syntax. All of these are strongly typed, compile-time type checked, and work for arbitrary types. For example if a is a float and b is a vector of integers, then a*b is a vector of floats, which is a different type than a or b. Another example is if a is a 2x3 matrix and b is a 3x2 matrix, the return value is a 2x2 matrix. Generic programming requires you to think abstractly about operations where you don't know what the types are going to be. mul(a,b) is trivial, but if you imagine a more complex algorithm, you can see it's going to require careful thinking. It's just harder than working with concrete types, regardless of the language. Dealing with the syntax is just an annoyance.

The reward is that you get very powerful code that can be reused in many more situations without compromising type safety or performance.

I used generic programming as an example, but the same kind of arguments apply for object oriented, procedural or even functional programming. The real beauty of C++ (and D) is that you can combine these styles of programming according to what's appropriate for the task at hand. But you shouldn't expect that to be as easy as learning OOP in Java or procedural programming in C.

Re:The thing about new languages...

[Anonymous Coward]

It depends on how entrepreneurial your environment is, how future time oriented the culture is, and how much power you have.

It won't take long to make a good C++ developer productive in D, and this is what Sociomantic do. I actually don't think it would take so long to make a good Python programmer productive either. But I appreciate that for some firms, this kind of thinking isn't possible. I am glad to avoid such firms when I can.

The compelling reason for my business to use D is that there isn't really an appealing alternative for our work. .NET - mono is still not quite there on Linux. Java eats memory and is too verbose. (Scala is appealing, but eats even more memory it seems). C++ - the complexity of the language scares me, and nobody can say that this is intrinsically a highly productive way of working. (It seems like the latest version of the language and some libraries make things better, but...)

The flipside of the lesser prominent commercial element, is that if you want to hire a talented programmer, the D community may be a good place to go - even if you want C++! That is what Ruppe has found, and that is what I plan on doing when hiring in some months.

What toolstack do you need? I use sublime to edit, and personally don't find IDE debuggers useful. The libraries are lacking a bit, but you can generate bindings quickly using dstep for C code. There is an experimental full integration of C++ and D under LLVM, but you can still do quite a lot natively interfacing with C++ code.

As an observer of social trends, I don't see D going away any time soon. It's not the shiniest language and community, but there are deep signs of vigour. One doesn't worry about a twenty year old dying of a heart attack, even though it could happen.

Re:The thing about new languages...

[terjeber]

I totally disagree with you. I strive to learn a new programming language at least once a year. I also re-visit an old "friend" at least once a year. I have no need to "ditch" anything to learn something new.

For my daily work I do Java, C# and JavaScript mostly, and just because I have done some pet projects in Ruby doesn't mean I had to "ditch" C#. I can fit more than one programming language into my brain, but I can not be an expert in too many, obviously. Since C# and Java are syntactically more alike than different, and Google has all the standard Framework questions, I consider those two a single language, so switching between them is basically a noop.

So, if I only program in Java/C#/JS, why learn Ruby, Python or D? Simple. Every time I do a project in Ruby, I become a better Java/C# developer. If I brand into F#, I become a better JavaScript/Java/C# developer.

If I am in the process of hiring someone, if they have programmed in a single language for an extended period of time and do not have enough information to talk more or less intelligently about at least two other programming languages, I will recommend against hiring them. To me that is a far, far, far more important test than having them solve some retarded made-up programming related problem that they could find the solution to on Google in less than 30 seconds.

Re:The thing about new languages...

[superwiz]

Well, technically speaking, if your C++ spins python instances, it's JIT as well. Not to mention that it might be generating and loading shared libs (or at least accepting some sort of signed injected shared libs) in order to deal with unpredictability of changing requirements. I am actually somewhat baffled that the same people who think that dynamically generated shared libs are clever can be the people who think that JIT runtimes are crutches.

Having said that, let me actually get to your point. Semantically, C++ is C + syntactic sugar. So, while it's not implemented this way (anymore), it can be. So can any other language which has a run-time similar to that of C. Once you allow for language costructs which call into the native C libs on a platform, your language is good to go to be pre-processed into C at compile time and than compiled with whatever compiles your C.

BTW, syntactic sugar is not an insult. Syntactic sugar is a Good Thing (TM). It allows to offload to machines work which would otherwise have to be done by humans.

Gotta react to the market

[Actually, I do RTFA]

D's syntax is simpler and more readable than C++,... so shouldn't it be more popular?

I guess the users of languages don't like readable, simple, or maintainable code.

The languages with the biggest gains this time around include JavaScript, PL/SQL, Perl, VB, and COBOL. (Yes, COBOL.)

Confirmation!

Re:Gotta react to the market

[Anonymous Coward]

I guess the users of languages don't like readable, simple, or maintainable code.

The languages with the biggest gains this time around include JavaScript, PL/SQL, Perl, VB, and COBOL. (Yes, COBOL.)

Confirmation!

COBOL is by far the most maintainable, readable, well-structured and pleasant language out of those.

Re:Gotta react to the market

[david_thornley]

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 changed while I was determinedly ignoring it, but after fifteen or so years working in it I have absolutely no desire to touch it again in this lifetime.

Re:Gotta react to the market

[The Evil Atheist]

I actually think that's why some languages (and projects) are more successful than others. The thing with beautiful languages and beautiful code is it puts people off wanting to tinker with it. People are more comfortable messing around with things that are a bit messy. And that's how they become popular. LISP is by far one of the most elegant languages, but that reputation means it makes people want to spend more time coming up with elegant code rather than useful features.

A language like C++ has ugly syntax, so people feel comfortable putting some code down to solve a problem, and they think they can come back to fix its inelegance later. The good thing about C++ though is that it has templates and type deduction and so it is more achievable in C++ to actually come back to it and replace massive chunks of code with loops and conditionals with a few lines of algorithm calls. But it still allows you to write ugly looking code with the best intentions instead of making you do things the ordained way because some high priest deemed it so.

Re:Gotta react to the market

[Sun]

The D syntax may be more readable than C++, but to claim that it is simpler is just farcical. The number of language constructs, their specialization and their focus is staggering. For a language that set up to simplify matters, it has done anything but.

When you do:
A a;
a.something;

"something" might be a member. It might be a property. It might be a method with no arguments (which gets called). It might be a function defined outside the class with a special property. It might be any of the above on a member of A, specially defined (subtyping). I will not be surprised to hear I missed something.

How is that simple?

Shachar

Re:Gotta react to the market

[Cro Magnon]

IMO, COBOL was very readable, but no language can stop people from writing unreadable programs (and I saw lots of those). One of my gripes about the language is, it had no concept of scope; all variables were global.

Re:Gotta react to the market

[Actually, I do RTFA]

t no language can stop people from writing unreadable programs

While true, languages can encourage people to either create readable or unreadable programs. And which a language encourages has a lot to do with what you're trying to do in it..

Re:Gotta react to the market

[guruevi]

So-called readable and simple code is usually the least powerful because there is more time spent on it's semantics than what it actually has to do. Sometimes it gets so simplified that more complex operation require loads of customization to make something perform well (eg. by building additional C libraries -> see Python or Ruby) so it just is simpler to just do it well the first time around.

Re:Gotta react to the market

[euroq]

A a;
a.something;

"something" might be a member. It might be a property. It might be a method with no arguments (which gets called). It might be a function defined outside the class with a special property. It might be any of the above on a member of A, specially defined (subtyping). I will not be surprised to hear I missed something.

How is that simple?

You just described a simplified syntax for doing 5 things. That there is only 1 syntax as opposed to 5 syntaxes makes it simple.

Re:Gotta react to the market

[Anonymous Coward]

After you write how many copy constructors and assignment operators?

C++ has by far the most useless cruft of any language I've worked with if you follow all of the recommended practices to make your code robust. Much of this is to overcome poor decisions in the design of the original language (e.g. the slicing problem).

And a lot of the things that can potentially break your code are very hard to see among all the junk that cruds up your C++ code.

A smart language would automate all of that stuff. Most of them do.

Perl, PL/SQL, and Cobol

[Anonymous Coward]

Perl; a language whose next big version has been stuck in Wall's development hell since iOS was just an OS run on routers.
PL/SQL; a SQL variant whose idiosyncratic syntax qualifies you to write code for systems built by your father.
Cobol; It's fucking Cobol.

Any remaining faith I had in the Tiobe index is dead.

Re:Perl, PL/SQL, and Cobol

[CrazyBusError]

I love how webdevs and embedded programmers manage to constantly underestimate the sheer volume and scope of enterprise code that exists in the world.

Perl: Can't disagree there, really.
PL/SQL: Right, because oracle enterprise usage is dying out and no-one creates new databases based on it anymore...
COBOL: This will continue to exist when there's nothing left but rats and cockroaches. Wanna know why? Because it *works*, it works on mainframes, and it works *fast*. The business processes it runs rarely change and the code is all a very well known quantity by know, so there's absolutely no need to change it any more than utterly necessary. Sorry to inform you, but it's going to be around for another 20 years at least.

I think D

[Anonymous Coward]

is universally underrated. Everybody needs more D.

Re:I think D

[Anonymous Coward]

DD should be sufficient.

Re:I think D

[Anonymous Coward]

Her cup runneth over.

Re:I think D

[Anonymous Coward]

Or a few minutes of sunlight. Oh, I forgot this is /.

Cute specs, call me when you turn 18.

[pla]

So shouldn't it be more popular?

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.

[Anonymous Coward]

"We play both kinds of music. Country... and Western."

- The Blues Brothers

Re:Cute specs, call me when you turn 18.

[aardvarkjoe]

All three platforms, plus FreeBSD. So there's compilers for 133% of platforms! How can you compete with that?

Re:Cute specs, call me when you turn 18.

[Tablizer]

Obviously the compiler has a floating point bug.

Re:Cute specs, call me when you turn 18.

[rdnetto]

"D offers compilers for all three platforms (Windows, Mac and Linux) as well as FreeBSD."

Note that two of those compilers use GCC and LLVM as their back-ends. In practice, this means that you can use D on any architecture they support. For example, here's a patch that adds D support to buildroot toolchains.

I do agree that the third-party libraries available are pretty limited though.

Re:Cute specs, call me when you turn 18.

[Anonymous Coward]

So BSD isn't a platform?

Non-Dice, Non-tracking link to D

[OzPeter]

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

Delphi...

[ELCouz]

Delphi is good... In fact much better (asm support, low level access, compiled to machine code) than even .NET VB Niche in the job market thought!

Re:Delphi...

[CycleFreak]

Always loved Delphi. Went to a dev conference way back in the day when Anders Hejlsberg was still the chief architect at Borland for Turbo Pascal and then the Delphi product.

Have a look at the Lazarus Project if you don't want to get the current Delphi product from Embarcadero.

indied

[Anonymous Coward]

Cobol, ABAP, ADA - that's the future. & Fortran

Re:indied

[Anonymous Coward]

It's "Ada," moron.

Re:indied

[Sudline]

I confirm, this comes from Ada Lovelace. But it is not necessary to be rude.

Well...

[Amorymeltzer]

I'd give it a D+

Buggy compiler

[Anonymous Coward]

I ran into compiler bugs (including segmentation faults) within the first hour of playing with it. So I gave up.

Perl, my favorite language is rated higher...

[jjn1056]

... but I still think the rankings here are just about meaningless.

Re:Perl, my favorite language is rated higher...

[Tablizer]

Why is Perl up? It had been going down in use for a while. What event/change/fad sparked an uptick?

Or is it just random ebb and flow?

(I'm not trying to trash Perl, but there is something odd about the trend pattern here.)

Re:Perl, my favorite language is rated higher...

[aralin]

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 enough to build a large base of libraries and examples, so that it will stay and maybe even replace PERL eventually, who knows. But you gotta understand that every 10 years or so, all the old languages get a push from the above mentioned change of guard in the development positions.

Re: Perl, my favorite language is rated higher...

[Anonymous Coward]

Mojolicious

Re:Perl, my favorite language is rated higher...

[TapeCutter]

Old languages - C has been on top of every survey I have seen for the last 25yrs.

Re:Perl, my favorite language is rated higher...

[aralin]

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

[Tablizer]

C is the "new assembler". If you want tighter control over machine resources, then C is the next best thing to assembler/machine-language. CPU's are designed with C in mind even, so it's a 2-way street.

Re:Perl, my favorite language is rated higher...

[DuckDodgers]

Python nearly kneecapped itself with its switch from 2.x to 3.x. But most major Python code is 3.x -compatible. I expect the language to stay pretty popular.

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 Python's killer feature and the source of its staying power. Otherwise it doesn't have anything in particular to recommend it over Perl, Ruby, or even PHP.

Re:Perl, my favorite language is rated higher...

[aralin]

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 changing impact.

PERL has the write hundred ways quality, but in enterprise you can agree on standard way to write and then a larger team can be more productive in PERL than Python. PERL is also so much better at language embedding if you need to implement core routines in C.

On the other hand Python excels in the new to scripting, small (5) cohesive team market. They got that pretty much cornered now.

Re: Perl, my favorite language is rated higher...

[Anonymous Coward]

Perl is very similar to English.

Very few understand the complete set of rules, exceptions, and idioms.

Lots of people can get Perl to do the job, in the same way broken Engrish can get a message across.

It's still not the same as knowing the language, and using it well.

Re:Perl, my favorite language is rated higher...

[Sun]

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: Perl, my favorite language is rated higher...

[ThePhilips]

[...] in the same way broken Engrish can get a message across.

Which is kind of the whole point of the programming languages: getting the message across. Telling computer to do the job.

It's still not the same as knowing the language, and using it well.

Knowing language != being able to write good program in it. Real programmer can write good program in any language.

And "using the language well" is just meaningless statement, highlighting the modern focus on the form rather than content. AKA good program as beautiful programs vs. good program as working/useful program.

Why write several lines that do the job - when we can create beautiful class hierarchies spread across numerous libraries, use modern concepts and paradigms to accomplish the same?

Re:Perl, my favorite language is rated higher...

[Joey Vegetables]

Python has the huge advantage of being fairly easily readable, if you can get past the whitespace-as-syntax. Readability is HUGELY important in the real world, because most code is read far more often than it is written.

Re:Perl, my favorite language is rated higher...

[happy_place]

Here's why:

http://programming.tudorconsta...

The example at the end explains it most effectively.

Re:Perl, my favorite language is rated higher...

[david_thornley]

Objective-C is a strict superset of C, so you can do low-level system programming with it. I'm not sure that you'd ever want to write Objective-C that wasn't also straight C in such, but it's usable. It's also part of gcc, last I looked, although not really well supported on any platform that isn't from Apple.

Re:Perl, my favorite language is rated higher...

[Sun]

By "one platform" I did not mean it was unsupported. I meant it was unused.

You don't find many uses of Objective-C outside of the Apple echo system.

Shachar

Re:Perl, my favorite language is rated higher...

[aralin]

Readability always depends on the programmer. Indentation does not give you readability by itself. You need modularity, comments, compactness, good symbol selection, etc. There is so much more to readability. Maybe you just saw a python written by very good programmers, but I saw python scripts written by mediocre programmers and they are not any more or less readable than any other program in any other language that I run through indent.

Re:Perl, my favorite language is rated higher...

[rdnetto]

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.

Not sure if you know this, but the GC was recently / is being rewritten, which should hopefully improve things. There's also the new std.allocator interface.

That said, I don't think anyone can seriously claim D has good non-GC support, and it sounds like you definitely need a non-GC language given your latency requirements. Rust would probably work better, but it has its own quirks.

Re:Perl, my favorite language is rated higher...

[Anonymous Coward]

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.

some C++ features are not suitable for some low level scenarios.

When it comes to the language rankings, I think C comes out on top even though many of the people claiming to be using C are actually using a restricted subset of C++ or Objective C. The "C Compiler" is almost always actually a C++ and/or Objective C compiler (GCC, CLang and MSVC are all like that). And they all have command line switches to disable the more unsuitable-for-low-level features, like exceptions and RTTI.

It's reasonable to call that "C Programming" even though it isn't pure C, because calling it C++ or Objective C would be misleading given that the code itself is really closer to C. For those who really do stick to pure C, if you compare C89 to C99, you see a bunch of C++isms have been added, and I think that trend will continue.

I would take the relative ranking of C, C++ and Objective C with a grain of salt.

Re:Perl, my favorite language is rated higher...

[InfiniteVoid]

I'd be interested to hear about the cases where you can't use a destructor, or where the compiler won't call a struct's destructor, if you care to provide a bit more detail.

Re:Perl, my favorite language is rated higher...

[Sun]

Due to compiler bug, the following:

SomeStruct[10] s;
// Do stuff with s

s.init;

Up until recently, s's destructors would not be called.

In the language definition proper:
auto s = new SomeStruct;

The destructor is never going to be called, even when s's memory is reaped by the GC.

Shachar

Re:Perl, my favorite language is rated higher...

[Sun]

Forgot to add:
The second point above might seem petty. After all, that's why D distinguishes between structs and classes, right?

Then please consider the following:
void func(lazy bool e);

void otherfunc()
{
SomeStruct s;

func(s.isTrue());
}

Since func receives a delegate, s is allocated on the heap (despite this not being immediately obvious to people not versed in D). As a result, s's destructor is not going to get called. Ever.

Shachar

#35!

[Anonymous Coward]

#29, as an example, is Visual FoxPro.

Draw your own conclusions.

Re:#35!

[Anonymous Coward]

Some people still use VFP you insensitive clod!

Re:#35!

[Anne Thwacks]

Yes, but think of the children!

I prefer D++

[Anonymous Coward]

D# as well.

Esperanto is much easier than English

[Anonymous Coward]

And yet very few switch

Re:Esperanto is much easier than English

[Anonymous Coward]

Esperanto has poor compiler support, no IDEs, and doesn't integrate well with legacy English code.

Re:Esperanto is much easier than English

[Chrisq]

Esperanto is much easier than English ....And yet very few switch

That is a very good analogy. Unless you are a language enthusiast or have a niche requirement you probbly won't use Esperanto ... or D

Should be, but it isn't.

[Anonymous Coward]

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:Should be, but it isn't.

[H0p313ss]

Failure by design?

D is the Betamax of programming languages, well thought out, feature rich but flown into the ground.

Re:Should be, but it isn't.

[Anonymous Coward]

Thanks for the honest appraisal from someone who despite the 'complaints' likes it. Often, and understandably, a comment is naturally biased because of support or objection to the original author or the commentary. :)

Re:Should be, but it isn't.

[DuckDodgers]

The DMD compiler isn't free software because Walter Bright doesn't own all of the intellectual property rights. He has the right from other copyright holders to redistribute the code, but not the right to relicense it.

Re:Should be, but it isn't.

[loonycyborg]

The closed source nature of dmd is the whole reason I didn't actually try to learn D. Either reference compiler is open-source and open for contributions or language has no future and no point in wasting time.

Re:Should be, but it isn't.

[Anonymous Coward]

The closed source nature of dmd is the whole reason I didn't actually try to learn D. Either reference compiler is open-source and open for contributions or language has no future and no point in wasting time.

What? You are completely wrong. DMD frontend is Open Source (Boost license) even backend is open source (in way you can see code and make contribution). And there are alternatives backend gcc and llvm, which are even more Open Source :). So there is no reason to not try learn D.

Re:Should be, but it isn't.

[Anonymous Coward]

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.

This is not a big problem. On windows it is irrelevant and on Linux it is not problem too. For eg.: archlinux (pacman -Sy dmd), it is in official repository. And there are still GDC and LDC.

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.

Not true anymore. LDC 0.15.1 has same frontend as official dmd compiler, GDC is only one release behind.

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

I prefer CMake, but I do not have any problem with Make too. But still you can use LDC(CMake) and GDC(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.

I use DUB few times without problems, but it is young software so I belive there is place for improvments.

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.

No, Linux support is much better than windows from my POV. This has been problem in past I guess.

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

I do not see any issue, he just think he must convert it to char[], but he has been mistaken. To be fair the only think I hated on D string type is autodecoding.

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/

Yes it is :)

Re:Should be, but it isn't.

[loonycyborg]

The real reason that it's not in portage, and I had problems using ebuilds from overlay. Problems that happen only with closed source stuff. If it was open then Gentoo would be performing full 3 stage bootstrap of it in ebuild(assuming it's self hosting).

Re:Should be, but it isn't.

[loonycyborg]

Oh wait. It seems Gentoo has ebuild in portage for it now. But still binary only for some reason.

Re:Should be, but it isn't.

[Anonymous Coward]

Maybe you know this, but it's only the backend of the reference compiler that has a somewhat restrictive licence. Even then, the source is fully available and contributions work in the same way as for the rest of the compiler and standard library, through github.

Unless you plan to distribute DMD, you wouldn't even notice.

Re:Should be, but it isn't.

[rdnetto]

I've been using the overlay, and while I don't like how they've put everything in /opt, I haven't had any problems with it. The ebuilds for gdc, etc. are properly bootstrapped.

(The separate directories in /opt are apparently the result of the lack of a stable ABI between compilers, or even between different versions of the same compiler. AIUI, C++ has the same problem, but most distros just treat GCC as the official compiler instead of treating them all equally.)

Re:Should be, but it isn't.

[loonycyborg]

Of course they are, but they aren't reference compilers.

At some point having d overlay led to getting warnings during portage sync and what-not, so I removed it.

All in all I just didn't consider it interesting enough to study even. I'm more interested in a true paradigm shift rather than another iteration of C++ which already is good enough for my taste. So I still have haskell overlay and actually do learn haskell :P

Re:Should be, but it isn't.

[rdnetto]

All in all I just didn't consider it interesting enough to study even. I'm more interested in a true paradigm shift rather than another iteration of C++ which already is good enough for my taste. So I still have haskell overlay and actually do learn haskell :P

I'll agree with you there - D is the sort of language that tries to copy as many features as possible from other languages, rather than one which tries to do anything truly revolutionary. (I think UFCS is the only novel feature it has, and it's nothing more than a nicety.)

Haskell is definitely a much more interesting language - I spent the entirety of last year working with it and don't feel like I even scratched the surface. There are some applications imperative languages are better for though, so it is nice to see languages like Rust and D providing support for both.

Re:Should be, but it isn't.

[Anonymous Coward]

The source is here:
https://github.com/D-Programming-Language/dmd

Here is a guide to the source code:
http://wiki.dlang.org/DMD_Source_Guide

Contributions are welcomed:
https://github.com/D-Programming-Language/dmd/pulls
http://wiki.dlang.org/Get_involved

Half of it is open-source, and the other is not. But not totally open-source for this other half is more like a legal nicety. Walter Bright isn't able to transfer the license away, even if he would like to, because his former employer owns it. But he can give people the right to redistribute derivative products of the compiler, and he has not been known to refuse (as far as I am aware).

Re:Should be, but it isn't.

[Anonymous Coward]

FUD much?

Are Fedora and Arch distributions? (Maybe others too, but those are the ones I know about):

DMD:

[root@localhost kprop]# yum search dmd
dmd.x86_64 : Digital Mars D Compiler

[root@localhost kprop]# yum search ldc
ldc-config.noarch : Config file for ldc
ldc.i686 : A compiler for the D programming language
ldc.x86_64 : A compiler for the D programming language
ldc-druntime.i686 : Runtime library for D
ldc-druntime.x86_64 : Runtime library for D
ldc-druntime-devel.i686 : Support for developing D application
ldc-druntime-devel.x86_64 : Support for developing D application
ldc-phobos.i686 : Standard Runtime Library
ldc-phobos.x86_64 : Standard Runtime Library
ldc-phobos-devel.i686 : Support for developing D application
ldc-phobos-devel.x86_64 : Support for developing D application
ldc-phobos-geany-tags.noarch : Support for enable autocompletion in geany

It's a mispresentation (whether or not innocent) to say that Alexandrescu and Bright focus on DMD, suggesting implicitly that this is a commercial product and the language comes second. Their primary focus as manifested by their behaviour as well as words is on the D language. Nobody is making a buck from D compilers. Bright works on DMD because that what he can control - and it is desirable that he does so because it's a pretty good compiler, and there is a tremendous benefit to the language from having a top notch compiler designer having architected it and continuing to shape its development. One wouldn't want him ceasing to work on DMD, or to split his energies maintaining two other compilers too. Strength from diversity, not from having a monoculture of implementations.

In practice, I am not so sure how often you find that you can't do what you want in LDC because of a few months lag. For some people it may really matter, but I doubt it's many. And it's hardly the most important question when making such a basic decision as language choice.

You find the DMD and Phobos build harder than a typical autoconf etc setup? Really? As a newcomer to D, it took me a few minutes to figure out I had to change a couple of paths in the makefile. And then it just worked. And compilation on my oldish machine was a few minutes for the whole language and libraries. Compare that to a typical C++ project... This being said, there has been a push by Alexandrescu just a couple of days ago to update the build system, so not bad will shortly become better.

dub takes some getting used to, but much less than make, and it's really not too bad for a pure D project. Nobody is forcing you to use dub though - you can use whatever you want.

I haven't experienced any link problems on Linux, nor heard of it being a problem for many. It's arrant nonsense to say that there is a big focus on Windows, if by that you mean at the expense of Linux. Linux support is a bit better on the whole. I would guess a majority of people on the forums use Linux. Sorry to hear you are having problems, but it's probably something quite simple that can be easily fixed. If you post on the forum, people are pretty helpful.

Re string - the standard library could do with a bit of polish, but that's hardly a deal-breaker or maker. One should keep things in perspective - maybe D is not right for you, but one should make that decision on the basis of relevant factors, and bearing in mind the alternatives.
As regards GDC and LDC lagging,

I tried it

[gabereiser]

and I liked it, until I tried to deploy it. I think D could really use some more documentation on deploying applications written with it outside of the systems applications. I tried making a desktop application (opengl based) with it and found it extremely difficult to deploy to other machines let alone Mac OSX. But then again, it could have just been my naiveté.

Re:I tried it

[Anonymous Coward]

I'm sure documentation could be written, but deploying an application usually is very application specific. That said, it being a native language the deployment will very much resemble that of the same program written in C.

Re:I tried it

[rdnetto]

Given that DMD, etc. statically link the standard library by default, the resulting executable won't be significantly difficult from one produced by a C compiler. My guess is you either ran into issues with dub, [1] or you dynamically linked something opengl-related and had trouble due to that on the other systems.

[1] Minor rant: why does language popularised in the last decade need their own, language-specific package management? What's wrong with make or cmake?

Re:I tried it

[gabereiser]

My issue was a little more complicated than that. I made something with D, tried to package it up as an App Bundle for Mac, while it worked, it was rejected due to using "proprietary api's". On Windows, I had to use a hex editor and resource editor to give the resulting exe an icon. On linux, depending on the flavor, I had to add all these extra things just to get it to show up on the desktop (granted, that's not a D limitation, but rather a linux desktop environment limitation as it's different with each). So for "desktop" apps, it was a pain. I eventually gave up and wrote it in C++.

Re:I tried it

[Anonymous Coward]

On Windows, I had to use a hex editor and resource editor to give the resulting exe an icon.

Were you using Visual D plugin with Visual Studio? I've never used D but I'd have thought the Visual D plugin integrated with Visual Studio well enough to make setting an icon for the executable easy.

Not just underrated....

[unixisc]

... but unheard of, as well

Mod parent to + infinity!!!!

[Anonymous Coward]

extremely relevant

Re:Mod parent to + infinity!!!!

[bazmonkey]

I hate you.

Re:Mod parent to + infinity!!!!

[Anonymous Coward]

He is sort of right. For a systems language, garbage collection cannot be *mandatory*; at least for the sensitive (particularly real-time) part of the code.

What you really want is compiler verifiable *safety*.

Rust is an example out of the conundrum; as it removed garbage collection from the core (though it exists). Garbage collection is only one way; and it has a runtime cost. Annotating pointers so that the compiler *can* certify safety of their use without runtime costs is another way. In core Rust, there is no mandatory garbage collection, but instead there are more pointer related annotations.

C's problem is one of bad defaults defeating good tooling everywhere. Pointers should be guaranteed initialized as the default. Nullable pointers are not the same type as pointers). If you want an unchecked and unproven array indexing, then that should not be the default. If the default in C were to force you to annotate unprovable constructs as "unsafe", then you could still get away with anything at the cost of having some annotations everywhere you used problematic constructs. In such a language, if the compiler could just *tell* you what assertion must be true in order to prove a line of code safe (ie: "foo.c2:50 => must assert(initialized(ptr) && ptr!=NULL)"), it would be fine to simply assert that condition until the compiler can finally prove it (and tell you to then remove the assertion). That way, you could set the assertions in that package to either: 1) default: abort with a message 2) check and log violations 3) totally unchecked.

Also, as is plainly made obvious by the success of the "go" command line, "cargo", "rails", "mvn", LLVM, SCons, etc... C projects have a problem with the compiler interfaces being way too primitive. We have adhoc messes with Make that have implicit dependencies on primitive shells. The compilers themselves should be quite scriptable and toolable (see LLVM! then look at it again!). Entire projects need standard interfaces to aggregate/update/make/build/test/deploy. Making static library-less binaries should be the default stance as in golang. Etc...

None of this implies that you need an obese language with a lot of runtime overhead or a blind compiler that can't be properly tooled.

At least it has a Wikipedia page

[wiredlogic]

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.

Re:At least it has a Wikipedia page

[Anonymous Coward]

Nim is a fucking joke. That's why it doesn't have a Wikipedia page.

I lurk on their IRC channel sometimes. The idiocy there is unbelievable.

Look at the IRC logs for today, for example.

We see insults like:

17:46:17 ldlework EXetoC: the problem is that you're just spouting weightless and thoughtless generalizations about how you can whimsically avoid BlaXpirit_'s problems with magical design

19:08:33 ldlework Your justification is piss.

19:10:07 Zuchto BlaXpirit_: because ldlework is being an ass to the person that, as far as I know, is doing just that

20:14:47 Zuchto ldlework: still being an ass, I would say that that makes any high ground you try and claim about being a "good internet citizen" pretty much null and void.

And there's lots of unnecessary sarcasm:

19:54:14 ldlework "Nim supports generics and inheritance but if you want to do OOP programming, Fuck You, Nim is really a functional language because we arbitrarilly limit the language to mirror limitations in F# (which show up for compltely unrelated reasons than in Nim)

Then there's lunacy and quasi-psychotic ranting and rambling:

19:58:39 Triplefox I like the modules as they are
19:58:51 ldlework Triplefox: we're not trying to change the module system per-say
19:59:06 ldlework And, great as long as they're sufficient for you, we should all shut up
19:59:19 BlaXpirit_ damn you're good at arguments
19:59:19 ldlework Let us remember to run by all our shortcomings with Nim through Triplefox first
19:59:47 ldlework BlaXpirit_: because the actual answer here is "Oh right, just wait until forward type declarations."
19:59:58 Triplefox Uh, so you want to bully?
20:00:17 ldlework If Araq had just said that instead of taking some high-brow self-contradicting position for which he can provide no direct argumentation against, then we both would have been satisfied long ago.
20:00:26 ldlework Because that's all that needed to be said about this problem.
20:02:57 ldlework Triplefox: Uh, so you just want to sqaush other people's conversations that have no effect or bearing on you by making a wierd obersvation that you don't suffer the same difficulty as others?
20:02:59 ldlework What?
20:03:56 Triplefox Your conversation consists of forcing someone to say they're wrong
20:04:06 ldlework Nope
20:04:08 ldlework There is a problem X
20:04:14 ldlework there is a sufficient solution Y
20:04:23 ldlework But Y is purportedly bad because X shouldn't be a problem at all
20:04:31 ldlework so instead of providing a solution to X
20:04:32 ldlework we say
20:04:34 ldlework You're wrong.
20:04:37 ldlework You're thinking wrong.
20:04:40 ldlework You're a bad programmer.
20:04:42 ldlework Read this article.
20:04:56 ldlework If there was a solution as nice as Y, that we were missing, everyone here would have provided it.
20:05:03 ldlework Instead of the hand waving and high-browing.
20:05:37 Triplefox Except that you're getting a change already
20:05:45 ldlework Triplefox: right, that was my point, that's Y
20:05:55 ldlework But we just had to pointout how people who need Y are terrible programmers
20:06:06 ldlework Because there is some hidden unspoken thing you could do instead of X that would alleviate it
20:06:16 ldlework Just it seems no one can actually produce what that altnerative is
20:06:38 ldlework So the discrepency between "Shutup and just write your software correctly" and the blinding abscence of a simple solution being reported into the channel, speaks volumes.
20:07:25 Bla

Yippee!

[VAXcat]

Perl went up in the ratings!

PL/I on TIOBE

[Rob Riggs]

Who knew that PL/I was still a thing? Hell, even IBM is releasing a compiler update for this language. Somehow it is about as popular as D.

Re:PL/I on TIOBE

[msobkow]

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:PL/I on TIOBE

[Kishin]

PL/I is what many mainframe applications were written in. MULTIC's was written in a similar language because it prevented errors you see in others. IBM's mainframe OS IIRC was written in a runtime-less version called PL/S. They considered it a secret weapon for a combination of productivity, performance, safety, and safety/speed tradeoffs. There are two papers you can find with Google on it. Interesting part is how you can put identifiers in each function to control how compiler will transform it to machine code. That both allows and documents tradeoffs you make on a per module/function basis. Mainframes set the gold standard in reliability with often 30+ year uptimes so I think it's unwise to laugh at their design and implementation choices. Unlike my UNIX/Windows boxes, those PL/S and PL/I apps virtually never fail. Language design probably contributes a little bit. -Nick P

Re:PL/I on TIOBE

[Anonymous Coward]

Not only that, it comes in ahead of Scala.

Re:PL/I on TIOBE

[sconeu]

Let me guess... WUSTL? I remember that we wrote PL/1 using the PL/C subset in '80 and '81. Go WUSTL Bears!!!

Re:PL/I on TIOBE

[gadfium]

Alas, there is no free PL/I compiler for Windows or Linux; certainly not one with anything approaching a full feature set and currently maintained. I learned PL/I at technical college in the 1980s and it was certainly better than the other languages taught then (COBOL, BASIC and RPG). I would like to be able to write a few programs in it for nostalgic reasons.

Problems in C++

[ShakaUVM]

>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 write_array(int arr[]) { for (int i : arr) cout i; }

STL arrays and vectors are obviously better, at the cost of decreased code readibility. Square bracket accesses are easier to read than .at()s everywhere.

2. Strings. Even with the string type, it is still shitty to use, still has terrible support, and you still have to use the c library string.h for some functionality since they've been too lazy to rewrite all of them into the C++ standard library. This means that people wanting to use the C++ string class still need to know the C way of doing things, and are still vulnerable to the same off by one errors that have been around for decades.

3. Almost no reflection capabilities.

4. The language still enforces rather idiotic rules about class and function definitions that modern languages have done away with, and for the better. It's not like putting #ifdef guards on your code is difficult, but in these modern times it should not be necessary. And forward declarations are a way of saving compiler time at the expense of programmer time. This is the opposite of what should be happening. Compilers are there to make programmers' work easier, not the other way around.

5. C++11 and later has made great strides in simplifying the life of programmers, but its cruft accumulation shows.

Re:Problems in C++

[Anonymous Coward]

Amen to 5: The reuse of keywords in C++ is beyond a joke.

Re:Problems in C++

[linuxrocks123]

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:Problems in C++

[Anonymous Coward]

1) Both std::array and std::vector have the [] operator overloaded. You don't need to use .at().
3) If you introduce reflection, then you cannot optimize out methods and functions or even entire classes even when that's possible to do so. Worth it, especially when metaprogramming can replace a lot of the gains from reflection.
4) Any sensible, mainstream compiler should have a #pragma once or similar directive.

Re:Problems in C++

[Anonymous Coward]

Say hello to my little friend: http://en.cppreference.com/w/c...

Re:Problems in C++

[angel'o'sphere]

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:Problems in C++

[ShakaUVM]

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

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

The biggest gaps were filled in C++11 with replacements for atoi() and so forth, but there's still no replacement for strtok or some of the other functions in the core language.

>>3. C++ isn't an interpreted language; of course it won't have much reflection.

Sure. Makes life more difficult though by pushing those tests out to the linker instead of being able to code them directly from the language itself.

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

Not my point. Quite obviously you need declarations for extern names not found in the file scope. But for functions within the same file scope, you still need to do forward declarations, which is only done to avoid having to do an extra pass over the code. Might have made sense in the 80s, but not today. Maybe it's not a huge deal since it's just a single copy and paste and edit every time you change a function definition when you're working on it, but it still otherwise serves no benefit.

Also, there shouldn't be much need for #ifdef guards any more. It's 2015. We should be able to include the same function definition twice without the universe breaking.

Re:Problems in C++

[linuxrocks123]

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 that in production just for some slight convenience while debugging. If you want bounds checking while debugging, use []s like normal and just pass the special flag to GCC to enable run-time STL debugging. .at() is for special cases, which is why it's syntactically awkward. If it were meant to be used in the general case, it would have been defined as the [] operator and the non-bounds-checked version would be .at().

2. I wrote my own tokenizer a decade ago. It's about 20 lines of code. Maybe I should publish it if it's that Earth-shattering.

3. I've never found myself wanting more reflection than what's provided by RTTI. In fact, I don't often use RTTI, either. Reflection is for dynamic languages; it's just not appropriate in this space.

4. It's never bothered me, but I can see it being a pet peeve. Yeah, I guess it's a holdover from earlier times. However, you can include the same function definition twice. Just use inline :) Whether the universe breaks depends on whether the definitions are identical.

Re:Problems in C++

[Anonymous Coward]

You'll never get past the people who aren't capable of understanding the strengths of C and trying to refer to them as weaknesses. Other, higher level, languages were designed for them. Unfortunately this is as far as they are capable of going and understanding. Sadly, they don't understand this about themselves, and because of this say things that don't make a lot of sense outside of the limited context they have available to themselves.

Re:Problems in C++

[linuxrocks123]

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:Problems in C++

[Anonymous Coward]

Also, there shouldn't be much need for #ifdef guards any more. It's 2015. We should be able to include the same function definition twice without the universe breaking.

This is to prevent circular dependencies. If you hit it, it generally means "fix your code!". For other cases, you can just stick "#pragma once" as the first line of your header. It's supported by every important compiler out there.

http://en.wikipedia.org/wiki/P...

Re:Problems in C++

[Jamu]

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:Problems in C++

[boristhespider]

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 they come with one drawback, which is that there's no standardised way of enforcing a virtual destructor. I'm fine with putting in a virtual destructor in every base class but again, it's just noise. There's no need for it now. I should be able to declare

interface Interface
{
    void Method();
}

and have that exactly equivalent to

class Interface
{
public:
    virtual void Method() = 0;

    virtual ~Interface(){}
}

and have

interface Interface
{
    void Method();

protected:
    ~Interface(){}
}

equivalent to

class Interface
{
public:
    virtual void Method() = 0;

protected:
    ~Interface(){}
}

Not difficult to do, but it's not in the standard. It would cut down noise for those of us who make extensive use of interfaces and reduce the risk of accidental memory leaks quite significantly.

Re:Problems in C++

[Anonymous Coward]

Simply adding data somehow magically causes slowdown? What?..

Unless you actually use reflection, metadata just lies there in memory, doing nothing. It's also not some extraordinary amounts of memory, unless we're talking having to fit in kilobytes of on-chip PROM. It's just a kilobyte or so for each class and a pointer to class data for each object. It's already there in a limited form as RTTI.

I'm pretty sure you don't know what you're talking about.

Re:Problems in C++

[linuxrocks123]

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 for C++ ... but it's not at all obvious how such a system would interact with C++'s type system and just how it would work at runtime without causing slowdown. A kilobyte of data for every class definition is already VERY significant overhead in C++-land, and that's not all you would need. You'd need some sort of "magic" classes to provide the data requested to the classes and then do even more magic to invoke the discovered methods in some sort of reasonable way.

And what, exactly, would you get for your trouble for having done this? Java needs reflection for dynamic loading. C++ and C have a different system for dynamic loading based on the POSIX dlopen() and friends. In a very real sense, dlopen() is C++'s reflection system. Why do you think it needs another one?

Re:Problems in C++

[hermitdev]

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:Problems in C++

[Anonymous Coward]

In any non-memory-constrained application, shared kilobyte or few of metadata per class would be completely overshadowed by combined size of classes' code and all the instances - but that's a side note, as your objection was about performance, not memory use.

As for performance, why would statically known method calls suddenly require invoking reflection just because it's there? Even in Java's case such calls get JITted to quite straightforward code, as opposed to actually using reflection for dynamic invocations.

> In a static language, this is for obvious reasons extremely hard to do.

Surely you meant "In a static language this is relatively easy to do" - as proven, again, by Java.

PS: Don't let Javaphiles see you talking about "Java-level slowdowns", or we're not gonna see the end of the discussion between all the "but my benchmarks!.." - "but you mean *micro*benchmarks on a warmed up VM!.."

Re:Problems in C++

[linuxrocks123]

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 per object pointing to the class metadata like for RTTI. And unlike with RTTI, the overhead won't be limited to classes with vtables, because who knows what you might call this thing on?

All in all, it certainly wouldn't be possible to add reflection to C++, but I'm still not seeing why you'd want it. If you want to dynamically load libraries, just use dlopen().

Re:Problems in C++

[Anonymous Coward]

> you'll have to carry around metadata per-object, not per-class; you'll at least need one pointer per object pointing to the class metadata

Uh, that's exactly what I said in my first post.

> I meant "statically compiled language", not "statically typed language". I should have specified.

It makes it only easier. For example, when adding an extra pointer per instance is too much, that theoretical C++/Reflection compiler could have an option to control (non-)inclusion of reflection per class via attributes. Obligations only exist between the host program and possible dynamically loaded modules. In Java's case host program is generic VM and it's obliged to provide everything from every dynamically loaded class to every other one. In case of your own host, it's at your discretion. Just like -fno-rtti, you could compile your program with -fno-reflection.

Don't ask me "why", though - I'm only here to discuss "why not". Better dynamic loading than just getting a raw pointer to hopefully proper function from dlsym()/friends and then getting a table of raw pointers to functions from it as result could be nice, though.

Re:Problems in C++

[Anonymous Coward]

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.

1) No, that's not the case. The difference between .at and operator[] is that .at() has a const overload and operator[] is not.
2) Most high performance apps (eg. games) turn off bounds checking in any case for performance reasons.

The biggest gaps were filled in C++11 with replacements for atoi() and so forth, but there's still no replacement for strtok or some of the other functions in the core language.

Uh, stringstreams? http://stackoverflow.com/questions/11719538/how-to-use-stringstream-to-separate-comma-separated-strings

Re:Problems in C++

[Anonymous Coward]

You should be using std::array or std::vector.

std::array works exactly like a built-in array, but not only knows it's size, it also exposes the same interfaces as any container so you can write code using std::array and switch it to std::vector later if you want without changing any code except the declaration of the array.

Re:Problems in C++

[rdnetto]

3. C++ isn't an interpreted language; of course it won't have much reflection.

While reflection is much easier to implement in interpreted languages, there are compiled languages that support it. e.g. D

Re:Problems in C++

[ardor]

> The biggest gaps were filled in C++11 with replacements for atoi() and so forth, but there's still no replacement for strtok or some of the other functions in the core language.

stringstream and getline together can be used to form a tokenizer. I am not saying it is a paragon of beauty, but it works. See: http://stackoverflow.com/a/117...

Re:Problems in C++

[ardor]

In general, the C++ committee eschews the introduction of new keywords unless they really have to. "interface" would be something they'd reject. That said, I do agree that it would reduce the noise, but since C++ has template metaprogramming which uses a form of structural typing, interfaces are not as essential as in, say, Java. In Java a type needs to inherit from the "Comparable" interface to be compatible with sorting functions. In C++ there has to be a less-than operator defined for the type, but it does not have to inherit from anything special (see "C++ generic programming" for details).

Of course, you can write C++ in a more Java-esque way, but you don't have to. That is my main point. And since you don't have to, the committee would rightfully argue that "interface" is not that essential.

Re:Problems in C++

[serviscope_minor]

1. Yes it does. The size is part of the type, so you have to write a type generic function:

template>class C>
void write_array(const C& arr)
{
        for(int i: arr)
                cout >> i >> endl;
}

Also, this is C++, not java. Operator overloading is still a thing and [] works just fine.

Re:Problems in C++

[Anonymous Coward]

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.

Wrong. At() is not the proper methodology. Should you do numerics you would know.

Re:Problems in C++

[snake_case_hoschi]

Thanks!

Re:Problems in C++

[angel'o'sphere]

Reflection does not slow down anything, as long as you don't use it. C++ has RTTI, which already is a small subset of reflection.
Or in other words, programmatically querrying an object for its methods and then calling a specific one based on type of arguments or name is ofc slower than a 'normal call'.
But it costs you nothing to have this option in the language per se.

Re:Problems in C++

[angel'o'sphere]

Java is static compileed, too.
The way how a language is compiled has nothing to do with reflection support.
Also claiming that 1k extra memory for the class meta data is a burden must be a joke.
With thousand classes this is just a mega byte.
And obviously: we talk about C++, if we had reflection and did not want it, we would just switch it off, as we do with RTTI, exceptions and any other thing we do not want.
Everyone who never had used reflection has any idea how powerfull it is.
E.g. by inspecting business objects with reflection you could build up GUIs at runtime without any manual written GUI code.
Simple design patterns or argument parsing for programms or simple forms of the interpreter pattern can easy be done in a few lines of code using reflection.
Everyone who never has used X is always wondering why anyone would want X ... so is your position towards reflection.

Re:Problems in C++

[angel'o'sphere]

pointer per object pointing to the class metadata like for RTTI. That pointer you have anyway, it is the ptr to the vtab. And RTTI is accessed via that vtab, in the same way can be any other meta data.
Also you forget: libraries used for dynamic linking already include all the meta informat, method names etc. they only lack a proper 'standard' API to interpret that meta data.
And that 'knowledge' in those libraries is kept in memory anway, which makes your '1k meta data per class is already to much argument' mood.

Re:Problems in C++

[linuxrocks123]

Only classes that use virtual inheritance have a vtab. Your proposal would add a vtab to everything.

Dynamic linking information is not kept in memory. The dynamic loader reads the dynamic loading information from the ELF headers and throws it away when it's done with it.

Re:Problems in C++

[david_thornley]

In most cases, it's not a matter of extra data. It's a matter of not being able to predict what the program can do, which makes it harder for the programmer to reason about. I suspect it would also interfere with optimizations.

RTTI is somewhat different from what is usually considered to be reflection. It's a way of finding exactly what class a given variable or value instantiates, not a way of finding anything else about the class. Classes in C++ with virtual functions have a hidden pointer to the vtable (this isn't in the standard, but I don't know a compiler that doesn't do it this way), and the value of that pointer is sufficient to determine the type.

Re:Problems in C++

[angel'o'sphere]

That is wrong.
Every class that uses a virtual method has a vtab (and in nearly every scenario where you use inheritance, you should have a virtual destructor).
Virtual inheritance is a a trick to avoid the so called 'diamond problem' if you happen to inherit via different pathes from the smae base class. However it is not the solution :)

Re:Problems in C++

[david_thornley]

1. The [] operator can skip bounds-checking, just like C-type arrays. (The .at() member function requires bounds checking, but operator[]() doesn't forbid it.) std::vector was designed to have C-type arrays with additional functionality and safety. If you want bounds-checking, it's easy enough to have a myvector template that fixes that, or use .at() when you need it.

Stroustrup pointed out that, given a fast version of something, it's possible to make a slower version that does error checking, but if all you've got is the slower version that does error checking you can't make the fast version. Since there's no reason not to use the fast version when you can prove errors won't happen (and don't forget to put the necessary assert() statements in), C++ provides the fast version.

2. strtok() is a destructive function and hard to use properly. It's the work of a few minutes to write something in C++ that works a lot better. And why are you saying you have to use string.h (or cstring) for atoi()? That's in stdlib.h (or cstdlib). C string handling sucks worse than C++'s, and I've never seen praise for std::string that amounts to more than "it's usable and standard".

Re:Problems in C++

[linuxrocks123]

Slight misuse of terminology on my part, I meant "classes with virtual methods". That's still a far cry from every class.

I see no problems with using (real) virtual inheritance to solve the diamond problem.

Re:Problems in C++

[gerddie]

STL arrays and vectors are obviously better, at the cost of decreased code readibility. Square bracket accesses are easier to read than .at()s everywhere.

What's wrong with the vector [] access operator?

Re:Problems in C++

[angel'o'sphere]

The first problem is: there is no diamond problem. Everything works as designed. Using virtual inheritance means you have to walk back in old sources and find the first inheritance to the same class and make the virtual, too.
So: no real solution, as such sources usually are not under your control.
And in cases where you indeed want to inherit several times, without using 'virtual' you still have no option to 'access' the 'parts' you intentionally inherited multiple times.

The solution would be so simple:
class Derived : Base A, Base B {} and now you could write Derived::A and Derived::B to access the 'parts' if you needed to. No idea why the designers of C++ are against this solution.

So in our days the internet is full with advices not to use MI in C++, however there are plenty and elegant uses for it.

E.g. you know you have certain objects which you want to hold ALWAYS in at least two linked lists.

An easy way to do that is to have a LinkededList template that has as template argument an integer or an enum.

Now you let inherit your class twice from that List with two different arguments (constants like 'parent=0' and 'siblings=1'). Now every object has a linked list going up to the parent and one covering its siblings 'build in'.

I did not invent that 'idiom', Jiri Soukoup did.

Anyway, in combinations with templates MI is a killer feature. I'm really pissed that Java/C# has neither templates (and no, generics are something completely different) nor MI, just because some idiots spread the mantra "MI is bad" in the early 1990s ...

Re:Problems in C++

[GuB-42]

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.

And how can the compiler consistently know the size of C-style arrays ?
In C, an array is just a pointer to a block of memory and while the lack of size information can cause buffer overflows, it also makes them much more powerful for high performance or system programming.
For example you can allocate several arrays at once with a single malloc() or new[] call. The array can also be located on a device rather than in RAM (useful for kernel level programming). Also, when the size can be known from elsewhere, why waste memory storing it ?
If you don't need low level control, just use STL vectors.

BTW, when performance is important, wasting memory is very bad. Don't be fooled by the gigabytes of RAM modern computers have. RAM is slow, and you only have a few kB of really fast memory (L1 cache) for both code and data.

Re:Problems in C++

[boristhespider]

All totally true. I'd still like it to be there -- or some other way of enforcing the existence of a virtual destructor baked into the language rather than hand-rolled -- but they're not going to introduce it.

Re:Problems in C++

[linuxrocks123]

Eh, sometimes you want two copies of the but often you don't. And your example seems like it would be much better served by containment than multiple inheritance.

I'm all for MI, though. Java and C# have spent the past two decades adding MI back in. Have a look at Java's "default interface implementations" for a laugh sometime.

Re:Problems in C++

[brantondaveperson]

I must say, you're being very polite to a rather belligerent AC...

Anyway, I have a nitpick:

dlopen() is C++'s reflection system.

Not quite. dlopen is Linux (Unix? POSIX? Not sure...) reflection system, and OMG I hate it :) I remember reading the source code to some Linux commandline utility, and being completely unable to figure out how a particular function was being called until I found the dlopen() call...

Re:Problems in C++

[brantondaveperson]

The [] operator skips bounds checking, which is the main reason for using these classes in the first place.

Stopped reading here. What nonsense. std::vector doesn't bounds check in any meaningful way in release code, and asserts in every possible way in debug code. The [] operator is overloaded by std::vector, and most assuredly does bounds-checking, and more besides. This is one of the reasons that stl is so slow in debug builds.

Re:Problems in C++

[ShakaUVM]

>1) No, that's not the case. The difference between .at and operator[] is that .at() has a const overload and operator[] is not.

Are you sure about that?

http://www.cplusplus.com/refer...

>2) Most high performance apps (eg. games) turn off bounds checking in any case for performance reasons.

Which is fine.

Personally, I'd have preferred it if I could simply enable or disable bounds checking on [], so I could test my code to make sure I'm not going to fry memory, and then disable bounds checking on performance critical code for release.

>Uh, stringstreams? http://stackoverflow.com/quest...

I'm not saying that you can't write your own functions, just that the STL string class is not a drop-in replacement in functionality in string.h

Re:Problems in C++

[devent]

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:Problems in C++

[devent]

I never understood the distinction between "release" and "debug" code. It's sure wonderful if on your own development machine with the few test cases you get meaningful error codes, but on the client's computer your program just crash. I'm sure the client will appreciate how fast your program crash with "release" code, only to not have the possibility to give you a meaningful error code to fix it.

It Sure Is An Underrated Language

[Anonymous Coward]

In fact it is 25% better than C.

:D

[wcrowe]

Perhaps they should call it :D. At least it would seem more friendly.

Re::D

[Anonymous Coward]

> 2015
> wanting the D
> not demonizing it as a symbol of maleness.
I seriously hope you gURLs don't do that.

Re::D

[Anonymous Coward]

That would contrast with :C

Re::D

[Sudline]

It is obvious the discussion here is at higher level than on Nim forum.

Yes D only lost out to...

[Anonymous Coward]

... many others, including OpenEdge ABL, Swift and not to mention SAS - the latter being billed by Wikipedia as "a graphical point-and-click user interface for non-technical users."

The D horse is dead. Really. Stop flogging it.

I can accept there's a shattered dream here. We all wanted D to be the language C++ was not (20 years ago) but it's just not turned out that way. That's life. Get over it. Beautiful or flawed - it's resigned to the history books.

Re:Yes D only lost out to...

[Anonymous Coward]

C is dead...

Pascal, not D, is Underrated

[Anonymous Coward]

While some programming languages achieved early success only to fall by the wayside (e.g., Delphi)

It seems more like both Object Pascal and Pascal are underrated. Object Pascal and Pascal each rank higher than D on the TIOBE index individually and combined they rank 10th (1.507%).

It's a shame more people don't use Object Pascal. I find it to be quite elegant, particularly with the recent language additions in the latest Delphi compilers. I still haven't seen anything beat Delphi for RAD development.

Re:Pascal, not D, is Underrated

[Anonymous Coward]

combined they rank 10th

Typo. They rank 11th.

If I were a big name researcher

[david.emery]

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

[dentin]

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:Why D isn't more popular

[phantomfive]

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.

Re:Why D isn't more popular

[rdnetto]

D works quite well with C-based interfaces - you just annotate the function definitions and link against the binaries. (C++ support is a bit more incomplete.)
That said, at 264 kLOC, I don't think you're going to be switching to any new languages, except maybe newer revisions of C/C++.
New languages are only ever feasible for new systems, rewrites, or loosely coupled modules of existing systems. Anything else just causes more headaches than its worth.

Re:Why D isn't more popular

[Anonymous Coward]

Sometimes one doesn't need to make the full gamble - all or nothing. One can make small bets that will not be a disaster if they don't pay off.

You can definitely talk to your C code directly from D. Use dstep to generate bindings semi-automatically from your header files. The C++ interface is not perfect, but you can do quite a lot via extern(C++) - actually more than is currently described in the documentation, and this is a priority for language development. There is an experimental project called Calypso that creates perfect interoperability with C++ using clang/LLVM.

Also, you can write code in D and call it from C, C++, or even Python.

So it might make sense to pick a small self-contained project or module and give it a spin to see how you like it.

One can't know what a language is like except by actually writing in it - same as sex: the theory is all very well, but...

Delphi is excellent... apk

[Anonymous Coward]

What platform CAN'T you target with it? Pretty much everything/anything http://www.embarcadero.com/pro... - & you're right on inline assembly (which from Delphi XE3 onward, you have that option again as you did in say, Delphi 2-7).

Circa 1997-1998, what took me from C/C++ & VB (my "then favorites")? Delphi! Sure - I did a lot of C++ or VB (even Access) projects, but nothing touched Delphi to get C++ (heck, better, proof's below) power & speed + abilities (except for multiple inheritance model)... & to build it as fast/easy as VB too?? You couldn't TOUCH that combination!

What else convinced me? A test resultset from (of all places) "VBPJ" (Visual Basic Programmer's Journal) issue Sept./Oct. 1997 "Inside the VB5 Compiler"...

There, I saw Borland Delphi LITERALLY "knock-the-chocolate" outta MS' offerings, overall, in performance...

Specifics below (the most important, overall? Again - imo @ least - What they ALL do - math & strings!):

---

  STRING SUITE:

  Delphi = .275ms
MSVC++ = .500ms
MSVB = 4.091ms

---

  MATH SUITE:

  Delphi = 1.523ms
MSVC++ = 2.890ms
MSVB = 7.071ms

* AGAIN - note what I said above? Even while I was a HUGE fan of MS' Visual Studio?? I couldn't "argue with the numbers" here, & gravitated towards a BETTER coding environs in Delphi, by far, for performance alone!

---

  API GRAPHICS METHODS SUITE:

  Delphi = .269ms
MSVC++ = .293ms
MSVB = 292

---

  TEXTBOX FORM LOADING SUITE:

MSVC++ = .012ms
  Delphi = .069ms
MSVB = .072ms

---

  ACTIVE X FORM LOADS:

MSVB = .114ms
  Delphi = .495ms
MSVC++ = .778ms

---

  NATIVE TO LANGUAGE GRAPHICS METHODS SUITE:

MSVC++ = .293ms
MSVB = .455ms
  Delphi = .503ms

---

In the 6 tests given, Delphi won the majority (overwhelmingly in fact, in what ALL PROGRAMS DO, math & strings work)...

* "Argue with the numbers..."

(I couldn't... & switched to it as my primary personal favorite development tool, & haven't switched since!)
APK

P.S.=> Between being able to target *ANY* major player hardware platform there is, AND speed + abilities that either rival OR EXCEED those of MSVC++? Hey - can you blame me for liking Delphi & Object Pascal, the best?? apk

Re:Delphi is excellent... apk

[Anonymous Coward]

What platform CAN'T you target with it? Pretty much everything/anything http://www.embarcadero.com/pro... - & you're right on inline assembly (which from Delphi XE3 onward, you have that option again as you did in say, Delphi 2-7).

Circa 1997-1998, what took me from C/C++ & VB (my "then favorites")? Delphi! Sure - I did a lot of C++ or VB (even Access) projects, but nothing touched Delphi to get C++ (heck, better, proof's below) power & speed + abilities (except for multiple inheritance model)... & to build it as fast/easy as VB too?? You couldn't TOUCH that combination!

What else convinced me? A test resultset from (of all places) "VBPJ" (Visual Basic Programmer's Journal) issue Sept./Oct. 1997 "Inside the VB5 Compiler"...

There, I saw Borland Delphi LITERALLY "knock-the-chocolate" outta MS' offerings, overall, in performance...

Specifics below (the most important, overall? Again - imo @ least - What they ALL do - math & strings!):

---

STRING SUITE:

Delphi = .275ms MSVC++ = .500ms MSVB = 4.091ms

---

MATH SUITE:

Delphi = 1.523ms MSVC++ = 2.890ms MSVB = 7.071ms

* AGAIN - note what I said above? Even while I was a HUGE fan of MS' Visual Studio?? I couldn't "argue with the numbers" here, & gravitated towards a BETTER coding environs in Delphi, by far, for performance alone!

---

API GRAPHICS METHODS SUITE:

Delphi = .269ms MSVC++ = .293ms MSVB = 292

---

TEXTBOX FORM LOADING SUITE:

MSVC++ = .012ms Delphi = .069ms MSVB = .072ms

---

ACTIVE X FORM LOADS:

MSVB = .114ms Delphi = .495ms MSVC++ = .778ms

---

NATIVE TO LANGUAGE GRAPHICS METHODS SUITE:

MSVC++ = .293ms MSVB = .455ms Delphi = .503ms

---

In the 6 tests given, Delphi won the majority (overwhelmingly in fact, in what ALL PROGRAMS DO, math & strings work)...

* "Argue with the numbers..."

(I couldn't... & switched to it as my primary personal favorite development tool, & haven't switched since!) APK

P.S.=> Between being able to target *ANY* major player hardware platform there is, AND speed + abilities that either rival OR EXCEED those of MSVC++? Hey - can you blame me for liking Delphi & Object Pascal, the best?? apk

Wait a minute... APK. Not trolling. You've... you've actually posted something that's not entirely a waste of space!?

...

I need a drink.

Re:Delphi is excellent... apk

[DocHoncho]

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:Delphi is excellent... apk

[Anonymous Coward]

... says DocHoncho the "ne'er-do-well" done zero of worth troll...

Re:Delphi is excellent... apk

[Anonymous Coward]

... says the off topic ac "ne'er-do-well" done zero of worth troll...

c++11 does it in

[Anonymous Coward]

'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:c++11 does it in

[DuckDodgers]

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 still think legacy code and legacy expertise are the biggest obstacles, and they are formidable.

Re:c++11 does it in

[disambiguated]

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 amazing. In fact, C++ is innovating faster than D is.

Re:c++11 does it in

[DuckDodgers]

I'm ten years rusty with C++, and I wasn't a very good C++ developer back when I used it professionally. If I was starting something new in C++ from scratch (not building on older C++ code), are there any specific resources you recommend - books, websites, etc... - to point me to the newest idiomatic way to get things done?

Re:c++11 does it in

[Anonymous Coward]

Scott Meyers is writing an updated book for C++11/C++14 which is quite good

Re:c++11 does it in

[disambiguated]

These just came out, so I haven't read them, but you can't go wrong with these authors:
A Tour of C++ by Bjarne Stroustrup (the original creator of C++)
Effective Modern C++ by Scott Meyers

Dr Dobbs journal is always good.
Microsoft's Channel 9 has a lot of good talks like these and these.
The ISO C++ committee has a great website.

Re:c++11 does it in

[DuckDodgers]

Thank you! I'll give some of them a look.

It's rated D

[Anonymous Coward]

C++ seems better, but still mediocre. I guess I'll stick with the one and only A Programming Language

Re:It's rated D

[__aaltlg1547]

Why isn't Mindfuck more widely used? And what about Whitespace?

Re:It's rated D

[Anonymous Coward]

Those languages have largely been superseded by Malbolge. You want to see beautiful code, just look at the 99 bottles of beer implementation in Malbolge. That's truly a work of art. And it's secure, very secure. So secure, in fact, that you have to be a cryptoanalyst just to write code that even compiles.

Re:It's rated D

[Anonymous Coward]

Why isn't Mindfuck more widely used? And what about Whitespace?

I think the official name is brainfuck.

Re:It's rated D

[Anonymous Coward]

Why isn't Mindfuck more widely used?

Because it doesn't exist.
Brainfuck, on the other hand, was in the news recently as it was used in code-evolving project.

Just so long as

[Anonymous Coward]

The D language creator creator Walter Bright doesn't start manufacturing blue meth with a former student or referring to himself as "Heisenberg" I think I am ok with this.

Mod Parent "Edgy"

[Anonymous Coward]

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.

Nah

[Anonymous Coward]

I don't think so. The author of the language failed the very first requirement of creating a new programming language, which is to give it a unique name. You can't call languages, C, D, or R any more. You just can't. You need to demonstrate that you give a shit.

But people keep doing it. We will soon have multiple languages named after the same single alphabetical character. Any language named after a single letter must therefore be ignored......

Re:Nah

[__aaltlg1547]

C++. C#?

Re:Nah

[DuckDodgers]

Walter Bright named the language Mars, and then the community kept calling it D. After a few years he gave up and started calling it 'D' himself.

Basic things make all the difference.

[Cafe Alpha]

If D had garbage collectors as advanced and scalable as Java then it would be appropriate for even the largest projects.

It doesn't.

No one (except maybe .net) has caught up with Java on having a scalable garbage collector. Java's isn't perfect, but it's tunable too.

Similarly, java makes multithreaded/multiprocessor programming much safer than almost anything else. You can mess with objects in globally visible variables from multiple threads perfectly safely in Java. With or without garbage collection, that's very hard to do from C++11, I have no idea about D here...

So until other projects catch up on these sorts of basics people will stick to the engines that do the basics well. Having a great language is convenient, but it's not as important as having one with the needed capabilities.

Re:Basic things make all the difference.

[Cafe Alpha]

Also what I mean by "You can mess with objects in globally visible variables from multiple threads perfectly safely in Java." is from the point of view of the garbage collector.

For instance, in C++11, even with safe pointers you can can't safely modify a pointer from more than one thread, reachable objects can be collected - THAT kind of unsafe. And despite all of the "don't do that sort of dangerous thing" hysteria that goes around, the fact is that highly optimized multiprocessor algorithms have to do "unsafe things" under the covers.

No one has come up with a library that lets you do that sort of thing in C++11.

Re:Basic things make all the difference.

[Anonymous Coward]

Highly optimized multiprocessor algorithms don't typically run in a garbage collected environment. That's because CPUs and MMUs just aren't advanced enough to permit languages to optimize these things behind the scenes without explicitly syntax or APIs. And they likely never will be--things like transactional memory, even if implemented entirely in hardware, are just too expensive to provide universally. (Contrast virtual memory, which is also quite expensive but still practical.)

Furthermore, the best thing you can do for any multiprocessor algorithm is avoid and minimize contention, period.

The guarantees that Java provides come with a significant cost that is trivially and naturally avoided in C++ and C and the patterns you use in those languages. E.g. if you don't need atomic load/stores or memory barriers, you don't have to pay the cost. In Java these things are always guaranteed to some extent by the language, and cannot be easily nor entirely optimized away given the significant non-determinism inherent in preemptive multi-threading.

And the awesome thing is that you can even use C or C++ implementations from Java, or just about any other language. Whereas using Java from a C program is not practical, because the JVM is doing a ridiculous amount of work under the hood.

Re:Basic things make all the difference.

[Shados]

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 subtleties often get lost by the peanut gallery.

Re:Basic things make all the difference.

[Cafe Alpha]

My impression is that Java is GOOD ENOUGH that people use it for this, when other systems won't do. Yes, you can always program in assembly and OS driver levels and extreme stuff for best possible.

Re:Basic things make all the difference.

[Cafe Alpha]

And by Java I mean the JVM not java itself.

Re:Basic things make all the difference.

[Anonymous Coward]

or GCJ...

chris lukehart

Re:It get's a D

[Anonymous Coward]

http://www.google.com/imgres?imgurl=https://sitevalley.com/blog/wp-content/uploads/2011/06/ram.jpg&imgrefurl=https://sitevalley.com/blog/how-much-ram-do-i-need-on-my-vps/&h=296&w=450&tbnid=-JhdzjPTS23c6M:&zoom=1&docid=wSLVqI6Br3o0cM&ei=M_K-VM2sMsSnyATHqIL4AQ&tbm=isch&ved=0CEAQMygNMA0

Being an excellent language isn't enough

[swilly]

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 entrenched, and it will take a lot more than being a better language to significantly displace them), and finally there is the coolness factor. Coolness relies on many things, but the one that I think is most important is having a charismatic creator or evangelist.

Now D is making significant improvements in each of these areas, so I expect it to continue to grow in market share. In particular, LLVM support and having Andrei Alexandrescu as an evangelist are pretty huge. It still has a ways to go before it can catch up to C++, however.

D has problems, and not just a few

[Anonymous Coward]

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

Re:D has problems, and not just a few

[eluusive]

As an active member of the D community, I agree with what you're saying. Some of it is an issue of manpower though. I've seen these things start to change recently as more people have come onboard.

Re: D has problems, and not just a few

[master_p]

Amen brother.

I was saying almost exactly what you just said but no one listens. Almost everyone thinks D is better than C++. In reality, D is far worse than C++, with twice the inconsistencies and gotchas.

What C++ needs to really make D obsolete is: a) concepts, b) modules, c) put all of C's unsafe operators inside unsafe blocks. Then it will really shine.

Re:D has problems, and not just a few

[rdnetto]

- Huge portions of the standard library are missing attributes like 'pure' and 'nothrow', which directly impacts user code that attempts to include them

Could you explain why adding pure/nothrow is considered a breaking change? I would have thought it only increases the contexts from which the function could be called.

Re:D has problems, and not just a few

[Anonymous Coward]

You're quite correct. I don't believe that would be considered a breaking change. It remains a largely unfixed issue, however, and I included it because it was such a prominent source of frustration for me (and no doubt many others) when I was trying to design my solution.

Re:D has problems, and not just a few

[Anonymous Coward]

That's really good to hear. D has so much potential, so hopefully things continue to improve for it.

Re:D has problems, and not just a few

[Anonymous Coward]

It's a question of perspective as to what matters to you, and what you are prepared to put up with as being part of the imperfection of life. Certainly if you have found another language that offers what D does without its imperfections then you should use that - but I would certainly like to know what that is. Horses for courses...

Bright is an engineer with an appreciation for beauty. That means saying no is a key part of retaining what makes D D, and not C++. His mindset is very different from that of the corporate manager, and so you shouldn't expect him to respond to social pressure in the way that most other people would. Sociomantic asked for breaking changes, but given they haven't yet fully migrated to D2, that is easy for them to say. I am not sure who else you consider a 'major player' has asked for breaking changes, but I hope you would appreciate that the fact that someone is a 'major player' doesn't mean it is the right thing to do to bow to their requests. Quite often, people have less of an understanding of what really matters to them then you might think - and they are also not focused on the broader consequences over time of such decisions. Note that D has been criticized in the course of a few posts for making too many breaking changes (D2 vs D1) and too few.

Attributes vs keywords - an infelicity. But does it really get in the way of being productive? I haven't found that to be the case. You figure it out quite quickly.

If you want to use the standard library without GC, you could compile it with -nogc which will tell you which functions depend on garbage collection. It's really quite small and readable, so it's not hard to take a quick look and see. And with time one will know what you can use and not. But I do think the fuss over GC is somewhat overblown for most users. If writing hard realtime - kernel or game code - maybe. People who write hard realtime stuff (sociomantic too) just allocate buffers at the beginning and use those. It's not so much work to do it that way, particularly given the nice CTFE and templating features. A little work to set up once and get used to, and then it gets much easier.

You're right - the documentation needs to be improved, and people are working on it with renewed focus. Which functions and modules do you think need to be better documented?

The pull request situation is not perfect. Perhaps growing pains accompanying the development of D. Again, people have been trying to work on a better solution, and no doubt it will improve over time. I don't think it's right to say that people maintaining their own patched version leads to fragmentation - hackers do hacker things - because in each case you have just one person with their own version, and not a whole competing community. Actually, I think it's very positive that people engage in 'experiments in living' - that's how you know what works and what doesn't, because people of their own accord take the initiative to try things.

This may come as a strange idea to you, but a language - even a computer language - is somewhat an organic phenomenon that has its own existence. Nobody designed C++ with the idea that templates would be able to do what we have figured out how to do with them now - this was a possibility intrinsic within the language, and it emerged through creative human discovery. Similarly with D, the language "doesn't know what it wants to be" because new possibilities are still emerging.

This is only a problem where there is a lack of coherence and organizing principles and you have a mishmash - not one thing, not another rather than just versatility. If you feel like this is the case, I would love to know what it is that you think is fundamentally incoherent within the language.

I think we lack the vocabulary to describe languages clearly given all the development that has taken place. It is no longer clear what a systems language means exactly. Certainly you can embed assembler in your source code, and do whatever you want wit

Re:Agreed, 110% + why (with proofs)... apk

[Anonymous Coward]

YOU want to read THIS

Well, not really. It's a bit of a rant. You'd make a more convincing argument with better, calmer style.

Little blue flowers

[solanum]

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.

On the downside

[kkruecke]

From the same article: "On the downside, I searched for D programming jobs and found just a couple". I like D but you can't get work doing it.

NO

[russotto]

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.

What about TECO?!

[darkdoc]

Talk about underrated! Without TECO there would be no Emacs, and without Emacs, lisp wouldn't even be on that list.

Bah

[Anonymous Coward]

I had thought to add my opinion to this discussion, as I have some 12+ years now. But no, it took half an hour and >30 attempts to post just this: fuck Beta.

D is a regression

[RoLi]

D may be "nicer" in some niche-aspects, but they destroy all that by dropping the preprocessor. Yes, I know that the snobists don't like it and think it's "outdated". Yet the preprocessor offers something that no other language feature offers: Because the preprocessor "creates" the C-code, you can do *everything* with it.

For example:

#ifdef UNTESTED_FEATURE
        #include "crazy_new_untested_code.c"
#endif

You know what?

If you unset UNTESTED_FEATURE, the program will still compile and work just fine, no matter what crazy things the new guy who was hired to program "crazy_new_untested_code.c" does. He still can check in his work, testers can try it out by setting UNTESTED_FEATURE, etc.

This is the reason why we keep using C after all these years. It's the only (major?) language with preprocessor.

Re:D is a regression

[disambiguated]

You don't need a preprocessor to have conditionally compiled code. C# supports your use-case (producing different code depending on symbols being defined) without a preprocessor, and many other languages do too. C++ has basically eliminated the need for every use of the preprocessor except #include with inline functions, constexpr functions, const variable declarations or template functions. The preprocessor is the worst thing about C++, but getting rid of it would be the mother of all breaking changes. The module proposal would eliminate #include, at least for new code.

The preprocessor makes code harder to understand, very hard to parse, and makes things like refactoring tools, static analysis tools, etc. much harder than they should be. There are damn good reasons why no language since C/C++ has reinvented the preprocessor: it sucks.

If you really need a code generator, use a code generator. The preprocessor isn't well suited for that either.

Re:D is a regression

[Anonymous Coward]

For example: #ifdef UNTESTED_FEATURE

D supports conditional compilation. And has features to accomplish any other sane use of the preprocessor, but in a cleaner way as first class language constructs.

Because the preprocessor "creates" the C-code, you can do *everything* with it.

Yeah, but should you? That's basically writing code in a feature-poor unstructured string manipulation meta-language.

Re:D is a regression

[RoLi]

You don't need a preprocessor to have conditionally compiled code.

Yes, you do.

Because programmers make mistakes and "crazy_new_untested_code.c" may include everything from normal software bugs to syntax errors.

A preprocessor is the only way to ignore syntax errors.

C# supports your use-case (producing different code depending on symbols being defined)

Don't lie. The use case was:

the program will still compile and work just fine, no matter what crazy things the new guy who was hired to program "crazy_new_untested_code.c" does.

If the guy checks in some syntax error in C#, it will no longer compile. End of story.

With a preprocessor you can be absolutely SURE that some disabled code does not influence your program. And if the programmer only has write access to "crazy_new_untested_code.c" he does not even have a theoretical possibility of breaking it.

I have not seen any supposed "replacements" of preprocessors that can do that. These "replacements" are full of unrealistic assumptions straight from the ivory tower. (for example your assumption that all code that is checked in is syntactically correct)

The preprocessor makes code harder to understand, very hard to parse, and makes things like refactoring tools, static analysis tools, etc. much harder than they should be.

Preprocessor-code is much easier to understand than C++ templates. (Yes, I admit it - I have once looked at these template programming and I have long since forgotten about C++ templates) In fact the basic #ifdef structure is straightforward.

Another use-case:

typedef struct {
one int;
#ifdef GREATFEATURE
two int;
#endif
} mystructure;

In that case mystructure will be just as big as actually needed. Can you easily provide the same functionality with C++ templates? Probably not, you probably have to check some book and forum to come up with the code - if it's possible at all, which I'm not sure.

And that is the reason why C is still king for embedded software.

Re:D is a regression

[RoLi]

D supports conditional compilation [dlang.org]. And has features to accomplish any other sane use of the preprocessor, but in a cleaner way as first class language constructs.

As I explained to the other guy, it does not help against syntax errors. It does not allow for strict separation of features.

Yeah, but should you? That's basically writing code in a feature-poor unstructured string manipulation meta-language.

I certainly agree that the C-preprocessor is a poor language. But the problem lies in the lack of features of the preprocessor, not the fact that it is a preprocessor.

So yes, it is a poor language - but that is still better than no preprocessor at all.

Re:D is a regression

[ardor]

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 instead of a preprocessor macro, do so. A good example is a templated min() function vs. a MIN() macro. Another one are awful sins like "#define DWORD unsigned long" . Oh, and include guards? Unfortunately a necessary evil, because #include is a relic from the past, and we have no modern, proper replacement (something like packages, modules, units in other languages). And no, #include + include guards are not "good enough". Hacks like the pimpl idiom are necessary because of the stupidity of #include. I hope the C++ committee gets modules done in the next C++ standard revision. Then *finally*, I can say goodbye to C++ headers.

Your example with the untested feature can be solved by isolating the crazy untested code in its own module, and simply *not enabling that module in the build scripts*. Not by filling code with #ifdefs.

WebKit unfortunately uses #ifdefs in its code, even in its headers. Example: https://github.com/WebKit/webk... and it is a horrible design approach. It completely violates the open/closed principle, and as a result, integrating a new graphics API or toolkit is not as straightfoward as it could be.

Of course the preprocessor can sometimes be useful, but it is not as much of a killer feature as you make it to be. In C it needs to be used much more often than in C++.

Re:D is a regression

[RoLi]

You only offer emotional arguments ("a blight", "relic from the past", etc.).

Yes, the preprocessor does not work at the same level as the compiler - and that is the good thing about it because it gives you leverage about what the compiler sees and it allows you to guarantee that the logic outside the #ifdefs is untouched by any changes - therefore you get much higher quality/stability.

Your example with the untested feature can be solved by isolating the crazy untested code in its own module, and simply *not enabling that module in the build scripts*.

So you have to have modules for every tiny feature?

And all that bloat and overhead just to satisfy your emotional sense of aesthetics?

So to avoid 2 lines of "ugly" code (#ifdef / #endif) you need to create a module, adapt the build-system, etc. etc.?

And we have not even gone into some "advanced" stuff like

#if defined(TEST_1) && defined(TEST_2)

So easy to do with the preprocessor - how do you do that with modules? Create a third module that contains just the code that is needed when both other modules are included? And hide everything in the build-system so that nobody can find and/or debug it?

And again, why all that overhead when all you get is a program that is slower, uses more RAM and (yes!) is much more difficult to understand and debug?

Ideally, the buld-system should not contain any logic. All the logic should be in the source-code.

And of course your "aesthetics before function" - approach may be acceptable on the PC where all that bloat does not matter much. But it is a absolute no-go in embedded-systems programming. Just two years ago I have worked in a project where we had only 128 KB (yes, that is kilobytes) of RAM. And we had to frequently cut the bloat to stay under that limit.

In that situation you forget about "modules", object-orientation and all that other buzz-words from the ivory-tower pretty fast.

So what do you do when you have a new revision of a circuit board that has a different pin-layout?

Do you throw away everything (several man-months of programming and testing) and create a sophisticated module-system that will create numerous other problems and limitations to satisfy aesthetics?

No: You use the preprocessor to add the new stuff while still avoiding any change for the old, so the old stuff can still be used and tested and (more importantly) you can compare the old with the new.

Re:D is a regression

[RoLi]

Another point:

The preprocessor-haters always only offer theoretical arguments ("it supports conditional compilation!") but they never post real code.

Why?

Very simple:

First, even they have a hard time to learn C++ templates and all the other highly complicated replacements.

Second, even when you know about it, using templates is pretty hard actual work. You don't do that kind of work for a posting in a discussion-forum.

Third, when you do the work and compare all that highly sophisticated template-code with the preprocessor-stuff it is supposed to replace, you will realize that just using the preprocessor is so much easier that it is almost comical.

Re:D is a regression

[disambiguated]

A preprocessor is the only way to ignore syntax errors.

Here's how to break your compile even when UNTESTED_FEATURE is undefined:

/* crazy_new_untested_code.c */
#endif /* now what? */
...

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 need a preprocessor for that. I was going to show how to do that in C++ with partial specialization, but it's obvious you don't care and nothing is going to convince you that the preprocessor is evil :)

That's fine, you can keep it.

Re:D is a regression

[david_thornley]

Why do you care about crazy_new_untested_code.c compiling? You simply don't check it in (except maybe to a feature branch) until it compiles. It's really not that big a deal. If it does compile, it can't screw anything up unless executed. If you've got people breaking the build like that, you need to do something about it. (We've got a stuffed bunny that goes to the last person to break the build.) Hiding crap behind a preprocessor doesn't buy you much, and forcing people to only check in code that compiles is hardly an imposition at all.

Your struct sucks. No code can use the second int without an #ifdef, which means #ifdefs all over the place. This means that it's harder to test the code, and in particular it takes extra scaffolding to automatically test (most automatic tests I've seen start with the compiled code and don't recompile). I've worked with code that had lots of #ifdefs, and it really, really sucked when we had to use different combinations.

Your struct also isn't functionality. It's an artificial construct with a made-up backstory. In a reasonably long time on Stack Overflow, I've noticed that questions of the form "how do I use X to do Y?" are almost always bad, and need to be recast as "I want to do Z, tried to do X, but it didn't do Y". If you were to give us a real example, we could see if it can be handled better without the preprocessor (and I'd guess it could).

The reasons C is excellent for embedded are things like easy access to the machine level, ability to do without OS support in freestanding mode, and simplicity. The preprocessor has nothing to do with it.

Re:D is a regression

[david_thornley]

If you have any reason to use "#if defined(TEST_1)&&DEFINED(TEST_2)", you've got at least four configurations that have to be individually compiled and tested. That way lies combinatorial madness.

Re:D is a regression

[ardor]

You only offer emotional arguments ("a blight", "relic from the past", etc.).

Yes, the preprocessor does not work at the same level as the compiler - and that is the good thing about it because it gives you leverage about what the compiler sees and it allows you to guarantee that the logic outside the #ifdefs is untouched by any changes - therefore you get much higher quality/stability.

Did you just say logic? Have you ever written complex sets of code with the preprocessor? A heap of nested macros? This thing scales very badly, and is not even turing complete. C++ templates also scale badly, that's a given (complex metacode is a horror, just like complex macros calling other macros), but they have knowledge about typing information and semantics of the language. By that I mean things like namespaces. Template metaprograms also run in a different realm (at compile-time, and not at run-time), so where does that leave the preprocessor?

In case you missed it: I said that in C, the preprocessor needs to be used a lot more often. I do not argue against that (I know it firsthand from writing C code for embedded hardware). I do argue that *in C++*, the preprocessor does not have to be used nearly as often. There is *zero* reason for a MIN() macro when you can have a templated min() function, for example.

Your example with the untested feature can be solved by isolating the crazy untested code in its own module, and simply *not enabling that module in the build scripts*.

So you have to have modules for every tiny feature?

And all that bloat and overhead just to satisfy your emotional sense of aesthetics?

So to avoid 2 lines of "ugly" code (#ifdef / #endif) you need to create a module, adapt the build-system, etc. etc.?

And we have not even gone into some "advanced" stuff like

#if defined(TEST_1) && defined(TEST_2)

So easy to do with the preprocessor - how do you do that with modules? Create a third module that contains just the code that is needed when both other modules are included? And hide everything in the build-system so that nobody can find and/or debug it?

And again, why all that overhead when all you get is a program that is slower, uses more RAM and (yes!) is much more difficult to understand and debug?

Ideally, the buld-system should not contain any logic. All the logic should be in the source-code.

And of course your "aesthetics before function" - approach may be acceptable on the PC where all that bloat does not matter much. But it is a absolute no-go in embedded-systems programming. Just two years ago I have worked in a project where we had only 128 KB (yes, that is kilobytes) of RAM. And we had to frequently cut the bloat to stay under that limit.

In that situation you forget about "modules", object-orientation and all that other buzz-words from the ivory-tower pretty fast.

If you seriously believe that modularization and object oriented programming are stuff that has no practical usage, then you obviously do not know much about them. Here's a hint: these things are incredibly useful and can even be applied to tiny platforms like stuff that you program with Keil compilers. Yes, things with 32K SRAM or less, no full standard C library (usually hardly any library at all), no heap, etc. I have worked on these. I have applied modularization and object orientation to them. No, it wasn't bloated. No, object oriented programming does not imply huge amounts of registries, virtual function tables, or deep class hierarchies. It is all about having a proper architecture where separate concerns are handled by separate modules. Not one big piece of magical code doing it all, in a messy, convoluted way. The fact that you call such essential concepts "aesthetics" and "ivory tower stuff" speaks volumes.

And I obviously do not advocate imperative logic in the build scripts. It is trivial to see that I mean different configurations for different feature se

Empire!

[Anonymous Coward]

No one else seemed to mention D's Walter Bright is the *same* Walter Bright who wrote EMPIRE, a game Microprose rejected, and them... ahem... payed tribute to as CIVILIZATION. You can get EMPIRE - various versions - free at Bright's web site: http://www.classicempire.com/

D is underrated

[FithisUX]

it is definitely better than c++ for my use cases, but it needs a Boost port. However as with C/Freebasic/C++ it should offer a better type system I cannot understand why void print(MyObject obj){ writeln(obj.myStringRepresntation); } does not make the compiler complaint that MyObjeect should be marked as const in the signature Of course type inference should have a way to see that writeln is const (the define it) Even if writeln is unsafe, the user could put an annotation on the signature @trust void writeln(const T){ //asm code } and one could infer that print should mark MyObject as const. D is a good language, but it needs more love.

Opinion

[Anonymous Coward]

If I want to be unproductive I would use C++. The community is souring. I think it is normal though. It's time has come and is gone..

Maybe there's a future with D but I have no reason to try it...

Does Slashdot prefer articles with a questionmark?

[allo]

not enough sources -> put a questionmark after the headline.

Why D isn't more popular

[Anonymous Coward]

D is binary compatible with C and it is possible to use C/C++ code and D code in the same application without marshaling. You should be able to have modules written in C/C++ and modules written in D in the same application.

If you are really interested take a look at this application https://github.com/TurkeyMan/fuji

Re:Agreed, 110% + why (with proofs)... apk

[Anonymous Coward]

You're off topic & obviously the downmodder of apk's post since you post ac now.

Agreed, 110% + why (with proofs)... apk

[Anonymous Coward]

YOU want to read THIS http://developers.slashdot.org...

* It's ALL undeniable concrete & verfiable fact...

APK

P.S.=> I used Delphi to create this latest program of mine (as I do for any freeware/shareware I've created since 1997):

APK Hosts File Engine 9.0++ SR-1 32/64-Bit:

http://start64.com/index.php?o...

It gives you more speed, security, reliability, & even anonymity (to a lesser extent on the latter) than *ANY* single solution out there, bar-none, for less resources consumed using something you already have natively vs. "bolting on more" to do the same (heck, less usually, by far): Details of what it does for you are in the link above...

Enjoy: It's 100% free, & & the BEST in the security antimalware & antispyware business currently http://www.av-test.org/en/news... per that VERY recent test's results also host & RECOMMEND my program for hosts -> http://hosts-file.net/?s=Downl... ... apk

Re:Agreed, 110% + why (with proofs)... apk

[Anonymous Coward]

YOU want to read THIS

I can only say again that I don't have much use for posts that read like rants or as advertisements for "APK Hosts File Engine", in which I am both disinterested and uninterested.

How about

[Anonymous Coward]

Exceptions considered harmful. I mean after all they are PC branches without being able to see where execution will end up

Go

[Ottibus]

D [] is a lot closer to "C++11 with simpler syntax" than Go.

Another plus point for Go

Re:Go

[Anonymous Coward]

I agree the syntax has become unpleasant (*ahem*), but I'm curious what it is about C++ that you don't like that doesn't come down to syntax?

Re:Agreed, 110% + why (with proofs)... apk

[Anonymous Coward]

Link used wasn't apk's program. It's about Delphi (learn to read) http://developers.slashdot.org... His post you replied to only pointed out a program later that he created using Delphi.

durrrr...uh huh.....durrrrrrr

[Anonymous Coward]

"...you had to CALL or PERFORM different code in another statement, returning the answer in a variable."

uh you just described a function, genius.