Konrad Hinsen 2024-08-01 06:10:09
Konrad Hinsen 2024-08-01 06:13:30
J. Ryan Stinnett 2024-08-01 11:50:17
Future of Coding History
Konrad Hinsen, I just watched Orion Reed’s talk youtube.com/watch?v=csGNVaB83Rk, pointed out by Christopher Shank. The talk continuously fired the same neurons in my head as does the phrase “malleable computing”. I’m not in that head-space, but, I continue to wonder if there’s a connection … (YMMV)
there is! and Orion Reed spoke at this Malleable Computing event last week: youtu.be/z3v7qj6PxME?si=7WB0ZBd2l1NJHGDz
One part of the connection is in the title: "integration domain" (as different from "implementation domain of components").
There's also an interesting paper by Stephen Kell on that topic: dl.acm.org/citation.cfm?id=1869487
📝 Component adaptation and assembly using interface relations | ACM SIGPLAN Notices
Software's expense owes partly to frequent reimplementation of similar functionality and partly to maintenance of patches, ports or components targeting evolving interfaces. More modular non-invasive approaches are unpopular because they entail ...
Kell's 2009 "mythical matched modules" paper is another good one to check out: humprog.org/~stephen/research/papers/kell09mythical.pdf
Prompt for everyone here: to the extent that you think about the Future of Coding or have projects to try to improve things, what problem are you trying to attack? Can you state it in a couple of sentences? Without reference to a solution? Try to be precise about the audience. For example, some problems affect everyone, while others affect only professional programmers, or only researchers who use computers in their work.
My hypothesis is that focusing on problems will help us all find our most promising collaborators in this group. (The next step will be to combat our tendency to be defined by our tools, to let our tools erect barriers that divide and balkanize us. But that's further down the road. For now, let's just "find our homies," the people we share specific dissatisfactions with.)
There are ideas for problem statements in a couple of earlier threads:
But this thread is not for critiquing or analyzing any of those statements. Just add your own, and nothing else.
(It's totally fine to copy statements from these threads. Many of them were arrived at after tons of consideration so it would be surprising if others didn't care about them. Also feel free to synthesize from multiple statements. Just try to get to something crisp and opinionated.)
I have different answers for each project I'm involved with, but they're all ultimately a "there oughta be". I am the audience, in that I want to see something exist in the world.
It's fun and cool and a matter of creative pride to build well crafted and loved software for your family and friends and immediate community, but not enough people do it because it's unnecessarily hard, intimidating, and annoying.
Our programming environment is the main thing that influences the way we think about software. Much of this learning is implicit. It affects what problems we solve, how we work together, what things we consider possible, what things we consider hard, what arguments we find compelling. There is exists no combination of tools that teach these things in a way that align with my values.
Adapting computers to ourselves is hard.
(hi there @Arvind Thyagarajan)
I think fundamentally I’m trying to attack this feeling that the digital spaces my friends and I inhabit don’t feel like our own personal space, and we have to communicate using someone else’s set of rules.
A lot of what I do isn’t big project based work, it tends to be small sort of toys, but I do always contextualize it within the context of the future of coding — and while it doesn’t have a clear single problem statement my focus shared across implementations, on every project I tackle I explore some new bit or way of approaching the process of programming; whereas people had stories for eons it wasn’t until relatively recently that folks settled in to some of those stories being novels — I’m interested in exploring the different forms are programs can take and what forms help meet what sort of situation
Programming is too hard due to the mistaken fundamental assumption that CPUs are like functions. This mistaken assumption originated around 1954. Future of Coding projects implemented using computers, would progress much more quickly if we thought about CPUs as CPUs instead of as functions. I poke, randomly, at a variety of ways of thinking about programming and try to show that many ideas are 10x easier than can be imagined when using /only/ the function-based paradigm.For example, DPLs (Diagrammatic Programming Languages) and multi-tasking.
I have added a ➕to all statements that I see as overlapping significantly with my own. Four so far, not bad! But I'll also try a problem statement in my own words:
Agency over information processing systems is too centralized. Too many people have to adapt to someone else's systems, rather than adapting their own system to their own wishes.
I am working on this problem mainly in my professional domain, computational science, because that's where I feel I can make most progress with the little means I have, but I'd like to see it attacked more widely.
I think I am most aligned with malleability: adapting software, ad hoc tooling, fast UI/logic generation, alternative representations, reactive programming. Did not know there was a collective until just now!
I want to create interactive content and games, the way I work in Houdini / Photoshop / AfterEffects...
Malleability via abstraction for me. I have found programming to be joyful when done in an elegant domain-specific language. The absolute opposite of "ad-hoc". I hope today's LLM-generating walls of unmaintainable code is NOT the future of coding.
The world runs on rules. Rules can be made computable (without translating them into objects or functions or processes) but it's unnecessarily hard to do. If it was easy, people who understand rules could build software that understands them too, people with problems could get cheap and reliable help, asymmetry of information would be reduced, and the world would be more just.
A great deal more business logic can be expressed in First Order Logic than usually is.
The relational model shows us how to make FOL inference straightforward and predictable.
Therefore, we should implement much more of our apps in a relational system.
We have existing, successful, widely-used systems that implement an end-user relational “programming” system (FileMaker, Access).
Datalog is almost certainly the language in which to express this logic, insofar as we’re not just doing it with a GUI.
This attacks the issues we’re all concerned with by:
The unprecedented magical powers and freedom of creation of programmable technology are not available to normal people, they're controlled by a "priesthood" of techies, big tech and technocrats that encourage and exploit complex, hard, imperative architectures and paradigms that inevitably lead to them watching, censoring, manipulating and dividing us.
All of us should be freed and empowered to cast our own magical spells over our own personal and shared realities, through simpler and softer, humane styles of interaction.
I think the world needs more domain specific languages.
"General Purpose" programming languages are difficult to work with because they require you to work in abstractions far away from the problem domain. Domain specific languages can have first class visualization/structured editing of logic and data. This dramatically reduces the amount of things to keep in your head, and domain expertise (rather than coding skillz) becomes the primary prerequisite for proficiency.
Falsifiable theory…
Theory: Function-based thinking greatly restricts thinking about FoC.
Test: if this theory is true, then examination of the source code for The Mother Of All Demos will reveal that not all parts of the demo system were tightly inter-connected into a single synchronous, functional blob of design.
How?: Where can we find the source code for TMOAD? If we obtain the source, how can we reverse-engineer the design out from the implementation details? If we can get at the design, we should look for how the sub-units of software are interconnected. We need to examine if the code is designed as many islands of synchrony vs. being designed as just one big blob of synchrony.
Corollary: if TMOAD was designed as many islands of software and hardware, then it is unlikely that anything as interesting as TMOAD can come of building software on computers using only synchronous languages, like Python, Haskell, using concepts such as thread libraries, theorem-provers, etc. [Thread libraries are but assembler-level work-arounds that enable the use of the function-based programming paradigm with languages like Python, Haskell, etc. Theorem provers need single islands of synchronous code, to work]
I take the success of Excel as evidence that functional programming is the most natural way to express programming for non-programmers.
Excel ~is~ a functional programming language. The cells contain either values or functions of those values.
It is a lazy, partially spatial (as opposed to purely textual) functional programming language.
The latest version even has user-defined functions (a ~major~ update to its functionality that went largely unremarked).
Excel is perhaps the most successful example of the sort of thing that this group is about.
I have a feeling that you, Paul Tarvydas, have a very specific definition of what you call “functional” in mind, that may not fully overlap with what many of us here think it means. My interpretation is that you think of functional more in terms of structured programming perhaps? I also don’t think “functional programming” is particularly well defined either. I think Conal Elliott is known for criticizing this.
I wonder if the issue might be with the word “programming”. I try to be careful to use the phrase “function-based programming” instead of “functional programming”. Function-based programming covers many more programming languages than functional-programming covers. I think of “programming” to mean solderless - quick and easy - reconfiguration of reprogrammable machines. At that low level, functions are not inherently supported by hardware - you have to /add/ software and hardware to make “programs” work like “functions”, i.e. you have to add lots of inefficiency to allow manipulation of reprogrammable hardware to make the hardware expressible as mathematical equations written on paper. I think that the paradigm of functions-grafted-onto-hardware is inappropriate for many modern problems, like internet, robotics, gaming, GUIs, etc. as witnessed by the invention of extreme gyrations and work-arounds such as thread libraries, promises, monads, etc. Early FORTRANs and BASICs did not express hardware manipulation as mathematical functions. Early Lisps showed that grafting functions onto hardware was viable and was a productive /paradigm/. Sector Lisp shows just how clean and small this can be when the paradigm is respected. Yet, early games showed that this kind of thinking was /not/ necessary. I feel that so-called “computer science” ran with only the one paradigm - i.e. inefficient, function-based thinking mapped onto hardware manipulation - at the expense of cutting off many avenues of problem-solving. For the record, C and Pascal and Haskell and Python and JS and WASM and ..., are function-based, while PROLOG is not function-based, and, StateCharts are not function-based. I think that the function-based mentality deeply affects developers and, therefore, affects what developers can invent for non-programmers. I think that spreadsheets are just a stop-gap technology. Spreadsheets are “the best” that programmers can provide for non-programmers given developers’ function-based mentality. Mathematical 2D notation is OK for use with papyrus and clay-tablet media, but, is not necessarily the most appropriate way to think about reprogrammable electronic machines in 2024. So, in my mind, we need to change the culture of /developers/ before even trying to imagine FoP (Future of Programming). I think that TMOAD (The Mother Of All Demos) was not bound by the function-based paradigm and that function-based programmers hold TMOAD in awe because it looks non-understandable - like magic - from a mono-paradigmatic perspective. I think that it would behoove modern programming researchers to delve deeply into TMOAD and to see how it differs from function-based thinking.
(FTR, I fleshed this out some more into a longer essay and posted it to my substack programmingsimplicity.substack.com/p/2024-08-03-functional-vs-function?r=1egdky)
📝 2024-08-03-Functional vs. Function-Based Thinking and Mono-paradigmatic Programming
I am more focussed on developers than on non-programmers.
Follow-up to 💬 #thinking-together@2024-08-01: post a single comment with a number from 1 to 6 for every comment but yours in yesterday's thread, indicating how close you perceive everyone else's problem statement to be relative to yours. (And don't read other people's comments before you post yours; that's part of the fun here.)
Here's what the numeric scale means:
Hopefully that makes sense and I haven't missed some major option..
In a day or two I'll collate the results in the attached table. (You're welcome to do so as well; just download the html file and open it in a browser tab, fill in and hit the 'save' button to save a local copy with your edits. Upload it here if you like, that can be an alternative way to give your votes.)
Here are my reactions, in the same order as the comments on the previous thread:
(Hopefully this example helps clarify what I'm asking for.)
Attached is the html file with my row filled out. Just in case that helps 🤦
Ivan Reese: 4, 1, 2
Arvind Thyagarajan: 3.5
Jasmine Otto: 2.5
Jimmy Miller: 1
Kartik Agaram: 1–5
avon: 4
Eli Mellen: 0.9
Paul Tarvydas: mostly 6, but DPLs are a 2
Konrad Hinsen: 6 (but ironic)
Tom Larkworthy: 4 i
Dany: 1 + <3
Nilesh Trivedi: 5?
Beni Cherniavsky-Paskin: 3
Jason Morris: >6
Guyren Howe: 6.0
Duncan Cragg: 3
Ivan Reese: 1, 6, 6 (edit)
Arvind Thyagarajan: 4
Jasmine Otto: 2
Jimmy Miller: 1 (it doesn't say anything about your approach though)
Kartik Agaram: 4
avon: 4
Eli Mellen: 6
Paul Tarvydas: 6
Konrad Hinsen: 3
Tom Larkworthy: 2
Nilesh Trivedi: 2
Beni Cherniavsky-Paskin: 4
Jason Morris: 5
Guyren Howe: 3
Duncan Cragg: 6
Ivan 2, 3, 4
Arvind 2
Jasmine 2
Jimmy 2
Kartik 2
Avon 1
Eli 2
Paul 4
Konrad 2
Tom: -
Dany 3
Nilesh 2
Beni 1
Jason 2
Guyren 3
Duncan 3
• Ivan Reese: 6
• Arvind Thyagarajan: 2
• Jasmine Otto: 3
• Jimmy Miller: 3
• Kartik Agaram: 2
• avon: 3
• Eli Mellen: 6
• Paul Tarvydas: 5
• Tom Larkworthy: 3
• Dany: 5
• Nilesh Trivedi: 3
• Beni Cherniavsky-Paskin: 3
• Jason Morris: 5
• Guyren Howe: 5
• Duncan Cragg: 2
Ivan Reese: 3,3,3
Arvind Thyagarajan: 2
Jasmine Otto: 3
Jimmy Miller: 2
Kartik Agaram: 2
avon: ---
Eli Mellen: 3
Paul Tarvydas: 6
Konrad Hinsen: 3
Tom Larkworthy: 2
Dany: 3
Nilesh Trivedi: 3
Beni Cherniavsky-Paskin: 2
Jason Morris: 2
Guyren Howe: 6
Duncan Cragg: 2
Ivan Reese: 4
Arvind Thyagarajan: 4
Jasmine Otto: 5
Kartik: 5
avon: 4
Eli Mellen: 6
Paul Tarvydas: 6
Konrad Hinsen: 4
Tom Larkworthy: 4
Dany: 6
Nilesh Trivedi: 6
Beni Cherniavsky-Paskin: 5
Jason Morris: 5
Guyren Howe: 6
Duncan Cragg: 4
A minor remark on the wording of 4 and 5: I have added a tacit "in the context of my work" to them. There are problem statements here, e.g. by Paul Tarvydas, whose background and motivation I can perfectly well understand, but which I don't see as important in my own work.
Hello, I am currently building a lowcode platform for easy and fast backend development. Basically, you write logic using functions which look like excel functions or UDFs. Do you have any opinions on programming using Excel? I have written prototypes many times using it, but main problems have been 1) not being able to use it as a backend 2) more complex sheets are hard to understand and test
And just to share a demo that now works: scrape main content of a web page, ask a question about it, and you will get an answer (powered by OpenAI API gpt-4o-mini)
api_key=PIPELINE_ENV('OPENAI_API_KEY') page=SCRAPE_URL(' yle.fi/news ') answer=OPENAI_QA(api_key, page, 'any news related to Posti?')
So basically logic is expressed as a sequence of functions (and not as cells in a sheet)
So my thinking is that maybe a share of programming (in future) could be done using lowcode solutions, which would be possible because of a choice of limiting expressivity and complexity. For example, for complex programs you would still need to use Turing complete languages and human programmers
I like the idea of programming in spreadsheets in general, and tend to agree with you that they need some new tools as sheets grow complex. I don't have much direct experience with them, though. I haven't kept up with the past attempts, but I know we've discussed them a bunch here in the past. Let me try to dig up some links..
Oh this was a good one from last year: blog.nilenso.com/blog/2023/11/10/spreadsheets-and-small-software
Treesheets is a particularly memorable project in this area: strlen.com/treesheets
loglo.app experiments with combining a grid with a shared stack per row.
youtube.com/watch?v=y1Ca5czOY7Q shows off a project called Flowsheets.
A few tantalizing links in rarely-used channels:
akkartik.name/archives/foc/of-end-user-programming/1573942666.111300.html
akkartik.name/archives/foc/of-logic-programming/1621430499.000300.html
akkartik.name/archives/foc/of-music/1625731658.003200.html
The history of #introduce-yourself has a ton of references to people trying to do this. Most not active here, sadly: akkartik.name/archives/foc/introduce-yourself
Other than that, there's just too much, but maybe a good starting point is to search for keywords in the top-level view of these channels:
akkartik.name/archives/foc/thinking-together
akkartik.name/archives/foc/linking-together
akkartik.name/archives/foc/share-your-work
akkartik.name/archives/foc/present-company
akkartik.name/archives/foc/two-minute-week
akkartik.name/archives/foc/devlog-together
Jari and others, definitely share any resources you've been collecting as well. Or highlight any nuggets you particularly like in the archives. This feels like a topic worth a public list of curated bookmarks. Maybe somebody already knows of one?
Here's the current state of people's reactions to each other's problem statements. If you haven't added your reactions yet, please consider doing so! If you haven't written a problem statement yet, please do so before reacting to those of others. I know it's a non-trivial bit of work. I tend to open Slack on two windows somehow to jump between 💬 #thinking-together@2024-08-01 and the problem reaction thread 🤦 But it does seem like something promising to think about.
I've also included a very rough, very preliminary, very incomplete stab at visualizing clusters of people's problem statements. There's no reason to think this "space" is Euclidean or 2D, so take it with a huge bucket of salt.
The visualization is in no way mapping status relationships. The intent is not to exclude anyone, but a very narrow instrumental purpose of finding opportunities to collaborate. If you need an analogy, a better one might be a star chart. It seems safe to assume we're all light years apart given our track record of collaborating 😄 This picture is an initial attempt at making a map based on imprecise measurements from a single point. If you spend any time thinking about the map, try to build your own from the raw data to avoid my inevitable biases.
I started out with Kartik at the origin (no objectivity here!) and positioned first my 1s, then my 2s, then 3s and so on all the way to 6s. Then I tried to go through others similarly and resolve tensions in a very rough, very manual way. I might do this a few times to try to get better at it.
Even though this "data set" is almost certainly high-dimensional, a few 1-D relationships popped out at me:
Kartik -> Tom Tom -> Paul = Kartik -> PaulKartik -> Tom Tom -> Nilesh = Kartik -> NileshI responded by putting the 4 of us on a straight line. There may be a spectrum here that bridges the incomprehension between the ends.
This sort of bridging of incomprehension is a common pattern. I initially had Ivan as far away from Kartik as Paul . But several connections drew the Ivan / Eli cluster closer. Dany too might be as far from me as Paul , but is just 1 away from Jimmy . Guyren too, but is close to Tom and Dany . So some of these edges have more "tension" than others, and I haven't come up with a way yet to show that.
(I'm currently showing edges labeled 1-3. If we get more data I might need to prune that further. The edges are directional but unfortunately my tool doesn't have arrows.)
Anyways. Add your problem statements and reactions!
