Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Great comment!
>I think late architecture is orthogonal to functional, imperative
Absolutely. From a truly architectural view, procedural, functional, and method-oriented (current OO) are really only variations on the call/return architectural style. Good and sometimes important distinctions, but not really that far apart. They are very much about computing, results from inputs. That is an appropriate architecture for fewer and fewer programs.
See Why Architecture Oriented Programming matters
https://blog.metaobject.com/2019/02/why-architecture-oriente...
and
Can Programmers Escape the Gentle Tyranny of call/return?
https://2020.programming-conference.org/details/salon-2020-p...
> its solution is higher level than even functional programming
Yes. Well, functional actually gets most of its utility from being lower level as far as paradigms go (less powerful). But yes.
> and more abstract
No. Well, yes, if expressed with current programming languages. But that's part of the problem set, not part of the solution set. We should be able to express our architectures less abstractly, more concretely, but for that we need linguistic support. Which is why I am working on that:
http://objective.st
> I want software architecture to be cheap and easy to change without breaking any existing behaviours. I don't know much research on this subject.
There was quite a bit of research at CMU, for example on packaging mismatch. Famous paper Architectural Mismatch, Why Reuse is so hard, and the 10 year follow up in 2009: Architectural Mismatch: Why Reuse is Still So Hard
https://repository.upenn.edu/cgi/viewcontent.cgi?article=107...*
Not much has changed since.
> https://github.com/samsquire/ideas4
> https://devops-pipeline.com
Will check those out. Dataflow is definitely a big part of it, with the extension of dataflow constraints (make, spreadsheets, "FRP"/"Rx"). But so is in-process REST with Storage Combinators!
And breaking down barriers between scripting and "real" programming.
do-notation can be easily implemented using delimited continuations (ie. generators). Generators compose well and flatten tail calls so you don't need TCO or trampolines. The only notable issue is that one-shot delimited continuations like generators don't work with non-deterministic monads (ie. List). Multi-shot can be emulated by keeping a cache of past values and replaying the generator, but performance will suffer. See burrido [1] for a JavaScript do-notation implementation.
[1] https://github.com/pelotom/burrido