We all like to demo how awesome Julia is, which occasionally results in interesting, but possibly non-idiomatic, non-extensible, or fragile code (relying on internals, etc) that stretches the boundaries of the language. I will not provide examples here (first, because I don’t want to single out anyone, second, because I actually like these examples a lot), but they include
squeezing the last nanosecond out of an optimization problem using internals and unsafe ops, or very complex code that works around a compiler quirk,
defining a mini-DSL using macros,
extending syntax through creative use of getproperty.
There are great fun to read and comprehend (I have learned a lot from them), but I wonder if it would make sense to exercise some judgement when the topic is in the First steps category, either explicitly or implicitly (which usually is apparent from the question).
As Julia is growing, we can expect many more newcomers who, potentially because experience with some other language, sometimes ask for things which can be done, but perhaps should not be done, or not until one understands a lot more about using Julia. They may not be able to tell that the solution is not something one would do on a regular basis, because of safety or maintenance concerns, or think that Julia is about doing weird and complex stuff to gain 10% runtime performance, or develop parallel syntax that mimics some other language instead of learning how it is done in Julia.
Can I also add a small plea related to this? As @Tamas_Papp says we all learn from looking at code published here. For me anyway, seeing real code here and wanting to try it out is better than textbooks.
Would people please consider that there are newbies coming in as Tamas says. Comment as much as you can. It might be obvious to you what <: or range definitions do. But sometimes a complex line of Julia code which has functions, types and range definitions inline can degenerate into what looks like chicken tracks in the sand.
A small comment like: here we specify a type of Float 64 and a range of 1 to 100 in steps of 2 goes a very long way.
Clearly there comes a point at which commenting every line is ridiculous and hinders the fast communication we love on here.
I generally think it’s fine to post “inappropriate” solutions if there’s a tangible advantage to them. It would be silly I think to not even mention a possible 2x speedup because it uses internals (as in this example of updating a dictionary). I often see newcomers here benchmark Julia code to another language and be disappointed if the performance isn’t the same.
BUT – I agree with you that it’d be a good idea to hold back unless there’s a clear advantage, and above all I think that we could be better at providing proper explanations/warnings for these cases, and not be shy to point this out when we see it in others’ posts.
I agree with you that this would be a much beneficial practice. And potentially not restricted to the “first steps” category: even in the “performance” category, where these have a rightful place, any reader should be aware of which solutions are idiomatic and considered good / acceptable practice, and which are fragile, difficult to maintain, or otherwise not to be advised except in specific cases.
Should we perhaps draft and post a PSA related to this ? In simple / common cases, providing such explanations / warnings could only be a matter of linking to this PSA (much like we do for “please quote your code” or “help us help you” answers and the like).
(possibly, multiple PSAs could be created: one for each type of “inappropriateness” identified by Tamas above)
I think the issue mainly involves experienced Julia programmers who have the skillset to go overboard with solutions. Not more than 10–20 people on this forum. If they agree to occasionally reflect on the context of questions, there should be no need to formalize this further.