www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D-etractions A real world programmers view on D

reply Pragma Tix <pragmatix orange.fr> writes:
----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
Aug 24 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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?
Aug 24 2012
next sibling parent reply Pragma Tix <pragmatix orange.fr> writes:
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.
Aug 24 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Aug 24 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/25/2012 03:36 AM, Pragma Tix wrote:

 ...
 I think this is an constructive blog, in case that somebody is
 willing to listen.


I really don't get what this is about. Are you actually suggesting
things are as they are because some clueless developers are unaware of
the issues?
Aug 25 2012
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 25 August 2012 at 16:23:22 UTC, Timon Gehr wrote:

 On 08/25/2012 03:36 AM, Pragma Tix wrote:

 ...
 I think this is an constructive blog, in case that somebody is
 willing to listen.


 I really don't get what this is about. Are you actually 
 suggesting
 things are as they are because some clueless developers are 
 unaware of
 the issues?


Not to speak for "Pragma Tix", but I don't think he is suggesting 
that. The blog post is simply another data point to gauge 
perception of D outside this newsgroup.
Aug 25 2012
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/25/2012 12:23 PM, Timon Gehr wrote:

 On 08/25/2012 03:36 AM, Pragma Tix wrote:

 I really don't get what this is about. Are you actually suggesting
 things are as they are because some clueless developers are unaware of
 the issues?


Judging by your first reaction, that is a possibility, where you 
completely ignored important issues like garbage collection and the pain 
surrounding immutable.

As for the IDE, he mentioned Scala, and there the developers made an 
effort to support the IDE in the compiler so that work wouldn't be 
duplicated and the IDE would support the latest language release. They 
also had funding and hired somebody to work on the Eclipse plugin full time.
Aug 25 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/25/2012 09:48 PM, Jeff Nowakowski wrote:

 On 08/25/2012 12:23 PM, Timon Gehr wrote:

 On 08/25/2012 03:36 AM, Pragma Tix wrote:

 I really don't get what this is about. Are you actually suggesting
 things are as they are because some clueless developers are unaware of
 the issues?


 Judging by your first reaction, that is a possibility, where you
 completely ignored important issues like garbage collection and the pain
 surrounding immutable.


Everyone here is aware of these issues.


 ...
 They also had funding and hired somebody to work on the Eclipse plugin full
 time.


Exactly.
Aug 25 2012
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/25/2012 06:29 PM, Timon Gehr wrote:

 Everyone here is aware of these issues.


Yet when you replied you ignored them while trying to dismiss the post 
as a triviality.
Aug 25 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/26/2012 08:22 AM, Jeff Nowakowski wrote:

 On 08/25/2012 06:29 PM, Timon Gehr wrote:

 Everyone here is aware of these issues.


 Yet  when you replied you ignored them


If you were expecting an exalted "pointing these out once again will
improve the development of D without bounds, thank you for sharing!",
then rest assured that this is not how things work.


 while trying to dismiss the post as a triviality.


Valuable posts are those that embody or document some creative effort.

Anyway, let us stop the meta-talk.
Aug 26 2012
parent Jeff Nowakowski <jeff dilacero.org> writes:
On 08/26/2012 08:51 AM, Timon Gehr wrote:

 If you were expecting an exalted "pointing these out once again will
 improve the development of D without bounds, thank you for sharing!",
 then rest assured that this is not how things work.


Nice strawman. You could have said, "Yes, these are important problems 
that we are aware of", but instead you ignored them and dismissed the 
post with an insulting summary.


 Anyway, let us stop the meta-talk.


Sure, as it takes two to do that feel free not to reply.
Aug 26 2012
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 25 August 2012 at 19:48:33 UTC, Jeff Nowakowski 
wrote:


 As for the IDE, he mentioned Scala, and there the developers 
 made an effort to support the IDE in the compiler so that work 
 wouldn't be duplicated and the IDE would support the latest 
 language release. They also had funding and hired somebody to 
 work on the Eclipse plugin full time.


I wish Walter went on kickstarter to get public funds allowing 
him to hire a couple of full time developers.
Aug 27 2012
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Monday, 27 August 2012 at 23:28:31 UTC, SomeDude wrote:

 I wish Walter went on kickstarter to get public funds allowing 
 him to hire a couple of full time developers.


I would pitch in $150 for that.
Aug 27 2012
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 28 August 2012 at 00:14:34 UTC, Chris Cain wrote:

 On Monday, 27 August 2012 at 23:28:31 UTC, SomeDude wrote:

 I wish Walter went on kickstarter to get public funds allowing 
 him to hire a couple of full time developers.


 I would pitch in $150 for that.


  I'd throw in $50, or $10-$15 each month for as long as it was 
needed. Perhaps putting up a option to give donations via paypal 
or something. Then when he accumulates a thousand or something 
that would hire for a while, Maybe get some help from FSF as well.
Aug 27 2012
parent 1100110 <10equals2 gmail.com> writes:
On Mon, 27 Aug 2012 22:39:55 -0500, Era Scarecrow <rtcvb32 yahoo.com>  
wrote:


 On Tuesday, 28 August 2012 at 00:14:34 UTC, Chris Cain wrote:

 On Monday, 27 August 2012 at 23:28:31 UTC, SomeDude wrote:

 I wish Walter went on kickstarter to get public funds allowing him to  
 hire a couple of full time developers.


 I would pitch in $150 for that.


   I'd throw in $50, or $10-$15 each month for as long as it was needed.  
 Perhaps putting up a option to give donations via paypal or something.  
 Then when he accumulates a thousand or something that would hire for a  
 while, Maybe get some help from FSF as well.


I would throw in for that.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Aug 27 2012
prev sibling next sibling parent "mist" <none none.none> writes:
On Monday, 27 August 2012 at 23:28:31 UTC, SomeDude wrote:

 On Saturday, 25 August 2012 at 19:48:33 UTC, Jeff Nowakowski 
 wrote:


 As for the IDE, he mentioned Scala, and there the developers 
 made an effort to support the IDE in the compiler so that work 
 wouldn't be duplicated and the IDE would support the latest 
 language release. They also had funding and hired somebody to 
 work on the Eclipse plugin full time.


 I wish Walter went on kickstarter to get public funds allowing 
 him to hire a couple of full time developers.


vote++
Aug 28 2012
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 28/08/12 00:28, SomeDude wrote:

 I wish Walter went on kickstarter to get public funds allowing him to hire a
 couple of full time developers.


Yes, but you have to be cautious about things like that.  Having people paid by 
the project to work on things can demotivate the efforts of other contributors.

There is another project I have some connection to where one of the major 
contributors, a freelance developer, started soliciting donations to enable him 
to dedicate work time to the project, with in particular a promise that if more 
than a certain threshold could be raised, he'd be full-time on it.

The effect of this was decidedly ambivalent, with several project members 
feeling they didn't contribute to the project so that other people could make 
money off it.  It's not clear that the extra time he dedicated was worth the 
loss of those other contributions.

It's a different thing if some 3rd party comes in and says, "OK, we're going to 
pay some of our staff to work on this project."  But having the project itself 
select certain people to be paid, or having project members solicit donations
in 
this way, can be problematic.

At the very least you'd need to define the parameters and expectations quite 
precisely, so that people can see where it does or doesn't overlap with work 
they might have contributed as volunteers.
Aug 30 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Aug 2012 08:54:33 -0400, Joseph Rushton Wakeling  
<joseph.wakeling webdrake.net> wrote:


 On 28/08/12 00:28, SomeDude wrote:

 I wish Walter went on kickstarter to get public funds allowing him to  
 hire a
 couple of full time developers.


 Yes, but you have to be cautious about things like that.  Having people  
 paid by the project to work on things can demotivate the efforts of  
 other contributors.

 There is another project I have some connection to where one of the  
 major contributors, a freelance developer, started soliciting donations  
 to enable him to dedicate work time to the project, with in particular a  
 promise that if more than a certain threshold could be raised, he'd be  
 full-time on it.

 The effect of this was decidedly ambivalent, with several project  
 members feeling they didn't contribute to the project so that other  
 people could make money off it.  It's not clear that the extra time he  
 dedicated was worth the loss of those other contributions.

 It's a different thing if some 3rd party comes in and says, "OK, we're  
 going to pay some of our staff to work on this project."  But having the  
 project itself select certain people to be paid, or having project  
 members solicit donations in this way, can be problematic.

 At the very least you'd need to define the parameters and expectations  
 quite precisely, so that people can see where it does or doesn't overlap  
 with work they might have contributed as volunteers.


Um what?  If someone wants to solicit donations in order to work on D,  
there is *nothing* that we can do to stop that.

What do we do, reject that contributor?  I think that's a much worse plan  
of action.  D needs all the help it can get, and if someone can only  
contribute full time if he gets paid, and people are willing to pay him,  
GREAT!

I fail to see how this story has any moral except, "some people hate  
money".  Which really isn't most of us here.  Myself in particular, I have  
very little time to work on D because I have a full time job so I can  
support my family, and a paying side gig.

-Steve
Aug 30 2012
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 30/08/12 14:21, Steven Schveighoffer wrote:

 Um what?  If someone wants to solicit donations in order to work on D, there is
 *nothing* that we can do to stop that.


I'm not saying that you can or should stop independent individuals soliciting 
donations.  It's just something where everyone concerned needs to think a bit 
about how it can affect the dynamic of the project.

In this case, someone was suggesting that a donation drive be organized by the 
project, to pay developers to work on something.  That's something a bit 
different, because it's _the project_ saying who gets paid, and for what.  It 
can work, but it can mean people are less motivated to volunteer, because gosh, 
the project can afford to _hire_ people to do this now.


 What do we do, reject that contributor?  I think that's a much worse plan of
 action.  D needs all the help it can get, and if someone can only contribute
 full time if he gets paid, and people are willing to pay him, GREAT!


That's why I said it makes a difference whether payment is organized by 3rd 
parties, or the project itself.  (In the case of the project I referred to, it 
was technically one developer soliciting for donations, but he was so core to 
the project that it felt a bit different to some people.)


 I fail to see how this story has any moral except, "some people hate money".
 Which really isn't most of us here.  Myself in particular, I have very little
 time to work on D because I have a full time job so I can support my family,
and
 a paying side gig.


Yes.  Now consider how you might react if the parts of D you were contributing 
to were also being worked on by people who the D project was paying for.  You 
might well feel, "Well, that stuff already has sufficient resources dedicated
to 
it, so I'm going to use my limited free time for something else."  That's not 
hating money, just a rational reaction to the fact that your limited volunteer 
time should be put where it's needed most.

But if enough volunteer contributors react like that, the project suffers.

Simon Phipps (former Sun Open Source chief, now on the OSI board) has written
an 
interesting article about the dynamics of money in open source projects, worth 
reading:
http://blogs.computerworlduk.com/simon-says/2011/09/should-you-donate-to-open-source-projects/index.htm
Aug 30 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Aug 2012 10:27:39 -0400, Joseph Rushton Wakeling  
<joseph.wakeling webdrake.net> wrote:


 On 30/08/12 14:21, Steven Schveighoffer wrote:

 I fail to see how this story has any moral except, "some people hate  
 money".
 Which really isn't most of us here.  Myself in particular, I have very  
 little
 time to work on D because I have a full time job so I can support my  
 family, and
 a paying side gig.


 Yes.  Now consider how you might react if the parts of D you were  
 contributing to were also being worked on by people who the D project  
 was paying for.  You might well feel, "Well, that stuff already has  
 sufficient resources dedicated to it, so I'm going to use my limited  
 free time for something else."  That's not hating money, just a rational  
 reaction to the fact that your limited volunteer time should be put  
 where it's needed most.

 But if enough volunteer contributors react like that, the project  
 suffers.


I cannot relate to that at all.  Nor do I think the project suffers.

When I work on a piece of D, it's because I want it to work the way I  
want.  I want to have influence over its design so it appeals to me.  It  
has nothing to do with who paid for what.  In fact, I don't even care  
about getting credit, I just want a language that I enjoy using!

I throw out suggestions all the time, but they are almost always ignored.   
But when I actually contribute, it has a much better chance of success,  
and I have had several of my contributions included in both Tango and D2  
phobos/druntime.

My gut feeling (no research for this, just how I feel) is that people who  
feel their time is better spent elsewhere, but truly want to contribute,  
probably would work on some other part of D that *doesn't* have resources  
dedicated to it, or a library that uses D.  I don't think D suffers for  
this.

I think some people have a somewhat biased attitude that if a project  
isn't developed by all volunteers, it's "impure".  I know there are some  
who won't even touch D because of DMD's license, even though that has  
nothing to do with produced code :)  I don't know if this applies to your  
anecdote because I know nothing about the community there.  But there  
isn't much we can do about that, and if we don't have those people on  
board, I don't really think we are worse off.  I want to have people that  
are good at solving problems, good at writing code, and *want* to  
contribute, not people who have alternate agendas.  We cannot cater to  
every social viewpoint, so the best thing we can do is produce the best  
language we can, and if we do, others will want to use it and contribute  
to it.

Now, if D got to the point where it frequently preferred code that was  
paid for over code that was donated, solely based on the fact that one was  
paid for and one wasn't, that would not work out well.  We can't be biased  
in either direction, and then I think our community will be fine.


 Simon Phipps (former Sun Open Source chief, now on the OSI board) has  
 written an interesting article about the dynamics of money in open  
 source projects, worth reading:
 http://blogs.computerworlduk.com/simon-says/2011/09/should-you-donate-to-open-source-projects/index.htm


I will check it out, thanks.

-Steve
Aug 30 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Aug 2012 11:21:06 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Thu, 30 Aug 2012 10:27:39 -0400, Joseph Rushton Wakeling  
 <joseph.wakeling webdrake.net> wrote:

 Simon Phipps (former Sun Open Source chief, now on the OSI board) has  
 written an interesting article about the dynamics of money in open  
 source projects, worth reading:
 http://blogs.computerworlduk.com/simon-says/2011/09/should-you-donate-to-open-source-projects/index.htm


 I will check it out, thanks.


An interesting point of view, and I can see how paying someone could be  
misconstrued.  If Walter was given money to hire people, and he hired  
certain already-active members of the community, it might leave some  
thinking "why them and not me?"  One thing I think would pose a large  
dilemma is who do you pay?  Someone who is very active in contributing to  
D may not be able to contribute more, simply because there are just so  
many hours in a day.  I'm amazed sometimes as to how some people do so  
much work on D!  This means we're just handing out bonuses without getting  
much back.

But then would you pay someone like me, who has contributed very  
sporadically?  Maybe it makes it so I can contribute more, but it's almost  
like rewarding me for being less active!

Paying someone in the community is like giving a company more money to  
develop a project faster, but instead they just pay their existing staff  
more.

If, however, Walter simply just hired two developers *outside* the  
community, and added them to the project, it would be a net gain for  
everyone.  Two previously uninvolved developers who could make the  
development go faster.  Perhaps that's the only real way to fund a project  
like this.

I agree with Mr. Phipps that the best way probably to fund an open source  
project is to purchase from a company who benefits from the language  
itself, and let them know why.  Then they have an incentive to make  
contributions ensuring they continue to receive that revenue.

I don't find this much different than paying someone who volunteers via  
donations, except that you aren't getting any benefit via service, just  
better language.

Thanks for the interesting read!

-Steve
Aug 30 2012
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 30 August 2012 at 17:52:27 UTC, Steven Schveighoffer 
wrote:

 An interesting point of view, and I can see how paying someone 
 could be misconstrued.  If Walter was given money to hire 
 people, and he hired certain already-active members of the 
 community, it might leave some thinking "why them and not me?"  
 One thing I think would pose a large dilemma is who do you pay?



 Someone who is very active in contributing to D may not be able 
 to contribute more, simply because there are just so many hours 
 in a day.  I'm amazed sometimes as to how some people do so 
 much work on D!  This means we're just handing out bonuses 
 without getting much back.


  In my view this has very little to do with money, it has to do 
with time. Most likely most of us are freelancers or doing 
something that isn't getting us some 60k a year (or more) jobs, 
and although some of us likely are more skilled and able to take 
those jobs, the economy prevents to a degree.

  I would see the donations being used to hire someone NOT as a 
bonus or as incentive, but to allow them to tell their work place 
"hey I'll be taking a month off". If they love programming they 
may very well give more than their $15-$20/hr (or whatever is 
decided) wage they are accepting for the work; I know I certainly 
would.
Aug 30 2012
prev sibling next sibling parent reply "Andrew McKinlay" <apmckinlay gmail.com> writes:
 His post comes down to: "I like to have an IDE and I prefer Java
 because I already know Java."


Just for the record, I am no particular fan of the Java language 
- it's weak, boring, and often tedious. Any "loyalty" to Java 
that I have is not because I already know it, but because it is a 
robust, stable, performant platform with a rich ecosystem of 
libraries and tools. I am very open to new languages. I learnt 
Java from scratch several years ago for a specific project. Other 
than that I have primarily used C++. I am always looking at 
language alternatives like Scala, Clojure, Erlang, and D.

You're right that I like to have an IDE. But I think that applies 
to a large percentage of programmers.

I fully admit to being a newbie at D and because of that I may be 
making incorrect judgements. However, keep in mind that every 
newcomer to D will be in the same position. If a language scares 
away newcomers, then it will have trouble gaining traction.


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


One relevance to D development may be that there are a lot of 
Java developers out there who are a potential source of converts. 
Right or wrong, they are going to make many of the same  
comparisons as me.

All the things I mention can (and I'm sure will) be improved - 
the garbage collector, the libraries, the tools, etc.

Just to be clear, I would love to see D be successful.
Aug 25 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/25/2012 08:36 PM, Andrew McKinlay wrote:

 His post comes down to: "I like to have an IDE and I prefer Java
 because I already know Java."


 Just for the record, I am no particular fan of the Java language - it's
 weak, boring, and often tedious.
 Any "loyalty" to Java that I have is not
 because I already know it,  but because it is a robust, stable,
 performant platform with a rich ecosystem of libraries and tools. I am
 very open to new languages. I learnt Java from scratch several years ago
 for a specific project. Other than that I have primarily used C++. I am
 always looking at language alternatives like Scala, Clojure, Erlang, and D.

 You're right that I like to have an IDE. But I think that applies to a
 large percentage of programmers.

 I fully admit to being a newbie at D and because of that I may be making
 incorrect judgements.


Oh, I am certainly not claiming that the judgements are incorrect. You
should use whatever works for you.


 However, keep in mind that every newcomer to D
 will be in the same position. If a language scares away newcomers, then
 it will have trouble gaining traction.


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


 One relevance to D development may be that there are a lot of Java
 developers out there who are a potential source of converts.


Well, Java is a huge platform as well as a language. Furthermore, the
fact that the language feels weak, boring and often tedious is probably
a significant part of the reason it has been successful. I wouldn't
expect many people intimately familiar with the Java platform to
convert to D.


 Right or wrong, they are going to make many of the same comparisons as me.


Exactly. What I mean by 'because I already know Java' is, that those
comparisons will naturally be somewhat biased towards what
the developer already knows. It is not really a matter of right or
wrong. A programmer is likely to (attempt to) apply patterns that work
well in a language he is familiar with.


 All the things I mention can (and I'm sure will) be improved - the
 garbage collector, the libraries, the tools, etc.

 Just to be clear, I would love to see D be successful.


I think the blog post is entirely reasonable.
I was reacting mostly to Bjoern's statement "IMO a voice, D core
developers should listen to.", whose nature I may have misunderstood.

The point is, I don't think it is lacking on insight which efforts
might be worth following, it is more a matter of having enough
sufficiently skilled people dedicate their limited spare time. ;)
Aug 25 2012
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 25 August 2012 at 00:20:57 UTC, Timon Gehr wrote:

 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?


No, he points out that 1) templates inherently complexify code 2) 
make refactoring difficult, especially automated refactoring, 
something that is supported by major modern IDEs and not by text 
editors like vim/emacs, because the former have some knowledge of 
the AST, not the latter.
I know the first point is debatable; maybe there is less need for 
refactoring as the language is more expressive, but when 
refactoring is needed, it's probably much more difficult than in
Aug 25 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 25 Aug 2012 22:36:08 +0200
"SomeDude" <lovelydear mailmetrash.com> wrote:


 On Saturday, 25 August 2012 at 00:20:57 UTC, Timon Gehr wrote:

 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?


 
 No, he points out that 1) templates inherently complexify code 2) 
 make refactoring difficult, especially automated refactoring, 
 something that is supported by major modern IDEs and not by text 
 editors like vim/emacs, because the former have some knowledge of 
 the AST, not the latter.
 I know the first point is debatable; maybe there is less need for 
 refactoring as the language is more expressive, but when 
 refactoring is needed, it's probably much more difficult than in 



FWIW: Personally, I would argue that (as nice as automated refactoring
admittedly is) putting up with a simplistic less expressive language for
the sake of niceties like (perfect) automated refactoring is putting the
cart before the horse. It'd be like putting up with starvation because
you can't find a salad marked "organic". Having automated refactoring be
less-than-perfect is a price, yes, but it's a very small price to pay
for the much bigger savings you get from having powerful
metaprogramming.

Plus, certain non-automatic refactorings would be a much bigger pain in
something like Java anyway because of, for example, the lack of type
inference and the increased need for code to be non-generic in the first
place.

My $0.02, anyway.
Aug 25 2012
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 25 August 2012 at 22:40:56 UTC, Nick Sabalausky 
wrote:

 On Sat, 25 Aug 2012 22:36:08 +0200
 "SomeDude" <lovelydear mailmetrash.com> wrote:


 On Saturday, 25 August 2012 at 00:20:57 UTC, Timon Gehr wrote:

 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?


 
 No, he points out that 1) templates inherently complexify code 
 2) make refactoring difficult, especially automated 
 refactoring, something that is supported by major modern IDEs 
 and not by text editors like vim/emacs, because the former 
 have some knowledge of the AST, not the latter.
 I know the first point is debatable; maybe there is less need 
 for refactoring as the language is more expressive, but when 
 refactoring is needed, it's probably much more difficult than 



 FWIW: Personally, I would argue that (as nice as automated 
 refactoring
 admittedly is) putting up with a simplistic less expressive 
 language for
 the sake of niceties like (perfect) automated refactoring is 
 putting the
 cart before the horse. It'd be like putting up with starvation 
 because
 you can't find a salad marked "organic". Having automated 
 refactoring be
 less-than-perfect is a price, yes, but it's a very small price 
 to pay
 for the much bigger savings you get from having powerful
 metaprogramming.

 Plus, certain non-automatic refactorings would be a much bigger 
 pain in
 something like Java anyway because of, for example, the lack of 
 type
 inference and the increased need for code to be non-generic in 
 the first
 place.

 My $0.02, anyway.


I mostly agree, although some basic refactoring like a simple 
renaming is also very handy.
Aug 27 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Aug 24 2012
next sibling parent reply Pragma Tix <pragmatix orange.fr> writes:
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 ..
Aug 24 2012
parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Aug 24 2012
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Aug 25 2012
next sibling parent "Chris Cain" <clcain uncg.edu> writes:
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.
Aug 25 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/25/2012 6:03 AM, Peter Alexander wrote:

 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.


How many IDEs can handle the C preprocessor, with token pasting and all, when 
refactoring?
Aug 25 2012
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 25 August 2012 at 19:39:47 UTC, Walter Bright wrote:

 On 8/25/2012 6:03 AM, Peter Alexander wrote:

 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.


 How many IDEs can handle the C preprocessor, with token pasting 
 and all, when refactoring?


Straw man - I didn't suggest that the C preprocessor was any 
better. C++ is similarly criticised for its poor IDE support 

templates. If you haven't seen the level of support that (for 

it out. I imagine the situation with Java and Eclipse is similar, 
but I don't have any experience there.
Aug 25 2012
next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 25 August 2012 at 20:06:59 UTC, Peter Alexander 
wrote:

 On Saturday, 25 August 2012 at 19:39:47 UTC, Walter Bright 
 wrote:

 On 8/25/2012 6:03 AM, Peter Alexander wrote:

 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.


 How many IDEs can handle the C preprocessor, with token 
 pasting and all, when refactoring?


 Straw man - I didn't suggest that the C preprocessor was any 
 better. C++ is similarly criticised for its poor IDE support 

 templates. If you haven't seen the level of support that (for 

 checking it out. I imagine the situation with Java and Eclipse 
 is similar, but I don't have any experience there.


For the record, here is what IntelliJ IDEA (a now free IDE) 
offers:
http://www.jetbrains.com/idea/features/refactoring.html
Aug 25 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/25/2012 1:06 PM, Peter Alexander wrote:

 On Saturday, 25 August 2012 at 19:39:47 UTC, Walter Bright wrote:

 On 8/25/2012 6:03 AM, Peter Alexander wrote:

 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.


 How many IDEs can handle the C preprocessor, with token pasting and all, when
 refactoring?


 Straw man - I didn't suggest that the C preprocessor was any better. C++ is

 due to the pre-processor and templates. If you haven't seen the level of
support

 out. I imagine the situation with Java and Eclipse is similar, but I don't have
 any experience there.



I don't agree it's a straw man - it's the point. A perfect job is not necessary 
in order for people to find automated refactoring useful.
Aug 25 2012
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 25 August 2012 at 21:17:55 UTC, Walter Bright wrote:

 On 8/25/2012 1:06 PM, Peter Alexander wrote:

 On Saturday, 25 August 2012 at 19:39:47 UTC, Walter Bright 
 wrote:

 On 8/25/2012 6:03 AM, Peter Alexander wrote:

 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.


 How many IDEs can handle the C preprocessor, with token 
 pasting and all, when
 refactoring?


 Straw man - I didn't suggest that the C preprocessor was any 
 better. C++ is
 similarly criticised for its poor IDE support (when compared 

 due to the pre-processor and templates. If you haven't seen 
 the level of support

 recommend checking it
 out. I imagine the situation with Java and Eclipse is similar, 
 but I don't have
 any experience there.



 I don't agree it's a straw man - it's the point. A perfect job 
 is not necessary in order for people to find automated 
 refactoring useful.


I'm not sure how your previous comment supports that point.

C (and C++) don't do a perfect job, but as I said, they are 
similarly criticised for their poor IDE support.

I do agree with you: the tools don't need to do a perfect job, 
but I worry if they'll even be able to do a reasonable job. 
Templates, CTFE, mixins, etc. are all rampant in D, so I worry 
about the amount of work required for tool-developers to support 
a respectable subset of D that will stand up to criticism from
Aug 25 2012
parent reply "Araq" <rumpf_a web.de> writes:
Because of reflection, refactoring can't do an accurate job in
Aug 25 2012
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Saturday, 25 August 2012 at 22:11:12 UTC, Araq wrote:

 Because of reflection, refactoring can't do an accurate job in 




Uh, you're being VERY unfair here.


code.

Calling them "inaccurate" because of reflection is completely 
missing the point.

C++ or D tools can't even do their compile-time job to begin 
with, even forgetting about RTTI.
Aug 25 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 26 Aug 2012 00:33:01 +0200
"Mehrdad" <wfunction hotmail.com> wrote:


 On Saturday, 25 August 2012 at 22:11:12 UTC, Araq wrote:

 Because of reflection, refactoring can't do an accurate job in 



 
 
 Uh, you're being VERY unfair here.
 

 code.
 
 Calling them "inaccurate" because of reflection is completely 
 missing the point.
 
 C++ or D tools can't even do their compile-time job to begin 
 with, even forgetting about RTTI.


No, I think Araq raises a good point here: Reflection screws with
automated refactoring, period, and Java and D both have reflection.

Whether that reflection is runtime or compile-time doesn't change
anything here. Java code that uses reflection can't be perfectly
auto-refactored. D code that uses reflection can't be perfectly
auto-refactored. Same effect either way. Saying that it counts for
compile-time but not for run-time is just arbitrarily moving the
goal-posts.

Of course, D also has other things besides reflection that can mess with
refactorings, like mixins+ctfe, but hey, anyone can still stick a
code-generator in front of a call to "javac", and you've got the same
problem (only clunkier to use and even *less* likely to be
refactorable). Not saying that's as common in Java as mixins+ctfe are
in D, but the point is: it's features/techniques that mess with
auto-refactoring, not languages.

It *is* a tradeoff, admittedly. But I'm not sure how fair it is to
blame a language for it rather than a technique. And I think that
many people, even if not *all* (can't please all the people all the
time), would find the tradeoff to be a net gain. I certainly do, at
least.
Aug 25 2012
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 25 August 2012 at 23:02:52 UTC, Nick Sabalausky 
wrote:

 Of course, D also has other things besides reflection that can 
 mess with
 refactorings, like mixins+ctfe, but hey, anyone can still stick 
 a
 code-generator in front of a call to "javac", and you've got 
 the same
 problem (only clunkier to use and even *less* likely to be
 refactorable).


Code generation is evil. I now avoid almost all the frameworks 
based on code generation, it almost always generates crap.
Aug 27 2012
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 25 Aug 2012 14:16:27 -0700
Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/25/2012 1:06 PM, Peter Alexander wrote:

 Straw man - I didn't suggest that the C preprocessor was any
 better. C++ is similarly criticised for its poor IDE support (when

 If you haven't seen the level of support that (for example) Visual

 the situation with Java and Eclipse is similar, but I don't have
 any experience there.


 
 
 I don't agree it's a straw man - it's the point. A perfect job is not
 necessary in order for people to find automated refactoring useful.
 


C++ is known for having a lot of problems - Heck, that's why D exists.
So saying "C++ does XX" doesn't necessarily excuse anything. And I
don't think it does excuse it in this case. 

However, that said, I think C++ does work as an example of why it's not
*necessarily* a terribile thing that D isn't perfectly
auto-refactorable. And FWIW, I do think D's metaprogramming power *is*
perfectly sufficient justification for it's refactoring difficulty.

And do I agree that "A perfect job is not necessary in order for people
to find automated refactoring useful."
Aug 25 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-25 21:39, Walter Bright wrote:


 How many IDEs can handle the C preprocessor, with token pasting and all,
 when refactoring?


1. Any IDE based on libclang should be able to handle this. Xcode 4 uses 
libclang.

2. The C preprocessor is no excuse to why we shouldn't have good 
refactoring tools for D.

-- 
/Jacob Carlborg
Aug 25 2012
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 25 August 2012 at 22:32:10 UTC, Jacob Carlborg wrote:

 On 2012-08-25 21:39, Walter Bright wrote:


 How many IDEs can handle the C preprocessor, with token 
 pasting and all,
 when refactoring?


 1. Any IDE based on libclang should be able to handle this. 
 Xcode 4 uses libclang.

 2. The C preprocessor is no excuse to why we shouldn't have 
 good refactoring tools for D.


For (1), I think Walter is referring to something like this:


#define

int GLOBAL(foo);
g_foo = 123;


I don't think XCode would allow you to right-click the g_foo and 
rename it. It's not possible in the general case.
Aug 25 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/25/2012 3:32 PM, Jacob Carlborg wrote:

 On 2012-08-25 21:39, Walter Bright wrote:


 How many IDEs can handle the C preprocessor, with token pasting and all,
 when refactoring?


 1. Any IDE based on libclang should be able to handle this. Xcode 4 uses
libclang.

 2. The C preprocessor is no excuse to why we shouldn't have good refactoring
 tools for D.


I'm not saying it's an excuse, I'm saying that people don't say C IDEs are a 
failure because of this.
Aug 25 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 26/08/2012 01:14, Walter Bright a écrit :

 On 8/25/2012 3:32 PM, Jacob Carlborg wrote:

 On 2012-08-25 21:39, Walter Bright wrote:


 How many IDEs can handle the C preprocessor, with token pasting and all,
 when refactoring?


 1. Any IDE based on libclang should be able to handle this. Xcode 4
 uses libclang.

 2. The C preprocessor is no excuse to why we shouldn't have good
 refactoring
 tools for D.


 I'm not saying it's an excuse, I'm saying that people don't say C IDEs
 are a failure because of this.


Well this is known problem. People expect from new languages to solve 
such problems.
Aug 27 2012
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
 2. The C preprocessor is no excuse to why we shouldn't have 
 good refactoring tools for D.


I think the author of the original message including many who 
agree with him forget a simple fact - coding an IDE that can 
handle D's generative abilities is not a trivial thing to do.

I can whine about many things that I miss, but I can't expect 
from an open-source community to spend thousands of working hours 
coding extra-dificult features...
Sep 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-06 19:25, Dejan Lekic wrote:


 I think the author of the original message including many who agree with
 him forget a simple fact - coding an IDE that can handle D's generative
 abilities is not a trivial thing to do.

 I can whine about many things that I miss, but I can't expect from an
 open-source community to spend thousands of working hours coding
 extra-dificult features...


Yeah, but I'm tried of constantly hearing: "But C++ doesn't have that", 
"That doesn't work in C++". Like it would be some kind of excuse when 
basically the rest of the languages out there has it or can do it.

-- 
/Jacob Carlborg
Sep 06 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 25 August 2012 at 19:39:47 UTC, Walter Bright wrote:

 How many IDEs can handle the C preprocessor, with token pasting 
 and all, when refactoring?


KDevelop, for example.

David
Aug 26 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 25 Aug 2012 15:39:14 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 8/25/2012 6:03 AM, Peter Alexander wrote:

 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.


 How many IDEs can handle the C preprocessor, with token pasting and all,  
 when refactoring?


Not any that I have used.  In fact, in one project that I was working from  
an existing code base, I had to configure Visual Studio 2010 to NOT fade  
out what it thought was commented code, because it was wrong.  Otherwise,  
it was too distracting.

Here is what I think:

1. an IDE can be built that refactors non-meta-generated code quite well,  
D is easily parsed.
2. Said IDE can be provided hooks so when it does encounter mixins, it can  
be told what things mean.

For example, I use netbeans to write php -- a dynamic language.  There are  
no real variable type declarations, so when you start typing,  
auto-complete sucks unless you have told the IDE what a variable is.  You  
do so like this:

/**
   var Type
  */
var $varname;

And now the IDE assumes you have stored a Type into $varname, so when you  
type $this->varname->, it completes with the members of Type.  Without the  
comment, I get nothing.

A similar approach could be taken with mixins, like bitfields.  You  
identify what the parameters to the mixin are, and then the IDE can take  
appropriate actions.

For things like bitfields, which are considered core language constructs  
in phobos, the IDE may actually be made more intelligent and detect this  
automatically.

I don't think this is an unsolvable problem...

-Steve
Aug 30 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-30 15:35, Steven Schveighoffer wrote:


 Not any that I have used.  In fact, in one project that I was working
 from an existing code base, I had to configure Visual Studio 2010 to NOT
 fade out what it thought was commented code, because it was wrong.
 Otherwise, it was too distracting.


As I replied to Walter's post, any IDE based on Clang should be able to 
handle this. Xcode 4 has Clang integrate from the start, There's a 
plugin for Sublime Text and I'm pretty sure there's a plugin for vim.


 Here is what I think:

 1. an IDE can be built that refactors non-meta-generated code quite
 well, D is easily parsed.
 2. Said IDE can be provided hooks so when it does encounter mixins, it
 can be told what things mean.

 For example, I use netbeans to write php -- a dynamic language.  There
 are no real variable type declarations, so when you start typing,
 auto-complete sucks unless you have told the IDE what a variable is.
 You do so like this:

 /**
    var Type
   */
 var $varname;

 And now the IDE assumes you have stored a Type into $varname, so when
 you type $this->varname->, it completes with the members of Type.
 Without the comment, I get nothing.


I've tried RubyMine with Ruby on Rails. It worked surprisingly well 
without needing to add extra comments. It knows the actual types of the 
variables and can provide accurate autocompletion in most cases. When 
I'm saying this you should know that there are many methods in Rails 
that are generated dynamically or uses method_missing (opDispatch).

The same company have made an IDE for PHP as well, you might what to 
give it a try:

http://www.jetbrains.com/phpstorm/


 A similar approach could be taken with mixins, like bitfields.  You
 identify what the parameters to the mixin are, and then the IDE can take
 appropriate actions.

 For things like bitfields, which are considered core language constructs
 in phobos, the IDE may actually be made more intelligent and detect this
 automatically.

 I don't think this is an unsolvable problem...


I think a compiler library that can lex, parse and do full semantic 
analysis should be able to handle this.

-- 
/Jacob Carlborg
Aug 30 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 30 Aug 2012 14:26:41 -0400, Jacob Carlborg <doob me.com> wrote:


 On 2012-08-30 15:35, Steven Schveighoffer wrote:


 Not any that I have used.  In fact, in one project that I was working
 from an existing code base, I had to configure Visual Studio 2010 to NOT
 fade out what it thought was commented code, because it was wrong.
 Otherwise, it was too distracting.


 As I replied to Walter's post, any IDE based on Clang should be able to  
 handle this. Xcode 4 has Clang integrate from the start, There's a  
 plugin for Sublime Text and I'm pretty sure there's a plugin for vim.


I don't think the problem is solvable with CPP, because it's not always  
possible to know how it's included.

For example, if I have a file x.h which does:

#ifdef A
#define B
#endif

And I edit x.h, how does it know the original source file which includes  
x.h does or doesn't define A before including x.h?  That is the issue I  
was having.

I suppose you could refactor any C or C++ source files, but not header  
files (and most variables/members are defined in header files).

Like the D problem though, there is certainly some level of confidence you  
can have when refactoring if things aren't dependent on #ifdefs.  But I  
wouldn't want to write that code :)


 I've tried RubyMine with Ruby on Rails. It worked surprisingly well  
 without needing to add extra comments. It knows the actual types of the  
 variables and can provide accurate autocompletion in most cases. When  
 I'm saying this you should know that there are many methods in Rails  
 that are generated dynamically or uses method_missing (opDispatch).

 The same company have made an IDE for PHP as well, you might what to  
 give it a try:

 http://www.jetbrains.com/phpstorm/


Thanks, I will look at it.  Netbeans does do a pretty good job knowing  
when you have previously assigned a variable that it is of that type, but  
there are pieces that cause it to give up, like if the variable comes as a  
parameter to a function, or is not assigned in the file you are editing,  
or it is put into an array (that last one I really hate).


 I think a compiler library that can lex, parse and do full semantic  
 analysis should be able to handle this.


I think so too.  And even if it's not perfect, as long as it can *tell*  
when it's not possible, that is OK.

-Steve
Aug 30 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-30 21:00, Steven Schveighoffer wrote:


 I don't think the problem is solvable with CPP, because it's not always
 possible to know how it's included.

 For example, if I have a file x.h which does:

 #ifdef A
 #define B
 #endif

 And I edit x.h, how does it know the original source file which includes
 x.h does or doesn't define A before including x.h?  That is the issue I
 was having.


Oh, yeah, that would be a bit complicated :)

-- 
/Jacob Carlborg
Aug 30 2012
prev sibling next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 30 August 2012 at 19:00:58 UTC, Steven Schveighoffer 
wrote:

 And I edit x.h, how does it know the original source file which 
 includes x.h does or doesn't define A before including x.h?  
 That is the issue I was having.


I don't understand why that should be so difficult...

Why can't the IDE just scan all the #include dependencies in an 
internal database, and update them accordingly?
Aug 30 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-31 06:54, Mehrdad wrote:


 Why can't the IDE just scan all the #include dependencies in an internal
 database, and update them accordingly?


Say you're building a library and you're currently editing one of the 
header files. You have know idea where that file can be used in the 
future. There's possible that the file isn't used at all in the library, 
i.e. no file includes it.

-- 
/Jacob Carlborg
Aug 30 2012
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 31 August 2012 at 06:30:04 UTC, Jacob Carlborg wrote:

 On 2012-08-31 06:54, Mehrdad wrote:


 Why can't the IDE just scan all the #include dependencies in 
 an internal
 database, and update them accordingly?


 Say you're building a library and you're currently editing one 
 of the header files. You have know idea where that file can be 
 used in the future.



Huh? Who is trying to predict the future?

We're talking about the C/C++ macro example here, with _existing_ 
code in the _same_ project...
Aug 31 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-08-31 09:14, Mehrdad wrote:


 Huh? Who is trying to predict the future?

 We're talking about the C/C++ macro example here, with _existing_ code
 in the _same_ project...


If you limit yourself to the existing project that's very different. I 
would like to have autocompletion across project boundaries.

-- 
/Jacob Carlborg
Aug 31 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 31 Aug 2012 00:54:07 -0400, Mehrdad <wfunction hotmail.com> wrote:


 On Thursday, 30 August 2012 at 19:00:58 UTC, Steven Schveighoffer wrote:

 And I edit x.h, how does it know the original source file which  
 includes x.h does or doesn't define A before including x.h?  That is  
 the issue I was having.


 I don't understand why that should be so difficult...

 Why can't the IDE just scan all the #include dependencies in an internal  
 database, and update them accordingly?


a.c:

#define A
#include "x.h"

b.c:

#include "x.h"

Now, depending on whether you are editing x.h in terms of a.c or b.c, the  
#ifdef is active or not.  The IDE will be wrong no matter what choice it  
makes.

This is why I like how external definitions and imports cannot affect D  
modules.

-Steve
Aug 31 2012
parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 31 August 2012 at 15:41:10 UTC, Steven Schveighoffer 
wrote:

 On Fri, 31 Aug 2012 00:54:07 -0400, Mehrdad 
 <wfunction hotmail.com> wrote:


 On Thursday, 30 August 2012 at 19:00:58 UTC, Steven 
 Schveighoffer wrote:

 And I edit x.h, how does it know the original source file 
 which includes x.h does or doesn't define A before including 
 x.h?  That is the issue I was having.


 I don't understand why that should be so difficult...

 Why can't the IDE just scan all the #include dependencies in 
 an internal database, and update them accordingly?


 a.c:

 #define A
 #include "x.h"

 b.c:

 #include "x.h"

 Now, depending on whether you are editing x.h in terms of a.c 
 or b.c, the #ifdef is active or not.  The IDE will be wrong no 
 matter what choice it makes.

 This is why I like how external definitions and imports cannot 
 affect D modules.

 -Steve



Ooh I see.

The IDE could just give you a warning though, and ask which ones 
you want to rename. It might be "wrong" but it'd still be very 
usable.
Aug 31 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-30 21:00, Steven Schveighoffer wrote:


 For example, if I have a file x.h which does:

 #ifdef A
 #define B
 #endif

 And I edit x.h, how does it know the original source file which includes
 x.h does or doesn't define A before including x.h?  That is the issue I
 was having.


There's no possible why to know that. So when you're editing a 
particular header file it will only know about which other files it 
includes. It would be possible to detect if "A" is defined in a file 
that is included by x.h but not the other way around.

-- 
/Jacob Carlborg
Aug 30 2012
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 30 Aug 2012 09:35:31 -0400
"Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 
 For example, I use netbeans to write php -- a dynamic language.
 There are no real variable type declarations, so when you start
 typing, auto-complete sucks unless you have told the IDE what a
 variable is.  You do so like this:
 
 /**
    var Type
   */
 var $varname;
 
 And now the IDE assumes you have stored a Type into $varname, so when
 you type $this->varname->, it completes with the members of Type.
 


Wow, so it's basically reinventing static typing poorly. You've got
the boilerplate and verbosity of a poorly-made static type system, with
very few of the benefits (ie, IDE-awareness and nothing else).

I'll never understand the dynamic world.
Sep 01 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-09-02 03:21, Nick Sabalausky wrote:


 Wow, so it's basically reinventing static typing poorly. You've got
 the boilerplate and verbosity of a poorly-made static type system, with
 very few of the benefits (ie, IDE-awareness and nothing else).

 I'll never understand the dynamic world.


You can of course build a tool that does type checking if you use these 
kind of comments. Something like Dart seems to do, but Dart has built-in 
support for static types.

-- 
/Jacob Carlborg
Sep 02 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 01 Sep 2012 21:21:50 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On Thu, 30 Aug 2012 09:35:31 -0400
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 For example, I use netbeans to write php -- a dynamic language.
 There are no real variable type declarations, so when you start
 typing, auto-complete sucks unless you have told the IDE what a
 variable is.  You do so like this:

 /**
    var Type
   */
 var $varname;

 And now the IDE assumes you have stored a Type into $varname, so when
 you type $this->varname->, it completes with the members of Type.


 Wow, so it's basically reinventing static typing poorly. You've got
 the boilerplate and verbosity of a poorly-made static type system, with
 very few of the benefits (ie, IDE-awareness and nothing else).

 I'll never understand the dynamic world.


I have on occasion had the benefit of simply adding a member variable to  
instances of a class when I needed it without having to burden the rest of  
the code with knowing about that variable.  I felt dirty doing it...

But I think you are right -- "fake" static typing does not come close to  
actual static typing.  If I could count all the time I've wasted because I  
mistyped a member variable name, and it "just worked", blissfully reading  
null instead of the variable I've set, it would probably add up to days.   
Thankfully, netbeans 7 is better at telling me that a variable is  
previously unset or is never used, but it can't be perfect, especially  
with this mess I inherited.  The original author thought "modularity"  
meant importing large pieces of functions from other files, which the IDE  
refuses to correctly interpret.

This, of course, all comes from two guys who really like static typing :)   
We *may* have a biased view.

In any case, it is what it is -- the existing code-base is huge, and I  
have no real desire to rewrite all of it :)  The best I can do is add some  
typing comments and hobble through it (cursing as I go).  If I had a year  
of spare time, I could rewrite it all in D!

-Steve
Sep 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-04 15:59, Steven Schveighoffer wrote:


 I have on occasion had the benefit of simply adding a member variable to
 instances of a class when I needed it without having to burden the rest
 of the code with knowing about that variable.  I felt dirty doing it...

 But I think you are right -- "fake" static typing does not come close to
 actual static typing.  If I could count all the time I've wasted because
 I mistyped a member variable name, and it "just worked", blissfully
 reading null instead of the variable I've set, it would probably add up
 to days.  Thankfully, netbeans 7 is better at telling me that a variable
 is previously unset or is never used, but it can't be perfect,
 especially with this mess I inherited.  The original author thought
 "modularity" meant importing large pieces of functions from other files,
 which the IDE refuses to correctly interpret.

 This, of course, all comes from two guys who really like static typing
 :)  We *may* have a biased view.


I can tell you this, I've wished many times that I had static typing in 
Ruby. I've also wished quite many times I had dynamic typing in D. I 
think optional static typing, like Dart, sounds like a good idea.

I'm currently updating a Rails project to Ruby 1.9 and I really wished I 
had static typing. Just that fact that it won't load file until it's 
actually needed is quite annoying. Finding all the corner cases can be 
quite a lot of work. For example, a partial that is loaded when the 
rendering is triggered by an Ajax request.


 In any case, it is what it is -- the existing code-base is huge, and I
 have no real desire to rewrite all of it :)  The best I can do is add
 some typing comments and hobble through it (cursing as I go).  If I had
 a year of spare time, I could rewrite it all in D!

 -Steve



-- 
/Jacob Carlborg
Sep 04 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 4 September 2012 at 19:18:05 UTC, Jacob Carlborg 
wrote:

 I've also wished quite many times I had dynamic typing in D.


I think we're *fairly* close with things like std.variant,
especially combined with some helpers. Take a look:

Variant a = 10;
string b = a; // can't, and I say that's good, usually
b = a.coerce!string; // works

But, to get a dynamic feel, you don't want to write
out coerce!type. I kinda want it to be auto. So,

Variant a = 10;
string b;

b.dset = a; // dset means dynamic set

This is pretty doable in D today.

auto dset(T, U)(ref T t, U u) {
         return t = to!T(u);
}

Then call with UFCS + property getter syntax.


The other thing is to do function calls. And we might
be able to pull that off too with something like

void foo(string a, string b) {}

auto dcall(alias func, T...)(T args) {
	import std.traits;
	ParameterTypeTuple!func typedArgs;
	foreach(i, ref arg; typedArgs)
		arg.dset = args[i];
	return func(typedArgs);
}

dcall!foo(a, b);



Thus your user code is pretty type-agnostic, with loose
types when requested.
Sep 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-04 21:39, Adam D. Ruppe wrote:

 On Tuesday, 4 September 2012 at 19:18:05 UTC, Jacob Carlborg wrote:

 I've also wished quite many times I had dynamic typing in D.


 I think we're *fairly* close with things like std.variant,
 especially combined with some helpers. Take a look:

 Variant a = 10;
 string b = a; // can't, and I say that's good, usually
 b = a.coerce!string; // works

 But, to get a dynamic feel, you don't want to write
 out coerce!type. I kinda want it to be auto. So,

 Variant a = 10;
 string b;

 b.dset = a; // dset means dynamic set

 This is pretty doable in D today.


When I said "dynamic typing" that was a bit misleading. It's more the 
dynamic nature of Ruby I like. For example:

* Open classes
* Reflection - adding methods, calling a method via a string, introspection
* Have executing code in all level of scopes
* Eval

The comparable features in a static language would probably AST-macros, 
annotations and similar features. If D had those features then I 
probably wouldn't want dynamic typing that much.

-- 
/Jacob Carlborg
Sep 04 2012
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 05 Sep 2012 08:34:34 +0200
Jacob Carlborg <doob me.com> wrote:

 
 When I said "dynamic typing" that was a bit misleading. It's more the 
 dynamic nature of Ruby I like. For example:
 
 * Open classes
 * Reflection - adding methods, calling a method via a string,
 introspection


As far as monkey patching, I find *not* having that to be a major
feature. :)

While a lot of runtime reflection *can* be built in D (even if it
isn't all there right now), I am kind of annoyed at some of the
limitations. Like how it's impossible (at either compile-time or
runtime) to find the subclasses of a class. Uhh, actually that's the
only limitation I know of. There might be more though.


 * Have executing code in all level of scopes


Not sure what sure mean by this?


 * Eval
 


Needs polish, but:

https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/process.d#cl-49

Usage:

string str;

str = q{ return 42; };
assert( eval!int(str) == 42 );

str = q{ return "Test string".dup; };
assert( eval!(char[])(str) == "Test string" );

:)

Granted, there'd probably be a lot less overhead doing that in Ruby or
JS. But it works, more or less.
Sep 05 2012
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 5 September 2012 at 18:22:16 UTC, Nick Sabalausky 
wrote:

 * Have executing code in all level of scopes


 Not sure what sure mean by this?


In Javascript for instance, you don't need to use functions at 
all and can just write code that will run at the very top of the 
file.


Sometimes with D, I use a little helper program that adds some 
phobos imports and a void main(){} wrapper to the input, thus 
getting this same effect.


I don't like it in anything but short programs though... main() 
rox.
Sep 05 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-05 20:43, Adam D. Ruppe wrote:


 In Javascript for instance, you don't need to use functions at all and
 can just write code that will run at the very top of the file.


 Sometimes with D, I use a little helper program that adds some phobos
 imports and a void main(){} wrapper to the input, thus getting this same
 effect.


 I don't like it in anything but short programs though... main() rox.


In Ruby you can also but executable code in class declarations. It's 
heavily used in Ruby on Rails' ActiveRecord implementation:

class Post
   has_many :comments
end

class Comment
   belongs_to :post
end

"belongs_to" and "has_many" are plain class methods. When this is 
possible you rarely need user defined attributes/annotations and similar 
features.

-- 
/Jacob Carlborg
Sep 05 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-05 20:22, Nick Sabalausky wrote:


 As far as monkey patching, I find *not* having that to be a major
 feature. :)


It has saved my ass several times. Especially recently when we started 
to update Ruby 1.8 to 1.9.


 While a lot of runtime reflection *can* be built in D (even if it
 isn't all there right now), I am kind of annoyed at some of the
 limitations. Like how it's impossible (at either compile-time or
 runtime) to find the subclasses of a class. Uhh, actually that's the
 only limitation I know of. There might be more though.


Hmm, I actually haven't needed that in D yet. But it's so cool in Ruby, 
you can sort of hook up an event and be notified when a subclass 
inherits from its base class. The subclass then gets passed to the event 
handler and you can add new methods on the subclass.


 * Have executing code in all level of scopes


 Not sure what sure mean by this?


The obvious one is you can have executable code at the global level. The 
less obvious one is you can have executable code when declaring a class:

def bar
end

class Foo

end

This is heavily used in Ruby on Rails' ActiveRecord implementation:

class Post
   has_many :comments
end

class Comment
   belongs_to :post
end

The cool thing is that these are just plain method class (class 
methods). They will add some methods to context where they are called. 
Any other language would probably need annotations or some other kind of 
extra language feature to get this nice looking syntax.

Currently in D you would probably use template mixins:

class Post
{
     mixin hasMany!("comments);
}

class Comment
{
     mixin belongsTo!("post");
}

But I think this use case would be perfect for AST-macros or user 
defined attributes/annotations:

class Post
{
      hasMany("comments");
}

class Comment
{
      belongsTo!("post");
}



 Needs polish, but:

 https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/process.d#cl-49

 Usage:

 string str;

 str = q{ return 42; };
 assert( eval!int(str) == 42 );

 str = q{ return "Test string".dup; };
 assert( eval!(char[])(str) == "Test string" );

 :)

 Granted, there'd probably be a lot less overhead doing that in Ruby or
 JS. But it works, more or less.


I'll have to take a look at that sometime. Is it that code that calls 
RDMD to compile and run it?

-- 
/Jacob Carlborg
Sep 05 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 06 Sep 2012 08:44:20 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2012-09-05 20:22, Nick Sabalausky wrote:

 Needs polish, but:

 https://bitbucket.org/Abscissa/semitwistdtools/src/977820d5dcb0/src/semitwist/util/process.d#cl-49

 Usage:

 string str;

 str = q{ return 42; };
 assert( eval!int(str) == 42 );

 str = q{ return "Test string".dup; };
 assert( eval!(char[])(str) == "Test string" );


 
 I'll have to take a look at that sometime. Is it that code that calls 
 RDMD to compile and run it?
 


Yes.
Sep 06 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 6 Sep 2012 04:38:24 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:


 On Thu, 06 Sep 2012 08:44:20 +0200
 Jacob Carlborg <doob me.com> wrote:
 

 
 I'll have to take a look at that sometime. Is it that code that
 calls RDMD to compile and run it?
 


 
 Yes.
 


The only other trick is (de)serializing the eval's return value to send
it back through stdout. It'd probably be a good job for Orange ;)
Sep 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-06 10:41, Nick Sabalausky wrote:


 The only other trick is (de)serializing the eval's return value to send
 it back through stdout. It'd probably be a good job for Orange ;)


Hehe :)

-- 
/Jacob Carlborg
Sep 06 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 05 Sep 2012 14:22:43 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:



 While a lot of runtime reflection *can* be built in D (even if it
 isn't all there right now), I am kind of annoyed at some of the
 limitations. Like how it's impossible (at either compile-time or
 runtime) to find the subclasses of a class. Uhh, actually that's the
 only limitation I know of. There might be more though.


I think this actually is one of the few reflection things possible :)

If you look in druntime, there is a way to iterate over all class TypeInfo  
objects, and you can simply see if the class type inherits from your  
target.

It may be inefficient, but possible (and you can build a tree based on  
this so further lookups are not slow).

-Steve
Sep 06 2012
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 5 September 2012 at 06:34:01 UTC, Jacob Carlborg 
wrote:

 When I said "dynamic typing" that was a bit misleading. It's 
 more the dynamic nature of Ruby I like. For example:


Yeah, that stuff can be good. Something I've been playing with in 
D is a prototype inheritance class, that you can add methods to 
dynamically. 9/10 times, I don't want this, but sometimes it is 
just nice to have.

But, right now, the horribly broken  property is really ruining 
it (and opCall being strangely designed in structs takes some fun 
out, but it works pretty well with classes... which means you 
have to use new at declaration, but meh, not a big deal). 
Everything else is pretty doable though.

Granted you couldn't use it to extend regular D stuff, but UFCS 
lets us sorta cheat on those anyway.


 The comparable features in a static language would probably 
 AST-macros, annotations and similar features. If D had those 
 features then I probably wouldn't want dynamic typing that much.


Annotations are my last dream for D, just bog simple attach 
metadata. My other wishes are pretty much little bug fixes.
Sep 05 2012
prev sibling next sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 4 September 2012 at 19:18:05 UTC, Jacob Carlborg 
wrote:

 On 2012-09-04 15:59, Steven Schveighoffer wrote:


 I have on occasion had the benefit of simply adding a member 
 variable to
 instances of a class when I needed it without having to burden 
 the rest
 of the code with knowing about that variable.  I felt dirty 
 doing it...

 But I think you are right -- "fake" static typing does not 
 come close to
 actual static typing.  If I could count all the time I've 
 wasted because
 I mistyped a member variable name, and it "just worked", 
 blissfully
 reading null instead of the variable I've set, it would 
 probably add up
 to days.  Thankfully, netbeans 7 is better at telling me that 
 a variable
 is previously unset or is never used, but it can't be perfect,
 especially with this mess I inherited.  The original author 
 thought
 "modularity" meant importing large pieces of functions from 
 other files,
 which the IDE refuses to correctly interpret.

 This, of course, all comes from two guys who really like 
 static typing
 :)  We *may* have a biased view.


 I can tell you this, I've wished many times that I had static 
 typing in Ruby. I've also wished quite many times I had dynamic 
 typing in D. I think optional static typing, like Dart, sounds 
 like a good idea.

 I'm currently updating a Rails project to Ruby 1.9 and I really 
 wished I had static typing. Just that fact that it won't load 
 file until it's actually needed is quite annoying. Finding all 
 the corner cases can be quite a lot of work. For example, a 
 partial that is loaded when the rendering is triggered by an 
 Ajax request.


 In any case, it is what it is -- the existing code-base is 
 huge, and I
 have no real desire to rewrite all of it :)  The best I can do 
 is add
 some typing comments and hobble through it (cursing as I go).  
 If I had
 a year of spare time, I could rewrite it all in D!

 -Steve




The only experience I've had with dynamic typing (in Python), I 
can say I hated it. I prefer to write Java code, which I think 
tells a lot about my love for dynamic typing. I probably wouldn't 
mind writing some Lua code, but not in the large. Unless you are 
working in an environment which changes all the time, so that you 
need to adapt your code very quickly, dynamic languages are a 
waste of time above ~10,000 lines of code in my opinion.
Sep 04 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, September 04, 2012 22:44:07 SomeDude wrote:

 The only experience I've had with dynamic typing (in Python), I
 can say I hated it. I prefer to write Java code, which I think
 tells a lot about my love for dynamic typing. I probably wouldn't
 mind writing some Lua code, but not in the large. Unless you are
 working in an environment which changes all the time, so that you
 need to adapt your code very quickly, dynamic languages are a
 waste of time above ~10,000 lines of code in my opinion.


Agreed. I avoid dynamic languages like the plague. I'll only touch them when I 
have to or when I need a script which won't require recompilation to run (and 
if D ever becomes widespread enough that you can reasonably rely on it being 
on a Linux system, then all of my scripts will probably be written in D). 
Dynamic typing is evil.

- Jonathan M Davis
Sep 04 2012
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 4 September 2012 at 21:08:42 UTC, Jonathan M Davis 
wrote:

 Dynamic typing is evil.
 - Jonathan M Davis


This is now my email signature. Thanks.
Sep 04 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Chris Cain:


 This is now my email signature. Thanks.


Fundamentalism has no place in engineering.

Bye,
bearophile
Sep 04 2012
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 4 September 2012 at 21:46:12 UTC, bearophile wrote:

 Fundamentalism has no place in engineering.


It just made me smile. I still sometimes use Python for small 
projects and I'm going to be getting more serious about learning 
Javascript (and maybe a variant like CoffeeScript). However, 
dynamic typing has frustrated me plenty of times in the past... 
Mr. Davis' statement reflects my feelings for it.
Sep 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-05 00:13, Chris Cain wrote:


 It just made me smile. I still sometimes use Python for small projects
 and I'm going to be getting more serious about learning Javascript (and
 maybe a variant like CoffeeScript). However, dynamic typing has
 frustrated me plenty of times in the past... Mr. Davis' statement
 reflects my feelings for it.


I suggest you go with CoffeeScript, I see know reason to use plain 
JavaScript. It fixes a couple of problems with JavaScript but you can 
never escape that fact that it compiles down to JavaScript and that's 
basically the only language you can run in a browser.

-- 
/Jacob Carlborg
Sep 05 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 04 Sep 2012 22:44:07 +0200
"SomeDude" <lovelydear mailmetrash.com> wrote:

 The only experience I've had with dynamic typing (in Python), I 
 can say I hated it. I prefer to write Java code, which I think 
 tells a lot about my love for dynamic typing.
 


Wow, now *that's* hard-core static typing fan :)

Languages like ActionScript 2 and PHP (ie, the worst of the dynamic
bunch - or at least I *hope*) have conditioned me to develop a severe
allergic reaction to any and all dynamic typing. But if my only static
choice were Java, I think it's very possible I'd end up a dynamic guy
(but with something more sensible than AS2 or PHP, of course).
Dynamic has major flaws IMO, but Java's a pedantic rubber-coated pain.

But I can still relate, though. As much as I hate C++ (How much? This
much:
<https://semitwist.com/articles/article/view/top-d-features-i-miss-in-c>),
I'm actually still *happier* using C++ on my current "real world"
project than I was with the dynamic languages I've used in other
projects. C++ sucks, but as long I stick mainly to "C with classes",
I find it more manageable than dynamic weirdness. (But I grew up with
C/C++, so that probably does help me tolerate it.)


 Unless you are 
 working in an environment which changes all the time, so that you 
 need to adapt your code very quickly, dynamic languages are a 
 waste of time above ~10,000 lines of code in my opinion.



Personally, I'd knock a zero or two off that figure.
Sep 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-05 08:17, Nick Sabalausky wrote:


 Wow, now *that's* hard-core static typing fan :)

 Languages like ActionScript 2 and PHP (ie, the worst of the dynamic
 bunch - or at least I *hope*) have conditioned me to develop a severe
 allergic reaction to any and all dynamic typing. But if my only static
 choice were Java, I think it's very possible I'd end up a dynamic guy
 (but with something more sensible than AS2 or PHP, of course).
 Dynamic has major flaws IMO, but Java's a pedantic rubber-coated pain.


ActionScript and PHP are probably two of the worst languages. Ruby is 
way better.

-- 
/Jacob Carlborg
Sep 04 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 05 Sep 2012 08:39:37 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2012-09-05 08:17, Nick Sabalausky wrote:
 

 Wow, now *that's* hard-core static typing fan :)

 Languages like ActionScript 2 and PHP (ie, the worst of the dynamic
 bunch - or at least I *hope*) have conditioned me to develop a
 severe allergic reaction to any and all dynamic typing. But if my
 only static choice were Java, I think it's very possible I'd end up
 a dynamic guy (but with something more sensible than AS2 or PHP, of
 course). Dynamic has major flaws IMO, but Java's a pedantic
 rubber-coated pain.


 
 ActionScript and PHP are probably two of the worst languages. Ruby is 
 way better.
 


Totally agree. Although the odd thing with Ruby though is any time
I use it I feel like I have no idea what's *really* going on. Maybe
it's the lax parsing rules, or maybe I just need to learn it better, I
dunno. But yea, I'll agree AS2/PHP are to dynamic typing what C++/Java
are to static typing: Bad examples ;)
Sep 05 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-05 09:14, Nick Sabalausky wrote:


 Totally agree. Although the odd thing with Ruby though is any time
 I use it I feel like I have no idea what's *really* going on. Maybe
 it's the lax parsing rules, or maybe I just need to learn it better, I
 dunno. But yea, I'll agree AS2/PHP are to dynamic typing what C++/Java
 are to static typing: Bad examples ;)


As with all things: that's the beauty, but can also a problem. The fact 
that you can call a method without parentheses is one of the things 
making it possible to create so nice looking DSL in Ruby.

But if you don't know the rules or every detail of the syntax that can 
cause problems. Example:




def foo (arg)
end







Then, as with all languages, you can do stupid things. For example, in 
Ruby it's possible to overwrite the whole standard library:

class String

   def upcase
     downcase
   end
end

This can also be really useful. You can fix a bug in a library, but put 
the fix in your own project. No need for recompilation or distributing 
patched versions of libraries. The fix is distributed with the rest of 
your project.

But you can do just as stupid things in C or D. For example, you can 
write to arbitrary memory address.

-- 
/Jacob Carlborg
Sep 05 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-09-04 22:44, SomeDude wrote:


 The only experience I've had with dynamic typing (in Python), I can say
 I hated it. I prefer to write Java code, which I think tells a lot about
 my love for dynamic typing. I probably wouldn't mind writing some Lua
 code, but not in the large. Unless you are working in an environment
 which changes all the time, so that you need to adapt your code very
 quickly, dynamic languages are a waste of time above ~10,000 lines of
 code in my opinion.


I see your point. But I think Java is a bad example, it's too verbose 
and doesn't give you enough features to express the code you want to write.

-- 
/Jacob Carlborg
Sep 04 2012
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 04 Sep 2012 21:18:41 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2012-09-04 15:59, Steven Schveighoffer wrote:

 This, of course, all comes from two guys who really like static
 typing :)  We *may* have a biased view.


 


I like to think it's the other way around: I like static typing
*because* it's better ;)


 I can tell you this, I've wished many times that I had static typing
 in Ruby. I've also wished quite many times I had dynamic typing in D.
 I think optional static typing, like Dart, sounds like a good idea.
 


I don't know if maybe my experience is different from usual, but
personally, I haven't *ever* wished I had dynamic typing in D.
Templates and (on rare occasion) variants have always been perfectly
sufficient (and even preferable) in any cases I've ever had.
Sep 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-05 07:55, Nick Sabalausky wrote:


 I don't know if maybe my experience is different from usual, but
 personally, I haven't *ever* wished I had dynamic typing in D.
 Templates and (on rare occasion) variants have always been perfectly
 sufficient (and even preferable) in any cases I've ever had.


As I replied to Adam, "dynamic typing" was a bit misleading. It's more 
the dynamic nature of Ruby I like. For example:

* Open classes
* Reflection
* Eval
* Executable code in all levels of scope

So if D had something comparable, like AST-macros, better reflection and 
annotations I would be more happy.

-- 
/Jacob Carlborg
Sep 04 2012
prev sibling next sibling parent reply "Niklas" <niklas.volcz gmail.com> writes:
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
Aug 25 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.08.2012 16:43, schrieb Niklas:

 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



Quite true.

I was used to IDEs from the MS-DOS, early Windows days.

In the university I discovered Emacs and VI, and joined Emacs side for 
many years.

Until I joined the world of enterprise development, where the IDEs 
usually rule.

The amount of tooling Emacs, Netbeans, InteliJ, Visual Studio offer for 
code navigation, refactoring, code analysis, visual debugging and 
integration beats what Emacs and VI are able to offer. Even with tons of 
customization, it is not the same thing.

With background static analysis I can even forget my strong typing 
(Pascal family) bias against C and C++.

Emacs used to be considered as bloated as we consider IDEs nowadays. :)

--
Paulo
Aug 25 2012
prev sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
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 didn't see anything of relevance for this group, but it is a 
good statement of current affairs that those looking at D should 
be aware of. The "const" system is something I avoid and 
recommend avoiding, but look forward to seeing the final pieces 
being put together.

Personally I think he is completely wrong on the template note 
(for one development on hit has basically been complete for 
years). Templates are simple in D, but as you learn them you will 
want more and that power you want will be the complexity. I also 
don't think you need to know much about them to use them. 
However, Any question asked here will likely receive feedback on 
how to use templates/mixins and all their extravagance because of 
how idiomatic D they are.
Aug 25 2012