The Economist stylized this as “tweets are appraised as speech, but punished as writing.”
752 karma · joined January 15, 2008
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 : <Just Int|v> case v of ‘Just 0 -> ...
[open; note the row var v] v : <Just Int>
[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.
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.
This post shows a simple "positive" assertions, without any combinatorial logic associated with the proofs. But this is similar to programming by contracts.
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.
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 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?
https://www.newscientist.com/article/mg24132143-900-silencin...