I think the difficulty here is that the people who are worst affected by these kinds of performance changes may be people who also might not know that they should opt in to using Lint/TypeCheck. To get the proper effect from those tools, you probably need to impose them from above by default rather than allow them to be available if asked for.
I'd be strongly in favor of that, but it would make Julia feel more like one of those static languages for which compilers readily warn you about your bad habits. -- John On Jul 23, 2014, at 11:35 AM, Patrick O'Leary <patrick.ole...@gmail.com> wrote: > On Wednesday, July 23, 2014 12:49:28 PM UTC-5, Stefan Karpinski wrote: > I definitely agree that the current status is suboptimal. Lord only knows > I've spent a lot of time thinking about ways to fix the slow global scope > issue. Many but by no means all of these thoughts are in the issues Jacob > linked to. If we figure out a solution that seems to be the right way to do > it, it will be a really good day. Until then, it seems to me that the point > of view that it's a bad thing to get a 32x speedup with very little effort or > change is a lousy way to look at things. A lot of effort has been put into > allowing that 32x speedup. Not coincidentally, 32x is about how much slower > Python is for this kind of code; Matlab, R and Octave are slower. > > I suspect some of the reaction amounts to what appears to be performance > instability--if small changes can have such large effects, and you don't yet > understand why, it can be unsettling because it feels like you're on a knife > edge you could fall off of at any moment with one errant keystroke. And you > don't know what keystroke that is. A value of developing tools like Lint and > TypeCheck are that they can help make the effects of these "small changes" > more transparent.
