Thanks Only problem is: I got my macBook and it included a program that basically did what I wanted my program to do. So, by winning the contest I basically ensured that I won't develop PowerComics any further.

--There are no stupid questions, but there are a lot of inquisitive idiots.

---Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.MiquelFire.red | +MeWindows 8 is a toned, stylish, polished professional athlete. But it’s wearing clown makeup, and that creates a serious image problem. ~PCWorld Article

Come to think of it, it's funny how important stylistic choices considering the syntax of a lanuage in fact are to us. I really hate the :: operator in C++, merely on the grounds that it's damn ugly. I like how D replaced the ::, -> and . operators with just a . operator. Nice and neat IMO.

In theory, yes, but the implementation is lacking. At least it works in a consistent way in C. In the current D implementation (the two compilers use the same frontend), you never know when it's going to bite you. And how to get around it is just trial and error, really. But that'll hopefully improve.

Come to think of it, it's funny how important stylistic choices considering the syntax of a lanuage in fact are to us. I really hate the :: operator in C++, merely on the grounds that it's damn ugly. I like how D replaced the ::, -> and . operators with just a . operator. Nice and neat IMO.

Of course you can typedef C++ to get less verbose, but still D is much more elegant. Ultimately (with just about every example) they both do the same conceptual things, but yet I find D more enjoyable.

So yeah, I think you're right that the language's style or amount of "sugar" really has a lot to do with how we enjoy working with it. (Of course that sounds obvious, but I'm speaking more about the subtle differences of typing fewer keys.)

According to this the compiler decides whether a function is inlined or not. But if you speak of inline in the sense that the function is defined within the class, then yes that is the case. Which is awesome.

Call me odd, by I actually like using '->' compared to '.' (forgoing the fact that I also like -> telling me it's dereferencing and getting a member, next to . saying it's getting the member right from the var). The :: "operator" isn't too bad, but I sometimes find myself wishing the compiler was smart enough so that I can use the var itself.. to take matthew's example:

I think that when people use a language so verbose as C++, over time they tend to believe that all of that complexity is needed in order to be efficient (in terms of runtime speed) and non-ambiguous. So when a language like D comes along and challenges the very notion that such complexity offers nothing, it's a bit of a culture shock.

I don't think it's intentional, but it's almost like a superiority complex. C++ has more syntax, so it must be better. I know if it's dereferencing or not. But when it comes down to it, does it really matter? It's kind of like how we naturally get the feeling that the more a pair of shoes costs, the better made it is.

For instance, when dealing with a class (Note that in D, the class is technically different from a struct in many ways):

// C++
MyFoo foo;
foo.bar =1;
MyFoo *foo =new MyFoo();
foo->bar =1;

Why does that distinction even matter when dealing with a class? I understand the technical difference, but as a programmer I don't care. (If I did care, I'd be working with assembly!) D only gives you one way:

True. But by giving someone several ways of declaring visibility the language does help a bit.

Yes, I dislike the "more than one way approach." (This is partly why I don't think offering . and -> for classes is very beneficial.) I would rather there only be one way to declare public or private. Personally, I like to explicitly declare it on each function, but I'd be fine with any single method that was consistent.

In the end, it's the coder's fault for writing bad code. But I agree that the language can make it worse. Just take a look at the crap written in languages like PHP. (I don't mean to imply it's a horrible language; I just use it as an example because I know it the best.) PHP lets you do a lot of things in many ways, using a lot of shortcuts, and it ends up causing nearly every open-source PHP package to be riddled with ridiculous bugs.

Well, if you're working on larger pieces of code you'll have to work with code other people have written. Let's say Joe Coder prefers one way, Jane Coda prefers another way. Both work on the same project, but different parts of it. Sooner or later code from one part of the project will migrate into another part. Normally this happens if Jane is on vacation and a critical bug has been found in one of her modules. Since Joe is under pressure and he isn't familiar with her code, he starts doing things his way. He might add a comment like // TODO: Need to clean up this code which normally means this code won't be touched because everybody is too afraid breaking it. Or maybe it's because the code "works" and working 4h on a piece of code that already works, risking that it won't work exactly the same way as it did before is not in the interest of the company (= not paid for).

Developing a language is like developing an API. You should try to get a slim but complete API.

I'm used to code in C and Java. I know my way around C++ but I never considered it a language that works for me. If I want to code something fun and simple I use C. If I want to code something high level I use Java. Does the trick for me.

D might allow me to use one language for both high level and low level stuff. Only problem for me is that I like to code games using "low level" stuff. I also like Java. Esp. the number of utility APIs I can use.As soon as it gets "high level" the amount of code that you don't need to code yourself becomes more important. So, right now, for me, Java wins the high level race against D and C wins the low level race.But both C and Java have to admit that it was a pretty close thing

--There are no stupid questions, but there are a lot of inquisitive idiots.

Wow, my_like_for_D--. I really don't like that many languages that use dot for everything.

Initially I thought I agreed with Dustin, but thinking about it for a second I think using the dot (.) operator alone is a better syntax rule. That said, I don't mind the -> or :: operators when used in C++ with their individual meanings. However, languages that use -> or :: in place of the dot (.) operator (I get the impression that PHP is one, but I haven't touched PHP in a while and can't remember doing object-oriented programming with it) are silly because the dot (.) operator is much more clean.

But if you speak of inline in the sense that the function is defined within the class, then yes that is the case. Which is awesome.

So they removed the linking feature. Interesting idea... This seems to be the 'modern language' way.

File clutter prevention ranks high on my list, this takes a big chunk out of my favorability for D.

Matt said:

I think that when people use a language so verbose as C++, over time they tend to believe that all of that complexity is needed in order to be efficient (in terms of runtime speed) and non-ambiguous.

A valid point. However, my primary like of having all dereference operators is for reading code. I can read ::blah and know exactly what is meant very quickly.

I am overly harsh on the feature because of subconscious association with the recent trend to 'hide anything similar to a pointer'. I find myself staring at code for long periods of time trying to figure out what they hell kind of crazy reference solution this language decided to come up with.

On another note (which doesn't really effect my personal selection of languages) things like hiding :: and -> increase the number of idiots who can get hired to write horrible code.

But if you speak of inline in the sense that the function is defined within the class, then yes that is the case. Which is awesome.

So they removed the linking feature. Interesting idea... This seems to be the 'modern language' way.

File clutter prevention ranks high on my list, this takes a big chunk out of my favorability for D.

Not sure what you mean by 'removed the linking feature', but D is no different from C when it comes to compiling and linking. The source files act as headers when they are imported by other files. If you need it, you can have the compiler generate pure header files (*.di) from your source code.

And a javadoc-like documentation system is built into the compiler, which means that you'll often get html documentation of the public API by just compiling with the -D argument. It's built in to make it more likely that at least basic docs are available. And it's really easy to use. No excuse for not keeping the source code clean and well organized, of course.