| 08:18 | <annevk> | littledan: I paged most of the scoping discussion we had out again, but I was wondering if https://github.com/whatwg/html/issues/8476 and https://github.com/fserb/canvas2D/blob/master/spec/layers.md are something it could help with. In particular giving you syntax for exiting the scope that would then result in endLayer() getting invoked. (As well as allow for nesting of scopes.) |
| 12:37 | <littledan> | Oh is this a potential place where the using declaration could help? |
| 12:41 | <Domenic> | Yeah I think so, although not sure about the nesting thing |
| 12:45 | <littledan> | Annevk: it would be great to have your thoughts in https://github.com/w3ctag/design-reviews/discussions/800 especially if it might feed back into any needed changes for the disposal API—it’d be ideal to work all that out before the whole set of proposals reaches Stage 3 |
| 16:27 | <annevk> | I essentially put my earlier comment from here, there. Hope that's useful :-) |
| 17:43 | <Greg> | Hi, I asked where I could post my objection to the pipe operator So here is my objection, copy/pasted from Github:
|
| 17:45 | <ljharb> | Greg: if it wasn't clear from my github comment, the tone of your objection is not in the spirit of our code of conduct |
| 17:45 | <ljharb> | is there something specific about the pipeline operator you think should be different? a generic "new things are complicated" isn't really productive |
| 17:46 | <Greg> | I think the pipe operator shouldn't exist, period. That is my objection. My reasoning is the disaster that is C++. Anyone familiar with C++ knows what I'm talking about, I think. |
| 17:47 | <Greg> | When a language adds more and more syntax, it makes the language more difficult to use |
| 17:47 | <ljharb> | that objection is basically useless, because lots of us think it should |
| 17:47 | <Greg> | This additional syntax represents a cognitive burden to the developer |
| 17:47 | <ljharb> | and i'm not sure how C++ is relevant |
| 17:47 | <ljharb> | yes, all additional features represent a cognitive burden |
| 17:47 | <ljharb> | should we all pack up and go home? |
| 17:47 | <ljharb> | that's not a useful argument |
| 17:48 | <Greg> | No, we should design good languages. I have a more longform blog post on this subject here: https://www.taoeffect.com/blog/2010/01/how-newlisp-took-my-breath-and-syntax-away/ |
| 17:48 | <ljharb> | "good" is subjective, and "less syntax" is not an objectively good quality (nor is "more syntax" an objectively good one, ofc) |
| 17:48 | <Greg> | |> is unnecessary complexity |
| 17:48 | <ljharb> | unnecessary for you, perhaps |
| 17:48 | <ljharb> | clearly necessary for some |
| 17:48 | <Greg> | It's literally unnecessary |
| 17:48 | <Greg> | How is it necessary? The proposal shows how things can be written using the existing syntax in a shorter way |
| 17:48 | <ljharb> | it's necessary if you want to express a sequence of statements in a left-to-right order |
| 17:49 | <ljharb> | "shorter" isn't the important bit here - "left to right" is. |
| 17:49 | <ljharb> | clarity, not brevity, is what's important when writing code. |
| 17:49 | <Greg> | Then my proposal would be to change JavaScript so that this symbol can be used in a way that does not add new syntax |
| 17:49 | <ljharb> | sometimes those are the same, sometimes they're not |
| 17:49 | <ljharb> | it's not possible to do without new syntax. |
| 17:49 | <Greg> | For example, in LISPs the |> operator is trivial to add without adding new syntax to the language |
| 17:50 | <ljharb> | yes but JS isn't and never can be a LISP |
| 17:50 | <ljharb> | for example, you can't await in the middle of a pipeline unless it's syntax. |
| 17:50 | <ljharb> | i hear you that you're upset that JS doesn't work the same as a language you like (LISP, i assume?), but that's not the same thing as "it's possible to make JS into the language you like" |
| 17:51 | <ljharb> | btw i hope you realize that i'm truly trying to have a good-faith discussion with you here, despite your abrupt and confrontational entrance. you're not being ignored or brushed aside. |
| 17:53 | <Greg> | I appreciate that, and I realize that is exactly how I entered this discussion, and that it would probably have been better to do so with more diplomacy. I am however time pressured at the moment, and it was either that abrupt reply or saying nothing at all |
| 17:53 | <Greg> | Please consider the road this is putting JS down. How much more syntax can the language handle before it becomes a monstrosity to more people? It is already a monstrosity to many |
| 17:54 | <ljharb> | there are a number of folks on TC39 who share your general sentiment that "too much syntax" is something to avoid. the "tragedy of the common lisp" article has been cited dozens of times |
| 17:54 | <ljharb> | that's not an argument against any specific proposal though, and it doesn't have consensus as a ban on further syntax. |
| 17:55 | <ljharb> | so rest assured, if that's the extent of your pushback on this proposal, your viewpoint has long been strongly represented. |
| 17:55 | <Greg> | OK, thanks for hearing me out |
| 17:55 | <ljharb> | absolutely |
| 17:55 | <ljharb> | nobody wants JS to become a syntax soup that's hard for people to learn and understand - even those that are enthusiastic about specific syntax proposals |
| 17:57 | <Chris de Almeida> | Greg: also, FWIW, know that preventing unnecessary bloat in the language is an issue that is regularly raised in plenary, and proposals absolutely must pass that sniff test to go anywhere |
| 18:08 | <Greg> | I guess I would ask the people who are working on modifying JavaScript: when is enough enough (in terms of the syntax)? Does such a point exist? Or will the syntax be modified into perpetuity? There are costs to this:
So again. Is there a line that shouldn't be crossed, and what does that line look like? It would be nice if that question were decided upon, at some point. |
| 18:09 | <Jack Works> | https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 |
| 18:09 | <Jack Works> | Maybe you're interested in this article |
| 18:13 | <Greg> | Thanks Jack Works, yes it's saying essentially the same thing, nice article |
| 18:16 | <Greg> | Edited my comment above to add 2 more costs:
|
| 18:25 | <Andreu Botella> | Little of that seems specific to syntax |
| 18:35 | <Greg> | Andreu Botella: how is it not specific to syntax? |
| 18:37 | <Andreu Botella> | Any change in the language will mean changes for users, tooling and engines |
| 18:40 | <Greg> | The standard of the language as it impacts browser developers is primarily the syntax, but sure, there might be other aspects of the language that could have these costs too |
| 18:54 | <Andreu Botella> | I don't think that's true |
| 18:55 | <Andreu Botella> | JS has a bunch of built-ins that are defined by the spec |
| 18:56 | <Greg> | I am agreeing with you, so I'm not sure what you're saying isn't true, if you could be more specific it'd be appreciated |
| 19:10 | <ryzokuken> | Greg: I see the basis of your argument but I think to some extent you're overestimating the effect of syntax additions of the language. |
| 19:20 | <Greg> | ryzokuken: Has the number of independent browsers supporting the latest features of JavaScript gone up or down over time? |
| 19:22 | <ryzokuken> | Irrespective of the answer, the point I'm trying to make is that syntax additions to JavaScript are far from the main cause of these things. |
| 19:27 | <ryzokuken> | I think a much better argument can be made on the grounds of ergonomics and language complexity |
| 19:27 | <ryzokuken> | But even there, things aren't so black and white IMO |
| 19:28 | <ryzokuken> | Syntax additions to the language can actually make it more straightforward to code in many cases. |
| 19:35 | <ljharb> | generally in all cases, i'd hope |
| 23:00 | <James DiGioia (mAAdhaTTah on GH)> | ryzokuken: Has the number of independent browsers supporting the latest features of JavaScript gone up or down over time? |