this post was submitted on 21 Mar 2024
293 points (94.8% liked)

Programmer Humor

19161 readers
321 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
293
Functional bros be like (lemmy.world)
submitted 5 months ago by ZILtoid1991@lemmy.world to c/programmer_humor@programming.dev
62 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] frezik@midwest.social 1 points 5 months ago (1 children)

In all those cases, the answer is to swap in a new variable and throw the old one away.

[–] RageAgainstTheRich@lemmy.world 1 points 5 months ago (1 children)

Legit question because i think I'm misunderstanding. But if its a const, how are you able to swap or replace it?

[–] frezik@midwest.social 5 points 5 months ago (2 children)

It's only a const within a function. You can pass the value to another function and changing it as it's passed. For example:

const int foo = 1
other_func( foo + 1)

In functional programming, you tend to keep track of state on the stack like this.

[–] RageAgainstTheRich@lemmy.world 1 points 5 months ago

Aaah okay i get it now :) that makes a lot more sense.

[–] madcaesar@lemmy.world 1 points 5 months ago (1 children)

What is the advantage of this VS just overwriting the var?

[–] frezik@midwest.social 7 points 5 months ago (1 children)

Keeping state managed. The data for the function will be very predictable. This is especially important when it comes to multithreading. You can't have a race condition where two things update the same data when they never update it that way at all.

[–] madcaesar@lemmy.world 1 points 5 months ago (1 children)

Hm I'm having trouble visualizing this do you know a quick little example to illustrate this?

[–] frezik@midwest.social 1 points 5 months ago (1 children)

Rather than me coming up with an elaborate and contrived example, I suggest giving a language like Elixir a try. It tends to force you into thinking in terms of immutability. Bit of a learning curve if you're not used to it, but it just takes practice.

[–] madcaesar@lemmy.world 1 points 5 months ago (1 children)

Ok how about this then, I frequently do something like this:

let className = 'btn'
  if (displayType) {
    className += ` ${displayType}`
  }
  if (size) {
    className += ` ${size}`
  }
  if (bordered) {
    className += ' border'
  }
  if (classNameProp) {
    className += ` ${classNameProp}`
  }

How would this be made better with a functional approach? And would be more legible, better in anyway?

[–] frezik@midwest.social 1 points 5 months ago* (last edited 5 months ago) (1 children)

I'd say this example doesn't fully show off what immutable data can do--it tends to help as things scale up to much larger code--but here's how I might do it in JS.

function generate_class_name( display_type, size, bordered, class_name_prop ) 
{
  classes = [
      'btn',
      ( display_type ? display_type : [] ),
      ( size ? size : [] ),
      ( bordered ? bordered : [] ),
      ( class_name_prop ? class_name_prop : [] ),
  ];

  return classes.flat().join( " " );
}

console.log( "<"
    + generate_class_name( "mobile", "big", null, null )
    + ">" );
console.log( "<"
    + generate_class_name( "desktop", "small", "solid", "my-class" ) 
    + ">" );
console.log( "<"
    + generate_class_name( null, "medium", null, null ) 
    + ">" );

Results:

<btn mobile big>
<btn desktop small solid my-class>
<btn medium>

Notice that JavaScript has a bit of the immutability idea built in here. The Array.flat() returns a new array with flattened elements. That means we can chain the call to Array.join( " " ). The classes array is never modified, and we could keep using it as it was. Unfortunately, JavaScript doesn't always do that; push() and pop() modify the array in place.

This particular example would show off its power a little more if there wasn't that initial btn class always there. Then you would end up with a leading space in your example, but handling it as an array this way avoids the problem.

[–] madcaesar@lemmy.world 2 points 5 months ago

Very interesting. Actually the part you mention about there being an initial 'btn' class is a good point. Using arrays and joining would be nice for that. I wish more people would chime in. Because between our two examples, I think mine is more readable. But yours would probably scale better. I also wonder about the performance implications of creating arrays. But that might be negligible.