marianoguerra / future-of-coding-weekly

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

Future of Coding Weekly 2021/11 Week 4 #105

Closed marianoguerra closed 2 years ago

marianoguerra commented 2 years ago
marianoguerra commented 2 years ago

🧟 Immortal vs crash-only programs 🌜 Design of Lua πŸ”Œ PowerFX Open Source πŸ§‘β€πŸŽ¨ Sonic Wire Sculptor

πŸ₯³ 100 Issues

πŸ“’ We are working on Review Jam a week to experience some of the projects that appear on this newsletter and provide constructive feedback, check the site and subscribe to the mailing list to stay updated!

Two Minute Week

πŸŽ₯ New Feature: Chart from Group By with Card "Magic Wand" 🎩 via Mariano Guerra

🧡 conversation

Thumbnail

πŸͺ„ When selected it proposes all possible charts that can be created from the Group By's output

marianoguerra commented 2 years ago

πŸ“ Dynamically-sized types and almost-finished garbage collection via Alexey Shmalko

🧡 conversation

πŸ‘‹ Hi, all! This is my first post on Alpha here, so I want to establish a little bit of context. (The next posts will be shorter.)

Alphaβ€”a programming language for extensible systems (and hopefully malleable ones in the future). I imagine it as something in between of Julia, Emacs Lisp, and Smalltalk.

I’ve been working on it for a month now, so it’s still an infant. It has REPL, user-defined types, multi-methods, and a print function, but not much else 😁

So far it serves two purposes:

This week I was adding a garbage collector. It was tougher than I expected, but I got it working with the host language. The compiler still needs to be modified to produce the compatible code, so that’s the focus of the next week.

Here is a larger update for this week with memory layout images and some tips on debugging GC:

marianoguerra commented 2 years ago

πŸ’¬ Breck Yunits

🧡 conversation

Does anyone know examples (or name of the pattern) of markup formats where instead of writing format directives inline like this you do it out-of-the-line like:

text writing format directives inline like this

 bold like this
marianoguerra commented 2 years ago

πŸ’¬ Immortal programs vs crash-only programs by Kartik Agaram

🧡 conversation

In brief, immortal programs try to never, ever reboot. Crash-only programs are designed to always be able to recover gracefully from a reboot. There's a fundamental tension here, and I'm starting to realize I'm very definitely on one side of it. I like a neat desk, and am compulsively closing things (terminals, browser tabs, browser sessions) when I'm done with them. I prefer text editors to IDEs, vim to emacs, unix as my IDE rather than slime. I'd always thought of these as subjective opinions that were just down to my personality and past experience. But, upon reflection, I want to make a stronger case that "my side" is superior.

Putting these reasons together, immortal systems are more forbidding to newcomers. Crashing becomes a traumatic event, one newcomers are not used to, something beginner tutorials don't cover. When things don't work, it's more challenging to ask for help. Creating and sharing reproducible test cases requires crash-recovery skills.

Rereading the Pinocchio post now, I notice that there's actually no concrete benefits stated for long-lived programs. All there is are (compelling) analogies. A counter-analogy: an immortal program is like a spaceship. Once launched you're in a little bubble, stuck with whoever you happened to start out with. A crash-only program is like a little stone rolling down a hillside, gathering other stones until it turns into an avalanche.

As I said above, I'm biased because of my experiences. I'm curious to hear from others with more experience of immortal programs. Am I understating the benefits, overstating the drawbacks?

πŸ’¬ Paul Tarvydas:

🧡 conversation

I agree with your perspective, but I think that the Happy Path culture is more insidious than imagined. It deeply affects our tools and thought processes. Here are some of my thoughts... Failure Driven Design.

marianoguerra commented 2 years ago

Content

πŸ•ΈοΈ SNOB - A decentralized SPARQL query model for querying RDF data in a network of browsers via Sophie Smithburg

🧡 conversation

marianoguerra commented 2 years ago

πŸŒ› A Look at the Design of Lua via Kartik Agaram

🧡 conversation

I've been getting sucked hard into the Lua universe in recent weeks. Some links.

Introductory magazine article: A Look at the Design of Lua

Very cool technical paper on how they manage to implement an efficient interpreter and register-based VM in 12k LoC: The Implementation of Lua 5.0

A very interesting "federated monorepo" approach to a batteries-included Lua distribution: luapower.com. In particular check out luapower.com/philosophy. I particularly feel like the author and I were separated at birth for this passage:

NO [SUB-]DIRECTORIES

This may be a hard sell but I stand by it. [Sub-]directories are evil. Not so much because of semantics, but because of the tools we use suck at working with them. [No global overview;] instead you have to navigate them.

marianoguerra commented 2 years ago

πŸŽ₯ Primitive via Breck Yunits

🧡 conversation

These videos from Primitive (via @John Voorhees ) are amazing! Primitive Youtube Channel Feel like I've gotten a better sense of what the cutting edge of FoC in VR is in just a few minutes.

marianoguerra commented 2 years ago

πŸ§‘β€πŸ’» Power Fx: Open source now available via J. Ryan Stinnett

🧡 conversation

Microsoft's spreadsheet-like Power Fx formula language (which was mentioned here back in March) is now open source

marianoguerra commented 2 years ago

πŸ§‘β€πŸŽ¨ Sonic Wire Sculptor by Amit Pitaru via Mattia Fregola

🧡 conversation

Product: sonicwiresculptor.com

🐦 Amit Pitaru: From the archives Playing on the Sonic Wire Sculptor

[[SOUND ON]]

Tweet Thumbnail

marianoguerra commented 2 years ago

https://tinyletter.com/marianoguerra/letters/future-of-coding-weekly-2021-11-week-4