https://joshondesign.com/2021/01/14/intro_hl from @Josh Marinacci looks really cool. It can be tried online in https://apps.josh.earth/hl/, and there is a Github repo https://github.com/joshmarinacci/humanist_lang

I really like the design prompt here: Filament is a tool for thinking about things, not shipping production software. Two open-ended feedbacky thoughts that spring to mind from that: 1: I think the language could push much more radically in the direction of the design prompt, and away from conventional programming practice. Some (easy, top-of-mind) ideas... Rather than:

select(contacts, where: (a) => a.type == DB.person and a.category == DB.contacts)
  >> for((f) => f.latlon = lookup_lat_lon(f.address))
  >> draw_geomap( coord: (f)=> f.latlon, label: (f)=>f.avatar)

Why not:

contacts
where(.type == DB.person and .category == DB.contacts)
each(.latlon = lookup_lat_lon(.address))
draw_geomap(coord: .latlon, label: .avatar)

What's changed? • Rather than explicit lambdas with named parameters, any expression can just refer to an unknown input object. (So

.type == DB.person and .category == DB.contacts

is a function) This isn't actually even that radical: R's dplyr does something like this. But it's a nice increase in speed-of-thought fluidity, at the expense of things software engineers care about, like explicitness and infinitely-nestable composability. • Perhaps the pipe operator (>>) will be so common it will be better to have successive lines automatically connected with a pipe. (If you want to stop a pipeline, just add a blank line in the middle.) • [other minor changes] I think much more radical & less obvious changes are possible, but it all starts with breaking away from something that looks so much like JavaScript. 2: Maybe @Josh Marinacci is already thinking about this, but the design prompt also calls strongly for a new interface for using this language. In particular, these pipey step-by-step calculations really want automatic visualization of the data at every step! And a really slick keyboard-driven interface that lets you move around the pipelines at will! Etc. I hope this work continues to evolve – would be great to see where it goes!

Strong R+tidyverse vibes in the examples. 🙂

Sorry I’ve been MIA. Thank you for the wonderful feedback. Yes, it feels too javascripty right now. I want to break away from that. One of the big decisions i’m wrestling with is whether to have real objects with dot notation. Currently it’s purely functional with only array index dereferencing.

I'd be curious to hear why you might want to not have "real objects", if my understanding is correct that "real objects" here means "records" – values with labelled sub-values. It's hard for me to imagine a legible system without them! (I suppose I'm familiar with the SICP "define a datatype with a bunch of cons cells and then write a bunch of constructors / getters / setters" approach, but that seems like a total bummer in practice...)

@Joshua Horowitz One can have a

map

type that provides named sub-values without creating closed types, for example

@Jack Rusher Oh I see; I wasn't thinking about types at all. (I think the distinction you're mentioning is just a distinction of types?) I had guessed @Josh Marinacci was deciding if his language should have any "named sub-value" values at all.

@Josh Marinacci would have to clarify, but I read it as "foo.bar"-style "object with member" kind of stuff, as opposed to nested maps-style. 🤷