Am Mon, 16 Dec 2013 18:39:13 +0100
schrieb "Francesco Cattoglio" <francesco.cattoglio@gmail.com>:

> On Monday, 16 December 2013 at 17:32:11 UTC, deadalnix wrote:
> > On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright
> >> Good idea. I suggest writing a pull request against the documentation for this.
> >
> > That is a bad idea as it preclude any GC optimization based on immutability.
> 
> What do you mean by this? How can a change in the documentation preclude GC optimization? Does our GC read docs to understand what can be collected? Now I get it: it's a stop the world, then RTFM, then collect GC implementation :)

Think again(, please)! The more restricted the language becomes, the more room for specific optimizations there will be. When the written specs are liberal then some GC optimizations cannot be applied like compaction.

-- 
Marco

On Monday, 16 December 2013 at 18:20:23 UTC, Andrei Alexandrescu wrote:
> Nonsense. Using extralinguistic tools including code generators is not the exclusive appurtenance of C.

Not sure what you mean is nonsense. In general, having to resort to macros and source-generating tools have been seen as a weakness of the semantics of the language. In most dynamic languages you never have to do that (because you can eval()). However, the Unix/C philosophy has always been that of having a conglomerate of smaller programs to build larger systems. It is not a "quick fix", it is in line with the basic philosophy of having many simple tools. Hence it is idiomatic.

When you reach the complexity of C++/D you really should not be required to resort to such techniques. C is a simple language that used to have simple compilers.

> And m4, more powerful and supposedly better, has only spawned more madness.

m4 is quite powerful, but macro-processors are annoying, if that is what you are implying. I've only used m4 to address limitations in more limited languages.

> Current applications also demand good modeling power. The days when one thousand lines was a nontrivial program are behind us. The right solution is a language that combines performance control with the modeling required by large applications.

M… There are two schools of object-orientation: that of object oriented design/modelling and that of object oriented programming. If you don't skip the modelling part you can write OO in most languages. Many programmers skip the modelling part and think that doing OOP is sufficient. It is isn't. OOP is about ADTs. OOD is about the understanding the domain, where you need flexibility in the future etc, the language is not the most important aspect of getting good structure. You can probably do a good job even in PHP (which is a very crappy language) if your analysis of the domain is good.

If you want more modelling power you should look at Beta, Datalog/Prolog etc… D doesn't provide more modelling power than other imperative OO languages. Does it? Are the objects nested like in Beta? Do you have the ability to do virtual inheritance on classes? Do you have the ability to extend virtual functions by calling the sub-class from the superclass (inner-statements rather than outer, so that you can enforce transactional BEGIN/END clauses?)

But that was not my point. My point was that performance on the CPU is going to be less important because it account for only 10% of the total performance. GPUs now do TerraFLOPs. FPGAS are being packaged with CPUs by Zynq, OpenCL will be able to compile to FPGAs. So basically, to get performance the language should support more than just the CPU and that is not easy because of the potential bottlenecks between the subsystems.

On Monday, 16 December 2013 at 19:08:49 UTC, Ola Fosheim Grøstad wrote:
> 10% of the total performance. GPUs now do TerraFLOPs. FPGAS are

Tera… ;)

On Monday, 16 December 2013 at 17:39:14 UTC, Francesco Cattoglio wrote:
> On Monday, 16 December 2013 at 17:32:11 UTC, deadalnix wrote:
>> On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright
>>> Good idea. I suggest writing a pull request against the documentation for this.
>>
>> That is a bad idea as it preclude any GC optimization based on immutability.
>
> What do you mean by this? How can a change in the documentation preclude GC optimization? Does our GC read docs to understand what can be collected? Now I get it: it's a stop the world, then RTFM, then collect GC implementation :)

The GC won't know about you bypassing the type system. It never will. It suddenly that isn't undefined behavior anymore, it become impossible for the GC to take advantage of type qualifier.

I won't continue nitpicking on separate points because it clearly
seems to me we are speaking with completely different
applications in mind. Have you noticed project example I have
described for Manu
(http://forum.dlang.org/post/mznzsfktnzfggckgyeer@forum.dlang.org)?
It does not work with application layer strings (thus not
unicode), does no floating point at all. But lack of forced
inlining or control over emitted symbols would have just killed
it, there is no way anyone would even consider language which
does not provide that, it does not matter how awesome it may be
at higher level of abstraction.

I am not going to argue that D can beat C in user-space domain
because pretty much anything can beat C here. It is not even
worth discussing. Interesting part is world where C is still
completely unrivaled - embedded / barebone. D can _possibly_ beat
C here but is very far from there _right now_ because of missing
basics. Once basics are here, lot of advantages you have
mentioned will really start to matter. Not now.

On 07/12/2013 17:29, Walter Bright wrote:
> On 12/7/2013 1:52 AM, Joseph Rushton Wakeling wrote:
>> On 07/12/13 02:10, Walter Bright wrote:
>>> I know well that people used to C++ will likely do this. However, one can get in
>>> the habit of by default adding "final:" as the first line in a class definition,
>>> and then the compiler will tell you which ones need to be made virtual.
>>
>> The disadvantage of this approach is that, if one forgets to add that "final",
>> it doesn't just produce a performance hit -- it means that it may be impossible
>> to correct without breaking downstream code, because users may have overridden
>> class methods that weren't meant to be virtual.
>
> D doesn't allow overriding non-virtual functions (unlike C++).

How do you _override_ a non-virtual function in C++, as opposed to define an independent function with the same name in a derived class?

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.