"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ah1b24$1iko$1@digitaldaemon.com...
> Well, you certainly seem to have a lot more experience
> with it than me. I guess I was misinformed. Sorry about
> that. So there really *is* a gap in the market for D. I
> thought of C# as D's biggest competitor, because I
> thought you could straight compile your programs too.

A crucial difference between D and C# is that D is meant to be compiled into machine code. This has a lot of interesting ramifications, from subtleties of the language design to how a resulting app looks. For example, you can build system apps in D. I don't see a way to do that with C#.

"Andrey Tarantsov" <andreyvit@nvkz.kuzbass.net> wrote in message news:aglpvi$qc0$1@digitaldaemon.com...
> > D is designed to be a simple language - easy to write a compiler for and easy to learn.
> This does not mean it would be easy to program with it. Standard Pascal is
a
> very simple language, but it's very hard to write anything useful.

Very true. Pascal is a good language to learn how to write compilers. I can't say it's useful for much else. I am trying to bring my experience to bear on the problem of finding a fairly minimal set of features that cover most of the programming needs.

I remember when Ada first appeared, it was considered unimplementable for years. Eventually, people did figure out how to implement it as compiler technology advanced. C++ also suffered for years being unimplementable. I wish to avoid that fate with D by at least providing source to a reference implementation.

I read your comments with interest. Can I sum them up by saying that you wish for D to be more of a meta-language, such as providing the building blocks for dynamic arrays rather than implementing them directly? That's a valid point of view, and certainly the one C++ takes with STL. So why does D have dynamic arrays built in?

1) They are so darned useful. I use them everywhere in my own code - and find them to be a more than suitable replacement for most singly linked lists, doubly linked lists, stacks, queues, etc. Having to learn only dynamic arrays instead of vectors, lists, stacks, queues, etc., makes programming easier and less buggy.

2) By integrating them into the language, D can achieve tight and nearly seamless integration with static C style arrays - important for interfacing with external C functions.

3) Since the compiler knows about dynamic arrays, sensible and to the point error diagnostics can be issued, rather than the notoriously inscrutable messages coming from metalanguage constructs.

4) Good code can be generated for a builtin construct by a less sophisticated compiler. Constructs built up from meta-primitives usually need a very advanced compiler to generate comparably good code.

5) Designing the syntax into the language enables the use of special syntax where useful, such as the array slicing syntax.

6) In a garbage collected language, dynamic arrays should be a fundamental type, not something built up from metalanguage constructs. Metalanguage constructs are needed for special types, and should not be necessary for basic types.

Sets and ranges were both quite useful.

You can't use ++ and -- on enum variables in C++... can you in D?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ahah9f$m73$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:agjp40$195r$1@digitaldaemon.com...
> > --I wonder what Walter opinion on D looking like pascal more then C++
is?
> > > > Although Walters previous pascal compiler experiance my shine though
> the
> > > cracks.
> > Although Walters previous pascal compiler experiance may shine though
the
> > cracks.
> > > What did you mean?
> > I simply mean (Walter correct me if I'm wrong) is that Walters written a pascal compiler before and elements of that may show in D.
>
> It's true that the first compiler I wrote was for a Pascal subset, way
back
> in 1980 or so. While Pascal is not my favorite language, it does have a
nice
> feature I tried to carry into D - that of being able to separate the lexical, syntactic, and semantic phases of compilation. This is a crucial feature for reducing a complicated language into managable pieces, for
easy
> understanding and implementation.

"Walter" <walter@digitalmars.com> wrote in message news:ahaldu$ptj$1@digitaldaemon.com...
>
> "Andrey Tarantsov" <andreyvit@nvkz.kuzbass.net> wrote in message news:aglpvi$qc0$1@digitaldaemon.com...
> > > D is designed to be a simple language - easy to write a compiler for
and
> > > easy to learn.
> > This does not mean it would be easy to program with it. Standard Pascal
is
> a
> > very simple language, but it's very hard to write anything useful.

No object support, and no means to really control the display.  No decent standard library.  Yeah that makes it hard.  There's also a bunch of practical extensions needed (Borland provided most of these later and became the de-facto standard).

> Very true. Pascal is a good language to learn how to write compilers. I can't say it's useful for much else. I am trying to bring my experience to bear on the problem of finding a fairly minimal set of features that cover most of the programming needs.

This is good, so long as we can extend the language later.  If it will let us write really low level stuff that looks and acts like the things the language provides built-in.

> I remember when Ada first appeared, it was considered unimplementable for years. Eventually, people did figure out how to implement it as compiler technology advanced. C++ also suffered for years being unimplementable. I wish to avoid that fate with D by at least providing source to a reference implementation.
>
> I read your comments with interest. Can I sum them up by saying that you wish for D to be more of a meta-language, such as providing the building blocks for dynamic arrays rather than implementing them directly? That's a valid point of view, and certainly the one C++ takes with STL. So why does
D
> have dynamic arrays built in?
>
> 1) They are so darned useful. I use them everywhere in my own code - and find them to be a more than suitable replacement for most singly linked lists, doubly linked lists, stacks, queues, etc. Having to learn only dynamic arrays instead of vectors, lists, stacks, queues, etc., makes programming easier and less buggy.

But the performance characteristics of dynamic arrays don't match those of lists.  Yeah, you *can* build any container type out of some other container type, but the fundamental containers (vector, list) have vastly different performance characteristics and can't easily emulate one another without being very inefficient.

Lists are for fast arbitrary insertion and removal and linear traversal. Arrays are for fast random access or linear traversal and are easier to copy since the whole thing can be copied as a contiguous block.  Insertion at the end isn't too bad but can cause reallocations, insertion or removal at the beginning are very slow.

> 2) By integrating them into the language, D can achieve tight and nearly seamless integration with static C style arrays - important for
interfacing
> with external C functions.

This is nice.

> 3) Since the compiler knows about dynamic arrays, sensible and to the
point
> error diagnostics can be issued, rather than the notoriously inscrutable messages coming from metalanguage constructs.

Heh.  Good point.  ;)

> 4) Good code can be generated for a builtin construct by a less sophisticated compiler. Constructs built up from meta-primitives usually need a very advanced compiler to generate comparably good code.

Agreed.

> 5) Designing the syntax into the language enables the use of special
syntax
> where useful, such as the array slicing syntax.

Yes.

> 6) In a garbage collected language, dynamic arrays should be a fundamental type, not something built up from metalanguage constructs. Metalanguage constructs are needed for special types, and should not be necessary for basic types.

Agreed, the most basic of basic types should be part of the language. They're so basic that everyone will have to implement them anyway or that they'll need to be part of the standard library.

I think we should take another look at the possibility of adding linked lists directly to the language and formalizing the concept of iterator as a basic language feature.  Can this be done?  If so, how?

I'm going to split this off into a new thread.

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ahci0h$47g$1@digitaldaemon.com...
> Sets and ranges were both quite useful.



> You can't use ++ and -- on enum variables in C++... can you in D?

You know, I never thought of that. What do you think?

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ahcipd$4tg$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:ahaldu$ptj$1@digitaldaemon.com...
> >So why does D
> > have dynamic arrays built in?
> >
> > 1) They are so darned useful. I use them everywhere in my own code - and find them to be a more than suitable replacement for most singly linked lists, doubly linked lists, stacks, queues, etc. Having to learn only dynamic arrays instead of vectors, lists, stacks, queues, etc., makes programming easier and less buggy.
> But the performance characteristics of dynamic arrays don't match those of lists.  Yeah, you *can* build any container type out of some other
container
> type, but the fundamental containers (vector, list) have vastly different performance characteristics and can't easily emulate one another without being very inefficient.

Yes, they are very different for long lists and long arrays. 99% of the time, however, I find that I have just a handful of members, and the performance difference just doesn't come up on the radar screen.


> I think we should take another look at the possibility of adding linked lists directly to the language and formalizing the concept of iterator as
a
> basic language feature.  Can this be done?  If so, how?
>
> I'm going to split this off into a new thread.

Ok, see ya there.

"Walter" <walter@digitalmars.com> wrote in message news:ahahse$mn4$1@digitaldaemon.com...
>
> A crucial difference between D and C# is that D is meant to be compiled
into
> machine code. This has a lot of interesting ramifications, from subtleties of the language design to how a resulting app looks. For example, you can build system apps in D. I don't see a way to do that with C#.

"system apps". I'm thinking device drivers. Could anyone provide me with
other examples?
Are there aspects of D other than it's ability to do inline assembly that
lends D to systems programming?
Apologies - I don't know much about systems programming. Why is it that
device drivers need to be written in assembler?

-- Regards, Steve.

"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahcv9a$hhg$1@digitaldaemon.com...
> "system apps". I'm thinking device drivers. Could anyone provide me with other examples?

Most of the operating system can be called a "system app". System apps include compilers, editors, utilities, networking infrastructure code, the Java VM, the .net VM, etc.

> Are there aspects of D other than it's ability to do inline assembly that lends D to systems programming?

Yes:
1) it can be compiled to machine code and stored as an executable binary
2) it doesn't require an abstraction layer or virtual machine between it and
the actual hardware
3) it can interface directly to the raw operating system entry points
4) type checking, semantic analysis, etc., is done at compile time, not run
time, so the executable code runs at maximal speed with minimal overhead
5) the semantics of the language are flexible enough to conform to the
actual peculiarities of real CPUs, so no costly and slow emulations are
necessary

> Apologies - I don't know much about systems programming. Why is it that device drivers need to be written in assembler?

They don't always need to be written in assembler - but frequently there are special instructions that need to be executed, I/O ports that need accessing, interrupt handlers that need hooking, etc., and those usually get done with a bit of assembler. Inline assembler can also get you out of a hole when the compiler is not generating good enough code for a particular performance bottleneck.

"Walter" <walter@digitalmars.com> wrote in message news:ahd42a$lt8$1@digitaldaemon.com...
>
> "Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahcv9a$hhg$1@digitaldaemon.com...
> > "system apps". I'm thinking device drivers. Could anyone provide me with other examples?
>
> Most of the operating system can be called a "system app". System apps include compilers, editors, utilities, networking infrastructure code, the Java VM, the .net VM, etc.

Just to clarify: .net doesn't have a VM. It's just got a runtime. Microsoft
calls it CLR for .net
and CLI in the ecma spec Common Language Runtime (or Infrastructure I
think).

I get what you mean. Modula-3 was a language, too that was design
to be used for systems programming but still had modules, class-based
objects and gc.

> > Are there aspects of D other than it's ability to do inline assembly
that
> > lends D to systems programming?
>
> Yes:
> 1) it can be compiled to machine code and stored as an executable binary

For some embedded work this is probably mandatory. I get the feeling,
though, that
many system apps do not require this feature. Though it doesn't hurt to have
it.
I just don't like to see too much Java and C# bashing here on the D
newsgroup.
You can write compilers, editors, jvm's in Java (can't say I know *how* they
did it), so
I'm sure that it would be pretty hard to come up with a task that just flat
can't be done.

> 2) it doesn't require an abstraction layer or virtual machine between it
and
> the actual hardware

Does this mean that D doesn't have a runtime?
Or more likely that you can optionally leave out the runtime at link time?

> 3) it can interface directly to the raw operating system entry points

Is this the C  interoperability at work?

> 4) type checking, semantic analysis, etc., is done at compile time, not
run
> time, so the executable code runs at maximal speed with minimal overhead

I also get the feeling from other posts that the D implementation uses whole program optimisation techniques to decide when methods need not be dynamically dispatched. yes?

> 5) the semantics of the language are flexible enough to conform to the actual peculiarities of real CPUs, so no costly and slow emulations are necessary

Understood. More like C (than Java) in this respect.

> > Apologies - I don't know much about systems programming. Why is it that device drivers need to be written in assembler?
>
> They don't always need to be written in assembler - but frequently there
are
> special instructions that need to be executed, I/O ports that need accessing, interrupt handlers that need hooking, etc., and those usually
get
> done with a bit of assembler. Inline assembler can also get you out of a hole when the compiler is not generating good enough code for a particular performance bottleneck.

Thanks. This is starting to ring some old bells from school days.
In a C project I once saw inline assembler used to access the host cpu's
test-and-set operation(s) for implementing locks. Until then I didn't think
you could embed asm in C (maybe just a gcc enhancement).

--Cheers, Steve.

On Sun, 21 Jul 2002 18:27:08 +1000 "Steven Shaw" <steven_shaw@iprimus.com.au> wrote:

> For some embedded work this is probably mandatory. I get the feeling,
> though, that
> many system apps do not require this feature. Though it doesn't hurt to have
> it.
> I just don't like to see too much Java and C# bashing here on the D
> newsgroup.
> You can write compilers, editors, jvm's in Java (can't say I know *how* they
> did it), so
> I'm sure that it would be pretty hard to come up with a task that just flat
> can't be done.

You can write GUI applications in Java, but do they work fast? And how would they work if entire graphics output, down to the lowest-level primitives, would be written in Java?

VM... not sure how fast VM written in Java would be, but I'd bet it
is slower than any VM written in some non-interpreted language.

>> 2) it doesn't require an abstraction layer or virtual machine between it
> and
>> the actual hardware
> 
> Does this mean that D doesn't have a runtime?

It does, but it is embedded into your executable. You don't need any external applications or DLLs or components to run the D program. For Java, you need a JVM. For C#, there are some DLLs, as far as I know.

> Or more likely that you can optionally leave out the runtime at link time?

I doubt. GC, dynamic arrays, hashes, class Object, ClassInfo - are all in
RTL.

>> 3) it can interface directly to the raw operating system entry points
> 
> Is this the C  interoperability at work?

Not only C, but also stdcall.

> I also get the feeling from other posts that the D implementation uses whole program optimisation techniques to decide when methods need not be dynamically dispatched. yes?

It is stated. But I'm not sure whether current alpha supports this.

> Thanks. This is starting to ring some old bells from school days.
> In a C project I once saw inline assembler used to access the host cpu's
> test-and-set operation(s) for implementing locks. Until then I didn't think
> you could embed asm in C (maybe just a gcc enhancement).

It isn't ANSI C (nor C++), but I haven't yet seen any C/C++ compiler which doesn't support some form of inline asm. At least MS, Intel, Borland, GNU, and DM compilers support it.