> After all, sometimes it feels like most of the programming you wind up doing is glue code. This, except in spades. > But on the other hand, it feels like a

> After all, sometimes it feels like most of the programming you wind up doing is glue code. This, except in spades. > But on the other hand, it feels like a lot of that already is taken care of. E.g. CSS is essentially declarative glue code for what would otherwise be a huge number of painting and layout lines of code. Every gui environment seems to have something like that. Whether it's as primitive as Win32 or as advanced as Android, you still program by putting widgets with properties in places. None of these really allow you to program the edges. > And most of the glue code I myself wind up writing winds up being written specifically to handle various constraints around memory, disk space, etc -- e.g. how to import a protobuf that changes every 30 seconds and convert it to 10,000 rows in a live database in a way that's performant -- and so isn't as amenable to something simple. If the glue that I wrote served that purpose, I'd be happy. If you're programming to meet a business requirement, it's not really glue: and performing fast enough is a business requirement. I can handle the Win32 glue, and work around it, because I know it's there to make it easy to adapt code that was designed to work on computers with single digit megabytes of RAM. If I write an Android program, the whole thing feels like writing glue, and the result is as chunky as an Android program always is. There's like one line of code to implement a requirement surrounded by dozens of lines of code to fulfil the ever changing requirements of the API. The best way of actually focusing on the requirements is by writing even more lines of Rx glue to turn the whole thing inside out, but the Rx glue isn't particularly concise either or well documented. The whole thing feels like I'm fighting against the people at Google, who give me an API that is neither efficient nor effective, nor some compromise of the two. I do think these reactive style libraries and functional abstractions help to factor out some of the glue, if you don't have to write it all yourself. And when I can write a page in an FRP style, I can squint and imagine, with a bit more work, the business rules could be expressed in a declarative/markup language and even automatically drawn as a (state machine) diagram. In principle, with such a markup, you could write the glue for each platform and compile it to a native Swift iOS app or a Kotlin jvm Android app or JS app (using some library, perhaps Rx, as part of the target). (Naturally, you wouldn't have something that was truly write once. Platform specific logic and processes should still be captured in the business logic, when they aren't mere formalities. But it still gets the complexity way down.) I think it's in that direction we should go. Just like we can declaratively specify a REST API in Swagger and compile it to a target language and library, we should declarative specify the business logic of our program and compile it to a target language and library, instead of trying to specify our logic in terms of the APIs provided by some GUI service provider. The declarative language should be third party, so that it is genuinely adaptable to multiple platforms.