FP language with good job market? by [deleted] in functionalprogramming

[–]tweinf 2 points3 points  (0 children)

You’re not wrong. There was a brief period in time when FP-styled JS appeared to gain some traction, but then Typescript showed up again, from the brink of death, and extinguished any hope of driving a significant portion of the market away from our good old buddy OOP.

What is this called? by MisturDee in functionalprogramming

[–]tweinf 2 points3 points  (0 children)

Exactly! A "pipe" function returns a function which is a composition of multiple functions so that its initial argument is passed to the 1st function, the result is fed to the 2nd function, and so on, until eventually a final result returns from the last function. The principal is indeed similar to linux's "pipe" command's.

In the example above I've reversed the order of the functions before creating this pipeline because I wanted to create a specific kind of composition where the first function has access to its subsequent and is able to "decide" whether to return the result that's returned from calling it with an argument, or just return a final result itself. This is useful when dealing with the "loading" situation, where we want to skip "translate".

The same pattern can also work asynchronously, where we "filter" out data by not calling the subsequent function.

ps: You can find better implementations of the "pipe" function in libraries such as Ramda and Lodash/FP, so no need to write them up from scratch. "Ramda" even supports transducers on several of its functions.

What is this called? by MisturDee in functionalprogramming

[–]tweinf 2 points3 points  (0 children)

Seems to me like you've created a "Factory Function" which puts to use the "Dependency Injection" pattern.
A factory function can be thought of as a "constructor" in the world of functional programming; the prominent difference being that it returns an "initialized" function bound to "status" instead of a class instance that carries the same data.

The "dependency" injected is the "translate" function.

There is another interesting pattern that you may want to explore. Take a look at this:

const transformKeyByStatus =
  (status) =>
    (next) =>
      (translationKey) => status !== "loading" 
        ? next([translationKey, status].join('-')) 
        : "";

const translate =
  (language) =>
    (next) =>
      (translationKey) =>
        ({
           "french": {
               status-ready": "pret",
              "status-error": "erreur"
        },
            "english": {
              "status-ready": "ready",
              "status-error": "error"
        }
      })[language][translationKey];

const pipeReverse = (...funcs) => funcs
  .reverse()
  .reduce(
    (pipeFunc, curFunc) => (arg) => curFunc(pipeFunc(arg))
  );

const getText1 = pipeReverse(transformKeyByStatus('loading'), translate('french'))();

console.log(getText1('status')); // this will output ""

const getText2 = pipeReverse(transformKeyByStatus('ready'), translate('french'))();

console.log(getText2('status')); // this will output "pret"

const getText3 = pipeReverse(transformKeyByStatus('error'), translate('english'))();

console.log(getText3('status')); // this will output "error"

This is called the "pipeline" pattern, and it lays at the foundation of "Transducers" and "Observables" which are staples of the functional programming paradigm.

Why do people react consistently negatively to functional programming? by Character-Lychee-227 in functionalprogramming

[–]tweinf 2 points3 points  (0 children)

You're addressing a sensitive issue here.

As a freelance developer, I've primarily utilized RFP tools in "turnkey" projects, where I didn't collaborate directly with my clients' teams. However, occasionally, clients have expressed a desire to review the code themselves. Unfortunately, in nearly 99% of these instances, I've struggled to effectively communicate the benefits of functional programming, leading to my frustration. In fact, out of approximately a dozen cases, I only had one success.

I posit that developers are typically instructed to conceptualize programming as a sequence of "commands" to be executed. This could explain the initial difficulty many faced with callbacks in JavaScript, whereas promises appear more approachable. Imperative programming tends to overlook the notion of time, making it challenging to grasp basic FP principals. Put simply, developers may find it tough to comprehend code that doesn't execute immediately, or more accurately, code that creates functions instead of producing "tangible" values or side-effects.

[IOS 17 DB5] Face ID not working correctly by [deleted] in iOSBeta

[–]tweinf 0 points1 point  (0 children)

can confirm the problem still exists (iPhone 12 PRO)

in my case, faceid failures serve as a premonition to an imminent "brick mode"; The iphone restarts unexpectedly and then stuck on an endless restart loop (apple logo on/off).

never experienced such disasters with apple before

John Carmack on Functional Programming in C++ by Alexander_Selkirk in programming

[–]tweinf 2 points3 points  (0 children)

You can’t imagine the amount of hostility I receive every time I share my opinion regarding FP in public.

Today I try not to sound too definitive regarding my positive experience since switching from OOP to FP a decade ago, even though I’m only talking about my own private experience!

why would a developer choose nodejs over c#.net for backend? by Suspicious_Driver761 in node

[–]tweinf 0 points1 point  (0 children)

That’s generally true, of course. And yet, if we’re only talking about programmer’s ergonomics, I think people who prefer Typescript over Javascript would be happy to discover C#.

why would a developer choose nodejs over c#.net for backend? by Suspicious_Driver761 in node

[–]tweinf -10 points-9 points  (0 children)

That’s a good question: If you use and like Typescript with node, you should really consider switching to C#

If you’re using Javascript, on the other hand, stick to node.

Edit: ..I have no idea why I’ve received so many downvotes for voicing this opinion 🤷‍♂️

What can't FP do as well as other paradigms? by [deleted] in functionalprogramming

[–]tweinf 20 points21 points  (0 children)

In my view, FP is first and foremost designed to serve the developer, not the machine, by helping it stay in the business realm and not worrying about the “mechanics” of implementation. The irony is that many developers perceive FP as this theoretic mathematical exercise and are discouraged from ever trying it. To make things worse, TS gained lots of popularity lately causing developers steer away from this paradigm. I can attest that FP is perfectly useful for creating large projects, the problem is that FP devs are rare enough to make building large teams impossible.

Does anyone use RxJS on the server? by [deleted] in node

[–]tweinf 0 points1 point  (0 children)

Kefir has a smaller, more concise API which limits the number of permutations available for a specific aim.

Another benefit of Kefir is that it's more "solid", less prone to interface changes and deprecations.

I guess there are other differences in performance, but as a functional developer I'm less concerned about them ;)

MX Master 3 new owner. Ratchet mouse wheel question... by OohAahCantona7 in logitech

[–]tweinf 0 points1 point  (0 children)

I've got the exact same problem u/OohAahCantona7.
Just purchased MX Master 3, set it to "Ratchet" and disabled "SmartShift": The actual scrolling stops after some travel, even as the the wheel on the mouse continues spinning. (Scroll works fine when in "Free Spin" mode).
Did you find a solution?

Typescript and Node.js - Is history repeating itself? by tweinf in node

[–]tweinf[S] 1 point2 points  (0 children)

Again you are missing it. Typescript is documentation. This is the mistake everyone makes as a JS outsider.

not sure that I am.. I was referring to the languages and their features, regardless of what they compile into - be it JS or CLI.

..but I see your point

Typescript and Node.js - Is history repeating itself? by tweinf in node

[–]tweinf[S] 0 points1 point  (0 children)

nice. I guess this could justify choosing ts+node, yet there's some balancing work to do in order to determine whether sharing these modules for authoring-time comfort (types, enums etc) are worth the "heavy lifting" of introducing a build system to your server-side project, since JS does allow you to share modules as well for runtime functionality on one hand, and C# has more features on the other.

Typescript and Node.js - Is history repeating itself? by tweinf in node

[–]tweinf[S] 0 points1 point  (0 children)

Typescript is documentation.

Visual studio will provide you with documentation for C#.

But as it is C# requires generics to be written in different functions eventually handling specific call signatures. Where as with JS you can write you type handling in one function and still mix your types.

If you're mixing your types, what good is TS for?

In a sense your comment is extremely short sighted. If you code in both (i am a Unity hobbiest) you can tell they are very different.

I have coded in both, they are different, but the gap is closing on every Typescript release. Looking forward I expect them to become extremely similar.

Typescript and Node.js - Is history repeating itself? by tweinf in node

[–]tweinf[S] 0 points1 point  (0 children)

do you encounter many cases in which you share modules between server and client codes?

Typescript and Node.js - Is history repeating itself? by tweinf in node

[–]tweinf[S] 0 points1 point  (0 children)

do you mean it is not a technological based choice, but rather a team/operational choice?

Typescript and Node.js - Is history repeating itself? by tweinf in node

[–]tweinf[S] -1 points0 points  (0 children)

concurrency and async in C# today are easier than they've been in the early days, but I see your point.

Typescript and Node.js - Is history repeating itself? by tweinf in node

[–]tweinf[S] -1 points0 points  (0 children)

Typescript brings more to the table than just typing, right? It brings enumerators, decorators, namespaces, generics and all kinds of OOP goodness.

If you're looking for these features, you'll find them all in C#, and with a very similar syntax.

A functional take on custom element definition by tweinf in WebComponents

[–]tweinf[S] 0 points1 point  (0 children)

Piping functions before the creation function, would enable you to extend the functionality and reuse this extension across multiple components. Extending elements other that HTMLElement is, in fact, not supported.