You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the October, 2024 TC39 plenary, some concerns were raised over the potential for developers to overlook the "hidden costs" of Extractors evaluating user code via the custom matcher protocol. If possible, I would like to request a usability study to ascertain developer intuition around the feature, and whether developers would feel knowledgeable enough about the mechanics of the feature to make an informed decision about the runtime performance of using this mechanism vs. other existing mechanisms. I've regularly described the feature as "evaluating user-defined code as part of destructuring for the purpose of data validation and transformation" and that "extraction is the dual of (function) application" with the express purpose of making evident that the runtime cost you should associate with an Extractor should be roughly equivalent to the runtime cost you would associate with a function call. It would be profoundly useful to determine whether that sentiment matches developer intuition.
I'm curious as to what the process would be for such a user study, and how the study would avoid bias. Would prior experience with similar concepts in other languages be tracked? Would it be introducing developers to the syntax with or without explanation?
During the October, 2024 TC39 plenary, some concerns were raised over the potential for developers to overlook the "hidden costs" of Extractors evaluating user code via the custom matcher protocol. If possible, I would like to request a usability study to ascertain developer intuition around the feature, and whether developers would feel knowledgeable enough about the mechanics of the feature to make an informed decision about the runtime performance of using this mechanism vs. other existing mechanisms. I've regularly described the feature as "evaluating user-defined code as part of destructuring for the purpose of data validation and transformation" and that "extraction is the dual of (function) application" with the express purpose of making evident that the runtime cost you should associate with an Extractor should be roughly equivalent to the runtime cost you would associate with a function call. It would be profoundly useful to determine whether that sentiment matches developer intuition.
I'm curious as to what the process would be for such a user study, and how the study would avoid bias. Would prior experience with similar concepts in other languages be tracked? Would it be introducing developers to the syntax with or without explanation?
Related #29
The text was updated successfully, but these errors were encountered: