July 23, 2009
Walter Bright wrote:
> It's no surprise that most people who fix up those old cars also upgrade the systems with modern technology.

I was just over in one of the restoration forums, where they're talking about a company that makes exact reproductions of original wiring harnesses. Turns out they aren't exact reproductions, they're using much higher quality wire that is more resistant to heat.
July 23, 2009
On Thu, Jul 23, 2009 at 2:23 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
> Lutger wrote:
>>
>> Jarrett Billingsley wrote:
>>
>>> On Thu, Jul 23, 2009 at 1:59 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>>>>
>>>> Michel Fortin wrote:
>>>>>
>>>>> If I'm not mistaken, both your D1 and D2 installer install at the same
>>>>> location and they will overwrite each other. I'd much prefer if D2 and
>>>>> D1 could coexist without having to go with a special installer or
>>>>> custom
>>>>> installation instructions. Otherwise it'll be hard for me to offer the
>>>>> choice between D1 and D2 in Xcode (and I certainly do want that choice
>>>>> to be available).
>>>>>
>>>>> Thoughts?
>>>>
>>>> I've been switching the directories to {dmd, dmd2} so they can coexist.
>>>
>>> Will you rename the DMD2 compiler to 'dmd2' as well?
>>
>> That would be very convenient, please consider this.
>>
>
> I think moving forward D2 will be the norm, so I suggest going with dmd1 and dmd dir names and dmd1 and dmd binary names.

Yeah, let me know when that happens.  Until then, I'd like to continue to be able to use my build tools that were designed for D1 without having to modify all their config files.
July 23, 2009
Jarrett Billingsley, el 23 de julio a las 14:06 me escribiste:
> On Thu, Jul 23, 2009 at 1:20 PM, Steven Schveighoffer<schveiguy@yahoo.com> wrote:
> 
> >
> > However, when I realized that with a custom allocator, I could tremendously increase performance, I had to switch to structs.
> 
> Um, did you?  Because you can have custom allocators for classes too..

And that reason only seems to be a complain with the GC performance, not with the struct/class separation ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Que barbaridad, este país se va cada ves más pa' tras, más pa' tras...
	-- Sidharta Kiwi
July 23, 2009
Ary Borenszweig Wrote:

> Andrei Alexandrescu wrote:
> > Ary Borenszweig wrote:
> >> Unfortunately the designers of D doesn't care at all about IDE support for their language, even though in any "why don't you use D" discussion it is mentioned.
> > 
> > The problem is not not caring. For one, I'd love a D IDE as much as the next guy, but I don't have the resources to put into writing one. IDEs come with language acceptance and are seldom written by the creator of the language.
> 
> I'm not talking about writing an IDE. I'm talking about when thinking of a feature, think how this could be supported in an IDE.
> 
> For instance properties seem to be a fundamental thing in Delphi and C#. When you are debugging and you watch some varaible, the debugger automatically allows you to expand a node and see the varaible's properties. You can't do that with D because any function that has zero parameters could be a property, even though some functions aren't properties.

While working on QtD I have also come up with the conclusion that D needs proper properties. Qt itself greatly relies on properties and it makes a lot of cool things possible. Of course C++ doesn't support them, it is done via Qt metatype system. When D goes popular, IDEs will severely lack this functionality from the language.
July 23, 2009
Andrei Alexandrescu wrote:

> Lutger wrote:
>> Jarrett Billingsley wrote:
>> 
>>> On Thu, Jul 23, 2009 at 1:59 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>>>> Michel Fortin wrote:
>>>>> If I'm not mistaken, both your D1 and D2 installer install at the same location and they will overwrite each other. I'd much prefer if D2 and D1 could coexist without having to go with a special installer or custom installation instructions. Otherwise it'll be hard for me to offer the choice between D1 and D2 in Xcode (and I certainly do want that choice to be available).
>>>>>
>>>>> Thoughts?
>>>> I've been switching the directories to {dmd, dmd2} so they can coexist.
>>> Will you rename the DMD2 compiler to 'dmd2' as well?
>> 
>> That would be very convenient, please consider this.
>> 
> 
> I think moving forward D2 will be the norm, so I suggest going with dmd1 and dmd dir names and dmd1 and dmd binary names.
> 
> 
> Andrei

Also fine, as long as they are different to ease more complex setups, plus it will make it much more convenient to create linux packages for this.

July 23, 2009
Michiel Helvensteijn wrote:
> Aren't immutable and enum the same thing? At least to the programmer?

Not at all. How would you declare a type that is "pointer to immutable int" using an enum? Anyhow, there was a looong thread about this a year back or so.

>>> * Contract programming (no contract inheritance, no compile-time static
>>> analysis, no loop invariants / ranking functions)
>> True, but compile-time static analysis is a "quality of implementation"
>> issue.
> 
> Only when you're talking about optimization. There is great value in
> automatic proof of correctness. But I know this is a tall order.
> 
>> Furthermore, I know of no language other than Eiffel that has all this, and nobody uses Eiffel.
> 
> That's a spurious argument. The reason people don't use Eiffel is not its
> advanced contract programming features. (It may be the syntax.)

It may indeed be the syntax, but consider that no other language adopted those constructs. There was a proposal to add contracts to C++0x which died. I added them to Digital Mars C++ and nobody cared.


> Plus, you ignored the other points. Contract inheritance, loop invariants,
> ranking functions.

Contracts didn't hit paydirt, and so haven't gotten a lot of follow-on attention. Eiffel has contract inheritance, I think it has loop invariants, and I never heard of ranking functions.


>>> * Class/Struct properties (no control over their use by class designer,
>>> no way to use +=, -=, no global properties, no parameterized properties)
>> I don't understand what this means.
> 
> Properties. Your syntactic sugar:
> 
> int i = c.p; // int i = c.p()
> p = i // c.p(i)
> 
> They can't do these things:
> 
> * No control over their use by class designer: ANY member function with one
> or zero parameters may be called using 'property syntax'. This is not a
> good thing.

Why not? Seriously, what is the semantic difference?

> * No way to use +=, -=: I hope this one is clear. The operators that require
> both read and write access won't work on properties.

Agreed that's a problem. Andrei has also been a strong advocate of fixing it.


> * No global properties: If I'm not mistaken, global functions can't be
> properties.

int foo() { return 3; }

void main()
{
    int x = foo;
}

works.


> * No parameterized properties: c.f(5) = 6; // c.f(5, 6)

Ok.


>>> * Operator overloading (no fine control over comparison operators,
>>  > fixed commutativity,
>>
>> This is deliberate. Operator overloading should be restricted to implementing arithmetic like operations on objects, not completely
>> different things like what iostreams, Spirit and Boost::regex do.
> 
> Arithmetic like operations like matrix multiplication (which is not
> commutative)?

I believe this is completely controllable with D.


>>> confusing rule priority to determine translation,
>> The alternative is "Koenig lookup", which I guarantee is far more
>> confusing and has many weird problems.
> 
> Perhaps you misunderstand. I was referring to the algorithm that first
> checks for a complete match, then tries the 'reverse overload', then tries
> the commutative call.

I did understand it. The alternative is Koenig Lookup, and the reason for its existence. Reverse operator overloading is a bit awkward, but the awkwardness is restricted to the class in which it appears. ADL (Koenig Lookup) spreads awkwardness everywhere.


>>> no overloading of !, &&, ||,
>> That's deliberate. For !, I wish to maintain the property of negation of
>> the boolean result, as much of the semantics of transformation depend on
>> it.
> 
> I can perhaps understand this one. Though I'm sure there are programmers
> that'd rather have the ability to overload it.

I'm sure there are, too. That doesn't mean it's a good idea! Features ought to have compelling use cases for them, not just it-would-be-nice-if.


>> For && and ||, they are "short circuit" operators, and how that would sensibly interact with operator overloading I have no idea.
> 
> See my comments above about lazy parameter evaluation. I suggest that those
> operators are defined with a lazy second parameter for bools, and
> programmers should be allowed to overload them for other types as they
> please.
> 
>> I know of no language that allows overloading && and ||.
> 
> C++ does. ! too.

Oops, you're right. Here's an old thread about it: http://www.digitalmars.com/d/archives/digitalmars/D/18153.html

I can't recall ever seeing anyone use it, though. Until there's a compelling use case for it, not just it being a nice idea, I'll stick with my belief it's a bad idea.


>>> * Tuples (no dedicated syntax, no parallel assignment, no non-flattening
>>> tuples without workarounds, no returning tuples)
>> The flattening thing is a problem. The rest can be done with better
>> library support.
> 
> You cannot get a dedicated syntax with library support.

Of course that's true, but why is a dedicated syntax better than Tuple!( ...) ?


> I've mentioned I'm working on a programming language myself. I haven't
> mentioned its name here, because I didn't think it'd be appropriate. But
> with your permission I can post a link to a page describing my tuples.

Sure.


>>> * Unit testing (not at compile time,
>> You can do testing at compile time with static asserts.
> 
> Not unit testing, surely.

You can use static asserts to, at compile time, check the result of any computation, including function calls, that the compiler is able to execute at compile time. It sounds perfectly usable as unit tests to me, and in fact I do use static assert that way.



> Perhaps. But all these available but underpowered features make D look like
> a playground rather than a serious language. It's as if you think of a new
> feature, try it out for a week, then abandon it (I know, I'm exaggerating).

I replied more on unit testing in another response in this thread.


> Yes, but 'pretty clear' does not a spec make. I refer you to our earlier
> divide/modulo discussion.

We're going to fix the modulo thing. But the C++ standard leaves it implementation defined. How is that better?

And how about the C++ source character set and the behavior of "char"? It's a standardized specifying of a mess of implementation defined and undefined behavior.

Sure, the D spec has gaps in it. But the C++ standard also has large gaps of uselessness in it.
July 23, 2009
On Thu, 23 Jul 2009 14:06:12 -0400, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:

> On Thu, Jul 23, 2009 at 1:20 PM, Steven
> Schveighoffer<schveiguy@yahoo.com> wrote:
>
>>
>> However, when I realized that with a custom allocator, I could tremendously
>> increase performance, I had to switch to structs.
>
> Um, did you?  Because you can have custom allocators for classes too..

First, there were other reasons, such as I don't need polymorphism or interfaces for those node types, so switching to structs helped eliminate bloat for those features.

What I did was allocate an array of structs vs. allocating each node, which uses the GC less.  The less you use the GC the better when it comes to performance :)

Can you do that with classes, I don't know.  I thought it was impossible to allocate several classes in one block.  It was pretty easy to do the custom allocator with structs...

-Steve
July 23, 2009
Jarrett Billingsley wrote:
> Will you rename the DMD2 compiler to 'dmd2' as well?

No. If they're in different directory trees, there's no reason to. After all, that's the whole point of having directories!
July 23, 2009
On Thu, Jul 23, 2009 at 12:09 PM, Lutger<lutger.blijdestijn@gmail.com> wrote:
> Andrei Alexandrescu wrote:
>
>> Lutger wrote:
>>> Jarrett Billingsley wrote:
>>>
>>>> On Thu, Jul 23, 2009 at 1:59 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>>>>> Michel Fortin wrote:
>>>>>> If I'm not mistaken, both your D1 and D2 installer install at the same location and they will overwrite each other. I'd much prefer if D2 and D1 could coexist without having to go with a special installer or custom installation instructions. Otherwise it'll be hard for me to offer the choice between D1 and D2 in Xcode (and I certainly do want that choice to be available).
>>>>>>
>>>>>> Thoughts?
>>>>> I've been switching the directories to {dmd, dmd2} so they can coexist.
>>>> Will you rename the DMD2 compiler to 'dmd2' as well?
>>>
>>> That would be very convenient, please consider this.
>>>
>>
>> I think moving forward D2 will be the norm, so I suggest going with dmd1 and dmd dir names and dmd1 and dmd binary names.
>>
>>
>> Andrei
>
> Also fine, as long as they are different to ease more complex setups, plus it will make it much more convenient to create linux packages for this.

Shouldn't the strategy taken be something more akin to what multi-version packages like python and perl already do? They don't just automatically rename old python to be python<OldVersion> after every new version comes out.

On windows they call it python.exe but put it in a different directory.

On versions of linux I think there are some fancy schemes for setting up symlinks to particular versions to be the default.  Can't recall what that system was called.  "Defaults" or something like it. Anyway, seems like on linux dmd should work with that rather than just going and changing the names of exes according to whim.

--bb
July 23, 2009
Jarrett Billingsley wrote:
> Yeah, let me know when that happens.  Until then, I'd like to continue
> to be able to use my build tools that were designed for D1 without
> having to modify all their config files.

I don't know what build tools you're using, but consider make:

------ win32.mak ---------

DMD=\dmd\windows\bin\dmd

target : foo.obj

foo.obj : foo.d
    $(DMD) -c foo
--------------------------

Now, we can drive it with a makefile that customizes the macros like so:

------ makefile ----------

target:
    make -fwin32.mak DMD=\dmd2\windows\bin\dmd
--------------------------


I use this technique a lot. You can also have makefiles recursively call themselves and reset the macros:

---------- makefile --------
DMD=\dmd\windows\bin\dmd

target : foo.obj

target2:
    make target DMD=\dmd2\windows\bin\dmd

foo.obj : foo.d
    $(DMD) -c foo
----------------------------