search

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 2022/10 Week 2 #155

Closed marianoguerra closed 1 year ago

marianoguerra commented 1 year ago
marianoguerra commented 1 year ago

💡 Formality Considered Harmful 🗃 Codebase as Database 🖊 Programmable Ink 📜 Future of Text

Our Work

🎥 Week 40: language, structural editor and cluster manager via Peter Saxton

🧵 conversation

This update covers the last couple of weeks of my language, structural editor, and now cluster manager.

There are 4 sections in this video but the last one is probably most interesting where I discuss type safe hot code reloading over a cluster

marianoguerra commented 1 year ago

💻 visualize the scores of your recent HackerNews posts in Ohayo via Breck Yunits

🧵 conversation

I made a program in my tree language Ohayo that let's you visualize the scores of your recent HackerNews posts

marianoguerra commented 1 year ago

Reading Together

📝 “First Steps Towards Inferential Programming” by Scherlis and Scott (1983) via Christopher Shank

🧵 conversation

Logics of programs, while they have contributed significantly to our understanding of individual programs and to our knowledge of programming language design, have had disappointingly little influence on the methods by which programs are constructed and documented in practice. The reason for this, we suspect, is that the understanding embodied in these systems deals with individual programs and does not directly address the process by which. programs are constructed. By focusing attention on this process, attempting to discern the fundamental steps in the evolution of programs, we propose that it may be possible lo develop a logical system- supported by an appropriate machine

environment--that will be more directly applicable to programming practice. The bencfits of such a point of view will be discussed.

marianoguerra commented 1 year ago

📚 Formality Considered Harmful: Experiences, Emerging Themes, and Directions on the Use of Formal Representations in Interactive Systems via Christopher Shank

🧵 conversation

“Formality Considered Harmful: Experiences, Emerging Themes, and Directions on the Use of Formal Representations in Interactive Systems” by Shipman and Marshall (1999)

In this paper, we describe how creators of systems that support intellectual work like design, writing, or organizing and interpreting information are particularly at risk of expecting too great a level of formality from their users. To understand the effects of imposing or requiring formality, we draw on our own experiences designing and using such systems.

marianoguerra commented 1 year ago

Content

📝 Codebase as Database: Turning the IDE Inside Out with Datalog via Srini K

🧵 conversation

marianoguerra commented 1 year ago

🚰 Build Streaming Data Pipelines Visually with Stream Designer via Mariano Guerra

🧵 conversation

Visual interface for building streaming data pipelines natively on Apache Kafka

Rapidly build, test, and deploy pipelines using a visual canvas extensible with SQL

marianoguerra commented 1 year ago

📝 latest FoC ep via Joshua Horowitz

🧵 conversation

I really appreciated the latest FoC ep about "The Structure of a Programming Language Revolution". I'm in The Academy, and I'm perpetually fascinated by what's happened to academic PL. This essay provided some missing links. Thanks Ivan Reese & Jimmy Miller!

One fun aha I had afterwards: The systems vs. languages distinction helps clear up something I've always wondered about prototypal object-oriented programming. Namely, why use prototypes at all? Rather than writing:

// Version A

function Dog () { }

Dog.prototype = {
  bark: function () { ... },
  fetch: function () { ... },
}

you could just write:

// Version B

function bark () { ... }
function fetch () { ... }

function Dog () {
  this.bark = bark;
  this.fetch = fetch;
}

Sure, maybe that's a hair less ergonomic. There's a (extremely tiny bit) more memory used to store the slots. But that hardly seems worth inventing a whole new language feature and making such a big deal about it.

I think part of the answer is that prototypal inheritance was born in Self, a programming system . If you want to modify a "prototype" in a programming language , the two approaches above are equivalent. You modify the (literal) prototype in version A, or you modify the constructor in version B, and then you re-run your code. But if you want to modify a "prototype" in a programming system , you'll discover you already have a bunch of instances of the class running around. Version B doesn't work, because it only changes how new instances are constructed, not how existing instances behave. A live connection between the instance and its prototype is required to enable live development in a living system.

I feel like Dan Brown over here, finding secret traces of the past in the present.

(Ominous hole in my theory: This doesn't explain why prototypes were brought into Javascript, where they ostensibly no longer had much use.)

marianoguerra commented 1 year ago

🐉 An Incremental Approach to Compiler Construction by Abdulaziz Ghuloum via Shubhadeep Roychowdhury

🧵 conversation

marianoguerra commented 1 year ago

🎥 "Programmable Ink" by Szymon Kaliski (Strange Loop 2022) via Mariano Guerra

🧵 conversation

Thumbnail

Sketching with pen & paper is a powerful way to think through ideas, but ink on paper is static. Dynamic behavior, on the other hand, requires programming -- which lacks the immediacy of the canvas: it's indirect, abstract, symbolic, and full of bureaucracy. What if we could harness the power of modern tablet computers to combine the intimacy of ink with the power of computation?

Note: Ivan Reese @Szymon Kaliski and Marcel Goethals were involved in this project and a new iteration has started with @Patrick Dubroy

marianoguerra commented 1 year ago

📜 Future of Text Volume | via Kartik Agaram

🧵 conversation

In the early to mid-1990’s, I was composing a document and needed to find and insert some information from another program. To do this, I had to leave my text editor, search for and launch another application, browse for the information I was looking for, format it appropriately for my source needs, and then switch back to where I was in my original text editor. All of this took minutes, and more importantly, took me out of the flow of what I was writing. There had to be a better way, I thought.

As a result, I devised what I called “The Invisible Interface”. The idea was to use the computer’s clipboard as an interpretable information bus for retrieving information I wanted without ever having to leave the application, or even the very text line, I was working on. As an example, I would type something like, “Please send the package to my sister’s address”. I would then select and copy to the clipboard the phrase “my sister’s address”, hit a function key to request processing, and I would instantly hear an audio cue: “bing” if successful, “bong” if the system was not able to resolve the phrase to more specific information. If I heard a “bing”, I would hit the paste command in my editor, and it would replace the selected text “my sister’s address” with “Sara Cheyer, 123 Main St. Town, State, 91101”. I connected a myriad of databases and information sources, and could instantly and painlessly retrieve all sorts of information by a concise, direct phrase inserted in-line in the context of what I was doing: “population of South America’s largest country”, “email for my boss”, “free time on Thursday”, “flower in French”, etc.

-- Adam Cheyer, "Interpretable and Executable text", in The Future of Text

marianoguerra commented 1 year ago

https://tinyletter.com/marianoguerra/letters/future-of-coding-weekly-2022-10-week-2