On Monday, July 20, 2015 at 7:13:35 AM UTC-7, Staś Małolepszy wrote: > I see how this might be minimal learning curve for someone who understands > a bit of programming. For those who haven't had such experience at all, > this is black magic. It's familiar to us and it's easy to confuse this > with thinking that this is *the* minimal learning curve. In fact, I could > argue that S-expressions are the minimal learning curve too!
I disagree, I also don't think that it's the right topic (as in, I'm not sure if the answer to this question should be a major component of the decision on what syntax we use). > > I believe that that's your personal subjective experience not shared by > > majority of people working with IT. > > > > And what's that belief based on? Gut feelings, personal experience with software, nothing sharp enough to make finite statements. > S-expressions give us that flexibility by moving syntax constructs like + > operator to runtime, where + is a function call. The syntax stays the same. I think you misunderstood what I wrote above. > > > And I am actually quite confident that if we went with your expression > > syntax that it would be a major reason for people not to adopt L20n. > > > > Why are you confident again, here? Once again. Gut feeling, personal belief, experience with software. Wherver I write about my personal take which is a matter of preference, I denote that. It's the same strength of argument as vast majority of the whole thread from your side - personal preference. > You say "they probably don't" and then you say "may want to execute > arithmetic operations". What kind of operations are those? Can you think > of specific examples? Realistically, do we need more than some kind of > plural support which can be extended to take into account metadata bools > like "is animate" or "is a person" and some kind of string lookup function > (startsWith, endsWith)? I don't know :) I don't know which direction L20n will take as we'll add more features. Will we end up with some sort of responsive localization? With dynamic string length adaptation? With string lookups? I believe that JS-style expression is a safe bet for what we may want to do in the future. > I think we're overengineering L20n big time. It shows in the discussion > about the dash in identifiers. Is L20n supposed to be a programming > language? Or is it supposed to be a data store format with some expression > syntax? I firmly believe it's the latter. We'd be using YAML if it wasn't > for multiline strings on our side and significant whitespace on YAML's > side. I want the expression syntax to be well thought-out and baked into > the language, but perhaps we're focusing too much on it and in fact we're > ending up designing the whole syntax for an edge-case! I agree that expressions are minor piece of l20n format. I don't know if it will be in the future. I believe that JS-style expression syntax allows us to provide the minimal now, and easily extend-while-staying-familiar later. We'd be using YAML, awesome. And we'd be storing JS-style expression in that YAML. I just don't agree with you, I guesss, with your belief that JS-expression syntax is overcomplicated, overengineered and overall bad for our goals. I believe it's perfect for our goals :) > No, and that is why S-expressions are part of my proposal. I fully believe > that if our syntax is not based on S-expressions we should not allow dashes > in names. My point was about being webby. CSS ids feel webby to me and we > don't have them right now. I don't believe that dash-based IDs are at the heart of what we should try to improve in our syntax. At the same time, I'm ok improving that. We can introduce similar semantics that JS have to solve it. But I don't believe that we should transition away from JS-style to lisp-style to achieve them. > If we allow dashes in names there won't be need for toCamelCase. We can > fix what DOM got wrong :) See one above. > That's not true. All Lisps can substract :) Arguably, the dash is more > webby: CSS and HTML both support it. And JS supports it too. > Is @os a property or a method? Is @hour a property or a method? > @deviceType? I think we're creating confusion by allowing globals to be > both callable and non-callable. I don't think we'll want to pass things > around be reference, so maybe they should always be callable? Yeah, maybe they should. I would be ok with "@hour" being shortcut for "@hour()", but maybe we want to stay explicit. > Of course not, but using & or | in the future as a special name might be > helpful. C-like syntax forbids a lot of characters, really. Also, naming > bool-returning functions as `person?` instead of `isPerson` is a nice > humanizing aspect that I really like in Lisp and Ruby. I see it as another risk of unfamiliar syntax that increases the chance that a localizer will try to translate it. Humanizing expression syntax in localization language may be an anti-pattern for me. Which is maybe also part (just part) of why I'm not that worried about cryptic syntax. I expect localizers to copy&paste a lot as they learn, and the less "en-US" like the expression looks like the less risk that they'll try to translate it. "isPerson($name)" sound way less risky than "person? name". zb. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
