A common programmer beliefs is that our main way of programming — editing mixed imperative/functional languages in text files — is suboptimal, and we need to advance beyond this. The "improvements" include structural editing, visual languages, "dynabooks", etc. Some thoughts on this: - ThreadSky

hillelwayne.com • 41 days ago

A common programmer beliefs is that our main way of programming — editing mixed imperative/functional languages in text files — is suboptimal, and we need to advance beyond this. The "improvements" include structural editing, visual languages, "dynabooks", etc.

Some thoughts on this:

Comments

dfeldman.org•41 days ago

Visual dataflow programming is incredibly popular for graphics, games, music, and control systems in electrical engineering. Planes fly with autopilots built visually in Realtime Workshop. I wouldn’t say it’s a failure, just that it tends to work in certain well-defined niches.

hillelwayne.com•41 days ago

I'm one step removed from a project auditing Simulink code and have Seen Some Shit. But yeah I definitely was just thinking about general purpose programming here, not DSLs

elucidating.bsky.social•41 days ago

I find the entire idea we're at the maximum for textual medium kinda wrong, because there is so much in the margins of academia that is surprising, powerful and good yet the mainstream doesn't touch due to training issues.

If we are at a maxima, it's for the way the industry sources talent.

hillelwayne.com•41 days ago

Please share!

elucidating.bsky.social•41 days ago

Well I like to gesture to Idris 2. It can do a lot of the things that people associate with llm autocomplete. But it doesn't use ml it uses types.

That language is the labor of love and subject to study for one man but imagine if the resources put towards golang or rust went to it.

elucidating.bsky.social•41 days ago

An awful lot of the work of a programming language these days is excellent tooling, excellent compilers, and a lot of thoughts towards usability in the library building. Things very small projects can't really provide. So I just too is by no means a thing you should go use now. But it's provocative!

elucidating.bsky.social•41 days ago

Erhem, Idris2

hillelwayne.com•41 days ago

@edwin.type-driven.org.uk

elucidating.bsky.social•41 days ago

Another really provocative thing is Julia's macro system. It's much friendlier to use than rust's macro system however it allows you to make incredibly powerful things if you're willing to roll up your sleeves.

elucidating.bsky.social•41 days ago

There are whole types of programming that we don't do because we haven't really explored efficient syntax for expressing those ideas. Data parallel programming is a great example where only a few languages even try to make this feel native and well furnished.

hillelwayne.com•41 days ago

I think it's true that we're in a local maximum, and that a better world is possible. The problem is we got to this maximum through lots of trial, error, and practical experience. Most of the alternatives presented work well in theory, but run into major issues in practice.

hillelwayne.com•41 days ago

The third most viewed StrangeLoop talk is "Stop Writing Dead Programs", where the author argues that compiled languages like Rust are "dead code" and we should be using "live/interactive" code, like APL or Pharo or graphical languages. Room was packed, but...

https://www.youtube.com/watch?v=8Ab3ArE8W3s

hillelwayne.com•41 days ago

I had firsthand experience with quite a few of the languages discussed, and many of them had serious shortcomings he glossed over. Sometimes essential, sometimes accidental: one smalltalk dialect he praised could only be run in a special IDE that lagged out on my high-performance workstation

hillelwayne.com•41 days ago

I don't think it's impossible to escape our local maximum and get to a better world, as seen with Rust, Zig, TLA+, Jujutsu. But the key is to think about how we can get there without making things worse in the meantime. IE if structural editing is better than text, how do we smoothly migrate?

hillelwayne.com•41 days ago

Often this means moving in baby steps. LSP and treesitter are two of the biggest structural editing advances this century, but were made for, and 99% used for, text-based editing. You can't just jump all the way to the "better world" (if it even exists)

ltratt.bsky.social•41 days ago

Agreed. And I speak as someone who's done quite a bit of research in this area (with the general aims you're suggesting).

hjvt.dev•41 days ago

I think the interesting space is not in moving beyond textual editing, but in moving beyond storing programs as flat plaintext.
Something like a sqlite database individually storing - versioned - procedures and types would already unlock so many new workflows.

mvsamuel.bsky.social•41 days ago

`diff` and `patch` are so central to how teams combine individual contributions that any advance needs to work with them or come with replacements.

joachimschipper.nl•41 days ago

I agree, and I’d put enforced autoformatting in the same list: it takes a text-based language at least some way to a token-based language.

(Autoformatting really isn’t new - GNU Indent is ancient and was itself not the first system - but it seems to have gotten a lot more popular lately.)

hillelwayne.com•41 days ago

This, too. We've developed a lot of powerful workflows for our current local maximum, which raises the barrier of any new approach. One reason why jj is currently growing faster than fossil or pijul https://bsky.app/profile/mvsamuel.bsky.social/post/3lpcf3nqnac2u

channingwalton.bsky.social•41 days ago

I’m interested in what you think of the ideas in @unison-lang.org

martinfowler.com•41 days ago

I'm intrigued by the possibilities of moving beyond text editing, but agree with you that such things haven't yet proved practical. I wonder if LLMs might carve out a route in that direction.

mb21.bsky.social•41 days ago

Jup. Every intermediary step needs to be viable. https://newsletter.squishy.computer/p/evolution-adjacent-possible

kentbeck.com•41 days ago

The thing about tools that use a 1-dimension vector of characters is that they don't exclude any new options. If we operated everything from ASTs, there are novel things that would become much harder. That said, I'd really rather manipulate an AST directly.

aidenfoxivey.com•41 days ago

https://plutojl.org has struck me as a very neat interactive way to program.

Especially given how precarious my relationship with Jupyter Notebooks are.

ocschwar.bsky.social•41 days ago

One of the algorithms for coming out of local maxima is called "basin hopping," and the analogy here is ways to convert from one paradigm to the other. A graphical interface that produces readable code in Rust, for example (e.g. Pictorus).

ocschwar.bsky.social•41 days ago

Or a notebook that tracks which cell executions are responsible for the current cell and which are not, and outputs a script that only includes those. Or a typed checked language that can be analyzed to produce a Simulink like call chart.

nekotachi.bsky.social•40 days ago

i think Unison is a worthwhile point of reference, although it still has some issues.

bram.xyz•41 days ago

I actually find it very useful that I can diff different versions of my source code.

It's plausible that a good diff will exist for non-textual languages, but I'm not certain about that at all.

bram.xyz•41 days ago

I actually deem it likely that one of the super important aspects of languages will be just unacceptably bad for non-textual languages. Maybe it's diffability, maybe auditability, maybe something different altogether that we just accept as given now.

bram.xyz•41 days ago

Another common wisdom is that you should choose the best tool for the job — including your programming language.

One might say you're choosing your abstractions. And all abstractions come at some price. Pick your poisons.

internetgeorge.bsky.social•41 days ago

The elixir, bram, agent86, and process emulation (simulink) comments all point to the benefit of dev experience for a wide variety of DSLs and expert systems. This will stymie / pigeonhole some and nourish others. The others find it good background for diff and choice architecture ideation but

internetgeorge.bsky.social•41 days ago

I wonder having said this, doesn’t a hypothetical trainee still have to go 'through' it to arrive at this starting point?

Does it practically / administratively make more sense to train someone through the imperative / functional process *into* structural / type or can one begin anywhere

internetgeorge.bsky.social•41 days ago

I wish I had the scope of experience, time, and support to give a lecture titled: “better” vs “more powerful” (the debate at the center of choice architecture)

madamesosumi.bsky.social•40 days ago

I disagree, programmers are hostile to anything that isn't text and built around Unix. Lisp and Smalltalk environments are far more productive than the ways we usually write code in and Unix is an OS built for the 70s that doesn't adequately serve modern needs.

ayourtch.bsky.social•41 days ago

i have a sort-of working PoC of a Rust editor which slurps the entire project and then the unit of editing is a function or struct or type, and one navigates by usage graph “Jump to definition” / “give me a list of users/callers of this item”, or search. It’s super convenient.

Comments

Posting Rules

Reply