Re: [swift-evolution] Annotation of Warnings/Errors

[Alejandro Martinez via swift-evolution]

I don't think this is a language issue, as said warnings and fix-its
are really useful.
In the other handm when watching other programmers in other languages
without IDE triggering a compile trough the terminal I see that it
allows them to put all their ideas into code first, and then deal with
warnings or errors.

The solution seems just to be "Go to preferences and select the
“General” tab. Make sure that “show live issues” is deselected". At
the end, any option to turn on or off warnings (or even show them at
specific times) should be a setting in the IDE as currently is in
Xcode.

On Sat, Feb 4, 2017 at 1:45 AM, Derrick Ho via swift-evolution
 wrote:
> I feel like warnings showing up as you type are an IDE's responsibility.
>
> Annotations to delay warnings seem like noise.  Once you get used to
> programming you don't need the annotations.
>
> If warnings are bothersome, then turn it off in the Xcode settings!
>
>
>
>
> On Thu, Feb 2, 2017 at 1:34 PM Pierre Monod-Broca via swift-evolution
>  wrote:
>>
>> +1 to the proposal
>> +1 to teach how to remove live issues to beginners, so they have a chance
>> to train at detecting errors without the compiler
>>
>>
>>
>> Pierre
>>
>> Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution
>>  a écrit :
>>
>> +1
>>
>> On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution
>>  wrote:
>>>
>>> One of the biggest issues that I saw while teaching Swift to newbies
>>> (most had not programmed before) is confusion based on the early
>>> warnings/errors that swift/xcode gives you as they type.  What would happen
>>> is that they would type a variable, and it would say… “You haven’t used this
>>> variable” and so they would just click the fixit because they trust the
>>> compiler more than they trust themselves.  This would lead to a point where
>>> they were very confused because some of the code was code they had thought
>>> through, and some of it was changed by random fixits in ways they didn’t
>>> understand… and so it would lead to more errors/fixits until they had errors
>>> which couldn’t be fixed.
>>>
>>>
>>> Imho this is the best example to illustrate that inflationary use of
>>> warnings does more harm than good, and I hope it will be fixed.
>>>
>>> Having a bunch of conditions for warnings looks like overkill to me, and
>>> there are alternatives:
>>> - Only show when building
>>> - Only show in release builds
>>> - Linter
>>>
>>> That said, I'm going out on a limb and claim I already know how to write
>>> code and don't need basic schooling, and showing warnings before I hit
>>> compile is merely a distraction.
>>>
>>> But there are also Playgrounds which seem to be an important aspect of
>>> Swift, especially for newbies who could really benefit from some hints.
>>> There are no linters, no release builds, and even no regular builds for
>>> Playgrounds, so your model is the only one that works for them.
>>>
>>> Bottom line:
>>> +1
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Derrick Ho via swift-evolution]

I feel like warnings showing up as you type are an IDE's responsibility.

Annotations to delay warnings seem like noise.  Once you get used to
programming you don't need the annotations.

If warnings are bothersome, then turn it off in the Xcode settings!




On Thu, Feb 2, 2017 at 1:34 PM Pierre Monod-Broca via swift-evolution <
swift-evolution@swift.org> wrote:

+1 to the proposal
+1 to teach how to remove live issues to beginners, so they have a chance
to train at detecting errors without the compiler



Pierre

Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution <
swift-evolution@swift.org> a écrit :

+1

On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

One of the biggest issues that I saw while teaching Swift to newbies (most
had not programmed before) is confusion based on the early warnings/errors
that swift/xcode gives you as they type.  What would happen is that they
would type a variable, and it would say… “You haven’t used this variable”
and so they would just click the fixit because they trust the compiler more
than they trust themselves.  This would lead to a point where they were
very confused because some of the code was code they had thought through,
and some of it was changed by random fixits in ways they didn’t understand…
and so it would lead to more errors/fixits until they had errors which
couldn’t be fixed.


Imho this is the best example to illustrate that inflationary use of
warnings does more harm than good, and I hope it will be fixed.

Having a bunch of conditions for warnings looks like overkill to me, and
there are alternatives:
- Only show when building
- Only show in release builds
- Linter

That said, I'm going out on a limb and claim I already know how to write
code and don't need basic schooling, and showing warnings before I hit
compile is merely a distraction.

But there are also Playgrounds which seem to be an important aspect of
Swift, especially for newbies who could really benefit from some hints.
There are no linters, no release builds, and even no regular builds for
Playgrounds, so your model is the only one that works for them.

Bottom line:
+1

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Pierre Monod-Broca via swift-evolution]

+1 to the proposal
+1 to teach how to remove live issues to beginners, so they have a chance to 
train at detecting errors without the compiler



Pierre

> Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution 
>  a écrit :
> 
> +1
> 
> On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution 
>  wrote:
>>> One of the biggest issues that I saw while teaching Swift to newbies (most 
>>> had not programmed before) is confusion based on the early warnings/errors 
>>> that swift/xcode gives you as they type.  What would happen is that they 
>>> would type a variable, and it would say… “You haven’t used this variable” 
>>> and so they would just click the fixit because they trust the compiler more 
>>> than they trust themselves.  This would lead to a point where they were 
>>> very confused because some of the code was code they had thought through, 
>>> and some of it was changed by random fixits in ways they didn’t understand… 
>>> and so it would lead to more errors/fixits until they had errors which 
>>> couldn’t be fixed.
>> 
>> 
>> Imho this is the best example to illustrate that inflationary use of 
>> warnings does more harm than good, and I hope it will be fixed.
>> 
>> Having a bunch of conditions for warnings looks like overkill to me, and 
>> there are alternatives:
>> - Only show when building
>> - Only show in release builds
>> - Linter
>> 
>> That said, I'm going out on a limb and claim I already know how to write 
>> code and don't need basic schooling, and showing warnings before I hit 
>> compile is merely a distraction.
>> 
>> But there are also Playgrounds which seem to be an important aspect of 
>> Swift, especially for newbies who could really benefit from some hints.
>> There are no linters, no release builds, and even no regular builds for 
>> Playgrounds, so your model is the only one that works for them.
>> 
>> Bottom line:
>> +1 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Nicolas Fezans via swift-evolution]

+1

On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> One of the biggest issues that I saw while teaching Swift to newbies (most
> had not programmed before) is confusion based on the early warnings/errors
> that swift/xcode gives you as they type.  What would happen is that they
> would type a variable, and it would say… “You haven’t used this variable”
> and so they would just click the fixit because they trust the compiler more
> than they trust themselves.  This would lead to a point where they were
> very confused because some of the code was code they had thought through,
> and some of it was changed by random fixits in ways they didn’t understand…
> and so it would lead to more errors/fixits until they had errors which
> couldn’t be fixed.
>
>
> Imho this is the best example to illustrate that inflationary use of
> warnings does more harm than good, and I hope it will be fixed.
>
> Having a bunch of conditions for warnings looks like overkill to me, and
> there are alternatives:
> - Only show when building
> - Only show in release builds
> - Linter
>
> That said, I'm going out on a limb and claim I already know how to write
> code and don't need basic schooling, and showing warnings before I hit
> compile is merely a distraction.
>
> But there are also Playgrounds which seem to be an important aspect of
> Swift, especially for newbies who could really benefit from some hints.
> There are no linters, no release builds, and even no regular builds for
> Playgrounds, so your model is the only one that works for them.
>
> Bottom line:
> +1
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Tino Heth via swift-evolution]

> One of the biggest issues that I saw while teaching Swift to newbies (most 
> had not programmed before) is confusion based on the early warnings/errors 
> that swift/xcode gives you as they type.  What would happen is that they 
> would type a variable, and it would say… “You haven’t used this variable” and 
> so they would just click the fixit because they trust the compiler more than 
> they trust themselves.  This would lead to a point where they were very 
> confused because some of the code was code they had thought through, and some 
> of it was changed by random fixits in ways they didn’t understand… and so it 
> would lead to more errors/fixits until they had errors which couldn’t be 
> fixed.


Imho this is the best example to illustrate that inflationary use of warnings 
does more harm than good, and I hope it will be fixed.

Having a bunch of conditions for warnings looks like overkill to me, and there 
are alternatives:
- Only show when building
- Only show in release builds
- Linter

That said, I'm going out on a limb and claim I already know how to write code 
and don't need basic schooling, and showing warnings before I hit compile is 
merely a distraction.

But there are also Playgrounds which seem to be an important aspect of Swift, 
especially for newbies who could really benefit from some hints.
There are no linters, no release builds, and even no regular builds for 
Playgrounds, so your model is the only one that works for them.

Bottom line:
+1 ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Jeremy Pereira via swift-evolution]

> On 26 Jan 2017, at 20:45, charles--- via swift-evolution 
>  wrote:
> 
> +1
> 
> Strongly in favour of this one. One of those things that seems obvious in 
> retrospect
> 
> It would also make the language more enjoyable to code in.

For you maybe. I like having the issues pop up and then disappear when I’m done 
with the thing they are complaining about. For example, the issue that tells me 
that some var I have declared is never mutated is a nice little prompt that I 
haven’t finished the scope yet.


> When Xcode nags me about my function not providing a return value when I've 
> only just started writing it, I get the irrational urge to tell Xcode to shut 
> its (metaphorical) mouth.

Go to preferences and select the “General” tab. Make sure that “show live 
issues” is deselected. That tells Xcode to shut up. If beginners are really so 
confused about the errors popping up (I’m sceptical), maybe that should be 
lesson one.

I would be dead against any language change that assumes a particular IDE or a 
particular workflow on the part of all developers.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[charles--- via swift-evolution]

+1

Strongly in favour of this one. One of those things that seems obvious in 
retrospect

It would also make the language more enjoyable to code in. When Xcode nags me 
about my function not providing a return value when I've only just started 
writing it, I get the irrational urge to tell Xcode to shut its (metaphorical) 
mouth. Using context to tell me errors "just in time" would be much more 
Apple-like.

Sent from my iPhone

> On Jan 25, 2017, at 3:59 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> One of the biggest issues that I saw while teaching Swift to newbies (most 
>> had not programmed before) is confusion based on the early warnings/errors 
>> that swift/xcode gives you as they type.  What would happen is that they 
>> would type a variable, and it would say… “You haven’t used this variable” 
>> and so they would just click the fixit because they trust the compiler more 
>> than they trust themselves.  This would lead to a point where they were very 
>> confused because some of the code was code they had thought through, and 
>> some of it was changed by random fixits in ways they didn’t understand… and 
>> so it would lead to more errors/fixits until they had errors which couldn’t 
>> be fixed.
>> 
>> By the end of the semester they had learned to ignore the warnings until 
>> they were finished, but it took a couple of months to get there, and was a 
>> big deterrent to new users… (Also, learning to ignore warnings ignorer to 
>> use a system seems like an anti-pattern)
>> 
>> I have a good friend who is an expert perl programmer who tried Swift and 
>> eventually gave up because he couldn’t figure out which errors to ignore 
>> (and which might just disappear a minute later) and which he needed to pay 
>> attention to. He was overwhelmed by the sheer number, and they didn’t seem 
>> trustworthy to him (“Swift is full of lies!” he would say of the warnings… 
>> which is a mantra I find myself parroting when I get those 
>> appearing/disappearing errors).
>> 
>> 
>> To fix this, I propose adding a way to annotate warnings/errors to say how 
>> immediate they need to be:
>> • Immediate - This error should always be shown
>> • DifferentLine - This error should only be shown once the cursor is on a 
>> different line
>> • DifferentScope - This error should only be shown once the cursor is in a 
>> different scope from this line
>> • DifferentFunction - This error should only be shown once the cursor is in 
>> a different function
>> 
>> So the “You haven’t used this variable” warning would be marked 
>> .differentScope, meaning that it would only show up once you had clicked 
>> away from the scope. The reason for this is that while you are in the same 
>> scope, it is fairly likely that you are still going to use the variable… so 
>> the warning is premature. Once I have left the scope, it makes sense to warn 
>> me.
>> 
>> Similarly, the “You need a return value” error would be marked 
>> .differentFunction because you are likely to add one while typing the 
>> function. But a type mismatch with the return value would either be 
>> .immediate or .differentLine because you have made an error that isn’t 
>> likely to be fixed with more typing on other lines.
>> 
>> I think this will cut way down on the number of warnings/errors that need to 
>> be ignored, which should increase trust in the system overall.
>> 
>> To be clear, I am only proposing adding the annotation to Swift (probably 
>> with a default of .differentLine). The compiler would not repress the 
>> warning/error itself… just vend it with a way to retrieve the annotation.  
>> IDE makers like Apple/Xcode would then be free to use that extra information 
>> in their UI if desired.
>> 
>> Thanks,
>> Jon
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> Having warnings and errors vanish and then reappear as you click in/out of 
> function seems far more confusing to me. Is there any other language/IDE that 
> does things that way?
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Saagar Jha via swift-evolution]

There's nothing wrong with fix-its and error messages, and indeed they can
be quite helpful-the issue is that sometimes they show up when they really
shouldn't, like in the middle of typing a line. Novices will then often
stop and see what it's trying to say (wouldn't you trust a tool if it tells
you something's wrong, especially if you're not acquainted with it?), and
the advice it gives is often irrelevant since the compiler doesn't have a
full understanding of what's going on. This simply suppresses the error
until the programmer is done typing.

Sent from my iPhone


> On Jan 25, 2017, at 23:31, Rien via swift-evolution <
swift-evolution@swift.org> wrote:
>
> OTOH, looking at fixit and error messages can also aid in understanding
Swift better.
> Seeing what happens when it happens is something I find quite useful.
>
> Not that I have anything against the proposal, but I do wonder if that is
the best usage of available resources.
>
> A BIG OT warning:
>
> If people are so easily put off, they probably are not very suited to
being a programmer/sw-engineer. It might be good for them to drop out asap
so they can pursue something more fitting to their personality… I have met
a lot of people that would have been better off not to get into
programming. It would have been better for them and for the projects they
worked on.
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:
>>
>> One of the biggest issues that I saw while teaching Swift to newbies
(most had not programmed before) is confusion based on the early
warnings/errors that swift/xcode gives you as they type.  What would happen
is that they would type a variable, and it would say… “You haven’t used
this variable” and so they would just click the fixit because they trust
the compiler more than they trust themselves.  This would lead to a point
where they were very confused because some of the code was code they had
thought through, and some of it was changed by random fixits in ways they
didn’t understand… and so it would lead to more errors/fixits until they
had errors which couldn’t be fixed.
>>
>> By the end of the semester they had learned to ignore the warnings until
they were finished, but it took a couple of months to get there, and was a
big deterrent to new users… (Also, learning to ignore warnings ignorer to
use a system seems like an anti-pattern)
>>
>> I have a good friend who is an expert perl programmer who tried Swift
and eventually gave up because he couldn’t figure out which errors to
ignore (and which might just disappear a minute later) and which he needed
to pay attention to. He was overwhelmed by the sheer number, and they
didn’t seem trustworthy to him (“Swift is full of lies!” he would say of
the warnings… which is a mantra I find myself parroting when I get those
appearing/disappearing errors).
>>
>>
>> To fix this, I propose adding a way to annotate warnings/errors to say
how immediate they need to be:
>> • Immediate - This error should always be shown
>> • DifferentLine - This error should only be shown once the cursor is on
a different line
>> • DifferentScope - This error should only be shown once the cursor is in
a different scope from this line
>> • DifferentFunction - This error should only be shown once the cursor is
in a different function
>>
>> So the “You haven’t used this variable” warning would be marked
.differentScope, meaning that it would only show up once you had clicked
away from the scope. The reason for this is that while you are in the same
scope, it is fairly likely that you are still going to use the variable… so
the warning is premature. Once I have left the scope, it makes sense to
warn me.
>>
>> Similarly, the “You need a return value” error would be marked
.differentFunction because you are likely to add one while typing the
function. But a type mismatch with the return value would either be
.immediate or .differentLine because you have made an error that isn’t
likely to be fixed with more typing on other lines.
>>
>> I think this will cut way down on the number of warnings/errors that
need to be ignored, which should increase trust in the system overall.
>>
>> To be clear, I am only proposing adding the annotation to Swift
(probably with a default of .differentLine). The compiler would not repress
the warning/error itself… just vend it with a way to retrieve the
annotation.  IDE makers like Apple/Xcode would then be free to use that
extra information in their UI if desired.
>>
>> Thanks,
>> Jon
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://

Re: [swift-evolution] Annotation of Warnings/Errors

[Rien via swift-evolution]

OTOH, looking at fixit and error messages can also aid in understanding Swift 
better.
Seeing what happens when it happens is something I find quite useful.

Not that I have anything against the proposal, but I do wonder if that is the 
best usage of available resources. 

A BIG OT warning:

If people are so easily put off, they probably are not very suited to being a 
programmer/sw-engineer. It might be good for them to drop out asap so they can 
pursue something more fitting to their personality… I have met a lot of people 
that would have been better off not to get into programming. It would have been 
better for them and for the projects they worked on.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution 
>  wrote:
> 
> One of the biggest issues that I saw while teaching Swift to newbies (most 
> had not programmed before) is confusion based on the early warnings/errors 
> that swift/xcode gives you as they type.  What would happen is that they 
> would type a variable, and it would say… “You haven’t used this variable” and 
> so they would just click the fixit because they trust the compiler more than 
> they trust themselves.  This would lead to a point where they were very 
> confused because some of the code was code they had thought through, and some 
> of it was changed by random fixits in ways they didn’t understand… and so it 
> would lead to more errors/fixits until they had errors which couldn’t be 
> fixed.
> 
> By the end of the semester they had learned to ignore the warnings until they 
> were finished, but it took a couple of months to get there, and was a big 
> deterrent to new users… (Also, learning to ignore warnings ignorer to use a 
> system seems like an anti-pattern)
> 
> I have a good friend who is an expert perl programmer who tried Swift and 
> eventually gave up because he couldn’t figure out which errors to ignore (and 
> which might just disappear a minute later) and which he needed to pay 
> attention to. He was overwhelmed by the sheer number, and they didn’t seem 
> trustworthy to him (“Swift is full of lies!” he would say of the warnings… 
> which is a mantra I find myself parroting when I get those 
> appearing/disappearing errors).
> 
> 
> To fix this, I propose adding a way to annotate warnings/errors to say how 
> immediate they need to be:
> • Immediate - This error should always be shown
> • DifferentLine - This error should only be shown once the cursor is on a 
> different line
> • DifferentScope - This error should only be shown once the cursor is in a 
> different scope from this line
> • DifferentFunction - This error should only be shown once the cursor is in a 
> different function
> 
> So the “You haven’t used this variable” warning would be marked 
> .differentScope, meaning that it would only show up once you had clicked away 
> from the scope. The reason for this is that while you are in the same scope, 
> it is fairly likely that you are still going to use the variable… so the 
> warning is premature. Once I have left the scope, it makes sense to warn me.
> 
> Similarly, the “You need a return value” error would be marked 
> .differentFunction because you are likely to add one while typing the 
> function. But a type mismatch with the return value would either be 
> .immediate or .differentLine because you have made an error that isn’t likely 
> to be fixed with more typing on other lines.
> 
> I think this will cut way down on the number of warnings/errors that need to 
> be ignored, which should increase trust in the system overall.
> 
> To be clear, I am only proposing adding the annotation to Swift (probably 
> with a default of .differentLine). The compiler would not repress the 
> warning/error itself… just vend it with a way to retrieve the annotation.  
> IDE makers like Apple/Xcode would then be free to use that extra information 
> in their UI if desired.
> 
> Thanks,
> Jon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Jeff Kelley via swift-evolution]

This sounds wonderful. It’s extremely common, in my experience with junior
developers, for them to blindly accept Xcode’s suggestions—and why wouldn’t
they? Delaying the display would certainly be a benefit for everyone, but
especially people who are just learning Swift.


Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan  |
jeffkelley.org

On Wed, Jan 25, 2017 at 6:46 PM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> One of the biggest issues that I saw while teaching Swift to newbies (most
> had not programmed before) is confusion based on the early warnings/errors
> that swift/xcode gives you as they type.  What would happen is that they
> would type a variable, and it would say… “You haven’t used this variable”
> and so they would just click the fixit because they trust the compiler more
> than they trust themselves.  This would lead to a point where they were
> very confused because some of the code was code they had thought through,
> and some of it was changed by random fixits in ways they didn’t understand…
> and so it would lead to more errors/fixits until they had errors which
> couldn’t be fixed.
>
> By the end of the semester they had learned to ignore the warnings until
> they were finished, but it took a couple of months to get there, and was a
> big deterrent to new users… (Also, learning to ignore warnings ignorer to
> use a system seems like an anti-pattern)
>
> I have a good friend who is an expert perl programmer who tried Swift and
> eventually gave up because he couldn’t figure out which errors to ignore
> (and which might just disappear a minute later) and which he needed to pay
> attention to. He was overwhelmed by the sheer number, and they didn’t seem
> trustworthy to him (“Swift is full of lies!” he would say of the warnings…
> which is a mantra I find myself parroting when I get those
> appearing/disappearing errors).
>
>
> To fix this, I propose adding a way to annotate warnings/errors to say how
> immediate they need to be:
> • Immediate - This error should always be shown
> • DifferentLine - This error should only be shown once the cursor is on a
> different line
> • DifferentScope - This error should only be shown once the cursor is in a
> different scope from this line
> • DifferentFunction - This error should only be shown once the cursor is
> in a different function
>
> So the “You haven’t used this variable” warning would be marked
> .differentScope, meaning that it would only show up once you had clicked
> away from the scope. The reason for this is that while you are in the same
> scope, it is fairly likely that you are still going to use the variable… so
> the warning is premature. Once I have left the scope, it makes sense to
> warn me.
>
> Similarly, the “You need a return value” error would be marked
> .differentFunction because you are likely to add one while typing the
> function. But a type mismatch with the return value would either be
> .immediate or .differentLine because you have made an error that isn’t
> likely to be fixed with more typing on other lines.
>
> I think this will cut way down on the number of warnings/errors that need
> to be ignored, which should increase trust in the system overall.
>
> To be clear, I am only proposing adding the annotation to Swift (probably
> with a default of .differentLine). The compiler would not repress the
> warning/error itself… just vend it with a way to retrieve the annotation.
> IDE makers like Apple/Xcode would then be free to use that extra
> information in their UI if desired.
>
> Thanks,
> Jon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Saagar Jha via swift-evolution]

+1, provided these differences are ignored if the user manually builds a
project. Hopefully this takes some of the load off of SourceKitService.
On Wed, Jan 25, 2017 at 16:07 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> Yes.  It would stick once it appears (until it is fixed, of course)
>
> On Jan 25, 2017, at 4:02 PM, Xiaodi Wu  wrote:
>
> I didn't read the proposal to mean vanish; rather, just lazily displayed
> until some condition, but then permanently there once it shows up. It
> really is annoying to be constantly reminded you haven't used a variable
> when you've literally just declared it. Once you've left the scope once,
> it's fair to have that warning stay there whether or not you click back.
> On Wed, Jan 25, 2017 at 17:59 Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> > On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > One of the biggest issues that I saw while teaching Swift to newbies
> (most had not programmed before) is confusion based on the early
> warnings/errors that swift/xcode gives you as they type.  What would happen
> is that they would type a variable, and it would say… “You haven’t used
> this variable” and so they would just click the fixit because they trust
> the compiler more than they trust themselves.  This would lead to a point
> where they were very confused because some of the code was code they had
> thought through, and some of it was changed by random fixits in ways they
> didn’t understand… and so it would lead to more errors/fixits until they
> had errors which couldn’t be fixed.
> >
> > By the end of the semester they had learned to ignore the warnings until
> they were finished, but it took a couple of months to get there, and was a
> big deterrent to new users… (Also, learning to ignore warnings ignorer to
> use a system seems like an anti-pattern)
> >
> > I have a good friend who is an expert perl programmer who tried Swift
> and eventually gave up because he couldn’t figure out which errors to
> ignore (and which might just disappear a minute later) and which he needed
> to pay attention to. He was overwhelmed by the sheer number, and they
> didn’t seem trustworthy to him (“Swift is full of lies!” he would say of
> the warnings… which is a mantra I find myself parroting when I get those
> appearing/disappearing errors).
> >
> >
> > To fix this, I propose adding a way to annotate warnings/errors to say
> how immediate they need to be:
> > • Immediate - This error should always be shown
> > • DifferentLine - This error should only be shown once the cursor is on
> a different line
> > • DifferentScope - This error should only be shown once the cursor is in
> a different scope from this line
> > • DifferentFunction - This error should only be shown once the cursor is
> in a different function
> >
> > So the “You haven’t used this variable” warning would be marked
> .differentScope, meaning that it would only show up once you had clicked
> away from the scope. The reason for this is that while you are in the same
> scope, it is fairly likely that you are still going to use the variable… so
> the warning is premature. Once I have left the scope, it makes sense to
> warn me.
> >
> > Similarly, the “You need a return value” error would be marked
> .differentFunction because you are likely to add one while typing the
> function. But a type mismatch with the return value would either be
> .immediate or .differentLine because you have made an error that isn’t
> likely to be fixed with more typing on other lines.
> >
> > I think this will cut way down on the number of warnings/errors that
> need to be ignored, which should increase trust in the system overall.
> >
> > To be clear, I am only proposing adding the annotation to Swift
> (probably with a default of .differentLine). The compiler would not repress
> the warning/error itself… just vend it with a way to retrieve the
> annotation.  IDE makers like Apple/Xcode would then be free to use that
> extra information in their UI if desired.
> >
> > Thanks,
> > Jon
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Having warnings and errors vanish and then reappear as you click in/out of
> function seems far more confusing to me. Is there any other language/IDE
> that does things that way?
>
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-ev

Re: [swift-evolution] Annotation of Warnings/Errors

[Jonathan Hull via swift-evolution]

Yes.  It would stick once it appears (until it is fixed, of course)

> On Jan 25, 2017, at 4:02 PM, Xiaodi Wu  wrote:
> 
> I didn't read the proposal to mean vanish; rather, just lazily displayed 
> until some condition, but then permanently there once it shows up. It really 
> is annoying to be constantly reminded you haven't used a variable when you've 
> literally just declared it. Once you've left the scope once, it's fair to 
> have that warning stay there whether or not you click back.
> On Wed, Jan 25, 2017 at 17:59 Karl Wagner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> > One of the biggest issues that I saw while teaching Swift to newbies (most 
> > had not programmed before) is confusion based on the early warnings/errors 
> > that swift/xcode gives you as they type.  What would happen is that they 
> > would type a variable, and it would say… “You haven’t used this variable” 
> > and so they would just click the fixit because they trust the compiler more 
> > than they trust themselves.  This would lead to a point where they were 
> > very confused because some of the code was code they had thought through, 
> > and some of it was changed by random fixits in ways they didn’t understand… 
> > and so it would lead to more errors/fixits until they had errors which 
> > couldn’t be fixed.
> >
> > By the end of the semester they had learned to ignore the warnings until 
> > they were finished, but it took a couple of months to get there, and was a 
> > big deterrent to new users… (Also, learning to ignore warnings ignorer to 
> > use a system seems like an anti-pattern)
> >
> > I have a good friend who is an expert perl programmer who tried Swift and 
> > eventually gave up because he couldn’t figure out which errors to ignore 
> > (and which might just disappear a minute later) and which he needed to pay 
> > attention to. He was overwhelmed by the sheer number, and they didn’t seem 
> > trustworthy to him (“Swift is full of lies!” he would say of the warnings… 
> > which is a mantra I find myself parroting when I get those 
> > appearing/disappearing errors).
> >
> >
> > To fix this, I propose adding a way to annotate warnings/errors to say how 
> > immediate they need to be:
> > • Immediate - This error should always be shown
> > • DifferentLine - This error should only be shown once the cursor is on a 
> > different line
> > • DifferentScope - This error should only be shown once the cursor is in a 
> > different scope from this line
> > • DifferentFunction - This error should only be shown once the cursor is in 
> > a different function
> >
> > So the “You haven’t used this variable” warning would be marked 
> > .differentScope, meaning that it would only show up once you had clicked 
> > away from the scope. The reason for this is that while you are in the same 
> > scope, it is fairly likely that you are still going to use the variable… so 
> > the warning is premature. Once I have left the scope, it makes sense to 
> > warn me.
> >
> > Similarly, the “You need a return value” error would be marked 
> > .differentFunction because you are likely to add one while typing the 
> > function. But a type mismatch with the return value would either be 
> > .immediate or .differentLine because you have made an error that isn’t 
> > likely to be fixed with more typing on other lines.
> >
> > I think this will cut way down on the number of warnings/errors that need 
> > to be ignored, which should increase trust in the system overall.
> >
> > To be clear, I am only proposing adding the annotation to Swift (probably 
> > with a default of .differentLine). The compiler would not repress the 
> > warning/error itself… just vend it with a way to retrieve the annotation.  
> > IDE makers like Apple/Xcode would then be free to use that extra 
> > information in their UI if desired.
> >
> > Thanks,
> > Jon
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> Having warnings and errors vanish and then reappear as you click in/out of 
> function seems far more confusing to me. Is there any other language/IDE that 
> does things that way?
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Xiaodi Wu via swift-evolution]

I didn't read the proposal to mean vanish; rather, just lazily displayed
until some condition, but then permanently there once it shows up. It
really is annoying to be constantly reminded you haven't used a variable
when you've literally just declared it. Once you've left the scope once,
it's fair to have that warning stay there whether or not you click back.
On Wed, Jan 25, 2017 at 17:59 Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > One of the biggest issues that I saw while teaching Swift to newbies
> (most had not programmed before) is confusion based on the early
> warnings/errors that swift/xcode gives you as they type.  What would happen
> is that they would type a variable, and it would say… “You haven’t used
> this variable” and so they would just click the fixit because they trust
> the compiler more than they trust themselves.  This would lead to a point
> where they were very confused because some of the code was code they had
> thought through, and some of it was changed by random fixits in ways they
> didn’t understand… and so it would lead to more errors/fixits until they
> had errors which couldn’t be fixed.
> >
> > By the end of the semester they had learned to ignore the warnings until
> they were finished, but it took a couple of months to get there, and was a
> big deterrent to new users… (Also, learning to ignore warnings ignorer to
> use a system seems like an anti-pattern)
> >
> > I have a good friend who is an expert perl programmer who tried Swift
> and eventually gave up because he couldn’t figure out which errors to
> ignore (and which might just disappear a minute later) and which he needed
> to pay attention to. He was overwhelmed by the sheer number, and they
> didn’t seem trustworthy to him (“Swift is full of lies!” he would say of
> the warnings… which is a mantra I find myself parroting when I get those
> appearing/disappearing errors).
> >
> >
> > To fix this, I propose adding a way to annotate warnings/errors to say
> how immediate they need to be:
> > • Immediate - This error should always be shown
> > • DifferentLine - This error should only be shown once the cursor is on
> a different line
> > • DifferentScope - This error should only be shown once the cursor is in
> a different scope from this line
> > • DifferentFunction - This error should only be shown once the cursor is
> in a different function
> >
> > So the “You haven’t used this variable” warning would be marked
> .differentScope, meaning that it would only show up once you had clicked
> away from the scope. The reason for this is that while you are in the same
> scope, it is fairly likely that you are still going to use the variable… so
> the warning is premature. Once I have left the scope, it makes sense to
> warn me.
> >
> > Similarly, the “You need a return value” error would be marked
> .differentFunction because you are likely to add one while typing the
> function. But a type mismatch with the return value would either be
> .immediate or .differentLine because you have made an error that isn’t
> likely to be fixed with more typing on other lines.
> >
> > I think this will cut way down on the number of warnings/errors that
> need to be ignored, which should increase trust in the system overall.
> >
> > To be clear, I am only proposing adding the annotation to Swift
> (probably with a default of .differentLine). The compiler would not repress
> the warning/error itself… just vend it with a way to retrieve the
> annotation.  IDE makers like Apple/Xcode would then be free to use that
> extra information in their UI if desired.
> >
> > Thanks,
> > Jon
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Having warnings and errors vanish and then reappear as you click in/out of
> function seems far more confusing to me. Is there any other language/IDE
> that does things that way?
>
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Karl Wagner via swift-evolution]

> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution 
>  wrote:
> 
> One of the biggest issues that I saw while teaching Swift to newbies (most 
> had not programmed before) is confusion based on the early warnings/errors 
> that swift/xcode gives you as they type.  What would happen is that they 
> would type a variable, and it would say… “You haven’t used this variable” and 
> so they would just click the fixit because they trust the compiler more than 
> they trust themselves.  This would lead to a point where they were very 
> confused because some of the code was code they had thought through, and some 
> of it was changed by random fixits in ways they didn’t understand… and so it 
> would lead to more errors/fixits until they had errors which couldn’t be 
> fixed.
> 
> By the end of the semester they had learned to ignore the warnings until they 
> were finished, but it took a couple of months to get there, and was a big 
> deterrent to new users… (Also, learning to ignore warnings ignorer to use a 
> system seems like an anti-pattern)
> 
> I have a good friend who is an expert perl programmer who tried Swift and 
> eventually gave up because he couldn’t figure out which errors to ignore (and 
> which might just disappear a minute later) and which he needed to pay 
> attention to. He was overwhelmed by the sheer number, and they didn’t seem 
> trustworthy to him (“Swift is full of lies!” he would say of the warnings… 
> which is a mantra I find myself parroting when I get those 
> appearing/disappearing errors).
> 
> 
> To fix this, I propose adding a way to annotate warnings/errors to say how 
> immediate they need to be:
> • Immediate - This error should always be shown
> • DifferentLine - This error should only be shown once the cursor is on a 
> different line
> • DifferentScope - This error should only be shown once the cursor is in a 
> different scope from this line
> • DifferentFunction - This error should only be shown once the cursor is in a 
> different function
> 
> So the “You haven’t used this variable” warning would be marked 
> .differentScope, meaning that it would only show up once you had clicked away 
> from the scope. The reason for this is that while you are in the same scope, 
> it is fairly likely that you are still going to use the variable… so the 
> warning is premature. Once I have left the scope, it makes sense to warn me.
> 
> Similarly, the “You need a return value” error would be marked 
> .differentFunction because you are likely to add one while typing the 
> function. But a type mismatch with the return value would either be 
> .immediate or .differentLine because you have made an error that isn’t likely 
> to be fixed with more typing on other lines.
> 
> I think this will cut way down on the number of warnings/errors that need to 
> be ignored, which should increase trust in the system overall.
> 
> To be clear, I am only proposing adding the annotation to Swift (probably 
> with a default of .differentLine). The compiler would not repress the 
> warning/error itself… just vend it with a way to retrieve the annotation.  
> IDE makers like Apple/Xcode would then be free to use that extra information 
> in their UI if desired.
> 
> Thanks,
> Jon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Having warnings and errors vanish and then reappear as you click in/out of 
function seems far more confusing to me. Is there any other language/IDE that 
does things that way?

- Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Annotation of Warnings/Errors

[Xiaodi Wu via swift-evolution]

I'd quibble with you on the detailed design, but personally I think the
general idea is quite wonderful.

Quibble:
I don't particularly think different-scope and different-function are in
practice usefully distinct. And I think that for maximum elegance we could
parallel the supported access levels: immediate (actually, is this one
_strictly_ necessary? seems next-line is sufficiently immediate feedback),
different-line, different-scope, different-file.

But overall, wonderful.


On Wed, Jan 25, 2017 at 17:46 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> One of the biggest issues that I saw while teaching Swift to newbies (most
> had not programmed before) is confusion based on the early warnings/errors
> that swift/xcode gives you as they type.  What would happen is that they
> would type a variable, and it would say… “You haven’t used this variable”
> and so they would just click the fixit because they trust the compiler more
> than they trust themselves.  This would lead to a point where they were
> very confused because some of the code was code they had thought through,
> and some of it was changed by random fixits in ways they didn’t understand…
> and so it would lead to more errors/fixits until they had errors which
> couldn’t be fixed.
>
> By the end of the semester they had learned to ignore the warnings until
> they were finished, but it took a couple of months to get there, and was a
> big deterrent to new users… (Also, learning to ignore warnings ignorer to
> use a system seems like an anti-pattern)
>
> I have a good friend who is an expert perl programmer who tried Swift and
> eventually gave up because he couldn’t figure out which errors to ignore
> (and which might just disappear a minute later) and which he needed to pay
> attention to. He was overwhelmed by the sheer number, and they didn’t seem
> trustworthy to him (“Swift is full of lies!” he would say of the warnings…
> which is a mantra I find myself parroting when I get those
> appearing/disappearing errors).
>
>
> To fix this, I propose adding a way to annotate warnings/errors to say how
> immediate they need to be:
> • Immediate - This error should always be shown
> • DifferentLine - This error should only be shown once the cursor is on a
> different line
> • DifferentScope - This error should only be shown once the cursor is in a
> different scope from this line
> • DifferentFunction - This error should only be shown once the cursor is
> in a different function
>
> So the “You haven’t used this variable” warning would be marked
> .differentScope, meaning that it would only show up once you had clicked
> away from the scope. The reason for this is that while you are in the same
> scope, it is fairly likely that you are still going to use the variable… so
> the warning is premature. Once I have left the scope, it makes sense to
> warn me.
>
> Similarly, the “You need a return value” error would be marked
> .differentFunction because you are likely to add one while typing the
> function. But a type mismatch with the return value would either be
> .immediate or .differentLine because you have made an error that isn’t
> likely to be fixed with more typing on other lines.
>
> I think this will cut way down on the number of warnings/errors that need
> to be ignored, which should increase trust in the system overall.
>
> To be clear, I am only proposing adding the annotation to Swift (probably
> with a default of .differentLine). The compiler would not repress the
> warning/error itself… just vend it with a way to retrieve the annotation.
> IDE makers like Apple/Xcode would then be free to use that extra
> information in their UI if desired.
>
> Thanks,
> Jon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Annotation of Warnings/Errors

[Jonathan Hull via swift-evolution]

One of the biggest issues that I saw while teaching Swift to newbies (most had 
not programmed before) is confusion based on the early warnings/errors that 
swift/xcode gives you as they type.  What would happen is that they would type 
a variable, and it would say… “You haven’t used this variable” and so they 
would just click the fixit because they trust the compiler more than they trust 
themselves.  This would lead to a point where they were very confused because 
some of the code was code they had thought through, and some of it was changed 
by random fixits in ways they didn’t understand… and so it would lead to more 
errors/fixits until they had errors which couldn’t be fixed.

By the end of the semester they had learned to ignore the warnings until they 
were finished, but it took a couple of months to get there, and was a big 
deterrent to new users… (Also, learning to ignore warnings ignorer to use a 
system seems like an anti-pattern)

I have a good friend who is an expert perl programmer who tried Swift and 
eventually gave up because he couldn’t figure out which errors to ignore (and 
which might just disappear a minute later) and which he needed to pay attention 
to. He was overwhelmed by the sheer number, and they didn’t seem trustworthy to 
him (“Swift is full of lies!” he would say of the warnings… which is a mantra I 
find myself parroting when I get those appearing/disappearing errors).


To fix this, I propose adding a way to annotate warnings/errors to say how 
immediate they need to be:
• Immediate - This error should always be shown
• DifferentLine - This error should only be shown once the cursor is on a 
different line
• DifferentScope - This error should only be shown once the cursor is in a 
different scope from this line
• DifferentFunction - This error should only be shown once the cursor is in a 
different function

So the “You haven’t used this variable” warning would be marked 
.differentScope, meaning that it would only show up once you had clicked away 
from the scope. The reason for this is that while you are in the same scope, it 
is fairly likely that you are still going to use the variable… so the warning 
is premature. Once I have left the scope, it makes sense to warn me.

Similarly, the “You need a return value” error would be marked 
.differentFunction because you are likely to add one while typing the function. 
But a type mismatch with the return value would either be .immediate or 
.differentLine because you have made an error that isn’t likely to be fixed 
with more typing on other lines.

I think this will cut way down on the number of warnings/errors that need to be 
ignored, which should increase trust in the system overall.

To be clear, I am only proposing adding the annotation to Swift (probably with 
a default of .differentLine). The compiler would not repress the warning/error 
itself… just vend it with a way to retrieve the annotation.  IDE makers like 
Apple/Xcode would then be free to use that extra information in their UI if 
desired.

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution