I do think that bringing new syntax to the table is justifiable if it brings new concepts with it.

I agree, power query is essentially a separate product and doesn’t feel first class. I think that probably explains its relative obscurity, despite being highly powerful.

It’s called Inflex: https://inflex.io/

And it is a pure functional programming language, with cells, which are reactive, and with real data structures like lists and records. We have a work in progress beta. Sign up requires a paid subscription, but only because I wanted to make sure that the infrastructure was working. To try the work in progress product, you can just hit Try which lets you play in a sandbox. It doesn’t save or remember any of your work, and also doesn’t even hit our databases. (Safe from the hug of death.)

It’s pretty bare-bones right now but it’s based on ideas from Haskell, and Unison which is a content addressable language. (Every cell has a SHA512 hash of its content.) That makes versioning very easy, but this is not seen in the UI yet.

The table editing and what not is a little cumbersome right now, as there are a lot of things to come together and I wanted to demonstrate at least some of them.

Speaking of clean separation between data and display, The plan is to build for example reports using a simple HTML like DSL. Also, things like time and external data sources will be treated in the type system as explicit streams, which is an architecture that has been fully explored in Haskell under the guise of FRP.

But I’m working on this in my spare time and therefore progress is turtle pace rather than silicon valley pace. :)

One thing that you can do when you have a pure functional programming language is rather than generating separate cells for modifications, you can go into the code and modify it directly fairly reliably.

I’ve linked my project elsewhere, don’t want to spam the thread.

This, in my opinion, is putting lipstick on a pig. The inputs and outputs work represents a very stretched contortion of trying to do real programming in a limited environment.

I am coming at it (commented elsewhere in the submission my project, avoiding spam) from the other end: start with a fresh, language take all the tried and tested programming language research useful to this way of working and connect it to a UI which fully comprehends this language. Throw out the grid and coordinates.

Row types, polymorphic variants, FRP for time/streams/events, type classes for arithmetic, CAS for cells, etc. We really do know what works, and therefore we can actually start from scratch and have some thing that is actually nice to use.

Email benefits from network effects. The difference is that email is designed to be decentralized and from the beginning had many clients with open protocols. IRC similar. And of course, the web browser itself. DNS.

Back when these were invented, people had many different operating systems and architectures, so the protocol was more important than the client/server. Today, we have about three platforms: web, iOS and Android, meaning you can reach millions of users with software rapidly, rather than the slow way of pushing a protocol. There’s less incentive to have decentralization and there’s money to be made. Protocols require cooperation and therefore move slower. SMS and IRC and email don’t feel modern because they move at glacial pace of cooperation.

I think therefore it’s harder today to push a decentralized, more free protocol than it was when we had more OS/arch diversity. When in a quasi-mono-culture, protocols take a back seat. People don’t ask about it or know what they are. The ratios are flipped: we have basically three OSes and a very large diversity of app/services all incompatible and each locking you in.

And the earlier paper “A Polymorphic Type System for Extensible Records and Variants” https://web.cecs.pdx.edu/~mpj/pubs/96-3.pdf

Row types are magically good: they serve either records or variants (aka sum types aka enums) equally well and both polymorphically. They’re duals. Here’s a diagram.

              Construction                Inspection

    Records   {x:1} : {x:Int}             r.x — r : {x:Int|r}
              [closed]                    [open; note the row variable r]
    
    Variants  ‘Just 1 :       case v of ‘Just 0 -> ...
              [open; note the row var v]  v : 
                                          [closed]

(Work to live vs live to work, perhaps.)

I just finished a Great Courses lecture series on the Norman conquest of England, and the professor makes this very comment. And also argues that the melding of Norman--not 'French', Norman was a sister to Old French that looks more like Vulgar Latin--and Old English is what gives modern English its vast vocabulary, roughly twice the size of Spanish; as many words have the Germanic and Romance varieties. You can 'meet' someone or 'encounter' someone, etc.

Ironically, "Norman" comes from "north men", as Normandy was settled by Scandinavian invaders who "went native" in France. Then they "went native" again in England, forgetting their original Norman.

A zen master may deliberate on a question, but will never dither. When presented with a choice, do the thinking it deserves but no more.

A simple example: you're looking at a menu and they all look good. Pick the first one or the one closest to your finger. It doesn't matter.

Also, don't cheat and be deferential; "I don't know, which would _you_ like?" Practice actively choosing. It'll do wonders in your daily life.

With some template-haskell you could run the property test at compile-time, and then use that proof later (e.g. for an instance of Semigroup which would require a argument proof of associativity), in languages like Unison that never run the same test suite twice (due to Content addressable code), this would be feasible. Or just run the property in your test suite and hope that the developer runs the test suite often. GHC erases data types that aren't actually evaluated in many contexts, so we even have erasure too.

I like your angle!

Types are sound mostly because they are a stupid mini language, so easily enforced, like you said. Contracts are practical and convenient because you tend to write them in the language or a subset thereof that you’re checking. That’s hard to ignore.

GODP has you write a runtime check in regular code, and return as a result a proof value. Put that code in a module boundary. Then you have upstream functions expect a proof argument along with the value the proof is about. They’re tied together with a unique type variable (rank n or existential are the mechanisms of delivery for Haskell, but may differ in other languages).

head :: NonEmpty n -> Named n (List a) -> a

In this way you started from a dynamic, runtime piece of code, and ended up using a static type system to just ensure everything is passed around correctly which is trivial.

A single proof in this technique is nominal in the type (e.g. not null or positive or sorted ascending/descending), but combining them is done at the value level so there’s flexibility.

The bang for buck potential is large. I’m more interested in stuff like this than the dependent types direction that people are pushing for in GHC. If I wanted dependent types I have Agda, Coq, Isabelle, Idris, etc. to play with.