HN Theater @HNTheaterMonth

I haven't worked with Qt so I don't know how the API looks,

But on a complex app, to see "dirty bitflags", "intermediate values", "redrew the UI in the middle of mutating document state", I feel what you feel, and I want to share what helps me and my team overcome this kind of complexity.

This happened a few years ago to my team. We alleviated this with several solutions. The most effective solutions is to 1.) separate UI logic/compositive component from UI visual/appearance component, 2.) separate UI component from actors.

1.) Separating logic from visual helps developers define problems separately, especially those around the required states, step-functions, and lifecycle. We made this separation because of three things: 1.) We observed that our programmers are simply divided into these two categories, 2.) The dependencies of these two sets of components are simply different (e.g. logic --depends-on-> actors and ownership/lifetime management modules, while visuals depends on DOM, rendering, setting up callbacks), 3.) It is actually good to have a high cohesion between UI and logic modules. You may want to use the same UI for a slightly different logic, and vice versa.

2.) Separating UI component from actors helps a lot with decoupling state changes and re-rendering, and actually gives developer a chance to separate/abstract/generalize concerns when things have gotten too complex to be written in a UI component.

Actors is what I call any kinds of data that can act, have their own agency. It can be what you call a service, worker. It can have a Timer-based or queue-based internal lifecycle-management that does not require interaction from user (very useful for things like updating background data at interval)

UI component can both "own" or "borrow" actors. "owned" actors dies when its parent component is destroyed, while "borrowed" actors does not die when its borrowing component is destroyed.

We decouple actors from UI component and set up bridge between them. UI component can signal actors by function call, and actors can get back to the UI component by using either a return value or event/callback system.

And the last but not least, writing app in a smartly typed language combined with functional domain modelling helps a lot (see about it here https://www.youtube.com/watch?v=Up7LcbGZFuo).

⬐ phibz

You're probably going to seriously confuse someone familiar with the "actor pattern". Look it up.

⬐ valand

I realize that I probably contribute in overloading the term actor.

This "thing" is partially influenced by actor pattern. The other influences are entity component system and Alan Kay's original of OOP.

⬐ nyanpasu64

Sorry, I don't understand what you're getting at. When timers or user actions are triggered, what code runs, where is the state it modifies located (next to the specific timer/action, within a module or dialog's object, or globally), how does the function determine which parts of the UI to reload from state, and when does it reload the UI? (Is this explained in the video or not? I haven't watched it yet.)

⬐ valand

About the video, I should have made it clear that the video only talks about functional domain modelling.

Before we got into where state should be and when is UI reload/rerender triggered. I'm going to tell you a little imaginary problem.

Imagine you are building an application for downloading several huge files.

1.) This app must have a download page to trigger the downloading of various files as well as monitor their statuses.

2.) a system to manage multiple downloads. It can queue multiple downloads but only one should run at a time. But, regardless of the download page is open or not, the downloader should run its download.

3.) a persistent notification system for the app to notify the user (e.g. if a download succeeded or failed). This notification should be persisting, meaning that if the user does not dismiss a notification, it will stay there. The UI for the notification system looks like a smart phone's one.

4.) There are several other pages in the app.

Before we got into asking where state should be placed, we should examine what actors are there. There are the "downloader", the "download page", the "notification system", the "notification UI".

Because we have these several actors, we need to assume that all of these have several local states. All of these actors need to be in the component tree, but not necessarily bound to the rendering lifecycle.

The dependency arrows look like this:

- "download page"=>"downloader"=>"notification system" - "notification UI" => "notification system"

These dependency arrows form the component tree automatically. Now, let's examine the solution:

- The state that tracks the notification should be in the notification system. The user-facing message in a notification item should be a copy that is put into the memory of the notification system.

- The state that tracks the queue of multiple downloads and the function that schedule the downloads should live in the downloader. These scheduler will have its own timer-like mechanism to notify itself that it needs to run other task if one is finished.

- The download page "listens" to events and "borrows" data from the "downloader". So if the downloader makes a change, the downloader page will change too.

- Last, the notification UI. The notification UI lives longer than the download page, because the user can switch between page but the notification UI stays on. The notification UI listens to the notification system for changes in its state and borrows its state.

- If you pay attention to the dependency arrow, notification UI and and download page both are the descendant of the notification system, but only notification UI react to "change-signal" from the notification system. Download page should not react to any signal from notification UI (e.g. no rerender).

- This is an indicator that the notification system must not be bound into the re-render lifecycle of the tree of components. Notification UI should explicitly subscribe to the notification system in order to allow other page to ignore the notification system. In JavaScript/TypeScript it is pretty easy to implement a callback-based event emitter that can be attached/detached.

- The notification system and the downloader is what I call an actor that can, but not always, be bound into the render lifecycle. It lives with the component that spawns and destroy it, but is detached from it.

Take something like the design discipline Scott Wlaschin describes in this talk "Domain Modeling Made Functional"[1]. Combine it with a catalog of standard models like David Hay's "Data Model Patterns: A Metadata Map"[2] which is like a Pattern Language for data models combined with a catalog covering most (enterprise) needs. Specify the binary formats with Erlang "bit syntax"[3]. Eh?

[1] https://www.youtube.com/watch?v=Up7LcbGZFuo

[2] https://www.sciencedirect.com/book/9780120887989/data-model-...

[3] http://erlang.org/doc/programming_examples/bit_syntax.html

In re: Haskell's goodness or badness, compare and contrast with, say, PHP (crap language with wild success.) Or Prolog (a stately Elven language with deep but obscure success.) Haskell is what it is.

In re: types and data, FP is good for that. See e.g. "Domain Modeling Made Functional" by Scott Wlaschin ( https://www.youtube.com/watch?v=Up7LcbGZFuo ) it's about F# but the concepts apply cross-language.

In re: FP PLs "done right" I submit Elm lang. I've been using Elm recently and it gets the job done. It's weird though: on the one hand, as a experienced professional it feels like a toy. The error messages feel almost insulting, like I'm being patronized. On the other hand, once I got over that (silly) reaction, they're awesome. Changing code is a breeze, because Elm leverages the crap out of the type system, and the structure of the code and runtime prevent whole vast categories of errors.

Combine that with the sort of Domain-Driven development that Wlaschin is talking about and "baby, you got a stew going!"

⬐ KurtMueller

I was introduced to OCaml through Elm - a deeply-opinionated language with strict guard rails. In Elm, there is either a happy path or there is no path. As a newcomer, you're not overwhelmed or paralyzed with a plethora of choices on how to get things done simply because Elm limits your choices. Each tool in your toolbox is documented with simple examples how to use that tool.

After finally jumping the fence and exploring/devving with other OCaml languages (specifically F#), I still come back to Elm to see how it and the community does things: namely their best practices and explanation of fp concepts.

I like this talk: "Domain Modeling Made Functional" by Scott Wlaschin https://www.youtube.com/watch?v=Up7LcbGZFuo He's working in F# but the concepts map.

There's a fascinating book "Data Model Patterns: A Metadata Map" by David C. Hay that's pretty much a Pattern Language or catalog for data models. You can just implement the subset of Hay's patterns that make sense for your application.

Not CT (IIRC) but see also "Domain Modeling Made Functional" - Scott Wlaschin

https://www.youtube.com/watch?v=Up7LcbGZFuo

Yep! This talk captures it pretty darn well: https://www.youtube.com/watch?v=Up7LcbGZFuo

Besides that, the compiler becomes a partner in coding. - Refactoring things is no longer something I avoid, because the compiler will point out any unexpected places that interact with a given piece of code. - I can code for an hour without loading the app, and be reasonably certain that the code I'm writing will be more or less be correct. Overall, I feel like the compiler does the double-checking and second-guessing that I was always doing in the back of my head, which gives some peace of mind and frees me up to focus on the actual task.

⬐ donut2d

Yeah! I'll code for days without running the app. In OCaml, it's as you say, mostly correct when I actually get around to running it. With PHP/JS, I still have a lot of work ahead of me. With OCaml I feel like I'm thinking much more about the problem and less about the language I'm using.

Scott Wlaschin, author of F# for Fun and Profit, has an excellent talk on using F# (an ML language) for domain driven design and business development:

https://www.youtube.com/watch?v=Up7LcbGZFuo

If anyone is looking for a really eye-opening video take a look at that this. "Domain Modeling Made Functional"

It's applying Functional Programming to plain old Enterprise line of business apps in F#. The author argues why it's so much simpler, and simply walks through an example with cases. It's hard not to be persuaded. It leaves behind all of the lofty crazy maths you see in a lot of presentations of FP, and just shows how it's a simpler technique to solve real world problems.

Domain Modeling Made Functional - https://www.youtube.com/watch?v=Up7LcbGZFuo&feature=youtu.be... (Watch on 1.25x speed)

It's really impressive, and also surprising why more people promoting FP don't show it's tangible benefits and simplicity vs. the theoretical/abstract way it's usually presented.

It's also a great introduction to 'Domain Driven Design' and data modeling regardless of the language you use.

⬐ mettamage

After watching it for 20 minutes, I want to know more.

Where can I learn more about this magic called functional programming? Is there a good course? I want to do it for BLOBAs (as he calls them) apps as I'm not too math-heavy.

Also, to what extent does JS support FP? I use anonymous functions/callbacks (I mean red functions, pun intended) and closures (even as poor man's objects, lol) but I don't really know why that is FP and what makes it FP.

This is a bit of too big of an ask now that I think about it. I sound like a person who never programmed before and to be like: so what programming language should I use?

Is there anything good around for JS to create BLOBAs?

⬐ runaway

You can write JS functionally but to get the benefits from the video like modeling your data as sum & product types as well as static type checking, you need to use a language with its own compiler.

For languages that compile to JS, Elm looks a bit more like the F# in the video (https://elm-lang.org/) and Typescript (https://www.typescriptlang.org/) is a much more like standard JS.

⬐ maxdeviant

You can also use Fable (https://fable.io/) to compile F# to JS.

⬐ KurtMueller

Scott's website, F# for Fun and Profit, is really good and has some great articles. His article on Railway Oriented Programming is really good.

As for typed, adt functional languages that compile to javascript, there's F#, Elm, Purescript, and ReasonML. I'm a big fan of F# and Elm.

⬐ qsymmachus

It's very easy to write JS in a functional style, since as you point out, it already supports first-class functions, which is the most important building block.

To really go whole hog, try setting one constraint for yourself: only use immutable data. Make all your variables `const`s, and only use immutable data structures (Immutable.js is a useful library for this).

You'll discover that it's basically impossible to write code in the familiar imperative style – everything needs to be a pure function, that just takes an input and returns a consistent output, without mutating state. This really is the "secret sauce" of FP.

⬐ dan-robertson

This seems to be missing the point which the GP makes that a significant advantage for FP is not so much the functions (or even the immutability) as it is the domain modelling. In JavaScript a float is a float and the fact that it is immutable won’t save you from accidentally confusing two things that happen to be numbers (say the width of an element and the duration of an animation, or the price of some product and the amount in stock, or a pipe length in feet and thickness in millimetres).

The other domain-modelling-in-FP feature missing from JS is discriminated unions (aka sum types or enums in some languages).

This domain modelling is a big important feature in rust too (with more invariants which may be expressed using ownership constraints) but no one claims it’s a particularly functional language. Indeed I don’t think one needs FP for this kind of domain modelling that we get via ML-family languages.

⬐ mettamage

Yep, true, DDD with FP looks practical. I love defining new words, and that talk in F# simply made it really clear.

It was weird to see a talk like that and realize to myself "but this is just how my brain works!" I happen to be quite a noun-driven person [1]. And I guess I fell into the trap that this made everything seem so easy and understandable!

Which is why I got excited :P I just bought his book, lol. That was too easy to understand and yet entertaining at the same time while feeling useful as well.

[1] Sometimes even creating new nouns into the Dutch language to make arcane but important concepts clear. My most fun noun is "search term scavenger hunt" (in Dutch it is conjugated) for the situation where you know what you're looking for but don't know the right term to get hits on a search engine and you're hunting for the right word.

⬐ BoiledCabbage

So I didn't include it in the original link, but he has a book he wrote under the same title (Domain Modeling Made Functional). I've been going through it now. It's a much more in-depth treatment of the same topics. He walks through a small product from start to finish.

Additionally he does a really great job of walking through two things that I don't think are covered well enough at all for beginning and intermediate programmers (and even experienced ones like myself may have missed parts of along the way).

1. How to effectively gather customer requirements, what questions to ask, what things to dig into, how to organize them. A simple walk through, better than the hand-wavy stuff most people do when requirements gathering.

2. How to model a domain / problem space before implementing. How to effectively reason about your entities, services and actions. And iterate on these with your customer before coding.

I seriously wish I had run across this when I first started coding. A really great collection of tangible, actionable advice.

I've never done it in javascript so won't try to guess, but the first two parts of the three part book are really applicable regardless of the language. Will have to finish the third to see how it is.

Domain Modeling Made Functional - Scott Wlaschin

  https://pragprog.com/book/swdddf/domain-modeling-made-functional

  https://www.amazon.com/Domain-Modeling-Made-Functional-Domain-Driven/dp/1680502549

(I have zero affiliation with the author and get nothing from any links)

His blog https://fsharpforfunandprofit.com/

⬐ mettamage

Thanks! I bought the book.

⬐ slifin

I'd also recommend https://youtu.be/tV4pHW_WOrY

⬐ qsymmachus

Agreed 100%, sometimes the FP community is its own worst enemy. Too many FP enthusiasts seem to think that "real" FP requires mastering category theory, which is cool and all but really just a particular subset of the paradigm, and a particularly Haskell-centric subset at that.

I encourage anyone who wants to learn functional programming to pick up the classic "Little Schemer" by Friedman and Felleisen. It's a charming book, designed for undergraduates, that teaches you all the important and appealing aspects of FP. And you won't be made to feel like an idiot because you don't know what a monoid is.

⬐ mettamage

I'll dust it of my nightstand. I really should get to it, I guess now is a good day.

Thanks!

This too, eh? "Domain Modeling Made Functional" - Scott Wlaschin

https://www.youtube.com/watch?v=Up7LcbGZFuo

The "F# for fun and profit" site by Scott Wlaschin is a great jumping-off point: https://fsharpforfunandprofit.com/

I discovered it when I was reading a lot about domain driven design, and I stumbled upon a talk by the author that kind of blew my mind:

"Domain Modeling Made Functional" https://www.youtube.com/watch?v=Up7LcbGZFuo