"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:mailman.131.1248306024.14071.digitalmars-d@puremagic.com...
>
> That's how easy installing DMD is, but this guy, and many others, don't see it that way. I blame this page: http://www.digitalmars.com/d/2.0/dmd-linux.html#installation
>

Really? That surprises me. I consider myself relatively green when it comes to Linux, and I've never once tried to use/install DMD on Linux (yet), or looked at that page before, but for Linux that looks pretty darn easy. Not apt-get easy of course, but even I've dealt with far worse than this. Not that it couldn't or shouldn't be improved, of course, but if someone is complaining that it's *dmd* that's too hard to install on Linux, then it sounds like they're in for a rather rough ride period ;)

On 2009-07-23 05:37:24 -0400, Jacob Carlborg <doob@me.com> said:

> Yes: http://www.dsource.org/projects/dmd-installer
> I'm still waiting for Walter to add the osx installer to the dmd download page.

Speaking of that OS X DMD installer, are you sure installing it at /usr/share/dmd/ is a good idea? Normally /usr/share is reserved for architecture-independent data[1], not executable files. What about /usr/local/dmd with symlinks in /usr/local/bin for executables /usr/local/lib for phobos and druntime and /usr/local/man for man pages. Or perhaps install /Library/D/{dmd,dmd2} so the files are more user accessible and easy to change if you got the zip archive (/usr is a hidden dir on Mac OS X).

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?


[1]: http://www.pathname.com/fhs/2.2/fhs-4.11.html

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Walter Bright wrote:

> immutable - data that cannot change or be changed (imagine it is stored
> in ROM)
> 
> const - read only view of data, you cannot change it but others can
> 
> enum - compile time constant, has no storage
> 
> The only place these overlap is in the declaration of symbolic constants. C++ has all three, but in a way that is context dependent that very few people are aware of.

Aren't immutable and enum the same thing? At least to the programmer?

>> * structs, classes
> 
> structs are value types, classes are reference types. That's a fundamental distinction, not two ways to do the same thing. A lot of confusing problems with C++ code stem from attempting to use a struct (or class!) both ways, or trying to give it characteristics of both.

But in C++ you can put a class object on the stack with value semantics, just as you can put a struct object on the heap. No problem, really. Stack is default. For the heap, all you need is a pointer.

Personally I hate Java style reference semantics (a.k.a. heap without pointers). Especially because they also offer a small set of value types, to confuse matters. Now here's D doing the same thing.

So the solution in D would then be to always use struct? No, because value semantics seems to come at the price of inheritance. Why? C++ seems to handle inheritance in value types just fine.

>> * functions, delegates, lazy parameter evaluation
> 
> Lazy parameter evaluation may turn out to be a bad idea, it doesn't seem to have found its "groove" anywhere. On the other hand, you can just ignore them like everyone else does, like everyone ignores exception specifications in C++.

Actually, lazy parameter evaluation has its purpose. I personally like languages in which there are little or no "special constructs" that only the compiler can provide. In this case, lazy parameter eval could be used to overload your own short-circuiting operator.

> There's some undeniable extra complexity in having both function pointers and delegates. At some level, function pointers must be supported in order to support the C interface. Delegates are just too useful to give up (C++ has had awful problems trying to work around not having them - member function pointers anyone? Boost::bind? no thanks).

I understand why you keep delegates around. I'd just call them function variables and remove the C(++) cruft. But D's goal is to keep some sort of backwards compatibility, so ok.

>> D offers some cool features, but leaves them very underpowered:
>> 
>> * 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.)

Plus, you ignored the other points. Contract inheritance, loop invariants, 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.

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

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

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

>> * 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)?

>> 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.

>> 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.

> 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.

>> * 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.

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.

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

Not unit testing, surely.

>  > not possible to categorize)
> 
> I agree that D's built-in unit testing is basic. But the fact that it exists *at all* is a huge improvement for a programming language. I firmly believe that its mere existence has been a big factor in improving the general quality of D code.

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).

> The fact that you want more from unit testing is great. Unit testing has raised the bar of expectations on a language, and in that it's a home run.

The fact that I want more, but you can't provide it, is a home run? :-)

>> I maintain that D suffers greatly from its lack of a formal specification.
> 
> Perhaps, but remember that most languages don't get formal specs until long after they become popular. Consider that C++ was defined by cfront for the first 10 or 12 years of its existence.

That was then, this is now. In the now, we have a C++ with classes and templates and a very strict standards committee overseeing its specification. You want to know why people in the now choose C++ over D? This is one reason.

>> Not only does the D specification feel really
>> unstable,
> 
> I admit I'm not good at writing language lawyer text. But the D1 spec isn't unstable. The feature set is set, it's pretty clear

Yes, but 'pretty clear' does not a spec make. I refer you to our earlier divide/modulo discussion. You expect programmers that want details to look at the DMD source code?

And when you change a formal specification, people at least know the language changes as a result. When you change the compiler, we don't know if the language has changed or not.

I know that most people can distinguish between a bug and a feature. But when you want to play with the big boys, you need to make it unambiguous.

> Much of D's improvements appear to be small, but the aggregate is large enough that once you write a project in D, you'll find it pretty hard to go back to another language.

I don't dispute that most changes D has made to C++ are good, and that the result is greater than the sum of its parts. And if it weren't for all my other complaints, this one would not be enough to keep me from D.

-- 
Michiel Helvensteijn

Nick Sabalausky wrote:

> Not apt-get easy of course,

Linux Gentoo does have DMD in portage, by the way. apt-get easy. Or, to be more precise, emerge easy.

-- 
Michiel Helvensteijn

Michiel Helvensteijn Wrote:
> Nick Sabalausky wrote:
> 
> > Not apt-get easy of course,
> 
> Linux Gentoo does have DMD in portage, by the way. apt-get easy. Or, to be more precise, emerge easy.

Available versions:  (~)1.016!m!s (~)2.008-r1!m!s

You can use this overlay for the latest versions: http://www.assembla.com/wiki/show/d-overlay We usually update it in one day to one week from dmd release.

Walter Bright wrote:
> http://www.reddit.com/r/programming/comments/93jh5/ask_proggit_the_d_programming_language_looks/ 
> 

Let me start with an example.

Some time ago I need a script to get and process some data.
I trough why not use D, but I couldn't find a function in the standard library which would get a simple web page with http.
Instead of find and downloading other libraries I switched to peal and had it running in no time.


I think it is the choice of problem domain for D.

Successful language are typical the first moves in a new and popular problem domain.

FORTRAN - vector processing.
PHP - server side web programing.
Java - platform independent client side programing.
etc.


If you want people to switch you need provide the tools for solving this  problems.

To get the Fortran crowd D needs faster vector processing.
To get the PHP crowd D needs libraries that support web programming.
To get the java crowd, it should be possible to run platform independent D programs in you browser.
etc.

I know the real focus for D system programing and the C++ people.

I think one of D's strongest points for people to make the switch is build in unit testing. (at least this is the strongest point for me)

But the very simple implementation of unit testing in D nearly ruin the advantage it gives. (see suggestion from the wishlist below)

C++ have a lot of good libraries to solve all type of problems,
for me it wouldn't be a problem if I knew that the D libraries would be a much better quality.

A indicator for this would be if I knew that the library was properly unit tested.

A simple way to ensure that could if the compiler issued a error/warning if a function had no unit tests or contracts.


What follows is some unit test suggestions from http://all-technology.com/eigenpolls/dwishlist
Because I would like to hear your opinion about them.

** unit test & code separation
I think it would be more useful if the code
and the unit test where two separate binaries.

Sometimes you need to move the production binary to another machine/environment.
It would be nice if one could move the test binary with it and test that everything works.

It would also allow for arguments to the test binary,
so that you would be able to run a specific unit test.


** black box unit testing
The d compiler should enforce black box unit tests.

Which is unit tests that only use the classes exposed interface.(public, protected)

Together with 100% unit test coverage it helps ensure that
the code is modular,decoupled and that you can change
the private parts without changing the unit tests.

For those how is not ready for this high code standard,
there might be a --allow-white-box switch.



** Unit test isolation
I would like to be able to isolate the unit test,
so that if one fail the next still runs.


unittest()
{
test("test1")
{
assert(...);
assert(...)
}

test("test1")
{
assert(...);
assert(...)
}

for (i=3;i<10;i++)
{
test("test"~i)
{
assert(...);
assert(...)
}
}
}

** Unit test measurements
In combination with test isolation
it would be nice to have d output
memory and time used in each unit test.



-- 
Join me on
CrowdNews  http://crowdnews.eu/users/addGuide/42/
Facebook   http://www.facebook.com/profile.php?id=1198821880
Linkedin   http://www.linkedin.com/pub/0/117/a54
Mandala    http://www.mandala.dk/view-profile.php4?profileID=7660

Michiel Helvensteijn wrote:
> Walter Bright wrote:
> 
>> immutable - data that cannot change or be changed (imagine it is stored
>> in ROM)
>>
>> const - read only view of data, you cannot change it but others can
>>
>> enum - compile time constant, has no storage
>>
>> The only place these overlap is in the declaration of symbolic
>> constants. C++ has all three, but in a way that is context dependent
>> that very few people are aware of.
> 
> Aren't immutable and enum the same thing? At least to the programmer?

Well you can build an immutable list.

>>> * structs, classes
>> structs are value types, classes are reference types. That's a
>> fundamental distinction, not two ways to do the same thing. A lot of
>> confusing problems with C++ code stem from attempting to use a struct
>> (or class!) both ways, or trying to give it characteristics of both.
> 
> But in C++ you can put a class object on the stack with value semantics,
> just as you can put a struct object on the heap. No problem, really. Stack
> is default. For the heap, all you need is a pointer.
> 
> Personally I hate Java style reference semantics (a.k.a. heap without
> pointers). Especially because they also offer a small set of value types,
> to confuse matters. Now here's D doing the same thing.
> 
> So the solution in D would then be to always use struct? No, because value
> semantics seems to come at the price of inheritance. Why? C++ seems to
> handle inheritance in value types just fine.

I think C++ does not handle inheritance in value types all that well, in fact the way it deals with the collision is pretty gruesome. It's all dark corners and dangers and caveats and puzzling behavior. There's only one place when anyone would seriously want something to be a value and a reference simultaneously, and that's exception classes. And those are tricky. I've never seen any correctly designed exception hierarchy in C++, starting with the standard exceptions. The fact that D requires one more allocation to throw an exception is IMHO a very small compromise.


Andrei

Andrei Alexandrescu wrote:

>> So the solution in D would then be to always use struct? No, because value semantics seems to come at the price of inheritance. Why? C++ seems to handle inheritance in value types just fine.
> 
> I think C++ does not handle inheritance in value types all that well, in fact the way it deals with the collision is pretty gruesome. It's all dark corners and dangers and caveats and puzzling behavior.

Walter said something similar. I'm curious, which collision are you referring to? Which dark corners and dangers and caveats and puzzling behavior?

Can you explain? Or perhaps refer me to a web location that explains?

Thanks.

-- 
Michiel Helvensteijn

Michiel Helvensteijn wrote:
> Andrei Alexandrescu wrote:
> 
>>> So the solution in D would then be to always use struct? No, because
>>> value semantics seems to come at the price of inheritance. Why? C++ seems
>>> to handle inheritance in value types just fine.
>> I think C++ does not handle inheritance in value types all that well, in
>> fact the way it deals with the collision is pretty gruesome. It's all
>> dark corners and dangers and caveats and puzzling behavior.
> 
> Walter said something similar. I'm curious, which collision are you
> referring to? Which dark corners and dangers and caveats and puzzling
> behavior?
> 
> Can you explain? Or perhaps refer me to a web location that explains?
> 
> Thanks.
> 

The issues are discussed in the book C++ Coding Standards and also in More Effective C++. Part of the problem is slicing, which you may want to google for. MEC++ discusses the problem of defining constructors and particularly copy constructors in hierarchies. Assignment and comparison are also problematic.


Andrei

Andrei Alexandrescu wrote:

> The issues are discussed in the book C++ Coding Standards and also in More Effective C++. Part of the problem is slicing, which you may want to google for.

I'm aware of slicing. I didn't really think of it as a problem. But now that you mention it, I suppose it can be confusing. And perhaps violate class invariants.

There may be a solution. What I'm thinking now is that in the background, the heap may be used, as long as this is transparent to the programmer. i.e. assignment still makes a copy, comparison still compares the objects, not the addresses. But a base class value variable still has a superclass object in the background.

This requires some thinking. Thanks for the clarification.

-- 
Michiel Helvensteijn