On processors for D ~ decoupling

[kris]

Walter Bright wrote:
> Georg Wrede wrote:
> 
>> I admit this is a "feelings based" thing with most people I've talked 
>> with. It seems that on embedded platforms, many expect to write all 
>> the needed code themselves. It's also felt (possibly unduely??) that 
>> Phobos (or whatever general Win+*nix standard library) is mostly 
>> useless in embedded applications.
> 
> 
> I'd like to get to the bottom of this feeling. For example, Kris was 
> unhappy that typeinfo imported std.strings. I can't figure out what the 
> problem with that is.


I'll try to explain it from my perspective:

1) You show an adversion to tightly coupled library modules ~ made a 
number of negative comments about the Java libraries in that respect ~ 
and have spelled out in the past a desire to duplicate code as necessary 
to avoid said tight coupling. This is good design, and it's one of the 
harder things to balance when building a library. Yet, there's flagrant 
cases where D tosses this out of the window along with the bathwater. 
Instead of adding a duplicate itoa() method (about 60 bytes of code), or 
perhaps linking to the C library version, TypeInfo gratuitously imports 
std.string and all its vast array of baggage. Heck, everyone makes 
mistakes, but your comment above indicates you feel this kind of tight 
coupling is perfectly fine?

Then, there's printf() being linked via Object ~ it's been 2 years since 
the push to have that removed (which you agreed to), yet it's now clear 
there's no intent to do so. So what's wrong with printf()? Well, it 
brings along with it almost the entire C IO library, including most of 
the wide-char processing and, of course, all the floating-point support, 
setup, and management. All completely unecessary where one doesn't use 
it. And it's linked at the base of the Object tree.

Without wishing to put too fine a point on it, you continue to do just 
exactly what you preach against; and there's apparently no good reason 
for it.


2) Not everyone likes Phobos. One might think you'd be happy to 
encourage (support, even!) alternate libraries that might far exceed the 
utility and/or design parameters of Phobos itself. Yet, by tightly 
coupling the D language to Phobos, you make life difficult for those 
alternate libraries. And for what reason? It makes no sense at all.


If you'd decouple the language from the library, you'd end up with 
something very close to Ares. It's lean, efficient, and very flexible. 
In fact, it lends itself very well to others building a working D 
compiler & environment ~ the kind of thing that helps increase adoption 
by decreasing concerns. By encouraging development of alternate 
libraries, the D language stands a better chance of having a good one. 
Via judicious decoupling, you can keep the resultant executable lean and 
mean ~ making it more attractive to the embedded market, amongst others. 
D might even avoid having to link the FPU management code by default :-P


You said "Kris was unhappy that typeinfo imported std.strings. I can't 
figure out what the problem with that is" ~~ I hope this helps you get 
there.