Ian, Graydon, Community,
I am fairly NEW to programming in current languages at all... So I am a
great guinea pig for testing all these conversations about "What would a
beginner to Rust...or even programming languages in general" think about
this ? I personally think that "dot notation" is fine, and I have learned
why others, such as yourself, think that using "dot notation" might bring
some unfamiliarity in using it. It does not rub me the wrong way, and has
a "functional order" to it, but that is because my background way, way back
when, was only with functional languages.
In the end, folks have preferences, primarily based on "what your used to
using that did not make your brain explode trying to understand it, and
made you fairly productive". In this case, I would hope that the language
design is decided by not a majority vote wins, but what represents a
"pleasant taste in the mouth" 90% of the time when programming Rust, no
matter their background. I would encourage the community to repeat good
designs, and stretch out against bad designs and debated language
preferences that folks have. You cannot please everyone, but a good goal
would be that "90% pleasant taste in the mouth". That's not trademarked,
so your free to use that Graydon, if necessary. :-)
So, back to the original thread subject you brought up...
Re-using "in" seems to also leave a pleasant taste in my mouth, simply
because I do not have a high preference, and am easily adaptable. I find
that if you can design a language that reads fairly well, WORKS AS
DOCUMENTED, and as a bonus is intuitive for 90% of the folks that read 50%
of the docs or less...then you've got a winning language design.
(and I would not hope that your sealing up the language just yet - since
there is no high visibility, in production system that is using it - but I
do understand the causal effects of introducing more keywords in this later
stage of design)
On Sat, Jul 27, 2013 at 11:40 AM, Ian P. Cooke <i...@informatic.io> wrote:
>
> On Jul 27, 2013, at 10:48 , Zoltán Tóth <zo1...@gmail.com> wrote:
>
> Then the coder can drop the pattern part without making the wording weird:
>
> loop 10.times() { ... }
>
>
> This syntax has always bugged me. I always read it as "send the message
> 'times' to the object named '10'" but 10 is an integer literal and integers
> don't have behavior. The '10.times()' syntax makes it look to the reader
> that he's observing a conversation with a number rather than a dictation of
> the actions that 'self' is about to perform. I know Smalltalk and Ruby use
> similar syntax but I feel like they're also wrong to do so. I like any of
> the following:
>
> for i in 1..10 {}
> for i in range(10) {}
> for _ in range(10) {} //if you don't care about the index of the iteration
> for i in range(1, 20, 2) {}
>
> all of which are more clear to me. Something as core as control flow
> should have a simple syntax without object-oriented-looking, DSL-type
> cleverness.
>
> I don't intend to start a debate on the merit of any the various syntax
> choices but this thread made me want to assure at least one
> anti-'10.times()' opinion was heard :)
>
> My motivation is actaully something different: I feel this order more
> intuitive. I during coding generally like to be able to write the code in
> the order that I think. When I want to write a loop, first I think about
> that I want to iterate over some collection. Only after that do I think
> about a suitable name for the loop_variable / iterator. I understand that
> most programming languages use the <pattern> <expr> order and that
> programmers are used to it, but I think to be be intuitive is more
> important than to be similar, especially for a new language.
>
>
> I do agree with this. SQL has a similar issue:
>
> FROM t SELECT x, y, z
>
> makes more sense (and as such can get more context-sensitive help) than
>
> SELECT x, y, z FROM t.
>
> Microsoft's Linq gets this order right IMO. In fact, Linq is pretty
> awesome in general (
> http://msdn.microsoft.com/en-us/library/vstudio/bb397906.aspx,
> http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b ) although my
> opinion is mostly academic there. Having language-level support for the
> notion of a query would be incredibly useful to me (unifying local and
> remote collections).
>
> -ipc
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
--
-Thad
Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
