----was Andrew McKinlay is trying D for Suneido.

http://thesoftwarelife.blogspot.fr/2012/08/d-etractions.html

You do not necessarily have to agree with Andrew, but this is a pragmatic developer's view.  Let me say that Andrew has created his own database system (Relational Algebra based) , his own language (Ruby like)  and his own application frame work. Finally he is using his Tools to create real world software.. i.e. Trucking/Transport / Accounting etc.

IMO a voice, D core developers should listen to.

Bjoern

On 08/25/2012 01:58 AM, Pragma Tix wrote:
> ----was Andrew McKinlay is trying D for Suneido.
>
> http://thesoftwarelife.blogspot.fr/2012/08/d-etractions.html
>
> You do not necessarily have to agree with Andrew, but this is a
> pragmatic developer's view.  Let me say that Andrew has created his own
> database system (Relational Algebra based) , his own language (Ruby
> like)  and his own application frame work. Finally he is using his Tools
> to create real world software.. i.e. Trucking/Transport / Accounting etc.
>
> IMO a voice, D core developers should listen to.
>
> Bjoern

His post comes down to: "I like to have an IDE and I prefer Java
because I already know Java."
This is perfectly fine of course, but why would this be relevant for D
development?

Pragma Tix:

> IMO a voice, D core developers should listen to.

Even assuming all the things he has said are true, what do you suggest D core developers to do?
Example: how can D language devevelopers help D programmers better refactor D code? Maybe having some built-in refactoring features?

Probably some GC improvements are coming, thanks to Google sponsorship.

Bye,
bearophile

Am 25.08.2012 02:22, schrieb bearophile:
> Even assuming all the things he has said are true, what do you suggest D
> core developers to do?
> Example: how can D language devevelopers help D programmers better
> refactor D code? Maybe having some built-in refactoring features?
>
> Probably some GC improvements are coming, thanks to Google sponsorship.

First of all --- I have just forwarded a link, 'cause I thought that this blog contains some interesting insights/views/opinions.


Next. What the core team can do :

GC Improvements.

IDE support. std.lexer

Following the blog you will find a few remarks about missing things in Phobos.
----

Quote ~
D templates and CTFE + mixins are making me nervous.
~ End quote

Well, than .. I would say C++11 is making me panicking.
But the author did not offer any details. so it's hard to say what exactly make him worry.
send him some gentle feedback ..

Pragma Tix:

> First of all --- I have just forwarded a link, 'cause I thought that this blog contains some interesting insights/views/opinions.

Right, sorry :-)

Bye,
bearophile

Am 25.08.2012 02:20, schrieb Timon Gehr:
> His post comes down to: "I like to have an IDE and I prefer Java
> because I already know Java."

Not exactly. Seems that he likes pure and immutable ... (not really Java )

F.I.
quote
But when you can't put immutable values in a container without wrapping them in a "Rebindable" template, that again makes me nervous.
end quote

Say an associative array that stores immutable objects.


> This is perfectly fine of course, but why would this be relevant for D
> development?

This blog is relevant 'cause it is a voice saying "D is not production ready"
Let me ask you this. why HBase/Hadoop is not done in D, why SWIFT is not written in D, why... etc.   A: 'Cause the language is not yet stable, therefore the basic library is in flow.

4 me D2 is very far away from being a serious tool, atm D is a geek toy. Having a foreign pragmatic programmer saying exactly that, makes sense to me. I think this is an constructive blog, in case that somebody is willing to listen.

Pragma Tix:

> 'Cause the language is not yet stable, therefore the basic library is in flow.

In a simulated annealing algorithm (http://en.wikipedia.org/wiki/Simulated_annealing ) you can't lower the temperature too much quickly, otherwise you get a bad solution. To reach a stable solution you need to lower the temperature progressively and smartly, sometimes you even have to increase it a bit again, before letting the system cool down and reach the stability you look for.

Stochastic optimization strategies offer lot of useful metaphors to express ideas :-)

Bye,
bearophile

On Saturday, 25 August 2012 at 00:22:58 UTC, bearophile wrote:
> Pragma Tix:
>
>> IMO a voice, D core developers should listen to.
>
> Even assuming all the things he has said are true, what do you suggest D core developers to do?
> Example: how can D language devevelopers help D programmers better refactor D code? Maybe having some built-in refactoring features?

The D language is designed in such a way that makes many automated refactoring tasks incredibly difficult, if not impossible.

An example from Walter's recent talk:

struct A {
    int a;
    mixin(bitfields!(
        uint, "x", 2,
        int, "y", 3,
        uint, "z", 2,
        bool, "flag", 1));
}
A obj;
obj.x = 2;
obj.z = obj.x;


A common (and simple) refactoring task included in most IDEs is to rename a variable. Imagine what's involved in renaming the x, y, and z from the bitfield in the above code. You would have to expand the template (which involved CTFE) and then somehow infer that the name of the variable came from that string in the template args.

Okay, so bitfields are rarely used, but many templates involve some use of CTFE, and templates are very common in D code. It's good that D's parser is fairly simple to implement (compared to C++ anyway), but to do automated refactoring you need simple semantic analysis, and this is something that D does not have.

On Saturday, 25 August 2012 at 13:03:13 UTC, Peter Alexander wrote:
> You would have to expand the template (which involved CTFE) and then somehow infer that the name of the variable came from that string in the template args.
> ...
> but to do automated refactoring you need simple semantic analysis, and this is something that D does not have.

I agree. However, I'd even go as far as to say it's _definitely_ impossible (at least, in general).

Consider a mixin that makes a string like this:

template awesomeVar(string param) {
    enum awesomeVar = "int awesomeVariableOf" ~ param ~";";
}

and it's used in some classes:

class A {
   ...
   mixin(awesomeVar!"Doom");
   ...
}

class B {
   ...
   mixin(awesomeVar!"Epicness");
   ...
}

Later in code you see:
   A a = new A;
   ...
   a.awesomeVariableOfDoom = 7;
   ...

You can decide to change that to "awesomeVariableOfStuff" and sufficiently smart refactoring software could figure out that it just needs to change A's mixin declaration to mixin(awesomeVar!"Stuff") ... I make it sound like "sufficiently smart refactoring software" would be easy to write, but it wouldn't be.

Or you decide, "Oh, I'm going to refactor that and change the name to 'incredibleVariableOfDoom'". So now your refactoring software will have to expand the mixin, figure out the relevant parts of the mixin to modify, figure out every class that uses the mixin (such as B changing to incredibleVariableOfEpicness), and then perform the changes to the relevant parts there as well. That sounds much tougher to me.

Now consider if you decide "Oh, I'm going to refactor that and change the name to 'iLoveCopyPasta'". In this case, exactly what should your software do? Prompt you (maybe) a hundred times to resolve the numerous conflicts? Obviously, there's no automated way to decide what B's variable should be named. And keep in mind, this is a _simple_ mixin.

For all practical purposes, if refactoring will be done on any mixins, it will require special casing (for instance, write a plugin to refactor bitfields, don't generalize it to work with every mixin). That would make it much more reasonable... but it makes writing your own mixins less effective (because, presumably, you're going to want to write your own plugin to handle refactoring your mixin if you're going to use it everywhere).


That all said, I still like mixins and it doesn't bother me that I'd lose refactoring on certain code. But it's something to be aware of, at least.

On Friday, 24 August 2012 at 23:58:19 UTC, Pragma Tix wrote:
> ----was Andrew McKinlay is trying D for Suneido.
>
> http://thesoftwarelife.blogspot.fr/2012/08/d-etractions.html
>
> You do not necessarily have to agree with Andrew, but this is a pragmatic developer's view.  Let me say that Andrew has created his own database system (Relational Algebra based) , his own language (Ruby like)  and his own application frame work. Finally he is using his Tools to create real world software.. i.e. Trucking/Transport / Accounting etc.
>
> IMO a voice, D core developers should listen to.
>
> Bjoern

I would say that a modern IDE is what most of todays developers use today. The D community misses out on a HUGE audience here. It's already hard to convince a programmer to try out something new. Starting up a D project isn't something that is done in a day by a person who is pretty new to programming.

Best regards,
Niklas