Let us consider:
a = 1
In C/Java/C++/C#/etc, a
has to be an existing thing - there is dedicated syntax for introducing new things into scopes, and it can't be done accidentally. In certain other languages, this just declares a
outright. That's extremely dangerous: a simple typo is all it takes to make your code wrong and yet it compiles without errors, or in some cases it even compiles without warnings!
I can understand older languages doing it: they didn't know any better. But [i]new[/i] languages!?[quote=Crystal]We want the compiler to understand what we mean without having to specify types everywhere.[/quote]So I asked about it in their IRC:
[15:22] <LB__> When I assign to a variable, how do I know whether I'm declaring a new local variable or assigning to one in an enclosing scope? What if I want the compiler to warn me about the former?
[15:28] <jhass> LB__: there's no difference in crystal, assignment and declaration is the same
[15:29] <LB__> So if I make a typo the compiler won't even warn me?
[15:29] <jhass> LB__: IME if you really have the problem of forgetting which local variables are valid in your current scope, you write way too long methods
[15:30] <jhass> Crystal doesn't warn, either something is valid or not
[15:30] <jhass> and of course accessing a local that was never assigned will error
[15:33] <LB__> IMO that's a pretty bad thing. Oh well.
I don't know about you, but every time I have had to spend multiple hours debugging code, it has been because of a simple typo that the compiler didn't warn me about. Some typos are pretty hard for humans to spot, but [b]it should be obvious to a computer[/b].
Also, did you catch that?
[15:39] <LB__> Wait, when you say "Crystal doesn't warn", do you mean there are never any warnings generated ever?
[15:44] <jhass> no, only errors
[15:45] <jhass> well, I guess we warn when you benchmark in non-release mode
[15:45] <jhass> but that's like a stdlib warning, not a compiler warning
[15:46] <LB__> That's going to be fixed, right? Surely there's some code that is obviously suspicious or wrong and the compiler can warn about it?
[15:53] <jhass> LB__: if the compiler thinks something is wrong, it'll error out on it
Ok, so warnings as errors is a good idea, but I think there are some cases where a warning is more appropriate. Then this guy literally spells out a perfect example:
[15:54] <LB__> But it won't error out on typos?
[15:54] <LB__> What about variables that are only assigned to and never used?
[15:55] <LB__> I can get behind the 'errors only' thing, but only if it actually catches common mistakes
[15:57] <jhass> erroring out on write only would be annoying as you temporarily comment out stuff
This is the perfect case for having a warning. I couldn't have said it better myself.
[15:58] <LB__> So why not have a warning for it? For instance, if you forget to uncomment that code or you make a typo?
[16:00] <jhass> people ignore warnings
[16:00] <jhass> you'll end up having to use a library that produces lots
[16:00] <jhass> so you'll ignore them even more
[16:01] <LB__> I guess we'll just have t agree to disagree.
People ignore warnings? Well, yeah, but only if they're idiots. Just because idiots ignore warnings doesn't mean they shouldn't be there. As for the library argument...why would your brand new language allow warnings in library code to be displayed to the user of the library!?
Crystal is not the only language with this problem. This attitude is exactly why I stay away from such languages. They are IMO scary dangerous languages where the community of developers doesn't afraid of anything.