There's no inherent problem with designing language with available tools in mind. After all, what we put in the language is a strict subset of what's viable in a compiler.
IMHO Swift should care more about separation of language and tools due to its long-term ambition: is it a good language out side of the most typical experience? If I edit the source with my favorite editor, on Linux, and/or compile with an alternative compiler, can I get a similar experience ?
A language that conquers the world shouldn't depend on tools to be awesome.
Daniel Duan
···
Sent from my iPhone
On Apr 10, 2017, at 10:22 AM, Sean Heber <sean@fifthace.com> wrote:
On Apr 10, 2017, at 11:38 AM, Daniel Duan <daniel@duan.org> wrote:
Using tools isn't a bad thing. Designing language assuming users are using tools with certain capability is kind of a bad thing.
I see this sentiment on this list a lot. Where does it come from? Is there any supporting research? What drives it?
(I don’t mean to pick on Daniel - I’m curious about this overall from anyone that has sources. It has become such a prevailing refrain at times that I think it’d be best for everyone if we knew if it was even true!)
There's no inherent problem with designing language with available tools in mind. After all, what we put in the language is a strict subset of what's viable in a compiler.
IMHO Swift should care more about separation of language and tools due to its long-term ambition: is it a good language out side of the most typical experience? If I edit the source with my favorite editor, on Linux, and/or compile with an alternative compiler, can I get a similar experience ?
A language that conquers the world shouldn't depend on tools to be awesome.
I agree with this. I just don’t think inference depends on tools. It only depends on reasonable judgement by authors. The same can be said for many features that we don’t want to do without. Inference just happens to be an area where tools can help out when 1) a beginner or someone new to Swift is reading the code or 2) the author left off an annotation where maybe they should have included one.
···
On Apr 10, 2017, at 12:48 PM, Daniel Duan <daniel@duan.org> wrote:
Daniel Duan
Sent from my iPhone
On Apr 10, 2017, at 10:22 AM, Sean Heber <sean@fifthace.com> wrote:
On Apr 10, 2017, at 11:38 AM, Daniel Duan <daniel@duan.org> wrote:
Using tools isn't a bad thing. Designing language assuming users are using tools with certain capability is kind of a bad thing.
I see this sentiment on this list a lot. Where does it come from? Is there any supporting research? What drives it?
(I don’t mean to pick on Daniel - I’m curious about this overall from anyone that has sources. It has become such a prevailing refrain at times that I think it’d be best for everyone if we knew if it was even true!)
Using tools isn't a bad thing. Designing language assuming users are using tools with certain capability is kind of a bad thing.
I see this sentiment on this list a lot. Where does it come from? Is there any supporting research? What drives it?
I personally am one of those people advocating not to design it around an IDE for these reasons:
- GitHub (or other SCM)
- support for other OSs (as Swift is designed not just for Mac/iOS)
- non-Xcode IDEs. Believe it or not, from time to time I reach for other apps, such as CodeRunner.
···
On Apr 10, 2017, at 7:22 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:
On Apr 10, 2017, at 11:38 AM, Daniel Duan <daniel@duan.org> wrote:
(I don’t mean to pick on Daniel - I’m curious about this overall from anyone that has sources. It has become such a prevailing refrain at times that I think it’d be best for everyone if we knew if it was even true!)
There's no inherent problem with designing language with available tools in mind. After all, what we put in the language is a strict subset of what's viable in a compiler.
IMHO Swift should care more about separation of language and tools due to its long-term ambition: is it a good language out side of the most typical experience? If I edit the source with my favorite editor, on Linux, and/or compile with an alternative compiler, can I get a similar experience ?
A language that conquers the world shouldn't depend on tools to be awesome.
I agree with this. I just don’t think inference depends on tools. It only depends on reasonable judgement by authors. The same can be said for many features that we don’t want to do without. Inference just happens to be an area where tools can help out when 1) a beginner or someone new to Swift is reading the code or 2) the author left off an annotation where maybe they should have included one.
I’d argue that a fix-it suggestion should do. Tools can go above and beyond what the the language defines of course.
···
On Apr 10, 2017, at 10:52 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Apr 10, 2017, at 12:48 PM, Daniel Duan <daniel@duan.org> wrote:
Daniel Duan
Sent from my iPhone
On Apr 10, 2017, at 10:22 AM, Sean Heber <sean@fifthace.com> wrote:
On Apr 10, 2017, at 11:38 AM, Daniel Duan <daniel@duan.org> wrote:
Using tools isn't a bad thing. Designing language assuming users are using tools with certain capability is kind of a bad thing.
I see this sentiment on this list a lot. Where does it come from? Is there any supporting research? What drives it?
(I don’t mean to pick on Daniel - I’m curious about this overall from anyone that has sources. It has become such a prevailing refrain at times that I think it’d be best for everyone if we knew if it was even true!)
There's no inherent problem with designing language with available tools in mind. After all, what we put in the language is a strict subset of what's viable in a compiler.
IMHO Swift should care more about separation of language and tools due to its long-term ambition: is it a good language out side of the most typical experience? If I edit the source with my favorite editor, on Linux, and/or compile with an alternative compiler, can I get a similar experience ?
A language that conquers the world shouldn't depend on tools to be awesome.
I agree with this. I just don’t think inference depends on tools. It only depends on reasonable judgement by authors. The same can be said for many features that we don’t want to do without. Inference just happens to be an area where tools can help out when 1) a beginner or someone new to Swift is reading the code or 2) the author left off an annotation where maybe they should have included one.
I’d argue that a fix-it suggestion should do. Tools can go above and beyond what the the language defines of course.
How would the fix-it stay out of the way when the annotation really isn’t intended?
···
On Apr 10, 2017, at 1:04 PM, Daniel Duan <daniel@duan.org> wrote:
On Apr 10, 2017, at 10:52 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Apr 10, 2017, at 12:48 PM, Daniel Duan <daniel@duan.org> wrote:
Daniel Duan
Sent from my iPhone
On Apr 10, 2017, at 10:22 AM, Sean Heber <sean@fifthace.com> wrote:
On Apr 10, 2017, at 11:38 AM, Daniel Duan <daniel@duan.org> wrote:
Using tools isn't a bad thing. Designing language assuming users are using tools with certain capability is kind of a bad thing.
I see this sentiment on this list a lot. Where does it come from? Is there any supporting research? What drives it?
(I don’t mean to pick on Daniel - I’m curious about this overall from anyone that has sources. It has become such a prevailing refrain at times that I think it’d be best for everyone if we knew if it was even true!)