Jump to page: 1 24  
Page
Thread overview
Lang.NEXT panel
Jun 04, 2014
Joakim
Jun 10, 2014
justme
Jun 12, 2014
Nick Sabalausky
Jun 12, 2014
Atila Neves
Jun 12, 2014
John Carter
Jun 12, 2014
Dicebot
Jun 12, 2014
deadalnix
Jun 13, 2014
w0rp
Re: Dfix
Jun 14, 2014
Stefan Koch
Re: Lang.NEXT panel (dfix)
Jun 16, 2014
Bruno Medeiros
Jun 16, 2014
Stefan Koch
Jun 16, 2014
Bruno Medeiros
Jun 16, 2014
Stefan Koch
Jun 17, 2014
Bruno Medeiros
Jun 17, 2014
Jacob Carlborg
Jun 17, 2014
Bruno Medeiros
Jun 17, 2014
Bruno Medeiros
Jun 17, 2014
Bruno Medeiros
Jun 17, 2014
deadalnix
Jun 17, 2014
Bruno Medeiros
Jun 17, 2014
Dicebot
Jun 20, 2014
Bruno Medeiros
Jun 20, 2014
Dicebot
Jun 17, 2014
Jacob Carlborg
Jun 17, 2014
Bruno Medeiros
Jun 18, 2014
Jacob Carlborg
Jun 19, 2014
Stefan Koch
Jun 19, 2014
Brian Schott
Jun 20, 2014
Stefan Koch
Jun 20, 2014
Bruno Medeiros
Jun 13, 2014
Jacob Carlborg
Jun 12, 2014
Brian Schott
June 04, 2014
Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/

Andrei
June 04, 2014
On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:
> Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/
>
> Andrei

Nice panel.  Not much really new there, but gives an idea of what you language designers are thinking about and who you are.  I was never much interested in Go, but after seeing Pike for the first time, was a bit more interested in his language.  Funny to see Bjarne swinging his legs on the high stool like a kid. :)
June 10, 2014
On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:
> Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/
>
> Andrei

IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version.

That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it.
June 12, 2014
On 6/10/2014 12:35 PM, justme wrote:
> On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:
>> Of possible interest.
>> http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/
>>
>>
>> Andrei
>
> IMHO, the coolest thing was when Rob Pike told about the tool they made
> for automatically upgrading user source code to their next language
> version.
>
> That should be quite easy to implement now in D, and once done, would
> give much needed room for breaking changes we feel should be done. Pike
> seemed to be extremely satisfied they did it.

Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D.

It's a cute trick, but not a worthwhile use of development resources.

June 12, 2014
On 6/12/14, 10:40 AM, Nick Sabalausky wrote:
> On 6/10/2014 12:35 PM, justme wrote:
>> On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:
>>> Of possible interest.
>>> http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/
>>>
>>>
>>>
>>> Andrei
>>
>> IMHO, the coolest thing was when Rob Pike told about the tool they made
>> for automatically upgrading user source code to their next language
>> version.
>>
>> That should be quite easy to implement now in D, and once done, would
>> give much needed room for breaking changes we feel should be done. Pike
>> seemed to be extremely satisfied they did it.
>
> Personally, I wouldn't be comfortable trusting such a tool. Besides, I
> find that upgrading a codebase to a newer language version is one of the
> most trivial tasks I ever face in software development - even in D.
>
> It's a cute trick, but not a worthwhile use of development resources.

I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors.

I got convinced a dfix tool would be a strategic component of D's offering going forward.


Andrei

June 12, 2014
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu wrote:
> On 6/12/14, 10:40 AM, Nick Sabalausky wrote:
>> On 6/10/2014 12:35 PM, justme wrote:
>>> On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:
>>>> Of possible interest.
>>>> http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/
>>>>
>>>>
>>>>
>>>> Andrei
>>>
>>> IMHO, the coolest thing was when Rob Pike told about the tool they made
>>> for automatically upgrading user source code to their next language
>>> version.
>>>
>>> That should be quite easy to implement now in D, and once done, would
>>> give much needed room for breaking changes we feel should be done. Pike
>>> seemed to be extremely satisfied they did it.
>>
>> Personally, I wouldn't be comfortable trusting such a tool. Besides, I
>> find that upgrading a codebase to a newer language version is one of the
>> most trivial tasks I ever face in software development - even in D.
>>
>> It's a cute trick, but not a worthwhile use of development resources.
>
> I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors.
>
> I got convinced a dfix tool would be a strategic component of D's offering going forward.
>
>
> Andrei

I thought the same. I was considering writing it, actually. Imagine how having the tool would have influenced the "final by default" discussion. Amongst others, of course.

Atila

June 12, 2014
Yes!

That is only one of the reasons to have that ability.

Almost more important is automated reasoning about very large codebases.

What are the global properties?

Where are the "antipatterns" of use and can we fix them?

Can we "lint" away large classes of defects?

Even Stroustrup believes such tools would be useful for C++.


On Fri, Jun 13, 2014 at 5:53 AM, Andrei Alexandrescu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:

> On 6/12/14, 10:40 AM, Nick Sabalausky wrote:
>
>> On 6/10/2014 12:35 PM, justme wrote:
>>
>>> On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:
>>>
>>>> Of possible interest. http://www.reddit.com/r/programming/comments/278twt/ panel_systems_programming_in_2014_and_beyond/
>>>>
>>>>
>>>>
>>>> Andrei
>>>>
>>>
>>> IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version.
>>>
>>> That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it.
>>>
>>
>> Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D.
>>
>> It's a cute trick, but not a worthwhile use of development resources.
>>
>
> I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors.
>
> I got convinced a dfix tool would be a strategic component of D's offering going forward.
>
>
> Andrei
>
>


-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 

------------------------------
This email, including any attachments, is only for the intended recipient.
It is subject to copyright, is confidential and may be the subject of legal
or other privilege, none of which is waived or lost by reason of this
transmission.
If you are not an intended recipient, you may not use, disseminate,
distribute or reproduce such email, any attachments, or any part thereof.
If you have received a message in error, please notify the sender
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or
corrupted during transmission nor can we guarantee that any email or any
attachments are free from computer viruses or other conditions which may
damage or interfere with recipient data, hardware or software. The
recipient relies upon its own procedures and assumes all risk of use and of
opening any attachments.
------------------------------


June 12, 2014
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu wrote:
> I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors.
>
> I got convinced a dfix tool would be a strategic component of D's offering going forward.

It essentially comes down to persistent compiler-as-a-library issue :( Tools like dscanner can help with some of more simple transition cases but anything more complicated is likely to require full semantic analysis.
June 12, 2014
On Tuesday, 10 June 2014 at 16:35:23 UTC, justme wrote:
> That should be quite easy to implement now in D

What makes you say this?
June 12, 2014
On Thursday, 12 June 2014 at 20:48:10 UTC, Dicebot wrote:
> On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu wrote:
>> I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors.
>>
>> I got convinced a dfix tool would be a strategic component of D's offering going forward.
>
> It essentially comes down to persistent compiler-as-a-library issue :( Tools like dscanner can help with some of more simple transition cases but anything more complicated is likely to require full semantic analysis.

If only we had such a tool !
« First   ‹ Prev
1 2 3 4