The question for us is, what "killer app" are we going to produce as a
community.

Good question. For starters, such an app would have to be a non-toolchain kind
of program; this would place it one tier above where most of us are
concentrating right now.
D's advantage over its competitors, in the hands of the end user, is in terms of
program quality, size and speed. I think this is a viable niche for a D "killer
app" that could attract people to the technology.
I read something on digg the other day about "microtorrent" which was warmly
received even though it had pretty much the same feature set its competition. I
distinguished itself by being more responsive, smaller and faster than just
about every other torrent tracker out there. I'd like to think that particular
software author managed to tap into something that users actually want.
An idle thought: has anyone around here given any thought to an automated bug
reporting service for D apps? Maybe we can set up something that plugs into
dsource.org's Trac system?
- Eric Anderton at yahoo

Good question. For starters, such an app would have to be a non-toolchain kind
of program; this would place it one tier above where most of us are
concentrating right now.
D's advantage over its competitors, in the hands of the end user, is in terms
of
program quality, size and speed. I think this is a viable niche for a D
"killer
app" that could attract people to the technology.

I think a real "killer app" would be a next generation desktop
environment (e.g. D port of KDE using interpreted scripting languages
and XML), but it would need to be written from scratch using D.
The main advantages are that
- D is more powerful than current functional languages
- D is more reliable (=bug-free) than C/C++
- D doesn't run under a virtual machine
- it's easy to integrate garbage collecting scripting languages inside D
Another great project would be a D operating system, but it's far too
big a project for this community and eventually would not be able to
produce enough hype around D.
--
Jari-Matti

of program; this would place it one tier above where most of us are
concentrating right now.
D's advantage over its competitors, in the hands of the end user, is in terms
of
program quality, size and speed. I think this is a viable niche for a D
"killer
app" that could attract people to the technology.

I think a real "killer app" would be a next generation desktop
environment (e.g. D port of KDE using interpreted scripting languages
and XML), but it would need to be written from scratch using D.
The main advantages are that
- D is more powerful than current functional languages
- D is more reliable (=bug-free) than C/C++
- D doesn't run under a virtual machine
- it's easy to integrate garbage collecting scripting languages inside D
Another great project would be a D operating system, but it's far too
big a project for this community and eventually would not be able to
produce enough hype around D.

non-toolchain kind
of program; this would place it one tier above where most of us are
concentrating right now.
D's advantage over its competitors, in the hands of the end user, is
in terms of
program quality, size and speed. I think this is a viable niche for
a D "killer
app" that could attract people to the technology.

I think a real "killer app" would be a next generation desktop
environment (e.g. D port of KDE using interpreted scripting languages
and XML), but it would need to be written from scratch using D.
The main advantages are that
- D is more powerful than current functional languages
- D is more reliable (=bug-free) than C/C++
- D doesn't run under a virtual machine
- it's easy to integrate garbage collecting scripting languages inside D
Another great project would be a D operating system, but it's far too
big a project for this community and eventually would not be able to
produce enough hype around D.

What approximate LOC could be expected in a Firefox-like app?

A lot :) It depends on many things. Most users would probably want the
html/xml-parser to be able to parse all kinds of invalid markup too.
Then some others would like to have a file system browser integrated
there. I guess a good point to start would be the (x)html rendering
engine, khtml and gecko are both leaking a lot of memory. Maybe ~100 000
lines of code would be enough?
--
Jari-Matti

Good question. For starters, such an app would have to be a non-toolchain kind
of program; this would place it one tier above where most of us are
concentrating right now.
D's advantage over its competitors, in the hands of the end user, is in terms
of
program quality, size and speed. I think this is a viable niche for a D
"killer
app" that could attract people to the technology.
I read something on digg the other day about "microtorrent" which was warmly
received even though it had pretty much the same feature set its competition.
I
distinguished itself by being more responsive, smaller and faster than just
about every other torrent tracker out there. I'd like to think that particular
software author managed to tap into something that users actually want.
An idle thought: has anyone around here given any thought to an automated bug
reporting service for D apps? Maybe we can set up something that plugs into
dsource.org's Trac system?
- Eric Anderton at yahoo

What about a killer web stack? Arent Mango and DSP half the way there already?
Wouldnt Kris's http server beat out a java one in
terms of speed and memory footprint?

Good question. For starters, such an app would have to be a non-toolchain kind
of program; this would place it one tier above where most of us are
concentrating right now.
D's advantage over its competitors, in the hands of the end user, is in terms
of
program quality, size and speed. I think this is a viable niche for a D
"killer
app" that could attract people to the technology.
I read something on digg the other day about "microtorrent" which was warmly
received even though it had pretty much the same feature set its competition.
I
distinguished itself by being more responsive, smaller and faster than just
about every other torrent tracker out there. I'd like to think that particular
software author managed to tap into something that users actually want.
An idle thought: has anyone around here given any thought to an automated bug
reporting service for D apps? Maybe we can set up something that plugs into
dsource.org's Trac system?
- Eric Anderton at yahoo

What about a killer web stack? Arent Mango and DSP half the way there already?
Wouldnt Kris's http server beat out a java one in
terms of speed and memory footprint?

Can't say in terms of memory footprint (I know DDL has *some* potential to pack
on the KB if you don't stack your libraries right), but in terms of performance:
you bet.
As for DSP itself, I'm also taking advantage of its "back burner" status for now
and considering what can be done to level it against Rails and such.
- Eric Anderton at yahoo

Good question. For starters, such an app would have to be a non-toolchain
kind
of program; this would place it one tier above where most of us are
concentrating right now.
D's advantage over its competitors, in the hands of the end user, is in
terms of
program quality, size and speed. I think this is a viable niche for a D
"killer
app" that could attract people to the technology.
I read something on digg the other day about "microtorrent" which was
warmly
received even though it had pretty much the same feature set its
competition. I
distinguished itself by being more responsive, smaller and faster than
just
about every other torrent tracker out there. I'd like to think that
particular
software author managed to tap into something that users actually want.

Maybe, but I don't think most people care much about whether something is
written in D or C. Both will give you similar results in the end, and what
people notice is when things break. e.g. does it break my cell-phone
(perhaps eat all the memory) when I do X? Programmers, and others who might
appreciate the finer points of one solution over another, are in a rather
small minority.
Thus, perhaps a general distinction for the developer becomes "which
language has the most appropriate library" to get this job done? Other pain
points may come into focus along the way, such as memory usage (in a limited
environment) and performance (on a battery powered device).
In short, I don't think D has any particular redeeming feature that would
lend itself toward a "D Killer App", rather than a "C++ Killer App".
Instead, I think D needs a target market of developers who are actually
*looking* for a better solution than what they currently have.

The question for us is, what "killer app" are we going to produce as a
community.

A no-frills yet fast and light browser to start with. Worked for Java (even w/o
the fast and light parts).
Here are the specs:
- Firefox functionality w/o anything not essential for displaying pages
containing HTML, standard image formats and JavaScript.
- Name it hotDamn, Dowser or (time for a name contest?) <g>
Perhaps DWT could be used to encapsulate Harmonia (for the HTML, CSS and image
rendering) and we already have a world-class ECMAScript engine for the
JavaScript engine.

The question for us is, what "killer app" are we going to produce as a
community.

How about the RoR equivalent for the desktop? ;)
http://www.litwindow.com/lwl/doc/html/comparison_10x.html
RapidUI it's an excellent library that wraps the wxWidgets SDK with
macros and some template magic to speed up development of GUI apps.
Places were I see D competing with C++ face to face is in the Game and
Shareware markets. A really easy game engine and a library like RapidUI
wrapping DFL or DWT would sell any of my friends to D any day.
Maybe Doug Clougston (a.k.a Template Ninka) could take this task on it's
shoulders?

Hmmm ... I thought it was quite moderate :)
Sure, there's one fool jiving on Z80, but I thought the other comments were
pretty accurate :: it's a step in the right direction, but with no realistic
library (yet), and no *obvious* sign of the backing needed to make an
notable impact.
These are realistic criticisms.
On the other hand, the whole topic is immediately flawed :: it's almost all
about Ruby. Ruby is great for writing throw-away code. Has anyone here
actually tried to use it with say, 20 developers, over a multi-year project?
It's not as though Ruby is actually new ~ been around for years. It's
really, really hard to write large-scale, maintainable code in *any*
scripting language (yes, I know there's one or two household names who use
it ~ but do you also know their pain?)
The point is that Ruby et.al. are designed for scripting ~ a whole different
ballgame than a systems language. One might well argue the pro's and con's
of late- vs early- binding. Instead, I'll just note that Ruby, Perl, Python,
VB, and a slew of others address a conceptually different set of problems
than D. For example, D would be a good language to write a Ruby engine in.
Would Python be an appropriate choice to write a Ruby interpreter? D would
probably be a good choice to write "yet another back-office suite" (think
PeopleSoft, Oracle, SAP :: payroll processing, etc), yet Perl would probably
not be ...
As the industry matures, there's a high likelihood for the balance to shift
between around between different types of languages (between, say, 3G and 4
or 5G). Yet you still have to pick the right tool for the job. Throwaway
code is apparently becoming more and more popular (there's much less
emphasis on long-term maintenance than there used to be), and processors are
bob-awful fast these days compared to what they used to be. Not to mention
the amounts of memory available. Still, another set of killer-apps will
eventually come along that squeezes the hardware once again, and D will be
right there for when that happens (just as C and C++ will be). I mean, we
ain't gonna see a speech-recognition engine written in Ruby ~ at least, not
this decade!
One final thought :: I really think D has the wrong target in mind. Walter
seems to be interested in the desktop/server arena, yet the best place for D
is actually the embedded market instead. We're talking about the most
prevalent computers on the planet ~ they're in washing machines, vaccum
cleaners, cars, ships, TV's, mp3 players, iPod's, cell-phones, blah blah
blah. People don't use C++ there because it's way too bloated. They use C
(and some assembler) because it's lightweight and fits the devices nicely.
It's a huge market, just crying out for an 'upgrade' in terms of a language
as a tool.
This is why I have an interest in getting D running on PocketPC. There's an
enormous potential in the land of cell-phones and, frankly, I rather suspect
that's the general direction of future platforms (as opposed to desktops).
Why bother competing with C++ and/or Java when you can sidestep them (and
all the associated cronyism) completely?

Agreed. However, threads on slashdot have an exceedingly short
half-life--moderation stagnates a few hours after the topic appears at
most. So while it would be nice to have in there, few people may
actually read it at this point.
Sean

Agreed. However, threads on slashdot have an exceedingly short
half-life--moderation stagnates a few hours after the topic appears at
most. So while it would be nice to have in there, few people may actually
read it at this point.

The 'slashdot effect' for an article lasts about 24-48 hours (based on the
surge of traffic at www.digitalmars.com when we're on slashdot). So you're
right, the half-life is brief, but on the other hand, a lot of people are
reached who would not otherwise have heard of D.

<g>
Actually, that was intended primarily for you to digest. Whilst it's
just an opinion, I truly feel you should seriously consider the embedded
market as the initial home for D. Here's some off-the-cuff reasoning:
a) Java & C++ have the desktop & server market sewn up for now (in
non-scripting languages). Sure, you can try to challenge that from the
basement level ~ but D needs some street cred to make it past the first
stairwell. Java had a comparatively limitless budget, and there was a
brand new hole needing to be plugged. What does D have to compete with?
Good intentions alone are not enough to succeed.
b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language.
One with a small learning curve, fast compiler, and a small library. The
best of Java and C together. Sure, I may not use D for a
micro-controller with 4KB; but that's fast becoming the exception for
everyday devices. Combine D with cell-phones and a gazillion other new
gadgets ... Seems like a no-brainer.
c) Believe it or not, you can still sell compilers to the embedded
market. Four years ago, I paid over $2000 for a C compiler, questionable
debugger, and emulator from Hitachi (t'was the only one available). You
can probably still sell a good D compiler and debugger for $300 per
seat. As you know, that kind of market disappeared long ago on the
desktop ~ if it ain't free, forget it (how does the venerable
Green-Hills stay in business these days? Is it the embedded market?)
Heck, GDC can apparently already compile targets for Arm/xscale devices.
Yet there needs to be a full toolchain to make it worthy of more than a
passing glance.
d) the embedded market is far more likely to give D "a go". Unlike the
desktop/server world, there's generally far less investment into a
particular or specific infrastructure. Often none. If an engineer can
prove that D is faster to develop with and more robust, it's often a
done deal. The environment is quite different than today's Java
sweat-shops ~ in my humble experience it retains many of the good
qualities from twenty years ago.
d) Building up some credibility in the embedded market also provides
time to construct a decent (and robust) library set for other arenas. We
all know there's an ocean missing there in terms of the desktop/server
space (compared to C, C++, Java, Ruby, Python, VB etc). The embedded
market prefers to get by without such fancy jewelry. They prefer just a
solid toolchain with a language that exposes assembler, and can bind to
C libs if necessary. Eliminating bugs early in the cycle is *the key*
thing in that environment. It's just not economically feasible to patch
devices once they're out on the street, so you *have* to get it correct
up front. Can you say 'contracts' and 'bounds-checking', 'exception
handling' and 'optional garbage collection'?
There's that question that keeps coming up year after year: "what does D
target"? I think Matthew grumbled about it again just the other day, and
it's one that I've certainly asked myself a number of times. The
embedded market is the one place I can think of that would potentially
embrace the language. In contrast, it's quite clear that the C++/Java
arena would prefer to dispense scorn instead. That's not exactly
unexpected at this point, but D would stand a much better chance of
success if it had some true street-cred under its belt. And you might
even make a bundle selling compilers in the meantime <g>

<g>
Actually, that was intended primarily for you to digest. Whilst it's
just an opinion, I truly feel you should seriously consider the embedded
market as the initial home for D. Here's some off-the-cuff reasoning:
a) Java & C++ have the desktop & server market sewn up for now (in
non-scripting languages). Sure, you can try to challenge that from the
basement level ~ but D needs some street cred to make it past the first
stairwell. Java had a comparatively limitless budget, and there was a
brand new hole needing to be plugged. What does D have to compete with?
Good intentions alone are not enough to succeed.
b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language.
One with a small learning curve, fast compiler, and a small library. The
best of Java and C together. Sure, I may not use D for a
micro-controller with 4KB; but that's fast becoming the exception for
everyday devices. Combine D with cell-phones and a gazillion other new
gadgets ... Seems like a no-brainer.
c) Believe it or not, you can still sell compilers to the embedded
market. Four years ago, I paid over $2000 for a C compiler, questionable
debugger, and emulator from Hitachi (t'was the only one available). You
can probably still sell a good D compiler and debugger for $300 per
seat. As you know, that kind of market disappeared long ago on the
desktop ~ if it ain't free, forget it (how does the venerable
Green-Hills stay in business these days? Is it the embedded market?)

LOL, I could walk to Green Hills from where I live! I might intern there this
summer :-)
Yeah, they are all about embedded systems. (if that wasn't rhetorical)

Heck, GDC can apparently already compile targets for Arm/xscale devices.
Yet there needs to be a full toolchain to make it worthy of more than a
passing glance.
d) the embedded market is far more likely to give D "a go". Unlike the
desktop/server world, there's generally far less investment into a
particular or specific infrastructure. Often none. If an engineer can
prove that D is faster to develop with and more robust, it's often a
done deal. The environment is quite different than today's Java
sweat-shops ~ in my humble experience it retains many of the good
qualities from twenty years ago.
d) Building up some credibility in the embedded market also provides
time to construct a decent (and robust) library set for other arenas. We
all know there's an ocean missing there in terms of the desktop/server
space (compared to C, C++, Java, Ruby, Python, VB etc). The embedded
market prefers to get by without such fancy jewelry. They prefer just a
solid toolchain with a language that exposes assembler, and can bind to
C libs if necessary. Eliminating bugs early in the cycle is *the key*
thing in that environment. It's just not economically feasible to patch
devices once they're out on the street, so you *have* to get it correct
up front. Can you say 'contracts' and 'bounds-checking', 'exception
handling' and 'optional garbage collection'?
There's that question that keeps coming up year after year: "what does D
target"? I think Matthew grumbled about it again just the other day, and
it's one that I've certainly asked myself a number of times. The
embedded market is the one place I can think of that would potentially
embrace the language. In contrast, it's quite clear that the C++/Java
arena would prefer to dispense scorn instead. That's not exactly
unexpected at this point, but D would stand a much better chance of
success if it had some true street-cred under its belt. And you might
even make a bundle selling compilers in the meantime <g>

Solid reasoning. Does DMD have the ability to handle other assembler besides
x86?

Solid reasoning.
Does DMD have the ability to handle other assembler besides x86?

AFAIK, DMD doesn't even do code for anything but X86. Let alone asm.
GDC, on the other hand, does code for other architectures but needs
some work for non-X86 assembler (mapping arguments to registers, etc)
But GCC does inline assembler for several targets (only tried PowerPC)
Meanwhile; one can do separate assembler files, and link them with D ?
--anders

That all makes a *hell of a lot* of sense to me.
"kris" <fu bar.org> wrote in message news:drsfap$7bk$1 digitaldaemon.com...

Walter Bright wrote:

I think you should post that on slashdot as well!

<g>
Actually, that was intended primarily for you to digest. Whilst it's just
an opinion, I truly feel you should seriously consider the embedded market
as the initial home for D. Here's some off-the-cuff reasoning:
a) Java & C++ have the desktop & server market sewn up for now (in
non-scripting languages). Sure, you can try to challenge that from the
basement level ~ but D needs some street cred to make it past the first
stairwell. Java had a comparatively limitless budget, and there was a
brand new hole needing to be plugged. What does D have to compete with?
Good intentions alone are not enough to succeed.
b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language. One
with a small learning curve, fast compiler, and a small library. The best
of Java and C together. Sure, I may not use D for a micro-controller with
4KB; but that's fast becoming the exception for everyday devices. Combine
D with cell-phones and a gazillion other new gadgets ... Seems like a
no-brainer.
c) Believe it or not, you can still sell compilers to the embedded market.
Four years ago, I paid over $2000 for a C compiler, questionable debugger,
and emulator from Hitachi (t'was the only one available). You can probably
still sell a good D compiler and debugger for $300 per seat. As you know,
that kind of market disappeared long ago on the desktop ~ if it ain't
free, forget it (how does the venerable Green-Hills stay in business these
days? Is it the embedded market?)
Heck, GDC can apparently already compile targets for Arm/xscale devices.
Yet there needs to be a full toolchain to make it worthy of more than a
passing glance.
d) the embedded market is far more likely to give D "a go". Unlike the
desktop/server world, there's generally far less investment into a
particular or specific infrastructure. Often none. If an engineer can
prove that D is faster to develop with and more robust, it's often a done
deal. The environment is quite different than today's Java sweat-shops ~
in my humble experience it retains many of the good qualities from twenty
years ago.
d) Building up some credibility in the embedded market also provides time
to construct a decent (and robust) library set for other arenas. We all
know there's an ocean missing there in terms of the desktop/server space
(compared to C, C++, Java, Ruby, Python, VB etc). The embedded market
prefers to get by without such fancy jewelry. They prefer just a solid
toolchain with a language that exposes assembler, and can bind to C libs
if necessary. Eliminating bugs early in the cycle is *the key* thing in
that environment. It's just not economically feasible to patch devices
once they're out on the street, so you *have* to get it correct up front.
Can you say 'contracts' and 'bounds-checking', 'exception handling' and
'optional garbage collection'?
There's that question that keeps coming up year after year: "what does D
target"? I think Matthew grumbled about it again just the other day, and
it's one that I've certainly asked myself a number of times. The embedded
market is the one place I can think of that would potentially embrace the
language. In contrast, it's quite clear that the C++/Java arena would
prefer to dispense scorn instead. That's not exactly unexpected at this
point, but D would stand a much better chance of success if it had some
true street-cred under its belt. And you might even make a bundle selling
compilers in the meantime <g>

At first blush I thought the (very well argued) embedded idea a grand one, but
playing the contrarian here:
- I don't have stats. on this, but I got to believe that both dedicated embedded
developers and total embedded LOC are both in a pretty small minority. A good
chunk of a (relatively) small, fragmented market is still a small, fragmented
chunk, even if it is growing <g>
- C didn't become big in the embedded market until it was used for other
development in and of more mainstream 'standardized' environments.
- D's biggest problem right now seems to be libraries, which implies that
embedded developers would have to create their own or hack phobos. This would
further 'fragment' lib. development. And who's to say that these specialized
libraries would be much good anywhere else but for the specific system they were
developed for (e.g.: ARM assembly sprinkled throughout).
- Would embedded developers embrace a language that (according to several in
this group who have voiced support of the embedded idea) is not quite
ready-for-prime-time yet, no matter how great the language is?
- If D does happen to take off in the embedded market, does that neccessarily
mean it will catch on for the majority in the mainstream any sooner than it
would otherwise?
- As to developing backends for the different embedded platforms - Hasn't x86-32
been getting more and more market share in the embedded space over the last
couple of years anyway (in part because of the dev. tools already available and
relatively cheap for it)?
I can't agree more that D needs to stand out somehow, but I'm wondering if
concentrating effort on the embedded market is really an answer?
- Dave

<g>
Actually, that was intended primarily for you to digest. Whilst it's just
an opinion, I truly feel you should seriously consider the embedded market
as the initial home for D. Here's some off-the-cuff reasoning:
a) Java & C++ have the desktop & server market sewn up for now (in
non-scripting languages). Sure, you can try to challenge that from the
basement level ~ but D needs some street cred to make it past the first
stairwell. Java had a comparatively limitless budget, and there was a
brand new hole needing to be plugged. What does D have to compete with?
Good intentions alone are not enough to succeed.
b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language. One
with a small learning curve, fast compiler, and a small library. The best
of Java and C together. Sure, I may not use D for a micro-controller with
4KB; but that's fast becoming the exception for everyday devices. Combine
D with cell-phones and a gazillion other new gadgets ... Seems like a
no-brainer.
c) Believe it or not, you can still sell compilers to the embedded market.
Four years ago, I paid over $2000 for a C compiler, questionable debugger,
and emulator from Hitachi (t'was the only one available). You can probably
still sell a good D compiler and debugger for $300 per seat. As you know,
that kind of market disappeared long ago on the desktop ~ if it ain't
free, forget it (how does the venerable Green-Hills stay in business these
days? Is it the embedded market?)
Heck, GDC can apparently already compile targets for Arm/xscale devices.
Yet there needs to be a full toolchain to make it worthy of more than a
passing glance.
d) the embedded market is far more likely to give D "a go". Unlike the
desktop/server world, there's generally far less investment into a
particular or specific infrastructure. Often none. If an engineer can
prove that D is faster to develop with and more robust, it's often a done
deal. The environment is quite different than today's Java sweat-shops ~
in my humble experience it retains many of the good qualities from twenty
years ago.
d) Building up some credibility in the embedded market also provides time
to construct a decent (and robust) library set for other arenas. We all
know there's an ocean missing there in terms of the desktop/server space
(compared to C, C++, Java, Ruby, Python, VB etc). The embedded market
prefers to get by without such fancy jewelry. They prefer just a solid
toolchain with a language that exposes assembler, and can bind to C libs
if necessary. Eliminating bugs early in the cycle is *the key* thing in
that environment. It's just not economically feasible to patch devices
once they're out on the street, so you *have* to get it correct up front.
Can you say 'contracts' and 'bounds-checking', 'exception handling' and
'optional garbage collection'?
There's that question that keeps coming up year after year: "what does D
target"? I think Matthew grumbled about it again just the other day, and
it's one that I've certainly asked myself a number of times. The embedded
market is the one place I can think of that would potentially embrace the
language. In contrast, it's quite clear that the C++/Java arena would
prefer to dispense scorn instead. That's not exactly unexpected at this
point, but D would stand a much better chance of success if it had some
true street-cred under its belt. And you might even make a bundle selling
compilers in the meantime <g>

Good points, Dave. I'll have a stab at a few of them:
"Dave" <Dave_member pathlink.com> wrote in..

In article <drsgqm$8jg$1 digitaldaemon.com>, Matthew says...

That all makes a *hell of a lot* of sense to me.

At first blush I thought the (very well argued) embedded idea a grand one,
but
playing the contrarian here:
- I don't have stats. on this, but I got to believe that both dedicated
embedded
developers and total embedded LOC are both in a pretty small minority. A
good
chunk of a (relatively) small, fragmented market is still a small,
fragmented
chunk, even if it is growing <g>

D has no user-base right now (the NG doesn't count in the real world).
Getting a foothold within a market segment that is far more open to change
would potentially give D the credibility it needs for adoption elsewhere.
From a different perspective, it's not as though there's an economic
incentive to address the desktop market ~ it's all free there, whereas you
could actually fund a traditional business within the embedded space. I have
to wonder whether the latter is moot, though. And who's to say it an "all or
nothing" prospect? D simply cannot compete in the desktop/server market now,
so why not establish some credibility in other areas?

- C didn't become big in the embedded market until it was used for other
development in and of more mainstream 'standardized' environments.

Are you sure there was a recognizable embedded market prior to C? How many
years back? Yes, there were various flavours of BASIC burned into ROM on
early devices, but those were supplemented by early C compilers. I'm going
back 22 years, when we used WordStar for a code-editor (and had to walk to
work in our bare feet ...)

- D's biggest problem right now seems to be libraries, which implies that
embedded developers would have to create their own or hack phobos. This
would
further 'fragment' lib. development. And who's to say that these
specialized
libraries would be much good anywhere else but for the specific system
they were
developed for (e.g.: ARM assembly sprinkled throughout).

The embedded market tend to have far less relience upon libraries. Math and
signal-processing are big. Comms is big. But nothing at all like the
desktop/server Java platform. They are truly worlds' apart. This is a big
factor of why it potentially makes sense to address the embedded segment for
the time being ~ allows time for realistic desktop/server libs to develop &
mature.

- Would embedded developers embrace a language that (according to several
in
this group who have voiced support of the embedded idea) is not quite
ready-for-prime-time yet, no matter how great the language is?

That depends what you need out of a language. For example, the -H issue is
far less pronounced in the embedded segment. Perhaps even non-existent. The
emphasis on various language aspects are quite different.

- If D does happen to take off in the embedded market, does that
neccessarily
mean it will catch on for the majority in the mainstream any sooner than
it
would otherwise?

I suspect it would stand a much better chance with some real-world usage.
And again, it allows more time for competitive Java/C++ level libraries to
establish and become mature.

- As to developing backends for the different embedded platforms - Hasn't
x86-32
been getting more and more market share in the embedded space over the
last
couple of years anyway (in part because of the dev. tools already
available and
relatively cheap for it)?

Yes; there are a number of ongoing efforts (that I know of) to bring Win32
to the palm of your hand. Some very cool ones too. But that's the driving
force there. You far less likely to see that in cars, planes, ships, etc,
etc. Embedded systems are typically specific to a particular need ~ they're
not general purpose in the same sense as Win32 machines. So, while we might
see a number of tiny Win32 machines, they'll be a rather small overall
proportion. Additionally, I suspect it'll be quite a while (if ever) before
x86-32 has competitive battery longevity.

I can't agree more that D needs to stand out somehow, but I'm wondering if
concentrating effort on the embedded market is really an answer?

I wonder too. But thought it worth investigating given that lack of any
other strategy, and the lack of competitive libraries :)

<g>
Actually, that was intended primarily for you to digest. Whilst it's
just
an opinion, I truly feel you should seriously consider the embedded
market
as the initial home for D. Here's some off-the-cuff reasoning:
a) Java & C++ have the desktop & server market sewn up for now (in
non-scripting languages). Sure, you can try to challenge that from the
basement level ~ but D needs some street cred to make it past the first
stairwell. Java had a comparatively limitless budget, and there was a
brand new hole needing to be plugged. What does D have to compete with?
Good intentions alone are not enough to succeed.
b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language.
One
with a small learning curve, fast compiler, and a small library. The
best
of Java and C together. Sure, I may not use D for a micro-controller
with
4KB; but that's fast becoming the exception for everyday devices.
Combine
D with cell-phones and a gazillion other new gadgets ... Seems like a
no-brainer.
c) Believe it or not, you can still sell compilers to the embedded
market.
Four years ago, I paid over $2000 for a C compiler, questionable
debugger,
and emulator from Hitachi (t'was the only one available). You can
probably
still sell a good D compiler and debugger for $300 per seat. As you
know,
that kind of market disappeared long ago on the desktop ~ if it ain't
free, forget it (how does the venerable Green-Hills stay in business
these
days? Is it the embedded market?)
Heck, GDC can apparently already compile targets for Arm/xscale devices.
Yet there needs to be a full toolchain to make it worthy of more than a
passing glance.
d) the embedded market is far more likely to give D "a go". Unlike the
desktop/server world, there's generally far less investment into a
particular or specific infrastructure. Often none. If an engineer can
prove that D is faster to develop with and more robust, it's often a
done
deal. The environment is quite different than today's Java sweat-shops ~
in my humble experience it retains many of the good qualities from
twenty
years ago.
d) Building up some credibility in the embedded market also provides
time
to construct a decent (and robust) library set for other arenas. We all
know there's an ocean missing there in terms of the desktop/server space
(compared to C, C++, Java, Ruby, Python, VB etc). The embedded market
prefers to get by without such fancy jewelry. They prefer just a solid
toolchain with a language that exposes assembler, and can bind to C libs
if necessary. Eliminating bugs early in the cycle is *the key* thing in
that environment. It's just not economically feasible to patch devices
once they're out on the street, so you *have* to get it correct up
front.
Can you say 'contracts' and 'bounds-checking', 'exception handling' and
'optional garbage collection'?
There's that question that keeps coming up year after year: "what does D
target"? I think Matthew grumbled about it again just the other day, and
it's one that I've certainly asked myself a number of times. The
embedded
market is the one place I can think of that would potentially embrace
the
language. In contrast, it's quite clear that the C++/Java arena would
prefer to dispense scorn instead. That's not exactly unexpected at this
point, but D would stand a much better chance of success if it had some
true street-cred under its belt. And you might even make a bundle
selling
compilers in the meantime <g>

Are you sure there was a recognizable embedded market prior to C? How many
years back? Yes, there were various flavours of BASIC burned into ROM on
early devices, but those were supplemented by early C compilers. I'm going
back 22 years, when we used WordStar for a code-editor (and had to walk to
work in our bare feet ...)

Are you sure there was a recognizable embedded market prior to C? How
many
years back? Yes, there were various flavours of BASIC burned into ROM on
early devices, but those were supplemented by early C compilers. I'm
going
back 22 years, when we used WordStar for a code-editor (and had to walk
to
work in our bare feet ...)

b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language.
One with a small learning curve, fast compiler, and a small library. The
best of Java and C together. Sure, I may not use D for a
micro-controller with 4KB; but that's fast becoming the exception for
everyday devices. Combine D with cell-phones and a gazillion other new
gadgets ... Seems like a no-brainer.

This couldn't be more true.
It just so happens that I've been spending some of my free time looking into
retro game console development (a personal soft spot of mine). It is absolutely
shocking how few options there are out there for hobby developers, let alone
professionals, when it comes to languages for everything that isn't an x86 or
PPC processor. Its either C, Basic, ASM or some bastard combination of the
above. Hobbyist tools are of usually poor quality, or just poorly documented.
Also that landscape is also the reason why code reuse and mobitiliy between
architectures is non-existant.
I agree with Kris' sentiment about micros, but it might be an interesting
experiment non the less. But I am scratching my head as to how you'd get D to
target an 8-bit or 16-bit embedded environment. Perhaps that's just not
possible?
- Eric Anderton at yahoo

b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language.
One with a small learning curve, fast compiler, and a small library. The
best of Java and C together. Sure, I may not use D for a
micro-controller with 4KB; but that's fast becoming the exception for
everyday devices. Combine D with cell-phones and a gazillion other new
gadgets ... Seems like a no-brainer.

This couldn't be more true.
It just so happens that I've been spending some of my free time looking
into
retro game console development (a personal soft spot of mine). It is
absolutely
shocking how few options there are out there for hobby developers, let
alone
professionals, when it comes to languages for everything that isn't an x86
or
PPC processor. Its either C, Basic, ASM or some bastard combination of
the
above. Hobbyist tools are of usually poor quality, or just poorly
documented.
Also that landscape is also the reason why code reuse and mobitiliy
between
architectures is non-existant.

Amem.

I agree with Kris' sentiment about micros, but it might be an interesting
experiment non the less. But I am scratching my head as to how you'd get
D to
target an 8-bit or 16-bit embedded environment. Perhaps that's just not
possible?

I think that's a question of strategy. For example, it would make sense to
initially target the ARM/XScale instruction set (those devices are now
notably more capable than a "state of the art" PentiumII from not so long
ago). On the flip-side, I'm don't think it would make much sense to target
an 8-bit device. D is the wrong tool there.

<g>
Actually, that was intended primarily for you to digest. Whilst it's
just an opinion, I truly feel you should seriously consider the embedded
market as the initial home for D. Here's some off-the-cuff reasoning:
a) Java & C++ have the desktop & server market sewn up for now (in
non-scripting languages). Sure, you can try to challenge that from the
basement level ~ but D needs some street cred to make it past the first
stairwell. Java had a comparatively limitless budget, and there was a
brand new hole needing to be plugged. What does D have to compete with?
Good intentions alone are not enough to succeed.
b) The embedded market is stuck in C/assembler land. C++ is typically
scorned in such environments, well deserved or not. Thus, it's a ripe
market to address with D ~ a low overhead, efficient, robust language.
One with a small learning curve, fast compiler, and a small library. The
best of Java and C together. Sure, I may not use D for a
micro-controller with 4KB; but that's fast becoming the exception for
everyday devices. Combine D with cell-phones and a gazillion other new
gadgets ... Seems like a no-brainer.
c) Believe it or not, you can still sell compilers to the embedded
market. Four years ago, I paid over $2000 for a C compiler, questionable
debugger, and emulator from Hitachi (t'was the only one available). You
can probably still sell a good D compiler and debugger for $300 per
seat. As you know, that kind of market disappeared long ago on the
desktop ~ if it ain't free, forget it (how does the venerable
Green-Hills stay in business these days? Is it the embedded market?)
Heck, GDC can apparently already compile targets for Arm/xscale devices.
Yet there needs to be a full toolchain to make it worthy of more than a
passing glance.
d) the embedded market is far more likely to give D "a go". Unlike the
desktop/server world, there's generally far less investment into a
particular or specific infrastructure. Often none. If an engineer can
prove that D is faster to develop with and more robust, it's often a
done deal. The environment is quite different than today's Java
sweat-shops ~ in my humble experience it retains many of the good
qualities from twenty years ago.
d) Building up some credibility in the embedded market also provides
time to construct a decent (and robust) library set for other arenas. We
all know there's an ocean missing there in terms of the desktop/server
space (compared to C, C++, Java, Ruby, Python, VB etc). The embedded
market prefers to get by without such fancy jewelry. They prefer just a
solid toolchain with a language that exposes assembler, and can bind to
C libs if necessary. Eliminating bugs early in the cycle is *the key*
thing in that environment. It's just not economically feasible to patch
devices once they're out on the street, so you *have* to get it correct
up front. Can you say 'contracts' and 'bounds-checking', 'exception
handling' and 'optional garbage collection'?
There's that question that keeps coming up year after year: "what does D
target"? I think Matthew grumbled about it again just the other day, and
it's one that I've certainly asked myself a number of times. The
embedded market is the one place I can think of that would potentially
embrace the language. In contrast, it's quite clear that the C++/Java
arena would prefer to dispense scorn instead. That's not exactly
unexpected at this point, but D would stand a much better chance of
success if it had some true street-cred under its belt. And you might
even make a bundle selling compilers in the meantime <g>

Two observations:
(1) If D was well received in the embedded market, it could gain
coverage in publications like IEEE Spectrum, where its support for
floating point is another huge selling point. (Good for D).
(2) Other than for embedded x86 CPUs, I can't see how Walter could
implement this without massive rewrites to his compiler backend to
generate code for the other architectures. If he did that, his C++
compiler would also work on those systems. And I think his work on the
front-end would virtually come to a halt. (Very bad for D).

Two observations:
(1) If D was well received in the embedded market, it could gain coverage
in publications like IEEE Spectrum, where its support for floating point
is another huge selling point. (Good for D).
(2) Other than for embedded x86 CPUs, I can't see how Walter could
implement this without massive rewrites to his compiler backend to
generate code for the other architectures. If he did that, his C++
compiler would also work on those systems. And I think his work on the
front-end would virtually come to a halt. (Very bad for D).

That's just the problem. If I worked on embedded systems, nothing else would
happen.
But if anyone wants to set up a business doing D for embedded systems, I
would be more than happy to supply the compiler.

That's just the problem. If I worked on embedded systems, nothing else
would happen.

Ah yes; the "all or nothing" syndrome :)
This "embedded market" approach is just a notion; take it or leave it. Yet,
I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do
anything else" type of response. That's indicative of a knee-jerk reaction
rather than careful thought ~ of course, I could be completely mistaken.
Still, you have to wonder why others feel it would be a sound approach.
Thus, I do hope you give it some serious consideration.

But if anyone wants to set up a business doing D for embedded systems, I
would be more than happy to supply the compiler.

It's the entire tool-chain that's needed to gain traction ~ not a language
front-end. Of all people, it may be you who's needed to get something off
the ground. I'm sure there's plenty of capable individuals here who'd be
willing to step up and help. What D *really* needs right now is a goal; a
direction; some strategy. If you were to actually set something there, and
commit to it, I think you'd be surprised how quickly others would join up.
It would need to be something concrete ~ with a palatable end-point.
Of course, this whole topic is very much dependent upon how serious one is
about the success of D.

That's just the problem. If I worked on embedded systems, nothing else
would happen.

Ah yes; the "all or nothing" syndrome :)
This "embedded market" approach is just a notion; take it or leave it.
Yet,
I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do
anything else" type of response. That's indicative of a knee-jerk
reaction rather than careful thought ~ of course, I could be completely
mistaken.
Still, you have to wonder why others feel it would be a sound approach.
Thus, I do hope you give it some serious consideration.

I'm prepared to give Walter the benefit of the doubt.
As I know very little about the back end of compilers I have a few
questions:
How many different architectures are there in embedded programming?
How long does it take to develop a code generator for another
architecture? Or perhaps more importantly how long does it take to develop
one which performs well enough, compared to existing C compilers, to make
the switch from C to D viable for embedded programmers?*
*It would not necessarily have to outperform but rather perform well
enough to make the other benefits of D outweigh any short fall in
performance.
The C compilers presumably have years of optimisations behind them, won't
DMD require the same time spent optimising in order to reach that
threshold?
Or do embedded programmers "drop into" assembler so frequently as to make
any optimisations in the compiler almost non-essential?
That said, a complier that could optimise especially well would allow
programmers to forgo assembler completely, however, if C compilers have no
managed this, is it even possible? can DMD achieve this?

Of course, this whole topic is very much dependent upon how serious one
is about the success of D.

I'm also going to assume that Walter is dead serious about the success of
D.
Regan

That's hardly relevant, given prior comments; but I'll entertain you anyway:
there's perhaps, ummm, 5000? The point made previously was that you choose
the most appropriate one. Many (such as 8 bit devices) are probably not at
all relevant. I think it would be surprising to support more than two or
three mainstream instruction sets. Ever.

How long does it take to develop a code generator for another
architecture? Or perhaps more importantly how long does it take to develop
one which performs well enough, compared to existing C compilers, to make
the switch from C to D viable for embedded programmers?*

That is such a wide open question. Code generators are (in the classic case)
seperated from the optimizer. The latter operates upon an intermediate
representation, whilst the former is the last (or second to last, if you
count peep-hole seperately) stage. What you glossed over is the target
instruction set. Some are much more tricky than others, especially when it
comes to pipelining, multi-dispatch, and so on. The "standard" optimizations
such as loop-unrolling, constant-propogation, register-colouring and so on
are well understood; and typically isolated quite well. It very much depends
upon the compiler writer, and how much isolation they built into the "back
end".
The nice thing about the embedded market is that the devices are
comparatively simple. Battery life is a predominant factor, which tends to
favour RISC type architectures and single issue cores. They have far fewer
tricky edge conditions and special-cases than, say, X86 (which is pretty
awful). You should study this. Perhaps take a look at the GCC code-generator
for H8.

The C compilers presumably have years of optimisations behind them, won't
DMD require the same time spent optimising in order to reach that
threshold?

You'd be surprised. The type of devices in use require much less effort in
this department to get impresssive results. Almost child's-play to someone
of Walter's caliber. That aside, outright performance from the compiler is
often secondary to the language facilities for "correctness". You see,
embedded systems developers /expect/ to drop into assembler as necessary ~
they do it on a regular basis. It just need to be integrated cleanly and
appropriately.

I'm also going to assume that Walter is dead serious about the success of
D.

Good for you. Perhaps you'll be kind enough to explain what the current
strategy is?
I'm one of those who feel that the "if you build it they will come" approach
is somewhat lacking in success merits. There's nothing wrong with treating D
as a business, with goals, targets, strategies etc. What's troublesome is
(what appears to be) a complete lack of anything like that. Some of us have
invested in D far more than others, Regan. Thus, your comment fails to
address anything of value; and answers less. Perhaps you'll be good enough
to embellish upon your faith? If you can tell us the plot, that would be
great :)

<snip>
Thanks. Having zero knowledge of embedded programming or compiler
internals I was simply trying to get some idea of the scale of the problem.

I'm also going to assume that Walter is dead serious about the success
of D.

Good for you. Perhaps you'll be kind enough to explain what the current
strategy is?

Sarcasm is unbecoming. Your question is rhetorical but I will attempt to
answer the unasked one.
D belongs to Walter. Walter has given me no promises regarding it,
therefore I have no right to demand or require anything of him. Whether he
has a strategy or what that strategy is, is his to keep or share.
That said, I realise that when you invest a lot of time and effort into
something (i.e. Mango) you natuarally create a strong desire to see it
succeed and you may feel somewhat helpless when Walter has complete
control. However, as we've often noted the compiler is only part of the
success of D, libraries like Mango will play a large part in whether it
succeeds or fails, your work is invaluable and goes a long way to helping
D succeed, I'm sure Walter will agree here.
I guess all I am trying to say is, have a little faith in Walter, of all
people he should have the most desire to see D succeed. I want to be
clear, I am not suggesting we stop suggesting and questioning the path D
takes, a different perspective is always useful, but I am suggesting we
don't question his commitment to D.
Regan

I'm also going to assume that Walter is dead serious about the success
of D.

Good for you. Perhaps you'll be kind enough to explain what the current
strategy is?

D belongs to Walter.

I see.

Walter has given me no promises regarding it, therefore I have no right
to demand or require anything of him.

Given that you weren't asking for anything, there's a sly implication there
that people, other than yourself, do so.

Whether he has a strategy or what that strategy is, is his to keep or
share.

I, and others, disagree.

That said, I realise that when you invest a lot of time and effort into
something (i.e. Mango) you natuarally create a strong desire to see it
succeed and you may feel somewhat helpless when Walter has complete
control. However, as we've often noted the compiler is only part of the
success of D, libraries like Mango will play a large part in whether it
succeeds or fails, your work is invaluable and goes a long way to helping
D succeed, I'm sure Walter will agree here.

That's all very nice, Regan. But it's hardly relevant to establishing a
strategic direction. Libraries aside, it's "direction" that D is missing ~
that's always been the case. Great buckets of it.

I guess all I am trying to say is, have a little faith in Walter, of all
people he should have the most desire to see D succeed. I want to be
clear, I am not suggesting we stop suggesting and questioning the path D
takes, a different perspective is always useful, but I am suggesting we
don't question his commitment to D.

You're welcome to speak for yourself. As noted previously, the "build it and
they will come" approach has little vested chance of success in my book. We
don't have to speak in hushed tones about this, you know.
For my part, I'm simply suggesting a possible direction for D that might
actually get some traction. It's just an idea. Further, I'm carefully
suggesting that Walter set direction for (a) others here to actually help
with (b) to set the stage for outsider expectation and (c) to perhaps
justify the ongoing efforts of the one of two handfuls of pimary
contributors, and (d) fill in the many others here.
You may or may not have noticed that it's a tiny percentage of enthuisiasts
who build anything for others to use? Walter could effectively change that
by setting a tangible/palatable direction. It's amazing how quickly people
will sign up, once there's a clear path to follow.
Please at least try to be a bit constructive, Regan. It really seems that
you just want to argue irrelevance or split hairs all the time. Doesn't help
at all, especially when it's a difficult subject. BTW: I notice that you
have zero idea of what the current stratgey is.

That's just the problem. If I worked on embedded systems, nothing else
would happen.

Ah yes; the "all or nothing" syndrome :)
This "embedded market" approach is just a notion; take it or leave it.

I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do
anything else" type of response. That's indicative of a knee-jerk reaction
rather than careful thought ~ of course, I could be completely mistaken.
Still, you have to wonder why others feel it would be a sound approach.

It's not "a sound approach". It's _the only_ approach I've heard about D
that doesn't smack of crossed fingers and pipe-dreams. I think it's time
Walter told us what his approach is, cos it sure ain't giving talks to
people who've just been, and will later be, subject to kong-scale marketing
from soulless corporations, who're drive by _business_ not technology, no
matter how interesting, technically compelling and just plain good/right
they might be. (I've read the SDWest presentation, and it made me want to be
able to play with templates/DTL *right now*!! But that's not the point.) I
think it's been convincingly established that the vast bulk of the C++ world
simply aren't interested in D, and aren't going to be interested in D.
The reasons millions of C++ programmers fled to Java: Tools & Libraries.
Tools & Libraries. Tools & Libraries. Tools & Libraries. Tools & Libraries.
Tools & Libraries. Tools & Libraries. Oh, oh, oh. I nearly forget, there's
also Platform-Independent. (ROFL! Well, we must let the Java people have
their little delusion that there's a _technical_ reason they prefer it to
C++. The idea that Java the language could be technically superior to
anything . . . . <snip: OT>)
The reason millions of C++ programmers don't give a fig about D, and will
continue to not give a fig about D: Tools & Libraries. Tools & Libraries.
Tools & Libraries. Tools & Libraries. Tools & Libraries. Tools & Libraries.
Tools & Libraries. The templates don't matter. The C.P doesn't matter. The
modules don't matter. (In the same way that the awful warts don't matter
either.)
I offer you myself as a good example. When I was using them heavily I really
enjoyed D's templates (apart from lack of impl inst, of course.), and I
expect to do so again if/when I can get back to DTL. But that's a "play
around" / academic exercise. My "real" use of D amounted to several short,
beautifully succinct, hugely fun to code, file processing utilities, in
which D's string handling made the whole thing a total doddle to code
sophisticated behaviour in a short amount of time and LOCs, and without any
bugs to speak of. Marvellous, this D stuff.
But I haven't done any serious D coding in over a year. Why? Because I want
to use all the new features of recls that I've become used to (dependent
on?) in its other language guises. std.recls has stagnated, and when I tried
to use my lib externally the whole thing was a nightmare.
If I, one of D's longest and loudest public supporters, don't use it,
because it's libraries are wanting, or just plain suck, then what chance do
you really think D has of attracting commercial mind-share from the big
successful languages. Let me answer that for you if you've not guessed
already: None.
But hey, that's just one man's opinion. I might be totally wrong. It's only
been 2+ years that people have been voicing these same concerns: look how
far we've come!
Whatever the case, I'd love to hear Walter's strategy for D over the next
five years.
[Now, tiresome as it may be, I have to explicitly state here that I like D
and really want it to succeed - hell, I want to write a book on it! - and
that I consider Walter a friend, respect him, and think he's an obscenely
talented engineer, who's idea's are wont to blow me away or at least make me
go away and emulate them in C++ libs. ;-) He knows that, and most of you
know that, but in times past when I've made critical statements I've had
half the laughing gallery lamely lambast me with comments about "respect"
and "track-record" and other furphys.]

Thus, I do hope you give it some serious consideration.

But if anyone wants to set up a business doing D for embedded systems, I
would be more than happy to supply the compiler.

It's the entire tool-chain that's needed to gain traction ~ not a language
front-end. Of all people, it may be you who's needed to get something off
the ground. I'm sure there's plenty of capable individuals here who'd be
willing to step up and help. What D *really* needs right now is a goal; a
direction; some strategy. If you were to actually set something there, and
commit to it, I think you'd be surprised how quickly others would join up.
It would need to be something concrete ~ with a palatable end-point.

You couldn't be more right. After reading your post I was seeing pictures of
myself with little devices - palms, phones, and whatnot - and I _ain't_ no
hardware biscuit, let me tell you! ;-)

Of course, this whole topic is very much dependent upon how serious one is
about the success of D.

Ouch! I think you should leave the sarcasm to detestable Englishmed. ;-)

[Close-Captioned for the Aussie-Impaired]
Furphy: http://en.wikipedia.org/wiki/Furphy
"A furphy is Australian slang for a rumour, or an erroneous or improbable
story."
In article <drtrho$1f1u$1 digitaldaemon.com>, Matthew says...

That's just the problem. If I worked on embedded systems, nothing else
would happen.

Ah yes; the "all or nothing" syndrome :)
This "embedded market" approach is just a notion; take it or leave it.

I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do
anything else" type of response. That's indicative of a knee-jerk reaction
rather than careful thought ~ of course, I could be completely mistaken.
Still, you have to wonder why others feel it would be a sound approach.

It's not "a sound approach". It's _the only_ approach I've heard about D
that doesn't smack of crossed fingers and pipe-dreams. I think it's time
Walter told us what his approach is, cos it sure ain't giving talks to
people who've just been, and will later be, subject to kong-scale marketing
from soulless corporations, who're drive by _business_ not technology, no
matter how interesting, technically compelling and just plain good/right
they might be. (I've read the SDWest presentation, and it made me want to be
able to play with templates/DTL *right now*!! But that's not the point.) I
think it's been convincingly established that the vast bulk of the C++ world
simply aren't interested in D, and aren't going to be interested in D.
The reasons millions of C++ programmers fled to Java: Tools & Libraries.
Tools & Libraries. Tools & Libraries. Tools & Libraries. Tools & Libraries.
Tools & Libraries. Tools & Libraries. Oh, oh, oh. I nearly forget, there's
also Platform-Independent. (ROFL! Well, we must let the Java people have
their little delusion that there's a _technical_ reason they prefer it to
C++. The idea that Java the language could be technically superior to
anything . . . . <snip: OT>)
The reason millions of C++ programmers don't give a fig about D, and will
continue to not give a fig about D: Tools & Libraries. Tools & Libraries.
Tools & Libraries. Tools & Libraries. Tools & Libraries. Tools & Libraries.
Tools & Libraries. The templates don't matter. The C.P doesn't matter. The
modules don't matter. (In the same way that the awful warts don't matter
either.)
I offer you myself as a good example. When I was using them heavily I really
enjoyed D's templates (apart from lack of impl inst, of course.), and I
expect to do so again if/when I can get back to DTL. But that's a "play
around" / academic exercise. My "real" use of D amounted to several short,
beautifully succinct, hugely fun to code, file processing utilities, in
which D's string handling made the whole thing a total doddle to code
sophisticated behaviour in a short amount of time and LOCs, and without any
bugs to speak of. Marvellous, this D stuff.
But I haven't done any serious D coding in over a year. Why? Because I want
to use all the new features of recls that I've become used to (dependent
on?) in its other language guises. std.recls has stagnated, and when I tried
to use my lib externally the whole thing was a nightmare.
If I, one of D's longest and loudest public supporters, don't use it,
because it's libraries are wanting, or just plain suck, then what chance do
you really think D has of attracting commercial mind-share from the big
successful languages. Let me answer that for you if you've not guessed
already: None.
But hey, that's just one man's opinion. I might be totally wrong. It's only
been 2+ years that people have been voicing these same concerns: look how
far we've come!
Whatever the case, I'd love to hear Walter's strategy for D over the next
five years.
[Now, tiresome as it may be, I have to explicitly state here that I like D
and really want it to succeed - hell, I want to write a book on it! - and
that I consider Walter a friend, respect him, and think he's an obscenely
talented engineer, who's idea's are wont to blow me away or at least make me
go away and emulate them in C++ libs. ;-) He knows that, and most of you
know that, but in times past when I've made critical statements I've had
half the laughing gallery lamely lambast me with comments about "respect"
and "track-record" and other furphys.]

Thus, I do hope you give it some serious consideration.

But if anyone wants to set up a business doing D for embedded systems, I
would be more than happy to supply the compiler.

It's the entire tool-chain that's needed to gain traction ~ not a language
front-end. Of all people, it may be you who's needed to get something off
the ground. I'm sure there's plenty of capable individuals here who'd be
willing to step up and help. What D *really* needs right now is a goal; a
direction; some strategy. If you were to actually set something there, and
commit to it, I think you'd be surprised how quickly others would join up.
It would need to be something concrete ~ with a palatable end-point.

You couldn't be more right. After reading your post I was seeing pictures of
myself with little devices - palms, phones, and whatnot - and I _ain't_ no
hardware biscuit, let me tell you! ;-)

Of course, this whole topic is very much dependent upon how serious one is
about the success of D.

Ouch! I think you should leave the sarcasm to detestable Englishmed. ;-)

It's not "a sound approach". It's _the only_ approach I've heard about D
that doesn't smack of crossed fingers and pipe-dreams. I think it's time
Walter told us what his approach is, cos it sure ain't giving talks to
people who've just been, and will later be, subject to kong-scale
marketing
from soulless corporations, who're drive by _business_ not technology, no
matter how interesting, technically compelling and just plain good/right
they might be.

Amen.

It's the entire tool-chain that's needed to gain traction ~ not a
language
front-end. Of all people, it may be you who's needed to get something off
the ground. I'm sure there's plenty of capable individuals here who'd be
willing to step up and help. What D *really* needs right now is a goal; a
direction; some strategy. If you were to actually set something there,
and
commit to it, I think you'd be surprised how quickly others would join
up.
It would need to be something concrete ~ with a palatable end-point.

You couldn't be more right. After reading your post I was seeing pictures
of
myself with little devices - palms, phones, and whatnot - and I _ain't_ no
hardware biscuit, let me tell you! ;-)

Yeah ~ motivation is a powerful thing. It can seems silly to talk about
having "fun" using one language over another; yet D has that potential in
spades. Especially with tangible devices ~ you can really have fun doing
things that affect people in nice ways. It's a self-perpetuating
progression; and you can earn a nice living from it too :)

Of course, this whole topic is very much dependent upon how serious one
is
about the success of D.

Ouch! I think you should leave the sarcasm to detestable Englishmed. ;-)

True ~ it's perhaps misplaced. Yet there's truth in sarcasm also :: without
a viable strategy, D can be perceived as little more than an elaborate
hobby. Would come as no surprise if that were reflected somewhat in the
reaction from the C++/Java folks. It wouldn't hurt to avoid that pitfall;
detestable Englishmen aside :-)

That's just the problem. If I worked on embedded systems, nothing else
would happen.

Ah yes; the "all or nothing" syndrome :)
This "embedded market" approach is just a notion; take it or leave it.

I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do
anything else" type of response. That's indicative of a knee-jerk reaction
rather than careful thought ~ of course, I could be completely mistaken.
Still, you have to wonder why others feel it would be a sound approach.

It's not "a sound approach". It's _the only_ approach I've heard about D
that doesn't smack of crossed fingers and pipe-dreams. I think it's time
Walter told us what his approach is, cos it sure ain't giving talks to

IMO, a previous post of yours (Matthew) about adding features to the language to
entice programmers away from script languages made at least as much sense to me.
The fastest growing languages over recent years have been scripting languages
(like you mentioned: Perl, PHP, Python, Ruby, JavaScript) and I think a lot of
that is because one can fire up the code editor and knock-out quick utilities,
as you mentioned. In particular Perl and Ruby because of built-in regex. PHP
started as more-or-less a prototyping tool for smallish sites and now look at
it.
If D had a few more script-language like conveniences, then I think many C
developers using shell or Perl for utilities would be impressed if they could
replace both script and C with D..
The shop I'm currently working in uses many scripts that stay around for years.
In typical UNIX fashion, each 'module' is small, standalone and does it's
(single) job well, and is then chained together with others to make a 'program'.
If it's not in ksh or Perl, it's in C for performance reasons, or to most easily
interface with another C library.
For alot of things, D would be the all-around better choice, especially if it
could be comfortably used for 'scripting chores'. What's standing in the way are
things like Perl's built-in regex and nice 'glue' support routines (e.g.:
open(FH,"cut -c1-3 some_data |");while(<FH>){...}). Most of the latter could and
should be provided in libraries though, while I'm coming to believe that maybe
basic regex support would be served well as part of the language.
One other thing about scripts of course is that you fire them up at the
command-line w/o compilation.
I just built a small 'interpreter' that will take a D file prefaced with
'#!/usr/bin/rdmd', compile it and run it.
To really make this work nicely, the compiler would have to ignore any first
line starting with '#!' and would also (ideally) be able to take input from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d
(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script' files (one
problem is that linking with gcc is a bottleneck for single files).
Please excuse my babbling, but I think this is one area (small utilities
initially) where D could catch on with people: "The power of C++, the speed of C
and the convenience of Perl". <g>

If D had a few more script-language like conveniences, then I think many C
developers using shell or Perl for utilities would be impressed if they could
replace both script and C with D..

On the face of it, trying to mix languages from the opposite ends of the
spectrum sounds like dangerous ground :)
[snip]

To really make this work nicely, the compiler would have to ignore any first
line starting with '#!' and would also (ideally) be able to take input from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd

Egad! :)
Is is possible hide that within a comment?
[snip]

Please excuse my babbling, but I think this is one area (small utilities
initially) where D could catch on with people: "The power of C++, the speed of
C
and the convenience of Perl". <g>

And the eyes of a snake :)
It sounds interesting; like a modern-day Rexx perhaps? Yet, though
'auto' is really nice, is it a match for the lax types and late-binding
in a typical scripting environment? Isn't there perhaps some risk of
creating a FrankenD? Or are you thinking of a much more restricted style
of scripting?
Native regular-expressions in D have been visited a number of times, but
I don't think anyone has come up with a really solid approach for it
yet. There's the distinct possiblity of doing so via templates, but that
perhaps wouldn't have the charm or simplicity of a scripting language?
Then there's long unanswered questions about how to handle things like
regex text-folding in unicode ~ toupper() et. al. just don't cut it
anymore, and the rules can become really quite complex. Perhaps building
all that into the language itself (rather than via a configurable
library) ought to raise an eyebrow or two? I mention this because of a
familiarity with ICU.
After that, wouldn't one want to start building, say, the IO system
directly into the language? Or is that stretching the concept?
2 cents;

If D had a few more script-language like conveniences, then I think many C
developers using shell or Perl for utilities would be impressed if they could
replace both script and C with D..

On the face of it, trying to mix languages from the opposite ends of the
spectrum sounds like dangerous ground :)

What's funny is that at my current and previous gigs (everything outside my
workspace has to be ksh, Perl or C and the UNIX platform doesn't support D),
I've found myself typing 'notepad foo.d' when I want a quick prototype of an
algorithm or whatever that doesn't involve regex work.
That's because D arrays, AA's, D strings and things like writefln and
std.file.open() make it quicker to do some things than even Perl - at least in
my case. I'd have a lot easier time convincing current and future co-workers of
the same if some rudimentary search/replace regex stuff was built into the
language, I think.
Imagine demo'ing D (with built-in regex) to a bunch of Perl/C users on an
overhead, and then running a few array and AA benchmarks...

[snip]

To really make this work nicely, the compiler would have to ignore any first
line starting with '#!' and would also (ideally) be able to take input from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd

Egad! :)
Is is possible hide that within a comment?
[snip]

Please excuse my babbling, but I think this is one area (small utilities
initially) where D could catch on with people: "The power of C++, the speed of
C
and the convenience of Perl". <g>

And the eyes of a snake :)
It sounds interesting; like a modern-day Rexx perhaps? Yet, though
'auto' is really nice, is it a match for the lax types and late-binding
in a typical scripting environment? Isn't there perhaps some risk of
creating a FrankenD? Or are you thinking of a much more restricted style
of scripting?

No changes to D except ignoring the first line of a program if the first two
characters are '#!'.
I personally can type 'int var', 'char[] var' or 'int[char[]] var' faster than
that damn $var, var or %var all over the place, when you factor in the extra
time I spend having to go back and prepend [$ %] 1/2 the time <g>
Alot of the Perl I've seen (in shops and even OSS) could often be almost as
easily written in C (not the regex stuff of course), because it doesn't need
Perl's 'dynamism'.

Native regular-expressions in D have been visited a number of times, but
I don't think anyone has come up with a really solid approach for it
yet. There's the distinct possiblity of doing so via templates, but that
perhaps wouldn't have the charm or simplicity of a scripting language?

Yes, I know and it's a tough nut to crack. I'm not sure if the DM regexp lib.
strictly supports PCRE or PERE either, which may be a road-block.
But if the requirements start out with basic search, replace and some form of
paranthesized substring support, then I think that *could* be big (the old 80-20
rule).
I haven't checked out Eric's compile-time regex stuff yet either, and I'm no
regex expert by a long shot, I just get the feeling that there is a market in D
'bridging' the script / compiled gap as best a static compiled language can,
because others don't.
The whole idea is to encourage others to reach for D instead of either Perl or C
for much of what they're doing. Bring the 'cost' (of using D for simple tasks)
down and 'value' (adding native regex + all of D's other features) up until it
meets a break-even. As soon as people start using D for 'throw-away' utilities,
the market is ours (moohuhuhahahaha).

Then there's long unanswered questions about how to handle things like
regex text-folding in unicode ~ toupper() et. al. just don't cut it
anymore, and the rules can become really quite complex. Perhaps building
all that into the language itself (rather than via a configurable
library) ought to raise an eyebrow or two? I mention this because of a
familiarity with ICU.
After that, wouldn't one want to start building, say, the IO system
directly into the language? Or is that stretching the concept?

That would be too far <g> But I've been thinking about how to make it easier to
just open up an editor and start knocking out D code for utility type programs.
One very easy way would be to come up with 'profile imports'. For example:
import std.script;
This would publically include, say, std.stdio, std.file, std.string, std.regexp.
import std.gui; // import the most often used parts of DWT when that's ready
The -H option might even make the extra compile time overhead a break-even (Ha!
I knew I'd squeek that in here somewhere <g>)
- Dave

If D had a few more script-language like conveniences, then I think many C
developers using shell or Perl for utilities would be impressed if they could
replace both script and C with D..

spectrum sounds like dangerous ground :)

What's funny is that at my current and previous gigs (everything outside my
workspace has to be ksh, Perl or C and the UNIX platform doesn't support D),
I've found myself typing 'notepad foo.d' when I want a quick prototype of an
algorithm or whatever that doesn't involve regex work.
That's because D arrays, AA's, D strings and things like writefln and
std.file.open() make it quicker to do some things than even Perl - at least in
my case. I'd have a lot easier time convincing current and future co-workers of
the same if some rudimentary search/replace regex stuff was built into the
language, I think.
Imagine demo'ing D (with built-in regex) to a bunch of Perl/C users on an
overhead, and then running a few array and AA benchmarks...

This is an interesting idea. Since D is generally more productive and
less error-prone than C/C++, it would be a good language for product
demos (where rapid stable development is the crucial factor). And once
D had proven itself in that arena...
D would really need a solid GUI library for this to succeed, but it
sounds like we're on the road to having one.
Sean

No changes to D except ignoring the first line of a program if the first
two
characters are '#!'.

And there's no way to hide that in a comment? I mean, that would be better;
yes ?

I personally can type 'int var', 'char[] var' or 'int[char[]] var' faster
than
that damn $var, var or %var all over the place, when you factor in the
extra
time I spend having to go back and prepend [$ %] 1/2 the time <g>
Alot of the Perl I've seen (in shops and even OSS) could often be almost
as
easily written in C (not the regex stuff of course), because it doesn't
need
Perl's 'dynamism'.

Sounds good.

Native regular-expressions in D have been visited a number of times, but
I don't think anyone has come up with a really solid approach for it
yet. There's the distinct possiblity of doing so via templates, but that
perhaps wouldn't have the charm or simplicity of a scripting language?

Yes, I know and it's a tough nut to crack. I'm not sure if the DM regexp
lib.
strictly supports PCRE or PERE either, which may be a road-block.
But if the requirements start out with basic search, replace and some form
of
paranthesized substring support, then I think that *could* be big (the old
80-20
rule).

Yes; a lot of the scripting simplicity comes from output formatting. You
haven't mentioned 'automatic' conversion of numerics to strings, such as
"int: "~23~", float: "~3.14159; is there a reason for that?

I haven't checked out Eric's compile-time regex stuff yet either, and I'm
no
regex expert by a long shot, I just get the feeling that there is a market
in D
'bridging' the script / compiled gap as best a static compiled language
can,
because others don't.

Yes. To achieve that, I suspect regex would then have to be supported
directly by the lexer as a first class citizen.

The whole idea is to encourage others to reach for D instead of either
Perl or C
for much of what they're doing. Bring the 'cost' (of using D for simple
tasks)
down and 'value' (adding native regex + all of D's other features) up
until it
meets a break-even. As soon as people start using D for 'throw-away'
utilities,
the market is ours (moohuhuhahahaha).

Sometimes anything is better than nothing :~)

Then there's long unanswered questions about how to handle things like
regex text-folding in unicode ~ toupper() et. al. just don't cut it
anymore, and the rules can become really quite complex. Perhaps building
all that into the language itself (rather than via a configurable
library) ought to raise an eyebrow or two? I mention this because of a
familiarity with ICU.
After that, wouldn't one want to start building, say, the IO system
directly into the language? Or is that stretching the concept?

That would be too far <g> But I've been thinking about how to make it
easier to
just open up an editor and start knocking out D code for utility type
programs.
import std.script;
This would publically include, say, std.stdio, std.file, std.string,
std.regexp.

But it's a trap that's easy to fall into :)
For example, the 'automatic' conversions above would probably link directly
to Phobos? That would tends to exclude alternate libraries? The imports you
describe bind directly to Phobos also. That tends to heavily bias the
"scripts" toward a library that many of us feel is 'closed'. Perhaps this
needs to be considered? Some of this could be addressed by Walter leaving
some indirection within the bindings (rather than binding directly to some
'internal-only' label, like the way comparison/equality is performed).
- Kris

No changes to D except ignoring the first line of a program if the first
two
characters are '#!'.

And there's no way to hide that in a comment? I mean, that would be better;
yes ?

You probably already know this, but the '#!' is a token used by the shell
directly:
http://www.tldp.org/LDP/abs/html/sha-bang.html
"The sha-bang ( #!) at the head of a script tells your system that this file
is a set of commands to be fed to the command interpreter indicated. The #! is
actually a two-byte [1] magic number, a special marker that designates a file
type, or in this case an executable shell script (type man magic for more
details on this fascinating topic). Immediately following the sha-bang is a path
name. This is the path to the program that interprets the commands in the
script, whether it be a shell, a programming language, or a utility. This
command interpreter then executes the commands in the script, starting at the
top (line following the sha-bang line), ignoring comments."
So the convention is geared toward sh/bash scripts, is used directly by the
system, so any other grammar has to (unfortunately) follow suit. AFAIK, there's
no getting rid of it.
Of course if the D specification allowed such a directive, convienently named
'!' (*coughwalter?cough*), then there wouldn't be any problem with D shell
scripts being compilable via conventional means. ;)
- Eric Anderton at yahoo

"The sha-bang ( #!) at the head of a script tells your system that this
file
is a set of commands to be fed to the command interpreter indicated. The
#! is
actually a two-byte [1] magic number, a special marker that designates a
file
type, or in this case an executable shell script (type man magic for more
details on this fascinating topic). Immediately following the sha-bang is
a path
name. This is the path to the program that interprets the commands in the
script, whether it be a shell, a programming language, or a utility. This
command interpreter then executes the commands in the script, starting at
the
top (line following the sha-bang line), ignoring comments."
So the convention is geared toward sh/bash scripts, is used directly by
the
system, so any other grammar has to (unfortunately) follow suit. AFAIK,
there's
no getting rid of it.

Thanks, Eric ~ much appreciated. So, what happens when there's a unicode BOM
at the start of the file?

Of course if the D specification allowed such a directive, convienently
named
'!' (*coughwalter?cough*), then there wouldn't be any problem with D shell
scripts being compilable via conventional means. ;)

Of course if the D specification allowed such a directive, convienently
named
'!' (*coughwalter?cough*), then there wouldn't be any problem with D shell
scripts being compilable via conventional means. ;)

Can you expound on that a bit further, please?

Sure! The spec could be expanded by augmenting the "SpecialTokenSequence" which
is only being used for '#line' right now:
SpecialTokenSequence
# line Integer EndOfLine
# line Integer Filespec EndOfLine
# ! Filespec
Filespec
" Characters "
It would be an easy fix. DMD would just throw the filespec out. The real
question here is: is it worth it?
- EricAnderton at yahoo

It would be an easy fix. DMD would just throw the filespec out. The real
question here is: is it worth it?

Well, one concern (that nobody mentioned yet) is that such things are for
*nix only; yes?

As far as the "shebang" line stuff, yes: its *nix specific.
Under Windows, you'd have to configure a file type association to make this
work. As it turns out, those associations happen to apply to files in the shell
as well (under XP or later ... I don't think Win2k does this). Just try
"executing" a .jpg file and you'll see what I mean.
- Eric Anderton at yahoo

It would be an easy fix. DMD would just throw the filespec out. The real
question here is: is it worth it?

Well, one concern (that nobody mentioned yet) is that such things are for
*nix only; yes?

It wouldn't have to be - you (or an installation) could set up a windows
association to '.d' files that would run 'rdmd for windows'. If the '#!' was
there it would run it like linux, otherwise it could complain that it isn't
executable (or it could do more advanced things like look for another
association, like an editor or ide).

Well, one concern (that nobody mentioned yet) is that such things are for
*nix only; yes?

It wouldn't have to be - you (or an installation) could set up a windows
association to '.d' files that would run 'rdmd for windows'. If the '#!'
was
there it would run it like linux, otherwise it could complain that it
isn't
executable (or it could do more advanced things like look for another
association, like an editor or ide).

So, I have .d associated with emacs. I double-click the file and it opens up
in the editor.
How do I resolve that with an association (as described) that tries to
execute the file instead? Doesn't it seem that ".d" is being badly
overloaded here? And, why would I not just compile such a file/script into
an executable in the first place? What is the overriding value in trying to
execute a ".d" ? Are you trying to hide the compiler for some reason?
It seems like a good idea to make D more 'approachable' at the language
level, yet what you describe above appears to cause difficulties instead?
Lots of questions :)

Well, one concern (that nobody mentioned yet) is that such things are for
*nix only; yes?

It wouldn't have to be - you (or an installation) could set up a windows
association to '.d' files that would run 'rdmd for windows'. If the '#!'
was
there it would run it like linux, otherwise it could complain that it
isn't
executable (or it could do more advanced things like look for another
association, like an editor or ide).

So, I have .d associated with emacs. I double-click the file and it opens up
in the editor.
How do I resolve that with an association (as described) that tries to
execute the file instead? Doesn't it seem that ".d" is being badly
overloaded here? And, why would I not just compile such a file/script into
an executable in the first place? What is the overriding value in trying to
execute a ".d" ? Are you trying to hide the compiler for some reason?
It seems like a good idea to make D more 'approachable' at the language
level, yet what you describe above appears to cause difficulties instead?
Lots of questions :)

Well, in that case: just go with ".ds" (or something else) as your extension and
you handily solve the shebang line problem (its now saying that it's special by
name) and the file-type association problem. The downside: you're stepping away
from throwing the file to DMD directly, should you ever want to do that.
- Eric Anderton at yahoo

Well, in that case: just go with ".ds" (or something else) as your
extension and
you handily solve the shebang line problem (its now saying that it's
special by
name) and the file-type association problem. The downside: you're
stepping away
from throwing the file to DMD directly, should you ever want to do that.

Which is why I asked what value there might be in attempting to hide the
compiler. I mean, doesn't the ".exe" extension exist for a reason? Why not
just compile the .d "script" and be done with it?
Please try to forgive my ignorance, but is there something vaguely mystical
here that I just don't get?

Please try to forgive my ignorance, but is there something vaguely mystical
here that I just don't get?

I think the advantage here is that it takes advantage of the same use idiom that
shell scripts do. Both the shebang line (for unix) and a file-type association
(for Win) become a transparent wrapper. But yes, it boils down to a few
keystrokes really - but that's less to screw up, isn't it?
me host> myscript.ds arg1 arg2
-= versus =-
me host> dmdr myscript.ds arg1 arg2
As an exercise in contrast, *right now* you can get *really* close by doing
this:
me host> build myscript.d -silent -run"arg1 arg2"
(or just throw it into a script and leave it on the path somewhere)
The only reason why you wouldn't want to use build in this manner is that it 0)
is fairly verbose 1) likes to drop the executable in the current directory and
2) imports can/will be overridden by files in the current path.
Honestly, I think its a step toward true cross-platform scripting (no more .bat
and .sh files), which would be a very nice addition to our toolchain for D. The
only hard part is standardizing the configuration work, or at a minimum, making
such a task impossible to misconfigure via a utility.
- Eric Anderton at yahoo

As an exercise in contrast, *right now* you can get *really* close by doing
this:
me host> build myscript.d -silent -run"arg1 arg2"
(or just throw it into a script and leave it on the path somewhere)
The only reason why you wouldn't want to use build in this manner is that it 0)
is fairly verbose 1) likes to drop the executable in the current directory and
2) imports can/will be overridden by files in the current path.

Is there any way to override any of this behavior with Build? Line
length really isn't an issue as I'd probably just alias it anyway.
Sean

Sorry for the long post:
"pragma" <pragma_member pathlink.com> wrote...

In article <ds0jm0$qtc$1 digitaldaemon.com>, Kris says...

Please try to forgive my ignorance, but is there something vaguely
mystical
here that I just don't get?

I think the advantage here is that it takes advantage of the same use
idiom that
shell scripts do. Both the shebang line (for unix) and a file-type
association
(for Win) become a transparent wrapper. But yes, it boils down to a few
keystrokes really - but that's less to screw up, isn't it?
me host> myscript.ds arg1 arg2
-= versus =-
me host> dmdr myscript.ds arg1 arg2
As an exercise in contrast, *right now* you can get *really* close by
doing
this:
me host> build myscript.d -silent -run"arg1 arg2"
(or just throw it into a script and leave it on the path somewhere)
The only reason why you wouldn't want to use build in this manner is that
it 0)
is fairly verbose 1) likes to drop the executable in the current directory
and
2) imports can/will be overridden by files in the current path.

The second case is an executable, which doesn't appear to be a burden.
.
I see Ben has just posted something saying that there is some kind of
enormous productivity gain via scripting? This is the part I don't
comprehend at all. If you'll bear with me, let's take an example:
1) I want to write a program/script
2) I open an editor and either crib an existing .d file or create a new one
3) I think about how I'm going to construct this program/script
4) I start typing, think some more, and type some more. Repeat.
5) I exit the editor (or start another console) and run my program/script
6) It doesn't quite do what I expected. I re-open the file and goto #4
7) Eventually it does what I want, and I move onto something else.
Speculatively, how long is the writing/thinking process? 10 minutes perhaps?
2 minutes, if we already know exactly what we want and are intimately
familiar with the language? Let's pick five minutes as a middle ground?
OK. You spend 5 mins typing and thinking. How long does it take to compile a
script file that took 5 minutes to write? One second? a quarter second
perhaps?
You see what I'm getting at? If you eliminate the compile cycle, what
exactly do you gain? Where does this enormous productivity gain come from,
that Ben talks about? (Yes I should ask him that question :-)
~~~~~~~~~~~~
I think there's a few points here that are interesting:
1) Any productivity gain must surely be in the scripting language itself,
and not in simply sidestepping the compile cycle. The D compiler is
exceedingly fast.
2) Any simplification in getting our 5 minute program compiled is surely
handled by Build? You just type "build myfile" and you're done. That's it.
3) The program thus compiled is an independent entity ~ it does not rely on
backward or forward compatability with the "hidden" compiler or libraries.
4) What happens when you need to debug a "script"? Do you have to break out
the compiler and debugger at that point? Learn a different way of doing
things?
~~~~~~~~~~~~
So, while I can clearly see benefits in making the language itself more
"approachable" (such as native regex), the notion of a D script appears to
be something of a hollow promise? It's still just normal D, after all. Yes?
Debugging concerns aside, here's a hypothesis :: productivity gains using a
D "script" (actually, an attempt to hide the compiler) might gain you one
second of time out of five minutes.
Thoughts?

So, while I can clearly see benefits in making the language itself more
"approachable" (such as native regex), the notion of a D script appears to
be something of a hollow promise? It's still just normal D, after all.
Yes?

Compared to a compiled program, a script is:
- Transparent. The user has immediate access to the (current) source which
may or may not be available otherwise.
- Platform independent. A D script on a nfs share could work on both a Sparc
Solaris and a x86 Linux machine for example.
The advantages of a D script would not necessarily be in development time,
but in distribution and being easily customizable by the user.
Regarding development times: small scripts are often coded in different ways
than regular programs. For example, scripts often contain hardcoded paths
and values that the user may need to change. A user can probably make such
changes without needing much (any) knowledge of D and how to invoke a
compiler.
/Oskar

So, while I can clearly see benefits in making the language itself more
"approachable" (such as native regex), the notion of a D script appears to
be something of a hollow promise? It's still just normal D, after all.
Yes?

Compared to a compiled program, a script is:
- Transparent. The user has immediate access to the (current) source which
may or may not be available otherwise.
- Platform independent. A D script on a nfs share could work on both a Sparc
Solaris and a x86 Linux machine for example.
The advantages of a D script would not necessarily be in development time,
but in distribution and being easily customizable by the user.

Thanks; I appreciate the reply, and agree there's some value in the
above. It's just not clear to me how much value is really there (rather
little, on the face of it ~ I mean, sharing a D 'script' between Solaris
and x86 linux is not exactly a wildly predominant activity, is it?)
On the other hand, I can see using this as an argument for sneaking a D
compiler into various standard distributions. Except for one thing: the
D community has zero pull or leverage in terms of making that happen for
the multiple distro's that would be required to make this a turn-key
script-sharing environment. You'll forgive me if I note that the "out of
the box" cross-platform sharing aspect (that Walter pimped earlier)
seems riddled with finger-crossing and hollow-promise?

Regarding development times: small scripts are often coded in different ways
than regular programs. For example, scripts often contain hardcoded paths
and values that the user may need to change. A user can probably make such
changes without needing much (any) knowledge of D and how to invoke a
compiler.

I'd agree on the simplicity aspect, if Build were not available. But
your (valid) argument regarding changes holds perfectly true for Build
also. Delaying (hiding) the compile-cycle does not affect that in any
way. Wouldn't you agree? I mean, if GDC is going to be magically
included in all distro's, then Build can magically be included too.
So why am I troubled by this anyway? Well, it just seems like yet
another typically vague and transparant example of the "clutching at
straws" approach to D adoption.

How do I resolve that with an association (as described) that tries to
execute the file instead? Doesn't it seem that ".d" is being badly
overloaded here? And, why would I not just compile such a file/script into
an executable in the first place? What is the overriding value in trying
to execute a ".d" ? Are you trying to hide the compiler for some reason?
It seems like a good idea to make D more 'approachable' at the language
level, yet what you describe above appears to cause difficulties instead?

I think this is not going to work on Windows for the reasons you mentioned.
It'll work on *nix systems, but that still won't adversely affect Windows.
The reason to have it, where it can be supported, is simply sugar. One file
apps can be distributed as source, and it's not necessary for the user to
worry about compiling them, where to store the executable, what if the
source gets out of sync with the executable, etc. A good implementation can,
as Dave suggested, cache the generated executables so it really is just as
good as compiling them manually. It's cool enough to put the idea in
peoples' minds "why am I using a scripting language instead of D?"

It seems like a good idea to make D more 'approachable' at the language
level, yet what you describe above appears to cause difficulties instead?

I think this is not going to work on Windows for the reasons you
mentioned. It'll work on *nix systems, but that still won't adversely
affect Windows.
The reason to have it, where it can be supported, is simply sugar. One
file apps can be distributed as source, and it's not necessary for the
user to worry about compiling them, where to store the executable, what if
the source gets out of sync with the executable, etc. A good
implementation can, as Dave suggested, cache the generated executables so
it really is just as good as compiling them manually. It's cool enough to
put the idea in peoples' minds "why am I using a scripting language
instead of D?"

OK ~ thanks. Then, if you can, I'd very much appreciate a comment on these
related questions:
* So, what happens when you need to debug? D is hardly immune to such
things.
* What happens when the source gets "out of date" with the hidden compiler
and/or libraries? Couldn't an self-contained executable be considered better
in such cases? Like a statically-linked program can sometimes be better than
one using DLLs instead?
* This would be the only thing in the compiler front-end that is not
platform independent. It that such a good precedent?
* "One file apps" confuses me a bit. I mean, doesn't the user also have to
install GDC, GCC, LIBC, GDB, along with some 'Host' program to compile and
cache results? Won't they also have to manage conflicts between GDC and GCC
versioning?
* Given that the compiler is so darned fast, why not just compile it
immediately anyway? Using "build myscript"?
* Why would someone (who doesn't yet know D) choose to use D for quick,
easy, disposable code when they could use Ruby/Python/Perl etc instead?
* Surely the percentage of such disposable code that actually needs to be
faster than say, Ruby, is rather small?

The reason to have it, where it can be supported, is simply sugar. One
file apps can be distributed as source, and it's not necessary for the
user to worry about compiling them, where to store the executable, what
if the source gets out of sync with the executable, etc. A good
implementation can, as Dave suggested, cache the generated executables so
it really is just as good as compiling them manually. It's cool enough to
put the idea in peoples' minds "why am I using a scripting language
instead of D?"

OK ~ thanks. Then, if you can, I'd very much appreciate a comment on these
related questions:
* So, what happens when you need to debug? D is hardly immune to such
things.

Use the traditional edit/compile/debug cycle on it. This doesn't break that.

* What happens when the source gets "out of date" with the hidden compiler
and/or libraries?

It stops working. (Script engines have exactly the same problem, I know a
programmer who had a lot of grief with perl scripts over this.)

Couldn't an self-contained executable be considered better in such cases?

Absolutely. Interestingly, some script engines have the ability to create
'native' executables by essentially bundling the compiler/interpreter in
with the script into one big file.

Like a statically-linked program can sometimes be better than one using
DLLs instead?

Yes.

* This would be the only thing in the compiler front-end that is not
platform independent. It that such a good precedent?

It's a well established precedent in other scripting languages.

* "One file apps" confuses me a bit. I mean, doesn't the user also have
to install GDC, GCC, LIBC, GDB, along with some 'Host' program to compile
and cache results?

Yes. But gcc, libc, and gdb will already be there. And this will give an
incentive to put gdc into the default distribution so it is always there,
too. It isn't a different problem than script engines already have.

Won't they also have to manage conflicts between GDC and GCC versioning?

Yes, but similar issues exist for Perl and that doesn't seem to have impeded
it.

* Given that the compiler is so darned fast, why not just compile it
immediately anyway? Using "build myscript"?

The fast compiler is what makes this practical. You don't have to manage
.obj and .exe files, nor store them. You're replacing 100Kb files with 1Kb
files.

* Why would someone (who doesn't yet know D) choose to use D for quick,
easy, disposable code when they could use Ruby/Python/Perl etc instead?

Because they don't have to throw away their code and start over in another
language when it exceeds a certain level of complexity or starts having
performance limitations. Lots of sophisticated projects started out as quick
hacks, and just grew. D provides a growth path.

* Surely the percentage of such disposable code that actually needs to be
faster than say, Ruby, is rather small?

The attraction is scalability - you can use one language for small throwaway
scripts and the same language for huge projects. Less learning. (A lot of
people are attracted to Ruby, only to find out that it just doesn't work for
large projects.)

* So, what happens when you need to debug? D is hardly immune to such
things.

Use the traditional edit/compile/debug cycle on it. This doesn't break
that.

* What happens when the source gets "out of date" with the hidden
compiler and/or libraries?

It stops working. (Script engines have exactly the same problem, I know a
programmer who had a lot of grief with perl scripts over this.)

Couldn't an self-contained executable be considered better in such cases?

Absolutely. Interestingly, some script engines have the ability to create
'native' executables by essentially bundling the compiler/interpreter in
with the script into one big file.

Like a statically-linked program can sometimes be better than one using
DLLs instead?

Yes.

* This would be the only thing in the compiler front-end that is not
platform independent. It that such a good precedent?

It's a well established precedent in other scripting languages.

* "One file apps" confuses me a bit. I mean, doesn't the user also have
to install GDC, GCC, LIBC, GDB, along with some 'Host' program to compile
and cache results?

Yes. But gcc, libc, and gdb will already be there. And this will give an
incentive to put gdc into the default distribution so it is always there,
too. It isn't a different problem than script engines already have.

Won't they also have to manage conflicts between GDC and GCC versioning?

Yes, but similar issues exist for Perl and that doesn't seem to have
impeded it.

* Given that the compiler is so darned fast, why not just compile it
immediately anyway? Using "build myscript"?

The fast compiler is what makes this practical. You don't have to manage
.obj and .exe files, nor store them. You're replacing 100Kb files with 1Kb
files.

* Why would someone (who doesn't yet know D) choose to use D for quick,
easy, disposable code when they could use Ruby/Python/Perl etc instead?

Because they don't have to throw away their code and start over in another
language when it exceeds a certain level of complexity or starts having
performance limitations. Lots of sophisticated projects started out as
quick hacks, and just grew. D provides a growth path.

* Surely the percentage of such disposable code that actually needs to be
faster than say, Ruby, is rather small?

The attraction is scalability - you can use one language for small
throwaway scripts and the same language for huge projects. Less learning.
(A lot of people are attracted to Ruby, only to find out that it just
doesn't work for large projects.)

~~~~~~~~~~~~~~~
Since you have an answer for everything, how about this one: <g>
What is the strategic plan for getting D adopted in the commercial
market-place? Can you perhaps talk about 1 year, 3 year, and 5 year
intervals please? If there isn't one, then that's fine too.

* Why would someone (who doesn't yet know D) choose to use D for quick,
easy, disposable code when they could use Ruby/Python/Perl etc instead?

language when it exceeds a certain level of complexity or starts having
performance limitations. Lots of sophisticated projects started out as
quick hacks, and just grew. D provides a growth path.

* Surely the percentage of such disposable code that actually needs to be
faster than say, Ruby, is rather small?

throwaway scripts and the same language for huge projects. Less learning.
(A lot of people are attracted to Ruby, only to find out that it just
doesn't work for large projects.)

~~~~~~~~~~~~~~~
Since you have an answer for everything, how about this one: <g>
What is the strategic plan for getting D adopted in the commercial
market-place? Can you perhaps talk about 1 year, 3 year, and 5 year
intervals please? If there isn't one, then that's fine too.

How do I resolve that with an association (as described) that tries to
execute the file instead? Doesn't it seem that ".d" is being badly
overloaded here? And, why would I not just compile such a file/script into
an executable in the first place? What is the overriding value in trying
to execute a ".d" ? Are you trying to hide the compiler for some reason?
It seems like a good idea to make D more 'approachable' at the language
level, yet what you describe above appears to cause difficulties instead?

I think this is not going to work on Windows for the reasons you mentioned.
It'll work on *nix systems, but that still won't adversely affect Windows.

I think it will instead work. The only precaution being to change the extension
for d script files. Use ".ds" and you win.
Apart from that, I think that having a different extension for D sources
designed to be used as a script is a Good Thing(R).

The reason to have it, where it can be supported, is simply sugar. One file
apps can be distributed as source, and it's not necessary for the user to
worry about compiling them, where to store the executable, what if the
source gets out of sync with the executable, etc. A good implementation can,
as Dave suggested, cache the generated executables so it really is just as
good as compiling them manually.

It was my suggestion, not Dave's.

It's cool enough to put the idea in
peoples' minds "why am I using a scripting language instead of D?"

file
apps can be distributed as source, and it's not necessary for the user to
worry about compiling them, where to store the executable, what if the
source gets out of sync with the executable, etc. A good implementation
can,
as Dave suggested, cache the generated executables so it really is just as
good as compiling them manually.

Well there is an alternative...
1) Begin every D file with a magic sequence like "//-this-is-a-D-script-".
2) Add the magic sequence to "/etc/mime-magic".
3) Add the magic sequence and the script handler to "/etc/mailcap".
The problem: 2) and 3) require root access.

Yes; a lot of the scripting simplicity comes from output formatting. You
haven't mentioned 'automatic' conversion of numerics to strings, such as
"int: "~23~", float: "~3.14159; is there a reason for that?

I'm thinking writefln() et al would take care of quite a bit of that.
Instead of 'print "Sum = $sum\n";' it would be 'writefln("Sum = ",sum);'
23 characters for D, 21 for Perl <g>

But it's a trap that's easy to fall into :)
For example, the 'automatic' conversions above would probably link directly
to Phobos? That would tends to exclude alternate libraries? The imports you
describe bind directly to Phobos also. That tends to heavily bias the
"scripts" toward a library that many of us feel is 'closed'. Perhaps this
needs to be considered? Some of this could be addressed by Walter leaving
some indirection within the bindings (rather than binding directly to some
'internal-only' label, like the way comparison/equality is performed).

Oh, I meant that 'import std.script;' would actually import a file out on disk
in std/script.d:
std/script.d:
-------------
// one could put whatever they want in here, but the
// lib. distro. would have a default good for most
// 'scripting'
import std.stdio, std.file, std.string, std.regexp;
-------------
This wouldn't be any type of compiler intrinsic thing.
Unless you mean things like native regex support - that would just call an ABI
that any new library could plug into like AA's do now?

No changes to D except ignoring the first line of a program if the first two
characters are '#!'.

A thought occurrs... does UNIX check the BOM first? If not, then
Unicode source code could not be coerced into this...

While I'm no Unix hacker, I'd be willing to bet that the check for '#!' is done
in a very binary way: just look at the first two bytes. I say this because I
think it does the same thing to identify *binary* executables as well.
Is there a concession or some kind of short-hand for "write this character as a
single byte" in unicode?
- Eric Anderton at yahoo

No changes to D except ignoring the first line of a program if the first
two
characters are '#!'.

A thought occurrs... does UNIX check the BOM first? If not, then
Unicode source code could not be coerced into this...

While I'm no Unix hacker, I'd be willing to bet that the check for '#!' is
done
in a very binary way: just look at the first two bytes. I say this
because I
think it does the same thing to identify *binary* executables as well.
Is there a concession or some kind of short-hand for "write this character
as a
single byte" in unicode?

Sort of: you'd typically use UTF-8 to eliminate the need for a BOM. But that
precludes saving a file as UTF-16 or UTF-32, which D explicitly supports. It
may not be a major issue, but would certainly cause problems for some folks.
However, UTF-8 files can also have a BOM/signature called UTF-8N. The
signature is "efbbbf" hex. Thus, one cannot rely on any unicode form to
preclude a signature.

To really make this work nicely, the compiler would have to ignore any
first
line starting with '#!' and would also (ideally) be able to take input
from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d

Is that really all that's necessary to make this work, just ignore the first
line with #! ? This is surely a wild idea. I like it.

(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script'
files (one
problem is that linking with gcc is a bottleneck for single files).

To really make this work nicely, the compiler would have to ignore any
first
line starting with '#!' and would also (ideally) be able to take input
from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d

Is that really all that's necessary to make this work, just ignore the first
line with #! ? This is surely a wild idea. I like it.

(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script'
files (one
problem is that linking with gcc is a bottleneck for single files).

True, the gcc linker is painfully slow.

We had a similar conversation over on dsource.org regarding the implications of
having a runtime linker via the DDL project. In theory, your "rdmd" app could
simply take the intermediate output of the compiler (assuming a single script)
and execute it directly. No gcc link needed.
- Eric Anderton at yahoo

To really make this work nicely, the compiler would have to ignore any
first
line starting with '#!' and would also (ideally) be able to take input
from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d

Is that really all that's necessary to make this work, just ignore the first
line with #! ? This is surely a wild idea. I like it.

Yep - the 'input from stdin' thing is not really all that important either,
especially if '#!' is ignored.

(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script'
files (one
problem is that linking with gcc is a bottleneck for single files).

To really make this work nicely, the compiler would have to ignore any
first
line starting with '#!' and would also (ideally) be able to take input
from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d

Is that really all that's necessary to make this work, just ignore the first
line with #! ? This is surely a wild idea. I like it.

Yep - the 'input from stdin' thing is not really all that important either,
especially if '#!' is ignored.

(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script'
files (one
problem is that linking with gcc is a bottleneck for single files).

I just built a small 'interpreter' that will take a D file prefaced with
'#!/usr/bin/rdmd', compile it and run it.

Nice!

To really make this work nicely, the compiler would have to ignore any first
line starting with '#!' and would also (ideally) be able to take input from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d
(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script' files (one
problem is that linking with gcc is a bottleneck for single files).

You can cache compilations using timestamps. The first time you compile the
script and put the binary in some known directory. The second time you pick the
cached executable file, if it's newer than the source, otherwise recompile.

Please excuse my babbling, but I think this is one area (small utilities
initially) where D could catch on with people: "The power of C++, the speed of C
and the convenience of Perl". <g>

I just built a small 'interpreter' that will take a D file prefaced with
'#!/usr/bin/rdmd', compile it and run it.

Nice!

To really make this work nicely, the compiler would have to ignore any first
line starting with '#!' and would also (ideally) be able to take input from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d
(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script' files (one
problem is that linking with gcc is a bottleneck for single files).

You can cache compilations using timestamps. The first time you compile the
script and put the binary in some known directory. The second time you pick the
cached executable file, if it's newer than the source, otherwise recompile.

That was the next step, after I bring in the env for things like /usr/tmp,
etc... <g>
Once I figured out how the shell interprets '#!' it took about 1/2 hour to
actually get something running. I'll persue it more since others seem to think
it's a decent idea (that is, if my wife lets me 'play with my computer' over the
weekend <g>).

Please excuse my babbling, but I think this is one area (small utilities
initially) where D could catch on with people: "The power of C++, the speed of C
and the convenience of Perl". <g>

I just built a small 'interpreter' that will take a D file prefaced with
'#!/usr/bin/rdmd', compile it and run it.

To really make this work nicely, the compiler would have to ignore any first
line starting with '#!' and would also (ideally) be able to take input from
stdin.
example:
hello_script.d:
---------------
#!/usr/bin/rdmd
import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}
# chmod u+x hello_script.d
# hello_script.d
(At any time it could be simply compiled and run, of course).
Since the compiler is so fast, it's feasible for even larger 'script' files
(one
problem is that linking with gcc is a bottleneck for single files).

script and put the binary in some known directory. The second time you pick the
cached executable file, if it's newer than the source, otherwise recompile.

That was the next step, after I bring in the env for things like /usr/tmp,
etc... <g>
Once I figured out how the shell interprets '#!' it took about 1/2 hour to
actually get something running. I'll persue it more since others seem to think
it's a decent idea (that is, if my wife lets me 'play with my computer' over
the
weekend <g>).

Please do. I would love to be able to use D for shell scripting at
work. *sigh* that settles it then... sounds like I'm going to look into
a Solaris port of GDC.
Sean

Once I figured out how the shell interprets '#!' it took about 1/2 hour to
actually get something running. I'll persue it more since others seem to
think
it's a decent idea (that is, if my wife lets me 'play with my computer'
over the
weekend <g>).

One other thing about scripts of course is that you fire them up at the
command-line w/o compilation.
I just built a small 'interpreter' that will take a D file prefaced with
'#!/usr/bin/rdmd', compile it and run it.

I recommend looking at TinyCC http://www.tinycc.org.
It's an embeddable C preprocessor, compiler, and linker that can be used in
scripting mode. I've been using it for my compiler-hacking by aiming in the
exact direction you indicate - make something partly between C and a
scripting language. The benefit of scripting is an amazing productivity
boost. The benefit of C is performance. For example TinyCC can be invoked
using #!
#!/usr/local/bin/tcc -run
#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}

I suppose it's reflective of the mindset here that my first thought was
of GDC. However, is there any barrier to using it for this purpose?
And is the GCC tool-chain sufficient/appealing for embedded development?
Alternately, are there other customizable options in this arena that
could be made into something that doesn't feel like a cobbled together mess?
Sean

I suppose it's reflective of the mindset here that my first thought was of
GDC. However, is there any barrier to using it for this purpose? And is
the GCC tool-chain sufficient/appealing for embedded development?
Alternately, are there other customizable options in this arena that could
be made into something that doesn't feel like a cobbled together mess?

Yeah, I wondered about that also. The problem is the rather poor debugging
tools ~ even by 'embedded' standards. For better or worse, it struck me
that such a project would require some clear direction, concerted effort,
and commitment, from someone widely respected within the D community.
GDC can compile for PocketPC. But it won't get traction without a solid
toolchain.

I suppose it's reflective of the mindset here that my first thought was of
GDC. However, is there any barrier to using it for this purpose? And is
the GCC tool-chain sufficient/appealing for embedded development?
Alternately, are there other customizable options in this arena that could
be made into something that doesn't feel like a cobbled together mess?

Yeah, I wondered about that also. The problem is the rather poor debugging
tools ~ even by 'embedded' standards. For better or worse, it struck me
that such a project would require some clear direction, concerted effort,
and commitment, from someone widely respected within the D community.

Ah. I'd hoped GDB would be usable, perhaps with some additional debug
symbol help from Walter.

GDC can compile for PocketPC. But it won't get traction without a solid
toolchain.

Agreed. I asked mostly because I don't know how deep GNU support for
embedded instruction sets goes.
Sean

I suppose it's reflective of the mindset here that my first thought was
of GDC. However, is there any barrier to using it for this purpose? And
is the GCC tool-chain sufficient/appealing for embedded development?
Alternately, are there other customizable options in this arena that
could be made into something that doesn't feel like a cobbled together
mess?

Yeah, I wondered about that also. The problem is the rather poor
debugging tools ~ even by 'embedded' standards. For better or worse, it
struck me that such a project would require some clear direction,
concerted effort, and commitment, from someone widely respected within
the D community.

Ah. I'd hoped GDB would be usable, perhaps with some additional debug
symbol help from Walter.

I think that would be very useful anyway, Sean (just as it would be for
MSVC).

I suppose it's reflective of the mindset here that my first thought was
of GDC. However, is there any barrier to using it for this purpose? And
is the GCC tool-chain sufficient/appealing for embedded development?
Alternately, are there other customizable options in this arena that
could be made into something that doesn't feel like a cobbled together
mess?

So, here's a bit of (somewhat old) speculation:
* GCC can apparently generate PocketPC compatable code, for ARM/XScale.
David Friedman doesn't feel there'd be huge issues getting GDC to take
advantage of that.
* Microsoft has both emulators and debuggers for these devices. Very good
ones.
Do you think it would be cool to get those working together? And then
promote the heck out of it? I mean, isn't it potentially a better story than
.NET for that market?
Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the WinCE
version of DWT that Shawn has (the WinCE code is a version'd subset of the
Win32 SWT)?
Thoughts?

is the GCC tool-chain sufficient/appealing for embedded development?
Alternately, are there other customizable options in this arena that
could be made into something that doesn't feel like a cobbled together
mess?

So, here's a bit of (somewhat old) speculation:
* GCC can apparently generate PocketPC compatable code, for ARM/XScale.
David Friedman doesn't feel there'd be huge issues getting GDC to take
advantage of that.
* Microsoft has both emulators and debuggers for these devices. Very good
ones.
Do you think it would be cool to get those working together? And then
promote the heck out of it? I mean, isn't it potentially a better story

.NET for that market?
Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the

version of DWT that Shawn has (the WinCE code is a version'd subset of the
Win32 SWT)?
Thoughts?

So, here's a bit of (somewhat old) speculation:
* GCC can apparently generate PocketPC compatable code, for ARM/XScale.
David Friedman doesn't feel there'd be huge issues getting GDC to take
advantage of that.
* Microsoft has both emulators and debuggers for these devices. Very good
ones.
Do you think it would be cool to get those working together? And then
promote the heck out of it? I mean, isn't it potentially a better story than
.NET for that market?

Definately. And with Phoenix now available, this may not be terribly
difficult, though David would be the one to ask here.

Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the WinCE
version of DWT that Shawn has (the WinCE code is a version'd subset of the
Win32 SWT)?

The latter, I think. I'd like to believe a WinCE port of DWT wouldn't
be terribly difficult, and it would be nice to have a consistent API
across platforms.
Sean

So, here's a bit of (somewhat old) speculation:
* GCC can apparently generate PocketPC compatable code, for ARM/XScale.
David Friedman doesn't feel there'd be huge issues getting GDC to take
advantage of that.
* Microsoft has both emulators and debuggers for these devices. Very good
ones.
Do you think it would be cool to get those working together? And then
promote the heck out of it? I mean, isn't it potentially a better story
than .NET for that market?

Definately. And with Phoenix now available, this may not be terribly
difficult, though David would be the one to ask here.

So, I suspect the problem be finding volunteers? I'm afraid I don't have the
requisite knowledge, time, or skills to take this on; much as I'd dearly
love to. It would probably require some debugger support from Walter too, as
you noted earlier.

Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the
WinCE version of DWT that Shawn has (the WinCE code is a version'd subset
of the Win32 SWT)?

The latter, I think. I'd like to believe a WinCE port of DWT wouldn't be
terribly difficult, and it would be nice to have a consistent API across
platforms.

Aye. I think we'd find that Shawns work is already 95% there (he's got
version(wince) in the codebase, where SWT had if(WinCE) instead).

So, here's a bit of (somewhat old) speculation:
* GCC can apparently generate PocketPC compatable code, for ARM/XScale.
David Friedman doesn't feel there'd be huge issues getting GDC to take
advantage of that.
* Microsoft has both emulators and debuggers for these devices. Very good
ones.
Do you think it would be cool to get those working together? And then
promote the heck out of it? I mean, isn't it potentially a better story
than .NET for that market?

Definately. And with Phoenix now available, this may not be terribly
difficult, though David would be the one to ask here.

I hate bursting bubbles but I think Phoenix is a C# API.

So, I suspect the problem be finding volunteers? I'm afraid I don't have the
requisite knowledge, time, or skills to take this on; much as I'd dearly
love to. It would probably require some debugger support from Walter too, as
you noted earlier.

Some GUI would perhaps help? Maybe a DFL for PocketPC? Or perhaps the
WinCE version of DWT that Shawn has (the WinCE code is a version'd subset
of the Win32 SWT)?

The latter, I think. I'd like to believe a WinCE port of DWT wouldn't be
terribly difficult, and it would be nice to have a consistent API across
platforms.

Aye. I think we'd find that Shawns work is already 95% there (he's got
version(wince) in the codebase, where SWT had if(WinCE) instead).

So, here's a bit of (somewhat old) speculation:
* GCC can apparently generate PocketPC compatable code, for
ARM/XScale. David Friedman doesn't feel there'd be huge issues
getting GDC to take advantage of that.
* Microsoft has both emulators and debuggers for these devices. Very
good ones.
Do you think it would be cool to get those working together? And
then promote the heck out of it? I mean, isn't it potentially a
better story than .NET for that market?

Definately. And with Phoenix now available, this may not be terribly
difficult, though David would be the one to ask here.

I hate bursting bubbles but I think Phoenix is a C# API.

Even if it is, it might not be too difficult to create a managed C++
wrapper for the DMD/GDC front-end. Also, the Phoenix docs indicate that
it accepts MSIL, so code-level integration may not be necessary.
Sean

So, here's a bit of (somewhat old) speculation:
* GCC can apparently generate PocketPC compatable code, for
ARM/XScale. David Friedman doesn't feel there'd be huge issues
getting GDC to take advantage of that.
* Microsoft has both emulators and debuggers for these devices.
Very good ones.
Do you think it would be cool to get those working together? And
then promote the heck out of it? I mean, isn't it potentially a
better story than .NET for that market?

Definately. And with Phoenix now available, this may not be
terribly difficult, though David would be the one to ask here.

I hate bursting bubbles but I think Phoenix is a C# API.

Even if it is, it might not be too difficult to create a managed C++
wrapper for the DMD/GDC front-end. Also, the Phoenix docs indicate that
it accepts MSIL, so code-level integration may not be necessary.
Sean

For C++ to Managed C++ conversion, insert __gc before every array
declaration and new operator, basically... I've tried to convert the
most trivial of C applications over to Managed C++ and it was an
absolute nightmare (mostly cuz I didn't get the hang of __gc and __nogc).

For C++ to Managed C++ conversion, insert __gc before every array
declaration and new operator, basically... I've tried to convert the
most trivial of C applications over to Managed C++ and it was an
absolute nightmare (mostly cuz I didn't get the hang of __gc and __nogc).

This is no longer true in VC 2005--the syntax has been changed
completely, and the new syntax is a lot more palatable. However, I
wasn't thinking of converting all of GDC so much as writing a
marshalling layer of sorts. That aside, the MSIL option still holds.
Sean

Hmmm ... I thought it was quite moderate :)
Sure, there's one fool jiving on Z80, but I thought the other comments were
pretty accurate :: it's a step in the right direction, but with no realistic
library (yet), and no *obvious* sign of the backing needed to make an
notable impact.
These are realistic criticisms.
On the other hand, the whole topic is immediately flawed :: it's almost all
about Ruby. Ruby is great for writing throw-away code. Has anyone here
actually tried to use it with say, 20 developers, over a multi-year project?
It's not as though Ruby is actually new ~ been around for years. It's
really, really hard to write large-scale, maintainable code in *any*
scripting language (yes, I know there's one or two household names who use
it ~ but do you also know their pain?)
The point is that Ruby et.al. are designed for scripting ~ a whole different
ballgame than a systems language. One might well argue the pro's and con's
of late- vs early- binding. Instead, I'll just note that Ruby, Perl, Python,
VB, and a slew of others address a conceptually different set of problems
than D. For example, D would be a good language to write a Ruby engine in.
Would Python be an appropriate choice to write a Ruby interpreter? D would
probably be a good choice to write "yet another back-office suite" (think
PeopleSoft, Oracle, SAP :: payroll processing, etc), yet Perl would probably
not be ...
As the industry matures, there's a high likelihood for the balance to shift
between around between different types of languages (between, say, 3G and 4
or 5G). Yet you still have to pick the right tool for the job. Throwaway
code is apparently becoming more and more popular (there's much less
emphasis on long-term maintenance than there used to be), and processors are
bob-awful fast these days compared to what they used to be. Not to mention
the amounts of memory available. Still, another set of killer-apps will
eventually come along that squeezes the hardware once again, and D will be
right there for when that happens (just as C and C++ will be). I mean, we
ain't gonna see a speech-recognition engine written in Ruby ~ at least, not
this decade!
One final thought :: I really think D has the wrong target in mind. Walter
seems to be interested in the desktop/server arena, yet the best place for D
is actually the embedded market instead. We're talking about the most
prevalent computers on the planet ~ they're in washing machines, vaccum
cleaners, cars, ships, TV's, mp3 players, iPod's, cell-phones, blah blah
blah. People don't use C++ there because it's way too bloated. They use C
(and some assembler) because it's lightweight and fits the devices nicely.
It's a huge market, just crying out for an 'upgrade' in terms of a language
as a tool.
This is why I have an interest in getting D running on PocketPC. There's an
enormous potential in the land of cell-phones and, frankly, I rather suspect
that's the general direction of future platforms (as opposed to desktops).
Why bother competing with C++ and/or Java when you can sidestep them (and
all the associated cronyism) completely?

This is why I have an interest in getting D running on PocketPC. There's an
enormous potential in the land of cell-phones and, frankly, I rather suspect
that's the general direction of future platforms (as opposed to desktops).
Why bother competing with C++ and/or Java when you can sidestep them (and
all the associated cronyism) completely?

I thought that the subsets "Embedded C++" and "MicroJava" targeted this,
but I might be wrong. ..(I don't know much if anything about handhelds)
-anders

This is why I have an interest in getting D running on PocketPC. There's
an enormous potential in the land of cell-phones and, frankly, I rather
suspect that's the general direction of future platforms (as opposed to
desktops). Why bother competing with C++ and/or Java when you can
sidestep them (and all the associated cronyism) completely?

I thought that the subsets "Embedded C++" and "MicroJava" targeted this,
but I might be wrong. ..(I don't know much if anything about handhelds)

Embedded C++ seemed like a good idea, and was supported quite well in Japan.
It flopped. I don't think it offered sufficient benefit in order to make a
difference. It also had to drop a lot of things C++ folks were rather used
to: MI, op-overloads, etc. C++ just seems to be unsuitable for a variety of
reasons ~ both objective and subjective. That leaves an opportunity.
The various Java platforms are great on paper. J2ME has reasonable support
these days (I can write and dowload Java onto my phone; use it to interact
with a server), and the 'profiles' are becoming more capable. Performance is
seriously lacking though ~ operates like a scritping environment. You ain't
gonna' do any signal processing with it, and the 'integration' with other
facilities of the device are always 2 or 3 years behind the curve (e.g. you
still can't read a cellphone mailbox via Java).
For some reason or other, the old ARM10 hardware-support for Java didn't
take off at all.

This is why I have an interest in getting D running on PocketPC. There's
an enormous potential in the land of cell-phones and, frankly, I rather
suspect that's the general direction of future platforms (as opposed to
desktops). Why bother competing with C++ and/or Java when you can
sidestep them (and all the associated cronyism) completely?

I thought that the subsets "Embedded C++" and "MicroJava" targeted this,
but I might be wrong. ..(I don't know much if anything about handhelds)

Embedded C++ seemed like a good idea, and was supported quite well in Japan.
It flopped. I don't think it offered sufficient benefit in order to make a
difference. It also had to drop a lot of things C++ folks were rather used
to: MI, op-overloads, etc. C++ just seems to be unsuitable for a variety of
reasons ~ both objective and subjective. That leaves an opportunity.
The various Java platforms are great on paper. J2ME has reasonable support
these days (I can write and dowload Java onto my phone; use it to interact
with a server), and the 'profiles' are becoming more capable. Performance is
seriously lacking though ~ operates like a scritping environment. You ain't
gonna' do any signal processing with it,

I made a J2ME edge-detector and although it isn't that fast it works at
maybe 0.5 fps. Mobile phones are getting more and more powerfull so
maybe performance is going to be less an isue in time.

and the 'integration' with other
facilities of the device are always 2 or 3 years behind the curve (e.g. you
still can't read a cellphone mailbox via Java).
For some reason or other, the old ARM10 hardware-support for Java didn't
take off at all.

I thought that the subsets "Embedded C++" and "MicroJava" targeted this,
but I might be wrong. ..(I don't know much if anything about handhelds)

Embedded C++ seemed like a good idea, [...]
The various Java platforms are great on paper. [...]

OK, thanks for explaining that and offering some background !
(last "handheld" that I had was a calculator, back in school)
Guess I was a little wondering if you felt that D should
change directions - or if it could be used for both regular
desktop programming (e.g. similar to how I use it occasionally)
as well as prove a perhaps more "commercial" handheld language ?
I'm basically using D as something "between C and Java" myself,
out of a long-going disliking to just giving up and using C++.
And while I still play with D and hope that it will "work out",
I still have to use C++ (or Objective-C) at the end of the day.
Right now I'm shoveling some old PHP and Perl though... :-P
--anders

Guess I was a little wondering if you felt that D should
change directions - or if it could be used for both regular
desktop programming (e.g. similar to how I use it occasionally)
as well as prove a perhaps more "commercial" handheld language ?

A changing of direction would pre-suppose an existing one ;-)
Seriously, what interests me is setting a strategic gameplan for D gaining
real-world traction. As Matthew noted, there's been little more than some
vague finger-crossing and fluffly-wishing thus far. My interest is purely
selfish ~ I want D to become a legitimate option in the commercial sector
because it's simply a more advanced tool for the kind of work I'm involved
in.
To that end, I (strongly) suspect that getting a toehold ~ perhaps even a
foothold ~ in a potentially D-friendly market sector would be of notable
benefit to further market penetration. Taking on the (thus far unfriendly)
desktop/server sector with nothing but a hope, a prayer, and Phobos would
not exactly be the most convincing proposal I've heard. But then, there have
been no proposals. And, unless I missed it, there is no visible
market-adoption strategy of any description for D.

I'm basically using D as something "between C and Java" myself,
out of a long-going disliking to just giving up and using C++.
And while I still play with D and hope that it will "work out",
I still have to use C++ (or Objective-C) at the end of the day.

D has real potential to be an accepted/legitimate option. But it's not going
to happen without effort and direction. I'd like to see that change for the
better.
The embedded market is but one option. How about some additional
suggestions?

Yeah,
but direction happens anyway without pointing. Like through actions ?
But it's a lot harder to read between the lines than from the lines...

Seriously, what interests me is setting a strategic gameplan for D gaining
real-world traction. As Matthew noted, there's been little more than some
vague finger-crossing and fluffly-wishing thus far. My interest is purely
selfish ~ I want D to become a legitimate option in the commercial sector
because it's simply a more advanced tool for the kind of work I'm involved
in.

I'm using it for myself and as an alternative in a free software world.
Currently I do not offer any commercial D packages, they're all gratis.
--anders

Seriously, what interests me is setting a strategic gameplan for D
gaining real-world traction. As Matthew noted, there's been little
more than some vague finger-crossing and fluffly-wishing thus far. My
interest is purely selfish ~ I want D to become a legitimate option in
the commercial sector because it's simply a more advanced tool for the
kind of work I'm involved in.

I'm using it for myself and as an alternative in a free software world.
Currently I do not offer any commercial D packages, they're all gratis.

I hope you misunderstood me on that one ~ I didn't mean any commercial
stuff that I might have personally (all my code is gratis too). Instead
I meant using D as a recognized and valid alternative for
C++/ObjectiveC/Java within the place where I work. I don't care much for
those, so it would be nice to legitimally use D in the workplace instead.

I hope you misunderstood me on that one ~ I didn't mean any commercial
stuff that I might have personally (all my code is gratis too). Instead
I meant using D as a recognized and valid alternative for
C++/ObjectiveC/Java within the place where I work. I don't care much for
those, so it would be nice to legitimally use D in the workplace instead.

No, I don't think I did... Just that I'm using Perl/PHP "commercially"
at the moment and don't have any non-hobby projects going, D-suitable.
I've always found that companies make their decisions on non-technical
grounds, so maybe D just needs some better marketing. Or a new name :-)
Anyway, my vague point was that right now I am doing this for myself.
Whether or not it (D) will become a legitimate option in the commercial
sector is not something that I worry about. Seems to be all .NET anyway.
But I would of course also *like* seeing D become a valid alternative !
--anders

I hope you misunderstood me on that one ~ I didn't mean any commercial
stuff that I might have personally (all my code is gratis too).
Instead I meant using D as a recognized and valid alternative for
C++/ObjectiveC/Java within the place where I work. I don't care much
for those, so it would be nice to legitimally use D in the workplace
instead.

No, I don't think I did... Just that I'm using Perl/PHP "commercially"
at the moment and don't have any non-hobby projects going, D-suitable.

OK ... just clarifying :)

I've always found that companies make their decisions on non-technical
grounds, so maybe D just needs some better marketing. Or a new name :-)

You know, a better name really might help :-)

Anyway, my vague point was that right now I am doing this for myself.
Whether or not it (D) will become a legitimate option in the commercial
sector is not something that I worry about. Seems to be all .NET anyway.

Yeah. The .net thing is too bad ~ it has its place like every other
tool, but the corporate view can be that it's a "garden of sweetness
and light", guaranteed to whisk one's IT cares away with a comforting
wisp of lemon scent. Or something like that.

But I would of course also *like* seeing D become a valid alternative !
--anders

I've always found that companies make their decisions on non-technical
grounds, so maybe D just needs some better marketing. Or a new name :-)

You know, a better name really might help :-)

I wasn't thinking "better". I was thinking something more shiny/sparkly.
But we can't blame Walter for the name, he wanted something more spacey.

Yeah. The .net thing is too bad ~ it has its place like every other
tool, but the corporate view can be that it's a "garden of sweetness
and light", guaranteed to whisk one's IT cares away with a comforting
wisp of lemon scent. Or something like that.

Yeah. The .net thing is too bad ~ it has its place like every other
tool, but the corporate view can be that it's a "garden of sweetness
and light", guaranteed to whisk one's IT cares away with a comforting
wisp of lemon scent. Or something like that.

That explains why the last place I worked where .NET was the adopted new
platform of choice (back in the .NET Beta-1 days), management had these wild
expressions on their faces. Now I'm pretty much convinced that they must've
been huffing the code samples and press releases.
Good times.
- Eric Anderton at yahoo

Yeah. The .net thing is too bad ~ it has its place like every other
tool, but the corporate view can be that it's a "garden of sweetness
and light", guaranteed to whisk one's IT cares away with a comforting
wisp of lemon scent. Or something like that.

That explains why the last place I worked where .NET was the adopted new
platform of choice (back in the .NET Beta-1 days), management had these wild
expressions on their faces. Now I'm pretty much convinced that they must've
been huffing the code samples and press releases.

heh, same here pretty much. Microsoft passes it around and everyone
smokes it, next thing you know management is insisting on a .NET
initiative. Thank goodness I develop on Solaris.
Sean

I wouldn't mind if Walter decided to concentrate on embedded devices, as
long as D 1.0 is released first. Otherwise we'll be stuck with a beta
language for a long time. :'(
~ Clay
Kris wrote:

"pragma" <pragma_member pathlink.com> wrote..

Wow. The feedback to those D posts is.. erm.. brutal.

Hmmm ... I thought it was quite moderate :)
Sure, there's one fool jiving on Z80, but I thought the other comments were
pretty accurate :: it's a step in the right direction, but with no realistic
library (yet), and no *obvious* sign of the backing needed to make an
notable impact.
These are realistic criticisms.
On the other hand, the whole topic is immediately flawed :: it's almost all
about Ruby. Ruby is great for writing throw-away code. Has anyone here
actually tried to use it with say, 20 developers, over a multi-year project?
It's not as though Ruby is actually new ~ been around for years. It's
really, really hard to write large-scale, maintainable code in *any*
scripting language (yes, I know there's one or two household names who use
it ~ but do you also know their pain?)
The point is that Ruby et.al. are designed for scripting ~ a whole different
ballgame than a systems language. One might well argue the pro's and con's
of late- vs early- binding. Instead, I'll just note that Ruby, Perl, Python,
VB, and a slew of others address a conceptually different set of problems
than D. For example, D would be a good language to write a Ruby engine in.
Would Python be an appropriate choice to write a Ruby interpreter? D would
probably be a good choice to write "yet another back-office suite" (think
PeopleSoft, Oracle, SAP :: payroll processing, etc), yet Perl would probably
not be ...
As the industry matures, there's a high likelihood for the balance to shift
between around between different types of languages (between, say, 3G and 4
or 5G). Yet you still have to pick the right tool for the job. Throwaway
code is apparently becoming more and more popular (there's much less
emphasis on long-term maintenance than there used to be), and processors are
bob-awful fast these days compared to what they used to be. Not to mention
the amounts of memory available. Still, another set of killer-apps will
eventually come along that squeezes the hardware once again, and D will be
right there for when that happens (just as C and C++ will be). I mean, we
ain't gonna see a speech-recognition engine written in Ruby ~ at least, not
this decade!
One final thought :: I really think D has the wrong target in mind. Walter
seems to be interested in the desktop/server arena, yet the best place for D
is actually the embedded market instead. We're talking about the most
prevalent computers on the planet ~ they're in washing machines, vaccum
cleaners, cars, ships, TV's, mp3 players, iPod's, cell-phones, blah blah
blah. People don't use C++ there because it's way too bloated. They use C
(and some assembler) because it's lightweight and fits the devices nicely.
It's a huge market, just crying out for an 'upgrade' in terms of a language
as a tool.
This is why I have an interest in getting D running on PocketPC. There's an
enormous potential in the land of cell-phones and, frankly, I rather suspect
that's the general direction of future platforms (as opposed to desktops).
Why bother competing with C++ and/or Java when you can sidestep them (and
all the associated cronyism) completely?

I've just read the slashdot article now (long after the discussion has died out
there), and I have to say I didn't think it was anything near "brutal" :)
Comparing to comments I've seen about D om /. earlier, I was rather pleasantly
surprised by the comments that got modded up. I think a reader with no prior
knowledge of D would be left with an overall positive impression.
And while I don't necessarily believe that "all PR is good PR", I think that
every time D gets mentioned on /. some readers will click the link and check out
the docs, and a few will download and try the compiler. And once they're HOOKED,
there's no turning back ;-)
Nick
In article <drr58d$21j0$1 digitaldaemon.com>, pragma says...

I've just read the slashdot article now (long after the discussion has died out
there), and I have to say I didn't think it was anything near "brutal" :)
Comparing to comments I've seen about D om /. earlier, I was rather pleasantly
surprised by the comments that got modded up.

For what its worth: I got into that thread a little early (before it was even
mentioned here), and saw how things were going. There were a bunch of trolls
and knee-jerk reactions to the D-based posts. It was my gut feeling that things
were going to snowball in that direction. I'm glad to see they didn't. :)

I think a reader with no prior
knowledge of D would be left with an overall positive impression.