> The point is that there is an unavoidable cost to the developer when
features are added to the language. My apologies if that wasn't clear.
You don't really need to argue that there is an unavoidable cost to new
features. Few would disagree. And this cost is already taken into account
in discu
The point is that there is an unavoidable cost to the developer when
features are added to the language. My apologies if that wasn't clear.
-Terence Bandoian
On 3/22/2018 11:20 AM, Michael J. Ryan wrote:
Nobody is wishing away anything with a linter. The linter can only
enforce a choice not
Nobody is wishing away anything with a linter. The linter can only enforce
a choice not to use a given language feature.
In any case, I feel this syntax is very valuable, fairly obvious in use,
and similar to use in other languages.
Pipeline/composition are important features, touched on by sev
That's very true. However, every new feature is an added cost to the
developer that can't be wished away with a linter.
-Terence Bandoian
On 3/20/2018 6:07 PM, Jordan Harband wrote:
Learning is a continuing requirement with or without new features in
the language; any one feature *not* added
Learning is a continuing requirement with or without new features in the
language; any one feature *not* added to the language tends to mean you'll
have to learn about more than one userland solution to that problem.
Obviously there's a cost to adding anything to the language - but there's a
cost t
When "features" are added to the language, developers have to learn
them. Either that or risk being relegated to second class status. That
means more time learning about and testing and sorting out support for
new features and less time actually developing an application. I like
the idea of "
I would probably structure this so differently that it's hard to even say
where the changes should be. I don't know the Electron API, so the
following is almost certainly wrong, but it should demonstrate the basic
ideas:
```
const promisify = require('some-promisify-function');
const BrowserWind
@michael, integration-level javascript rarely deals with blocking-code. its
mostly tedious-work debugging and “fixing” endless piles of async-io timeout
issues, without the help of a stack-trace :`( and the term “fixing” is
oftentimes euphemism for “rewriting the carefully architected backend
Straw man. The problem is variables named h, f and g, not the use of a
composition operator.
On Sun, 11 Mar 2018 at 07:37, kai zhu wrote:
> @peter, put yourself in the shoes of a senior-programmer responsible
> for overseeing an entire web-project. the project is @ the
> integration-stage and y
All good points :-) I wasn't suggesting there's no cost to adding syntax to
a language; I was suggesting that kai's blanket "please don't add new
syntax because I don't want to have to deal with it in my project" isn't a
useful objection on its own.
On Tue, Mar 13, 2018 at 7:59 AM, Mark Miller wr
On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband wrote:
> As someone who does wear the shoes of a senior programmer responsible
> (along with my team) for overseeing a very very large web project, the
> super trivial and easy answer to this is "use a linter" - eslint can be
> configured to restri
As someone who does wear the shoes of a senior programmer responsible
(along with my team) for overseeing a very very large web project, the
super trivial and easy answer to this is "use a linter" - eslint can be
configured to restrict any syntax you like, and since surely your CI
process is alread
In my opinion, one of the more significant advances in the C programming
language was the increase in the maximum length of identifiers. To me,
this translates to "less cryptic is better".
-Terence Bandoian
On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote:
Personally, I'd push my subordinates to
Personally, I'd push my subordinates to learn this new syntax. But if you
dislike it, you can blacklist it in your linter: it's one of the main
features of a linter.
On Mar 10, 2018 23:37, "kai zhu" wrote:
> @peter, put yourself in the shoes of a senior-programmer responsible
> for overseeing an
@peter, put yourself in the shoes of a senior-programmer responsible
for overseeing an entire web-project. the project is @ the
integration-stage and you're busy debugging an async
timeout/near-timeout bug preventing the frontend from talking to the
backend (which btw, is one of the most common in
Oh please,
This is an alternative syntax that's very useful for many people. If you
want too simplify syntax yourself you can use a linter to disable
alternatives.
On Mar 10, 2018 22:56, "kai zhu" wrote:
> my vote is for neither. exactly what industry painpoint or
> problem-space do either of
my vote is for neither. exactly what industry painpoint or
problem-space do either of these proposals solve?
rather, they compound an existing industry painpoint; where
ocd-programmers have problems in deciding-and-choosing which es6
style/design-pattern to employ and stick with before coding eve
Just thought I'd point out that the proposal itself entertains the
possibility of a corresponding composition proposal [1]. Also, in my
proposal, one of my "potential expansions" [2] would open a generic
door for "lifting" over a type, addressing the concern of
extensibility. (It's not ideal, and I
Although it doesn't allow composition with generator functions like the
composition proposal does, otherwise it's a pretty good solution.
My only concern with pipeline is that since it offers a different way of
calling functions than the `()` syntax, it can lead to mixed and hence
slightly more co
I'd like to point out the partial application operator:
https://github.com/tc39/proposal-partial-application
Sounds like the combination of pipeline + partial application would result
in what is essentially the same as function composition operator:
```
const h = ? |> f |> g;
```
Which results i
That could be a problem for readability.
I agree with the rest of what you said.
On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall
wrote:
> I don’t know the implications but I could easily imagine the pipeline
> proposal being extended to not taking any input on the left hand side and
> effectively r
I don’t know the implications but I could easily imagine the pipeline
proposal being extended to not taking any input on the left hand side and
effectively represent composition in the opposite direction.
For example:
```
let h = |> f |> g
h(2) //g(f(2))
```
That said, the point holds for the pro
The function composition operator composes function pipelines into
functions for later use and/or further composition. Those functions still
need to be called via the existing `()` syntax, so it doesn't offer a
different way of calling functions as such.
The function pipeline operator calls the fu
See also recent discussions in these GitHub issues that touch on composition:
https://github.com/tc39/proposal-pipeline-operator/issues?q=composition+sort%3Aupdated-desc.
Look particularly at the issues that were created after 2018-01-31 – when
Gilbert/Mindeavor split the proposal into four comp
How is either operator not "a different way of calling functions"?
On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla
wrote:
> I was just thinking about the relative merits and coexistence (or not) of
> function composition operator and function pipeline operator features:
>
> e.g.
> https://github.
25 matches
Mail list logo