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

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

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

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

I have no desire to continue this discussion. Thanks for your thoughts.

Regan

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

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

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

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

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