I don’t think the syntax x ? y:z is a serious problem; it currently parses as a ternary operator with no range, and we could just keep that. For cases like this you already need parentheses, e.g. x ? (y:z) : (a:b). Furthermore, writing x ? (y:z) would be very unusual since it returns a range or nothing, which is not very useful.
My answer is (also) kind of off-topic (for main thread), to this:
I’m not sure you gain any keyboard speed.**
Taking this not literally about keyboards, making any change, say changing from you chosen language (C++?) to Julia, could have that improvement (maybe not?), or more.
Joel on software famously wrote about rewrite software is a mistake. Does that mean, Julia is only for startups? I think not, you need not rewrite, you can migrate slowly. Even from PHP, with Polyglot.jl… At least for C, C++, Python and more, is Julia the ideal migration language?
** I’m not sure, are programmers limited by keyboard speed and not thought? Maybe I am a little bit limited by my writing, e.g. right here responding, but for code, I spend more time thinking than typing. Still have heard of programmers using DVORAK and liking.
If the company forced DVORAK on all, I guess, many programmers would find themselves a new job… not sure if that applies to Julia.
This is completely missing the central point of the analogy which is to illustrate the problem of a greedy strategy working off incremental change getting stuck in local minima of the cost function. That is why we still have QWERTY.
I am sure keyboard speed is of little consequence in a typical high level programming environment, but this conversation was never about keyboards!
Then I didn’t miss it completely. My much longer text, was not on keyboards (or language design); sticking with the language you know (least resistance) fits your analogy. Changing, say to Julia might help people.
Just want to say that as a newb, not knowing about the short-circuit evaluation, I’ve been doing cond ? true : error() as a one-line check. This is obviously not very elegant, but it gets the job done. I’ll switch over to the short-circuit for now to be consistent with other code, but just want to add extra support behind cond ? error() as an option.
Speaking as a beginner, once you grok the ternary operator, I think this syntax would be immediately recognizable. In fact, I think I initially thought it would work because ternary looks like if-else, so it makes sense that just if would work as well.
2 Likes
Regarding readability:
- If we use operators such as
&&or?etc., then it’s a good idea to stick to semantics that exists in other languages, so that code is easier to read. - If we use keywords for this, then we could also do:
length(a) == length(b) or else raise "problem!"
length(a) != length(b) and then raise "problem!"
That is, instead of using just then and else as keywords (difficult to parse), or just and and or, we can use two keywords. We could also (as we do in elseif) combine these to the keywords orelse and andthen.
1 Like
I was thinking yesterday, that since there has been talk of Nullable{T} might end up as simply a Union{T, Void}, that if we had the cond ? expr syntax, that it could actually return a Nullable{typeof(expr)} (when the value of cond ? expr is actually used, although frequently it would just be something with a side effect such as assignment or control flow). if cond ; expr ; end type is inferred to be Union{typeof(expr), Void} already.
(This may be a crazy idea, but it seems to be nicely consistent to me)
It might be nice of have and and or for & and |, and andthen and orelse for && and ||
The if cond then statement one liner was always my favourite, and I don’t think it was disproved to be workable yet, was it? (Edit: I like it for explicit readability, I honestly don’t care at all if it’s as much typing as if cond; statement; end and more than &&).
There is some logic in leaving ? unary and binary open for whatever progress is made on Nullable syntax (though ?? could be an option there).
2 Likes
Hasn’t it been pretty much debunked that DVORAK has any actual speed advantages for users after they master either form? (But that’s beside the point)
But will this change actually make us 20% more productive? Or will .-fusing, array buffers, the type system overhaul, traits, Pkg3, the ability for precompilation to handle conditional dependencies, and dispatch on keyword arguments make us more productive? I am inclined to say that these issues are a better use of development time, so I wouldn’t want to burden any core developer whose working on anything close to this to spend even a week doing some syntax changes.
That’s why people are asking for this kind of stuff to be a PR. Even if it’s is “better” (debatable): do you think it’s work the development time? If it’s worth your time, then do it. Nobody else thinks it’s a good way to spend time.
Honestly, there are good syntax problems to explore: what’s a good syntax for traits? What about for the types for structs? etc. It’s much easier to see how discussions in those areas push the language forward than this.
It’s always about costs vs benefits.
5 Likes
Not sure if debunked, but there doesn’t seem to be clear evidence either way, and that’s only looking at speed, the effect of using Dvorak (or some other alternative like Colemak: https://colemak.com/) on RSI might be much more important, but I haven’t seen (but they might exist) any studies on RSI / carpal tunnel among QWERTY vs. Dvorak users.
I disagree with only this one thing that you said (that nobody thinks it’s a good way to spend time).
I do agree that changes / additions like this haven’t bubbled to a higher priority among the core devs for them to work on this, and yes, I’d much rather that they work on things like the low-level Buffer type to implement arrays/strings more generically, trait syntax, fixing the problem with being able to use typevars in expressions in a type/immutable definition [i.e. evaluate the expressions only when they are bound to make a concrete type], Pkg3, etc…
If I’ve got a bit of time, I might try my hand at implementing binary ?, having it return a Nullable (when it doesn’t just have some control flow for the expression).
result = ch <= '\U10FFFF' ? Char(ch) would set result to a Nullable{Char}, which currently I think would have to be written as result = ch <= '\U10FFFF' ? Nullable(Char(ch)) : Nullable{Char}().
Yeah, nobody was a bit strong of a word. A few people, one of which has submitted a PR (@Ismael-VC), do really care. Also it seems the people at Software Carpentry (at least a few) care:
I would however put it as very low priority, and think it should be clear that it’s not because I don’t like it (I prefer the and syntax), but because I don’t see it as a good use of time (I barely prefer the and syntax and would never ask anyone else to go through all of that work to make me less happy over a lifetime than a nice breakfast would).
1 Like
(staying offtopic here, sorry)
- what a lightweight blog post at Software Carpentry, but I like the first response
- I changed to Colemak 2 years ago, I am faster than before, but primarily, I feel much more comfortable typing. This was always the main goal of that alternative layout, never speed.
- I find that a lot of the criticisms of Julia as it was 2 years ago (including my own!) are no longer valid (there really has been a lot of great progress since I first saw the language end of March 2015). v0.6 is IMO going to be a great release.
- If I hadn’t been touch typing with QWERTY for 43 years, I’d switch to Colemak myself!
What about trailing ifs (similar to comprehensions):
a = 1.0
a = 4.0 if x<5
a += 1.0 if a==2.0
return if a == 0.0
look very clear to me.
an analogous construction would be:
A[i] = i for i=1:5
A[i,i] = 1.0 for i=1:10
A[i,j] = i+j for i=1:3, j=1:3
which also seems to be useful and close to mathematical notation.
2 Likes