Re: Optional Curly Braces in JavaScript

2019-11-03 Thread Sanford Whiteman
> C# had these feature but still the scientific community went for > Python and not C#. C# is a explicitly compiled language. And a Windows language. (Mono is irrelevant, it would be a huge dependency.) Next? ___ es-discuss mailing list

Re: Optional Curly Braces in JavaScript

2019-11-03 Thread Sanford Whiteman
> People are more inclined to go for readable and less verbose > languages You keep saying that's *the reason* scientific and data-scientific community prefers Python but haven't provided evidence, continuing to sidestep: ● Python's intrinsic support for large numbers ● Python's strong

Re: Optional Curly Braces in JavaScript

2019-11-03 Thread Sanford Whiteman
The single character _ *is already a valid identifier* as Ron said. And not an obscure one (not that that would matter) but rather *the global object used by the Underscore library*. You might as well be using $ here and trying to convince people to stop using it as the top level of

Re: Optional Curly Braces in JavaScript

2019-11-03 Thread Sanford Whiteman
> the only thing really missing (and which python has) is a builtin > wasm-sqlite3 library (and specialized/secure file-api's to persist > sqlite-db-blobs). Browsers (WPWG, not this group) tried WebSQL. It failed because there wasn't a competitive bake-off with any other implementations _besides_

Re: Optional Curly Braces in JavaScript

2019-11-02 Thread Sanford Whiteman
> I don't see any reason why Python is widely used in math and > science… Should talk to longtime Python peeps about it, it's not just "easy" or they'd be using VB6! Let me leave this here: Python has had bignum (arbitrary precision Integers) since 2008. Even before that, it had Long

Re: Proposal: Selector/Select Expression

2019-06-22 Thread Sanford Whiteman
E-40 uses the preferred pronouns he/him/his. There's no need to muddy the (40) Waters here. —— Sandy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: native XML object support.

2019-05-13 Thread Sanford Whiteman
> I don't think we can say that we live in a JSON centric world But we do. It's not that there aren't powerful XML-based applications still being developed. And XML still buttresses some of the most important back-end components of the modern (as well as ancient) web. But surely you cannot have

Re: Proposal: native XML object support.

2019-05-13 Thread Sanford Whiteman
> let foo = This is a retread of E4X (https://en.wikipedia.org/wiki/ECMAScript_for_XML) so I can't imagine it would be resuscitated in a (for better or worse) JSON-centric world. —— Sandy ___ es-discuss mailing list es-discuss@mozilla.org

Re: Array.prototype.remove(item)

2018-10-10 Thread Sanford Whiteman
> You need to cite your sources > hi Sandy, sure hear are 2 sources: So you believe these 2 patches prove "most of the tech debt" across all JavaScript product development is due to this factor. Huh. Well, to each their own as far as how "proof" works. I prefer the classical definition. You

Re: Array.prototype.remove(item)

2018-10-10 Thread Sanford Whiteman
You need to cite your sources for the claim that "most of the tech debt" in JavaScript product development is due to accidentally using types other than 20-year-old built-ins and having to figure out the daunting task of JSON serialization. —— Sandy

Re: Proposal: Phase-Invariant Einno Soliton Templates

2018-05-20 Thread Sanford Whiteman
> I personally would prefer that these proposals are specified in terms > of *what's actually being proposed* I think what's actually being proposed is that we fall for a troll. Possibly an academic troll who will later ridicule its victims, viz. the Social Text scandal