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