search

marianoguerra / future-of-coding-weekly

repository to work on future of coding weekly newsletter
https://tinyletter.com/marianoguerra/
33 stars 3 forks source link

Future of Coding Weekly 2024/05 Week 4 #249

Closed marianoguerra closed 1 month ago

marianoguerra commented 1 month ago
marianoguerra commented 1 month ago

📡 Propagator Networks 🌯 Visual Language for Polymorphic Types 🤨 NoCode Will Not Bring Computing to the Masses

Two Minute Week

🐚 Automat via Marek Rogalski

🧵 conversation

Context: Automat aims to be a general purpose visual shell - it's meant to control other apps & pass their data around. It has a website at automat.org. The MVP version is going to record & replay desktop macros. Last week I've pretty much finished the work on connections and now I'm working on the new timeline object!

Automat is a FOSS software that allows anyone to control their computers by combining interactive blocks.

🐦 Marek Rogalski (@mafikpl) on X: Working on the most complex Automat object so far - the Timeline. It should be able to control other objects according to its embedded tracks.

Tweet Thumbnail

marianoguerra commented 1 month ago

🎥 PID controller build with codeflowcanvas via Maikel van de Lisdonk

🧵 conversation

Youtube Thumbnail

In this video I show a PID-controller build with my visual programming system codeflowcanvas.io ... the PID-controller example can be found on demo.codeflowcanvas.io.

It uses expression nodes, global variables and flow-variables to handle the calculations and state. In a bar-chart the output of the mechanism can be seen. In this example the target value is 100 , and when moving the input value slider, that value is used as a measurement and the algorithm brings the measurement to the wanted value (100). This process is visualised in the bar-chart.

When the speed of the flow is set to maximum (in the top left corner), the "program-counter"-animation is not shown and it runs as fast as it can in realtime. That helps for these kind of algorithms.

marianoguerra commented 1 month ago

Our Work

📡 Propagator Networks via Dennis Hansen

🧵 conversation

Hello! So after much obsession with Propagator Networks as discussed on this slack 💬 #thinking-together@2024-03-21, i decided to make a little propagator network simulator on top of tldraw.

In short: Propagator networks enabling bi-directional computation via independently operating nodes- in the gif you can see one for converting temperatures. Propagators (squares) listen to changing inputs, run code, and update connected outputs.

You can make your own here.

There's lot of awesome stuff than can be made with these (maybe everything?). If you want to have fun with it, try to make a conditional or a switch. Its fun 🙂

Cheers!

ezgif-2-f1371da04b.gif

marianoguerra commented 1 month ago

💬 Kartik Agaram

🧵 conversation

🧵 for Cole Lawrence's demo today.

marianoguerra commented 1 month ago

💬 Mariano Guerra

🧵 conversation

🧵 for Maikel van de Lisdonk's demo today.

marianoguerra commented 1 month ago

💬 Mariano Guerra

🧵 conversation

forgot to share this in the demo

gloodata-inception.gif

marianoguerra commented 1 month ago

Devlog Together

🤖 github.com/nileshtrivedi/autogen via Nilesh Trivedi

🧵 conversation

I have started porting Microsoft's multi-agent framework "autogen" to Elixir: github.com/nileshtrivedi/autogen

Got basic multi-agent collaboration and code execution working. Now need to make Elixir functions available to agents as tools.

I feel Elixir will become more and more important for AI because of its excellent support for real-time communication (audio/video etc), and single-language stack (LiveView etc.)

marianoguerra commented 1 month ago

Reading Together

🌯 GeckoGraph: A Visual Language for Polymorphic Types via Don Abrams

🧵 conversation

Beautiful study on a visual representation of abstract types (Haskell in this case but generalizable). Conclusion: intuitive and helpful for beginners, but distracting GeckoGraph: A Visual Language for Polymorphic Types

marianoguerra commented 1 month ago

Thinking Together

💬 Stefan Lesser

🧵 conversation

This is one of those questions where I don’t really know yet how to ask it, so let me fumble and handwave a little bit and see where this goes:

In computing history we went from printers to screens, and on those screens from a brief stint with vector graphics to bitmap displays, and on those bitmap displays from text mode to frame buffer, and in those frame buffers from sprites and blitting to rasterization and compositing. In the early days, when there wasn’t enough RAM for a full-screen bitmap frame buffer, character glyphs and sprites were brought in from ROM. Now we have so much memory that we have double-/triple-buffering and realtime compositing of separately stored textures that often exceed the number of screen pixels available by an order of magnitude or more.

I’m particularly interested in the early transition to raster graphics. At some point (and I assume that was probably with PostScript?) it became feasible to compute graphics on the fly instead of having them prepared as bitmaps in ROM or on disk. If I remember this correctly, PostScript was invented because due to the different font sizes it was more economical to ship instructions to generate glyphs on the fly on the printer than to ship all possible glyphs as bitmaps in all the different font sizes.

In a way we went from a “final” representation of a map of bits restricted to a certain grid size to an “intermediate” representation of instructions that have to be executed to generate the final map of bits in the desired size. Alternatively, we could see that as swapping space (memory) for time (compute).

Are you aware of any papers or other material that compares both sides of this transition?

For instance in terms of performance in space and time, ie. how much compute is needed for how much memory saved. Or in the broader sense of how we settled on certain graphics primitives, because they were cheap enough to implement in terms of compute, and how we settled on certain data formats, because they were small enough in terms of memory usage, so that this trade-off made sense.

marianoguerra commented 1 month ago

🎥 Grail Demo from CHM tape via Oleksandr Kryvonos

🧵 conversation

Youtube Thumbnail

Does anyone know if there is somewhere a new implementation of something similar to GRAIL system from Rand corporation ?

marianoguerra commented 1 month ago

Content

🕸️ Dify's new workflows feature via John Choi

🧵 conversation

Has anyone tried using Dify's new workflows feature?

It seems to be a Node-RED-like visual programming tool that supports Python/Node scripting in addition to HTTP requests and LLM invocations for nodes.

(The parent app (Dify) is clearly positioned in the AI domain, but the workflows feature seems pretty general.)

I'm looking into it but also interested in hearing others' initial impressions/assessments of limitations 👀

marianoguerra commented 1 month ago

🤨 NoCode Will Not Bring Computing to the Masses via Mariano Guerra

🧵 conversation

It's not enough for a tool to solve your problem for you to use that tool. You have to also A) recognize the problem you have is solvable, B) recognize the tool can solve it, and C) be reasonably confident that you personally can solve the problem with the tool. You need knowledge, skill, and the right mentality. Even programmers, who already have that mentality, don't automatically generalize it to all applicable domains. Otherwise we'd be doing a lot more with our phones.

It's unreasonable to expect the average person will use any NoCode to solve their problems, regardless of how easy the tools are. This leaves the people for whom it provides economic value, which is why all modern NoCode tools are oriented towards business.

marianoguerra commented 1 month ago

📝 FORTRAN Report 1954 via Marcel Weiher

🧵 conversation

And of course “no code” and “lo code” are just new versions of “code”. Well, the ones that work at least.

My favorite quote on this topic encapsulates it nicely: “Since FORTRAN should virtually eliminate coding and debugging…” — FORTRAN Report 1954