www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Policy opinion

reply Georg Wrede <georg.wrede nospam.org> writes:
Currently, D is a Windows-32 language, and more or less just on the side 
is available for Linux.

We all know this is for "historical" reasons.

However, if we were to consider what (or if, any) future directions D 
should weigh against each other, things might be different.


Establishing a non-trivial presence on Windows will be hard. While 
gaining a marginal foothold is simple (as we've seen with D, Euphoria, 
and a bunch of other languages), reaching critical mass on Windows may 
be a hurdle that needs substantial markening savvy and economic backing.

On the other hand, those who make decisions on the Linux platform, are 
in a different situation. They already are on an "alternative" platform, 
and therefore are not averse to "unconventional" choices. For them, the 
product itself, rather than its market share or other secondary issues, 
is what counts.

While we don't have now, and will not have in the immediate future any 
significant chances of expanding outside Linux on 32-bit Intel, I still 
think that this is the exact segment we should target. That is the exact 
segment where we only need to make the distro install smoothly and 
behave like any other language package. At the same time, the effort 
needed here is next to trivial -- compared to other measures with the 
same effect. In other words, benefit per cost is superior here.

What makes competing on Windows harder is Microsoft's own languages, 
like C#, the move to Common Language Infrastructure, and the fact that 
companies who use Windows are conservative in their choice of tools.

By default everyone assumes a longevity for anything originating from 
Microsoft itself as comparable to that of Windows itself. We here on 
this mailing list may know better, but the issue is the assumptions of 
Customers, or end-users of languages and development tools. If a product 
is better has never before made any difference in Windows.

On Linux, the merits of the language itself are what counts. Even the 
documentation doesn't have to be all that "productized", as long as the 
compiler package doesn't appear quirky or pequliar.

---

The first thing we might do is to separate the Windows and Linux 
downloads. Then the Linux download should get rid of the /etc conf file. 
Next the .exe files should vanish. And the executable binaries should be 
executable on Linux without manual adjustment. Issues with finding 
libraries, "distribution home directory", the shared object file, should 
all be fixed. Good examples can be found in the other language compilers 
for Linux. Oh, and being non-root should cause a single user 
installation, and being root should cause a system-wide installation. D 
should not care or restrict choice of install directory.

These are all well understood issues with plenty of examples, howtos and 
other documentation around. Not having fixed these does give the 
language a home-made feel right from the outset. And to a user, this in 
itself implies other than longevity and huge potential.

Once prevalent and respected on Linux, D might wake up Windows people -- 
at the end of the day, we'd meet our goal this way with less total 
effort and expenditure than with the current tack.
Oct 24 2005
next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
I think the most important thing to do now is to come up with a working
language specification. You know, as long as the language is on an alpha
development state, all projects need to be partly rewritten due to some
nasty language modifications.

IMO there are same big problems with D interfaces. It would also be
crucial to clearly define all the advanced and generic features of the
language. Later on it would be easier to fix the smaller issues from
any 3rd party software code. We've seen this with Java. The late support
for generics has been a pain in the ass for many projects.

If the core language is not ready, the oss zealots _will_ most probably
want to fork their own versions of D. If the specification is "ready",
there's no further need to fork anything.

The same goes with "standard libraries". I think Phobos is not very
good. It's weirdly structured, the hierarchies seem to be far from
final. The main level of Phobos is strange - I don't think that
std.recls belongs to the same abstraction level with std.math or
std.file. Phobos is also missing some useful functions like the
std.file.islink(char[] name).
Oct 24 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:435D0D24.5020608 nospam.org...
 The first thing we might do is to separate the Windows and Linux
 downloads. Then the Linux download should get rid of the /etc conf file.
 Next the .exe files should vanish. And the executable binaries should be
 executable on Linux without manual adjustment. Issues with finding
 libraries, "distribution home directory", the shared object file, should
 all be fixed. Good examples can be found in the other language compilers
 for Linux. Oh, and being non-root should cause a single user
 installation, and being root should cause a system-wide installation. D
 should not care or restrict choice of install directory.

 These are all well understood issues with plenty of examples, howtos and
 other documentation around. Not having fixed these does give the
 language a home-made feel right from the outset. And to a user, this in
 itself implies other than longevity and huge potential.

I agree with you, but my expertise on Linux is minimal. If you can provide a step-by-step guide for me to implement this stuff, I can get it done.
Oct 24 2005
next sibling parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
Here are a few things I can think of off the top of my head:
1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search 
path; this way we can just copy the relevant stuff there and be done with 
it.
2. It would be a good idea to just drop the config file, and go with 
environment variables for configuration.
3. I believe, if nothing else than for unofficial community standards 
compliance, that we should drop the -op and -of options, have dmd respect 
paths like everything else, and reimplement -o.
What does everyone think?
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:djjeu3$1g0k$1 digitaldaemon.com...
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:435D0D24.5020608 nospam.org...
 The first thing we might do is to separate the Windows and Linux
 downloads. Then the Linux download should get rid of the /etc conf file.
 Next the .exe files should vanish. And the executable binaries should be
 executable on Linux without manual adjustment. Issues with finding
 libraries, "distribution home directory", the shared object file, should
 all be fixed. Good examples can be found in the other language compilers
 for Linux. Oh, and being non-root should cause a single user
 installation, and being root should cause a system-wide installation. D
 should not care or restrict choice of install directory.

 These are all well understood issues with plenty of examples, howtos and
 other documentation around. Not having fixed these does give the
 language a home-made feel right from the outset. And to a user, this in
 itself implies other than longevity and huge potential.

I agree with you, but my expertise on Linux is minimal. If you can provide a step-by-step guide for me to implement this stuff, I can get it done.

Oct 24 2005
parent reply BCS <BCS_member pathlink.com> writes:
What about us schmucks that can't wright to /usr/include/d and
/usr/local/include/d? 

I run dmd on a system for which I have only basic user privileges. If you are
going to tweak things how about make it easier for us little pawns. 

1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search 
path; this way we can just copy the relevant stuff there and be done with 
it.

Oct 24 2005
parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
Noone's saying you *have* to, just that since many do, it should be 
automatically planned for; if you can't, then set up your own directory, 
modify your environment, and you're all set.
"BCS" <BCS_member pathlink.com> wrote in message 
news:djjjes$1jo6$1 digitaldaemon.com...
 What about us schmucks that can't wright to /usr/include/d and
 /usr/local/include/d?

 I run dmd on a system for which I have only basic user privileges. If you 
 are
 going to tweak things how about make it easier for us little pawns.

1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search
path; this way we can just copy the relevant stuff there and be done with
it.


Oct 24 2005
parent reply BCS <BCS_member pathlink.com> writes:
That's more or less what I am doing. But it just seems like sutch a kluge. I'm
hopeing someone can come up with a better solution. 

In article <djjkjs$1kgf$1 digitaldaemon.com>, Ameer Armaly says...
Noone's saying you *have* to, just that since many do, it should be 
automatically planned for; if you can't, then set up your own directory, 
modify your environment, and you're all set.
"BCS" <BCS_member pathlink.com> wrote in message 
news:djjjes$1jo6$1 digitaldaemon.com...
 What about us schmucks that can't wright to /usr/include/d and
 /usr/local/include/d?

 I run dmd on a system for which I have only basic user privileges. If you 
 are
 going to tweak things how about make it easier for us little pawns.

1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search
path; this way we can just copy the relevant stuff there and be done with
it.



Oct 25 2005
parent =?utf-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?= <araelx gmail.com> writes:
On Tue, 25 Oct 2005 19:14:47 +0200, BCS <BCS_member pathlink.com> wrote:

 That's more or less what I am doing. But it just seems like sutch a  
 kluge. I'm
 hopeing someone can come up with a better solution.

This is exacly as everything else work in linux. Ever tried run gcc instaled under ~/ - it's the same. -- Dawid Ciężarkiewicz
Oct 26 2005
prev sibling parent =?utf-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?= <araelx gmail.com> writes:
On Mon, 24 Oct 2005 21:41:26 +0200, Walter Bright  
<newshound digitalmars.com> wrote:

 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:435D0D24.5020608 nospam.org...
 The first thing we might do is to separate the Windows and Linux
 downloads. Then the Linux download should get rid of the /etc conf file.
 Next the .exe files should vanish. And the executable binaries should be
 executable on Linux without manual adjustment. Issues with finding
 libraries, "distribution home directory", the shared object file, should
 all be fixed. Good examples can be found in the other language compilers
 for Linux. Oh, and being non-root should cause a single user
 installation, and being root should cause a system-wide installation. D
 should not care or restrict choice of install directory.


 These are all well understood issues with plenty of examples, howtos and
 other documentation around. Not having fixed these does give the
 language a home-made feel right from the outset. And to a user, this in
 itself implies other than longevity and huge potential.

I agree with you, but my expertise on Linux is minimal. If you can provide a step-by-step guide for me to implement this stuff, I can get it done.

IMO current DMD integration with linux is quite good. It is packager problem to make everything intalled well - so *.exe files are only wasted bandwidth problem (but if this wouldn't be a maintenance problem - should be splited of course). I have prepared myself packaged version of DMD for ArchLinux and I haven't had much problems - still it was different than "native" linux apps. What I miss is some "Makefile" that would make simple user life easier if his distro does not have dmd packaged. Ameer Armaly proposed things that I generaly agree (and are easy to do IMHO), and would make dmd looks more like standard unix compiler. Oh. And recognition of "dmd --help" and "dmd -h" would be trivial to add but unixuserfriendly. If the "/etc/dmd.conf" file removal is problem, then good resolution would be checking for "$HOME/.dmdrc" (or something like this - only leading dot is important) and unless it exists for global "/etc/dmd.conf". Everything of these are little things that make life nicer and most propably may give good impresion on Linux Zealots which are good to have on D (our) side. Regards, -- Dawid Ciężarkiewicz
Oct 26 2005