I’m using one of them, but only one. This looks like the start of a fun advent calendar.

I use one of them (Glamorous Toolkit) regularly, but not for everything. I was aware of perhaps half of the systems in your list, so I have a good excuse for the other half: ignorance.

My main reason for not using any of these for most of my coding is weak (or absent) ecosystem support for my application domains, plus past investment into other ecosystems.

A special mention goes to the Wolfram language, which would be a great fit for much that I do but which I do not use at all because of its proprietary nature. Even if I were personally willing to spend the roughly 1000€/year they charge for academics, I would seriously limit my collaborations if I expected my collaborators to do the same.

Because I ask myself these questions:

• will it be around in five or ten years? will this language/library be a liability for the company?
• how will it limit my use of other libraries, tools, languages, etc?
• how confident am I that this won’t embarrass us in production? will I spend a week tracking down some weird performance thing?
• will another engineer understand what’s going on? will the next person roll their eyes and rewrite everything in javascript?
• how much of a distraction will its strangeness become? how much political capital will I have to spend on the decision to use it?

It’s rarely a question of features.

GToolkit’s sidesteps a lot of this if you use it as an IDE. I don’t use it because it seems like getting any value of it involves a sizable investment in learning the interface, language, and libraries, and I can get by OK exploring an API or whatever by using a REPL.

It means a lot that GToolkit has been around for a long time and is being used by professionals solving real problems in the real world.

💬 #thinking-together@2024-01-26T17:05:18.921Z

Being too far ahead of your time may not be very good for you personally, but your example can end up being helpful to those who come after you.

Meeting people where they are, and being ahead of your time, are orthogonal, I think. The more ahead of your time you are, the more necessary it is to meet people where they are. Something that is very different is not therefore necessarily alienating, or difficult. It can be different precisely because of how much easier it is. But if something very different is also very difficult, it will have far less influence than it might have otherwise. Always meet your users where they are, whether you want to make evolutionary or revolutionary change. And if you can't, get different users, or make different changes.

First question: what does "a good thing" mean? Good for the author? For the field? For society? Short-term or long-term?

Relevant: steveklabnik.com/writing/the-language-strangeness-budget

Sometimes it makes sense to invest in something you know is very unlikely to be mainstream, because you’re trying to push frontiers; sometimes you’re specifically trying to take previously frontier ideas into the mainstream, and those have very different tradeoffs.

A good example here is the difference between Rust and the research languages it drew on. Rust itself (the example used to make a related point in the post I linked above) needed to be pretty mainstream in many of its surface syntax choices, even if the language designers might have preferred other syntaxes, because it was bringing along so much novelty in terms of type system, how it was asking people to think about systems programming and memory safety, etc.

Similarly, TypeScript’s success is very much a function of being a very small syntactical superset of JS, and being purely a way to express statically what (a[n ever-growing] subset of) the dynamic behavior of JS code is. Other compile-to-JS languages have had much less adoption, and TS has significantly changed the baseline for what kinds of type system constructs “mainstream” developers consider reasonable/normal as a result.

But on the other hand, even still in relatively mainstream programming (by comparison to a lot of the stuff we chat about in here), Elm has had comparatively minimal adoption, but has profoundly influenced the design of many other compilers and languages, by staking out a position and design ethos which have in turn shown that (for example) the baseline we were all used to and accepting of from compilers was not actually a necessary baseline, and that it could be much better.

I like cartographic over spatial because apple has overloaded the term, recently.

ieeexplore.ieee.org/document/9320477 used diagrammatic programming as a subgenre of visual programming

"spatial" is becoming very overloaded recently, with apple adopting it for their VR stuff. I use it to specify that it's "not sentential programming". I took it from SPLAT, which stands for Spatial Programming Language with Ascii Text.

but i misused it - I took the wrong part. the thing that makes it "non-sentential" is the ASCII TEXT, not the SPATIAL PROGRAMMING. it compiles to Ulam, which also works with spatial data, but using a sentential syntax.

essentially I don't care what terminology i use for it. the key thing is that I show how to program by arranging before-and-after diagrams

Spatial programming definitely goes way back. I've mostly seen it used in a similar sense to how Apple are using it, so it doesn't bother me too much. (But I haven't travelled much in the automata circles)

The term I like is "graphical programming", but I've also learned that this term has some historical usage I don't agree with.

So I'm kinda with Lu. It's like trying to describe musical genre. I don't mind doing it for other music, but for my own music? No. Never.

I'm just going to make the things that interest me and let others figure out what to call them.

(I've been told I make prog rock, which feels about as mortally offensive as claiming "node-wire" is a programming paradigm)

Oh I really like "cartographic programming". Maps are all about integrating continuous space with discrete markers, and textual labels and they work really well. The metaphor also works for me in terms of the relationship between code and what it represents, being like the relationship between a map and territory.