-Coders at Work by Peter Seibel (2009)Seibel: For you, what about the relation between research and actually programming?
Peyton Jones: Oh, they interact a lot. My area of study is programming languages. What are programming languages for in the end? They’re to make it easier to program. They’re the user interface of programming, in effect. So programming and programming language research are deeply related. One thing we’re not good about is this: the proof of the pudding is in the eating, so you should watch programmers eating. That is, you should do proper, formalized studies of programmers programming and see what they do. And that’s jolly expensive. And it’s also more “squishy.” It’s harder to come up with unequivocal results.
So the culture of the programming-language community is much more, “prove that your type system is sound and complete,” kind of stuff. We dodge, probably, the more important but much harder to answer questions about whether, in practice, they make people more productive. But they are questions that are really hard to give convincing answers to. Are you more productive writing a functional program or an object-oriented program to do the same thing? Even if you could spend a lot of money on doing serious experiments, I’m not sure you’d come up with results which people would actually buy.
While languages are for people to make things, it's easier to measure nice little properties. Which might be interesting and even suggest usefulness, but ultimately what matters is the projects people make - the proof of the pudding is in the eating.
Haskell might "avoid success at all costs" to research new ideas; Gleam lacks this caveat, stealing existing features (message passing, sum types) with friendly syntax and tooling.
So what things are people making? Where is the pudding?
I see more libraries than applications, but the proof of libraries, like languages, is what applications people make with them. Today 1587 packages are available on packages.gleam.run and maybe not all are good but many made by core Gleam people are pretty good. What I don't see as many of is Gleam applications, although of course libraries are naturally shared whereas there's no central applications.gleam.run repository.
Applications are also important because useful libraries are extracted from applications; libraries don't just come out of nowhere. It is fun to take an API or spec and model it in Gleam types. But what makes code good is contact with the real world. Which means a fresh pile of AI slop is not useful, but also even when writing code yourself, you have to think starting with real problems in the world -> applications to solve them -> reusable building blocks. A project solving a problem for people is the best sign you're doing something useful that, if reusable, you can pull out into a library.
And this not to say there are no Gleam applications. https://misprint.moe/ for instance lets you draw and print to a thermal printer! And it's enabled by libraries like lustre, plinth, envoy, mist, and of course starprnt. Again it may just be that libraries are more naturally shared than projects. But in any case I'd like to see more projects.
Part of this is probably me projecting my own concern about lack of progress on my own project. PotatoEMR is supposed to be a toy EMR, like a lesser OpenEMR in Gleam/FHIR, and what I should do is look at what people using EMRs need and try that in the project. But one thing OpenEMR does is export immunizations to hl7v2, because that's what US vaccination registries use. So I got sucked in to trying to generate Gleam types for hl7v2.
Which is not even a bad idea necessarily, but without contact with reality is very likely to be a waste of time. For one thing, it seems like real world hl7v2 users may define their own messages and even violate the spec, and if the data irl is too messy to parse into types...the types aren't so useful. Or maybe there won't be a need for this at all, who knows, it's impossible to say for sure without real users with problems.
I got as far as generating hl7v2 datatypes/segments/messages, with each thing_new and thing_to_string, but still not sure about parsing thing_from_string which is the hard one. Also just leaving dates etc as plain String. If hl7v2 is super common maybe I will come back to this, idk. But in terms of "is the juice worth the squeeze" I need to start with what problems OpenEMR users have.
A good question after all of this application talk would be why not just work on OpenEMR directly, which has had much more contact with reality? Well, I think FHIR in Gleam is very nice in a few ways: