from:"David White"

Re: Re: JavaScript Versioning

2017-07-23 Thread David White

Sorry, just seen this thread and thought it worth mentioning a similar thread 
ongoing here that has derived from wanting to remove less popular features from 
the specification:

https://esdiscuss.org/topic/removal-of-language-features

We should definitely continue this conversation in this thread.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

2017-07-23 Thread David White

Ooooh, a mime type based versioning would be very nice!

``

For the most part you control your applications language decision and honour 
that with your bundle then load additional scripts you have little control over 
such as logging, monitoring, stats, etc in different runtimes perhaps.

It’s certainly cleaner than injecting a version into the top of your bundle and 
would allow 3rd party vendors to provide version specific bundles.

David

> On 24 Jul 2017, at 00:43, doodad-js Admin <dooda...@gmail.com> wrote:
> 
> May I propose a new file extension and mime-type... "js2": 
> "application/javascript.2" ?
> 
> -----Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com] 
> Sent: Sunday, July 23, 2017 7:35 PM
> To: doodad-js Admin <dooda...@gmail.com>
> Subject: Re: Removal of language features
> 
> That’s an interesting proposal but I’m struggling to think how that would 
> solve this same issue 2 or 3 or 5 years down the line? JavaScript and 
> browsers have a symmetry along with HTML, CSS... and given the disparity of 
> devices today alone, let alone tomorrow a new major version would cause more 
> harm than good. Ideally we would need a solution that works as ES5 as 
> standard, then have that semantic in later versions of the language.
> 
> Perhaps this is not a problem for this community but something browser 
> providers should be providing / considering to allow developers to specify 
> their runtime in order to allow the language to progress more natrurally?
> 
> David
> 
> 
>> On 23 Jul 2017, at 23:38, doodad-js Admin <dooda...@gmail.com> wrote:
>> 
>> Maybe that's time to start a new major version of JS?
>> 
>> -Original Message-
>> From: David White [mailto:david.rhys.wh...@icloud.com] 
>> Sent: Sunday, July 23, 2017 5:54 PM
>> To: es-discuss@mozilla.org
>> Subject: Re: Re: Removal of language features
>> 
>> Lots of good thoughts and discussions here, and while it’s gone slightly off 
>> topic I’d love to discuss the possibilities of how we could get JavaScript 
>> to a point where we could actively remove features with every new 
>> specification.
>> 
>> I’m sure nobody would want to break the web, which would be very likely 
>> removing any parts of JavaScript, and certainly the biggest challenge, it 
>> does seem a shame that we can’t find an ulterior direction as it does seem 
>> allowing various features we consider bad practice today to still exist and 
>> the overhead that exists with them certainly hinders progress more than it 
>> helps.
>> 
>> Linting is certainly the fastest and easiest method, but to a certain extent 
>> I not really a solution in that we only lint our own code, and not the 
>> additional code that we rely upon. Ideally removal of features should mean 
>> more performance out of JavaScript, if engines have less constructs to deal 
>> with then there should be some beneficial performance related with that?
>> 
>> Given the lack of control over what browsers many users are using perhaps 
>> versioning could be a new semantic built into the language itself in the 
>> same way we have strict mode?
>> 
>> We could allow developers the option to specify the version they wish to 
>> use, avoiding unnecessary transpiration back to ES5 for applications 
>> confident enough to give their users the choice to upgrade if needed but 
>> also allow browsers to only run based on versions?
>> 
>> I'm sure it’s worth considering as removing features of a language / 
>> application is as important, if not more so, than adding features to a 
>> language or application.
>> 
>> David
>> 
> 
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

2017-07-23 Thread David White

That’s an interesting proposal but I’m struggling to think how that would solve 
this same issue 2 or 3 or 5 years down the line? JavaScript and browsers have a 
symmetry along with HTML, CSS... and given the disparity of devices today 
alone, let alone tomorrow a new major version would cause more harm than good. 
Ideally we would need a solution that works as ES5 as standard, then have that 
semantic in later versions of the language.

Perhaps this is not a problem for this community but something browser 
providers should be providing / considering to allow developers to specify 
their runtime in order to allow the language to progress more natrurally?

> On 23 Jul 2017, at 23:38, doodad-js Admin <dooda...@gmail.com> wrote:
> 
> Maybe that's time to start a new major version of JS?
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com] 
> Sent: Sunday, July 23, 2017 5:54 PM
> To: es-discuss@mozilla.org
> Subject: Re: Re: Removal of language features
> 
> Lots of good thoughts and discussions here, and while it’s gone slightly off 
> topic I’d love to discuss the possibilities of how we could get JavaScript to 
> a point where we could actively remove features with every new specification.
> 
> I’m sure nobody would want to break the web, which would be very likely 
> removing any parts of JavaScript, and certainly the biggest challenge, it 
> does seem a shame that we can’t find an ulterior direction as it does seem 
> allowing various features we consider bad practice today to still exist and 
> the overhead that exists with them certainly hinders progress more than it 
> helps.
> 
> Linting is certainly the fastest and easiest method, but to a certain extent 
> I not really a solution in that we only lint our own code, and not the 
> additional code that we rely upon. Ideally removal of features should mean 
> more performance out of JavaScript, if engines have less constructs to deal 
> with then there should be some beneficial performance related with that?
> 
> Given the lack of control over what browsers many users are using perhaps 
> versioning could be a new semantic built into the language itself in the same 
> way we have strict mode?
> 
> We could allow developers the option to specify the version they wish to use, 
> avoiding unnecessary transpiration back to ES5 for applications confident 
> enough to give their users the choice to upgrade if needed but also allow 
> browsers to only run based on versions?
> 
> I'm sure it’s worth considering as removing features of a language / 
> application is as important, if not more so, than adding features to a 
> language or application.
> 
> David
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Removal of language features

2017-07-19 Thread David White

Hi, 

I’m just curious as there are a lot of proposals for the addition of features 
to the ES specification, is there any scope for requests to remove language 
features? Going via the same means of writing a proposition that would attempt 
to support the removal of a feature, ultimately simplifying the specification 
and language?

David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: es-discuss Digest, Vol 125, Issue 51

2017-07-16 Thread David White

Too many operators can become quite confusing, having worked with many 
functional languages I find the number of operators more of a hinder than help. 
I’m very pro functional operators when they help me read the code explicitly 
rather than implicitly, for example with the `|>` pipeline operator, this helps 
you to read the code in the order of execution. With the current `|>` operator 
proposal you could write something similar with:

`const sum = numbers |> (numbers) => reduce(numbers, (a, b) => a + b);`

Passing numbers to an anonymous closure so you can have multiple arguments 
works quite elegantly.

David

> On 17 Jul 2017, at 00:11, es-discuss-requ...@mozilla.org wrote:
> 
> Send es-discuss mailing list submissions to
>   es-discuss@mozilla.org 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://mail.mozilla.org/listinfo/es-discuss 
> 
> or, via email, send a message with subject or body 'help' to
>   es-discuss-requ...@mozilla.org 
> 
> You can reach the person managing the list at
>   es-discuss-ow...@mozilla.org 
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
> Today's Topics:
> 
>   1. RE: Re: Functional Operators (doodad-js Admin)
>   2. Re: Array.prototype.tap (Eli White)
> 
> From: "doodad-js Admin" >
> Subject: RE: Re: Functional Operators
> Date: 16 July 2017 at 23:44:53 BST
> To: "'Ron Buckton'"  >, "'Darien Valentine'" 
> >, 
> >
> 
> 
> One question I have: why all these fuzzy (sorry, functional) operators? That 
> could become very hard to know what the code exactly does, and difficult to 
> debug... Are you becoming too “lazy” to type on the keyboard?
>  
>  
> From: Ron Buckton [mailto:ron.buck...@microsoft.com 
> ] 
> Sent: Sunday, July 16, 2017 3:54 PM
> To: Darien Valentine >; 
> es-discuss@mozilla.org 
> Subject: RE: Re: Functional Operators
>  
> (apologies for top posting as I’m replying from my phone)
>  
> Functional operators are not very interesting on their own, but are much more 
> interesting in terms of pipelines and partial application. However, they may 
> be a stretch in either scenario, so I’m not expecting them to be part of any 
> official proposal for pipeline/partial application at this time.
>  
> By ergonomic, I meant that ‘{+}’ is far fewer characters than ‘Math.add’. 
> Also, not every ‘+’ is arithmetic (i.e. string concatenation).
>  
> I can imagine a world where I can do:
>  
> ```js
> const sum = numbers |> reduce(?, {+});
> const joined = strings |> reduce(?, {+});
> ```
>  
> As a shorthand for:
>  
> ```js
> const sum = numbers |> reduce(?, (a, b) => a + b);
> const joined = strings |> reduce(?, (a, b) => a + b);
> ```
>  
> (I’m using `|>` here for pipeline and `?` as a positional argument for 
> partial application here)
>  
> Ron
>  
> From: Darien Valentine 
> Sent: Sunday, July 16, 2017 1:18 AM
> To: es-discuss@mozilla.org 
> Subject: Re: Re: Functional Operators
>  
> If I understand right, Ron, it means a new RHS for PrimaryExpression and 
> would behave like a reference, except that it is (presumably) not a valid 
> assignment target? Can you explain more about the ergonomics — maybe it’s 
> just from lack of familiarity, but to me this seems pretty grawlixy, like 
> something you’d see in Perl. 
>  
> In other words, I’m unsure how `arr.reduce({+})` is more ergonomic than 
> `arr.reduce(Math.add)`\*. Assuming it is and I’m just failing to see it, is 
> the benefit significant enough to merit new syntax?
>  
> (On further consideration, maybe `Reflect.add`, since `+` is not specific to 
> numeric values...)
>  
> On Sun, Jul 16, 2017 at 2:19 AM, Ron Buckton  > wrote:
> I have been looking into functional operators while working on a proposal for 
> pipeline and partial application. I’ve found that a sigil like `{+}` is just 
> as ergonomic as `(+)`, but has fewer lookahead issues with respect to regular 
> expression parsing. While `(/)` is ambiguous as to whether it would be a 
> division function or the start of a parenthesized regular expression literal, 
> `{/` is far less ambiguous in most expression positions. The only ambiguity 
> is at the statement level where `{/` could be interpreted as the start of a 
> block with a regular expression literal. However, it is fairly unlikely this 
> expression would be used in this

Re: Pipe operator for JavaScript

2017-07-11 Thread David White

Oh apologies for not taking a few moments to use the search facility. The 
linked github sounds extremely promising and certainly captures far more use 
cases than I initially intended.

Thanks Logan.

David


> On 11 Jul 2017, at 21:10, Logan Smyth <loganfsm...@gmail.com> wrote:
> 
> There's been talk of this before here and in 
> https://github.com/gilbert/es-pipeline-operator 
> <https://github.com/gilbert/es-pipeline-operator> among other places. Most 
> recently this was posted, which sounds like promising progress: 
> https://github.com/gilbert/es-pipeline-operator/issues/33#issuecomment-306986211
>  
> <https://github.com/gilbert/es-pipeline-operator/issues/33#issuecomment-306986211>
> 
> On Tue, Jul 11, 2017 at 1:02 PM, David White <david.rhys.wh...@icloud.com 
> <mailto:david.rhys.wh...@icloud.com>> wrote:
> Piping is useful when composing many small pure functions together, one 
> problem with this is the evaluation needs to be read from the inner most 
> expression value in reverse to the outer most function call. Given the 
> following statement we can see that it would be read as 'call math round then 
> call math square then pass in PI', whereas the order of execution is in 
> reverse.
> 
> ```javascript
> const myNumber = Math.round(Math.sqrt(Math.PI));
> ```
> 
> Unix has long provided a piping mechanism to achieve that, for example: `ps 
> aux | grep node`, as well as F# and the Elixir programming language, both 
> provide the `|>` pipe greater-than operator which is very readable.
> 
> My proposal would be to use the slightly more verbose `|>` pipe-greater than 
> syntax, it provides a convenient direction of travel for the expression on 
> the left side, into the expression on the right, F# also provides a `<|`, 
> which pipes in the opposite direction though I’ve not really seen very good 
> use cases for this operator.
> 
> ```javascript
> const myNumber = Math.PI |> Math.sqrt |> Math.round;
> ```
> 
> The left side of the operator should always be a primitive data type or data 
> structure, these could be any of the following: `Boolean`, `Null`, 
> `undefined`, `Number`, `String`, `Symbol` or `Object`. Since functions are 
> standard objects they can be passed in as the initial value, as long as the 
> function on the right handles the calling on that function.
> 
> It also provides a way to either log, process, or do anything with the data 
> from the last expression on the left at various stages of the execution 
> without adding additional brackets in and around the calls, for example.
> 
> ```javascript
> function logger (callback) {
>   return function (value) {
> callback(value);
> return value;
>   };
> }
> 
> Math.PI
>   |> logger(console.log);
>   |> Math.sqrt
>   |> logger(console.log);
>   |> Math.round
>   |> logger(console.log);
> ```
> 
> While a slightly contrived example as we certainly wouldn't write code that 
> looks like:
> 
> ```javascript
> logger(Math.round(logger(Math.sqrt(logger(Math.PI);
> ```
> 
> We would instead assign to variables at each stage of execution:
> 
> ```javascript
> const PI = Math.PI;
> logger(PI);
> 
> const squaredPI = Math.sqrt(PI);
> logger(squaredPI);
> 
> const roundedSquaredPI = Math.round(squaredPI);
> logger(roundedSquaredPI);
> ```
> 
> However with this clarity we have unfortunately had to create additional 
> constants within this lexical block, whereas simple value passing between 
> pure functions provides a very clean and readable approach and allows easier 
> updates in the future if we wanted to add additional processing within the 
> chain, for example Express middleware composition.
> 
> Would love to hear some thoughts on this?
> 
> David
> 
> * [F# pipe 
> operator](https://docs.microsoft.com/en-gb/dotnet/fsharp/language-reference/functions/index#function-composition-and-pipelining
>  
> <https://docs.microsoft.com/en-gb/dotnet/fsharp/language-reference/functions/index#function-composition-and-pipelining>)
> * [Elixir pipe 
> operator](https://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pipe-operator
>  
> <https://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pipe-operator>)
> * [Unix pipeline](https://en.wikipedia.org/wiki/Pipeline_(Unix) 
> <https://en.wikipedia.org/wiki/Pipeline_(Unix)>)
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss 
> <https://mail.mozilla.org/listinfo/es-discuss>
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Pipe operator for JavaScript

2017-07-11 Thread David White

Piping is useful when composing many small pure functions together, one problem 
with this is the evaluation needs to be read from the inner most expression 
value in reverse to the outer most function call. Given the following statement 
we can see that it would be read as 'call math round then call math square then 
pass in PI', whereas the order of execution is in reverse.

```javascript
const myNumber = Math.round(Math.sqrt(Math.PI));
```

Unix has long provided a piping mechanism to achieve that, for example: `ps aux 
| grep node`, as well as F# and the Elixir programming language, both provide 
the `|>` pipe greater-than operator which is very readable.

My proposal would be to use the slightly more verbose `|>` pipe-greater than 
syntax, it provides a convenient direction of travel for the expression on the 
left side, into the expression on the right, F# also provides a `<|`, which 
pipes in the opposite direction though I’ve not really seen very good use cases 
for this operator.

```javascript
const myNumber = Math.PI |> Math.sqrt |> Math.round;
```

The left side of the operator should always be a primitive data type or data 
structure, these could be any of the following: `Boolean`, `Null`, `undefined`, 
`Number`, `String`, `Symbol` or `Object`. Since functions are standard objects 
they can be passed in as the initial value, as long as the function on the 
right handles the calling on that function.

It also provides a way to either log, process, or do anything with the data 
from the last expression on the left at various stages of the execution without 
adding additional brackets in and around the calls, for example.

```javascript
function logger (callback) {
  return function (value) {
callback(value);
return value;
  };
}

Math.PI
  |> logger(console.log);
  |> Math.sqrt
  |> logger(console.log);
  |> Math.round
  |> logger(console.log);
```

While a slightly contrived example as we certainly wouldn't write code that 
looks like:

```javascript
logger(Math.round(logger(Math.sqrt(logger(Math.PI);
```

We would instead assign to variables at each stage of execution:

```javascript
const PI = Math.PI;
logger(PI);

const squaredPI = Math.sqrt(PI);
logger(squaredPI);

const roundedSquaredPI = Math.round(squaredPI);
logger(roundedSquaredPI);
```

However with this clarity we have unfortunately had to create additional 
constants within this lexical block, whereas simple value passing between pure 
functions provides a very clean and readable approach and allows easier updates 
in the future if we wanted to add additional processing within the chain, for 
example Express middleware composition.

Would love to hear some thoughts on this?

David

* [F# pipe 
operator](https://docs.microsoft.com/en-gb/dotnet/fsharp/language-reference/functions/index#function-composition-and-pipelining)
* [Elixir pipe 
operator](https://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pipe-operator)
* [Unix pipeline](https://en.wikipedia.org/wiki/Pipeline_(Unix))

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: JavaScript Versioning

Re: Removal of language features

Re: Removal of language features

Removal of language features

Re: es-discuss Digest, Vol 125, Issue 51

Re: Pipe operator for JavaScript

Pipe operator for JavaScript

7 matches

Site Navigation

Mail list logo

Footer information