4 ms·

For languages, which do not have built-in the power to change themselves, in many cases it might be better to stick to their feature set, instead of introducing

For languages, which do not have built-in the power to change themselves, in many cases it might be better to stick to their feature set, instead of introducing even more language concepts. Look at how much work is involved to get something as simple as pipelines. As if they will ever find the right syntax for everyone. If we used a normal function we might have to include a library or a dependency or heck, just take 5 minutes and write a pipeline function oneself. Sure, it will not be syntactically as minimal as a _change of the language itself_ to allow pipelining, but at least it will not introduce even more language features and everyone can easily look at the definition change it or include it in their own projects. Ideally we would strive for a minimalistic set of features, which in turn can implement anything we want. Adding more and more features, without introducing a way for the user to modify the language without a commitee and a lengthy process, seems short-sighted. If you want to give the user more power over syntax, introduce a well engineered macro mechanism (plenty of examples in other languages) and let people develop standards and libraries as macros and libraries. Later on decide what to take into the standard language. Similar to how jQuery influenced modern JS standard functions like querySelectorAll. Even if you don't take something into the standard language, users are still free to include it in their project. No harm done and everyone gets their lunch and can scratch their itches.

epolanski 4y ago
I understand the hassle around pipelines. Entire ecosystems like `fp-ts` or `effect-ts` are regularly used with pipeable APIs and no one beats an eye. The only thing that was needed was a syntax that would've allowed this: pipe( "foo ", capitalize, // "FOO " trim, "FOO" shout, "FOO!" console.log, undefined ) to not require `pipe`. "foo " |> capitalize |> trim |> shout |> console.log Why `pipe`? Because otherwise you need to write it like that: `console.log(shout(trim(capitalize("foo"))))` which is unnatural as you need to read the chain in reverse order and is especially hard in less trivial cases than a sequential string manipulation.

epolanski 4y ago

I understand the hassle around pipelines. Entire ecosystems like `fp-ts` or `effect-ts` are regularly used with pipeable APIs and no one beats an eye. The only thing that was needed was a syntax that would've allowed this: pipe( "foo ", capitalize, // "FOO " trim, "FOO" shout, "FOO!" console.log, undefined ) to not require `pipe`. "foo " |> capitalize |> trim |> shout |> console.log Why `pipe`? Because otherwise you need to write it like that: `console.log(shout(trim(capitalize("foo"))))` which is unnatural as you need to read the chain in reverse order and is especially hard in less trivial cases than a sequential string manipulation.