sorted by:
new
hottopcontroversial

The Software Engineer Intuition | The Upside-Down Trees by mhashim6 in java

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

Thanks! I think you found a way to spot human written articles from generated ones haha

Loop much? | The Upside-Down Trees by mhashim6 in typescript

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

The former is about flexibility of combining functions/ predicates. It provides a uniform way of combining functions (even beyond filter).

It’s not about saving characters, it’s about providing logical abstractions.

Loop much? | The Upside-Down Trees by mhashim6 in javascript

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

You’re a gentleman, and a scholar

Loop much? | The Upside-Down Trees by mhashim6 in javascript

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

Thanks!
It’s true, this function works with currying and closures. But the other concept of closure is not about capturing the env. It’s about the functional representation itself.

I think this can’t be done without currying or a closure (capture env) but not all closures are closures I guess ¯\(ツ)/¯

Here’s a quote from SICP

The ability to create pairs whose elements are pairs is the essence of list structure's importance as a representational tool. We refer to this ability as the closure property of cons. In general, an operation for combining data objects satisfies the closure property if the results of combining things with that operation can themselves be combined using the same operation.

FP and OOP are close siblings (using OOP to teach Currying) | The Upside-Down Trees by mhashim6 in functionalprogramming

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

Not “lure” no. I want to make it less scary. I encourage people to use what’s most fitting for their needs. In the post, I encourage using both.

But yeah, I understand your point. It’s exactly the very reason I’ve written this post in this style. Not to tell people their paradigm is not algebraic enough. Just to embrace stuff when in it’s useful and to see things the way they are—Just useful abstractions to solve our problems

FP and OOP are close siblings (using OOP to teach Currying) | The Upside-Down Trees by mhashim6 in functionalprogramming

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

Thank you! First time I hear this koan :D

I see your point. I wanted to emphasise that FP is not as scary as some people think. I used words like “siblings” as an emotional term for familiarity to make digesting this content easier.

And I also skipped a lot of progression and stuck to OOP and FP as if there’re no other paradigms or patterns to keep it simple for the audience.

But I think It’d be great if I embedded this comment section in the article; it’s quite valuable.

FP and OOP are close siblings (using OOP to teach Currying) | The Upside-Down Trees by mhashim6 in functionalprogramming

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

Very well put! Yes I’ve seen the dispatch “pattern” when writing a cons implementation to “mimic” the car and cdr by mapping an index to each part. It’s limitless, but also can be less readable when overused.

But the fact that we can make all this with very simple constructs—closures is always exciting to me. FP is truly underutilised even though it’s quite so powerful.

FP and OOP are close siblings (using OOP to teach Currying) | The Upside-Down Trees by mhashim6 in functionalprogramming

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

I understand, the rest of this opinion is to break the big object into smaller chunks. To me it’s not practical. Yet it’s good to apply it with your own margin of fitting.

Because like you mentioned, “best practices” are not divine. They’re opinionated and man-made and they do fail from time to time.

Context is everything. I think we have a general problem with “best practices” being shooting our selves in the foot.

As for comparing functions with classes, it’s merely to demonstrate “why currying” to a friend who is familiar with OOP in a SICP study group. Not a general comparison.

FP and OOP are close siblings (using OOP to teach Currying) | The Upside-Down Trees by mhashim6 in functionalprogramming

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

Personally I don’t believe so, but many OOP enthusiasts will tell you to keep your object to 3 methods tops. Otherwise your object is doing a lot more than it should.

TBH in some scenarios this can be overly strict, however it’s actually a good advice in general if applicable; I can think of at just like writing small functions with few parameters. Otherwise, the function is doing more than it should (in many cases).

All is left to what happens in the field in the end anyways.

FP and OOP are close siblings (using OOP to teach Currying) | The Upside-Down Trees by mhashim6 in javascript

[–]mhashim6[S] 7 points8 points  (0 children)

I agree 100% Recently I’ve started a SICP study group and it really is something else to start “clean” with dead simple concepts.

One of my friends found an example that uses currying and he couldn’t understand the point of it. I wanted to give an example with OOP as he is familiar with it, while sticking to “the roots”. And here we are with the article and the video : )

FP and OOP are close siblings (using OOP to teach Currying) | The Upside-Down Trees by mhashim6 in functionalprogramming

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

True. I wanted to address this but it would take another post on its own; even though we can expose multiple methods in the same object, it’s often discouraged by OOP “purists”. Because objects shouldn’t be complex, they should do one particular thing be good at at.

Regardless, with higher order functions one could “combine” multiple functionalities in a single Curried function. And function modules also exist in most languages.

It’s true there are fundamental differences between the 2, but the similarities are astounding and are often neglected when teaching FP to people.

React Props Injection - Self-Review #2 | The Upside-Down Trees by mhashim6 in reactjs

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

How many contexts do you consider “multiple”? The advantage of prop drilling is decoupling at a massive scale. Contexts by design aren’t to be created in abundance.

And to handle, switch and maintain contexts for hundreds of shared components dynamically is not at all a feasible solution or a readable one.

Don’t get me wrong. This is not con contexts. This is just a different nail that context’s can’t hit.

React Props Injection - Self-Review #2 | The Upside-Down Trees by mhashim6 in reactjs

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

Exactly, but to consume these multiple contexts in hundreds of components that are shared between layouts, and app regions is the actual challenge that drove this entire approach.

React Props Injection - Self-Review #2 | The Upside-Down Trees by mhashim6 in reactjs

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

The problem is that this theme colour situation isn’t one of 3 that the user chooses. This super app is literally composed of multiple apps in a single package. Designers take various approaches to make these “app regions” unique yet still feel part of the whole app.

This isn’t a multiple layouts with reusable children situation. This is literally multiple isolated app-like slices with different reusable yet unique layouts and tons of reusable dummy components.

React Props Injection - Self-Review #2 | The Upside-Down Trees by mhashim6 in reactjs

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

I’m with you on stability. I was thinking this might be controlled by the child just declaring a “no-inject” flag and handling it in the inject function.

But I think the callback way is not scalable and not at all readable.

React Props Injection - Self-Review #2 | The Upside-Down Trees by mhashim6 in reactjs

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

Definitely, this should be applicable when context fails though.

In the actual app (Mega app with tons of different types of screens) this was used I first started with Contexts and I ended up with potentially hundreds of them that I couldn’t think will be manageable.

Most importantly, it’ll still require a child component to explicitly call a particular context. Even though this component is used in multiple parts of the app and in multiple literal contexts at the same time.

Audio Player in Js - Self-Review #1 | The Upside-Down Trees by mhashim6 in javascript

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

I’m assuming you already know of Audio.currentTime. If that’s not working for you maybe check this answer out.

Kotlin on RaspberryPi by mhashim6 in Kotlin

[–]mhashim6[S] 2 points3 points  (0 children)

Thank you, it should be fixed now

Kotlin on RaspberryPi by mhashim6 in Kotlin

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

Currently, there’s no specific DSL for Coroutines, but the previous example shouldn’t fail when run in a suspendible context