Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Application-as-a-Function Thinking

doridori.github.io

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Application-as-a-Function Thinking

#71

Post by the_gipsy »

woojoo666 wrote: post #62
the_gipsy wrote: post #22

Earlier quoted context omitted.

"in context", what does this mean?

Not GP but I can try to explain. React tries to be as functional as possible, but components are still often stateful. For example, an accordian component [1] could have a `collapsed` boolean state. This `collapsed` state makes sense within the context of the accordian component. Now imagine if you tried to move the state out of all your components into a single location, so that your components can be stateless func…

Ah, got it, thanks!

IMHO, Component style (React) and State style (Elm) can be interpreted as two styles of isolating (or decoupling), just very orthogonal to each other. Isolating is a very basic necessity for keeping complexity at bay.

Component style isolation works really well for "inner UI state", like your accordion example. But it quickly gets out of hand once you get to some non-UI state that is shared between a bigger component hierarchy.

State/View/Message isolation works really well for actually keeping the views pure and having only one change-message channel. But the state model quickly (and message handler) quickly gets huge. You also cannot publish/provide a small "component" with local state.

Re: Application-as-a-Function Thinking

#72

Post by kodroid »

brap wrote: post #61
kodroid wrote: post #56

Earlier quoted context omitted.

Great thanks. > For me the difficult part was where the side effects fit in and how they're processed, what you call "commands" and "command handler" Do you mean difficult for you when designing, or difficult to understand in my post?

I meant for me, but also in the article I felt like there should be a bit more on that.

Thanks. Others have said similar, but more of a request for an additional post expanding on that aspect. Until then, there is a little more information in a previous related post https://doridori.github.io/Android-Architecture-Runtime/

Re: Application-as-a-Function Thinking

#73

Post by WJW »

mpweiher wrote: post #53
WJW wrote: post #45

Earlier quoted context omitted.

Well of course, more complex applications are going to have more complex state. Rails does a lot more than most web frameworks, so it has a lot of extra state to keep track of. This doesn't make it any less a function, it's now just a function that takes in the internal state (including the db contents) as an input. That's exactly what the article describes.

That's exactly my point. Sure, it is possible to model these things as functions, for example by "passing" the entire world as a "parameter". However, it is an extremely contrived modelling, basically you're hammering the square problem domain into the round function hole with the biggest hammer you can find until it "fits". It is also possible to model these things as Turing machines, or NAND gates...

The "app-as-function" is not at all contrived though, it has some very concrete applications that make use of the composability advantages that functions have. The [rack-test](https://github.com/rack/rack-test) gem (and similar languages) work exactly like this: they run the "app" part without the "web server" part to enable much easier testing. Rack middlewares similarly treat the enclosed app as just a function taking some specified input and returning some output value.

Re: Application-as-a-Function Thinking

#74

Post by carapace »

mpweiher wrote: post #64
carapace wrote: post #49

Earlier quoted context omitted.

> How many applications that you use on a daily basis work as follows... Most of them, but then I use the CLI a lot. E.g.: find | grep | xargs foo Where "foo" is (of course) a kind of meta-parameter, both a parameter itself and a function/application. - - - - How do you mean, ALGOL isn't a general purpose language?

1. The shell is not calling functions, it is composing filters via I/O. Superficially similar, but actually quite different. (And how it makes it superficially look like function application is also quite interesting, IMHO). 2. But yes, programs that act like functions definitely do exist. They even used to be in the majority. 3. ALGOL stands for ALGOrithmic Language. It's a DSL for the domain of algorithms. As are v…

In re: #1 that's the kind of discussion I could have all day. (If you take the state of the machine including the filesystem, then almost all non-networked programs could be treated as pure functions, eh?)

#2 so how does that modify your original comment, if at all?

#3 What would you contrast our mainstream so-called "general purpose" languages with?

Re: Application-as-a-Function Thinking

#75

Post by kodroid »

monocularvision wrote: post #69

Love this, thanks for sharing. This is fundamentally how our iOS application is modeled. We were highly inspired by Bernhardt’s talk and the Elm Architecture. It has lead to a very modular and maintainable app that has been very easy to test without ridiculous mocking you usually see when needing to interact with object-oriented / imperative frameworks like Cocoa Touch.

Great, thanks for sharing also and your experience makes total sense.

With this approach: 1. What downsides have you encountered? 2. How easy do you find it to onboard people? 3. Does Android do the same at your place?

Re: Application-as-a-Function Thinking

#77

Post by kodroid »

_dain_ wrote: post #63
kodroid wrote: post #60

Earlier quoted context omitted.

Hey, I can't say I have ever worked on such a project, it sounds like an interesting problem space. I am assuming when a user interacts with one control button / dial / interaction it has a cascade effect on other controls / displays etc? I am also assuming you already need to have a data structure representing the complete state of the system no? There are multiple interesting aspects here, like are you / do you nee…

>I am assuming when a user interacts with one control button / dial / interaction it has a cascade effect on other controls / displays etc? Sometimes yes, it depends on the instrument. Some have user interaction, but most don't and are just controlled by the software I write. When I said "knobs" I didn't mean literal knobs, just all the different things these gizmos can do .. they come with thousand-page manuals. OTO…

Ha, I love that you mind went to that final analogy.

I think you have correctly identified the important difference between the kind of applications I have been writing (mobile applications, which are relatively small and often have a good chunk of both side-effectful code and biz logic) and what your doing, which does not sound like it would have much to gain by spitting into a core & shell.

I have not much to offer you, having not worked on code such as you describe.

Re: Application-as-a-Function Thinking

#78

Post by monocularvision »

kodroid wrote: post #75
monocularvision wrote: post #69

Love this, thanks for sharing. This is fundamentally how our iOS application is modeled. We were highly inspired by Bernhardt’s talk and the Elm Architecture. It has lead to a very modular and maintainable app that has been very easy to test without ridiculous mocking you usually see when needing to interact with object-oriented / imperative frameworks like Cocoa Touch.

Great, thanks for sharing also and your experience makes total sense. With this approach: 1. What downsides have you encountered? 2. How easy do you find it to onboard people? 3. Does Android do the same at your place?

1. I can’t say I have found any real downsides yet. We have had to make improvements to support new capabilities, but it has been surprisingly easy to do so. Our most recent improvement was to formalize the concept of MVVM so that our ViewModels essentially acted in the same way as our Feature types. It allows us to continue using almost the same pattern at individual screen that we have been using at the feature level.

Our next big effort will be fitting the architecture into SwiftUI, which I think will actually be also straightforward since SwiftUI is extremely functional.

2. Onboarding is probably the biggest “downside”. I would say there is absolutely a learning curve that requires some investment but everyone I speak to about it has been pretty positive after getting over that hurdle. And it feels like our productivity is very high.

3. Android does not follow the same pattern. I am planning on sharing your article with the team though. :-)

Re: Application-as-a-Function Thinking

#79

Post by kodroid »

monocularvision wrote: post #78
kodroid wrote: post #75

Earlier quoted context omitted.

Great, thanks for sharing also and your experience makes total sense. With this approach: 1. What downsides have you encountered? 2. How easy do you find it to onboard people? 3. Does Android do the same at your place?

1. I can’t say I have found any real downsides yet. We have had to make improvements to support new capabilities, but it has been surprisingly easy to do so. Our most recent improvement was to formalize the concept of MVVM so that our ViewModels essentially acted in the same way as our Feature types. It allows us to continue using almost the same pattern at individual screen that we have been using at the feature lev…

Thanks. I love to see a description of that formalisation, if you ever get round to publishing it.

Re: Application-as-a-Function Thinking

#80

Post by monocularvision »

kodroid wrote: post #79
monocularvision wrote: post #78

Earlier quoted context omitted.

1. I can’t say I have found any real downsides yet. We have had to make improvements to support new capabilities, but it has been surprisingly easy to do so. Our most recent improvement was to formalize the concept of MVVM so that our ViewModels essentially acted in the same way as our Feature types. It allows us to continue using almost the same pattern at individual screen that we have been using at the feature lev…

Thanks. I love to see a description of that formalisation, if you ever get round to publishing it.

It’s really as simple as this:

1. Create a struct (value type in Swift) that implements a protocol (interface) to serve as your ViewModel 2. The main methods to implement are both called “update”. One is called automatically by our infrastructure when Feature state (state that exists across screens) changes. The other is called by the developer in their view controllers to pass along user actions (or other UIKit events). 3. The developer subscribed to all VM changes and updates the view in response. This subscription is done via Combine which is Apple’s FRP framework.

I am planning on writing more about this and the rest of our architecture in the future, hopefully.

Post reply on HN