chrisdone

The Economist stylized this as “tweets are appraised as speech, but punished as writing.”

I’m working on https://inflex.io/ which can achieve the data / logic separation of Improv, by putting functions in cells. But Improv isn’t an inspiration. Inflex is certainly closer to it than Airtable though.

I see that it supports units in terms of scale - does it also prevent units that measure different things from being combined? E.g. 2 kg + 3cm (units mismatch) or 3$ * 7$ (two monies can’t be multiplied).

Airtable is strongly typed in the fields of the tables, but the expression language is not. It is my conclusion based on researching Airtable, that the decision to have well typed tables is so that relational operations work nicely, and so that they can implement interfaces on top of these tables easily, such as calendars and work planning things etc. I don’t think that there is an underlying motivation to fix the ill-type code of the world, so to speak. Any non-trivial code work is done in JavaScript, anyway.

I commented elsewhere in this submission that I am working on a strongly typed spreadsheet. (Don’t want to spam my product link.)

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.

I am working on a product which is pretty much exactly what you describe. I love spreadsheets but I wanted something that I wanted to actually program in right from the beginning to the end of my work process.

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. :)

I like your work on Mito, and I feel like it’s the python answer to a project that I’m working on which is the equivalent but with Haskell, or rather a riff on Haskell to be more amenable to spreadsheets-like programming.

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.

SPJ has been coming at this from the angle of let’s add things to Excel because Excel itself is already established.

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.

It’s my understanding that the main selling feature of AirTable is the hard coded views that they offer; calendars, kanban style planners, things like that. The slightly more structured nature of relational tables over spreadsheets lets you implement those fairly reliably.

Someone said the problem of WhatsApp is network effects. Network effects are fine.

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.

Not that, but Unison is one direct inspiration. I wrote a small overview here https://community.inflex.io/t/the-inflex-language/20

A paper that profoundly influenced my language design: “Programming with Polymorphic Variants” https://caml.inria.fr/pub/papers/garrigue-polymorphic_varian...

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 : <Just Int|v>      case v of ‘Just 0 -> ...
              [open; note the row var v]  v : <Just Int>
                                          [closed]

That may be a cultural difference. You may see the EU as having a "very lax work ethic", but in my experience working in the EU, they see America (and Britain) as having an unhealthy work obsession.

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

The recent Unison language uses the effect system described in the Frank language https://www.unisonweb.org/

I agree. I read the same passage and had the same complaint.

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.

There's a StrangeLoop talk about teaching programming by Felienne Hermans (https://www.youtube.com/watch?v=g1ib43q3uXQ) that claims that all fields have an "exploration vs instruction" debate on how to teach their field, but this debate is apparently absent from the field of programming for the most part, wherein the "mess around and figure it out" exploration style of LOGO and Papert ("every time you teach something, you deprive a [student] of the pleasure and benefit of discovery") is the predominant unquestioned wisdom. Felienne wants more pedagogy fights. It's a worthwhile talk. I love LOGO and I think our generation of programmers are very sympathetic Papert's philosophy due to most of us being self-taught to some degree (you can see the fond nostalgia already on display in the comments here), but Felienne made me think about it more critically.

Reiki does not involve touch.

I think Decision Fatigue has a long and rich treatment in the Buddhist and specifically Zen tradition. One of the true practical daily takeaways from Zen teachings I can share is that dithering and hesitation are acute forms of suffering and akin to a broken record repeating.

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.

That's an interesting angle. Another way of saying it might be that GoDP on the face of it can make one-off proofs for a value. Proofs for a function requires making proofs about all possible inputs, which is where your property test comes in handy. I could have `Named a (List x -> List x -> List x)` as the function I'm proving things about.

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!

Techniques like Ghost of Departed Proofs are the most exciting thing to me as a casual correctness enthusiast. It acts as a means of combining static types with contracts.

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.

My email server (@chrisdone.com) has been running for a year and a half and is written in Haskell, saves all mail into a postgresql database, has a web interface and an Emacs interface. https://github.com/chrisdone/duta

I redirected my gmail account to forward all emails to this new domain, and changed all my account emails to theservicename@chrisdone.com e.g. for github it’s git@chrisdone.com. Once I’m done, Gmail won’t be receiving any new mail.

It has SPF which has captured most spam. I haven’t implemented sending yet. I thought this would be a problem initially, but after a year I’ve realized I rarely send personal email out. But I’ll do it one day just for completeness.

I’ve found two bugs of my server, which were easy to debug because mail sending is very robust. I fixed the bug, and the sender server tried again the next day automatically.

I did it for exactly the same reasons as the author, to control my own data. I wrote my own because existing open source offferings are silly complicated, but receiving mail is not.

Duta is easy to deploy with docker machine and DigitalOcean. My current setup has been deployed like this. It connects to a managed DO Postgres database, which runs separately, has monitoring and backups, so it’s easy to redeploy the mail server without worrying about losing my data.

Ghost of Departed proofs provides a fairly trivial way to generate proofs from arbitrary code and track them in the type system. See this article for example: https://ocharles.org.uk/blog/posts/2019-08-09-who-authorized...

This post shows a simple "positive" assertions, without any combinatorial logic associated with the proofs. But this is similar to programming by contracts.

I think physical comedy just has a broader audience, which worked well in silent movies and thereafter. The broadness is also why it’s considered cheap and used sparingly. It’s like shouting. As Friends went on and the writing got lazier every character was shouting all the time.

But a recent example of a well done pratfall I saw in a show mostly about dialog and editing was Modern Family (season 2) where Cameron turns to give his husband a kiss who pulls back (due to discomfort with public displays of affection, the theme of the episode) and Cameron overleans and falls head over heels over the back of the sofa quite roughly; he’s a big guy too. I laughed a lot partly in surprise because I basically never see a pratfall in comedy shows I like.

Fat clients of all kinds (cryptocurrency wallets, medical devices, data analysis, log viewers, etc.), depends on the client.

After our bad experience in 2016 using GHCJS on a big project, we haven't considered it for anything since. Anything that arrived after that related to GHCJS just hasn't been on my radar ("a history of my own experience in this problem space").

Elm can be looked at like Haskell on training wheels, in a good way, and that simplicity very likely contributed to its popularity.

We already tried Fay as a team (15kloc codebase to write an IDE), which was literally Haskell without type-classes. We've learned that we want type-classes, YMMV.

I think that the lumbering hogs we call publication web sites these days are making sure that you as a reader are paying a cost to use their otherwise free web site; paying a subscription is better, but no one will do that. People on mobiles pay a tax that people on desktops don't, and people on bad connections in poor areas pay a tax that people in rich fibre-wonderlands don't, and yet energy and money is wasted on transferring garbage that nobody wants.

I seem to get dismissed whenever I suggest this, but these web sites could instead try another approach: remove all the garbage, have a beautiful, clean web site, and implement artificial rate limiting on all connections to it. If you want a super fast experience, pay a subscription! What are the upsides?

* Less bandwidth and energy and mobile phone battery is wasted.

* The site will still load in the same time that people are normally used to anyway.

* Rich people and poor people get the same experience; you don't pay a poor people tax if you are poor. Equity!

* Mobile phone users don't pay a tax, either.

* Meanwhile, Rich people have disposable income; they should be spending money on magazines and newspapers that people are producing anyway, to show their support, but they don't, so here's an incentive. They also indirectly support the poor people with news/media, who can't afford to pay a subscription (or wouldn't benefit anyway).

Isn't anyone trying this model?

I read in New Scientist that they've discovered a way in mice to turn off the connection between pain receptors and the emotional response to pain in the brain. So the mouse feels the pain in the sense of recognising it, but doesn't have a negative feeling associated with it. That's like a half-way point; you wouldn't injure yourself accidentally (as the woman), but you also wouldn't suffer if enduring chronic pain.

https://www.newscientist.com/article/mg24132143-900-silencin...

It's Google. The only company that hears everything you say and listens to none of it.

That depends on the medium used to view the web. On my KoboHD e-ink reader, grey text is not legible. It's sad because thousands of web sites that would be gorgeously legible if their text were #000 are not. But this is more of a browser issue; Kobo should disable colors IMO. And this is something that people can do on regular browsers.