javascript vision thing

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Richard Gibson
As stated even more strongly in ECMA-404:
Because it is so simple, it is not expected that the JSON grammar will ever change. This gives JSON, as a foundational notation, tremendous stability.

On Thu, Jul 26, 2018 at 9:43 AM Jordan Harband <[hidden email]> wrote:
That's a ridiculous claim, considering JSON has never supported functions, or `undefined`, or RegExps, or Dates.

ES6 also introduced `Symbol`, `Map`, `Set`, etc all of which have no JSON representation.

There's no "limbo" - JSON is, and will forever be, a subset of JS. Many new things will be added to JS, and *none* of them will likely ever be added to JSON at this point.

On Thu, Jul 26, 2018 at 9:23 AM, Anders Rundgren <[hidden email]> wrote:
On 2018-07-26 17:24, Ranando King wrote:
JSON = JavaScript Object Notation

This obviously broke down when tc39 introduced BigInt leaving the JSON/JS community in limbo.

Anders

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Anders Rundgren-2
On 2018-07-28 00:34, Richard Gibson wrote:
> As stated even more strongly in ECMA-404:
>
>     Because it is so simple, it is not expected that the JSON grammar will ever change. This gives JSON, as a foundational notation, tremendous stability.
>

Richard, that's great but it doesn't completely respond to my "limbo" claim:

https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html

Take your pick! Whatever you come up with, I'm sure there will be some rotten tomatoes flying around :-)

Cheers,
Anders
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Richard Gibson
JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript JSON.parse implementation simply cannot accept e.g. 0n and still uphold the conformance guarantees:
Conforming implementations of JSON.parse and JSON.stringify must support the exact interchange format described in the ECMA-404 specification without any deletions or extensions to the format.

Both BigInt and Symbol lack native support in JSON, and although adding in custom serialization is relatively easy, custom parsing is not because JSON.parse doesn't expose the text used to produce a value. But in my opinion, it would be a mistake to characterize that explicit lack of support as "limbo".

On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren <[hidden email]> wrote:
On 2018-07-28 00:34, Richard Gibson wrote:
> As stated even more strongly in ECMA-404:
>
>     Because it is so simple, it is not expected that the JSON grammar will ever change. This gives JSON, as a foundational notation, tremendous stability.
>

Richard, that's great but it doesn't completely respond to my "limbo" claim:

https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html

Take your pick! Whatever you come up with, I'm sure there will be some rotten tomatoes flying around :-)

Cheers,
Anders

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

JSON support for BigInt in ES6. Was: javascript vision thing

Anders Rundgren-2
Richard et al,

If we call the situation "limbo" or not isn't that important, I just happen to have a preference for strong or funny expressions.

The root of the problem (not only for JavaScript) is that JSON is *the only general purpose data interchange format in existence* that uses a single notion to signal "here comes a number".

Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This obviously has major consequences for parsers.  However, as long as you stay with the original JS Number scope everything works just fine.

One camp suggests that the right solution is to use some kind of BigNumber as the underlying Number type which surely is one way dealing with *data type overloading*.

Other people (including myself) are more pragmatic and pretty much dismiss JSON Number as a suitable notation for numbers outside of the original JS scope.  This view is also aligned with most IETF and W3C standards to date defining JSON structures.

Now to the challenge: Create a scheme that makes everybody happy!  Well, to be more realistic; create something that maybe nobody really likes, by supporting BOTH of the opposing views.

Feel free slashing my minuscule change proposal:
https://github.com/tc39/proposal-bigint/issues/162#issuecomment-408679884

Cheers,
Anders
On 2018-08-01 05:37, Richard Gibson wrote:

> JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript JSON.parse implementation simply cannot accept e.g. 0n and still uphold the conformance guarantees <https://tc39.github.io/ecma262/#sec-json-object>:
>
>     Conforming implementations of *JSON.parse* and *JSON.stringify* must support the exact interchange format described in the ECMA-404 specification without any deletions or extensions to the format.
>
>
> Both BigInt and Symbol lack native support in JSON, and although adding in custom serialization is relatively easy, custom parsing is not because JSON.parse doesn't expose the text used to produce a value. But in my opinion, it would be a mistake to characterize that explicit lack of support as "limbo".
>
> On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 2018-07-28 00:34, Richard Gibson wrote:
>      > As stated even more strongly in ECMA-404:
>      >
>      >     Because it is so simple, it is not expected that the JSON grammar will ever change. This gives JSON, as a foundational notation, tremendous stability.
>      >
>
>     Richard, that's great but it doesn't completely respond to my "limbo" claim:
>
>     https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html
>
>     Take your pick! Whatever you come up with, I'm sure there will be some rotten tomatoes flying around :-)
>
>     Cheers,
>     Anders
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6. Was: javascript vision thing

Isiah Meadows-2
> Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This obviously
> has major consequences for parsers.  However, as long as you stay with the
> original JS Number scope everything works just fine.

BTW, most strongly typed languages parse numbers one of two ways:

- If it's just digits, it's parsed as an integer (typically an `int` or `long`)
- If it has floating point stuff, it's parsed as a float (typically a `double`)

> Other people (including myself) are more pragmatic and pretty much dismiss
> JSON Number as a suitable notation for numbers outside of the original JS
> scope.  This view is also aligned with most IETF and W3C standards to date
> defining JSON structures.

In general, JSON is great for prototyping protocols and easy
serialization when performance *isn't* a major concern, but that's
about it. (It's better than XML and more performant than it, but it's
still needlessly complex to parse/serialize.)

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Wed, Aug 1, 2018 at 1:51 AM, Anders Rundgren
<[hidden email]> wrote:

> Richard et al,
>
> If we call the situation "limbo" or not isn't that important, I just happen
> to have a preference for strong or funny expressions.
>
> The root of the problem (not only for JavaScript) is that JSON is *the only
> general purpose data interchange format in existence* that uses a single
> notion to signal "here comes a number".
>
> Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This obviously
> has major consequences for parsers.  However, as long as you stay with the
> original JS Number scope everything works just fine.
>
> One camp suggests that the right solution is to use some kind of BigNumber
> as the underlying Number type which surely is one way dealing with *data
> type overloading*.
>
> Other people (including myself) are more pragmatic and pretty much dismiss
> JSON Number as a suitable notation for numbers outside of the original JS
> scope.  This view is also aligned with most IETF and W3C standards to date
> defining JSON structures.
>
> Now to the challenge: Create a scheme that makes everybody happy!  Well, to
> be more realistic; create something that maybe nobody really likes, by
> supporting BOTH of the opposing views.
>
> Feel free slashing my minuscule change proposal:
> https://github.com/tc39/proposal-bigint/issues/162#issuecomment-408679884
>
> Cheers,
> Anders
> On 2018-08-01 05:37, Richard Gibson wrote:
>>
>> JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript
>> JSON.parse implementation simply cannot accept e.g. 0n and still uphold the
>> conformance guarantees <https://tc39.github.io/ecma262/#sec-json-object>:
>>
>>     Conforming implementations of *JSON.parse* and *JSON.stringify* must
>> support the exact interchange format described in the ECMA-404 specification
>> without any deletions or extensions to the format.
>>
>>
>> Both BigInt and Symbol lack native support in JSON, and although adding in
>> custom serialization is relatively easy, custom parsing is not because
>> JSON.parse doesn't expose the text used to produce a value. But in my
>> opinion, it would be a mistake to characterize that explicit lack of support
>> as "limbo".
>>
>> On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren
>> <[hidden email] <mailto:[hidden email]>>
>> wrote:
>>
>>     On 2018-07-28 00:34, Richard Gibson wrote:
>>      > As stated even more strongly in ECMA-404:
>>      >
>>      >     Because it is so simple, it is not expected that the JSON
>> grammar will ever change. This gives JSON, as a foundational notation,
>> tremendous stability.
>>      >
>>
>>     Richard, that's great but it doesn't completely respond to my "limbo"
>> claim:
>>
>>     https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html
>>
>>     Take your pick! Whatever you come up with, I'm sure there will be some
>> rotten tomatoes flying around :-)
>>
>>     Cheers,
>>     Anders
>>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6. Was: javascript vision thing

kai zhu

@isiah, actionable items before stage-4 are currently being debated @ https://github.com/tc39/proposal-bigint/issues/162


On Aug 1, 2018 14:00, "Isiah Meadows" <[hidden email]> wrote:
> Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This obviously
> has major consequences for parsers.  However, as long as you stay with the
> original JS Number scope everything works just fine.

BTW, most strongly typed languages parse numbers one of two ways:

- If it's just digits, it's parsed as an integer (typically an `int` or `long`)
- If it has floating point stuff, it's parsed as a float (typically a `double`)

> Other people (including myself) are more pragmatic and pretty much dismiss
> JSON Number as a suitable notation for numbers outside of the original JS
> scope.  This view is also aligned with most IETF and W3C standards to date
> defining JSON structures.

In general, JSON is great for prototyping protocols and easy
serialization when performance *isn't* a major concern, but that's
about it. (It's better than XML and more performant than it, but it's
still needlessly complex to parse/serialize.)

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Wed, Aug 1, 2018 at 1:51 AM, Anders Rundgren
<[hidden email]> wrote:
> Richard et al,
>
> If we call the situation "limbo" or not isn't that important, I just happen
> to have a preference for strong or funny expressions.
>
> The root of the problem (not only for JavaScript) is that JSON is *the only
> general purpose data interchange format in existence* that uses a single
> notion to signal "here comes a number".
>
> Is 1 a byte, int, double, BigInt or BigNumber?  You tell me!  This obviously
> has major consequences for parsers.  However, as long as you stay with the
> original JS Number scope everything works just fine.
>
> One camp suggests that the right solution is to use some kind of BigNumber
> as the underlying Number type which surely is one way dealing with *data
> type overloading*.
>
> Other people (including myself) are more pragmatic and pretty much dismiss
> JSON Number as a suitable notation for numbers outside of the original JS
> scope.  This view is also aligned with most IETF and W3C standards to date
> defining JSON structures.
>
> Now to the challenge: Create a scheme that makes everybody happy!  Well, to
> be more realistic; create something that maybe nobody really likes, by
> supporting BOTH of the opposing views.
>
> Feel free slashing my minuscule change proposal:
> https://github.com/tc39/proposal-bigint/issues/162#issuecomment-408679884
>
> Cheers,
> Anders
> On 2018-08-01 05:37, Richard Gibson wrote:
>>
>> JSON is defined by ECMA-404 and RFC 8259, not by ECMA-262. An ECMAScript
>> JSON.parse implementation simply cannot accept e.g. 0n and still uphold the
>> conformance guarantees <https://tc39.github.io/ecma262/#sec-json-object>:
>>
>>     Conforming implementations of *JSON.parse* and *JSON.stringify* must
>> support the exact interchange format described in the ECMA-404 specification
>> without any deletions or extensions to the format.
>>
>>
>> Both BigInt and Symbol lack native support in JSON, and although adding in
>> custom serialization is relatively easy, custom parsing is not because
>> JSON.parse doesn't expose the text used to produce a value. But in my
>> opinion, it would be a mistake to characterize that explicit lack of support
>> as "limbo".
>>
>> On Sat, Jul 28, 2018 at 1:02 AM Anders Rundgren
>> <[hidden email] <mailto:[hidden email]>>
>> wrote:
>>
>>     On 2018-07-28 00:34, Richard Gibson wrote:
>>      > As stated even more strongly in ECMA-404:
>>      >
>>      >     Because it is so simple, it is not expected that the JSON
>> grammar will ever change. This gives JSON, as a foundational notation,
>> tremendous stability.
>>      >
>>
>>     Richard, that's great but it doesn't completely respond to my "limbo"
>> claim:
>>
>>     https://mail.mozilla.org/pipermail/es-discuss/2018-July/051388.html
>>
>>     Take your pick! Whatever you come up with, I'm sure there will be some
>> rotten tomatoes flying around :-)
>>
>>     Cheers,
>>     Anders
>>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

Anders Rundgren-2
In reply to this post by Isiah Meadows-2
For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162
available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6

Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
OTOH, a fairly decent rationale for not specifying a default is also provided :-)
This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859

Cheers,
Anders
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

J Decker
my primary usage of json is 

in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in the same sort of thing as the input; although I guess dates do get lost in translation anyway, but they could be handled as numbers with a few more character exceptions ':','-'(in a number),'Z',' ' the last one (the space) complicating the whole thing immensely; there is no meaning of multiple numbers without a ',' between them in JSON, so maybe not so impossible.

and given the requirement that seems to be lost, that bigints ONLY interop with bigints, they MUST decode the same as their encoding; the JSONnumber type almost works; but requires custom code every time bigints are used. (much like dates)

what writing a JSON parser taught me, is the type of a variable is the type of the data it has; and JSON does a really good job of representing 99% of generally communicated types. which makes generic code quite easy... without having to respecify/recast the data, the data is already the type it is.

but there's certainly fewer of me, than of those that thing everything is perfectly fine, and shouldn't evolve as the langugage has.  
but then there's 'don't break the net' and 'this could certainy break the net'; but since bigints didn't exist before, I guess they shouldn't be added now, because sending them to old code would break  the old code.... but actually since being added; should also update JSON to support that number type (although I guess base JSON doesn't suppose ES6 number encodings like 0x, 0b, etc...) 

and again, since bigints ONLY interop with other bigints, there should be no chance they will get lost in interpretation.

can see JSONnumber can aid application handling; but if you send bigints to an application that doesn't support bigints it's not going to work anyway; so why not just let existing json.parse throw when it doens't have bigint support?
On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <[hidden email]> wrote:
For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162
available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6

Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
OTOH, a fairly decent rationale for not specifying a default is also provided :-)
This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859


 
Cheers,
Anders
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

Anders Rundgren-2
On 2018-08-14 06:55, J Decker wrote:
> my primary usage of json is
> https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects
>
> in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in the same sort of thing as the input; although I guess dates do get lost in translation anyway, but they could be handled as numbers with a few more character exceptions ':','-'(in a number),'Z',' ' the last one (the space) complicating the whole thing immensely; there is no meaning of multiple numbers without a ',' between them in JSON, so maybe not so impossible.
>
> and given the requirement that seems to be lost, that bigints ONLY interop with bigints, they MUST decode the same as their encoding; the JSONnumber type almost works; but requires custom code every time bigints are used. (much like dates)
>
> what writing a JSON parser taught me, is the type of a variable is the type of the data it has; and JSON does a really good job of representing 99% of generally communicated types. which makes generic code quite easy... without having to respecify/recast the data, the data is already the type it is.

Since the JSON standard doesn't distinguish between a single bit or BigNumber, I guess you are proposing extensions to JSON?


> but there's certainly fewer of me, than of those that thing everything is perfectly fine, and shouldn't evolve as the langugage has.
> but then there's 'don't break the net' and 'this could certainy break the net'; but since bigints didn't exist before, I guess they shouldn't be added now, because sending them to old code would break  the old code.... but actually since being added; should also update JSON to support that number type (although I guess base JSON doesn't suppose ES6 number encodings like 0x, 0b, etc...)
>
> and again, since bigints ONLY interop with other bigints, there should be no chance they will get lost in interpretation.
>
> can see JSONnumber can aid application handling; but if you send bigints to an application that doesn't support bigints it's not going to work anyway; so why not just let existing json.parse throw when it doens't have bigint support?

The proposal is targeting *cross-platform applications* using JSON.  The only thing it adds is offering a way to use JSON Number formatting for new numeric types, in addition to the quoting schemes which already are fully supported (and extensively used as well).

Example: A java class element like `BigInteger big;` used in a JSON context presumes that all values targeting "big" should be treated as BigIntger (=BigInt).  However, there are different practices for formatting BigIntegers in JSON and they are all "right" :-)

In essence, the proposal's only ambition is making the ES6 JSON object better aligned with an already established JSON reality.

Anders

> On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <[hidden email] <mailto:[hidden email]>> wrote:
>
>     For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162
>     available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6
>
>     Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
>     OTOH, a fairly decent rationale for not specifying a default is also provided :-)
>     This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859
>
>
>     Cheers,
>     Anders
>     _______________________________________________
>     es-discuss mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

Michał Wadas
Personally, I would like to see:
- third argument to JSON.parse reviver, "raw string"
- new class JSON.Fragment accepting any syntactically valid JSON in constructor (eg. new JSON.Fragment('99999999999999999')
- returning JSON.Fragment from JSON.stringify would paste it as-it-is into string output

This should cover any Bigint use case without breaking backward compatibility. 

On Tue, 14 Aug 2018, 07:57 Anders Rundgren, <[hidden email]> wrote:
On 2018-08-14 06:55, J Decker wrote:
> my primary usage of json is
> https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects
>
> in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in the same sort of thing as the input; although I guess dates do get lost in translation anyway, but they could be handled as numbers with a few more character exceptions ':','-'(in a number),'Z',' ' the last one (the space) complicating the whole thing immensely; there is no meaning of multiple numbers without a ',' between them in JSON, so maybe not so impossible.
>
> and given the requirement that seems to be lost, that bigints ONLY interop with bigints, they MUST decode the same as their encoding; the JSONnumber type almost works; but requires custom code every time bigints are used. (much like dates)
>
> what writing a JSON parser taught me, is the type of a variable is the type of the data it has; and JSON does a really good job of representing 99% of generally communicated types. which makes generic code quite easy... without having to respecify/recast the data, the data is already the type it is.

Since the JSON standard doesn't distinguish between a single bit or BigNumber, I guess you are proposing extensions to JSON?


> but there's certainly fewer of me, than of those that thing everything is perfectly fine, and shouldn't evolve as the langugage has.
> but then there's 'don't break the net' and 'this could certainy break the net'; but since bigints didn't exist before, I guess they shouldn't be added now, because sending them to old code would break  the old code.... but actually since being added; should also update JSON to support that number type (although I guess base JSON doesn't suppose ES6 number encodings like 0x, 0b, etc...)
>
> and again, since bigints ONLY interop with other bigints, there should be no chance they will get lost in interpretation.
>
> can see JSONnumber can aid application handling; but if you send bigints to an application that doesn't support bigints it's not going to work anyway; so why not just let existing json.parse throw when it doens't have bigint support?

The proposal is targeting *cross-platform applications* using JSON.  The only thing it adds is offering a way to use JSON Number formatting for new numeric types, in addition to the quoting schemes which already are fully supported (and extensively used as well).

Example: A java class element like `BigInteger big;` used in a JSON context presumes that all values targeting "big" should be treated as BigIntger (=BigInt).  However, there are different practices for formatting BigIntegers in JSON and they are all "right" :-)

In essence, the proposal's only ambition is making the ES6 JSON object better aligned with an already established JSON reality.

Anders

> On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <[hidden email] <mailto:[hidden email]>> wrote:
>
>     For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162
>     available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6
>
>     Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
>     OTOH, a fairly decent rationale for not specifying a default is also provided :-)
>     This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859
>
>
>     Cheers,
>     Anders
>     _______________________________________________
>     es-discuss mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

Anders Rundgren-2
On 2018-08-14 15:34, Michał Wadas wrote:
> Personally, I would like to see:
> - third argument to JSON.parse reviver, "raw string"
> - new class JSON.Fragment accepting any syntactically valid JSON in constructor (eg. new JSON.Fragment('99999999999999999')
> - returning JSON.Fragment from JSON.stringify would paste it as-it-is into string output
>
> This should cover any Bigint use case without breaking backward compatibility.

Would it be possible adding a little bit more meat to this? I didn't understand the "raw string" part :-(

JSON.Fragment seems like a more universalized version of JSONNumber.

BTW, my proposal is in fact designed to be 100% backward compatible.

Anders

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

Michael Theriot
In reply to this post by Michał Wadas
I've been brainstorming a few days and this is the same idea I reached. I just wasn't sure if returning some kind of special object (JSON.Fragment) was a good way to handle stringify.

Elaborating, basically a third argument would come back in JSON.parse reviver method, which is the actual string that was parsed (not the parsed value). When stringifying, a JSON.Fragment would not get parsed but inserts the underlying string value (which must be valid JSON).

JSON.Fragment would just be a way to use valid, raw strings in JSON. E.g.
JSON.stringify([0]) === JSON.stringify(JSON.Fragment("[0]")

On Tuesday, August 14, 2018, Michał Wadas <[hidden email]> wrote:
Personally, I would like to see:
- third argument to JSON.parse reviver, "raw string"
- new class JSON.Fragment accepting any syntactically valid JSON in constructor (eg. new JSON.Fragment('99999999999999999')
- returning JSON.Fragment from JSON.stringify would paste it as-it-is into string output

This should cover any Bigint use case without breaking backward compatibility. 

On Tue, 14 Aug 2018, 07:57 Anders Rundgren, <[hidden email]> wrote:
On 2018-08-14 06:55, J Decker wrote:
> my primary usage of json is
> https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects
>
> in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in the same sort of thing as the input; although I guess dates do get lost in translation anyway, but they could be handled as numbers with a few more character exceptions ':','-'(in a number),'Z',' ' the last one (the space) complicating the whole thing immensely; there is no meaning of multiple numbers without a ',' between them in JSON, so maybe not so impossible.
>
> and given the requirement that seems to be lost, that bigints ONLY interop with bigints, they MUST decode the same as their encoding; the JSONnumber type almost works; but requires custom code every time bigints are used. (much like dates)
>
> what writing a JSON parser taught me, is the type of a variable is the type of the data it has; and JSON does a really good job of representing 99% of generally communicated types. which makes generic code quite easy... without having to respecify/recast the data, the data is already the type it is.

Since the JSON standard doesn't distinguish between a single bit or BigNumber, I guess you are proposing extensions to JSON?


> but there's certainly fewer of me, than of those that thing everything is perfectly fine, and shouldn't evolve as the langugage has.
> but then there's 'don't break the net' and 'this could certainy break the net'; but since bigints didn't exist before, I guess they shouldn't be added now, because sending them to old code would break  the old code.... but actually since being added; should also update JSON to support that number type (although I guess base JSON doesn't suppose ES6 number encodings like 0x, 0b, etc...)
>
> and again, since bigints ONLY interop with other bigints, there should be no chance they will get lost in interpretation.
>
> can see JSONnumber can aid application handling; but if you send bigints to an application that doesn't support bigints it's not going to work anyway; so why not just let existing json.parse throw when it doens't have bigint support?

The proposal is targeting *cross-platform applications* using JSON.  The only thing it adds is offering a way to use JSON Number formatting for new numeric types, in addition to the quoting schemes which already are fully supported (and extensively used as well).

Example: A java class element like `BigInteger big;` used in a JSON context presumes that all values targeting "big" should be treated as BigIntger (=BigInt).  However, there are different practices for formatting BigIntegers in JSON and they are all "right" :-)

In essence, the proposal's only ambition is making the ES6 JSON object better aligned with an already established JSON reality.

Anders

> On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <[hidden email] <mailto:[hidden email]>> wrote:
>
>     For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162
>     available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6
>
>     Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
>     OTOH, a fairly decent rationale for not specifying a default is also provided :-)
>     This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859
>
>
>     Cheers,
>     Anders
>     _______________________________________________
>     es-discuss mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

Isiah Meadows-2
I like the idea, but I don't feel it's *quite* as simple as as just
adding an option for serializing BigInts/numbers as explicit
integers/floats.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Tue, Aug 14, 2018 at 2:31 PM Michael Theriot
<[hidden email]> wrote:

>
> I've been brainstorming a few days and this is the same idea I reached. I just wasn't sure if returning some kind of special object (JSON.Fragment) was a good way to handle stringify.
>
> Elaborating, basically a third argument would come back in JSON.parse reviver method, which is the actual string that was parsed (not the parsed value). When stringifying, a JSON.Fragment would not get parsed but inserts the underlying string value (which must be valid JSON).
>
> JSON.Fragment would just be a way to use valid, raw strings in JSON. E.g.
> JSON.stringify([0]) === JSON.stringify(JSON.Fragment("[0]")
>
> On Tuesday, August 14, 2018, Michał Wadas <[hidden email]> wrote:
>>
>> Personally, I would like to see:
>> - third argument to JSON.parse reviver, "raw string"
>> - new class JSON.Fragment accepting any syntactically valid JSON in constructor (eg. new JSON.Fragment('99999999999999999')
>> - returning JSON.Fragment from JSON.stringify would paste it as-it-is into string output
>>
>> This should cover any Bigint use case without breaking backward compatibility.
>>
>> On Tue, 14 Aug 2018, 07:57 Anders Rundgren, <[hidden email]> wrote:
>>>
>>> On 2018-08-14 06:55, J Decker wrote:
>>> > my primary usage of json is
>>> > https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects
>>> >
>>> > in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in the same sort of thing as the input; although I guess dates do get lost in translation anyway, but they could be handled as numbers with a few more character exceptions ':','-'(in a number),'Z',' ' the last one (the space) complicating the whole thing immensely; there is no meaning of multiple numbers without a ',' between them in JSON, so maybe not so impossible.
>>> >
>>> > and given the requirement that seems to be lost, that bigints ONLY interop with bigints, they MUST decode the same as their encoding; the JSONnumber type almost works; but requires custom code every time bigints are used. (much like dates)
>>> >
>>> > what writing a JSON parser taught me, is the type of a variable is the type of the data it has; and JSON does a really good job of representing 99% of generally communicated types. which makes generic code quite easy... without having to respecify/recast the data, the data is already the type it is.
>>>
>>> Since the JSON standard doesn't distinguish between a single bit or BigNumber, I guess you are proposing extensions to JSON?
>>>
>>>
>>> > but there's certainly fewer of me, than of those that thing everything is perfectly fine, and shouldn't evolve as the langugage has.
>>> > but then there's 'don't break the net' and 'this could certainy break the net'; but since bigints didn't exist before, I guess they shouldn't be added now, because sending them to old code would break  the old code.... but actually since being added; should also update JSON to support that number type (although I guess base JSON doesn't suppose ES6 number encodings like 0x, 0b, etc...)
>>> >
>>> > and again, since bigints ONLY interop with other bigints, there should be no chance they will get lost in interpretation.
>>> >
>>> > can see JSONnumber can aid application handling; but if you send bigints to an application that doesn't support bigints it's not going to work anyway; so why not just let existing json.parse throw when it doens't have bigint support?
>>>
>>> The proposal is targeting *cross-platform applications* using JSON.  The only thing it adds is offering a way to use JSON Number formatting for new numeric types, in addition to the quoting schemes which already are fully supported (and extensively used as well).
>>>
>>> Example: A java class element like `BigInteger big;` used in a JSON context presumes that all values targeting "big" should be treated as BigIntger (=BigInt).  However, there are different practices for formatting BigIntegers in JSON and they are all "right" :-)
>>>
>>> In essence, the proposal's only ambition is making the ES6 JSON object better aligned with an already established JSON reality.
>>>
>>> Anders
>>>
>>> > On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <[hidden email] <mailto:[hidden email]>> wrote:
>>> >
>>> >     For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162
>>> >     available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6
>>> >
>>> >     Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
>>> >     OTOH, a fairly decent rationale for not specifying a default is also provided :-)
>>> >     This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859
>>> >
>>> >
>>> >     Cheers,
>>> >     Anders
>>> >     _______________________________________________
>>> >     es-discuss mailing list
>>> >     [hidden email] <mailto:[hidden email]>
>>> >     https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > [hidden email]
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: JSON support for BigInt in ES6.

Anders Rundgren-2
In reply to this post by Michael Theriot
On 2018-08-14 20:30, Michael Theriot wrote:
> I've been brainstorming a few days and this is the same idea I reached.
> I just wasn't sure if returning some kind of special object (JSON.Fragment)
> was a good way to handle stringify.

Since we now are three who have the same (basic) idea it can't be all bad :-)

>
> Elaborating, basically a third argument would come back in
> JSON.parse reviver method, which is the actual string that was > parsed (not the parsed value).

Indeed, this *exactly* what my proposal suggests:
https://github.com/cyberphone/es6-bigint-json-support#22-rfc-mode-deserialization

The only difference is that my proposal is dedicated to JSON Number while Michal suggest JSON fragments.
The JSONNumber object can due to this restriction support additional number-related methods aiding the parsing process:
https://github.com/cyberphone/es6-bigint-json-support#223-syntax-checking-deserialization

Since the only non-conformant part of the JSON object actually is JSON Number, it seems like a dedicated solution would be more appropriate.

Anders


When stringifying, a JSON.Fragment would not get parsed but inserts the underlying string value (which must be valid JSON).

>
> JSON.Fragment would just be a way to use valid, raw strings in JSON. E.g.
> JSON.stringify([0]) === JSON.stringify(JSON.Fragment("[0]")
>
> On Tuesday, August 14, 2018, Michał Wadas <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Personally, I would like to see:
>     - third argument to JSON.parse reviver, "raw string"
>     - new class JSON.Fragment accepting any syntactically valid JSON in constructor (eg. new JSON.Fragment('99999999999999999')
>     - returning JSON.Fragment from JSON.stringify would paste it as-it-is into string output
>
>     This should cover any Bigint use case without breaking backward compatibility.
>
>     On Tue, 14 Aug 2018, 07:57 Anders Rundgren, <[hidden email] <mailto:[hidden email]>> wrote:
>
>         On 2018-08-14 06:55, J Decker wrote:
>          > my primary usage of json is
>          > https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects <https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications#Using_JSON_to_transmit_objects>
>          >
>          > in which case JSON.parse( JSON.strinigfy( msg ) ) really needs to result in the same sort of thing as the input; although I guess dates do get lost in translation anyway, but they could be handled as numbers with a few more character exceptions ':','-'(in a number),'Z',' ' the last one (the space) complicating the whole thing immensely; there is no meaning of multiple numbers without a ',' between them in JSON, so maybe not so impossible.
>          >
>          > and given the requirement that seems to be lost, that bigints ONLY interop with bigints, they MUST decode the same as their encoding; the JSONnumber type almost works; but requires custom code every time bigints are used. (much like dates)
>          >
>          > what writing a JSON parser taught me, is the type of a variable is the type of the data it has; and JSON does a really good job of representing 99% of generally communicated types. which makes generic code quite easy... without having to respecify/recast the data, the data is already the type it is.
>
>         Since the JSON standard doesn't distinguish between a single bit or BigNumber, I guess you are proposing extensions to JSON?
>
>
>          > but there's certainly fewer of me, than of those that thing everything is perfectly fine, and shouldn't evolve as the langugage has.
>          > but then there's 'don't break the net' and 'this could certainy break the net'; but since bigints didn't exist before, I guess they shouldn't be added now, because sending them to old code would break  the old code.... but actually since being added; should also update JSON to support that number type (although I guess base JSON doesn't suppose ES6 number encodings like 0x, 0b, etc...)
>          >
>          > and again, since bigints ONLY interop with other bigints, there should be no chance they will get lost in interpretation.
>          >
>          > can see JSONnumber can aid application handling; but if you send bigints to an application that doesn't support bigints it's not going to work anyway; so why not just let existing json.parse throw when it doens't have bigint support?
>
>         The proposal is targeting *cross-platform applications* using JSON.  The only thing it adds is offering a way to use JSON Number formatting for new numeric types, in addition to the quoting schemes which already are fully supported (and extensively used as well).
>
>         Example: A java class element like `BigInteger big;` used in a JSON context presumes that all values targeting "big" should be treated as BigIntger (=BigInt).  However, there are different practices for formatting BigIntegers in JSON and they are all "right" :-)
>
>         In essence, the proposal's only ambition is making the ES6 JSON object better aligned with an already established JSON reality.
>
>         Anders
>
>          > On Mon, Aug 13, 2018 at 12:33 AM Anders Rundgren <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>          >
>          >     For good or for worse I have written a proposal for https://github.com/tc39/proposal-bigint/issues/162 <https://github.com/tc39/proposal-bigint/issues/162>
>          >     available at https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6 <https://github.com/cyberphone/es6-bigint-json-support#json-support-for-bigint-in-es6>
>          >
>          >     Since the proposal doesn't introduce a default serialization mode, I guess nobody will be happy :-(
>          >     OTOH, a fairly decent rationale for not specifying a default is also provided :-)
>          >     This comment is also worth reading: https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859 <https://github.com/tc39/proposal-bigint/issues/162#issuecomment-409700859>
>          >
>          >
>          >     Cheers,
>          >     Anders
>          >     _______________________________________________
>          >     es-discuss mailing list
>          > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>          > https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>          >
>          >
>          >
>          > _______________________________________________
>          > es-discuss mailing list
>          > [hidden email] <mailto:[hidden email]>
>          > https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>          >
>
>         _______________________________________________
>         es-discuss mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

kai zhu
In reply to this post by Richard Gibson
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: javascript vision thing

Darien Valentine
In reply to this post by kai zhu
Unsubscribing from this mailing list, which seems to have become a spam platform.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: javascript vision thing

Isiah Meadows-2
You do that by going to here, typing in your password, and clicking "unsubscribe"


On Fri, Sep 21, 2018 at 21:11 Darien Valentine <[hidden email]> wrote:
Unsubscribing from this mailing list, which seems to have become a spam platform.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [nodejs] Re: javascript vision thing

kai zhu
In reply to this post by kai zhu
yes, in order of severity:

1. es6 generators and modules are the top 2 notorious things that come to mind as being difficult to debug/integrate in product-development.

2. classes (and typescript, though not directly es6-related), tend to create lots of unnecessary structure that becomes a PITA when you need to rewrite everything, which occurs often in product-development.  there are lots of newly minted js-devs entering industry, who lack experience in understanding the risks of javascript over-engineering (and that nothing you write is permanent).  they write lots of semi-permanent, es6 infrastructure-code during the initial design-phase, which is a general no-no for many veterans, who understand most of that stuff is going to get tossed out the window and rewritten during integration-phase (and again everytime a ux feature-request comes in that breaks the existing integration-workflow).

3. let and const declarations.  most code you debug/write in javascript is ux-related integration-code dealing with async-io, which relies heavily on function-scoped closures to pass variables across process-ticks.  block-level scoping is an unnecessary design-pattern that leads to confusion over the former.

4. fat-arrow.  it has garden-path issues, making it difficult to write efficient javascript-parsers that can differentiate the following [valid] javascript-code:
```js
(aa = 1, bb = 2, cc = 3);
// vs
(aa = 1, bb = 2, cc = 3) => aa + bb;
```
this leads to fundamental performance-issues with tooling/minification/test-coverage-instrumenters.  jslint for efficiency-reasons, simply cheats and assumes both of the above are fat-arrows, and raises fat-arrow warnings for both (and halts further parsing) [1].

[1] jslint managing garden-path complexity of fat-arrow, with a single lookahead, that can turn out wrong, so it halts parsing.


On 22 Sep 2018, at 12:04 PM, Siegfried Bilstein <[hidden email]> wrote:

Do you have examples of the patterns and es6 features you describe? 

Siggy

On Sat, Sep 22, 2018 at 01:02 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from Gmail Mobile

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Michael J. Ryan
In reply to this post by kai zhu
Considering how many js devs fail to answer "what values evaluate to false in JavaScript". It isn't the new features that are the problem.

There's a combination of problems.  People believing they're better developers than they are.  People who look down on js and front end development.  And those ahead to learn new things.

JS isn't really evolving any more than Java, C#, go, python and others as a whole in the past 20 years.  And having to fight uphill to use newer features is a pain.  I'm not on the younger side of this (I'm 42)... But I've managed to keep up.

On Fri, Sep 21, 2018, 17:14 kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Simon Blackwell
In reply to this post by kai zhu
This has little to do with Javascript ... I started coding in 1985 and managing (while still coding) in 1990. I have managed teams of up to 200 working on multiple products at the same time and delivered products in 8086 Assembler, Lisp, Prolog, C++, and Javascript. The only language in which I did not see this issue was Assembler. So, from my perspective, the problem has been around for over 25 years and probably goes beyond the software development realm.

In my experience, during an interview, close to 100 percent of developers will rate themselves as a 7 or an 8 out of 10 (with 10 being best).

On Sat, Sep 22, 2018, 1:14 AM kai zhu <[hidden email]> wrote:
a problem i've observed in industry is that many es6 language-features have the unintended-consequence of incentivising incompetent javascript-developers at the expense of competent-ones.  its generally difficult for many employers (even those knowledgeable in general-purpose programming), to discern between:

a) a competent javascript employee/contractor who can get things done and ship products (albeit with legitimate delays), and
b) an incompetent-one who can easily hide themselves in non-productive es6 busywork, and continually pushback product-integration (again with “legitimate” delays, until its too late).

its gotten bad enough that many industry-employers no longer trust general-purpose-programming technical-interviews when recruiting js-devs, and rely almost exclusively on either a) an applicant's reputation / word-of-mouth for getting things done, or b) their ability to complete a time-consuming tech-challenge, where they must demonstrate ability to ship a mini-product.  both methods are not scalable to meet the demand in industry for qualified js-devs in product-development.

the only solution i can think of to this industry-problem is to hold-back on introducing new disruptive/unproven javascript design-patterns, and figuring out how to educate the industry with tightened javascript style-guides and existing design-patterns proven to work (more is less); generally, ways to enhance the current, woefully inadequate “bullsh*t detector” of employers so they can better identify and mentor/train/weed-out unqualified js-devs.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12345