Personally, I don't think anyone who can't code should ever be allowed to be a product manager. A product manager will be making countless decisions whose impact on a product only a programmer can understand.

I’d strong disagree that a product person necessarily needs to know how to code, but that’s a total side topic for now. To the OG question, I’ve seen similar situations where this worked as an opportunity to extend or add configuration options — stuff that wasn’t available to end users, but that could be fiddled with on a per-client basis by in house folks familiar with the system.

I fall down on the opposite end of the spectrum from @Personal Dynamic Media — but an issue here is we might be imagining different ideas for "product" and "changes".

I build tools for non-technical artists, who use these tools to do programming-like tasks and ship their work straight to prod. I've built these tools to give the artists plenty of rope to hang themselves (and our customers) with, but also the adequate context, training, documentation, and features to make it so that the benefits vastly outweigh the risks and occasional mishaps. (And I, the senior programmer, also occasionally ship something that has avoidable bugs. My programming ability doesn't save me from being fallible, heh)

Something to further define for this question is what qualifies as a change in this context. Like, if you have an apartment rental site, does adding/removing apartments qualify as a change? I suppose not a very interesting one at least, and it's something that has basically been solved. How about defining the sorting logic in search results? Changing visual styles? UI layout? Adding new data field to apartments.. Many of these have specific challenges and solutions when it comes to non-coders making changes. As a whole this question is basically about low/no-code solutions and the current industry approach is to have domain specific solutions as a generic one would start to resemble a general purpose programming language..

But @Sophia Deng I'm curious, what kind of changes would you expect Product Managers wanting to make?

Having worked with several product managers who do not code, it's attention to detail and consequences that matters. These thoughts can happen mostly in the application domain, I only need to add info about computational and visual constraints.

That said, the value of making "direct changes" depends — since building a domain specific editor usually, unfortunately requires a shocking amount of development.

I used to work with this guy who shares a lot of links.

His solution is to sync his notes (where he tracks links) up to a website that generates an RSS feed at a regular interval. That RSS feed is plugged into a channel at slack. He left the company, but that channel lives on.

I like that links are colocated with the notes. I don't love that they're organized linearly. Interesting either way, and I love that their channel is living on

Thanks for sharing!

They’re also ordered by category in a tree view slightly lower. The top of that page is just like the ten most recent.

probably orthogonal, but may offer ideas: I am currently using Kinopio (kinopio.club) for keeping tagged notes and brainstorming and minutes for the Toronto Lisp meeting group and TODO lists and archives. Kinopio runs in the browser and can run on my desktop and my phone and can be shared with others (private, read-only, world write/collaboration.). The Kinopio API allows direct automatic manipulation.

Interesting. I haven't seen this before. I'm going to have to play around with it

The person behind Kinopio has a lovely essay on what they call “organic software”

The rabbit hole goes deeper!

once upon a time I tripped over a bunch of parentheses and I landed in APL and 6502 assembly. I haven’t found my way out, yet.

stares at APL model M siting on the shelf. shutters

emperor palpatine do-it dot gif

Maybe pushing data to Prometheus and having that as a data source in Grafana? prometheus.io/docs/instrumenting/pushing

My understanding was that Prometheus doesn't have persistent storage? Essentially I want to retain this data forever. It's on the order of a few hundred data points per day.

Yeah, it might not be the best choice. Are you looking for an existent service or is it something that you can set up yourself? One possibly very stupid idea might be to just Google Sheets API and push data into a spreadsheet there. A small script could handle the notifications too.

I guess I was hoping for an existing solution. 😐 But if that fails I'm not above spinning up a couple of docker containers. What I'm trying to avoid is spending time doing sysadmin stuff down the road.

So far it seems like maybe I could use influxdb + grafana and maybe that would be persistent. Not sure...

I haven't tried this, but maybe writing to postgrest wrapping a postgres db, with Grafana providing the graphs? Postgrest is a smidge intimidating, especially the auth situation, but maybe still easier than handrolling something. Otoh, a very small single-endpoint web server that writes to postgres, which is read from grafana, might be a good compromise... (Thinking out loud at this point)

I ended up trying a lot of stuff. But ended with hosted InfluxDB + Grafana. Works well enough. Influx has a POST Rest API, and it's all pretty easy to query in Grafana.

Luckily Influx has a pay-as-you-go permanent storage option, too.

Hadn't tried postgrest, though! I considered TimescaleDB which is on Postgres, but it requires you to map out the schemas in advance.

The other contender was Graphite, which is essentially built just for this purpose, but it's pretty old and kludgy.

Also, there was a suggestion that you could go from code to blocks by normalizing the code (standardizing whitespace, etc.) and then using some sort of evolutionary approach to build up a change to the block representation that has the same output as the text. Does that strike anyone else as WILDLY silly? The other approach I saw was adding the additional content relevant for the block language (e.g. X&y coordinates) as comments, and writing a JavaScript AST to Blockly XML transpiler. More reasonable, but limited to those two specific syntaxes, which seems short-sighted, and there are things that you can change in the text that will not survive round trips, which seems like a usability problem. Their use case was only to let AI write code, though, so that doesn't matter to them.

It’s a matter of semantic content and of discarding information. It is easy to go from a language that has more semantic content to a language that has less semantic content. But, it is difficult to go from a language that has less semantic content to a language that has more semantic content. Semantic content comes in forms other than sequences of characters (or sequences of vector graphics), e.g. structure and layout mean something to human readers. Going from Haskell to assembler makes sense, but, going from assembler to Haskell does not make sense. Likewise, if the VPL is any good, then going from VPL to code is easy, but going from code to VPL is difficult. N.B. if code->VPL were easy, it would imply that that the VPL adds no new information and is, therefore, redundant. A decent VPL should contain semantic meaning that is difficult to express in code. Hence, IMO, it makes no sense to even try to “round trip” code->VPL.

For an example in a very different field - math - we are taught that we can multiply matrices, but, that we cannot divide matrices. Robert Distinti has developed a way to divide matrices and blames previous failure to do so on the fact that too much information is discarded by current methods.

Aside: Note that, to me, a VPL is a hybrid of graphics and text (see SVG, for example). There is/was a field called “Design Recovery” that researched possible approaches to recovering semantic information (I witnessed such techniques being used for fixing Y2K problems, which would have been lessened if they had kept the source code and would not have equated “dates” with girls’ names in some of the code).

There are reasons to develop visually that don't have to do with adding semantic information. And the reason to be able to round trip might be to facilitate collaboration between people who prefer different interfaces, visual or text.

At least JetBrains MPS has been used to create DSLs with both visual and textual projections as well as (at least) writing to text files. Also my "projectional language workbench" generates a "headless" "AST editor engine" which can then be used, as you said, anyway you like. It exposes both the linearized version (for textual projections) and the tree structure (for visual projections). Currently I've only been working on the textual projection (which is a lot harder issue), but adding a 'blocky' projection should be just about writing the UI code. To read and write actual text files to and from the AST, a parser and an unparser should be implemented. Certainly possible but there's extra challenge in keeping the whitespaces when parsing and only writing minimal changes when unparsing. When parsing, the whitespace info should be stored in the AST that is then modified by the projectional editor. Now, it would be quite a bit easier if you wouldn't care that reading a text file, doing a minimal change in the projectional editor and writing back to a text file might change formatting for the whole file.

One approach to the text file round tripping could be to have the contents always follow strict formatting rules. Then the parser wouldn't need to care about formatting and the unparser would always just write according to those rules.

I've gotten as far as concluding that each projection, text or VPL or whatever, needs to have format-specific metadata associated with each abstract AST (that is, each individual document). eg the text projection will remember whitespace, the VPL projection might remember position constraints, color, etc. You need to handle defaults for the first time you project into a particular format, e.g. initial whitespacing. Probably there are also other hideous edge cases, the absolute worst intersection of naming things and cache invalidation; I'm sure the off-by-one errors are just waiting for their chance too. (I'm also thinking of this in the context of, say, bidirectional sync of documents in different formats).

“There are reasons to develop visually that don’t have to do with adding semantic information.”

I would be grateful to learn more about this.

If your visual language is a one-for-one recreation of the text semantics, it may still, by virtue of being visual, allow you to use full words instead of symbols, illustrate the syntax structures, and make various kinds of syntactical errors impossible.

Andrew F that's more or less where I have landed, too. But it feels easier to just say all that data is liable to be forgotten when you save and reload, because you aren't editing the interface, you are editing the AST, and those details have no meaning inside the AST, so just deal. But maybe that's too unfriendly.

As an answer to both Jason Morris and Paul Tarvydas, friendliness is usually the core goal of a vpl. :) At least as far as I can tell. Otherwise we would just make people deal with syntax errors.

Can't say I have, but I'm interested what do you mean by this exactly and what would be the use case?

The use case for CNL is to make the (usually domain-specific) code readable, but writing it has been hard, because there was no way to stop people from typing invalid syntax, and the CNL syntax was so similar to natural language that it was difficult to remember what you can and cannot say. Block-based languages solve the problem by not allowing you to type. You must drag and drop valid syntax nodes and combine them. That's good, but the interface is unfamiliar for some people. Oracle Policy Automation allows you to type anything you want (in MS Word), and offers a search bar you can use to find valid syntax if you get messed up. It's more familiar, but very easy to make syntax errors. A structure aware XML editor would look and feel more like Word, giving non-programmers a familiar environment, but only allow you to type things that were syntactically correct. I'm imagining a sort of strict autocomplete. My particular use case is knowledge representation of statute and regulation, so my users are used to those things being expressed as documents.

I see. I think the viability of using XML editor for CNL depends on the details of the language and how structure aware the editor is. Some XML schema definition might be enough for simple language, but more complex languages are likely to require context sensitive syntax rules and even semantic understanding from the editor. I feel like you'll run into a hard ceiling at some point trying to define and enforce the structure with a schema. A language workbench able to produce textual projectional editor would probably be a safer bet.