On 12/06/14 19:40, Nick Sabalausky wrote:

> 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 think the complete opposite. I migrated a Rails 2.3 app to Rails 3.x and from Ruby 1.8 to 1.9, it was an enormous task. Took probably six months. Also, it doesn't help to not have any tests and Ruby code in the database.

-- 
/Jacob Carlborg

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 am strongly in favour of a 'dfix' tool. There exist historical problems with languages, and you really must break them to make things better.

Douglas Crockford was pushing for '~' for string concatenation in ECMAScript 6, making '+' do only additon. This would have been very similar to how D handles the two, in an arguably correct manner, but the commity wouldn't agree to it because it would force everyone to change their code. So in the end ES6 is full of features, some useful, most seem nonsensical to me, but it doesn't really fix any of the issues in ES5, because it's almost totally backwards compatible so old code still works.

So I think having tools like gofix and deprecation warnings mitigate this issue massively, and it's especially easier when you're using an ahead-of-time compiled language like D. So we can make changes which break code, but just get rid of cruft likely to cause errors. I can't think of nearly as many examples of error-prone things in D that I can think of in ES6, though.

As it happens I am writing a kind of DFIX  on top of DScanner right at the moment.
There are a few details to sort out. But I should have some small demo pretty soon.

Regrards, Stefan

On 12/06/2014 18:53, 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
>

What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there.
Even I am working on a tool that can be easily retrofitted for this purpose.

Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 6/16/14, 6:43 AM, Bruno Medeiros wrote:
> On 12/06/2014 18:53, Andrei Alexandrescu wrote:
>> I got convinced a dfix tool would be a strategic component of D's
>> offering going forward.
>>
>>
>> Andrei
>>
>
> What's keeping us from having such a tool? It seems that after one has a
> decent parser (that also keeps tracks of the source ranges of AST
> nodes), it's easy to write code that does syntactic modifications and
> then rewrites the source code. And there's several D parsers out there
> already - so it should be too much effort to get there.
> Even I am working on a tool that can be easily retrofitted for this
> purpose.
>
> Or maybe I am misunderstanding the amount of semantic analysis that
> would typically be required? Can someone give some examples of
> modifications that would be useful for such a dfix tool? (I haven't yet
> had the time to watch the full panel video, if that's relevant)

No magic required. -- Andrei

> What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there.
> Even I am working on a tool that can be easily retrofitted for this purpose.
>
> Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant)

Well, my recent efforts lead my to belief that I am in over my head with this.
But ... many sufficiently simple transformations can be done with a complex regex and for me that is faster, given the trouble I have with writing ASTMatchers for Dscanner.
BTW. Does anyone know a good approch to a DSL describeing AST-transformation patterns ?
What I currently have is SQL-like Syntax and I feel it won't scale to complex  selction and/or transformation patterns.
Input is welcome.

On 16/06/2014 21:43, Stefan Koch wrote:
>> What's keeping us from having such a tool? It seems that after one has
>> a decent parser (that also keeps tracks of the source ranges of AST
>> nodes), it's easy to write code that does syntactic modifications and
>> then rewrites the source code. And there's several D parsers out there
>> already - so it should be too much effort to get there.
>> Even I am working on a tool that can be easily retrofitted for this
>> purpose.
>>
>> Or maybe I am misunderstanding the amount of semantic analysis that
>> would typically be required? Can someone give some examples of
>> modifications that would be useful for such a dfix tool? (I haven't
>> yet had the time to watch the full panel video, if that's relevant)
>
> Well, my recent efforts lead my to belief that I am in over my head with
> this.
> But ... many sufficiently simple transformations can be done with a
> complex regex and for me that is faster, given the trouble I have with
> writing ASTMatchers for Dscanner.
> BTW. Does anyone know a good approch to a DSL describeing
> AST-transformation patterns ?
> What I currently have is SQL-like Syntax and I feel it won't scale to
> complex  selction and/or transformation patterns.
> Input is welcome.

DSL?! You crazy bro?
If you are using DScanner, just let people use D itself to write their own custom AST transformation code. With DUB it should be super easy to compile that code and run it on the target D code.

This solution is vastly more simple than inventing your own DSL, and scales way better as a general purpose language will have much more power that selection/transformation patterns.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

> DSL?! You crazy bro?
> If you are using DScanner, just let people use D itself to write their own custom AST transformation code. With DUB it should be super easy to compile that code and run it on the target D code.
>
> This solution is vastly more simple than inventing your own DSL, and scales way better as a general purpose language will have much more power that selection/transformation patterns.

The thing I have in mind should be really easy for simple tasks
as in
`if constuctor in any class has parameter of type "oldRouter" change that parameter to type "new Router"`
but i habe yet to find a good notation for that

On 16/06/14 15:43, Bruno Medeiros wrote:

> What's keeping us from having such a tool? It seems that after one has a
> decent parser (that also keeps tracks of the source ranges of AST
> nodes), it's easy to write code that does syntactic modifications and
> then rewrites the source code. And there's several D parsers out there
> already - so it should be too much effort to get there.
> Even I am working on a tool that can be easily retrofitted for this
> purpose.
>
> Or maybe I am misunderstanding the amount of semantic analysis that
> would typically be required? Can someone give some examples of
> modifications that would be useful for such a dfix tool? (I haven't yet
> had the time to watch the full panel video, if that's relevant)

* The parser haven't been available for that long (I think)
* Can they handle whole language?
* Semantic analysis is needed. Otherwise as soon as someone uses templates or mixins the tool won't properly work

-- 
/Jacob Carlborg

On 16/06/2014 22:10, Stefan Koch wrote:
> The thing I have in mind should be really easy for simple tasks
> as in
> `if constuctor in any class has parameter of type "oldRouter" change
> that parameter to type "new Router"`
> but i habe yet to find a good notation for that

I guess a DSL for simple manipulations can be ok to have. But for more complex stuff better to just use the language the parser is written in.
I'd guess most people would just be using pre-written manipulations anyways.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros