Sigh, this really ought to be nailed to the nearest church door (like Martin Luther did). Or to the cover of CUJ.

Walter Bright wrote:
> Georg Wrede wrote:
> 
>> Or, could it be that D actually is bigger than C++ _feature_wise_, while C++ is _much_ larger than D when we look at the ramifications of their respective feature sets.
> 
> 
> D *is* bigger feature wise. But complexity wise, C++ beats it. The trouble with C++ is that its features are not very orthogonal - and where they interact/conflict there are a lot of weird special case rules. I have recently exchanged yet another set of emails with a person who is a top C++ expert who insisted that DMC++ had a serious bug with template name lookups. Turns out that DMC++ actually was implementing the name lookup rules *according to the C++ standard* and the other compilers were not. The bottom line is even the experts don't know how it is supposed to work.
> 
> Another example is the preprocessor. It took 10+ years for C/C++ compiler vendors to implement it correctly. This isn't because doing a macro processor is inherently difficult, it is because the specification for C's macro language is so obtuse and full of bizarre special cases. I know I've spent countless hours trying to figure out (1) how it's supposed to work and (2) how to implement it. It's been scrapped and totally reimplemented about 4 times.
> 
> 
>> What I mean is, one could write a "complete" book about D, and it still would be just a fraction of the size of Stroustrup's "C++". And that's because most of his book explains and chews on issues and implications that are unobvious to the reader or programmer, and that demand knowing them lest you shoot yourself in the foot -- and not even later understand what happened.
>>
>> D has virtually no such crap, so we can scrap 500 pages right off the bat.
> 
> 
> Consider just one issue with C++ - how to write a "correct" iterator class. Even harder is writing a "correct" container class.

Kyle Furlong wrote:
> Walter Bright wrote:
>> While I appreciate and enjoy the enthusiasm, this is deja vu all over again. My entire career in compilers (C, C++, D, Javascript, etc.) I've heard people say that "if only you implemented X, it will open the floodgates!" It never does, but what does work is to work with people who are *already* D users who are blocked by the lack of something. With S&S, I'd like to see first how far it can be pushed with existing D techniques.
> 
> This last paragraph is why D will succeed. Walter, if this isn't the best way to evolve a language, I don't know what is.

It's sort of like my relationship with tools. My inclination is to go to Tool Town and buy every tool they have. I want them all; 1" drive socket sets, welders, air tools, etc. The only solution I've found is to only buy a tool if I have an immediate need for it in a project I'm working on.

Georg Wrede wrote:
> Any web developers here? What would _you_ like, wish, need, if you were just starting a web project in D??

The most valuable thing would be a agile, customizable, modern framework for doing serious, large scale web apps. Maybe a low level framework.

I've done some coding with Ruby on Rails lately on smallish projects (<40 db tables, <80 html "pages"). IMO the biggest weaknesses in Ruby are it's speed and lack of compile-time syntax/type checking. I haven't studied these IL-compilers (e.g http://rubyforge.org/projects/cardinal/) a lot - maybe they'll fix the latter issue. However, there's not much point in fighting Ruby on its very own battleground. Even with reflection, high level structures, superb web application libraries a general purpose c-like language cannot provide all the dynamical functionality that Ruby and Rails have. It would also be quite stupid to only stick with Ruby. Complex systems seem to be hybrids consisting of several languages&environments for different purposes.

Currently these lower level systems are made with existing languages that may not be optimal for their purpose. C does not provide much support for complex architectures. C++ has its problems. I think the solution would be to focus on architectural issues in D. Templates and reflection fit nicely here. So do also lazy evaluation, design by contract and D scopes.

One thing I don't understand in D is AFAICT that the abstraction of classes is somewhat broken, namely the use of interfaces. Last time I checked it was quite impossible to implement all GoF design patterns without quirks because you have to cast interfaces to (some unknown) classes before being able to call their public methods. How can a predefined framework know beforehand about classes made by the end user.

> also as a big fan of QT, Id like to request a S&S mechanism; or some sort of messaging pattern in the language. I think this would take D "over the top!"

If I'm not mistaken, given the features already in D, specific S&S functionality would be a job for the standard library, wouldn't it?

Jeff wrote:
>> also as a big fan of QT, Id like to request a S&S mechanism; or some sort of messaging pattern in the language. I think this would take D "over the top!"
> 
> 
> If I'm not mistaken, given the features already in D, specific S&S functionality would be a job for the standard library, wouldn't it?

I agree, it should at least be in phobos.....

Georg Wrede wrote:

> We only have to become the _preferred_ language in _one_ area! After that it'll automatically follow that we gain other areas and a huge general interest. ("If C is good enough for Unix itself, it has to be a good language. -- If D is good enouhg for some of the best games shops, it has to be a good language.")

Two years ago I was struggling with getting reflection and introspection done with C++ for the 3D engine I'm developing and was looking for how other systems are doing it; I also came across the D homepage, but not considered it an alternative yet. However 3 unsuccessfull months later I completely dropped the idea of getting my module system working with C++. Obj-C seemed like a good alternative, though I don't like the mix of Smalltalk with the constraints of plain C. Then I remembered an language called D. Some google and a compiler install later I fell in love with it, though it took me a while to fully understand it's full power.

For example I got a whole bunch of OCaml code, that I used to generate C code with for certain mathematical operations (I got that idea from the FFTW project). But now it seems that D's metaprogramming features, together with the optimization algorithms of modern compilers can do the same whilst keeping it all in the same language.

So I decided to do a hard cut, venturing a huge project conversion, which of course requires me to learn a lot of D, and I'm far finished from grasping all possibilities.

However using D for a game engine also brings a bit development overhead with it. For example my engine has a global virtual file system, memory management, garbage collection etc. i.e. systems that could run in parallel to a language runtime, but it's cleaner to have a unique runtime covering all parts. So I provide my own version of Phobos, stripped down to the minimal required subset of features. The rest is covered by engine specific modules. One might ask, why a propritary runtime environment is neccesary at all; this is a quite complicated topic, among the reasons is, that one might want to deliver binary modules within packages, that are to be unpacked at runtime tepending on the executing environment, aka universal binary. Another reason is, that only a very small codebase is actually plattform dependent, and it makes no sense to recompile the whole stuff for different plattforms. Funny enough the OpenGL API, which by itself is plattform independent, requires different binaries for Windows and the whole rest, which is due to different calling conventions. I was thinking of developing a runtime trampoline code generator, that would load and link the OpenGL stuff upon startup. But since there are also some plattform dependent thing to do prior to initializing OpenGL I would have to plattform dependent compile the OpenGL module anyway.

Apropos plattform dependency. Also here D is great: Just segregate the code with version statements and you're done, no ifdefs and similair hard-to-debug-if-you've-forgot-an-endif stuff.

But there's still a lot of work to be done.

Wolfgang Draxinger

¹some graphic cards can do float/multisample within one buffers others have it mutually exclusive.
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867 GPG key FP: 2FC8 319E C7D7 1ADC 0408 65C6 05F5 A645 1FD3 BD3E

Wolfgang Draxinger wrote:
> So I decided to do a hard cut, venturing a huge project
> conversion, which of course requires me to learn a lot of D, and
> I'm far finished from grasping all possibilities.

None of us has come close to grasping all the possibilities of what can be done with D.

Your project experience sounds very interesting. Do you think you could write a brief article about it? I think as a case history it could be very good.

On Thu, 28 Sep 2006 13:34:15 -0700, Walter Bright <newshound@digitalmars.com> wrote:


>> also as a big fan of QT, Id like to request a S&S mechanism; or some sort of messaging pattern in the language. I think this would take D "over the top!"
>
> While I appreciate and enjoy the enthusiasm, this is deja vu all over again. My entire career in compilers (C, C++, D, Javascript, etc.) I've heard people say that "if only you implemented X, it will open the floodgates!" It never does, but what does work is to work with people who are *already* D users who are blocked by the lack of something. With S&S, I'd like to see first how far it can be pushed with existing D techniques.


I have to agree with this. S&S seems like a great pattern, but I'm worried about the urge to implement the current fads into the language just because they're "so great".  Someday, the excitement may fade when an improvement on the pattern surfaces, and we could be left with a feature in there that takes on a form altogether vestigual.  Of course, this is a risk of many language components, but I think D has to slow down on feature additions for awhile to let alternate solutions aggregate (a stress test of the language of sorts).

Nonetheless, it would certainly be fun to explore syntax alternatives for S&S,  just to see what it would be like.  I suppose if the pattern were generic enough, it could be interesting.

Another note, I've been reading up on S&S, and while its a fascinating pattern (although I dislike the signal/slot naming convention -- it seems to describe the solution unintuitively), I wonder how well it mixes with concurrency patterns.  I mean, we should really be looking at the broader application of it.  It really should have a combined application with concurrency.  That said, I noticed that CSP, which deals with "message-passing" and interprocess communication through "channels" has similarities to S&S, except in the context of concurrency.  Newer experiments in CSP have been exploring the passing of processes/threads/functions in addition to data... while here we are talking about concurrency, S&S appears to be messaging of a similar sort, except that it doesn't describe the threading domain.

Since concurrency is becoming such a hot issue, I really think we have to look at the broader scope of S&S in this context (I believe Qt S&S is said to be thread-safe while the boost alternative is not).  Is anybody here able to share how threading works with S&S?  Is it complicated?  Is in cleanly integrated?  I really think these two ideas should merge together cleanly... perhaps it can be done with a CSP implementation.

-JJR

John Reimer wrote:
> On Thu, 28 Sep 2006 13:34:15 -0700, Walter Bright <newshound@digitalmars.com> wrote:

> S&S seems like a great pattern, but I'm worried about the urge to implement the current fads into the language just because they're "so great".  Someday, the excitement may fade when an improvement on the pattern surfaces, and we could be left with a feature in there that takes on a form altogether vestigual.  

Yes.  For statically checked S&S, templates & mixins seem like they provide basically all that is needed to implement a good solution, (maybe there's still some weak reference business that needs to be sorted out, but it looks like it's mostly there).  The main wart is that you have to have a different template for each number of arguments, resulting in repetitive code.  Some form of Variadic Templates would be very nice to have there.

So instead of
template Signal(T1) // for one argument ...
template Signal(T1, T2) // for two arguments ...
template Signal(T1, T2, T3) // for three arguments ...
template Signal(T1, T2, T3, T4) // for four arguments ...
template Signal(T1, T2, T3, T4, T5) // for five arguments ...
template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
template Signal(etc...

You can just have one template
template Signal(...) // for any number of arguments ...


But something more is needed for Dynamic Qt-like S&S.  Some sort of compile-time introspection seems a minimal requirement.  I think some way to tag particular method like Qt's "slot:" keyword will also be necessary to make it usable.  Anyway you need some way to say "do something with this method" and do it at the point of declaration rather than in the constructor or elsewhere.

If there were a generic decorator mechanism, that would take care of it I think.  'slot' could be a particular user-defined decorator that takes a method and adds that method to a static call-by-name table for the class, all at compile time.  Decorators also make things like Aspect oriented programming, and precondition/postcondition easier.  Can also use them to implement things like "synchronized".  Other uses can be found here: http://www.python.org/dev/peps/pep-0318/

Anyway decorators are a very useful concept I think.  It's kind of like a mixin declared outside a scope rather than inside.  Like a 'mixout'. Mixin's inject some code inside something.  A decorator wraps some code around the outside of something.

--bb

Bill Baxter wrote:
> Yes.  For statically checked S&S, templates & mixins seem like they provide basically all that is needed to implement a good solution, (maybe there's still some weak reference business that needs to be sorted out, but it looks like it's mostly there).  The main wart is that you have to have a different template for each number of arguments, resulting in repetitive code.  Some form of Variadic Templates would be very nice to have there.
> 
> So instead of
> template Signal(T1) // for one argument ...
> template Signal(T1, T2) // for two arguments ...
> template Signal(T1, T2, T3) // for three arguments ...
> template Signal(T1, T2, T3, T4) // for four arguments ...
> template Signal(T1, T2, T3, T4, T5) // for five arguments ...
> template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
> template Signal(etc...
> 
> You can just have one template
> template Signal(...) // for any number of arguments ...

That would be better, but the user doesn't see that code, just the library implementer. So it isn't so bad.

> But something more is needed for Dynamic Qt-like S&S.  Some sort of compile-time introspection seems a minimal requirement.  I think some way to tag particular method like Qt's "slot:" keyword will also be necessary to make it usable.  Anyway you need some way to say "do something with this method" and do it at the point of declaration rather than in the constructor or elsewhere.

I don't understand. Exactly what needs to be done at compile time that can't be done with the mixin method?