August 02, 2010
On 2010-08-02 15:18, Andrei Alexandrescu wrote:
> On 08/02/2010 06:01 AM, Jacob Carlborg wrote:
>> On 2010-08-02 02:07, Andrei Alexandrescu wrote:
>>> Hello,
>>>
>>>
>>> I got an email from someone who got an interest in D following my talk
>>> at Google. He tried to install dmd on OSX, but got turned off (and
>>> rightly so) for the unnecessary difficulties of that process and the
>>> lack of documentation. Nicely of him he took the time to write me and
>>> detail his experience. Following that, Walter managed to fix the most
>>> egregious documentation errors.
>>>
>>> Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
>>> someone able and willing to own this project? I think improving the
>>> out-of-the-box experience is important and urgent.
>>>
>>>
>>> Andrei
>>>
>>> P.S. My talk at Google went, I think, reasonably well. It could've gone
>>> a whole lot better; I neglected to make a couple of points. The talk was
>>> recorded and, I was told, the recording will be on YouTube some time
>>> next week. My mentions of Python and Haskell will probably get me
>>> mortified in certain circles.
>>
>> Have you guys completely forgot
>> http://dsource.org/projects/dmd-installer/browser/trunk/osx ? It's been
>> there for over a year.
>
> Hi Jacob,
>
> Apologies for the oversight. I take it it's okay if Walter uses your
> code to build the distribution automatically? If so, what are the
> similarities and the differences with Michel's approach?
>
> Andrei

Yes, it's okay, that was the whole point of the code. The difference is that the package my code builds will contain dmd and it will install it in a different location (/usr/share/dmd). Obviously it doesn't contain the XCode plugin.

-- 
/Jacob Carlborg
August 02, 2010
On 2010-08-02 16:41, Michel Fortin wrote:
> On 2010-08-02 09:18:37 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> said:
>
>> On 08/02/2010 06:01 AM, Jacob Carlborg wrote:
>>> Have you guys completely forgot
>>> http://dsource.org/projects/dmd-installer/browser/trunk/osx ? It's been
>>> there for over a year.
>>
>> Hi Jacob,
>>
>> Apologies for the oversight. I take it it's okay if Walter uses your
>> code to build the distribution automatically? If so, what are the
>> similarities and the differences with Michel's approach?
>
> I think I can answer that.
>
> * Jacob's installer includes DMD directly inside the installation
> package, which I believe is more practical for the user, but less for
> the maintainer as the installer needs to be rebuild for each new
> release. My installer downloads the latest version during the install. I
> do this so I can host the installer on my website with no licensing
> issue and update it only when releasing a new version of D for Xcode.
>
> * Jacob's installer installs in /usr/share/dmd and creates symlinks in
> /usr/bin and /usr/share/man. D for Xocde installs DMD 1 in
> /Library/Compilers/dmd and DMD 2 in /Library/Compilers/dmd2 (user
> visible folders) and makes symlinks in /usr/local/{bin,lib,man}.
>
> * Jacob's installer requires a modified dmd.conf file. Not with my
> installer. With mine, once the symlinks are in place you can just swap
> the dmd or dmd2 folder in /Library/Compilers with a newer one from
> Digital Mars, but you'll need to set the executable bits manually
> (because Walter's archives comes without the executable bit set).
>
> * With Jacob's installer, DMD 1 and DMD 2 will overwrite each other (or
> so I believe). My installer is meant to have both dmd1 and dmd2 usable
> at the same time. Essentially the symlinks /usr/local/bin/* pointing to
> /Library/Compilers/{dmd,dmd2}/osx/bin/* are arranged to that you can
> call 'dmd1' and 'dmd2' from the command line to get either one or the
> other, and 'dmd' will call either dmd2 or dmd1, which you can change
> with the 'sudo setdmd 1' or 'sudo setdmd 2' command. This mimics
> somewhat how Apple bundles multiple versions of GCC in the Xcode package
> and allow changing the default version.

I guess I should fix that if anyone wants to use the installer.

> As a side note, my D plugin for Xcode expects DMD to be available at
> /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in
> /usr/local/lib. It won't work if the files can't be found there,
> although I might change that if an official distribution of DMD installs
> itself elsewhere.

That was a lot better answer than mine.

-- 
/Jacob Carlborg
August 02, 2010
dsimcha wrote:
> It just seems like common sense to me that a module system (and a language in
> general) should do what you mean as long as there's no ambiguity about what you
> mean (without forcing you to specify things redundantly, such as by using
> qualified names), but not guess what you mean when there is ambiguity.  Is there
> any other language that gets this right?

As far as I know, no other language does this right.

While it seems common sense in retrospect, coming up with it took a while. D1 is close, but D2 shines.

Rob Pike (of Go fame) says Go doesn't allow function overloading because of the confusion it causes. That's understandable given C++'s uncontrollable overloading and open namespaces. D2 doesn't have that problem.
August 03, 2010
Walter Bright, el  2 de agosto a las 16:12 me escribiste:
> dsimcha wrote:
> >It just seems like common sense to me that a module system (and a language in general) should do what you mean as long as there's no ambiguity about what you mean (without forcing you to specify things redundantly, such as by using qualified names), but not guess what you mean when there is ambiguity.  Is there any other language that gets this right?
> 
> As far as I know, no other language does this right.
> 
> While it seems common sense in retrospect, coming up with it took a while. D1 is close, but D2 shines.
> 
> Rob Pike (of Go fame) says Go doesn't allow function overloading because of the confusion it causes. That's understandable given C++'s uncontrollable overloading and open namespaces. D2 doesn't have that problem.

For me the problem with D is dependency control. You don't know what symbol come from which module. Yes, I know you can do explicit dependencies in D with static and selective imports, the same you can do the inverse in other languages with the import module.*-like syntax, but I think D got the default wrong, I prefer explicit by default.

With this default, I think complaining when no symbol from an imported module is used would be better to avoid extra unneeded dependencies. But I suggested that before and you don't like it.

Too bad.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
no longer afraid of the dark or midday shadows
nothing so ridiculously teenage and desperate,
nothing so childish - at a better pace,
slower and more calculated,
no chance of escape,
August 03, 2010
Leandro Lucarella wrote:
> For me the problem with D is dependency control. You don't know what
> symbol come from which module. Yes, I know you can do explicit
> dependencies in D with static and selective imports, the same you can do
> the inverse in other languages with the import module.*-like syntax, but
> I think D got the default wrong, I prefer explicit by default.

It's a reasonable point of view, but the motivating thing for me here is making it easy for people to write quick&dirty programs.

> With this default, I think complaining when no symbol from an imported
> module is used would be better to avoid extra unneeded dependencies. But
> I suggested that before and you don't like it.

While that idea has merit, too, I feel it would become rather annoying to people who want to:

    import std.all;

or who use conditional compilation. It would also mess with template definitions, as the symbols in them are not lookup up until they are instantiated.
August 03, 2010
== Quote from Leandro Lucarella (luca@llucax.com.ar)'s article
> With this default, I think complaining when no symbol from an imported
> module is used would be better to avoid extra unneeded dependencies. But
> I suggested that before and you don't like it.
> Too bad.

But then you wouldn't be able to do import somelib.all;.  This is essential because importing all the modules you need individually is tedious, annoying boilerplate code.  IMHO in a modern language with good metaprogramming facilities like D, boilerplate code should absolutely, 110%, at all costs, be swept off to the ash heap of history.  It's boring to write, hard to maintain (in the sense that it's just more code to slog through) and encourages cut-and-paste style coding.  I refuse to write even the few lines of boilerplate it takes to import the same 15 modules over and over, when I can have a module that just publicly imports all of the ones I typically need.
August 03, 2010
== Quote from Walter Bright (newshound2@digitalmars.com)'s article
> Leandro Lucarella wrote:
> > For me the problem with D is dependency control. You don't know what symbol come from which module. Yes, I know you can do explicit dependencies in D with static and selective imports, the same you can do the inverse in other languages with the import module.*-like syntax, but I think D got the default wrong, I prefer explicit by default.
> It's a reasonable point of view, but the motivating thing for me here is making it easy for people to write quick&dirty programs.

I truly appreciate D's stance that both quick and dirty code and more heavily engineered code need to be supported.  My biggest gripe about languages like Java is that they force so much "proper style" on me that I can't just "make it work" before I "make it right".

I love how, using D, I can go from a quick and dirty prototype to a "real" program/library without having to switch languages and completely rewrite every function.  In bioinformatics research, we do TONS of prototyping/small scripts and only a small fraction of these prototypes are fleshed out into serious programs. I suspect there are other fields like this, where you just want a quick prototype up front, but it may or may not be converted into a proper program depending on how the prototype works. Being able to do both in the same language is just an outstanding feature.

Second, being able to write quick/dirty programs lowers the barrier to entry for trying out the language.  My first few D programs, back when D was a mere curiosity for me, were things like programs that counted the amount of times each DNA nucleotide occurred in a sequence.  Of course this is trivial, but if the language treated me like a naughty child instead of a consenting adult, I would likely not have stuck with it.

Third, often only part of a program needs to be well-engineered (the core algorithms that will likely be around awhile) and the rest is just some quick and dirty glue to feed data to the core algorithms, and will likely change in relatively short order.  The well-factored core algorithms plus quick and dirty glue style is very often how I program in practice.
August 03, 2010
"Leandro Lucarella" <luca@llucax.com.ar> wrote in message news:20100803004718.GW3508@llucax.com.ar...
> Walter Bright, el  2 de agosto a las 16:12 me escribiste:
>> dsimcha wrote:
>> >It just seems like common sense to me that a module system (and a
>> >language in
>> >general) should do what you mean as long as there's no ambiguity about
>> >what you
>> >mean (without forcing you to specify things redundantly, such as by
>> >using
>> >qualified names), but not guess what you mean when there is ambiguity.
>> >Is there
>> >any other language that gets this right?
>>
>> As far as I know, no other language does this right.
>>
>> While it seems common sense in retrospect, coming up with it took a while. D1 is close, but D2 shines.
>>
>> Rob Pike (of Go fame) says Go doesn't allow function overloading because of the confusion it causes. That's understandable given C++'s uncontrollable overloading and open namespaces. D2 doesn't have that problem.
>
> For me the problem with D is dependency control. You don't know what symbol come from which module. Yes, I know you can do explicit dependencies in D with static and selective imports, the same you can do the inverse in other languages with the import module.*-like syntax, but I think D got the default wrong, I prefer explicit by default.
>

Personally, I would find that to save a couple minutes once in a while, and be a PITA most of the time. I'd find that to be a poor tradeoff.


August 03, 2010
dsimcha wrote:
> Third, often only part of a program needs to be well-engineered (the core
> algorithms that will likely be around awhile) and the rest is just some quick and
> dirty glue to feed data to the core algorithms, and will likely change in
> relatively short order.  The well-factored core algorithms plus quick and dirty
> glue style is very often how I program in practice.

I agree with all your points. D has a "layered" approach to program correctness and safety, and you can mix & match them as your project needs change.

The downside is D gets flak for being complicated and a kitchen sink, but I think it's a far better approach to have them properly integrated into the language rather than the rather desperate approaches I've seen using coding standards, third party analyzers, source code annotations, etc.
August 03, 2010
dsimcha, el  3 de agosto a las 02:16 me escribiste:
> == Quote from Leandro Lucarella (luca@llucax.com.ar)'s article
> > With this default, I think complaining when no symbol from an imported
> > module is used would be better to avoid extra unneeded dependencies. But
> > I suggested that before and you don't like it.
> > Too bad.
> 
> But then you wouldn't be able to do import somelib.all;

If a syntax like import somelib.*; would be implemented, that kind of "import all" statements could be taken as a special case and don't trigger the error. public imports should not trigger errors either, because you are just explicitly propagating what's in a module.

> because importing all the modules you need individually is tedious, annoying boilerplate code.  IMHO in a modern language with good metaprogramming facilities like D, boilerplate code should absolutely, 110%, at all costs, be swept off to the ash heap of history.  It's boring to write, hard to maintain (in the sense that it's just more code to slog through) and encourages cut-and-paste style coding.  I refuse to write even the few lines of boilerplate it takes to import the same 15 modules over and over, when I can have a module that just publicly imports all of the ones I typically need.

Again, I completely agree. But you can avoid all the boilerplate code and keep the dependencies explicit by default. They are not mutually exclusive goals.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y será el día en que la electricidad deje de ser rayo y sea depilador
femenino.
	-- Ricardo Vaporeso