If it doesn’t look like an elephant in the room, perhaps the elephant is the room.
This is the perfect metaphor!
The problem of composition can't be recognized until you zoom out far enough, and consider the outmost layers by which software is connected, namely operating systems and networking protocols.
If you're only thinking about revolutionising "app development", the problem of composition is very difficult to see.
“move I/O entirely out of our programming model into the implementation of a denotationally simple model for whole systems.”
You rely on Conal's beliefs, arguments, and utterings quite heavily. I can't help but consider that your belief in the usefulness of DCTP is thus an offshoot of Conal's (convincing) stories, rather than a conclusion you have truly reached on your own through independent critical thought. I think it's crucial to keep asking: what if Conal just hasn't found the answer here? What if DCTP can't find widespread utility? Maybe it can, but breakthroughs like this are really rare, and I've failed to believe this one myself despite many attempts.
non-solution
Non-solution to what? Your tone is quite dismissive. While monadic IO may not be ideal, it's certainly been put to a lot of good use in production software.
I don't like monadic IO either, but it's hard to convince people of anything when you shoot down their beliefs too aggressively.
So, have you caught the denotational disease? I hope so!
I'm afraid I haven't, and it's not because if the quality of your explanations. I just really don't see how this is better than the Elm architecture. Dealing with streams and continuous time just adds a lot of cognitive overhead that simply doesn't exist in TEA. Yes, with TEA you have to look across model, view, and update functions to see the whole data flow, but your attempts to visualise DCTP could easily be put to TEA for the same benefit.
While I am in love with this paradigm, it hurts my head to mentally grapple with such unwieldy types
Seems like you agree...
const count_ = yield liftNow( sample( scan( (n, m) => 1 + m, 1, switchStream( output.map(l => combine(...l.map((o, i) => o.click.mapTo(i + 1)))) ).filter(x => (x % 2 === 1)) ) ) );
This code just seems like it could be much more simple if described using a discrete Model-View-Update architecture (TEA). The logic here is dead simple, but fiddling around with the streams and cycles arguably adds incidental complexity.
Image Source
You got a license to use this image?
I use this perspective to argue against the Elm/Redux architecture and for DCTP.
It's not clear to me how/where Elm fails to be denotational. A clear technical description of the gap would be really helpful.
no there there
typo
I wanted to show these pompous pricks that their precious old FRP was worse than my modern FRP. (Maybe you feel the same way towards me, dear reader? 😜)
I think this language is far too aggressive and is likely to turn people off right away. Even if they were to keep reading, they'd probably turn combative for the rest of the article, which is not a mindset amenable to persuasion.
where I was surprised to find that it needed little improving: it was gotten right from the start.
to me this comes across as a little partisan, or "holier than thou"
I been searched
typo
Perhaps we could look for the good ideas in the systems we know and see if we can distill the essence?
I think this is crucial: you have to learn from the past to invent the future. "Stand on the shoulders of giants" etc.
We need to pick the best ideas, whatever they are.
if we consider introducing ‘functions’ and ‘data types’ in our programs and then also introduce the ideas of ‘verification’ and ‘soundness’ we end up at type systems. This is a small corner in the entire design space we started out with, but one that gets way too much attention.
Sure we take these things for granted, but we've never really found any alternative that works. Functions and data types are how we conceptualise, abstract, and modularise functionality.
The way you talk about things suggests that it is worthwhile to try and start from scratch. I don't think that will ever be possible: there's 80+ years of knowledge from many extremely intelligent people that brought us to where we are today, even if they didn't get everything right.
I don't think it's wise to consider throwing things out unless we believe that there is a problem directly associated with their existence.
we may need two or more programs to bring about desirable behavior
When? Why? If readers don't already know, they'll be confused.
(because that sure seems like a great idea 🤔).
I'm not sure that this sarcasm about text files here is necessary: many people still believe text files are a good thing, and you don't want to cause them to feel offended or doubt your wisdom due to this view (unless you properly explain why you hold this view).
presentation
representation
presentation
Do you mean "representation"?
persistent
What do you mean by "persistent"?
‘document like’
"document-like"
exhibit
"exhibits"
The current programming world view is very program-centric. The Wikipedia entry for computer mentions ‘programs’ in the second sentence. We obsess over programs — how to create programs, debug programs, visualize programs, which language to choose to write our programs, what are their type systems and syntax, and so on.
I would mention right up front what you're getting to: that the concept of a "system" is at least as important as that of a "program".
re-frame
Again, why italicised? Not a common style. (I realise these comments are superficial, feel free to ignore them.)
‘written in full’ and then ‘submitted’ to the system, to be possibly verified and then ‘run’.
I personally don't think it makes sense to put quotes around these phrases :P
their
I'm not sure why this is italicized.
ng large text corpora is a time-consuming effort. Although single-user annotation tools are available, web-based annotation applications allow for distributed annotation and file access from different locations. In this paper we present the web-b
testing
metadata
RDF is a model for data about data!