✉️ Not subscribed yet? Subscribe to the Newsletter

Future of Coding Weekly 2024/09 Week 2

2024-09-09 09:59

📢 PAINT & Causal Islands Berlin 💻 Decode: an augmented coding canvas 🎥 Roboco-op: mimetic engineering

Two Minute Week

💬 Marek Rogalski

🧵 conversation

Working on performance improvements now. Getting some nice visual effects thanks to uninitialized memory.

Our Work

🧑‍🔬 Account of the research project we’re doing at JetBrains by Pavel Mikhailovskii

🧵 conversation

Hi everyone!

I’d like to give an account of the research project we’re doing at JetBrains.

It is called Ludwig after Ludwig Wittgenstein and has an ambitious goal of re-engineering the foundations of the software development stack.

At the moment, we are still at a very early design and prototyping stage, but we believe that this project will let us create the next generation of development tools.

Here are the most important ideas we’re trying to materialize:

Liberation of code from the shackles of textual representation

Human-readable textual notations were a great innovation back in the 1950s. However, we have made great progress in the ways we store complex data structures since then, and the typical codebase sizes have also grown by a few orders of magnitude.

Code is essentially a graph with one tree-like perspective more important than others. An adequate way of storing such complex and evolving data as code would be to put it in a versioned graph / linked document database, supporting Git-like branching and merging. That would get rid of the need for continuous parsing, indexing, symbol resolution and typechecking that constitute the code editing workflow in modern IDEs. We would resolve symbols once, at the moment of typing and store their unique identifiers (not just names!) in an indexed by construction and preserving referential integrity database.

That would also make such intentions as Rename, Move, Find Usages or Go To Definition trivial to implement. Of course, structural representation of code will come hand-in-hand with structural (semantic) diff and merge.

This graph-like representation should allow for a fine-grained tracking of changes and dependencies and dramatically reduce feedback times in such scenarios as incremental compilation.

A minimalist approach towards programming language design

To prevent our language from becoming “fat and weak” as John Backus has put it in his famous lecture, we want to pass our language through a series of aggressive optimization rounds or distillation passes.

This should result in something comparable with Smalltalk’s “syntax on a postcard”. Actually, we believe that we could make it even more symmetric by eliminating the distinctions between methods, named and anonymous functions, operators and statements. (As you know, Smalltalk has different syntaxes and different behavior of return statements for methods and blocks and “surprising” execution order rules for different kinds of messages).

The goal is to come up with a language that would be easy to learn and read and straightforward to reason about for all kinds of agents-be it humans, static analysis tools or AI.

In terms of notation, it will look like an indentation-based syntax for a tiny subset of Lisp, but without its macros or the zoo of “special forms”. Being freed from the limitations of plain text, we’re going to use semantic coloring to make the notation even more expressive and compact.

Obviously, our programming language, as any other, should be able to express computation logic and code structure; what is less common is that we also want it to be able to express data, configurations and knowledge, thus eliminating the need for additional DSLs. A YAML-like data notation emerges from our tiny language as naturally as JSON emerged from JavaScript. The only difference is that JSON was discovered by chance, and our language is consciously designed to be able to declaratively describe complex data structures.

Unification of Object-Oriented and Functional programming

As a part of our minimalist program, we are aiming to heal the great schism that divided programming into the object-oriented and the functional worlds.

We believe that the class-free approach in the form proposed by Douglas Crockford will let us make OOP an integral part of functional programming, thus converging the two into what could be called unified programming. This form of OOP will keep the best parts—encapsulation and polymorphism and get rid of the "considered harmful" implementation inheritance. There will be no need for classes, constructors, prototypes, visibility modifiers, this and new - just immutable structures and anonymous functions.

An IDE designed for focus and context awareness

We want to build an immersive Smalltalk-like environment with structural navigation, a smaller editing scope and richer and more dynamic context compared to the traditional file- and text-based IDEs. This seems well-aligned with both the minimalist design of the language and the non-textual storage format. The latter should allow us to store some additional information alongside the code. That will include all kinds of metadata, normally invisible to the users, but also some unusual forms of embedded content. Think of a documentation comment containing a video explaining the algorithm or a discussion between multiple developers linked to a certain place in the code.

Smart typing

We also have some ideas on how we could implement some smart typing techniques, combining the convenience of automatic type inference with the solidness and discipline of explicit type annotations.

The key idea is that the flexibility of the non-textual representation will eliminate the need for the user to choose between the two worlds. Manual annotations can be hidden to reduce visual distraction, automatically inferred types can be displayed and persisted in the code database, etc.

Designed to be AI-fitting

Finally, we want the whole thing to be future-proof and provide better support for AI-aided development compared to the traditional languages. The simplicity of the language as well as its fine granularity and its property of always having all the symbols resolved should allow for high-quality “understanding” and retrieval-augmented generation of code compared to such languages as Python or Java.


As I said, at the moment we’re still at a very early stage. Many of our challenges are not technical, but about finding the way of how we could shape this set of ideas into a product vision. We are, of course, open to collaboration with like-minded people.

I will be happy to answer your questions and hear your feedback.

🎥 code::dive 2017 – Douglas Crockford – The better parts

code::dive 2017 – Douglas Crockford – The better parts

💬 Jarno Montonen

🧵 conversation

Added tabular data and document template import to my notebook demo so now it can be used to fill/generate documents from csv/spreadsheet rows. Would any of you find something like this useful? I know there are a bunch of document generators, but the ones I've seen seem kinda crappy. Happy to hear about experiences using any of the existing solutions and why they suck though 😆.

🎥 Document Generation

📝 About - The Parallel Reality Computer via Duncan Cragg

🧵 conversation

Hiya folks, now that many of you have been digging in to Dynamicland's website for a bit and are in the right frame of mind, I was hoping that you may have had your neurons tickled in just the right ways to be open to reading about a project with some similarities: mine! 🤗

So I updated my About page, and I was hoping that it's now short and accessible enough to be just the info needed for you to "get" what my project is all about:

📝 About - The Parallel Reality Computer

💬 Kartik Agaram

🧵 conversation

Still lots missing, but check this out.

Lol, look at how it renders hyperlinks. This isn't going to be useful without some sort of delimiter or fence around math.

fractions-bug.png

Thinking Together

🪼 Physics of JellyCar: Soft Body Physics Explained via Christopher Shank

🧵 conversation

Youtube Thumbnail

What are ways we can make computation more squishy with soft-body physics? Most visual notations are overwhelmingly rigid and structured!

Content

💻 Decode via Ivan Reese

🧵 conversation

Decode — a new tldraw-based augmented coding canvas tool from @Francois Laberge

📝 Situated Computations: Bridging Craft and Computation in the Trinidad and Tobago Carnival via Jasmine Otto

🧵 conversation

a paper from an architectural journal that combines an ethnography with a sculptural grammar ('situated computations').

🧦 dynamicland.org via Alex McLean

🧵 conversation

I hear dynamicland.org will update sometime today..

💡 Donate to dynamicland via Ivan Reese

🧵 conversation

Somewhat buried in the new DL webpage — you can now directly donate to support their work. This is absolutely the sort of thing I'd back on Patreon, so I'm glad to see they offer those sorts of $n/month options.

📝 The Canary via Kartik Agaram

🧵 conversation

No coding here, but this is fantastic.

The Canary

And yet even now his father hovered in the background both as a rhyme and a presence. The careers of both men had been redirected by a simple question posed in a college class. Both spent their lives measuring the stress in stone. Both used scientific methods to answer questions that had seemed to everyone else beyond the reach of science. Both sought to understand what prevented roofs from collapsing. The father’s work had received a lot of public attention and the son’s had not. But that was just an accident of what people cared about. A lot of people cared about Gothic cathedrals; fewer were concerned with whatever was happening to workers deep underground.

📢 PAINT: Programming Abstractions and Interactive Notations, Tools, and Environments via Beni Cherniavsky-Paskin

🧵 conversation

Looking at SPLASH '24 program, I knew LIVE workshop is always very relevant (this year majority of lectures involve folks here); but also found PAINT which sounds great too 👀

In the workshop on Programming Abstractions and Interactive Notations, Tools, and Environments (PAINT), we want to discuss programming environments that support users in working with and creating notations and abstractions that matter to them. We are interested in the relationship between people centric notations and general-purpose programming languages and environments. How do we reflect the various experiences, needs, and priorities of the many people involved in programming — whether they call it that or not?

Areas of interest to PAINT include but are not limited to:

  • Design and implementation of program representations and their means of interaction for end-users of all ages
  • Design and implementation of visual programming environments
  • Block-based environments and their application
  • Projectional editors and their application
  • Languages and their environments with mixed notations
  • Meta tools or tool creation frameworks
  • Methods to support working with abstractions, such as example-based programming
  • Input and output devices for interacting with programming environments
  • Theories of the above

PAINT format is flipped, kinda critical review, and not recorded IIUC. But the past papers look interesting.

📝 A note on the PERQ computer via Ivan Reese

🧵 conversation

A fun little rollercoaster of computing history shared in this short blog post by Graydon Hoare, looking at the lesser known Xerox Alto descendant, the PERQ.

📢 Causal Islands Berlin via Orion Reed

🧵 conversation

The Causal Islands Berlin conference (organised by me, Boris Mann, and Jack Rusher) is happening next month (Oct 4 & 5). Would love to see some of you there. It'll be quite small (100-ish capacity) but loaded with great talks and conversations. We'll also be doing a more full-size conference in May next year. The vibes are "future of computing" and "spiritual successor to Strange Loop" with a more socio-political bent.

Also, there is a CfP up if you want to submit a presentation!

🧑‍💻 To Write Code: The Cultural Fabrication of Programming Notation and Practice via Joel Chan

🧵 conversation

greetings! am thoroughly enjoying the latest podcast episode on agentsheets, and the discussion of “is programming a Language(TM)” and the history of how it came to be that programming was considered language in the sense of “has a formal grammar” reminded me of this paper by Ian Arawjo on the history of programming notation and its cultural referents (e.g., typewriters, and how it moved away from more “visual” forms and converged around “programming as typing on a typewriter”: To Write Code: The Cultural Fabrication of Programming Notation and Practice

i found the resulting frame of programming as translation work of “mapping one culture to another” provocative too!

CleanShot 2024-09-07 at 14.41.31@2x.png

CleanShot 2024-09-07 at 14.43.59@2x.png

🤖

💬 Nilesh Trivedi

🧵 conversation

TIL:

image.png

image.png

🎥 Roboco-op explainer via Tom Larkworthy

🧵 conversation

Youtube Thumbnail

I thought I had shared roboco-op here but it seems I had not. The idea is to mix code/runtime/chat context into a single materialised human editable representation to enable "mimetic engineering". Copy and pasting "skills" between notebooks and therefore engineering the AIs context to suit the task at hand, all while having a machine checked code based conversation (I demoed this at Berlin's GenAI meetup) withou context switches.


👨🏽‍💻 By 🐘 @marianoguerra@hachyderm.io 🐦 @warianoguerra

💬 Not a member yet? Check the Future of Coding Community

✉️ Not subscribed yet? Subscribe to the Newsletter / Archive / RSS

🎙️ Prefer podcasts? check the Future of Coding Podcast

Future of Coding Weekly 2024/09 Week 1

2024-09-02 10:19

🎙️ FoC 73 • Moving Beyond Syntax 📢 Onward! and LIVE Papers Announced 🧦 Hypercard in the World

Two Minute Week

💬 Karl Svartholm

🧵 conversation

Trying to make Duplo more interesting... So far it is working (probably), seem to have encouraged my daughter to learn to stack two pieces together! 😃

Actually the next step after a fanfare is probably (not the stars but) to have pieces make different sounds and/or beats depending on sensors (ex sensing colors, stacking, proximity or sound) — a music machine. Perhaps more important: a programmer base plate; where you stack pieces & program them (from ex Arduino studio, for now). Inter-piece communication could also be interesting? Ideas?

🎥 Video 1

🎥 Video 2

IMG_20240826_084224.jpg

Our Work

🎙️ Future of Coding 73 • Moving Beyond Syntax: Lessons from 20 Years of Blocks Programming in AgentSheets by Alexander Repenning via Ivan Reese

🧵 conversation

Finally, a title with appropriate length given the duration and depth of its episode. May it swiftly be surpassed.

Alexander Repenning created AgentSheets, an environment to help kids develop computational thinking skills. It wrapped an unusual computational model with an even more unusual user interface. The result was divisive. It inspired so many other projects, whilst being rejected at every turn and failing to catch on the way Scratch later did. So in 2017, Repenning published this obit of a paper, Moving Beyond Syntax: Lessons from 20 Years of Blocks Programming in AgentSheets, which covers his findings over the years as AgentSheets evolved and transformed, and gives perspective on block-based programming, programming-by-example, agents / rule / rewrite systems, automata, and more.

This is probably the most “normal” episode we’ve done in a while — we stay close to the text and un-clam many a thought-tickling pearl. I’m saying that sincerely now to throw you off our scent the next time we get totally lost in the weeds. I hear a clock ticking.

🤔 Bloquecitos: the ultimate visual programming language via Mariano Guerra

🧵 conversation

Inspired by the podcast episode above I created bloquecitos: the ultimate visual programming language

Try it here: marianoguerra.github.io/experiments/bloquecitos

🎥 Bloquecitos Demo

Devlog Together

💬 Kartik Agaram

🧵 conversation

Leveling up goals: a shower thought

Reading Together

📝 BDI Agents: From Theory to Practice via Nilesh Trivedi

🧵 conversation

LLMs are forcing me to think about non-deterministic yet rational "computation".

Agents are beyond what traditionally computation has been. When an agent starts performing a task, and the environment changes, they need to find the balance between too much rethinking (classical decision theory) and not enough rethinking (computation).

image.png

Thinking Together

💬 Guyren Howe

🧵 conversation

I just had a thought.

Is anyone aware of any work on a non-programmer-friendly UI for editing pattern matching? Semantically, I’m looking for Datalog. So I guess a Datalog query UI, although I could imagine a pattern matching UI being developed outside of a use with Datalog.

💬 Paul Tarvydas

🧵 conversation

I’m trying to figure out why you (Ivan Reese) think that using OhmJS to produce the wiki would create a dependency, while I (Paul Tarvydas) don’t think so. Here’s a diagram of how I understand the situation...

tonedown.png

💬 Nilesh Trivedi

🧵 conversation

I've been thinking about how neurosymbolic AI might be achieved. The first problem is that of memory/knowledge. Triple stores are often recommended. But I am failing to see how triples are THE definitive choice for knowledge representation.

The classic example would be: How to store the fact "Bob's age is 23yrs". This maps to the Entity-Attribute-Value or Subject-Predicate-Object pattern and the triple (Bob, age, 23yrs) works.

But on one hand, even a 2-store can be used:

(Bob, Bob's age)

(Bob's age, 23yrs)

This has more layers of indirections, yes. But the primitives become simpler.

On the other hand, if the fact was "Bob bought this camera in Singapore for 100$", the same layers of indirections show up in triple stores as well.

Arbitrary knowledge seems multidimensional (time, place, context etc etc). Is there a reason to believe that triple stores achieve the best tradeoff between simplicity and expressivity?

📝 0048: zest progress, zest ordering, wasm alignment, umbra papers, future of fast code, new internet, books, other stuff via Jamie Brandon

🧵 conversation

Does anyone have thoughts about equality vs ordering in maps/sets?

I have some pondering here - scattered-thoughts.net/log/0048/#zest-ordering but the decision tree at the end is the main thing:

  • Order isn't observable at all.
  • Iteration order is either non-deterministic or expensive.
  • Determism can be manually recovered by storing both a map and a list of keys, but at the cost of storing two copies of each key.
  • Order is observable.
  • Order doesn't affect equality.

  • Equality is not extensional ie a == b does not imply that f(a) == f(b) .

  • If [a: 0, b: 1] == [b: 1, a: 0] then we must have struct[a: i64, b: i64] == struct[b: i64, a: i64] , but we still have to remember that the field order is different, which implies that type equality can't rely on interning and pointer comparison.

  • Order affects equality.

  • Sets become surprising / less useful.

  • If I want to add query planning, I can't promise that f(db) == optimize-query(f)(db) .

Content

💡 SPLASH 2024 - Onward! Essays - SPLASH 2024 via Konrad Hinsen

🧵 conversation

The accepted contributions to Onward! Essays and Onward! papers have been announced. Many of the titles/abstracts sound very relevant for our community. And three essays have authors from FoC.

🎥 Capt. Grace Hopper on Future Possibilities: Data, Hardware, Software, and People (Part One, 1982) via Paul Tarvydas

🧵 conversation

Youtube Thumbnail

Capt. Grace Hopper on Future Possibilities: Data, Hardware, Software, and People, 1982

  • Part One * youtube.com/watch?v=si9iqF5uTFk&t=1s

  • 20:58 - We’ve Always Done It This Way *

  • 47:10 - Systems Of Computers, Not Bigger Computers *

  • 48:00 - Get Out Of The Plane Of Paper *

  • Part Two * youtube.com/watch?v=AW7ZHpKuqZg

  • 0:00 - Security *

  • 8:42 - Bloatware *

  • 9:57 - 2FA *

  • 12:12 - Specialized Machines Are Faster Than General Purpose Machines *

  • 12:59 -We Have To Overcome The Concept Of Only One Computer *

  • 14:58 - Dependency Analysis *

  • 18:53 - Use independent modules *

  • 22:15 - Advocate the use of standard high level languages *

  • 27:19 - Buying Computer Time *

  • 34:49 - Management vs. Leadership *

my thoughts on the above issues

🧦🎥 Hypercard in the World, May 2016 via Lu Wilson

🧵 conversation

Youtube Thumbnail

Just in case you missed it

🎥 Subtext 1 via Kartik Agaram

🧵 conversation

Vimeo Thumbnail

I had no idea Jonathan Edwards's landmark Subtext is almost 20 years old.

Subtext 1 (2005) is still hugely compelling. I hadn't watched this until today. If you're like me, you're in for a treat.

This work predates Bret Victor's "Inventing on Principle" by 7 years!

📑 Workshop on Live Programming (LIVE) via Maikel van de Lisdonk

🧵 conversation

The accepted list of papers for liveprog can be seen here liveprog.org and I notice that FoC is very well represented by quite some folks from this community, very nice! 😎

🤖

💬 Nilesh Trivedi

🧵 conversation

The holy grail of AI. Any thoughts on how this kind of integration can be achieved?

image.png

Present Company

🔠 Departure Mono via Christopher Shank

🧵 conversation

DEPARTURE MONO IS A MONOSPACED PIXEL FONT WITH A LO-FI TECHNICAL VIBE

🎥 Virtual Meetup 4 • August 28, 2024 via Ivan Reese

🧵 conversation

Youtube Thumbnail

Here's the recording of the Future of Coding Virtual Meetup 4. We saw a textual projectional editor from @Jarno Montonen, an Observable-based exploration of visualizations from Tom Larkworthy, and I shared an update on the FoC Wiki.

Next month, rather than demos, we're going to host a little event where we all get together on a call and write wiki articles. Should be fun, likely chaotic. See you there!


👨🏽‍💻 By 🐘 @marianoguerra@hachyderm.io 🐦 @warianoguerra

💬 Not a member yet? Check the Future of Coding Community

✉️ Not subscribed yet? Subscribe to the Newsletter / Archive / RSS

🎙️ Prefer podcasts? check the Future of Coding Podcast

Future of Coding Weekly 2024/08 Week 4

2024-08-25 23:01

🧮 Scrapsheets demo 🎥 Why Star Trek's Graphic Design Makes Sense 🔌 Visual Neural Networks

Two Minute Week

🔌🎥 Neural network training using mnist dataset in code-flow-canvas via Maikel van de Lisdonk

🧵 conversation

Youtube Thumbnail

After lots of reading (books and other people's code), watching video's, thinking, asking chatgpt for help (it needed help itself), experimenting and frustration, I finally managed to get a neural network working including the training using backward propagation, in my visual programming system!! You can see a small video where I demo it here

The results are far from perfect and neither is the visual flow itself. Currently I only used a subset of mnist to train (9000 images) and on every training iteration the weights are updated per training image. Also the network can for sure be improvement by using a different layer setup and configuration parameters (different learning rate and activation / cost functions). From a visual programming perspective there are also lots of things to improve: currently a lot of the needed functionality is inside the nodes instead of being visible in the flow. So the neural and training nodes are black boxes as well as the node that loads the mnist dataset and handles some of the logic in the training proces. I want to change this in the near future though. You currently can't even see the resulting weights and biases.

Hopefully it is clear from the neural node types how the neural network is structured: it shows the number of nodes in the layer and an icon illustrating whether a node represents an input, hidden or output layer.

In the video I show a slow and fast run of the training proces: by putting the speed slider to the right you can run the flow without animations otherwise it takes too long.

There's also a custom node type that can be used to draw a digit manually and provide the digit which the drawing represents for purpose of calculating the error cost/loss.

Anyway, for now I am happy with the result. More to follow in the future :-)

💬 Marek Rogalski

🧵 conversation

They may be totally invisible in the video but objects in Automat now drop shadows! They're drawn using fairly sophisticated procedures that were developed a copule of years ago for Google's Material Design system. Each object actually drops two different shadows - one coming from environmental light (a.k.a. ambient occlusion) and one from directional light (which is modelled as a disk with the same width as window and is positioned in 3d space roughly in front of the title bar). The cool thing about those shadows is that they're not using either shadow maps nor gaussian blurs (except concave shapes). The library takes some shape (vector contour of the object dropping shadow) + parameters of the light and computes a physically based analytical shadow mesh that is then drawn in the background. This manages to render fairly realistic shadows even while elevation of objects is being dynamically changed.

🎥 Demo

Our Work

📝 Call Return Spaghetti by Paul Tarvydas

🧵 conversation

In the essay referenced below, I examine why a diagram of a Call/Return system makes less sense than a diagram of a concurrent system.

Call/Return operates in a LIFO - last-in first-out, stack-like - manner.

Adopting an alternate perspective - FIFO, first-in first-out, queue-like manner - allows us to represent diagrams more easily.

CPU chips implement CALL and RETURN instructions as single opcodes, but, they do not implement queue behaviour as single opcodes.

Most popular languages are generally function-based, e.g. C, Haskell, Python, Javascript, Smalltalk, etc. Such function-based languages tend to adopt a LIFO (callstack) perspective and tend to use CALL and RETURN opcodes to fake out the function-based paradigm.

Such languages allow programmers to implement FIFO queues, but, such languages encourage the use of LIFO stacks. This seemingly small difference subtly affects designs with function-based - stack-based - thinking. This difference ultimately encourages single-threaded design while making multi-threaded design more difficult to imagine and to implement, as witnessed by the fact that most languages relegate multi-threading to hefty code libraries, while treating functions as basic building blocks.

This subtle encouragement towards function-based thinking has led to the general impression that Visual Programming Languages (VPLs), node-and-wire Diagrammatic Programming Languages (DPLs), Actors, etc., are ineffective programming tools.

I argue that VPLs, DPLs, Actors, etc. are effective programming tools, but that their use is are ultimately discouraged by the over-use of the function-based paradigm.

Further

💻 Tensort via Kyle Beechly

🧵 conversation

I just published Tensort, a family of sorting algorithms (slash research paper?) inspired by Ivan's remark near the end of Beyond Efficiency by Dave Ackley about Robustsort not existing yet. I'd love to hear what y'all think! 💙

📼 Bootstrapping OOP Part 3: Who Parses the Parser? via Mariano Guerra

🧵 conversation

How do we feed the prelude if there's no parser (yet)?

💡 If code is data then a data serialization format is a binary representation of a program

Devlog Together

💬 Kartik Agaram

🧵 conversation

Getting ready for Slack apocalypse.

motd.png

🔌🎥 Improved neural network layer node visualization in code flow canvas. via Maikel van de Lisdonk

🧵 conversation

Youtube Thumbnail

I've made some visualization improvements for the neural network layer nodes in my visual programming system "code flow canvas". Nodes can now have meta information to show internal data which is stored on the node level that is not shown on the node itself. For the neural network nodes this are the weights and biases.

Also the structure of the neural network itself can be viewed in a scalable way instead of just the nodes on the canvas itself. And with scalable I mean not showing all the nodes, but only a max of 10 per layer and add smaller dots in between to illustrate that there are more nodes then just the max 10 that are shown per layer. The number of dots are different depending on the total node count to make it clear that layers differ in total node count.

You can see it here or try it yourself at demo.codeflowcanvas.io and select the neural network mnist training & testing example.

Thinking Together

💬 Yuriy Zymlex

🧵 conversation

I have a few questions/topics about which I would like to get your opinion. Since I'm interested in the underlying logic of this things, this may look banal.

If the essence of every programming language is the construction of logic , have there ever been any attempts to bring that process __ into minimal separate entity for purpose of wider use than just programming?

By purposes, I mean the creation of:

  • Text instructions - as you can see them in Jira, Org-Mode, Markdown (or detailed program's log)
  • Graphical - MindMap or here it is good to remember "data flow diagrams" from informatics, but it can be expanded to any other kind
  • Actually programming itself, but as building any "pseudo" code (including graphical) for convenient use with a theoretical possibility of converting "pseudo" code back to logic
  • ... (other variants)

Content

🧮🎥 scrapsheets splash demo via Kartik Agaram

🧵 conversation

Youtube Thumbnail

Demo of a spreadsheet-like tool. To be presented at SPLASH? By @Taylor Troesh.

🎥 Why Star Trek's Graphic Design Makes Sense via Stefan Lesser

🧵 conversation

Youtube Thumbnail

YouTube served this older video to me, but I couldn’t help noticing a few things in relation to (the future of) coding:

  • All the models and (fake screens) etc. are now considered art, but they weren’t created as art. They were functional props on a movie/TV show set put together under tight timelines. How often do we put together functional code under tight deadlines? And how often is what we do regarded as art later? Almost never, I reckon.
  • His expertise: When he talks about smoked acrylic and how almost everybody doesn’t listen to him because “You’re losing light", even though he clearly knows exactly what he’s talking about, that reminds me of about a million conversations about how some clearly less experienced engineer tells an experienced veteran why their code isn’t good.
  • Oh, the pragmatism! The ship models? Hacked together from repurposing strange parts they had lying around. The details? Just enough to make it look great. The blinking buttons interface? Just a few lightbulbs behind the buttons that were supposed to blink. If that doesn’t remind you of software development, you’re not doing it right. Or you are, and that’s part of the problem. 😉
  • I know, there’s some physicality to all the examples in the video, but the LCARS interface points to the possibility of designing something in software only that can transcend its functional framing and become more than just a prop. We have a few examples of that in software (“You had me at scrolling”), but not nearly as much as we should have, I think.

Where are the videos like this that celebrate achievements in software design?

📝 The Competing Predictions of Edsger Dijkstra and Douglas Engelbart via Kartik Agaram

🧵 conversation

He who would do good to another must do it in minute particulars General Good is the plea of the scoundrel, hypocrite and flatterer For Art and Science cannot exist but in minutely organised particulars -- William Blake


👨🏽‍💻 By 🐘 @marianoguerra@hachyderm.io 🐦 @warianoguerra

💬 Not a member yet? Check the Future of Coding Community

✉️ Not subscribed yet? Subscribe to the Newsletter / Archive / RSS

🎙️ Prefer podcasts? check the Future of Coding Podcast

Contents © 2024 Mariano Guerra - Powered by Nikola