Yeah, I partially feel the same way... I'm proud of C/C++, whereas most people I know are afraid of it. I learned to program using C++ and have yet to find a language that I prefer to it, though I consider C# an equivalent...

One thing I especially like about C/C++ is that a lot of people are afraid of it. I know that of my college class there is probably only a couple of people that enjoy C/C++ (most are literally afraid of it). Perhaps of our computer studies class it's only Samuel Henderson and I that embrace it. Another [possibly virtual] benefit of C/C++ is that it takes a more competent programmer to write. A lot of other languages are more forgiving and allow less competent people to work on the project which can only result in poorer code.

One thing that I saw in college is that a lot of people are in IT for money and don't actually give a fuck about the software quality (or system integrity). C/C++ scares them and that [hopefully] means that they'll stay away from "real" projects. I know it's a flawed assumption, but it helps me sleep at night...

One could argue that any language COULD be compiled into machine code.

Yeah, I'm still going to finish my clone of your setup

You can keep your precious C++.

I was never impressed by C++. I never saw the benefits over C to be inticing enough to use it until I found Qt. For what it was lauded for, it just wasn't enough. Not high level enough. Its supposed to be easier than C for pete's sake, and it didn't even do that right

What does C++ offer that higher level languages don't? C++ is somewhat high level itself.

Why does that seem 99.9% likely to be a gross exaggeration. Sure, you may not have been able to do it in the same amount of time... But not at all?

Well, I'll agree that some tools are better suited to certain jobs, the only way you're going to get much higher than 10 times as productive per amount of time probably depends on you not reimplementing lots and lots of features under another language.

I'm sure there's something out there to make it quicker.

I find it incredibly difficult to manipulate and handle binary data.

In any case, there have been times I've wanted to write something in a higher level language and been unable to because it lacks basic functions. Which seems to be caused by certain things being completely covered up for "ease of use" (and under the assumption that you'd never need them directly).

I might just be talking out of my ass(blame the paranoia ), but I'm writing this not actually knowing the reason I said D looked higher level. Maybe it's because it's supposed to be so damn "easy".

D probably isn't that bad, in actuality though. If it's supposed to replace C++, it should allow a route to the bottom of it's functions and allow a person to do whatever they please.

I'm sure the time limit was implied.

Considering D lets you drop into assembler and call any C library function (including malloc() and free()), I don't really think it's lacking any power. If you take a look at D and try it out, I think you'll quickly find yourself wondering why C++ isn't more like it.

Edit: Regarding D vs C#, see this chart. It's since been taken down, which means maybe it was out of date. Also, of course, it's not meant to show the other language's advantages.

I think the biggest differences would stem from D being a compiled language. As such, it gives you lower level access ... but cannot do quite as much run-time magic.

Well, C++ libraries have always been a bitch to deal with: name mangling isn't standardized, so a C++ library from one compiler won't work in another. And I don't mean "may not work"--it really won't work.

Run objdump on a C++ DLL and you will see things like _ZNSi3getEv. That's called name mangling and it translates to std::istream::get(). Each compiler does this differently. Name mangling is what allows the compiler to tell the difference between void foo(int) and void foo().

That is the standard.

Name mangling itself is standard, but the style of the mangling is not. Early C++ compilers just translated code to C and were compiled normally (meaning it had to mangle to valid C symbols), while others didn't bother with that step.

Wikipedia explains it quite well:

Interpreted languages, loose typing... bad idea.

Right now I'm using PHP for it, and it works well. For a typical web site, I'd use it over Perl, Python, or Ruby simply because PHP has native support for running in a web server. (That's its primary purpose.)

Writing a framework with it is still possible, but it's less than ideal. The reason is that it's already an interpreted language. Adding another layer on top of it can really hurt performance. This is why my templates are actually translated to raw PHP code and cached at run time. I don't want to introduce another virtual layer.

While that works well, the rest of the framework still has to be written in PHP. But there's a lot of higher level things I'd like to add that are just impractical to do. (I'd like to add things to the core language.) So what I've considered is writing my own custom language that just gets translated to PHP, similarly to what I do with the templates.

And yes, languages like Python and Ruby are more flexible than PHP, but I'd still have to do the same thing. MVC frameworks already exist that use an existing language as-is (e.g. Rails [Ruby], Django [Python]). They are all good and well, but they require you to learn so much about the framework, to me, you might as well be learning a language/script that was designed from the top down to do what it's doing.

So ideally, I'd write the framework in a language like D and just skip all this translating to another scripting language. Of course that's a large task, and for a long time will probably only be a personal, hobby project of mine.

I don't mind the lack of IDE support. I just use UltraEdit (with a D syntax highlighting file) on Windows, save to my mapped virtual Linux drive, and run make in a Putty terminal. But, like you, I'm just playing around with it at the moment. However, I've seen enough to never use C++ again.