View mode: basic / threaded / horizontal-split · Log in · Help
August 24, 2012
D-etractions A real world programmers view on D
----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
August 25, 2012
Re: D-etractions A real world programmers view on D
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?
August 25, 2012
Re: D-etractions A real world programmers view on D
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
August 25, 2012
Re: D-etractions A real world programmers view on D
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 ..
August 25, 2012
Re: D-etractions A real world programmers view on D
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
August 25, 2012
Re: D-etractions A real world programmers view on D
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.
August 25, 2012
Re: D-etractions A real world programmers view on D
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
August 25, 2012
Re: D-etractions A real world programmers view on D
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.
August 25, 2012
Re: D-etractions A real world programmers view on D
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.
August 25, 2012
Re: D-etractions A real world programmers view on D
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home