www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - slashdot: beyond java

reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
Slashdot have just posted a story called beyond Java

http://books.slashdot.org/article.pl?sid=06/02/01/1455213
Feb 01 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
=?iso-8859-1?q?Knud_S=F8rensen?= says...

Slashdot have just posted a story called beyond Java

http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

Gotta love Slashdot.

- Eric Anderton at yahoo
Feb 01 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


 
 Wow.  The feedback to those D posts is.. erm.. brutal.
 
 Gotta love Slashdot.
 
 - Eric Anderton at yahoo


The question for us is, what "killer app" are we going to produce as a
community.
Feb 01 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <drr6qr$25q6$1 digitaldaemon.com>, Kyle Furlong says...

pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


 
 Wow.  The feedback to those D posts is.. erm.. brutal.
 
 Gotta love Slashdot.
 
 - Eric Anderton at yahoo


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
Feb 01 2006
next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
pragma wrote:

 In article <drr6qr$25q6$1 digitaldaemon.com>, Kyle Furlong says...

 pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

 Gotta love Slashdot.

 - Eric Anderton at yahoo


 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 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
Feb 01 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Jari-Matti Mäkelä wrote:

 pragma wrote:

 In article <drr6qr$25q6$1 digitaldaemon.com>, Kyle Furlong says...

 pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

 Gotta love Slashdot.

 - Eric Anderton at yahoo


 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 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?
Feb 01 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Kyle Furlong wrote:

 Jari-Matti Mäkelä wrote:

 pragma wrote:

 In article <drr6qr$25q6$1 digitaldaemon.com>, Kyle Furlong says...

 pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

 Gotta love Slashdot.

 - Eric Anderton at yahoo


 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 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
Feb 02 2006
prev sibling next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
pragma wrote:

 In article <drr6qr$25q6$1 digitaldaemon.com>, Kyle Furlong says...

 pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

 Gotta love Slashdot.

 - Eric Anderton at yahoo


 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


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?
Feb 01 2006
parent pragma <pragma_member pathlink.com> writes:
In article <drrmca$2nds$2 digitaldaemon.com>, Kyle Furlong says...

pragma wrote:

 In article <drr6qr$25q6$1 digitaldaemon.com>, Kyle Furlong says...

 pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

 Gotta love Slashdot.

 - Eric Anderton at yahoo


 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


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
Feb 02 2006
prev sibling parent "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote ...

 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.
Feb 01 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
In article <drr6qr$25q6$1 digitaldaemon.com>, Kyle Furlong says...

pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


 
 Wow.  The feedback to those D posts is.. erm.. brutal.
 
 Gotta love Slashdot.
 
 - Eric Anderton at yahoo


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.
Feb 01 2006
prev sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Kyle Furlong wrote:

 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?
Feb 02 2006
prev sibling next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message
news:drr58d$21j0$1 digitaldaemon.com...

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

Slashdot have just posted a story called beyond Java

http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

 Gotta love Slashdot.


Yes, but that also presents us with an opportunity. We can leave feedback as
well to correct misinformation.
Feb 01 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
pragma wrote:

 In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

 Slashdot have just posted a story called beyond Java

 http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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


Not sure why that one post was modded to 5/funny, but the feedback I've 
seen appears to be mostly positive.  I'm ignoring the troll who 
mentioned Z-80 assembler because, well, he's a troll ;-)


Sean
Feb 01 2006
prev sibling next sibling parent reply "Kris" <fu bar.com> writes:
"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?
Feb 01 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
I think you should post that on slashdot as well!
Feb 01 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 I think you should post that on slashdot as well! 


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
Feb 01 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:drrrlt$2rb4$1 digitaldaemon.com...

 Walter Bright wrote:

 I think you should post that on slashdot as well!


 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.
Feb 01 2006
prev sibling parent reply kris <fu bar.org> writes:
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>
Feb 02 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
kris wrote:

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


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?
Feb 02 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kyle Furlong wrote:


 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
Feb 02 2006
prev sibling next sibling parent reply "Matthew" <matthew stlsoft.com> writes:
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>
Feb 02 2006
parent reply Dave <Dave_member pathlink.com> writes:
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>

- 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


"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>
Feb 02 2006
parent reply "Kris" <fu bar.com> writes:
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 :)





 - Dave


"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>
Feb 02 2006
parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
 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 ...)


You wuh lucky you 'ad feet. We only 'ad stale bread to walk on.
Feb 02 2006
parent "Kris" <fu bar.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote .

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


 You wuh lucky you 'ad feet. We only 'ad stale bread to walk on.


Yew 'ad Bread?! Oooh, we yoost to dreeeeeem o' 'avin Bread ...
Feb 02 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
kris wrote:

 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.


My response to your last post got lost somehow, so I'd just like to 
chime in again for the first time and say that I agree completely :-)


Sean
Feb 02 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <drsfap$7bk$1 digitaldaemon.com>, kris says...

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
Feb 02 2006
parent "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote ..

 In article <drsfap$7bk$1 digitaldaemon.com>, kris says...

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.
Feb 02 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
kris wrote:

 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>


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).
Feb 02 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:drt6aq$q0p$1 digitaldaemon.com...

 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.
Feb 02 2006
parent reply "Kris" <fu bar.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote


 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.
Feb 02 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 2 Feb 2006 11:43:01 -0800, Kris <fu bar.com> wrote:

 "Walter Bright" <newshound digitalmars.com> wrote


 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
Feb 02 2006
parent reply "Kris" <fu bar.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote ..

 How many different architectures are there in embedded programming?


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 :)
Feb 02 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 2 Feb 2006 13:34:58 -0800, Kris <fu bar.com> wrote:

 "Regan Heath" <regan netwin.co.nz> wrote ..

 How many different architectures are there in embedded programming?


 That's hardly relevant, given prior comments; but I'll entertain you  
 anyway:


<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
Feb 02 2006
parent reply "Kris" <fu bar.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote ...

 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.
Feb 02 2006
parent "Regan Heath" <regan netwin.co.nz> writes:
I have no desire to continue this discussion. Thanks for your thoughts.

Regan
Feb 02 2006
prev sibling next sibling parent reply "Matthew" <matthew hat.stlsoft.dot.org> writes:
"Kris" <fu bar.com> wrote in message news:drtnc5$1ar4$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote


 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.


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. ;-)
Feb 02 2006
next sibling parent pragma <pragma_member pathlink.com> writes:
[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...

"Kris" <fu bar.com> wrote in message news:drtnc5$1ar4$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote


 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.


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


- Eric Anderton at yahoo
Feb 02 2006
prev sibling next sibling parent "Kris" <fu bar.com> writes:
"Matthew" <matthew hat.stlsoft.dot.org> wrote ...

 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 :-)
Feb 02 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <drtrho$1f1u$1 digitaldaemon.com>, Matthew says...

"Kris" <fu bar.com> wrote in message news:drtnc5$1ar4$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote


 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.


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


To really make this work nicely, the compiler would have to ignore any first

stdin.

example:

hello_script.d:
---------------

import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}




(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>
Feb 02 2006
next sibling parent reply kris <fu bar.org> writes:
Dave wrote:

 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

 stdin.
 
 example:
 
 hello_script.d:
 ---------------



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;
Feb 03 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <drv4st$2bif$1 digitaldaemon.com>, kris says...

Dave wrote:

 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

 stdin.
 
 example:
 
 hello_script.d:
 ---------------



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


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
Feb 03 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Dave wrote:

 In article <drv4st$2bif$1 digitaldaemon.com>, kris says...

 Dave wrote:

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


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
Feb 03 2006
prev sibling next sibling parent reply "Kris" <fu bar.com> writes:
"Dave" <Dave_member pathlink.com> wrote...

 No changes to D except ignoring the first line of a program if the first 
 two



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
Feb 03 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <ds09nc$hpo$1 digitaldaemon.com>, Kris says...

"Dave" <Dave_member pathlink.com> wrote...

 No changes to D except ignoring the first line of a program if the first 
 two



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



directly:

http://www.tldp.org/LDP/abs/html/sha-bang.html



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
Feb 03 2006
parent reply "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> ...



 directly:

 http://www.tldp.org/LDP/abs/html/sha-bang.html



I guessed so, but was hoping there'd be an alternative?




 file
 is a set of commands to be fed to the command interpreter indicated. The 

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



Can you expound on that a bit further, please?
Feb 03 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <ds0bh0$jiv$1 digitaldaemon.com>, Kris says...

 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




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
Feb 03 2006
parent reply "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote om...
[snip]

 SpecialTokenSequence




 Filespec
 " Characters "



Again, thanks.



 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?
Feb 03 2006
next sibling parent pragma <pragma_member pathlink.com> writes:
In article <ds0dut$le6$1 digitaldaemon.com>, Kris says...

"pragma" <pragma_member pathlink.com> wrote om...
[snip]

 SpecialTokenSequence




 Filespec
 " Characters "



Again, thanks.



 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
Feb 03 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <ds0dut$le6$1 digitaldaemon.com>, Kris says...

"pragma" <pragma_member pathlink.com> wrote om...
[snip]

 SpecialTokenSequence




 Filespec
 " Characters "



Again, thanks.



 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

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).
Feb 03 2006
parent reply "Kris" <fu bar.com> writes:
"Dave" <Dave_member pathlink.com> wrote


 In article <ds0dut$le6$1 digitaldaemon.com>, Kris says...

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

 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 :)
Feb 03 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <ds0hpf$p5m$1 digitaldaemon.com>, Kris says...

"Dave" <Dave_member pathlink.com> wrote


 In article <ds0dut$le6$1 digitaldaemon.com>, Kris says...

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

 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
Feb 03 2006
parent reply "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote ...

 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?
Feb 03 2006
parent reply pragma <pragma_member pathlink.com> writes:
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.

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
Feb 03 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
pragma wrote:

 
 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
Feb 03 2006
prev sibling parent reply "Kris" <fu bar.com> writes:
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.



Yes, I see that. But what's the difference here:


 me host> myscript.ds arg1 arg2

 -= versus =-

 me host> myscript arg1 arg2


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

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?
Feb 03 2006
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
Hi,

Kris wrote:

[snip]


 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
Feb 04 2006
parent kris <fu bar.org> writes:
Oskar Linde wrote:

 Hi,
 
 Kris wrote:
 
 [snip]
 
 

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.
Feb 04 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kris" <fu bar.com> wrote in message news:ds0hpf$p5m$1 digitaldaemon.com...

 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?"
Feb 03 2006
next sibling parent reply "Kris" <fu bar.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote ...

 "Kris" <fu bar.com> wrote ...

 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?
Feb 03 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kris" <fu bar.com> wrote in message news:ds14ir$16fn$1 digitaldaemon.com...

 "Walter Bright" <newshound digitalmars.com> wrote ...

 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.)
Feb 03 2006
parent reply "Kris" <fu bar.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote

 * 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.
Feb 03 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Kris wrote:

 "Walter Bright" <newshound digitalmars.com> wrote

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


I'm also very interested in a response to this query.
Feb 03 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Kris" <fu bar.com> wrote in message news:ds183t$18j6$1 digitaldaemon.com...

 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.


The plan is to continue to expand its appeal by expanding its capabilities, 
and to continue to flog it at every opportunity.
Feb 03 2006
prev sibling parent reply Roberto Martiottini <Roberto_member pathlink.com> writes:
In article <ds0qi1$1050$1 digitaldaemon.com>, Walter Bright says...

"Kris" <fu bar.com> wrote in message news:ds0hpf$p5m$1 digitaldaemon.com...

 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?" 


Yes!

Ciao

---
http://www.mariottini.net/roberto/
Feb 06 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Roberto Martiottini" <Roberto_member pathlink.com> wrote in message 
news:ds70b2$2ca8$1 digitaldaemon.com...

 In article <ds0qi1$1050$1 digitaldaemon.com>, Walter Bright says...


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.


Ah, my mistake. Thank you for the correction.
Feb 06 2006
prev sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kris schrieb am 2006-02-03:

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



 directly:

 http://www.tldp.org/LDP/abs/html/sha-bang.html



 I guessed so, but was hoping there'd be an alternative?


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.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFD5Jrn3w+/yD4P9tIRAkbrAKCNpIDZFazQwjz1PHBADRF7Xfm2VACeKghG
pcrlUlSD4I2JY83JJRwhS9E=
=X716
-----END PGP SIGNATURE-----
Feb 04 2006
parent kris <fu bar.org> writes:
Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Kris schrieb am 2006-02-03:
 

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




directly:

http://www.tldp.org/LDP/abs/html/sha-bang.html



I guessed so, but was hoping there'd be an alternative?


 
 
 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.


Ah; thanks
Feb 04 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
In article <ds09nc$hpo$1 digitaldaemon.com>, Kris says...

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>


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


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?


- Kris
Feb 03 2006
prev sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Dave wrote:
[snip]

 
 
 No changes to D except ignoring the first line of a program if the first two

 


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

[snip]


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne
Feb 03 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
James Dunne wrote:


 Dave wrote:
 [snip]

 
 
 No changes to D except ignoring the first line of a program if the first

 


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


I would be surprised if it didn't, most shells are really unicode aware.
Feb 03 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Dunne wrote:


 No changes to D except ignoring the first line of a program if the 



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


UTF-8 doesn't need a BOM, which is what makes it nice for such things.

--anders
Feb 03 2006
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <ds0cfe$k9u$1 digitaldaemon.com>, James Dunne says...

Dave wrote:
[snip]

 
 
 No changes to D except ignoring the first line of a program if the first two

 


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



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
Feb 03 2006
parent "Kris" <fu bar.com> writes:
"pragma" <pragma_member pathlink.com> wrote...

 In article <ds0cfe$k9u$1 digitaldaemon.com>, James Dunne says...

Dave wrote:
[snip]

 No changes to D except ignoring the first line of a program if the first 
 two



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



 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.
Feb 03 2006
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:druv9v$27p3$1 digitaldaemon.com...

 To really make this work nicely, the compiler would have to ignore any 
 first

 from
 stdin.

 example:

 hello_script.d:
 ---------------

 import std.stdio;
 int main()
 {
 writefln("Hello (pseudo) scripting world");
 }





Is that really all that's necessary to make this work, just ignore the first 




 (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.
Feb 03 2006
next sibling parent Thomas <Thomas_member pathlink.com> writes:
In article <drv7gb$2d4c$1 digitaldaemon.com>, Walter Bright says...

"Dave" <Dave_member pathlink.com> wrote in message 
news:druv9v$27p3$1 digitaldaemon.com...

 To really make this work nicely, the compiler would have to ignore any 
 first

 from
 stdin.

 example:

 hello_script.d:
 ---------------

 import std.stdio;
 int main()
 {
 writefln("Hello (pseudo) scripting world");
 }





Is that really all that's necessary to make this work, just ignore the first 



Yes

Thomas
Feb 03 2006
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <drv7gb$2d4c$1 digitaldaemon.com>, Walter Bright says...

 (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
Feb 03 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <drv7gb$2d4c$1 digitaldaemon.com>, Walter Bright says...

"Dave" <Dave_member pathlink.com> wrote in message 
news:druv9v$27p3$1 digitaldaemon.com...

 To really make this work nicely, the compiler would have to ignore any 
 first

 from
 stdin.

 example:

 hello_script.d:
 ---------------

 import std.stdio;
 int main()
 {
 writefln("Hello (pseudo) scripting world");
 }





Is that really all that's necessary to make this work, just ignore the first 



Yep - the 'input from stdin' thing is not really all that important either,



 (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.
Feb 03 2006
parent Dave <Dave_member pathlink.com> writes:
In article <ds03v0$dcl$1 digitaldaemon.com>, Dave says...

In article <drv7gb$2d4c$1 digitaldaemon.com>, Walter Bright says...

"Dave" <Dave_member pathlink.com> wrote in message 
news:druv9v$27p3$1 digitaldaemon.com...

 To really make this work nicely, the compiler would have to ignore any 
 first

 from
 stdin.

 example:

 hello_script.d:
 ---------------

 import std.stdio;
 int main()
 {
 writefln("Hello (pseudo) scripting world");
 }





Is that really all that's necessary to make this work, just ignore the first 



Yep - the 'input from stdin' thing is not really all that important either,



BTW - Things like this will work too:


import std.stdio;
void main()
{
version(Howdy)
writefln("Howdy (pseudo) scripting world");
else
writefln("Hello (pseudo) scripting world");
}


 (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.
Feb 03 2006
prev sibling next sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <druv9v$27p3$1 digitaldaemon.com>, Dave says...


[...]

I just built a small 'interpreter' that will take a D file prefaced with



Nice!


To really make this work nicely, the compiler would have to ignore any first

stdin.

example:

hello_script.d:
---------------

import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}




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


Indeed.

Ciao

http://www.mariottini.net/roberto/



 Feb 03 2006



  parent reply Dave <Dave_member pathlink.com>  writes:


In article <drve1c$2it4$1 digitaldaemon.com>, Roberto Mariottini says...

In article <druv9v$27p3$1 digitaldaemon.com>, Dave says...


[...]

I just built a small 'interpreter' that will take a D file prefaced with



Nice!


To really make this work nicely, the compiler would have to ignore any first

stdin.

example:

hello_script.d:
---------------

import std.stdio;
int main()
{
writefln("Hello (pseudo) scripting world");
}




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


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>


Indeed.

Ciao

http://www.mariottini.net/roberto/





 Feb 03 2006



 next sibling parent reply Sean Kelly <sean f4.ca>  writes:


Dave wrote:

 In article <drve1c$2it4$1 digitaldaemon.com>, Roberto Mariottini says...

 In article <druv9v$27p3$1 digitaldaemon.com>, Dave says...
 [...]

 I just built a small 'interpreter' that will take a D file prefaced with



 Nice!


 To really make this work nicely, the compiler would have to ignore any first

 stdin.

 example:

 hello_script.d:
 ---------------

 import std.stdio;
 int main()
 {
 writefln("Hello (pseudo) scripting world");
 }




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

 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



 Feb 03 2006



  parent reply "Walter Bright" <newshound digitalmars.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:ds03jc$ctu$1 digitaldaemon.com...

 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.


I have the easy part, just ignore the first line <g>. 



 Feb 03 2006



  parent  Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 "Sean Kelly" <sean f4.ca> wrote in message 
 news:ds03jc$ctu$1 digitaldaemon.com...

 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.


 
 I have the easy part, just ignore the first line <g>. 


Lucky ;-)  I just had a look at the glibc POSIX headers and was 
immediately reminded just how nice we have it in D.  The C preprocessor 
is an evil, evil thing.


Sean



 Feb 03 2006



prev sibling  parent  "Walter Bright" <newshound digitalmars.com>  writes:


"Dave" <Dave_member pathlink.com> wrote in message 
news:ds02v2$cnb$1 digitaldaemon.com...


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


Is there a url where I can learn more about this? 



 Feb 03 2006



prev sibling  parent  "Ben Hinkle" <bhinkle mathworks.com>  writes:


 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



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 



#include <stdio.h>
int main()
{
    printf("Hello World\n");
    return 0;
}



 Feb 03 2006



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


Kris wrote:

 "Walter Bright" <newshound digitalmars.com> wrote
 

 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.


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



 Feb 02 2006



  parent reply "Kris" <fu bar.com>  writes:


"Sean Kelly" <sean f4.ca> wrote ..


 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.



 Feb 02 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


Kris wrote:

 "Sean Kelly" <sean f4.ca> wrote ..
 

 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



 Feb 02 2006



 next sibling parent  "Kris" <fu bar.com>  writes:


"Sean Kelly" <sean f4.ca> wrote...

 Kris wrote:

 "Sean Kelly" <sean f4.ca> wrote ..


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



 Feb 02 2006



prev sibling  parent reply "Kris" <fu bar.com>  writes:


"Sean Kelly" <sean f4.ca> wrote

 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?



 Feb 02 2006



 next sibling parent  "Matthew" <matthew hat.stlsoft.dot.org>  writes:


"Kris" <fu bar.com> wrote in message news:druk9p$20qd$1 digitaldaemon.com...

 "Sean Kelly" <sean f4.ca> wrote

 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?


Keep singing, my corpulent little damsel.



 Feb 02 2006



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


Kris wrote:

 
 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



 Feb 02 2006



  parent reply "Kris" <fu bar.com>  writes:


"Sean Kelly" <sean f4.ca> wrote ...

 Kris wrote:

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



 Feb 02 2006



  parent reply James Dunne <james.jdunne gmail.com>  writes:


Kris wrote:

 "Sean Kelly" <sean f4.ca> wrote ...
 

Kris wrote:


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


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne



 Feb 03 2006



  parent reply Sean Kelly <sean f4.ca>  writes:


James Dunne wrote:

 Kris wrote:

 "Sean Kelly" <sean f4.ca> wrote ...


 Kris wrote:


 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.




 



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



 Feb 03 2006



  parent reply James Dunne <james.jdunne gmail.com>  writes:


Sean Kelly wrote:

 James Dunne wrote:
 

 Kris wrote:


 "Sean Kelly" <sean f4.ca> wrote ...


 Kris wrote:


 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.







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



 Feb 03 2006



  parent  Sean Kelly <sean f4.ca>  writes:


James Dunne wrote:

 
 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



 Feb 03 2006



prev sibling next sibling parent  John Reimer <terminal.node gmail.com>  writes:


Kris,

Very good post... I think your thoughts are dead on.

-JJR

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?
 
 
 





 Feb 02 2006



prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Kris wrote:


 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



 Feb 02 2006



  parent reply "Kris" <fu bar.com>  writes:


"Anders F Björklund" <afb algonet.se> wrote...

 Kris wrote:


 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.



 Feb 02 2006



 next sibling parent  Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com>  writes:


Kris wrote:

 "Anders F Björklund" <afb algonet.se> wrote...
 

Kris wrote:



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.
 
 
 





 Feb 02 2006



prev sibling  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Kris wrote:


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



 Feb 02 2006



  parent reply "Kris" <fu bar.com>  writes:


"Anders F Björklund" <afb algonet.se> wrote...


 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? 



 Feb 02 2006



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Kris wrote:


 A changing of direction would pre-suppose an existing one ;-)


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



 Feb 03 2006



  parent reply kris <fu bar.org>  writes:


Anders F Björklund wrote:

 Kris wrote:

 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.



 Feb 03 2006



  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


kris wrote:


 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



 Feb 03 2006



  parent reply kris <fu bar.org>  writes:


Anders F Björklund wrote:

 kris wrote:
 

 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





 Feb 03 2006



 next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


kris wrote:


 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.


Kinda reminds me of antoher big company. Write once, Run anywhere :-P



--anders



 Feb 03 2006



prev sibling  parent reply pragma <pragma_member pathlink.com>  writes:


In article <drv6ms$2ckk$1 digitaldaemon.com>, kris says...

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



 Feb 03 2006



  parent  Sean Kelly <sean f4.ca>  writes:


pragma wrote:

 In article <drv6ms$2ckk$1 digitaldaemon.com>, kris says...

 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



 Feb 03 2006



prev sibling  parent  clayasaurus <clayasaurus gmail.com>  writes:


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?
 
 
 





 Feb 02 2006



prev sibling  parent reply Nick <Nick_member pathlink.com>  writes:


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

In article <pan.2006.02.01.20.06.12.251531 sneakemail.com>,
=?iso-8859-1?q?Knud_S=F8rensen?= says...

Slashdot have just posted a story called beyond Java

http://books.slashdot.org/article.pl?sid=06/02/01/1455213


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

Gotta love Slashdot.





 Feb 04 2006



  parent  pragma <pragma_member pathlink.com>  writes:


In article <ds29bf$20rb$1 digitaldaemon.com>, Nick 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.


Simply.  Awesome.  Glad to hear that.

- Eric Anderton at yahoo



 Feb 04 2006