I don’t see a tradeoff between validating a student’s ideas and teaching them humility in how they weigh those ideas. For example: “You’re right that there are some advantages to the rules you’re proposing. However, there are disadvantages too, such as […]. In general, it’s wise to assume that design decisions are made by competent people based on carefully assessed tradeoffs. You can learn a lot by exploring some of those considerations, if you’re interested.”
1 Like
As I’ve pointed out over and over, the 0.6 behavior was a serious bug trap. Yes, it didn’t surprise people but it was also with regularity silently doing the wrong thing in non-toy programs, which is arguably much worse. People can’t file issues about a problem they don’t know they have.
12 Likes
Let’s not chastise the poor student for having an opinion that they didn’t even express in public.
7 Likes
4 Likes
I don’t see how this relates to my post, which was making a pretty trivial point, that though dismissing things is bad, healthy skepticism is good 
I agree — we should be chastising @PetrKryslUCSD instead for bringing up scope again 
1 Like
I think that’s out of the scope of this thread
6 Likes
I agree too. What I’m suggesting is a way of handling an objection to a well-trod issue that doesn’t involve re-surfacing the issue. But on second thought, I think your/Stefan’s suggestion of requesting a more detailed analysis is better, since it teaches the same lesson but with a more Socratic tone.
Just to clarify (in case the wasn’t enough): I was joking. We don’t need to chastise anyone.
I think that a lot of confusion happens because people think about Julia as a “new” language, imagining that it may be immature, with a lot of low-hanging fruits for improvement. So if some part of the language is surprising, it must be because its designers didn’t know better, and this is a great opportunity to enlighten them. This happens with scope, why-dont-we-have-OOP, surface syntax, etc.
This is somewhat understandable — after all, 1.0 is not that old, and Julia may be a newcomer in certain fields. But at the same time Julia is very mature: it has been around for almost a decade now, and builds on half a century of experience in programming language design. Various ideas have been tried, tested, and refined, and incorporated into the language.
It follows that changes to core features of the language need very compelling arguments at this stage. IMO this is the key point that should be communicated in these discussions: it’s not that the Julia community is hostile to any fundamental change a priori, just that the burden of demonstrating the advantages and, most importantly, how the proposal integrates with Julia is on the person making it.
16 Likes
Even though explaining the paradigms selected in Julia to badly-informed programmers may seem like a waste of time, it is a good selling point. Multiple dispatch made sense to me after a few days, while OOP never made any even after years of work. And looking at the code of other Julians, I think they share this opinion with me.
7 Likes
I’ve been using Julia since March 2019 and it took (and is still taking) some time for me to understand the design and how to best exploit it. I only figured out what multiple dispatch had to do with my life in the last couple weeks.
I’m still a badly informed Julia programmer and appreciate the responses to my novice confusion from the people on discourse. @zlatan is right about sales and marketing. When students in math ask if they should think about moving from Matlab to Julia, I can tell them that the learning curve is steep but that the community is helpful.
To stay on topic, I got burned so often by scoping inside the REPL vs outside that I have become ultra conservative. The new changes may protect me from some REPL errors, but won’t change my scoping phobia overall.
5 Likes