Closed marianoguerra closed 1 year ago
π§° Moldable Live Programming π Programming as Theory Building π’ Homoiconic Spreadsheets βοΈ Solving Problems with Fuzzy Constraints
π Webassembly Woes via Nicholas Yang
A draft about my woes dealing with compiling a Rust + C codebase to WebAssembly
π Higher-level commands for VSCode via Gregor
Iβve forked my Tofu experiment into a more production-ready subset, Soy! Iβll slowly expand its feature-set tofuwards: Higher-level commands for VSCode
π₯ Moldable Live Programming with Clerk (by Philippa Markovics) via Jack Rusher
We've had a bit of trouble communicating the flexibility of Clerk, so I'm very happy to see this short talk from my colleague Philippa Markovics talking about many use cases that aren't anything like one might expect from a Jupyter-style notebook
π FoC Podcast β’ Episode 61 Peter Naur: β’ Programming as Theory Building via Ivan Reese
Future of Coding β’ Episode 61
Peter Naur β’ Programming as Theory Building
π«Ά futureofcoding.org/episodes/061
What a bop! This paper offers a compelling explanation for many of the difficulties we encounter when maintaining large, long-lived programs. It makes us question the value of source code notation, commenting, documentation, and other artifacts of the programming activity, especially when it comes to communicating the ideas behind a program between different people working on it. When we work on our FoC projects, are we even understanding the right misunderstandings of our understandings? To make sense of that nonsense, we turn to the master of terrible bulls#$% (Ivan's take, not Jimmy's) β Gilbert Ryle!
Next month, we're honouring the recently-deceased Fred Brooks by dancing on (or, perhaps, with) Mythical Man-Month and No Silver Bullet.
π high-level architectures of information processing systems via Konrad Hinsen
Inspired by π¬ #linking-together@2023-01-03T14:27:40.085Z and futureofcoding.slack.com/archives/C5U3SEW6A/p1672816690782479, plus my daily work with a Smalltalk system, I started thinking about high-level architectures of information processing systems.
Spreadsheets are two-layer systems, with a data grid on top and a code grid below it. That's a good architecture for dealing with heterogeneous grid-shaped data and shallow computation. For homogeneous grid-shaped data (arrays, data frames) you'd prefer to compute with the grid as a whole, and for complex/deep computation, you want a more code-centric architecture. You can of course prepare the complex code in some other architecture and just call it from a spreadsheet. High-level architectures can be composed.
Dataflow graphs, of which Data Rabbit is an amazing implementation, have nodes containing code and data flowing through the edges. They can deal with irregularly shaped data, even messy data, but, like spreadsheets, they are limited to shallow computation.
A Smalltalk image is a code database built on top of a an unstructured "object lake". It's great for dealing with complex code, but has no high-level structure for data. You can, and have to, roll your own. From this point of view, a Smalltalk image is the perfect complement to a spreadsheet or a data flow graph, having opposite strengths and weaknesses.
So... are they more such high-level structures that have proven useful in practice? Is there just a small set whose elements can be combined, or should we expect a large number of unrelated architectures being good for specific purposes? Note that I am thinking about "good for", not "applicable to". All Turing-complete systems are equivalent in principle, but that doesn't make them good tools for all purposes. My question is ultimately one of human-computer interaction.
[January 3rd, 2023 6:27 AM] nilesh.tr: Homoiconic spreadsheets: What, How & Why (by Eli Parra)
[January 3rd, 2023 11:18 PM] jack529: Loads of good FOC stuff here: Through the looking glass w Data Rabbit: "A System built for Seeing" (by Ryan Robitaille)
π¦ Tweet from @ssebastien via Mariano Guerra
OurPaint is a new paint program that uses programmable brushes using a visual language. Node-based visual programming/editing environments are quite fascinating to me, as they provide immediate feedback, make structures tangible (as opposed to text), and can be picked up quickly.
π¦ SΓ©bastien Pierre: OurPaint is a new paint program that uses programmable brushes using a visual language. Node-based visual programming/editing environments are quite fascinating to me, as they provide immediate feedback, make structures tangible (as opposed to text), and can be picked up quickly. https://twitter.com/ChengduLittleA/status/1609921080923402241
π¦ @ChengduLittleA@mastodon.art: Our Paint 0.1 is released for Linux! Yay!
Download at http://ChengduLittleA.com/ourpaint
Borderless canvas, nodes brushes, color management, wacom support, and more!
(I have no idea if it runs on your machine, but there's an AppImage if anyone wants to try, otherwise you can compile)
π₯ Homoiconic spreadsheets: What, How & Why (by Eli Parra) via Nilesh Trivedi
π₯ Artificial Life Creation T-0 and Launching via Lu Wilson
Hey all if you haven't been following along with Dave Ackley's quest to make artificial life, he's finally done it! The project is incredible. His goal is to construct an entirely new computational stack that is:
The whole thing is a massive inspiration to me and I would have never got into the world of computing without it! Maybe it'll inspire you too.
And this week, he finally produced a self-replicating 'cell'. I found it oddly emotional to see the project get to this milestone! Anyway, happy new year!
π Handmade Network via Duncan Cragg
What do y'all make of this: handmade.network ?
𧩠Snap! Build Your Own Blocks via Nilesh Trivedi
Berkeley's Snap! visual programming language goes far beyond the popular ones like Scratch! snap.berkeley.edu
It's got first-class lists and functions, procedures as data, continuations, APL-like hyperblocks / higher-order functions, converters to traditional languages like Javascript, Python, C etc, metaprogramming, object-oriented programming with inheritance/polymorphism, ability to access hardware and the Internet.
π Untangle: Solving problems with fuzzy constraints via Jimmy Miller
Really interesting exploration of pattern matching, logic programming, and ink on cavas from Ink and Switch. Personally my favorite of the series so far.
π¬ Jimmy Miller
Been working on the foundation of my new editor. I set a goal this year to use a text editor I built my self for 10% of my development. So I'm starting with some new foundations.
The most frustrating part of the my previous experience was the compile/run cycle for adding new UI. This time I'm starting with an extension mechanism that is powerful enough for me to prototype features live. But also, I want to be able to integrate extensions I made into the core of the program as things solidify.
To that end, I've prototyped a little wasm extension mechanism. It is still early, but I can hot relaod code while keeping state. I can save state and rehydrate. I even have plans for being able to do some time travel debugging/snapshotting. Right now the extensions can just do simple drawings and respond to clicks, but the foundation is there and I'm excited for it.
π¬ Jason Morris
This week I managed to release a new version for the first time in nearly two months. I took an unusual (for me) deliberate approach to testing my code as I expanded my date library into a datetime library, then added or modified about 15 blocks in the visual language, plus documentation and a new example. All so that I can say "within 72 hours of departure".
[x] Change Month and Week Number
[x] focWeekExport "2023-01-19" "2023-01-26"
[x] Update Search Index
[x] Download New Attachments
[x] Update links
[x] Check that comment links work (push weekly dump with channel summaries)
[x] Check to mention right person for moved messages
[x] Summary
[ ] Hashtags
[x] Set title in newsletter
https://tinyletter.com/
https://tinyletter.com/marianoguerra/letters/
http://localhost:8000/history/
https://marianoguerra.github.io/future-of-coding-weekly/
https://stackedit.io/app#