We have Julia 1.0 round the corner. So Winter '16 must be close to last call for major syntax revisions (yes?), but also this presents an opportunity for floating novel suggestions.
[poll max=1 public=true]
- Yay
- Nay
- MOO
[/poll]
(Suggested maximum dose: one suggestion per post).
PS Be ever conscious of the natural tendency to reflex-vote for whatever is familiar (comfort zone). Whatever is proposed, evaluate it on its merits!
PPS I’m starting to question whether this is an appropriate format. We are surely going to want to debate the pros and cons of various suggestions, and it is going to become a giant mess if everything is on the same thread.
Wouldn’t it be better if we had a separate thread per suggestion, and the first post in the thread would be the actual poll? This would mean that discussion of the pros and cons could occur in the same thread. I think that would be better. But then I’m bit conscious of creating too much forum noise.
One possible solution might be to create a new ‘Polls’ section/category. In fact that’s the best structure I can think of. Would an admin care to create such a category?
PPPS I really really think one idea/poll per thread is the way to go forwards on this. Collecting votes alone is at best worthless. The real value is exposing and challenging the logic behind the decisions which requires conversation. I’m rather sorry for starting this thread now, and I encourage anyone to start a new thread for each proposed topic. I think putting a poll in the initial post is nice idea; the votes should come to reflect the strength of the logical arguments that unfold in the ensuing conversation.
As a reminder, unless otherwise noted by a committer or someone doing implementation work for a specific question, results here do not imply any course of action or prioritization of effort. While this is an interesting functionality to try out on the new platform, generally the past consensus has been that polls don’t solve very many real problems. A poll is a low-effort means of expressing an opinion, and is weighted as such. Higher weighting is given to detailed design proposals (“Juleps”), proof-of-concept code, and pull-requests.
It’s hard to emphasize this enough: historically by far the absolute most effective way to get something accepted has been to implement it and submit a PR. By far the least effective has been discussion threads about preferred syntaxes.
I do think this sort of poll can be rather useful to somebody contemplating making such a detailed Julep, proof-of-concept, or full PR. If you can see beforehand that most people are against it, then you can expend your energy in some other worthy change. On the other hand, if it has a lot of popular support, that gives a lot of motivation to actually implementing it.
Julia is an open source project, so effectively the poll is asking my preferences about work that a third party would do. From a moral perspective, since I am not doing that work, I don’t think it would be right for me to express a preference (even if it is not binding). From a practical perspective, I don’t think the value added comes from expressing a preference about surface syntax, it comes from doing the work. So I am not going to vote.
It would be very different if someone wanted comments about a PR. If you are doing a PR and I missed that, then disregard the above, and please include a link.
In general, I find it hard to foresee ramifications of even mere changes in surface syntax without going through a lot of code. I think the best way to do that is to do a PR: for the tests to run, you would have to work though quite a bit of code and see how it works. I frequently find that I abandon some idea that looked attractive a priori halfway though a branch, because it turns out to be not much of an improvement, or worse.
Surely it’s a bit presumptuous to go ahead and implement my own idea of what the syntax should be and then see if it gets approved, no?
Surely it would be far more intelligent to first float the idea somewhere it can be discussed… All of the underlying logic for and against could be exposed. And then if it is still standing it may make sense to dig in and implement.
Digging in straightaway might lead to a lot of wasted effort, and might upset people… surely?
Waking up this morning I find myself strongly against the idea of polls. I remembered the public reaction to Einstein’s theory of relativity included a publication of 100 authors against Einstein to which his response was “If I were wrong, one would be sufficient!”
I fervently hope that the core Julia team never pander to public opinion, but rather continue to constantly challenge the state-of-the-art.
The real problem is that these kinds of syntax discussions lead to disproportionate amount of work for what’s gained. If this was 1 second to change, sure why not. But in reality, this stuff would take time to do, but there’s virtually no gain. So the only way to really show that anyone cares enough to implement it is to implement it yourself.
Every minute a core dev is re-working syntax is a minute they could be implementing new features and optimizations. I vote for the latter.
Certainly testing the waters of public opinion before picking a syntax is not a bad idea. I’m just saying that if it stops with a poll, then it’s just noise. If it’s followed up with a PR, then it’s a good start
I think this is a place where writing a careful PR is actually a really good sign because it shows that the person suggesting a change has a meaningful understanding of the ramifications of their proposed change.
In fact, a couple of the core Julia developers built their reputations in the community by showing up with large, well-thought-out PR’s that no one had requested them to write. (IIRC, Oscar’s brand-new GC for Julia was such an example.)
And some people who wrote PR’s that never got merged were also widely perceived as highly valuable potential contributors even if their specific proposals didn’t get merged.
A good PR demonstrates technical competence – and that is the most valuable thing possible in any project that depends upon highly competent volunteers.
