On Oct 31, 2011, at 5:40 AM, Quildreen Motta wrote: > I still think <| is more straight-forward to grasp to non-native speakers -- > they're likely to have stumbled upon that on UML classes, methinks. Also, > there's the problem of creating new reserved words in the languages, imho it > makes a language feel heavier and clunkier. I think one of the greatest point > of ECMAScript is that, despite the awful amount of reserved words,
The original language had only: delete else false for function if in new null return this true typeof var void while with Ah, memories! Then came ES3, which added: break case catch continue default do finally instanceof switch throw try for 28 total. Still not bad in my book. > the language still manages to be simple and straight forward for people to > grasp, I beg to differ. The language is deceptively simple and usually forgiving, but as many deep thinkers have noted, it has depths that take years to plumb. Closures by themselves take study and practice to master. > except for a few semantic quirks here and there. Of course. (One thing I laugh at is the dog-piling on JS -- as if no other real language had quirks! dmr, bless him, talked about C's quirks frankly at plan9.bell-labs.com/who/dmr/chist.html.) > I don't think that evolution and simplicity have to be mutually exclusive. > Languages should strive to hide the perceived complexity from the end-user, > while still managing to be expressive. If we decide on using a keyword for > expressing <|, this word should be as straight-forward and simple to grasp > for both native english-speaking people and non-native english-speaking > people, which I don't think any of the proposed words are =/ I want a Pony too. We're not going to have a universal, English-free syntax. Not in my lifetime, anyway. 'switch' is hardly self-documenting. Even 'for' is overloaded and idiomatic (from C and awk, or Python if you squint really hard). Languages require learning, there's no avoidin it. They do not explain themselves, certainly not in arbitrary native tongues. /be > > 2011/10/31 Axel Rauschmayer <[email protected]> > >> I searched a bit and re-read Smalltalk, Self, Cecil, and Io docs to get a > >> handle on what <| does. It is not 'clone'. > > > > It's not 'copy' (Self) either, clearly. > > > > > >> It ain't 'create' except in a vacuous sense that's also already "taken" by > >> ES5 Object.create. It isn't "subsuming" in my view. "refinedBy" is closer > >> but you'll get camelCaps keywords into JS over my dead body! > >> > >> I landed on 'beget' because 'create' is close but vague yet poisoned, and > >> we need something pithy. > > > > Also, 'beget' does match the "sire" or "hatch" connotation of taking a > > parent (Self again) object and differentialy inheriting another object from > > it via proto-linking. Clone means make a twin and mutate. Copy is, well, > > just a copy -- arguably close to clone and one char shorter (so Self chose > > well). What we have with <| is more like "generate a child" -- hence, > > 'beget'. > > > > Two more ideas: > > const Employee = Person to { ... } // or any other preposition (prepositions > are like operators) > const Employee = Person parents { ... } > > -- > Dr. Axel Rauschmayer > [email protected] > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
