Future of Coding is an online community with a welcoming, cooperative, and revolutionary spirit. We are unified in the belief that the common practice of programming is tragically less humane than it could be.

Future of Coding

Hi!

it's been a long time since I posted in this group (almost 5 years, wow!). Life changed on my side (working full-time jobs, having kids, ...) but I still tried to follow what's going on occasionally. Thanks a lot to <@UBN9AFS0N> for the newsletter, it's the perfect digest for me to read whenever I have some spare time.

I've recently started using <https://obsidian.md/|Obsidian> and it's working great for me to collect and organize all kinds of thoughts. I've used quite a few tools for this over the years, but Obsidian is my new favorite. I'm sure it's been discussed here already, but here's what I love about it:
• based on markdown files instead of some proprietary formats
• great apps for desktop and mobile
• effortless e2e-encrypted sync between devices
• linking between files / pages and following those links is easy. I'm using a variation of a <https://zettelkasten.de/introduction/|Zettelkasten> (<https://obsidian.rocks/getting-started-with-zettelkasten-in-obsidian/#My-Process-for-Zettelkasten-in-Obsidian|this link> can be useful as a starting point; I can write about my approach if there's interest in it)
I'm currently trying to collect my FoC ideas, projects and thoughts into my Obsidian and therefore wanted to see my contributions to this community. I used the <http://akkartik.name/archives/foc/|Archive> tool by <@UCUSW7WVD> and it's been working great. A simple long webpage and Ctrl-F worked beautifully, probably better than what Slack Pro could have given me. Thanks a lot for creating the archive, Kartik!

Going back in time was very interesting. One thing I noticed though was that quite a few links that we discussed at the time sadly don't work anymore. With the help of the <https://web.archive.org/|wayback machine>, I was able to still access all the info though. This made me once again appreciate the wayback machine and its importance for the internet. Feels like a donation to the project is overdue.

That's all I wanted to share. Have a great day folks :)

I've been thinking about color, and I don't know anything about it.

I'd really like my hypertext browser to allow people to adjust color, but without ever compromising contrast. Is there some color space/model like rgb/hsl/CIELAB/Lch that allows you to adjust an _author foreground_ color relative to an _author background_ color, yielding new reader foreground and background colors that maintain the original level of contrast? Ideally I want a single spectrum/dimension/knob that I can adjust to change the hues of one element (say the background color), automatically adjusting the colors of other elements around it.

For example, say the background color is white. I reflect it to get a text color of black. Then I get 3 other foreground colors that are rotated by 120 degrees along the color wheel. Now I could adjust the hue to rotate around the color wheel. Or I could reflect to get dark mode. But is there a way that supports both without going all the way to a 2D color space? For example, if you set the background color to medium grey now no foreground color can give you the desired level of contrast. So I'd like to not even represent such a background color as an option.

I don't know if this is _exactly_ what you're looking for, but it reminded me of this demo of the color contrast tool in Figma I just saw: <https://x.com/billy_sweeney/status/1905640393045409923>

I really like the brightness as defined by HSLuv <https://www.hsluv.org/>. The transform betweeen RGB is not super straightforward but there is a lot of sample code and it produces really nice feeling colors.

Also it kind of depends if you're designing for color-blind people. Assuming the most pessimistic accessibility scenario (total color blindness), the only factor in foreground / background contrast is the difference in brightness but for folks that see color the whole UI could have the same effective brightness and still be legible (maybe even could still look nice).

Yeah, I don't really know what I'm doing regarding color blindness, mostly I just try to avoid red on green, or using red and green foregrounds on the same background.

I'm not intending this for extremely colorful things like you make, <@U06SS0DHZD1> or something professional quality that designers will make <@U05GSC0B4A0>. I'm imagining there's mostly a single background, a single body color, couple of accent colors say for syntax highlighting. So I don't need to support every possible point in a scale. The goal is more to exclude _bad_ points in a predictable, opinionated way.

Ah got it, yeah I guess I had never seen a visual representation of the available and bad colors at a given contrast level and thought there might be something useful for you there: exclude 90% of color space, set up some basic heuristics, get a pretty decent solution

i think <https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl|oklch> is the new black

<https://webaim.org/articles/contrast/|This is a good resource.>

I’ve been thinking about how languages taught at the intro level are usually taught with lots of white lies about how they work, out of necessity. For example, Python’s actual underlying memory model (how everything’s a reference and isn’t copied around) is confusing (arguably), so we avoid teaching that part and oftentimes make all these distinctions between references and primitives (even though everything’s an object). Teaching something more accurate (everything’s an object with references, and oh sometimes values are even referenced via referenced counting) would actually lead to confusion when trying to translate some of this in other languages like C, where everything’s actually a value (pointers are just ints purposed for addressing things).

Java is also confusing with all the GC stuff and opinions it has about memory and memory behavior.

I would like a first-learner’s language that has the arguably-more-consistent semantics of something like C (“everything’s a value”), but is closer to Python. So I can feel like I’m not “lying” so much. I think the closest thing is C itself, unfortunately, or C++ with a custom allocator thing.

Or maybe a hot-take: objective C / ARC are the closest.

But really I’d just like a Python with less obfuscation and inconsistency, so it looks more like C with safety on-top and better file imports.

Essentially, Python with proper value types for everything, even if a little more challenging. The most explainable language closest to hardware, but easier to use.

Just thinking out-loud. I think a Python 3 subset preprocessor that outputs raw C would look close to the language I have in-mind. (I’d like `end` for blocks too).

Could you elaborate on where beginners might get tripped up by memory model gotchas in these languages? Basically I'm wondering how to build up to a worldview that this is a major issue. For example, if you had a list of gotcha programs in Python that would be very interesting to go through. I can think of one gotcha in Python (appending to a default arg that is initialized to an empty list, or something like that). Is it a jungle out there, or is it just a couple of things like that in each language that people hit and learn to avoid?

e.g. “Why you can modify a list passed to a function and not a non-container type” ; “Why does setting a variable equal to a list / object type make for a reference to the list / object type, whereas ints/floats/strs don’t have this behavior?

In general you explain this in intro by describing copying of values and treating container/object types as references, but in Python that’s not actually how it works. These are not SUPER major issues, but any attempt to explain correctly leads to more complexity than an intro student can normally handle. Python’s a bit messy unless you just suspend disbelief and pretend things work a certain way without explaining why.

I’d like a language that doesn’t hide things like that quite as much, even if arguably it’s not a huge issue for intro.

I do think a simplified C is slightly better because the copying semantics is pretty well-defined vs Python’s reference counting stuff.

<https://nedbatchelder.com/text/names1.html|Good talk and page on how Python variables work>

C++ is value oriented and low level. Passing a container into a function creates a copy of that container (unless it's passed as a pointer). So the "reference vs value" gotcha can be mostly avoided while teaching. There is a sea of other gotchas in the language though.

IMO the value vs reference may not be such a big issue if explained directly through exercises. A couple tasks where the student has to directly experience how values and references behave should be enough to form a correct mental model. May be easier than chosing a different language altogether.

does <https://pyret.org/> check any of your boxes?

When I started advocating and teaching Python to scientists, around 1996, I tried to avoid the hard parts indeed. But not for long. After a few years, I covered the memory model in the very first session, to get that out of the way. It worked well, and I think it was helpful in particular for the many participants who grew up with Fortran.
That said, I never covered the more subtle gotchas of Python, such as the messy scoping rules.

I am ambivalent about teaching languages that avoid thorny issues but don't aim to be usable in real life. Whatever language is used for teaching should also permit learners to solve real problems that matter to them (though not necessarily to get a job in the software industry).

What isn't a gotcha in Python? lol. Cyclic imports, WTF is a `__init__.py` , imports are executing. setup.py is executed. package resolution. Nothing can be trusted due to monkey patching (which I like BTW). `from {foo} import` vs. `import foo` import-by-reference vs  import-by-value subtleties. module unloading. white space. Forgetting an f in a multi-line f string (I caused a prod outage coz of that, it is also unlintable). Can't put functions in a string interpolation. Single line lambdas only (?!).  the GIL. async. multi-processing. the list is endless with that language.
The default value being persistent in args is a steady cause of bugs which we can at least lint around. The memory model is not not my main source of problems though.

You _can_ write C++ in a value-oriented way, but you have to internalize a _lot_ of things about it to know how to do that consistently and effectively, so it’s a poor fit for the pedagogical context here I think… but folks with strong positive experiences using C++ in that value-oriented way as well as a lot of time using Swift (which obviously draws a _lot_ on the “C + ARC” model) are behind <https://www.hylo-lang.org|Hylo>, which might be interesting to poke at here. _Caveat emptor_: I haven’t used it, just read the docs, and it’s still quite early!

<@U02E4DAQGSZ> Your list contains mostly features that easily become problems in practice when developing large programs. That's not the same as features that require a precise mental model. It's easy to see why the f matters in f-strings, but that doesn't protect you from forgetting it.

Good language design should of course avoid both types of issues.

I’m thinking also in terms of curriculum. Going from python in intro straight to java then C seems like the wrong order because in a way, Python’s more complicated and unique than Java than C in that everything’s a reference, then most things are references / some are values, then everything’s a value in C (and pointers are values that can refer to other values).

It’s not a giant issue if you do handwaving and don’t explain how things work, but if you try to explain Python’s model for names/labels, I think it can cause friction if then trying to learn general-purpose things or other languages. The fact that python is all references/no copying is just a little weird.

I like python for a lot of things, but not for this aspect (and not for its lack of graphics and web support).

For me it’s major because stylistically, I like not to handwave.

Racket is a great teaching language with loads of pedagogical material available. If you hate s-expressions, then Pyret (mentioned above) and Rombus are very good choices. These languages have all been designed by people with decades of teaching programming and researching what works for language learners.

<https://rhombus-lang.org|https://rhombus-lang.org>

btw I don’t have a way to change the language since I don’t design the university curriculum. It’s more me thinking out-loud. I saw racket before, it’s cool.

I would still recommend C but without the stdlib ... perhaps an alternate stdlib library.

I’d do that and maybe provide wrappers around regular stdlib so people could check the innards if they wanted.

Perhaps add  a defer as well. I like D .... its just that the problem with  D is C library people write horrible APIs which abuse the C preprocessor. I hate C preprocessor .... people do some scary stuff with it, which is always intimidating for beginners.

Yeah all of them have the .... need C to do anything useful problem.

It’s basically what we’re talking about. Better allocator support, better imports, built-in allocator context, defer.

C’s worst offsense to me is the includes and headers

Zig / Odin change the syntax way too much.
At best I would be happy with just changes in the declaration syntax

`main(argc :int, argv :char[]) :: int`

but they change a whole lot. D is definitely more consistent.

objective C is really not a bad deal only issue with it is ... lack of win / linux support

I think C’s syntax is okay except the square brackets in declaring an array and the includes / headers are BLA. But yeah. A C with a custom course stdlib would be enough. Even if the allocation / deallocation straegy is not super efficient, having something automatic in-place could help. Just a big arena.

Or a Python with less magic.

C + Lua is a good combo as the world of warcarft players might pay more a attention in class I guess :grin:

Realistically just C with classes (barebones C++ with methods and basic templates)

Boosting <@U013ZLJARC7>’s recommendation for Racket. It has not only extensive teaching experience behind it, but it is also very usable in real life. Not for all domains, of course. Nothing is. But it's not just a toy language that you need to move on from rapidly.

We’re in university territory here. They only do python, java, and c-likes. So I’m sort of compromising. I imagine a version of python with more C-like behavior, or just using a variant of C.

I think why not because it behaves too differently and at a too high level from others, but that doesn’t mean smalltalk isn’t cool. It is cool.

The problem feels overconstrained as stated. You want a good language but also need it to run the gauntlet of a large bureaucracy like a university. Any attempt to improve on a mainstream language will be definition not be mainstream, at least at the start. Someone has to do the work to get it approved.

True. This all started with me being a bit frustrated at Python for hiding too many things. Among the existing languages, to me, some kind of constrained C makes sense. If there were a new language (insert “let’s make a new standard” meme), then yes. Maybe something with a simple simple runtime and smalltalk-esque syntax.

Odin (very modern) or assembler for one of the early CPU architectures (PDP-11, Vax, MC6809, NS32016, etc.). I've never used Turing (nor Turing+), but it is a language designed for teaching during the era when garbage collection was considered to be a dirty subject. In particular, I like CSRI's approach towards simplicity, esp. Holt's and Cordy's. Note that Kernighan was an undergrad at UofT and Rob Pike was at least seen at CSRI (I remember being convinced that Pike was an overgrad there, but, can't confirm) (CSRI was in the same small building as Marshall McLuhan's office). FWIW, further on my feelings about <https://programmingsimplicity.substack.com/p/remics-the-study-of-the-fundamentals?r=1egdky|Remics - the study of the fundamentals of reprogrammable machines>

Yep, I’ve been following Odin. Pretty nice.

<@ULM3U6275> Why not Smalltalk? From my perspective, Smalltalk would probably make a good system for starting with computing, but there isn't much teaching material for it, nor much teaching experience with it.

The same argument holds against Odin (just mentioned) and many other recent languages, including languages like Hedy which are designed for teaching. If you adopt any of them, you should be doing research in computing education, not large-scale teaching. Which is fine, I think that needs to be done, but it's another objective.

If you pick a language for teaching based on your gut feelings about that language being good for teaching, you are doing vibe teaching. Which is perhaps the next fashion, but it's not something I'd recommend based on my own (limited, of course) teaching experience.

<https://www.scattered-thoughts.net/writing/a-rough-survey-of-compilation-recompilation-and-compile-time-evaluation>

I'm curious if anyone knows of languages that have different approaches to the ones I covered here.

The article seems motivated by research around a better version of hot-reloading (?). I think about 1. Erlang (you have in the article), also 2. Vite which manages to bolt on hot reloading by exploiting dynamic imports and adds a layer of indirection there, which does not work reliably but works enough to create value and also 3. Observable runtime, which is a runtime that that first class support for swapping an implementation and recomputing the dependancy graph (it has a compilation process too but its kind of trivial). JS simplifies things in that you can't swap in the middle of a function because its single threaded, Erlang also works by having a higher level runtime scheduler deciding when to swap. I think that runtime support is essential for top recompilation. I keep thinking it be awesome if go was hot-swapable but I think it always feel like you need an actor like system with serializable messages communicating between them, and then its not like go anymore.
Anyway, Observable has the best hot-reload IMHO, aided by a combination of JS affordances (dynamic imports, single threaded, garbage collection), Runtime support (explicit dependancy graph, cell based construction which I feel is basically an actor system).

You don't really explicitly mention actor systems but they are perfect for defining boundaries for partial recompilation. Observable goes a little beyond Erlang in the sense that when a cell is recomputed, all downstream cells are recomputed which can be thought of replaying their messages that were tainted with the old code. There still exists a problem that the final state is non-deterministic based on the message processing order (same as Erlang) which is the manifestation of non-determinism in the schedular. Would be nice to fix that (I have no idea how).

&gt; ... actor systems ... are perfect for defining boundaries for partial recompilation
:100:
Function-calling makes hot-reloading more difficult than necessary. Units of software that have, both, input queues and output queues make hot-reloading easier to think about.

&gt; .. final state is non-deterministic ... Would be nice to fix that (I have no idea how).
The way to fix this is: don't fix it. Don't hide a fix in the engine, under the hood. Allow Software Architects and Software Engineers to deal with the issue on a custom, per-project basis. Give 'em textbooks filled with suggestions and algorithms. Assume that SW Architects and SW Engineers are smart enough to figure out which option to choose to solve a particular problem. Imagine if Civil Engineers had to use a unified bridge design for every bridge over rivers. All bridges would be the same and none of them would be any good in practice. In the current programming workflow, general purpose programming languages try to solve every problem at once and programmers need to waste time and efficiency playing whack-a-mole. One's programming mindset changes, for the better, when one knows that willy-nilly, blocking function calls are not allowed to cross software unit boundaries.

I've spent a considerable amount of time now figuring out in which "direction" do memory addresses mentally increase. I'm trying to pick a convention for presenting memory in Automat that would make it easier to mentally picture what's happening. No direction is perfect and each one involves some friction when mentally manipulating order of things.

The established conventions that I know of are:

• Text goes right and down (when lines wrap). Text direction may be pretty much arbitrary when different scripts are involved.
• Bits increase towards left (because &lt;&lt; shifts bits up) and then up (because of "higher" bytes). Computer science courses teach that "stacks grow down".
• Numbers increase towards left (more significant digits go towards left) but for a typical (little-endian) CPU more significant bytes are written towards right.
• Points on a cartesian system tend to increase first towards right and up.
• In nature things usually grow up.

I think we have no widely shared real-world experience of one-dimensional things other than maybe time. Can subsequent addresses be "later"? :sweat_smile:

You can "grow up" and you can go "deeper", as you can say you can go "right" on latin text or "left" on arabic numbers or <https://en.wikipedia.org/wiki/Boustrophedon|both>. The only constant is "away".

(And time, I really like the "later" answer)

The only universal answer: a spiral with zero in the middle. I kid, mostly.

For UI about memory, I would honestly go with the conventions for other UIs about memory like hexdumps, where smaller-numbered addresses are at the top of the page and proceed down, usually with a little bit of LTR or RTL within 16 byte blocks or so (possibly worth localizing?).

Unless you really want to innovate the UI, in which case do whatever. They're just numbers. You can use any consistent ordering, and they've all _been_ used for something, so there's not a firm precedent. I think bringing in endianness, 2d cartesian coordinates, etc is a bit of a red herring. I'd only caution that trying to have numbers that grow up and sideways like a cartesian graph will be really confusing, just because if it's embedded in a UI that reads topdown/LTR like English, it'll be really hard to avoid applying that to the memory UI too.

If you want to do something weird, I guess there's also the good ol' space-filling curve visualization; that'll keep things compact without privileging any direction or even either end of the ordering too much, at the cost of, well, being weird.

<https://binvis.io/|https://binvis.io/> uses the last one for reverse engineering (and it works wonderfully there!). Memory in this view feels a little like a long noodle squeezed into a container :joy:

<https://tomasp.net/blog/2015/library-frameworks/>

A good comparison can be Qt vs Skia.

I agree with most claims of this essay. However, having used many frameworks and after having analyzed why they work well, it boils down to.

1. Good documentation
2. Multiplatform abstraction behind a standard interface
3.  Combine many calls into a simple end point (button->draw in Qt vs drawing a button via Skia)
If these are addressed by libraries, then libraries with simple callbacks are much more preferrable to frameworks.

One problem which frameworks and libraries don't address or hide away is state machines.
An app is fundamentally event loop + state machine.

Any framework that you use long enough, you will want to peek into how it is actually handling events and customize it.

I think frameworks can change the programming model whereas a library cannot.

So a runtime like Akka is really a framework (note also has a state machine abstraction) , but there is no real way you can add the actor model without giving up execution control. Similarly, React gave a declarative programming model to the imperative DOM.  Not sure if its possible as a library (it kinda of is a library until you hit the JSX bit)

Programming languages don't compose either. I see frameworks as a less drastic version of a language change. They can fundamentally change the whole programming model. They change a programming language into a different programming language, but without changing the syntax (React did change the syntax too tho) or access to the ecosystem libraries.

So sometimes a thing needs to be a framework, but you should use the least powerful thing to achieve your needs. If it can be done as a library then do it as a library.

"Should technical candidates be allowed to use AI assistance in an interview?"

I've had the debate many times over the last two years. My initial stance has always been "of course not, I want to evaluate if they actually understand programming fundamentals." My stance here might be softening. Common responses I hear are
• "This is the way people write code now and we should assess candidates in as close to 'real world' conditions as possible"
• "Where is line between syntax highlighting, LSPs, and AI code-completion?"
• "It should be obvious when a candidate doesn't understand the code they're generating"
• "Cursor boosts your output; a productive engineer should always leverage the best tools"
My responses to those points vary from "LSPs don't write the code on your behalf", "code completion operates on syntax and not semantics", and "human-in-the loop reduces critical reasoning." I personally find it difficult to discern meaningful signal around a candidates level of understanding while they tap tab. What do you all think?

I'm a stick in the mud, but I still say no. At least, there should be a phase where you see if they can actually write code, even if there's also a stage where they can use AI.
(The "where is the line" complaint is bordering on bad faith by the way. Autocomplete and syntax highlighting are based on glorified grep. The line is plenty clear if you don't have an interest in obscuring it.)

Interviews are a shitshow and largely throwing spaghetti on the wall to see what sticks. They're not completely random lotteries, but they have a significant component of chance. They are also obviously robust to mistakes; I see bad candidates hired all the time and yet the world moves on. Therefore, speaking from zero experience and reasoning purely from first principles (since this is a forum on the Internet):

It's not clear to me that decisions along this one dimension will dramatically change the quality of outcomes.

Define what you want to measure first. Once you do that it should be easier to say how AI affects the SNR of the measured property. IMO for measuring "coding skills" or "problem solving" AI obscures the candidate's skill. It might be interesting to use a system prompt that asks the AI to help in measuring the candidate's knowledge in specific areas, for example by deliberately injecting bugs (the candidate should be aware of this though).

I do agree that technical interviews are often if not always misaligned from actual work product. At their worst, interviews are a pile of leetcode you'll never look at again. At their best, they're a toy piece of code that is intended to extract some form of signal.

I've started to narrow in on "code with AI allowed" and "debug / code review a buggy piece of code without AI." Thought being: the latter will evaluate instincts, intuition, informal reasoning etc while the former assess ability to problem solve and posit solutions, What this doesn't necessarily test is code architecture and organization which is... probably important?

"Should students be able to use a calculator on a math test?"

I agree with Marek that you have to first define what it is you are looking to measure. And I feel like many interviewers have not done that work so then the interview ends up being a "feeling."

Are you looking for rote memorization of algorithms/leetcode exercises, are you looking for someone who can level up your junior engineers because they're good at explaining things, someone who won't argue with your hard to work with VP because they don't ask tough questions so you won't have to backfill that position again in another 6 months, etc.

I've never understood how people find live coding interviews to be helpful. Is that really the conditions you need a candidate to perform well? I am a lousy typer. I am not the fastest programmer. My method is always to start messy and explore and refine code with time. I am bad at speaking out loud to someone I don't know and at the same time also thinking about my problem.

If you are going to insist on such an artificial, imperfect test of skill, why try and restrict it even further? Why not let them have the tools they'd actually use and see how they work?

But I really think these kinds of technical interviews are completely misguided. They aren't made to try and figure out the candidates skills but to see if they are weak in one particular problem you happen to choose. It is especially bad when the interviewer knows the problem well, because they see the solution as obvious and anyone who doesn't get it isn't as smart as them.

I try to make my interviews to focus on someones strengths. Is there background databases? Let's focus on that. Is there background frontend? Let's chat about that. Do they have a bunch of code on their github? Let me do the work to understand it and talk to them about that. I want to learn about a candidate. I want to find out what they care about, what they know deeply, what they are interested in. And I want them to understand the needs and challenges we have and see if they have some ability to help. Asking someone to live code for you is never going to help you figure that. Restricting them to an unfamiliar environment is going to make it even less likely that you get to know them.

autocomplete (reducing typing an memorization) isn’t the same as some ai generating solutions to problems you’re meant solve using your own thought process. It’s grunt work vs creativity. Ignoring that the live coding is flawed, but if you use AI you’re turning the interview into “can you be a compiler that checks for errors?”

eh…

I agree with the above too. I’m slow and iterative, and I need to try a few things. That’s not eary to come out in an interview at all and it might look like what I’m doing is bad if the measurement is just raw correctness and speed.

Personally, I think the premise is flawed. I don't believe that the person you interact with in the interview bares even a passing resemblance to the person they'll be after working with you for a month. If they have a modicum of interest in programming, and seem enthusiastic, then just give them the benefit of the doubt and do some work together. You'll each learn a lot.

I guess another way of putting this: I don't believe in fixed vs growth mindset in general, but I strongly believe in something similar existing when it comes to working with people.

I agree that technical interviews are a weak approximation of holistic ability and generally contain mixed signals. What's worse is when those misleading signals are interpreted or factored into the assessment -- typing, code style, etc. I do worry it's easy to throw the baby out with the bath water, though. Without some indication of work product, you're stuck evaluating a candidate on 'vibes'. My favorite way to evaluate a candidate is to look at existing work product. Have they contributed to an OSS project and are those contributions something you'd be excited to receive. If so, done and dusted. That's not always an option though when someone has contributed to closed-source projects the bulk of their career.

I think Marek's response is the most accurate: "define what you want to measure first"

&gt; I don't believe that the person you interact with in the interview bares even a passing resemblance to the person they'll be after working with you for a month.
Absolutely! But I don't think these narrow technical interviews are not meant to assess the person holistically. If you're looking for a broad signal using a narrow test, you're likely doing the candidate a disservice and not setting them up for success. But if you're focusing on narrow goals -- does the candidate have a grasp of core fundamentals required to operate on relevant systems -- I think there still is meaningful signal to extract. Question is: how? Related, I think the responses "I'm a slow typist" and "it's difficult to talk through intent with new people" are orthogonal to the issue. A qualified interviewer isn't assessing typing speed and should factor in nerves.

&gt; If you are going to insist on such an artificial, imperfect test of skill, why try and restrict it even further?
I keep coming back to thinking about AP CompSci or similar academic courses. Most of those are still pencil + paper which feels like an extreme restriction. I have to assume the goal is to extract a candidates core understanding of underlying principles without assistance. The counter argument, the content you're assessing is targeted and narrow in contrast to a job interview.

To answer the question directly: in my opinion, you might restrict the test further if the inclusion of those restrictions would further muddle or hide the signals you intend to measure. Brings it back to: "define what you want to measure first"

&gt; "Should students be able to use a calculator on a math test?"
This absolutely feels like a faulty parallelism. You still need to understanding _what_ you're typing into a calculator to get an accurate response.

I was actually just having this conversation with someone last night, and I think the "standard" interview questions of the past have kind of been used incorrectly as "here's a problem, get it right you pass, get it wrong you fail" when that doesn't matter that much - what you're really trying to assess is something closer to what Ivan is getting at: "do they have an enthusiastic interest in programming?" and "have they kept up with what the latest is with people who have enthusiastic interests in programming?", which has changed a lot over time.

At one time it was working with pointers, later it was working with hashes/hash maps, these days its a lot of functional/collection-based concepts now that a lot of languages hashes are a day 1 concept...

For me, the answer to your question is that how comfortable a candidate is at using AI in the interview is the primary thing I'm looking at. What techniques have they come up with or invented, how well do they know the different tools they're choosing and so on

I’ve always struggled with interviews, even on easyish questions. I can’t really talk with someone while coding or get the right answer straight away. When I actually code for myself, I’ll sort of vibe-out (not vibe code) and try molding what I’m doing.
Just… super unnatural to think out-loud because if I’m explaining out-loud, I’m not thinking. I’m in some zombie presenter state. Parallel processing issue?

I wish I could pass some of these interviews.

shameless plug: looking for collaborations on creative cool things. Feelings of computing indeed

&gt;&gt; "Should students be able to use a calculator on a math test?"
&gt; This absolutely feels like a faulty parallelism. You still need to understanding _what_ you're typing into a calculator to get an accurate response.
Well, yes, of course, which is exactly my point. If you want to test someone's ability to hand calculate, you have to remove the calculator. But if you want to test if someone knows how to approach answering the question, regardless of their ability to calculate, you probably allow a calculator (I feel like I might have been a civil engineer except for my tendency for hand written calculations in college to have an off-by-one or switched sign error, something that a computer would not have done - I was using the correct formula... but probably I'm just bitter about my own past mistakes)

I actually think using an LLM can potentially tell you more about how a candidate thinks, since it may generate a solution that needs to be refactored or tweaked because it doesn't handle all of the edge cases you'd want, which is something you wouldn't see in a standard technical interview. But it's also something you have less control over as an interviewer, since you don't know what the LLM will produce.

In any case, I think this question will be less and less relevant in the future as LLMs and tools improve and eventually there will just be an expectation that everyone uses them.

&gt; For me, the answer to your question is that how comfortable a candidate is at using AI in the interview is the primary thing I'm looking at.
Interesting, so you like to double down and evaluate the candidates use of AI as a tool in the modern toolbelt? That's aligned with the feedback I've heard of "a productive engineer should always leverage the best tools".

&gt; At one time it was working with pointers, later it was working with hashes/hash maps, these days its a lot of functional/collection-based concepts now that a lot of languages hashes are a day 1 concept...
I often think about this too! My framing is generally in terms of "abstraction layers". I like to ask myself "does this candidate understand one or two layers below the surface" or "could they explain how N is meant to work." Sorta like Gary Bernhardt's "Destroy All Software" project. As we add new abstraction layers though, the relative "fundamentals" follow as well

The calculator analogy doesn’t work and I’ve seen it so many times.

I think using an LLM is harder than just solving it on your own because now you have to debug the output and check for errors in something that you might not even fully understand. I’d want to evaluate someone based on how they design a solution to a problem end to end, even if there are fumbles. 

I wouldn’t expect everyone to use these since they can easily introduce technical debt.

If anything, you could introduce using a model/any automation tool as part of an interview to see how someone adapts to learning a new tool. See how someone pokes at something.

But in the end I want to know how someone is when they’re thinking through something with me, as if the tools and supports weren’t there. (I wouldn’t consider an llm a great support for many problems anyway.) An ideal interview is collaborative towards solving a problem and designing something.

&gt;&gt; "Should students be able to use a calculator on a math test?"
&gt;&gt; This absolutely feels like a faulty parallelism. You still need to understanding _what_ you're typing into a calculator to get an accurate response.
&gt; Well, yes, of course, which is exactly my point. If you want to test someone's ability to hand calculate, you have to remove the calculator. But if you want to test if someone knows how to approach answering the question, regardless of their ability to calculate, you probably allow a calculator
I see what you're getting at! Sorry I think I misunderstood your initial response. This framing on aligns with, I think, what I just posted about "relative levels of abstractions." The "fundamentals" are relative to the current tools of art.

Do you think it's important a candidate understands an increasing relative depth as the tools become further removed from the core technology. For example, I could argue it's important for an eng to understand the trade offs between "passing by value vs reference" regardless of how advanced the tools become

> But in the end I want to know how someone is when they’re thinking through something with me
:heavy_plus_sign: I've never dinged a candidate for not completing the given problem if they've demonstrated a solid understanding of the problem, have articulated their approach clearly, laid out a framework for success etc. I suppose, this is true and possible regardless if the candidate uses AI or not

In the end of the day, it's conversation. "Does it compile and pass tests" is a stinky approach.

Yeah, agreed, although I think using ai skips the point of explaining your thought process. Granted, I’ve struggled with multiprocessing thinking and explaining during such interviews.

&gt; Interesting, so you like to double down and evaluate the candidates use of AI as a tool in the modern toolbelt?
Yeah exactly, LLMs and LLM-based coding requires a much different mindset and is so new that best practices are still being discovered. I suspect it's going to be a long time before it feels like we really know what we're doing again, so someone who's curious and experimenting and testing out ideas (or keeping up with the latest ones and incorporating them into their process) would be my primary criteria right now...

&gt; As we add new abstraction layers though, the relative "fundamentals" follow as well
Yeah, it's an exciting time to see this new layer form :slightly_smiling_face:

&gt; I think using an LLM is harder than just solving it on your own because now you have to debug the output and check for errors in something that you might not even fully understand. I’d want to evaluate someone based on how they design a solution to a problem end to end, even if there are fumbles.
Yeah, but here you're also describing "legacy code", which I'd assume your current code base has plenty of.

But also, I think LLMs are probably a better fit for well known domains where there's a lot of training data, and I imagine the audience of this slack may skew toward more novel domains where the LLMs just give nonsense recommendations

Yes, nonsense recommendations in novel domains. Also, yes, legacy code is probably comparable, but I don’t know if I’d want to evaluate someone trying to look at the equivalent of legacy code rather than coming-up with something together. An llm in the middle seems a bit weird. “Hold on interviewer, I have to inspect this code.” Leaves a bit of an awkward gap versus just showing the full thought process. I’m of course a bit guilty of disliking the common process for other reasons.

One thing I didn't think of when this thread was created, and now it's too late to do anything about it, but just for reference: I think this thread belongs in <#C01932BJGE8|>. Not because it's about AI, but because it's about interviews.

With that assumption I have a couple of things to say:

• I've always punched above my weight class in coding interviews. Which is to say, employers who hired me on the basis of a coding interview usually over-estimated my capabilities. I think this one skill has contributed more to my personal bottom line than anything else. So I'm a long-time benefactor of dysfunctional interviewing practices.
• I'm currently preparing for an interview at a place that requires a coding interview at the level of "leetcode medium or hard." Leetcode hard is _really_ hard. There is no way in hell I can do a leetcode hard problem in 60 minutes. In fact, if I get a leetcode hard problem I suspect the interviewer is mostly going to see me hemming and hawing for 60 minutes. If I wasn't stuck at a desk in front of a window containing a camera feed I'd be lying down, or pacing the room, or tossing a ball against a wall. At least in person interviews let me scribble on a whiteboard.
• I've had to deal with leetcode hard interviews before, but it was usually a surprise in the past, and those employers weeded themselves out of my consideration. I've never tried to _train_ for this level. And it has given me greater empathy for others who haven't had my good luck, those who are penalized rather than advantaged by the current interview process. Like the people who need to toss a ball against a wall for leetcode medium problems. The problems themselves are fun, but they seem terrible in the context of an interview.
• It's all very well to say companies aren't doing interviews right. But what matters is the practice, not the ideal. Companies hire engineers, not "qualified interviewers." As an industry we have no rigorous rubric for interviewers, for their knowledge, their discernment, their curiosity about a candidate, their motivation to tease apart fine detail. For the most part, doing interviews well is not a priority for companies, and it's not clear that it should be. It doesn't obviously increase their fitness to their environment. It's not clear to me that adding LLMs changes that equation. Though it's still early days and there are going to be tons of uses for LLMs that my puny brain can't even conceive of right now.

I assume in an interview that you want to evaluate how the interviewee would likely perform in a given role.
If they can use AI in their role, then yes. If not, no.
To evaluate basic coding skills, I tend to use Soloway's Recuring Rainfall and make sure they can walk through how their solution works preferably with the correct vocabulary. I really need to check if if ChatGPT can do that yet.
For architecture/system structure, I usually don't have people write code. I'm usually looking for tradeoff selection. I don't see AI helping here.
For debugging/analysis check, I usually do two things: A) have them look over a PR and provide feedback, which would be interesting to see them use AI on. B) Tackle a previous big bug in a system they don't know with another engineer, basically just making sure they can work with someone binary-search style. AI would be too specific here and fail.

<https://www.linkedin.com/feed/update/urn:li:activity:7322560534824865792/|A data point I just noticed>

Duolingo will now evaluate for AI use in interviews

As if it’s not enough to think for yourself. Goodness.

Pure computation is pure all the way down, an advantage of this is the ability to verify a result by just putting the inputs in again. This is useful in the real world if you share a result with someone: for example when a bank tells a customer how much their mortgage repayment costs

It works not just for one result of interest, but for every other result that one depends on: in other words for the complete workings. So by sharing the pure computation code and it's inputs along with a number, the number is verifiable and you've also shared the complete workings (for free).

I exploit this as much as I can in calculang, including while developing models, with reactive visualizations showing me current model behavior for some inputs (with controls; all experimental at this stage).

It surprises me that on developer tools, functional programming is not in it's own league in front. There are some application state developer tools that FP techniques enable and some are influential. But I don't know anything about interesting introspection- or validation type tools that especially exploit purity. Anyone know if I'm missing something in particular or have any good references to read on?

I might consider a POC exploration on just this idea for some other language (maybe Haskell or PureScript but open to thoughts)

I finally got around to Dave Ackley's latest video report on robust-first computing which <@UJFN50C00> shared <https://futureofcoding.slack.com/archives/C5U3SEW6A/p1745855290195199|here>, and it prompted me to zoom out and think about the territory of computation and what we know of it so far in the year 2025. Right now I imagine it as a 3D terrain. Along one axis, analogous to a <https://en.wikipedia.org/wiki/Multiview_orthographic_projection|plan view>, I see the following coarse _technical_ approaches to structuring computation, each equally valid:
• Computation as the orchestration of precise instructions.
• Computation as the learning of matrix weights.
• Computation as the orchestration of fuzzy, imprecise cellular automata. Ackley's approach.
I think that's it? Are there others?

Along an orthogonal axis, analogous to an elevation view, I see _social_ approaches to organizing the means of computation. So far we only have open questions here:
• Does computational infrastructure necessarily require authoritarian dictators or at best feudal lords and vassals? Or is it possible to have something analogous to a democratic approach?
• Can we reduce inequality between the haves and have-nots of tech knowledge and computer whispering?
• Can we design incentives to keep computation working over time, in a secure and trustworthy way? (Can computation ever be biased less towards offense, can defense be viable?)
• Can we design incentives to make the means of computation sustainable in their impact on the environment?
And along a second orthogonal axis, analogous to a side view, I imagine ways to connect up computation with other fields of human endeavor. Here there has been much progress, though I am running out of steam:
• Learning from the arts to improve visual and auditory design, e.g. typography.
• Learning from math to better model the world, e.g. numerical methods.
• Learning from the social sciences to nudge groups of people in productive and unproductive directions. Coevolving populations with these lessons that will inevitably grow robust to such nudging.
• ...?
Feel free to point out gaps, additional axes, add examples..

In the end computers tend to end up executing precise instructions anyway. The first approach that you listed is the bedrock abstraction that the second and third approaches are built on top. In principle it's possible to build machines that would implement other approaches natively but doing so is rarely practical (1, 2 &amp; 3-d cellular automata are some of the exceptions).

I think the question that you asked ("are there others") is the main reason many of us are here :slightly_smiling_face: From the back of my memory, there is:
• quantum computing (another case where building a native computer is essential)
• spiking neural networks
• expert systems, also fuzzy ones
• fpga-style logic networks
• a few cryptographic approaches (ethereum / unison / white-box cryptography / zero-knowledge proofs)

There is a lot of passive mechanical computation in existence.

For an underwater robot we added floats to the bottom of our rotating wifi antenna so the antenna went vertical when on the water surface (maximizing range) but folded flat when underwater (reduce drag for locomotion).
This is a genuine computational device relying on a non-linearity and "programmed" by positioning hinges and orientated w.r.t. gravity and the environment to get a designed behaviour.

A toilet flush is quite a complicated but common one. I consider these closed loop control systems but the feedback computation is done without silicon, which is often _*much*_ more robust albiet limited in expressivity. They don't require electricity to run, but in these two examples they _are_ _powered_ but with kinetic energy (and they lose energy via heat losses like everything powered).

For the first axis, there are probably many candidates, depending on how "mainstream" we require them to be. Quantum computing is an obvious candidate, as <@U06SS0DHZD1> pointed out. There are also more exotic ideas, such as the <https://www.lix.polytechnique.fr/~fvalenci/papers/cham.pdf|Chemical Abstract Machine> . On the other hand, I'd remove "learning of matrix weights" from the list as long as it is implemented strictly in terms of the preceding technique in the list. Just to punish laziness.

We could also admit human crowds as computational agents, and then decide that markets are a form of computation. Perhaps the fundamental question is what defines computation within a wider framing, e.g. "information processing".

I don't care too much that one metaphor is built in terms of another, or which kind is most fundamental. That kind of reductionism seems unimportant here.

I agree. But if you want to map out the space of computation, you have to say somewhere what you mean by computation, at least roughly.

I have witnessed two heated debates, between academics of different disciplines, on the question "is the brain a computer?" In both cases, it turned out after some rounds of shouting at each other that each participants had a different view of what "computer" means. At one extreme, it was "a physical system capable of processing information", at the other extreme it was a deterministic system with a clear separation of hardware and software layers.

Yeah. Perhaps it would help to clarify that I'm thinking in this thread about the experience of getting some desired behavior. What does the inner experience of "programming" feel like. So the technical part of my OP was, you can program by engaging with syntax and semantics, or by running tons of data through an algorithm to tweak weights, or by whatever mechanism Dave Ackley is doing that I don't understand but definitely seems much more fault tolerant than syntax and semantics.

Expert systems and relevance work do feel like first-class different experiences. Maybe related to neural networks? In all 3 the feedback loop seems definitely dilated. There's no equivalent of adding a semi-colon in response to an error message..

I don't know enough about quantum computers to know what the activity of programming them feels like. So open question. Is it just libraries that run on a coprocessor with weird time complexity properties, and some barriers to adjusting function boundaries (to avoid observing at the wrong time)? Or is there more to the experience?

FPGAs don't immediately feel different in the same way. My rough sense is you compile the same conventional languages to commands that configure logic gates. It's akin to compiling down to Verilog. Though there's some weirdness in terms of seemingly simple things in software that explode to take up tons of gates. That might make programming them feel different.

Similarly, DAOs on blockchains seem like regular programming, just less flexible? Once it goes on the ledger it's hard/impossible to change.. They're probably slower, but we also have lots of experience with slow languages :slightly_smiling_face: ZK proofs do feel fundamentally different.

I have some sympathy for the idea that analog computation and reversible computation feel like their own experience. But I don't know enough to be sure.

I also have some sympathy for the idea that programming a game feels very different than other kinds of programming even if you're using similar languages and tools. There's a level of mechanism design and tuning for playability that's gestalt rather than detail-oriented in a way that I've never quite been able to grok. And that barrier is always an indication it's a whole different activity.

OK more on target then: programming an LLM system is quite a different beast (build benchmarks, iterate on prompt, think about context, lots of second guessing the LLMs thought process)

Programming with an LLM seems a little bit like being a manager. Which gets to <@UJBAJNFLK>'s idea of other people as a substrate to delegate work to. Arguably the oldest programming of all.

Using an LLM (1) is different to building a system around LLMs (2).  1. is managerial. 2. is herding cats and involves a lot of probabilistic reasoning.

Is 2 what you meant in your previous comment? I don't quite understand this kind of system building. Say more?

Yeah, building a system that uses an LLM internally ends up more like applied science. In normal programming you get deterministic results. When you embed an LLM you get this thing that kinda does what you want some of the time, so you have to deal with the rate of failure in a methodical way, and you tweak things to improve the rate of failure. So its quite a different way of programming.
This is different than using an LLM, coz in that situation you have a goal and you are both coordinating to achieve that goal, so some of the work gets done by you (e.g. code assistance). If you are giving an LLM powered product to lots of people, you have more unknowns and you can't apply test-driven-development or anything like that. So its different. Its still development, but its quite different to distributed systems where the rate of failure is relatively low and there are clear reasons why it behaves the way it did. LLMs you are programming where every function call is a roll of the dice modified by free text. The methodical way of taming that is evals at scale, which doesn't fit in a CI process, costs money etc. etc.

<@UCUSW7WVD> Focusing on the experience makes this a much clearer exercise!

For quantum computing, the main experience is the paperwork of getting access to one. Once you do, it feels much like batch processing in the past: you submit your program via some front-end (a standard computer), and wait for the result. The program has syntax much like a standard program, but its semantics are wildly different.

Analog computing is more interesting. It feels much more like doing an experiment in a lab than like running software.

Naive question (apologies in advance): What does convention vs configuration mean in a visual programming language? Are there interesting examples of this playing out in practice?

If I understand the question correctly...

I see it as a tradeoff between expressive power in the visual medium and reducing cognitive load to accelerate the production of "known patterns" of run-of-the-mill software products.

But I don't think that's the only reading. At the granular level I think some conventions in some visual programming paradigms flow intuitively from humans working with materials and do result in the medium feeling ready-to-hand (say, dragging cards around on a 2D canvas, or inputs grouped and separated from outputs)?

I guess if one were to lean hard into the distinction as used in textual programming, conventions (as opposed to configurations) are stronger than that--it's not that inputs and outputs are usually grouped for clarity, but that what _makes_ them inputs and outputs are the fact that they are grouped in a certain way.

This reminds me of an old USENIX talk that I found very inspiring, on Eidetic Systems, aka recording every input into the OS, write only, forever

<https://www.usenix.org/conference/osdi14/technical-sessions/presentation/devecsery>

With that, you can roll back any local computation, branch off of it, etc.

Still trying to work out how much ought to be the OS's job and how much ought to be the App's job

And to what degree the owner of the computer or data should be able to override eternal storage, to prevent this from becoming a privacy nightmare.

Right. You can always replace "old snapshot -&gt; inputs" with "new snapshot" and prevent any history from moving past the new snapshot. Its also possible to make this choice separately on a per-conponent basis.

I also think if someone other than Microsoft is doing it, then it's less of a nightmare. I don't want their sketchy AI adware looking at screenshots of anything, but being able to scrub backwards on my own 'version controlled' OS sounds lovely. Git, Ink&amp;Switch CRDTs, Browser History etc. all record a pretty detailed history as a feature

Microsoft inspecting your history is probably the worst-case scenario. But if history is stored at all, it presents a privacy risk. Imagine your computer being confiscated by the police of an authoritarian state with the goal of finding something that can justify putting you in jail. You'd probably prefer to be able to erase such information completely (and verifiably).

Oh totally! That's true of all useful data though. I agree it would need controls to be able to manage what's on your computer and what risks you're willing to have.

Same way it's very nice to have version controlled document history but you can also rewrite or delete it when you please

Trying to stay on topic, when have you most feared clicking on something? How could you have been reassured via humane programming language experience design?

I just had one of those fear-of-clicking experiences. A frequent one for me, being cause by Zotero. Every now and then, when I visit the site of some scientific journal, Zotero Connector (a Firefox extension) displays a banner asking if I want it to install a proxy for accessing this site. I have no idea what consequences this would imply. I have no idea either if Zotero is aware of the complexities of my journal access setup (which involves an OAUTH site and a certificate stored in my browser). So I see a lot of risk of breaking something, in exchange for an advantage that isn't quite clear to me.

The worst: I cannot tell Zotero to leave me alone. About once per week, it asks me again. And I fear that one day, I will click on "yes" by mistake.

Ah I'm quite fearful of zotero as well! In theory it's great for sharing references and PDFs with a group of people, except it's very easy to do destructive operations that can't be undone, and then are difficult to spot that they've happened. I've had to rebuild community bibliographies from scratch, so I'm particularly fearful of accepting someone's application to a group, in case they accidentally delete stuff.

I guess fear can be quite a useful emotion as well. E.g. fear of pressing 'submit' on a funding application you've been working on for months helps you with double checking everything is OK.

It's quite hard relating this to programming though, as things you do are generally low stakes at that moment, unless you're live coding.

clicking on an email or message that I'm nervous about reading

i find notifications scary. big red warning signs with growing numbers inside them. it would probably be less scary if they were more subtle, less attention grabbing

Typing not clicking but the sudo command used to really scare people with a "This incident will be reported." error message as well as giving a slightly odd message the first time you successfully used it

Every time I switch my car on I have to accept terms of use that allow the manufacturer to track my movements. Similarly the terrible Google, meta etc terms we accept every day as a mild annoyance to access some community should really strike fear into us but doesn't..

hitting "send" on a message you're not sure about

Just reading a PhD thesis "What live coders fear most is a bored audience." So mistakes, unintended behaviour, crashes are all positive, but smooth running, fulfilled expectations etc are potentially to be feared

right, standing there frozen, panicking and doing nothing!

There’s so many sites where if you click on an item in a list, it will take you to it, but if you hit back, you’ve lost our position in the list. So I’m constantly afraid to click on any list item anywhere without command-clicking to open it in a separate tab.

Have you seen this? I liked the Cultural perspective of it: <https://www.youtube.com/watch?v=08PPuE-Y1sE>

reflecting on jam oriented programming...

i can't believe i spent so many years being dictator of my projects. what a waste. 

i now do the jamming approach... it means i MUST accept all changes, even if i disagree with them. if i care enough, i can change them or revert them, but that takes effort, so they usually stay. and for ease, i make everyone admin of my own project. if you submit a pull request or an issue, i just instantly merge and make you admin. then i don't need to be a blocker in future: you can commit straight to main

it means the project becomes ten times richer because it's a team effort with everyone pulling it in different directions

nothing has to be perfect, and it gets done FAST.

it's more open than open source. it's jam source! 

each day it becomes more hilarious/tragic to me how most HCI and "future of coding" developers keep things so closed off and secret, now that I've experienced this better way

This reminds me of an article on how the default of the web is implicit feudalism. Feels similar to how we make software.

<https://www.colorado.edu/lab/medlab/2021/01/08/implicit-feudalism-why-online-communities-still-havent-caught-my-mothers-garden-club|https://www.colorado.edu/lab/medlab/2021/01/08/implicit-feudalism-why-online-communities-still-havent-caught-my-mothers-garden-club> 

right! thanks for the link. I've been thinking how github repos default to dictatorship, and how unhealthy that is for the ecosystem

there's some more info about jam oriented programming here: <https://www.pastagang.cc/paper/|https://www.pastagang.cc/paper/>

it's a work in progress paper intended to be submitted in about a month. the paper is getting jam written by tens of people

Curious what things you see github doing?

Does the main branch have protection on by default? Although it certainly nudges you towards that by the notification to set branch protections

Image from iOS.jpg

Also maybe helpful for your paper <https://unite.un.org/news/open-source-initiative-first-endorse-united-nations-open-source-principles|https://unite.un.org/news/open-source-initiative-first-endorse-united-nations-open-source-principles>

no it's nothing specific to GitHub, rather that the whole open source approach of benevolent dictator is shit

when you make a repo, only you can edit it. pull requests need to be reviewed by the glorious leader

to be clear i personally wrote like less than 5% of the content of that paper

Rebellion is fairly cheap in the world of open-source though. A dictator can usually be toppled with a single fork.

One problem I see with forks is that they are asymmetric. There's always "the original" and "the fork". GitHub makes it very obvious which is which.

Something I'd like to try is a pool of repos that are equals. Everyone can see everyone else's changes, adopt some and reject others, but without any notion of hierarchy or convergence to a consensus version. Git allows this, but today's forges don't. I am not aware either of any tool support for working in a pool of equals.

having one big jam repo is great honestly. being forced to accept every change (even the ones you want to reject) is important

Story time: back in 2009, some people on Hacker News got together to create a community fork of Paul Graham's Arc Lisp that anyone could modify. We called it the Arc Wiki and I suggested the name anarki. <https://github.com/arclanguage/anarki|It is still around.>

Back then Github had a setting to let you make a repo public so anyone could push to it. It disappeared around 10 years ago, in a move to be more enterprise friendly that nobody remembers anymore, and that seems minuscule compared to everything they've done since.

When that checkbox disappeared we adapted to it by saying <https://arclanguage.github.io/|anyone can get push permissions>. Just come ask.

I was obsessed with the Arc Forum to an extent that I still find my fingers typing out the url when I'm out walking. My fingers dream that it is 2014 and they're at a keyboard. The forum never had more than a half dozen people but it was surprisingly active for its size. The forum was the jam session, anarki was just a tool. On one level my story since has been about trying to find ways to make the jamming more acute, all while finding the jamming get less acute.

I sense that there are many ways to create jamming scenes. I've seen projects like Tiddlywiki and oh-my-zsh start out extremely permissive in letting people add changes to them. Over time they slow down as it gets harder and harder to make changes while maintaining any sort of sense of stability or continuity.

So it depends on what different people want. These days I think it's all an experience. Random walks and sprints to a destination all have their place, and they mix together in the world anyway if you think of it all as one giant repo under the sky.

Today I maintain 50 or so forks containing various apps, but none of the codeforges can tell that they're forks of each other or determine which one is the root, because I clone and reupload each fork from scratch. That information _is_ in the git logs. They're true git forks arranged in a network rather than github forks arranged in a tree. The jamming still doesn't happen, though. <https://carlos.bueno.org/2010/10/predicting-the-future.html|The future seldom cooperates.> Still, I feel I'm going somewhere interesting, and so is everyone else.

Prosperity and computers have radically expanded the space of things humans can do. As we expand into this space the default density of people drops. Each of us homes divergent urges to explore alongside convergent urges to explore together.

&gt; Over time they slow down as it gets harder and harder to make changes while maintaining any sort of sense of stability or continuity.
&gt; 
i guess this is a big part of it. letting go of stability and continuity (and control) is an important part of jam oriented programming

Yeah.

It's not just stability and continuity for the author/dictator. Every community has a tendency to prioritize the needs of people who show up early on. The minority in the present captures the infinite future.

there's certainly that risk for sure. much less risk than *not* taking the jamming approach i think

Reminds me of the do-ocracy we practiced in our shared flat in my 20ies: Anybody is allowed to change anything (in the communal rooms). Everything is shared (except toothbrushes) BUT no hard feelings when you just undo anything. To make this work we had semi-regular meetings where we talk real, little playfights in the hallway to resolve tensions and regular shared meals. Not sure how that can be transferred to the net. I think this physical presence/contact was crucial.

this kind of thing has been happening at <https://pastagang.cc|https://pastagang.cc> for quite a while now

and very recently <https://pondiverse.com|https://pondiverse.com>

Yes. I discovered the pastagang before. Watched you jam in awe but did not dare to touch the contraption. Too much stuck in old patterns I guess.

It's interesting to see that all of you mostly focus on the permissions aspect. For me that's rather secondary. With git, everyone has a local copy, so nobody can do serious damage to anyone else. So let everyone have whatever permissions on a shared repo, that's an administrative detail.

What I miss for peer-to-peer collaboration is discovery and exploration tools. I'd like to be able to check easily what everybody has been working on over the last week. Or find the branches across all repos that have a specific version of some piece of code. And I am not thinking only of jamming, but also of long-term, slow, asynchronous. Code that a hundred people use, but which only sees two or three changes per year.

perhaps it seems only secondary to you but it isn't at all! the whole point is that you *want* to subject yourself to the danger of other people's changes on yourself

I guess this is the wikipedia approach. They have to have moderation tools at that scale, but the model is still allow-first and worry-later.

For live-coding, I wonder if different languages would allow this to scale better. Eg if you have 1000s of people editing an imperative program, at any given point it probably doesn't run at all. But in a dataflow program, if part of the graph is broken then that part of the graph just doesn't put out values any more, but everyone else is still getting feedback on what they are doing.

i'm hesitant to suggest that different or new languages are needed because i want people to know that this approach is possible to do already with our existing tools - especially on the live coding front. see <http://www.youtube.com/watch?v=HCcSHMu0gzg|http://www.youtube.com/watch?v=HCcSHMu0gzg>

and yes, part of the "agreement" of a jam is that: yes you can make any edit. this also means that anyone can reverse your edit. 

there are other strategies you can take to scale and influence people's behaviour too, other than central control

<@U03R0B9U1GD> So you don't keep a local repo at all? The shared one on a forge is the only one you have? Or is it simply a social convention that the current state of the official repo is the only one from which anyone may move on?

I've always done that with my discord servers - everyone is an admin , anyone can change anything , disputes are resolved with pleasant conversation. Moving that policy from a small group of friends I know personally to anyone on the internet seems scary to me but I might just not be letting go enough. Cool to think about

<@UJBAJNFLK> 
i guess i do keep a local repo but it's often out of date because i often make edits via the forge ui itself. and it's not really the point. anyone can do anything. who knows what will happen when it inevitably all gets deleted

<@U089PPWPXT9> there's certainly a lot you sacrifice by doing it. there's a lot that's off limits, like auth, because it would make you too vulnerable. the community does a lot to try to keep itself "healthy". and people sometimes talk about the eventual inevitability of things getting mass deleted. it was covered on this episode of the pastagang podcast
<https://www.youtube.com/watch?v=x7Z6Uo4torg|https://www.youtube.com/watch?v=x7Z6Uo4torg>

the recurring "let code die" mantra is part of that.

Whether you look at the short history of social networks, the longer history of human societies, or the even much longer history of biological evolution, you always end up concluding that open communities (i.e. those that let anyone join by default) need an immune system to defend against hostile takeovers. So when I see these stories of "anyone can do anything", I wonder if they are about open communities that have been lucky so far, or about open communities that do have immune systems, even though they may not be explicit.

Question to <@U03R0B9U1GD>, <@U089PPWPXT9> and anyone else involved in such communities: Do you have an idea what would happen if, say, nazis move in? Has something like that happened already?

making sure we keep bigots out is a fairly regular conversation topic within the live coding world and places like pastagang. there are lots of different strategies you can take, which look very different to the ones you adopt in a more traditional hierarchical organisation

there are too many to list here really, but they include embedding activism deep into the community, making it clear who is (and isn't) welcome. and the "anyone can do anything" thing is actually helpful for this. i don't expect many people to understand, i would instead encourage you to try participating and see for yourself
<https://pastagang.cc|https://pastagang.cc>

to answer specifically, the nazis would be kicked out by the overwhelmingly larger number of non-nazis! if that fails, then we would let pastagang die and start again with something different. ("let code die").

there have been some bad actors, and they have never lasted long. sometimes they've been frustrated by how unbothered people are when they clean things up and/or invite the bad actor to join in. someone once tried to make bad/unpleasant sounds happen in the public jam room, and everyone flipped it on them by incorporating their sounds and contributions instead. in terms of content that NEEDS to be removed, the "anyone can do anything" thing means that moderation happens MUCH faster than traditional organisations.

there are certain ways in which we can alter the "physics" of collaboration. eg: deleting is much more powerful than adding within the nudel tool. undo is blocked. pasting is blocked. this means it's much easier to clean up trouble than create trouble

This thread is making me reconsider my current project some-
the current idea is a collaborative rube goldberg machine where anyone can add on to the end of it and keep making it bigger. Got a cool infinite grid design based on <https://cs.wellesley.edu/~pmwh/labyrinfinite/>
The plan so far was to divide the grid into squares and anyone can upload a PNG to have it added in, after a quick check that it's not trolling / hate. Once added its permanently there.

Trying to imagine myself as an uploader -
There is something nice and comforting about being able to have a section of the world that you added and you can show off to friends later without worrying. And you'd be able to have your name attached to it and give the 'tile' it's own title. The inspiration was of being a gallery, something like <https://www.collectionrert.org/> where anyone can add a work to the collection but your work itself is not open for modification

But at the same time, it would be cool to have someone add something to what you've made, as a nice feeling that your work was something inspiring for someone else. And the UI for just drawing straight on the live work would be really slick.

Towards jam coding specifically: there are a number of times that I've come across a project with a trivial mistake somewhere, a typo in a readme or out of date documentation or other very small very obviously correct change, and I've wished it was possible to just make that change there and then so that everyone can benefit. But, of course, github does not make that flow easy

Github with a wikipedia style flow would be a very neat project

I wonder if there'd be some way to add a somewhat more trusted group of testers that can flag specific revisions as being particularly workable so that this idea could mesh easier with Library development as compared to App development or Live Performance

& last little thought, but now that I live next to a light rail station, I've often wished that they had brooms/trash cans so I can tidy up a some while waiting.
I imagine there's a good reason there isn't any, since no trash cans in particular seems too obvious to be an oversight.

Thanks for the details <@U03R0B9U1GD>! Looks like you have a nice immune system. Much like a bacterial colony, or more generally swarms of roughly-equal individuals. An anarchist's dream!

<https://openopensource.github.io/> was a handy summary to link to for "we're liberal with push access here" although that site's <https://github.com/openopensource/openopensource.github.io|repo> got archived.  It still recommends PRs for pre-merge review of non-trivial/breaking changes.

Pieter Hintjens (RIP) was outspoken on "Optimistic Merging" (great name imho) e.g. <http://hintjens.com/blog:106|blog>, <https://alexschroeder.ch/view/Optimistic_Merging|book excerpt> — which is more radical, closer to what Lu describes in saying that merging a _bad_ change first, iterating later is a feature, not a bug.

I don't quite get the explanation why a toxic patch can be forced through under PM but not under OM though

the more I think about it the more I like it though. Instead of keeping the main branch perfectly clean, or worse the entire repo, instead it can be signing off on specific tags, or moments in time only

One potential issue I see with universal push access, as opposed to optimistic merging, is bad actors using automation to do harm. If you are really determined to kill a project, you could create a new account on GitHub every day and use it to attack the repo. Has this been observed or discussed?

<@UJBAJNFLK> Reason doesn't help here. Yes, bad things are possible. One can never anticipate everything. What you need is faith; _before_ bad things happen there is more room for good things to happen. If bad things happen we just pick ourselves up and build it all up again somewhere else.

One can never anticipate everything, but every living organism needs to anticipate as much as possible of what can threaten its survival. So...

&gt; If bad things happen we just pick ourselves up and build it all up again somewhere else.
... this means that the repo is not important for survival (of the team). No obligations attached, no responsibilities. That's a rare privilege.

wikipedia pulls it off, but also they have more nuance than always merging immediately (some articles are locked etc) but it's still their default

the strategy makes sense for me for a repo thats not immediately getting deployed somewhere, such that whoever is responsible has a chance to look things over

I also think things like CHERI and fine grained sandboxing can improve this. it's less of a risk for end-user-app type things if the possible fallout is contained

hopefully reverting a malicious change is as easy as denying a malicious merge request, so the only difference is that the repo will temporarily be in a bad state

but in general I really think this is a good strategy if you want people to contribute to your project. I edit Wikipedia for typos etc way more than github docs because its so much easier

<@UJBAJNFLK>:

&gt; this means that the repo is not important for survival (of the team). No obligations attached, no responsibilities.

Yes my sense was that is already assumed by the fact that incompatibility is not checked for or protected against.

Malice as a difference of degree in incompatibility?!

<@U089PPWPXT9> Wikipedia is indeed an interesting case because it has evolved, over many years, a very effective immune system. Neither too weak nor too constraining. The motivation for the questions I have been asking in this thread is finding other cases of effective immune systems for large-scale collaboration.

<@UCUSW7WVD> I guess you can define malice as severe incompatibility, though I am not sure it's a very helpful definition. Incompatibility comes at different levels of severity (easy vs. difficult to fix or work around), but also at different levels of social organization (incompatible with the latest version of gcc vs. incompatible with the values of the project founders, for example).

Catching up with everything...

The rules of "open open source" seem pretty strict and fight against some of the benefits of jam coding. we tend to encourage people to test on the main branch and in production. it brings you closer to your fellow users. you shouldn't go and hide away in your rabbit hole.

<@UJBAJNFLK> I think another effective strategy is obscurity / small scale

trolls don't tend to show up while you still have a small nice community

I think its worth considering using that advantage while you have it

still catching up... I very much agree with the observations on OM vs PM. 

<@U089PPWPXT9> the argument is that OM nips toxicity in the bud, while PM gives it lots of attention. I've certainly seen this myself, with bad actors getting bored very quickly when people just delete or revert (or embrace - their least favourite outcome) their code

<@U089PPWPXT9> It works for a while. In the long run, someone will find you. Ask <https://en.wikipedia.org/wiki/Dodo|the dodos> for their experience with this approach (if you can find one).

i need to catch up with all these messages at some point

In terms of biological analogies, this is colonies of single-celled organisms (OM) vs. multi-cellular organisms (PM). Both forms of organization have been around for a long time. Both have their ecological niches. Different strengths, different weaknesses.

&gt; One potential issue I see with universal push access, as opposed to optimistic merging, is bad actors using automation to do harm. If you are really determined to kill a project, you could create a new account on GitHub every day and use it to attack the repo. Has this been observed or discussed?
&gt; 
not observed but discussed. people in these jamming projects prepare themselves for this kind of possibility. the ability to 'let a project die' gracefully is embedded into the culture. "let code die" is thrown around non-stop. it's the thing i see newcomers struggle with most. if the project gets ruined that's okay. there's an acknowledgement that the value created is not in the code we write but in the interactions we have and the things we learn as a collective. there will come a time where a project needs to die. a bad actor might speed up that process! it'll make space, and free up energy for something new! this is a healthy part of the cycle

<@UCUSW7WVD> is right: bad things might happen, but there is a much higher chance of bad things happening in a traditionally hierarchied(?) project

&gt; .. this means that the repo is not important for survival (of the team). No obligations attached, no responsibilities. That's a rare privilege.
&gt; 
that's correct. this is the whole point and approach of the "slippy mindset" as a potential solution to the "tadi web" problem. if you can allow yourself to be in a situation where death of code is okay, then you unlock SO MANY possibilities (including jam oriented programming)

&gt; the strategy makes sense for me for a repo thats not immediately getting deployed somewhere, such that whoever is responsible has a chance to look things over
&gt; 
what's the point in a piece of jam code that doesn't get deployed? the whole point is that it gets instantly deployed. that's what makes it a jam! 
there are certain precautions you have to take like: make sure you unimplement any auth systems that get added. it can't be relied on because it would be easy for someone to steal your cookies or logins or whatever. "jamming" is an infectious activity in that sense. it encourages you to create other jamming tools

regarding malice: Sometimes it is very hard to determine what is "malice" and what is "someone getting confused" so it's best to take on board any change even if it seems bad! why not take the jam in a malicious direction for a bit. let the tool die! let it crash! why not??

i do think that obscurity helps. it's not watertight but you're in the game of numbers and chances, so of course it contributes. of course it doesn't last forever. nothing does. not me or you or any of us or any of the code we write. everyone and everything will die. until then, it's good to do things together!!!!!

re: not deployed, I was thinking in the context of an app that's running on your computer or with accesses to stuff that ought to stay private. For something like a public art piece or properly sandboxed tool then absolutely!

this is why I'm so excited abt stuff like cheri, genode, sandstorm, because I'd love to be able to run any software and be worried only about it being buggy and weird, and not about it messing with things outside of its scope

if there's no sort or reward in terms of being able to mine bitcoins, steal juicy data, be part of a botnet, or disrupt specific groups, then i don't think anyone has any reason to be malicious and won't. for my upcoming project its just a nice website. I'll serve it via an iframe or something and feel very safe that the worst that could happen is easily reverted vandalism and the best that could happen is beautiful and spontaneous ideas from people that would otherwise never have bothered

also, inspired by this thread, im looking into how hard it would be to build wiki-style live code updates into the website such that if anyone changes it, then it changes for everyone immediately, without needing to download the code, edit offline, and push

Thanks a lot <@U03R0B9U1GD>! Code as an ephemeral cultural artifact, like street art, is something we (i.e. society) need a lot more of. If only to develop the elusive "computational literacy" that people have been talking about for ages but always tried to achieve by design and top-down deployment, with roughly zero effect. But beyond any considerations of literacy, it's simply a great way to develop creativity.

I am looking at this from a very distant point in the code universe. My work is scientific research on biomolecules, and that's what I write code for. This is work that others will build on years from now, and it might end up becoming relevant for developing medical treatments. Which explains why the value system of research is very different from jamming: everything needs to be traceable, inspectable, verifiable. And yet, science needs the unbounded creativity of jamming as well, and I see it disappearing due to the growing complexity of software stacks and the (justified!) bureaucracy generated by traceability. Which is why I am asking all these questions: to figure out how jamming and science can be made to coexist.

<@U089PPWPXT9>
&gt; reward in terms of being able to mine bitcoins, steal juicy data, be part of a botnet, or disrupt specific groups ...
The specific group being disrupted could be your jamming group. Science is currently experiencing such attacks (and not just in the US, even if elsewhere the attacks proceed more slowly and less openly), which is why I am quite sensitive to this aspect.

Yeah totally, I'm trying to work together my thoughts on this too. For example, for a lot of tools I like leaving updates completely off so that things only change when I want them too. Big frustration re: windows. Jam coding that updates everything I use always would be like living in a big house with no room to myself

I think there's definitely something to the SQLite / Dwarf Fortress model of accepting no contributions so everything you're working on fits in your head. Same for the "make what you need / use what you make" style indieweb projects where its for yourself and given to others as an added bonus and contributions accepted based on usefulness to you

But if the point is to form a community all improving the code I think there's something to the Optimistic Merging style in making it as easy as possible

will catch up on this thread in time but for now check out this blog post that someone wrote about the jam style of coding they've experienced in the pondiverse
<https://cthulahoops.org/collapsing-the-pondiverse|https://cthulahoops.org/collapsing-the-pondiverse>

they published it today

<@U03R0B9U1GD> This remark from it is :bulb:

&gt; One intriguing idea around the Pondiverse is that <https://github.com/TodePond/Pondiverse/issues/19|things should be centred on types of creations not tools>. It shouldn't just be about showing off the tool creators work, it should be about making tools that can be used to create.
One question I've aimlessly had without resolution is how to add native apps to Pondiverse..

&gt; how to add native apps to Pondiverse
Isn't that just the old question of interoperability between Web-based and native code? Or is there some additional obstacle?