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

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

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

[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

"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 :)

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

"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 :-)

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

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

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