Slashdot Mirror
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#.
... 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!
Which has more power: the hammer, or the anvil?
I guess the users of languages don't like readable, simple, or maintainable code.
Confirmation!
Your ad here. Ask me how!
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.
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!
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
I am Slashdot. Are you Slashdot as well?
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!
I'd give it a D+
I live in constant fear of the Coming of the Red Spiders.
... but I still think the rankings here are just about meaningless.
Peace, or Not?
DD should be sufficient.
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/
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é.
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.
I am becoming gerund, destroyer of verbs.
I hate you.
English isn't a particularly nice language. It has one big advantage over other languages though. Can you figure out what it is?
Her cup runneth over.
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)
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Perl went up in the ratings!
There is no God, and Dirac is his prophet.
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.
the growth in cynicism and rebellion has not been without cause
>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.
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.
-1, Too Many Layers Of Abstraction
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?
Perhaps they should call it :D. At least it would seem more friendly.
Proverbs 21:19
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++.
It is pitch black. You are likely to be eaten by a grue.
I'd publish a paper, "C syntax considered harmful" with roughly the same kind of rationale as the "Goto considered harmful" paper.
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.
Alter Aeon Multiclass MUD - http://www.alteraeon.com
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?
“Common sense is not so common.” — Voltaire
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.
“Common sense is not so common.” — Voltaire
Nah, more likely an increase in retirement rate amongst COBOL programmers, requiring fresh blood to maintain the ageing applications.
Yes, but think of the children!
Sent from my ASR33 using ASCII
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
'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.
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.
Pleasant diphthongs?
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
Arbitrary spelling that must be memorized for every word?
Ambiguous syntax?
Homonyms?
Homographs?
Vagueness in general?
SNOBOL.
ok .. go ahead and name one language that isn't about domination and oppression. just one.
Esperanto.
Yaz
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.
"First they came for the slanderers and i said nothing."
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.
"First they came for the slanderers and i said nothing."
Why isn't Mindfuck more widely used? And what about Whitespace?
C++. C#?
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.
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.
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.
C compatibility is the least of C++s problems.
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.
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!!!
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.
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.
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.
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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.
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
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!
Celebrity worship is a poor substitute for Deity worship and costs more to boot.
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.
Code? Useless! Overrated! Real programmers program directly in binary.
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.
Si hoc legere scis nimium eruditionis habes.
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.
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.
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.
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.
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.
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?
Talk about underrated! Without TECO there would be no Emacs, and without Emacs, lisp wouldn't even be on that list.
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.
And by Java I mean the JVM not java itself.
Kial Esperanto uzas malfacilan Polan prononcon?
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Sorry, left out the cxu. So much for mian putron Esperanton.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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.
Most human behaviour can be explained in terms of identity.
That's completely false. The posters on the D Forum are made up of almost complete C and C++ programmers.
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.
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?
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.
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.
I confirm, this comes from Ada Lovelace. But it is not necessary to be rude.
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
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.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
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.
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.
When all you have is a hammer, every problem starts to look like a thumb.
No, it means the GP doesn't know what he's talking about.
When all you have is a hammer, every problem starts to look like a thumb.
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.
... or simply something procedural but higher level, like, for example, Python?
D is a better C++, but not many people need a better C++.
I apologize for the lack of a signature.
Does it also mean that every line run inside an exception block has an C-style assert() test attached to it?
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.
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.
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.
That one is about stomping out all the world's other languages and making us all speak the same. What a loss of culture.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
The first is how every language starts out. The second and third are the same thing and have been the goal since the beginning.
"The use-mention distinction" is not "enforced here."
When Chuck Norris throws an exception, it is always fatal.
If that isn't a hit to performance, nothing is.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
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.
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.
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.
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.
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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).
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
As somebody who has programmed in Python, Common Lisp, Java, and C# (among others), what you wrote isn't true.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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
If you have memory leaks and buffer overflows in C++, consider using C++ facilities like smart pointers and containers.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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.
“Common sense is not so common.” — Voltaire
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.
“Common sense is not so common.” — Voltaire
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.
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.
“Common sense is not so common.” — Voltaire
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.
Languages don't dominate and oppress.
People do that.
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.
Most human behaviour can be explained in terms of identity.
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.
It is pitch black. You are likely to be eaten by a grue.
not enough sources -> put a questionmark after the headline.
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.
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.
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?
When all you have is a hammer, every problem starts to look like a thumb.
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.
When all you have is a hammer, every problem starts to look like a thumb.
That's why the chinese made a proverb for it
When all you have is a hammer, every problem starts to look like a thumb.
Kial Esperanto uzas malfacilan Polan prononcon?
C^ar Zamenhof estis Polan?
Yaz
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
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.
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.
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.
"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.
"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.
Contribute to civilization: ari.aynrand.org/donate
D [] is a lot closer to "C++11 with simpler syntax" than Go.
Another plus point for Go
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.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
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.
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.
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.
When all you have is a hammer, every problem starts to look like a thumb.
So have I. So what. It's still crap.
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.
Ezekiel 23:20
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.
“Common sense is not so common.” — Voltaire
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?
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?
If you actually care, this: http://www.zompist.com/spell.h... provides some slight counter arguments.
He effected a bored affect.