Yes, maybe. I just think it’s more readable, I’m not saying it should be defined in Base.
But there is a parallel in how !f is parsed. You can write !f and !f(x) and both work fine.
2 Likes
This parses as -(sin(x)) before or after my definition, but (-sin)(x) has the same result anyway. And is an error on un-piratised Julia. Can you think of any examples where these would differ?
1 Like
Indeed, I’d forgotten about that.
Note by the way that these have very different precedences: Base.operator_precedence(:∘) == 13, Base.operator_precedence(:-) == 11, Base.operator_precedence(:!) == 0. Still worried this is going to break something horribly somewhere!
I presume it would be implemented like this:
-(f::Function) = (x...)->-f(x...)
instead of going through ∘.
I don’t think this should matter.
I have this in my startup file:
module Startup
if length( findall( x -> x == "Project.toml", readdir() ) ) > 0
using Pkg
Pkg.activate( "." )
end
end
Works for windows and linux 
You would be probably better off setting JULIA_PROJECT=@. That way, you can override it using --project=....
2 Likes
…until you get an off-by-one error…
Do you think that is more likely with a loop? Can you give an example?
So there’s been some great advice on this thread, thanks to all who’ve been contributing! And also some great and interesting discussion. But it’s getting difficult to just see the ‘nuggets’ in here if that’s what someone is seeking.
What to folks think of making the original post a Wiki so that the nuggets can be condensed into something a bit more digestible? (BTW I’m making that suggestion neither having made a post a wiki in the past nor used someone else’s, so forgive me if wiki posts in Discourse are just ill-advised in general 
).
I think that in the Julia community, traditional wikis are not that popular since they cannot be integrated into a CI framework so as the language moves on, code snippets and advice become outdated.
If you see some suggestions you consider useful but can’t find in the documentation, please consider making a pull request (for either Julia’s docs, or the relevant package). This usually does involve more work than editing a wiki, but is more future-proof and usually elicits suggestions and advice from reviewers, improving the result.
4 Likes
Tamas, I get where you are coming from, I think, but also it seems as the language becomes more popular the community can be expected to become more diverse, in a sense. That is, in the early days (I presume; I’m a relative newcomer!) the community was mostly developers, package creators/maintainers and other experts (with a few early adopters but they probably were pretty exceptional compared to the potential eventual user base).
But to the extent that Julia becomes successful as a tool for solving problems (i.e. a viable alternative to Matlab, R, Python in this regard) there will probably be many more in the community who would mainly like to get on with their work and suspect Julia might be an excellent tool for doing so. Along the way they will discover some of the great things that distinguish Julia from other languages (I know I certainly have). These ‘aha’ moments, which to the long established community members are second nature/obvious can be very valuable to others with the same perspective. And sometimes these come in the form of what I’ve, for lack of a better term perhaps, called protips.
Shouldn’t that be much less of a concern now that 1.0 is out and snippets (at least those that concern the core language/standard library and any packages that are >= 1.0) should not be at as much risk of becoming outdated?
I see your point but might this be letting perfect get in the way of “good enough”? Also it’s often not clear what to look for in the documentation in the first place, but such tips can be a great place to help one figure out what part of the docs to look at more closely (so e.g. in the above someone mentions JULIA_PROJECT).
If contributing a useful tip requires everything that goes into making a PR, then I suspect the bar will be too high for many, at least initially, and anyhow in many cases the value is not that something is simply documented (necessary) but that for some things in particular it can be found in some way outside of the official documentation that highlights its use in some particular way (sufficient much of the time). Of course where possible the docs should be pointed back to, and this is part of the advantage of a wiki because people can contribute a small edit, even if only to add a link to the relevant docs. So e.g. JULIA_PROJECT; that took me maybe 30 seconds to locate and link to and certainly doesn’t merit the attention that a PR, especially to the main language documentation, would require.
Anyhow just a some thoughts I have coming from the perspective that let me to make the post originally. Thanks for the feedback, and discussion, which is pretty uniformly amazing in this community and I certainly hope that that never changes!
1 Like
There is certainly a trade-off here between ease of contributing and having outdated examples. 1.0 may be around for at least a few years, but standard libraries can potentially change even during that timeframe, and 3rd party libraries are moving at a very quick pace, with some releasing multiple new major versions in a year.
At the same time, the presence of outdated code snippets on the net is already a concern for some (but of course we cannot do anything about that and all languages which are developed actively have this problem).
I think the ideal to strive for is having an API and documentation (with examples etc) that makes things so intuitive and well-explained that “pro tips” are not needed at all.
To find the “nuggets” expand the bottom menu on the first post and press the button “summarize topic”
3 Likes
Does page no longer exist?