I am a java guy trying to understand D, and I have a couple of questions/comments:

1) Why keep pointers around?  Doesn't the combination of lightweight (stack) objects and heap objects accounts for everything you might want to do with pointers?  Is it to be able to call C functions?

2) I think the C syntax for function pointers is one of the ugliest things that ome from C.  Why allow that syntax for function delegates?

3) What is this .map file I get after compiling something?

4) A nice thing about java is that it allows me to refer to files
using a forward slash (/) instead of a backward slash (/).  This
way my makefiles are completely unchanged from Windows to
Unix (without using an ugly variable to separate directories).
Is this something that is planned for D?

5) I read something about SWT being ported over.  I ported
SWT to use AWT for my company, and would be interested
in contributing.

Cheers,

Andres

> I am a java guy trying to understand D, and I have a couple of questions/comments:
>
> 1) Why keep pointers around?  Doesn't the combination of lightweight (stack) objects and heap objects accounts for everything you might want to do with pointers?  Is it to be able to call C functions?
>
> 2) I think the C syntax for function pointers is one of the ugliest things that ome from C.  Why allow that syntax for function delegates?

The answer to both these questions is that pointers are a very powerful and efficient mechanism, and is one of the reasons that C and C++ remain the foremost general purpose languages, despite having been around for 30 and 20 years, respectively.

The whole idea is that experienced people should have access to whatever level of power they need. This is the Spirit of C (http://www.comeaucomputing.com/faqs/genfaq.html#betterCgeneral)

You can have languages, and, with respect, pretty poor ones at that, such as Java, if you're prepared to constrain the programmer in significant ways. This can lead to all kinds of problems, such as bloat, lack of ability to express one's desires, lack of reuse, lack of robustness, but it most usually manifests itself, as it does with Java, in poor performance.

Essentially software engineering is a craft, and the *only* way to do it
well is to understand the principles, understand the tools (i.e. the
language(s) you are using), and to have experience.

D facilitates this, as does C++, by providing access to the lowest as well as the highest levels of abstraction. Languages such as Java and .NET tend to limit themselves to, say, the 50-75% level of abstraction.

> 3) What is this .map file I get after compiling something?

That's a file describing the symbols contained in your executable file.

> 4) A nice thing about java is that it allows me to refer to files
> using a forward slash (/) instead of a backward slash (/).  This
> way my makefiles are completely unchanged from Windows to
> Unix (without using an ugly variable to separate directories).
> Is this something that is planned for D?

The / vs \ is entirely an artifact of the operating system, and nothing to do with the D and Java languages. If you use Java on Win32, you will be manipulating paths with backslashes.

Some languages/libraries do "compensate" for programmers/users passing the wrong type, for the operating system, to functions, but this behaviour is a deemed an extension, rather than a standard aspect of a given language.


Cheers

Matthew

See answers/more questions below.

> > I am a java guy trying to understand D, and I have a couple of questions/comments:
> >
> > 1) Why keep pointers around?  Doesn't the combination of lightweight (stack) objects and heap objects accounts for everything you might want to do with pointers?  Is it to be able to call C functions?
> >
> > 2) I think the C syntax for function pointers is one of the ugliest things that ome from C.  Why allow that syntax for function delegates?
>
> The answer to both these questions is that pointers are a very powerful
and
> efficient mechanism, and is one of the reasons that C and C++ remain the foremost general purpose languages, despite having been around for 30 and
20
> years, respectively.
>
> The whole idea is that experienced people should have access to whatever level of power they need. This is the Spirit of C (http://www.comeaucomputing.com/faqs/genfaq.html#betterCgeneral)
>
> You can have languages, and, with respect, pretty poor ones at that, such
as
> Java, if you're prepared to constrain the programmer in significant ways. This can lead to all kinds of problems, such as bloat, lack of ability to express one's desires, lack of reuse, lack of robustness, but it most usually manifests itself, as it does with Java, in poor performance.
>
> Essentially software engineering is a craft, and the *only* way to do it
> well is to understand the principles, understand the tools (i.e. the
> language(s) you are using), and to have experience.
>
> D facilitates this, as does C++, by providing access to the lowest as well as the highest levels of abstraction. Languages such as Java and .NET tend to limit themselves to, say, the 50-75% level of abstraction.

I completely agree with you in everything you sais, nevertheless you did not answer my question.  When you explicitly have both stack and heap objects, heap objects basically serve as pointers with a nicer syntax.  I coded in C++ for many years, using very few pointers, and my code was cleaner and more readable.

I have nothing against a complete and general language, but the more
ways you have to write something, the more harder a language is to
read (I code in lisp for my work, and it takes me much longer to understand
other people code, even if writing my own is a joy).  Everything is
a compromise and a language should have reasons for being
whatever it is.  Otherwise, following your line of thought (exaggerating
a bit to make my point :-) just throw every possible feature at D,
and you'll have your ideal language.

> > 4) A nice thing about java is that it allows me to refer to files
> > using a forward slash (/) instead of a backward slash (/).  This
> > way my makefiles are completely unchanged from Windows to
> > Unix (without using an ugly variable to separate directories).
> > Is this something that is planned for D?
>
> The / vs \ is entirely an artifact of the operating system, and nothing to do with the D and Java languages. If you use Java on Win32, you will be manipulating paths with backslashes.
>
> Some languages/libraries do "compensate" for programmers/users passing the wrong type, for the operating system, to functions, but this behaviour is
a
> deemed an extension, rather than a standard aspect of a given language.

Again agreed, forgive my lack of precision.  I rephrase my question: "Is the *extension* above planned?  It's specifically useful for the compiler more tha the language itself.

Cheers,

Andres

Andres Rodriguez wrote:
> 
> [..]   When you explicitly have both stack and heap
> objects, heap objects basically serve as pointers with a nicer syntax.  I
> coded in C++ for many years, using very few pointers, and my code was
> cleaner and more readable.

You can't do pointer arithmetic with references.  Or convert them to ints, or other such sacrelige. :)

D aims to provide a better way to do most everything C coders use pointers and the like for, but does nothing to prevent their use in the case that a programmer really can't do it any other way without excessive hackery or performance impact.

 -- andy

"Matthew" <matthew.hat@stlsoft.dot.org> schreef:

> The / vs \ is entirely an artifact of the operating system, and nothing to do with the D and Java languages. If you use Java on Win32, you will be manipulating paths with backslashes.

AFAIK DOS & Windows support both "\" and "/" at the API level; only at the command line you have to use "\".

-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

"JanC" <usenet_spam@janc.invalid> wrote in message news:Xns94821A5C079E7JanC@213.119.4.35...
> "Matthew" <matthew.hat@stlsoft.dot.org> schreef:
>
> > The / vs \ is entirely an artifact of the operating system, and nothing to do with the D and Java languages. If you use Java on Win32, you will be manipulating paths with backslashes.
>
> AFAIK DOS & Windows support both "\" and "/" at the API level; only at the command line you have to use "\".

I'd very surprised if this was the case. I'm pretty sure I've been bitten by this by several Win32 APIs.

Haven't programmed to DOS for over five years, so I cannot comment on that.

>
> -- 
> JanC
>
> "Be strict when sending and tolerant when receiving."
> RFC 1958 - Architectural Principles of the Internet - section 3.9

>
>> > 4) A nice thing about java is that it allows me to refer to files
>> > using a forward slash (/) instead of a backward slash (/).  This
>> > way my makefiles are completely unchanged from Windows to
>> > Unix (without using an ugly variable to separate directories).
>> > Is this something that is planned for D?
>>
>> The / vs \ is entirely an artifact of the operating system, and nothing to do with the D and Java languages. If you use Java on Win32, you will be manipulating paths with backslashes.
>>
>> Some languages/libraries do "compensate" for programmers/users passing the wrong type, for the operating system, to functions, but this behaviour is
>a
>> deemed an extension, rather than a standard aspect of a given language.
>
>Again agreed, forgive my lack of precision.  I rephrase my question: "Is the *extension* above planned?  It's specifically useful for the compiler more tha the language itself.
>

It seems to me that that would be better in some kind of front end that you provide for the OS you happen to use. If I compile the D compiler on VMS for others to use would you expect me to alter the code to allow non-VMS file specifications? That would be silly.

Andres Rodriguez wrote:
> I am a java guy trying to understand D, and I have a couple
> of questions/comments:
> 
> 1) Why keep pointers around?  Doesn't the combination of
> lightweight (stack) objects and heap objects accounts for
> everything you might want to do with pointers?  Is it to be
> able to call C functions?
> 

I think the shortest reasonable answer is that D is a systems language, like C and C++, and unlike Java. One could write an operating system in D, and access hardware directly from within the language. That requires pointers and asm statements, which D has both.

In article <bvhffl$47n$1@digitaldaemon.com>, Andres Rodriguez says...
>
>I am a java guy trying to understand D,
[snip]
>5) I read something about SWT being ported over.  I ported
>SWT to use AWT for my company, and would be interested
>in contributing.

it appears that  Brad Anderson <brad@sankaty.dot.com> ( I think that email needs
a human tweak)
see:
http://www.digitalmars.com/drn-bin/wwwnews?D/22162
for the start of the thread

is kicking this off. An experienced Java guy would be a great asset.

The D community is quite friendly and open.  Welcome.

"Andres Rodriguez" <rodriguez@ai.sri.com> wrote in message news:bvhi7j$92v$1@digitaldaemon.com...
> I completely agree with you in everything you sais, nevertheless you did not answer my question.  When you explicitly have both stack and heap objects, heap objects basically serve as pointers with a nicer syntax.  I coded in C++ for many years, using very few pointers, and my code was cleaner and more readable.

Consider, for example, implementing a garbage collector. Without language support for pointers, a garbage collector could not be implemented in D.

(And yes, ABI compatibility with C is also a reason for supporting
pointers.)

> I have nothing against a complete and general language, but the more ways you have to write something, the more harder a language is to read (I code in lisp for my work, and it takes me much longer to
understand
> other people code, even if writing my own is a joy).  Everything is
> a compromise and a language should have reasons for being
> whatever it is.  Otherwise, following your line of thought (exaggerating
> a bit to make my point :-) just throw every possible feature at D,
> and you'll have your ideal language.

You're right. And D has been criticized (ironically by some C++ experts) as being a grab bag of features, despite my having said no to a very long list of feature requests <g>. The trick is to decide which features to include and which to exclude, based on their cost in terms of language complexity versus their benefit in terms of simplifying things for the user.

> Again agreed, forgive my lack of precision.  I rephrase my question: "Is the *extension* above planned?  It's specifically useful for the compiler more tha the language itself.

I think it already does that.