Nick Smith 2021-12-06 06:01:18 Has this community ever agreed on some "big problems" in programming language design? Having recently gone back to think about "big picture" things, I've realised I have no idea what other people think is important. Surely there are a couple of historical threads.
It would be a little awkward if after several years of having this Slack group, we've never collectively stopped to define the problems we're working on.
Christopher Galtenberg 2021-12-06 06:44:59 Who needs to define a problem to work on something good – our new paradigms don't require a crisis
William Taysom 2021-12-06 08:07:01 Would be great to have a conversation about what the big problems/directions of interest are. (Historical threads in Slack? I thought Slack was all about the eternal present. 😏)
Chris Knott 2021-12-06 10:08:29 I thought about starting a thread trying to define the major currents/factions in FoC space. I was inspired by the deadlock RPG game thing. This is very much a "Type 1 FoC" solution in that it's purpose is make current programming practice more understandable. It basically brings more people up to the point of a genius coder. Most of Learnable Programming is like this.
A Type 2 project would be something like these Actor Model systems that try and come at computation from a completely different place where things like deadlocks don't exist. I think that Dynamicland and maybe Hest is this type.
A third type would be the low-code/app builder type projects which just try and help people get to solutions as directly as possible.
So I would categorise projects based on how they deal with the fundamentally difficult points about programming at the moment;
- Try and explain them
- Try and avoid them
- Try and hide them
Chris Knott 2021-12-06 10:10:01 In this ontology I personally am a diehard type1-er therefore I may have inadvertently characterised the other options negatively
Andrew F 2021-12-06 10:13:58 A clear problem is indeed very helpful for making something both good and novel. I've thought about sharing my big ol list of design goals for feedback, but it's honestly still not super coherent.
One of the big things most of us seem to agree on is that programming should be more accessible to people lower technical skill (not sure about everyone else but I see this as overlapping the goal of reducing accidental complexity).
Another common undercurrent is the sort of political goal of keeping computation more under the control of device owners than corporations, et al. I'm sure there's a better way to phrase this....
Duncan Cragg 2021-12-06 12:08:51 I'm fully with what Andrew F said! He may not agree with my four-word summary: "power to the people!!"
Duncan Cragg 2021-12-06 12:10:09 ("Power to the people" can be Anarchistic, not necessarily Communistic!)
Nick Smith 2021-12-07 06:22:42 Well, I would be willing to have a proper video meeting wherein we as a community attempt to compare and contrast our perspectives on "the problem" with programming, and possibly come up with an "official" document that captures them. Perhaps we could try this? If you're interested, add your availability to this poll.
Nick Smith 2021-12-10 04:08:04 Hmm... only two other respondents. I must say, I'm surprised there isn't more enthusiasm!
William Taysom 2021-12-10 08:25:29 I found specifying my availability in when2meet, a little weird. So I almost gave up.
Duncan Cragg 2021-12-10 17:05:47 I think firstly that people are more comfortable getting the conversation started here, not on video, especially when it involves the mass synchronisation of busy and diverse folk, and secondly, yes, that site was, well, I don't want to be rude, so.. 🤗
Andrew F 2021-12-10 20:44:01 Video does not strike me as a good format for such a sprawling topic. By default a conversation is a random walk, not a survey. If you were really disciplined, you might be able to come up with a curated list of subject headings, maybe outline an agenda for a much larger discussion, but even that would be tricky. To say nothing of the logistical synchronization issues others mentioned... I think we can do better async. You are making me think I should get the ball rolling by posting my draft list of goals.
Nick Smith 2021-12-11 09:41:03 I actually dislike asynchronous (multi-day) text chat quite a lot, because in my experience everyone ends up talking past each other. In a video chat, you can more easily have a dialogue rather than a monologue. You can ask for clarification. But if everyone else prefers text chat then I suppose I'll have to settle for that.
I think video can work well if people come prepared with detailed discussion points.
Nick Smith 2021-12-07 06:22:42 Well, I would be willing to have a proper video meeting wherein we as a community attempt to compare and contrast our perspectives on "the problem" with programming, and possibly come up with an "official" document that captures them. Perhaps we could try this? If you're interested, add your availability to this poll.
Henning Sato von Rosen 2021-12-06 12:11:06 Hi all, anyone else here that’s a fan of Rich Hickeys thinking on language design? Please comment with your main take-aways! I’ve found his talks a treasure trove and his approach to go back to deep philosophy and fuse it with hard-earned dev experience a great inspiration! Here’s a link to a bunch of transcripts for those in the enviable position to not yet having devoured all of them ❤ https://github.com/matthiasn/talk-transcripts/tree/master/Hickey_Rich
Disclaimer: Obviously no one claims Hickey, including himself, invented all of the stuff he talks about, but his way to concretize, make use of, make understandable the stuff is just something appreciate deeply and learned a lot from.
Henning Sato von Rosen 2021-12-06 12:19:38 So here are some of my favorites that Rich Hickey describes in his talks and that relates to Language Design thinking, right off the top of my mind:
Orthogonality as the fundamental principle for composable language features
Data as a universal interface
Respect and understand the nature of Value semantics
The map data structure as a flexible composition of orthogonal concerns (my formulation, derived from his considerations for spec)
Build on abstractions, not conretions
etc etc
Jimmy Miller 2021-12-07 18:29:21 So as a full time clojure programmer I definitely have a lot of opinions on this. I largely agree with the philosophy, but at the same time find some unease with it.
I guess I want to have this conversation, but I also don't want to be super negative.
Clojure is a fantastic set of tradeoffs that makes for a super productive programming environment. But I do worry that there is a lot of talk from rich that this model of programming is the only good one. That is something I think needs more push back in the clojure world.
I think languages have something to learn from clojure. But clojure could learn a lot from other languages as well.
M. Lop 2021-12-08 20:02:57 Do someone know about something that uses an alternative to rendering trees ?
Ivan Reese 2021-12-08 23:48:51 Does a "scene graph" (commonly used in video games) count as a rendering tree?
Ivan Reese 2021-12-09 16:58:53 In that case, a scene graph (and the corresponding mesh data stored as indices and vertices, etc etc) is an alternative to web-esq rendering trees, used by basically all 3d video games :)
Henning Sato von Rosen 2021-12-09 10:39:12 Dear all, let’s do some #thinking-together about a really simple idea that I find irresistibly non-complected, but might well be partially or totally flawed or just a reformulation of something else; but hey! for the duration of this post, lets cast doubts aside and enter creative mode; exploring the idea as if building just another mind-blowing creation in Minecraft 🙂 :
Any static web page as well as every dynamic UI in the browser or anywhere, can be seen as an orthogonal combination of embodiment and essential state. Let’s call such a combination a layer. (Think of state the values and embodiment as rendering/timers/event-handlers etc).
Here’s the problem it is aimed for solving: State composes perfectly with state, embodiment composes perfectly with embodiment; but when we mix state and embodiment, complexity explodes exponentially; we can no more distinguish between them, no more extract and model the state explicitly, visualize it, generate tests based on it etc and for every new part or feature, technical debt is amassed and the complexity quickly skyrockets into levels that not even the most skilled designers and developers can handle.
So back to the really simple idea: Let’s keep it orthogonal; let components be expressed in an orthogonal way, let’s composition propagate orthogonality.
What follows from it? How can we model it; can we being to imagine a Layer Machine formalism? A layer machine markup language? Make an enlightening run-time visualization? Can we implement it, and in how many LOC?; can we use it to explore its PL usability factors along some cognitive dimensions? What new ideas can we form based on that experience?
Andrew F 2021-12-10 00:45:38 I'm having trouble with your terminology. By "embodiment" do you mean the translation between the "essential state" (I'm assuming this means pure business/domain logic) and a concrete UI?
Nick Smith 2021-12-10 04:11:35 Yeah, I can't really comment on this post, because you've coined your own term and not explained what it is, and why it "composes perfectly" with itself.
William Taysom 2021-12-10 08:24:16 "State composes perfectly with state, embodiment composes perfectly with embodiment; but when we mix state and embodiment, complexity explodes" — I'll take some of whatever state and embodiment you've got composing. In my experience, state composes awkwardly ("oh, it depends on this other data way over there"), embodiment composes awkwardly ("oh, that isn't going to fit on the screen"), and the two, when mixed, compose even worse ("wait, I was in the middle of editing that, it can't just disappear when make a change that will remove it from the list").
Henning Sato von Rosen 2021-12-10 09:00:51 @William Taysom What are examples of things that do compose well, in your experience? (I’m interested since I think composition is a key asset in keeping complexity from exploding)
Henning Sato von Rosen 2021-12-10 10:05:08 Andrew F Nick Smith Sorry for posting raw ideas of the top of my head and messing up the terminology. I’ll keep that in mind next time. Do you think a brief summary and a link to a blog post w code examples would be more helpful? Anyways, what I mean with stateis just a tree of pure values, like in statecharts , and, yes the embodiment can be DOM, concrete UI etc. In stead of Layer machine, just read state machine or statechart and assume a composable version of them that covers the whole app instead of leaving a lot to the host language. And in stead of layer machine markup, think HTML, just extended with some new kinds of tags or metatags. I think explicit state modeling as in e.g. statecharts is so great for keeping complexity at bay, and that the biggest thing stopping it from being even more useful is composability; thus I find anything that might enhance composability of statecharts/state modeling super exciting! Hope to do a better job of exiting people for that idea the next time! 🙂
William Taysom 2021-12-10 14:45:44 In my experience? The third rewrite composes better. The first version is too hot: rough and ready. The second is too cold: over-engineered. And the third is just right: reusable pieces that snap together tightly using minimal glue.
I have a short list of concrete examples, not my own:
Henning Sato von Rosen 2021-12-10 15:49:07 Andrew F Nick Smith Thanks for feedback, and my bad for posting raw ideas of the top of my head and omitting definitions/intuitions 🙂 I’ll keep that in mind next time; doesn’t hur to work on my communication skills 🙂 Do you think a couple of descriptive sentences and a link to a blog post w code examples would be more helpful? Anyways, what I mean with stateis just a tree of pure values, like in statecharts , and, yes the embodiment can be DOM, concrete UI etc. In stead of Layer machine, just read state machine or statechart and assume a composable version of them that covers the whole app instead of leaving a lot to the host language. I think explicit state modeling as in e.g. statecharts is so great for keeping complexity at bay, and that the biggest thing stopping it from being even more useful is composability; thus I find anything that can enhance composability of statecharts is super interesting.
