Projects We Wish We Had Time For

Projects We Wish We Had Time For

We discuss the power of the Elm when paired with developer tools, and we go through our notes to look at Elm tools we wish we had the time to build.

PublishedAugust 29, 2022

Episode#64

Sponsor: CareRev

CareRev is looking for Senior Frontend Elm engineers (job listing).

elm-review-simplify
Elm Radio Root Cause of False Positives episode
Dillon's pairing session using snapshot testing prototype with Corey Haines
elm-snapshot-test prototype repo
Approval testing
elm-coverage
elm-instrument
Llewellyn Falco Gilded Rose kata video
Idea: intellij integration for elm-coverage
Idea: code actions for safe refactorings
Idea: elm-review integration in intellij
Idea: sparksp/elm-review-imports either new feature, or separate project to give suggestions to make all inconsistent imports in a project consistent
Idea: elm-review code actions
Idea: elm-review collection mechanism to gather data from an AST
Pairwise testing (or all pairs)
Idea: pairwise permutation API that minimizes the number of permutations to go through to get complete coverage
Idea: mutation testing tool for Elm (is Phillip's tool relevant here?)
Idea: generated API for elm-graphql but with factory-style API for mocking out data that is compliant to the graph schema, for use with things like elm-program-test
Idea: Browser.application wrapper that provides some common initial flags like start time, initial window dimensions etc
Idea: HTTP Error type to get bad status payload that can be shared between libraries to reuse the same type (similar to the HttpError type defined in elm-graphql)
Aaron's community-standard elm-color package
Idea: tool to automatically vendor or un-vendor Elm packages
Idea: elm-format in Elm
Idea: elm diff, but it gives you more detailed information about code changes even if they don't change the API
Idea: Phantom Builder analyzer that generates a state diagram from Elm code
Idea: suggest types based on what's possible in your current editor context
Idea: type inference and value inference in elm-review
elm-http-fusion
Idea: use a collection of HTTP requests to an endpoint in elm-http-fusion to gather better type incormation about an API
Idea: make tools like elm-http-fusion embeddable in the elm-pages dev server so you can interactively fix decoder errors, etc.
Idea: elm-pages dev server code actions from the UI, like scaffolding new routes
elm-codegen
Idea: use elm-codegen for elm-pages scaffolding for user-customizable templates
Official Elm blog post The Syntax Cliff
Idea: show ANSI color code error messages embedded in blog posts
Talk about the Hedy language: What every programmer should know about cognition by Felienne Hermans
Elm Guide translated into French
Idea: translatable error messages and language keywords for Elm
Idea: elm-css tool to make inline styles into static CSS files and replace the styles with a reference to the generated class. Goal: reduce bundle size and performance overhead
Idea: codemod tool to post-process Elm code using elm-review fixes in a hidden temp directory
Idea: Elm step debugger
Idea: elm/parser debugger to see the state machine of what has been consumed
Idea: Elm debugger improvements like filtering Msg types, customizable inspecting for certain types
Idea: inspectable Cmds in the debugger, or similar idea for debugging elm-pages DataSources to see why a failure happened and what the breadcrumbs are
Idea: React ink, but for Elm
awesome-elm-sponsorship repo

Transcript

You know what I wish I had?

Plenty of things.

Money, but I think you're going to talk about...

Money, power, soul, space.

More time in the day.

Doesn't everybody wish they had more time in the day?

I wish I had more time in the day, but I would also settle for a bunch of people working

on open source Elm tooling code.

That would be cool, too.

So not necessarily your time.

You want other people's time.

That is so greedy.

It's our time, our community's time.

What are we talking about today?

Today we're talking about the projects that we wish we had time for.

Time that resource sets, lets you do things, but that is necessarily in too little amounts

Always too little.

But at least it feels like that.

Especially for people with insatiable appetites for amazing Elm tools.

I think that to me, what makes Elm exciting is Elm is not exciting to me by itself.

It's kind of exciting, but it's only exciting because of what it enables you to do with

outside projects and tools.

Without that, I wouldn't find Elm that interesting.

Give a few examples.

I totally agree with you, but I want to know exactly what you have in mind.

This is what in my head sits under the label, the promise of Elm, which is when you work

within a constraint, you are sacrificing something.

We make a sacrifice, and what do you get for that sacrifice?

Certainly we do get immediate sacrifice within just using the Elm language.

We do make the sacrifice of not being able to perform side effects and mutations wherever

we want and pull down global state.

There are times when that shortcut would be helpful, but of course it does give us immediate

payoff in that we do end up making more long term maintainable code.

We do end up being able to reason about our code more easily.

We can build in constraints with opaque types and rely on them.

So there's immediate payoff just by using the language.

But to me, the really exciting thing about Elm is what can we use those guarantees and

constraints in the language to do with tooling?

For example, unit testing in a pure functional language is very exciting.

Elm test is a really cool tool.

It's not as much exciting.

It's just like the opposite of what you have in JavaScript or languages with mutation.

That is just painful.

In a way, it's delightful because you don't have to care about all these problems.

Delightful is such a nice word.

It is a nice word.

Delightful even.

Yes, delightful really captures that feeling of those things that we get from the constraints

we accept working with Elm.

But then, as you've talked about many times, Elm Review, the most interesting thing about

Elm Review is that it gets to work with the language with the guarantees that Elm has.

You take that away and it's not as exciting.

Just like Suik, I worked on a addition to Elm Review Simplify where I was basically

able to detect if branches that can't execute.

Therefore, I can simplify the conditions by replacing some conditions to true or false

or removing the if branches that won't execute.

That was quite complex to do, but it was so much easier with the fact that I can just

rely on the fact that there are new mutation.

If you see if x equals f of n and then you see the same condition inside of it, like

if x equals f of n, well, those are the same.

The result will be the same, so you can just remove the second one.

But if you had mutation or side effects, you're like, I don't know.

It was still quite a lot of work, at least to get to something that worked as I expected,

but it was so much easier than having to think about all the other things.

I only realized that after the fact, like, oh, this was easier.

I didn't even have to think about it.

That was really nice.

It's like the difference between a few pots of coffee and some weekends versus several

years of research with grants and a team of postdocs to 100% guarantee that those things

Well, actually, the reason why I worked on this is because this was a rule that exists

I noticed, oh, we don't have this one for Elm Review.

It's the only one that is missing from the recommended rules for ESLint.

So I just added it and then noticed the original one in ESLint actually can create false positives

because of the potential for side effects and mutation.

I'm like, okay, so I did something nicer.

But I also go a bit further than what they're doing.

Because you have more information working in the environment with Elm, like we talked

about in our false positives episode.

So to me, Elm is just ripe for tooling, which I would say that you and I really hopefully

demonstrate with our actions how much we deeply believe that because we really want these

tools to exist because they are, to me, what makes Elm really exciting and delightful.

So I have a bunch of things, sort of lists that I keep mentally and in my note taking

app of things that I think would be interesting, but I just don't have time for with all the

other things I want to build.

So I thought it would be fun to like dive into some of those.

And I would love it if, well, I would love it if I were magically given more time in

That would be great.

But I would also love it if hopefully this conversation inspired some people to pick

up some of these ideas and run with them or inspired them to do some other ideas that

have been on their lists or spark some new ideas in their minds.

So I would just love to see more people that we could welcome into the sort of Elm tooling

community because I think it's like such a cool space to be kind of innovating in.

I mean, if we can have more people working on the existing tools and new ideas, then

that would be amazing.

Today's episode is sponsored by Carev.

Carev is looking for senior Elm engineers based in the US for fully remote positions.

Engineers at Carev get to work on a meaningful product, bringing the future of work to healthcare.

Carev is a modern marketplace platform offering professionals the freedom to choose how and

when they work, tools and training to develop their careers, and personalized growth opportunities.

Carev is looking for Elm engineers who will have a front end focus and get to work alongside

their peers doing code reviews, working in an agile environment, and mentoring other

They use Elm test, Elm verify examples, and Elm review in their CI, as well as Tailwind

CSS and custom elements.

And they do multiple releases per day with fast builds, preview environments, and they

recently converted their code base from React to Elm, so the code base is as clean as it

The role is 100% remote, and it includes benefits such as comprehensive medical care, dental

and vision benefits, short term disability, covered 100% by Carev, life insurance, paid

parental leave, generous paid holidays and unlimited PTO, 401k and company matching,

an office equipment stipend, and a learning reimbursement program.

So if you're a US based developer who loves Elm and has five plus years of JS or other

front end web experience, reach out to Carev, take a look in our show notes, or search for

Carev, and a big thank you to Carev for sponsoring.

So I've got like a few sort of like criteria slash questions that I thought we could consider

for our ideas, which is like, what problem does it solve slash is it valuable?

How difficult would it be and would somebody else be able to pick it up?

No one can pick your ideas up.

Yeah, I tried to include some low hanging fruit.

Well you know what, I would consider it, I do take pride in trying to think about simple

As long as that may seem, I try to think about simple ways to get valuable things.

So I would consider it a personal failing if none of my ideas were things that people

could easily pick up.

Because I do try to come up with big bang for your buck ideas as much as possible.

Okay, so it's not only the world's ideas that you had.

Right, which those are delightful as well to think about at least.

Somebody to like dive into is less delightful.

All right, well, should we dive into some?

Yeah, absolutely.

So what is on your list Dillon?

Well, one of the areas that I think is really interesting that we still have a lot of opportunity

to explore in is testing in Elm.

I did a video with Corey Haynes a while back, which was a lot of fun.

He's a fantastic thinker in testing code craftsmanship in Elm.

So I had a lot of fun playing around with this concept of snapshot testing in Elm.

We did the Gilded Rose Cotta.

I'll share a link to the YouTube video.

I played around with a proof of concept, sort of hacked together just to demonstrate what

it would be like working with snapshot testing in Elm.

So snapshot testing is the idea that you have a golden standard that you...

Another term for it is approval testing.

So you approve a certain output.

Usually it's in some form or another.

At the end of the day, it's a string.

Even if it's JSON and you can compare JSON output in a more intelligent way where you're

not just comparing string literals and you don't care about the order of JSON keys, at

the end of the day, you're typically storing some output to a string and you're able to

intelligently compare that output to see if it's changed.

And if it has changed, then the test is read.

And if you want to approve the new test, you essentially are just committing that new approved

output as part of your test suite.

Yeah, so it would be a separate file which you commit to your Git history.

It's part of your Git history and you're saying, I intended for the output to change for whatever

It could be because I expect different results now that some code has changed.

It could be because my test has changed and therefore there's new output.

Or it could be that something changed and you didn't intend it to and it caught that

mistake and then you go and you fix the test by making the output what it was before.

So the reason I love this technique is, for one thing, it's a very easy way to get some

very valuable tests.

So I'm a big fan of approval testing.

I think it would be really valuable to have a tool like this for Elm.

So we did a demo of that proof of concept.

So what problem does it solve?

I think it does solve a meaningful problem of providing this valuable technique for us

How hard would it be and what would it take?

It would take making some changes into the Elm core testing library.

Yeah, so it would just be additions to Elm tests.

And probably some APIs around building up permutations of inputs.

That's like a common, you know, Llewellyn Falco has sort of a suite of approval testing

tools in different languages.

And one of the core things he uses in that suite of tools is an API for building up permutations

So you can essentially, like it's a really cool legacy testing technique to basically

feed in, ideally, something that's going to hit all the possible code paths and then just

say, OK, this is the current behavior.

It's really cool for like legacy code refactoring because you say, OK, well, we've now captured,

say, like all of these different conditionals that we're hitting.

We know we're hitting all those permutations of those conditions.

And therefore, we have confidence that we have coverage of all these code paths and

the like a broad range of their output because we've sort of just cast a wide net and cut

all these outputs.

And now we can go and sort of safely refactor things.

So it's a really cool technique for that.

Is there something to this technique that makes more sense in Elm than in, say, JavaScript,

in your opinion?

That's a great question.

I mean, I think just the determinism of Elm makes it a little more interesting that you're

going to have more predictable output.

You're going to have less flakiness because in general, when you're doing any sort of

end to end testing or higher level testing, unit tests tend to be more well behaved and

predictable in general, and end to end tests, the higher you get, tend to be more flaky.

Like interdependent.

One test impacts the results of another test.

And they start depending on global state and side effects and mutations and environment,

non deterministic things, what time it is, what day it is.

So for that reason, I think it's interesting because you can do like very high level and

sort of easy to write tests that cast a wide net and verify a lot of things, but in a language

that is deterministic.

So it's going to be less flaky.

So I think that's the main thing.

Otherwise it's going to be, yeah, and I don't know, maybe that offers some interesting opportunities

for like tooling around an approval testing tool in Elm.

But otherwise, I think it's going to be pretty normal.

Do you know if there's an issue already discussing this in Elm tests?

I don't think there is.

I did mention this idea once to Harry Sarson, who is actively maintaining Elm tests.

And he said he was interested in the idea.

So that's kind of cool.

So if I had more time in the day, I would definitely want to work on this.

Maybe at some point I will.

Maybe somebody else finds this idea exciting.

But I think it's a pretty interesting idea.

We said we don't have time for this.

That's the whole point of this episode.

You could maybe create an issue so that people can hop in.

Yeah, that's a good idea.

And I've mentioned this in the past, but I do try to like, sometimes I get ideas to completion

where there's a certain definition of the term completion.

In this instance, the milestone was like demo a working proof of concept to show what it

would look like to use this technique in Elm and what an API for doing permutations and

that sort of thing would look like.

So I do have a complete working prototype that's a proof of concept.

So I did get it to that goalpost at least.

And I do think that that can be a valuable technique to kind of share your findings and

show proofs of concept.

I think that can be a really good technique to just say, here's the thing I built.

And here's the artifact I wrote my takeaways and what I learned in the process.

In a similar vein, another idea that I think would be really neat is to so I think I know

what you're going to talk about.

So Elias van Peer, you can pronounce his name better than I can.

Elias van Peer.

Pretend I said it like that.

He's built some really cool projects.

One of them being Elm coverage.

I actually think Elm coverage is sort of an underutilized tool.

It works so well.

Yeah, but I think I kind of know why.

Why do you think?

Because we're ashamed of our code coverage.

Because the thing is like, we use type so much to make sure that things don't misbehave

and that they behave kind of like what we want them to.

And that like some people say it's either you write tests or you write types.

And obviously we can do both and we should do both.

But I feel like, well, most of the things are already handled by the type system.

So in essence, we tend not to write a lot of tests.

That has been my experience, at least in some projects.

And in those projects, when they run coverage, I was like, well, this is disappointing.

That's a good insight.

I also think it's just not, I don't know, people aren't as aware of it as they could

So, but it's a very cool tool.

How does it work?

Does it run Elm tests for you or does it take the output of Elm tests?

It runs Elm tests for you.

I think you can give it a binary to use for Elm tests.

But what it does is it...

I think it runs the tool and then it modifies the compiled JavaScript at some stage.

Just to add markers, like this has been executed, this has not been executed.

And then it compiles that information and creates a coverage reports for you.

It uses another tool that Ilias created, which is called Elm Instrument to instrument the

lines of code with something that hooks in and performs a side effect to mark something

So it works incredibly well.

It's very reliable.

And one of the reasons I think you're asking if snapshot testing is particularly interesting

in Elm for any reason, I think one of the reasons that these things are really compelling

to me in Elm is because if you watch Llewellyn Falco, I'll share a link to a video which

you and I have discussed a lot where he does this gilded rows cata.

It's what inspired me to do this demo of this proof of concept of Elm snapshot testing,

using that to guide building up a test suite and then doing safe refactoring around gilded

And these safe refactoring techniques, it's not just like hacking away at code.

It's this very methodical approach that feels more like provable steps where you have a

very high degree of confidence that your changes are not breaking and you're being very careful

not to mix changing behavior refactoring.

And these sort of techniques where you, so Elm lends itself very well to that sort of

technique of doing safe refactorings.

That's why I think it's really exciting.

The way Llewellyn uses coverage reporting in Java, I think it is in that example, maybe

C sharp, but is really nifty.

And in Elm, a coverage report is a little bit more compelling because it's a deterministic

It's not going to choose a different code path based on the time of day and things like

So yeah, first tests, but that's it.

That's a good point.

So the tool around this that I think would be neat is just an integration into IntelliJ

because, and I think that's one of the reasons Elm coverage isn't used as much as it could

be is just integration into tooling makes a big difference.

That workflow of having to run it every time you want to see the results and then open

up an HTML file.

So I would love to see an integration where you can hit the run test with coverage button

in IntelliJ on your test suite.

And you can then see inline coverage highlighting in your editor.

Just to clarify, we wanted it in IntelliJ because that's the editor that we would use, but if

someone was working...

I would settle for it in anything.

If you want to add it to language server protocol or to have it in VS code or VM or something

else, that's fine too.

But we would be happier with IntelliJ.

Yes, that's true.

So I think this is definitely something that somebody else could pick up too.

I think it's like a pretty well defined problem.

And I imagine that the editors already have some kind of support for that already.

We need to instrument in a way that the editor gets that information.

Yeah, that would be pretty cool.

So to continue on the idea about improving the editor and making small changes, something

that would be very useful is to have a lot more code actions in your code.

Like being able to say, well, I have this expression now wrap it in an if expression

where this value is in both branches with some dummy condition or not with a dummy condition.

And then, yeah, just have all of these kind of safe refactors that you can use, commit

and then combine so that you can get to the place you want to in very simple steps.

So I have an IntelliJ Elm wishlist.

I'll share a link in the show notes.

And I just think there are a lot of things that are pretty straightforward that would

be high value, a lot of bang for your buck items there.

Which are often already implemented for other languages like C sharp or Java.

That's actually an amazing source of inspiration is, I mean, kind of like you were looking

at ESLint rules and saying, what do we not have in the Elm community?

I think looking at editor tooling and saying, what do we not have in the Elm community is

really a cool thing to do.

And oftentimes, like with that ESLint rule where you were able to eliminate one area

where there were false positives in ESLint.

Similarly, like there are cases where a refactoring might not be safe in certain languages and

in Elm, it's just always safe.

So we can do even more with these things.

Yeah, I would love, it's been on my wishlist for a long time to just have the basic suite

of sometimes people call these like the sort of crud operations for editing.

Create reads, updates, deletes.

So like deleting, either deleting unused references or inlining, like if you inline a constant

or a method or an Elm function, if you create one from usage, you update either renaming

or and create can also be like extracting a method, turning something that's inline

code into a let declaration or a function, those sorts of things, moving things to other

So like I would love to have, I would love to be able to just fly through my editor key

bindings, making safe refactorings without worrying about whether I've changed behavior

and then commit, commit, commit, refactor, commit, refactor, commit, refactor, commit.

And then, okay, now that I can sort of read this code a little better, let's go make some

behavior changes.

That would be so amazing in Elm.

So I wish I had more time for that.

I've considered just saying, you know what, let's like try to make a paid tool so I can

just like focus on this for a while.

But I'm not sure if that'll happen, but it's, I really want this to exist.

Yeah, same here.

Like some of them are probably not that hard to accomplish also.

But it's like when you have a lot of these simple things, that's where you get a lot

In the same vein, like I would love to have Elm review integration in editors.

So VS Code already has it, well, LSB I guess, but it's not as performant as it should be,

I think, because it's not every time you want the review reports, it starts over again and

that's only going to work for a very small project.

And I don't think that people know about this feature a lot.

Like you have to go through the settings to enable it, which makes sense maybe.

But for IntelliJ, it's in a branch from someone who worked on it and is not available anymore.

So someone needs to pick that up and get that merged into the tool at some point.

I would just love that.

These workflow things, like really, there's one thing, like I've learned so much from

people in the sort of software craftsmanship circles.

And I used to go to a lot of conferences in that space, sort of agile technical practices

and coach teams on that stuff.

And I learned a lot from some really smart people who I respect a lot.

And I think there's a lot of knowledge in those circles.

And one of the lessons from all of that for me was tooling is not just a convenience,

it fundamentally can change the way you work.

It can qualitatively change the way you work when you have better workflows.

That's like being able to use shortcuts effectively, refactoring tools, testing tools, continuous

integration feedback, and things like getting review errors in your editor, being able to

respond to them in real time, like just shortening that feedback loop, right?

Shortening the feedback loop is so key.

And having better workflows for tooling allows you to shorten the feedback loop.

And that can really change the way you work with code in a big way.

So I would love to see that integration into the editor.

I remember when I was using Atom, there was a very good plugin called Elmjitsu.

I loved Elmjitsu.

Yeah, I loved Atom, to be honest.

And I really liked the editor.

I really liked the plugin.

But there was one feature that it didn't have that IntelliJ did have.

And I only learned that when I switched to IntelliJ, because my colleagues just said,

you should use IntelliJ.

And I was adding an import for something.

And because I didn't have this, I got pretty fast at doing it myself.

Like I knew, well, okay, I just type abc.foo.

So I go to the beginning of the file, and then I go a few lines below, and then I type

imports, and I type the abc.

And it happened pretty quickly for me.

But when I got to IntelliJ, I was like, well, use add import.

Yeah, well, that's a lot nicer.

Yeah, I love that feature.

And sometimes you can just refer to something and then say qualify import.

You can say add import.

If you do like adder.class, you say add import and it says, would you like to import HTML.attributes

Yeah, pretty cool.

Yeah, I think VS Code has that automatic addition of imports.

So when you do adder.class, it automatically adds the imports or something like that.

The thing that I noticed compared to when I was working with MQ2 was like, the import

names, they become a lot less regular from one file to another.

You have aliases that are not the same across all modules because it's too easy and you

don't know which one it was.

Well, that could be a cool Elm review rule.

I know that Sparks SB has built something.

Phil Sparks, he created an Elm review rule for checking consistent imports.

But the way it works, I think you have to declare in your rule configuration, the import

conventions that you want to use for an explicit list.

But I could imagine a cool version of that tool or feature for that rule that it could

automatically find inconsistencies in your code base.

I think that was in the talks back when he was working on it.

He's less active at the moment.

But yeah, that was definitely among the things that we wanted.

I don't know if that's the same rule or a different rule or a different setting.

Yeah, absolutely.

Yeah, I think there's a cool opportunity there.

And I mean, it would be very cool if it could just intelligently say, Elm review doesn't

– it's currently kind of binary where it's like, there's an error or there's not an

Do you want to not fix it?

But it could be really cool if it was like, hey, I found these two different ways that

you're importing HTML.attributes in your code base.

Would you like to use the first one or the second one?

And then fixes those with that input from the user.

Yeah, what it could probably do is find all the aliases of imports, and then it suggests

the more common one.

And then they know and go change it themselves.

That would also work.

That's a good point.

You could feed input to Elm review by putting a magic comment somewhere that's like, dash

dash at Elm review input for the preferred option.

As long as that's comments.

Yeah, I mean, why not?

You had the debug to do.

Where you insert HTML.

And that's fine because it gets removed after one iteration.

So that's fine.

It doesn't stay in the code.

Yeah, it could like the prompt when it tells you there are inconsistent imports could give

you different lines that you could copy paste into your code.

And when you copy paste that exact comment, it deletes that comment and applies that choice.

Actually maybe that would work fine.

Maybe that would work well.

I've talked to you about this idea in the past.

I think we've talked about it on the show, but I think it would be, this is a big idea.

This is not the well scoped manageable idea.

This is like a very big picture idea.

And I think you know what I'm about to say.

I think that Elm review code actions could be incredible.

I think that the pitch is basically just like you have code actions in VS code and IntelliJ

where your cursor is at a certain point.

There's the context of where you're sitting in the cursor.

And based on that context, there are certain actions available.

If you're on list.map, you could turn list.map into a fold L. If you're on a pipe, you can

remove those pipes.

There are certain actions that are available if you're in an if condition or a Boolean

condition of any kind and it's not this and not this, you could use De Morgan's law on

And that's not a rule.

That's not something that's incorrect.

That's just a transformation that you can apply.

It's not right or wrong one way.

It's bi directional.

You can go either way and they're both acceptable forms to have it in.

And so I think that would be really interesting if Elm review had a mechanism for in a performant

way in a way that hooks into the editor being able to say, okay, here's the context.

Here's where my cursor is.

Would you like to hook in and participate in contributing an action that can be performed?

And then you can you can say yes or no for your particular code action.

That's a user defined thing like an Elm review rule.

And then once you execute that, you get that context and you're able to perform something

like a fix, but it's not really a fix.

It's transformation.

Yeah, I feel like that's kind of the point of a language server.

The idea that you have behind this is, I think, the fact that anyone can contribute this idea,

even if it only makes sense for their project.

And just so that we have more cross ID tools.

Lower the barrier to entry and people can make some amazing things.

You could even imagine having a code action that says, please draw a diagram of how this

update function works.

Something like that.

You would never have that in language server that is too generic or just generic.

That's exactly that's what I find compelling about it is that we've seen all this innovation

happening because, you know, though you write many Elm review rules, there are some really

cool things out there that that people are creating because they can because it's just

Elm code and you just publish an Elm package.

And that would be really cool if that power was extended to these transformations.

Well then let me talk about something that I want in Elm review and it's kind of there.

It's not published yet, but I have a branch where it's working.

So I think I've talked about this before at peace with you about being able to use Elm

review as something to extract data from your source code.

So Elm review already has this very useful mechanism to go through your project, collect

information in a much easier way than you would do with then through regexes or tree

So it's a really nice tool to collect data.

But then the only thing that you can do is to create errors because it's a linter.

Well, the idea would be that you use the Elm review to allow you to extract data just as

Jason or as plain strings or something.

And I think that would open up for a lot of interesting ideas.

I'm not sure entirely which ones.

The code quality reporting.

For instance, you could say like, well, here are the list of all the CSS classes that are

using my program compared to the CSS that we have elsewhere.

That would be a separate tool.

Extract the data and then you do something with it.

Or potentially even you could say, please write some JavaScript.

Just try to compile this Elm code to JavaScript.

And now you have an Elm in Elm compiler.

Especially if you have access to things like type annotations.

Like I could imagine some really cool things where you generate TypeScript bindings based

on some Elm code that you have in a particular format that you know is going to be used to

call ports or, you know, like.

So yeah, there's so many possibilities there.

My question is mostly about like, but whether this is a good idea is twofold.

Would this make the API a lot more complex?

I don't think so.

I think it should be pretty good.

But is Elm review the fastest tool that you can use for this?

And for now, that's probably not.

It's a convenient one, but it can be a bit too slow for your use.

I mean, you could potentially say that, you know, if you have something like this that

pushes the boundaries of Elm review, then maybe it, you know, if you get really compelling

cases, it gives you more reason to really push the boundaries of performance, which

I know already you care about and are putting a lot of energy into.

But maybe it warrants a big, you know, a big direction change where you fork the Elm compiler

in order to have very performant AST parsing and things like that.

I think with the code actions idea that you had, we could achieve some reasonable performance

if we make, using the same mechanism that I have in mind for faster fixes.

Fixes are terribly slow, at least compared to what I would like them to be.

And I think we could do the same, use the same mechanism for code actions, maybe to

be a lot faster.

A lot of ideas are there and would need to be implemented before we can have this, I

Like we would need in ID integration, we would need faster fixes.

We would need maybe some code extraction.

Code action is a different beast.

Very exciting ideas.

If you go back to testing, there were two ideas that I had in mind.

I think we talked about one of them before.

No, we actually talked about two of them.

So the first one is, I don't know the name of it, but there was a technique that was

found in some other community where they would try to go through all the different branches

of some function using as few inputs as possible.

Does that ring a bell to you?

Because I can't remember the name.

I don't think so.

It's not fascinating.

Because I know that you almost worked on it or we both worked on it almost.

So it's kind of like first testing, but I think.

The idea was like, well, we can analyze the code or something and then we can figure out

if we run these eight cases because we have three if branches, then we can hit 99% of

the branches or something like that.

Well, if anyone finds a name again, please let us know.

Now I know what you're talking about.

So you're talking, I don't remember the name of it, but I remember what you're talking

about and there's some, I'll try to find the name and put it in the show notes, but there's

some concept that you can take all the permutations.

So given a set of inputs, there is a, so the inputs have possible values that the conditionals

So if, you know, if you have a custom type, it has eight different values it could take

on a Boolean has two different values and you take all those permutations, but there's

this, there's like a theoretical concept that is optimal for generally tending to statistically

produce the most simple way of going through the code path.

This is like a statistical principle.

And so it's a way of combining those permutations where you basically only change one input

at a time or something, something like that.

Yeah, I'll look that up.

So the idea here is to be able to hit all the code branches, which is again, only useful

if you have code coverage.

Well, no, it's not only useful, but it's mostly useful if you have good coverage.

I'll try to find a link to that and put it in the show notes.

It's definitely an interesting concept that would go along with sort of an API for creating

permutations that you could use for snapshot testing.

And the other idea is what you called mutation testing when we talked about it.

It's where you take some codes and you make some random changes to the code in a way to

see whether the test would now break.

Like if you have a one somewhere in your function, let's try changing that to a two and see if

any of the tests break.

And well, if the tests are well done or very thorough, then the test should probably break.

And if nothing breaks, then either the change was not impactful, maybe kind of a purpose,

or you're not testing that part of the code as well as you should.

So you should add a test.

It kind of, I think it's generally going to point to you either have like a sort of dead

code path or you don't have proper test coverage.

And this would not only be about hitting all the branches.

This could relate to actual values, right?

Which code coverage doesn't care all that much about.

And again, these are the types of things that start to become, I think far more interesting

in a language like Elm because it's deterministic, it's pure, you're not relying on outside context.

So there's just a lot more you can do with these sort of theoretical mechanisms.

And so yeah, mutation sort of changing actual ASTs in your Elm code.

It becomes much more interesting in Elm.

In the vein of testing, I had another project idea, which is essentially for Elm GraphQL

generating an API that looks similar to the query builders in Elm GraphQL that let you

build up a selection set for a user where you say, I want a user with first name, last

But using that same sort of query builder API, giving you fuzzers instead that essentially

give you a mocked out fake API server that will give you responses for your GraphQL schema

that are not only, it's one thing with like fake data to say, well, here's your GraphQL

We know all the types you need.

And so we're going to send you fake API responses for tests that are conforming to those types.

But like, is empty string valid?

Is it a valid username?

So if you just give random usernames that you don't have any control over how they're

put together, you might not be able to use that in a meaningful way in end to end testing,

like with Elm program test.

But if instead you can say, well, let's generate fake test responses, but here's an API for

defining how to generate those random values.

So it's like a fuzzer for API responses where you can say, here's my first name generator.

Here's my last name generator for this field or for this custom scale, or here's my generator

for date time values.

And for each test you want to do that, you can give it your own thing.

So it would be kind of similar to this like factory style, you know, fake test data technique

like factory bot for, you know, this sort of thought bot library for Ruby testing.

I think that's a cool opportunity.

And again, I think Elm is particularly well suited to that.

So I would have expected you to say something like, well, we have this GraphQL selection

set and from that we generate values.

Is that what you said or is that not what you said?

That is not what I said.

So this is like...

That's how I would imagine it to be most useful.

Well, usually end to end testing tends to be more of a black box where you don't have

insight into the actual code that's running and you don't care what actual code is running.

And so in that case, you don't know what selection set is being used, but you want to define

if the API asks for this kind of data, here's how you generate fake data to return there.

You could also take the approach of saying, given a selection set, give me a fake one

of those and then configuring certain ways about how you're generating that fake one.

But that would be more for clear box or white box testing, you know, where you have access

to the more like unit level testing.

That's the level I was thinking of.

So I had a couple of actually pretty simple ideas that I thought could be interesting.

One of them is, you know how there's this very common pattern to sort of either wait

for some basic context before your Elm application is ready or pass it in from a port, like the

start time and dimensions, things that you need like a task or a subscription or that

sort of thing to get.

Or initial flags.

I was thinking it could be a pretty easy thing to put together, just a simple wrapper around

an Elm browser application that, you know, doesn't call the users in it until time.now

and the dimensions are available and just has them and wraps that.

So you don't have to have every application sort of rebuilding those things.

Like you could just have those things available and you don't have to have that maybe state

Yeah, that would be interesting.

It's a little experiment.

Yeah, it's always nice when you can remove those intermediary states.

The boilerplate is not a problem.

It's just like having to handle the other cases.

That can be annoying.

The other hanging fruit thing that I've often thought about is in Elm GraphQL, there's a

custom HTTP error type.

And the reason for that is because bad status just has an int for the status code for the

bad HTTP response.

But it doesn't include the headers of the response and the body of the response.

That's a change that was made from Elm HTTP 1.0 to 2.0.

And when that change happened, I introduced a change in the little HTTP wrapper that sends

GraphQL requests and Elm GraphQL to change the default for sending HTTP requests to give

back a custom variant of the HTTP error that includes that data.

So it's exactly the same as the Elm HTTP error type, except it includes that additional context.

And the thing is like...

See that's the thing, right?

But if it was a common thing, if it was a common package, just like Aaron Vanderhaar

created that common color package.

So it's sort of a community standard that people can align around and say, okay, this

is our color type.

We can use this.

We can use this common API for creating these types.

And when the community aligns around that, you can reuse that.

So I think it would be really nice to have a common package for HTTP errors that just

package authors can use so people can sort of not have to map back and forth between

these different HTTP error types when they're combining a pipeline with different HTTP requests.

It's like a very straightforward one.

I mean, the main important thing would probably be having a discussion thread probably on

discourse or something to get some consensus around what that would look like.

But really, I think it's pretty straightforward.

I think you could probably use exactly the type I have in the Elm GraphQL package.

But if that's out there and people can align on that, I think that would be really valuable.

I've also had a few small project ideas.

One of them has been in my head for quite a while, quite a few years already.

And that is a tool to vendorize packages.

So sometimes you use a package and it's not giving you all the tools that you want, all

the primitives that you want, or there's a bug or something.

So you create a bug report, but then you have to fix that bug really quickly or the maintainer

is not active anymore.

So you usually vendorize your proxy.

You copy it and you put it in your project.

In your source directories.

And that can be a bit annoying because you need to copy things and then you need to add

to change the source directories and you need to add all the dependencies.

And that's a small annoying thing that you have to do.

And as I thought, maybe a tool could be useful to make that easy.

And it could do a few more things like it could copy the license.

So you do the right thing.

It could also block you when the license doesn't allow it.

Like, Hey, you're not allowed to do this.

You're not allowed to copy it.

Which I don't know which licenses for that, but that would be something to look at.

99.9% of packages are BSD three clause anyway, but yeah.

Right, right, right.

And I think it would be very useful to have a, the tool add a file saying, or a comment

somewhere saying the original version of this package was from this repo, from this revision,

something like that.

And then have a command to make it easy to remove it and we add the new version.

Like if you were waiting for on a bug fix, for instance, Oh, the bug fix is in let's

Unventoring would be super handy too.

And I've seen a few people use this technique or this kind of technique to migrate packages

or for instance people who used it for migrating from elm HTTP one to version two.

I think that was Joelle that showed that technique and also so Luke Westby use that for going

from elm 018 to 019.

So like, Oh, well there's this new version of Elm core or basics.

Well let's start using them bit by bit by vendoring them.

And then you can remove the old one at some point and now you can just remove the vendorized

code and you're done.

So I think it would be not a tool that would be used very often, but when you have it,

it would be useful.

Yes, that would be very handy.

It's a nice one.

I would also love Elm format written in Elm because that would be useful for Elm review

at least that could be useful for if you generate code in Elm, which now since not a long time

ago, like two days, I think have a tool for called Elm code gen, but yeah, it could be

And then if you want to have an editor in Elm for Elm, like you want to recreate Ellie

or something, well you can, you have an Elm format function that would be useful.

And then Elm review can use that to be even better at fixes or something like that.

Another one is, you know how Elm provides a diff function or diff sub command.

So you do Elm diff name of the package and then the versions.

Well, these are the API differences between these two packages.

Well, I have seen the same thing in other languages where they also give you the code

that has changed or the functions whose implementations have changed.

And that could be interesting as well.

For instance, to know whether there are any security issues like, oh, well this function

that had the return the commands or return the task is now doing something else.

Well that's not necessarily going to be shown in the API, but it's something you might want

to know before you upgrade to your version.

There's so much cool static analysis stuff you could do in general with Elm.

Well, in this case, maybe you can just go to GitHub and ask for the diff.

So maybe I don't know if this is useful, but maybe there are some ideas that can be explored

I had an idea which we've talked about before, which is another small little convenience

project, which would be taking your Phantom builder types and turning it into a state

machine diagram.

Potentially, if you had like a sort of Elm review gathering helper to gather data and

output it into arbitrary formats, JSON or whatever, you could potentially use a tool

like that to sort of in pure Elm gather that up and then generate some diagram from that

output or something.

That would be useful.

Or just have a code action, just have a code action to draw the diagram in your code.

And let it tell you like, oh, well this diagram is not up to date.

We have changed the function, the builder pattern.

So you need to regenerate something.

In that same vein, I would love like more innovative tooling and pushing the boundary

with things like in our editors, understanding things about our Phantom builders and understanding

what like is contextually possible to give us the type that we need.

Well, this is the literal only way that you can construct this type is by stringing together

these functions with something of these types.

So here, let me do all the things I know for you.

Like I would, but that is pie in the sky.

That's definitely like big idea thinking, but it is Elm.

And so it is very statically analyzable.

So there are also big opportunities there.

I should probably also mention that when it comes to static analysis Elm review, I want

to add some features, which I will at some point, but I could definitely use some help

to have like type inference or visiting dependencies.

Like I've mentioned this in the last episode of like false positives, like just getting

more information.

So when I worked on the if branch is pruning, I mentioned that at the beginning, I kind

of made a value inference logic machine, which I think could be made more general, but that

requires some exploration, but that could be interesting.

And then you can use that for very nice diagrams or I don't know, whatever you tell me.

So many possibilities.

Another one I have on my list.

So actually Mario built this really cool tool that I'm sorry to sort of, I'm not sure if

we've mentioned it in the past on Elm radio, but sorry to put it out there, Mario, but

there's a tool called Elm fusion, which we haven't really announced, but we pretty much

are ready to share it.

But Mario created this really cool tool that allows you to run HTTP requests in lime Dara.

And so it's just a web application.

You give it a URL to hit a JSON API.

It gets the JSON data back in a little web page that you can play around with and you

can click things to build up a decoder.

So Mario created this like really cool tool for sort of interactively creating decoders.

And I kind of added a few things to that that like help you scaffold out things like Elm

pages, data sources, and lets you sort of paste in a curl command and it will automatically

turn that curl command into something it can execute for you, things like that.

But there are just so many cool things I think you could do with this tool.

Like one of the ideas I have that I think would be really neat is to be able to send

a collection of requests.

So right now there's already functionality to like take variables.

So if you use like a bash variable in your curl request and paste that in, I already

have it where it'll extract out the variable and you can sort of interactively type different

inputs for that variable.

And it will generate that as an Elm parameter in the function that it creates for the scaffolded

code that you use for that HTTP request.

But I think it would be really cool if you could like say, okay, well here are some different

inputs for these variables.

So like, you know, API slash users slash ID.

And then you say, okay, well go get users with these ID values and then combine together

And now if you're looking at, you know, email and instead of just seeing, oh, this is a

Well, in one of the responses, it's a string in one of the responses, it's null.

And now, you know, it's, you get more information by combining together these responses and

piecing together the bigger picture of what the types are.

So I think this could be a really cool, like basically like a Elm version of Postman or

Insomnia, these types of sort of API inspector application, but with like cool Elm things

you can do based on that.

In a similar vein, I've thought about how it'd be really interesting with like Elm pages

to be able to embed tools like that in the Elm pages dev server.

So to be able to like have an HTTP data source, get back a JSON response, and then suddenly

you have this Elm HTTP fusion embedded in there where you're inspecting the HTTP response.

You got a decoder error and you can sort of interactively fix it in line because it knows

the JSON it got back and it knows that you got a JSON decoding error.

So those are big ideas, but also doable.

And another idea with the Elm pages dev server that I've had is I think it would be really

interesting to have a sort of way of interacting with the dev server to perform code actions.

So like if you go to a 404 page, if you could say, would you like to create that page?

And then the command, which you typically use like a CLI command to scaffold out a new

page, you could use a button in the UI and that could even be like configurable.

Like we've talked about with like something like Elm review code actions or how Elm review

enables an ecosystem to develop where there's a low barrier to entry.

I think there could be a similar sort of ecosystem with Elm pages being able to do these interesting

things in the dev server.

Yeah, that would be really cool.

I think there's some cool possibilities there.

Oh, and another idea I had for the Elm pages dev server, we haven't mentioned Elm code

Matt Griffith recently released this really exciting library.

Like five minutes ago.

Well then we have, well, so I think it would be really interesting to use Elm code gen

in tools for the developer experience.

For example, in Elm pages being able to scaffold out a new page using Elm code gen and then

being able to use pure Elm code that you have confidence that you're generating something

that has the correct types to scaffold out in Elm pages route module.

So yeah, so many, so many cool possibilities.

It'll be really cool to see what kinds of innovations come in the next couple of years

with this tool.

There is one very tiny tool that I would really like, but that's not going to be useful to

Do you remember the blog posts on the Elm Lang website called the syntax cliff?

There's one really nice thing in there that you may not have noticed or may have remembered

because it's been a while.

It talks about error messages and it shows an error message at one point.

And that is actually not just a copy pasting of the report from the compiler.

And it's also not a screenshot.

It is a code block with the proper colors so you can copy paste it and it looks exactly

like a compiler error.

And I would really like to have that made easy in my blog posts.

It currently isn't.

I don't know how it's coded.

I think it was coded by hand by Evan.

I've looked at that code.

We should pair on that, Jeroen.

We can totally make that happen with Elm pages.

I said we don't have time for it.

Well, we have time for some things.

This one might be pretty straightforward actually.

Yeah, so that would be interesting.

It would be useful for the two of us at least.

And as we've mentioned in the past, you could definitely imagine a cool doc site for Elm

review packages where you can show more interactive output.

So I want this for the Elm compiler, but I also want it for Elm review errors, obviously.

And you could also have it for like, oh, Elm pages reported this error in a troubleshooting

section or Elm SPA or Elm code gen or whatever CLI that we're using and have that inside

the documentation.

And that would be a pretty nice experience, I think, for most people.

Yeah, it's actually really not rocket science.

I mean, it's just like anti color code parsing, which they're already on packages for.

So it's really just like stringing together a few of those things in your blog output.

So that's very doable.

So onto another topic on a project that might be that will not be as small.

So I went to lambda days recently and I heard a talk about from Felina Hermans.

Does that ring a bell?

Okay, she made the Hade language, which is intended to teach coding to kids.

So it's kind of like Python, but it's cut up into several levels.

So it's a subsection of Python and sometimes like a simplified Python.

So for instance, like level one is you say you type in hello world and that actually

prints hello world.

Level two is you need to say print hello world.

Level three is you need to add quotes or something, or level four you add variables, stuff like

At some point you add loops and that basically you start very simple and then you make it

slightly more complex, but that also allows you to do more things.

I thought that was a pretty interesting way of teaching that language.

I don't know if it would make sense for Elm.

Maybe it could, but there's another thing that Hade does and that is translating.

It is a language that you do on a website and the website is translated to a lot of

languages, but also the error messages are translated and the keywords are translated.

Like you would not say print, you would say imprimé in French or something like that.

Hopefully something shorter because one of the things that really help learning is when

you learn something in your own language, which in your case Dillon is English.

It's very convenient, I will admit.

In my case, my English was good enough when I started learning coding, so it wasn't a

problem, but I can totally imagine some people having more troubles than we did.

They're starting to make some languages where a lot of the keywords are Chinese now because

it is like, I mean, there's enough of an audience of Chinese programmers.

It's like a large demographic.

But yeah, if you had more of an AST based approach rather than just text, the bigger

picture here is like getting away from pure text serialization formats for code.

So I don't know whether it's interesting to do the Elm in several steps.

I don't know if it's interesting to do the, instead of if, use the appropriate word in

But one thing that I could see that would be a lot less work is to translate the error

messages and translate the documentation.

That would be much easier.

You could have a wrapper around the Elm compiler that does some reg exes on the output and

then reprint it in your language.

That could be interesting already.

And then documentation translate the Elm sites in some language.

I know the French community has done that recently where they translate the website

and the whole guide.

But yeah, you could imagine a tool that wraps the Elm compiler, but it just looks like it's

made for French people.

I love that idea.

Except that the keywords are if, then, case of.

And I would be open to that idea as well for Elm Review, like being able to translate errors,

but I don't know how much work that would be and how much work that would put on maintainers.

Because it's also like, oh, well, this error message has been translated to Chinese.

I don't know if Chinese did the translator do it in good faith or was it a troll that

just added something terrible?

So I have no experience with translating projects, but other programming language communities

have done that to some extent.

So we probably have something that we can copy from them.

And this would definitely be a community effort.

Otherwise, it would not go very far, I think.

Yeah, there's a big community element to that, for sure.

Yeah, we could cater to more communities like that, teach children not only in the US, like

where we've seen it be successful in some instances, but also like people in Germany,

people in France, people in China, people wherever.

Yeah, it could definitely go a long way for making it more accessible for people to learn.

Very cool idea.

I've got one more.

I've got a couple more categories on my list, just a few more items.

So one category that I find really interesting is bundle size and performance.

And I think that, again, I think that Elm is really interesting in the possibilities

here because it's so statically analyzable.

It's so swappable.

If you can do something that's equivalent, you can just swap it out and not worry about

whether it's going to be misbehaving in some way because it's very well behaved code because

So one idea I have is an Elm CSS compiler.

Elm CSS used to be actually a CSS compiler in its original form.

And there's a fork of it that still does something similar.

But the way it worked was basically using custom types instead of classes.

And you declared sort of global styles.

And then you would compile out a style sheet with those global styles and then use those

class names, which you had like safe Elm tokens to use with these nice custom types.

Elm UI used to actually use a similar technique where you had like globally declared styles.

But my idea here is, so I think that there is a real cost to having sort of CSS and JS,

in this case, the JS output of the Elm compiler.

But in putting that in our JS bundles, there's a performance cost.

CSS, when you have it as raw CSS, is very performant.

The browser is really optimized.

I mean, it's a more constrained language.

And so it can do more optimal things with it.

And it has to do less work to deal with it.

So I think it would be really cool to take, my idea is to take inline Elm CSS that you

have in an Elm CSS style tag, and then compile those out into an actual style sheet in your

compile step, in your build step, and replace them with just a class attribute pointing

to generated styles.

So you would be compiling out inline Elm CSS styles into a generated CSS file that point

to sort of a hashed version that refer to those CSS styles.

I think it's pretty doable.

The easy version is that you say, this only works for direct inline styles in Elm CSS

lists of styles.

Or something that your static analysis tool can understand.

Like we talked about in the false positives episode, like making your job easier for requiring

more constraints for it to be more static and more easily analyzable.

The more deluxe version is you say, OK, well, if your styles depend on certain variables,

so you say, if active, then background color is bright blue, else background color is dark

blue, or whatever.

Then you can say, OK, well, we're going to get fancy here, and we're going to compile

that down into two different classes.

Or you can get more sophisticated there.

But I think it would be really interesting to start with a form that just keeps it simple

and says, we're going to do a code mod, modify the code inline with an intermediary step

to take this generated output, strip out all of the only static things.

If you have any conditionals or case expressions around it, we're not going to touch those.

But the things that are purely static in your Elm CSS, we're going to take all of those

and turn them into a compiled CSS class.

I think that's quite doable.

I think so as well.

The only thing that you would need to do is to set constraints like, don't write any CSS

that I can't understand.

Don't pass a variable to attribute.class that you can't infer based on the context.

Or you ignore those ones, right?

You just say, hey, those ones in the code mod that we used to generate the output, we

just don't touch those.

But then the static ones, we pull out and put that into the compiled CSS.

So there will be a mix of Elm CSS.

But now, if you're able to compile out all of the Elm CSS, then you can actually essentially

compile out the Elm CSS library entirely, which is kind of interesting too.

So I think there's some kind of fun things you could do with bundle size there.

I think it would be really cool to do a proof of concept and then do some benchmarking and

see what that looks like.

On a related note, I think it could be really interesting to have some tools for these types

of general code mods in Elm.

In Elm pages, I do some code mods, meaning modifying source code in a precise way.

Using Elm review, I use some Elm review rules and apply them and output them to a secret

temporary directory and then use that to actually compile the output.

So I use that in the case of Elm pages to actually do dead code elimination for the

server side only stuff.

Because I know that it doesn't need to run that on the client.

So I can dead code eliminate all of that with the help of Elm review.

But I think that could be a cool little helper tool.

It's something that could help you manage those secret directories for running a code

mod and outputting that code and generating the Elm code.

So yeah, for code mods, I know that Aaron van der Haar worked on Elm refactor.

That one has not been released yet.

But that would be definitely useful, especially to have new versions of libraries.

So for instance, for Elm review, I think I'm going to make a lot of changes for v3 whenever

Like I just have ideas for now, having a code model would be super useful.

I also want to talk about debuggers.

Like I've always wanted a way to make Elm review more easy to debug.

Like why didn't this not work the way I wanted?

Like maybe go through each visit and have a step by step debugger or something.

Also like there's astxplorer.net, which is a tool where you can add your code, tell which

parser you want to use and shows you the AST for it.

And also allows you to insert like a ESLint rule or a Babel transformer, and it gives

you the output of that.

So that would be really useful for Elm review.

I have one of this for every, like from before I released the tool because that was very

I don't know if that's a barrier to entry for people.

It's not for me anymore because I know the AST well enough, but I think that would be

And I know that other people have talked about some things being very hard to debug as well,

like parsers, like having a tool that helps you find out like what has been consumed in

which state am I in this parser state machine.

And I think we could also have very cool ideas for enhancing the Elm debugger in the browser.

Like we could have a tool like Elm optimize that changes the output code to insert a new

kind of debugger, which would be either something very different or just an improvement of the

Elm debugger, which I don't see myself using that much anymore, but because some things

are annoying, like we have a tick message and I would like to be able to filter that

That's not possible at the moment.

So things like that.

The Elm debugger is very useful, but there are a couple of things that come up that could

make it much more usable in some cases, like you said, being able to filter things out.

Sometimes when output is large, it just turns into an ellipse that you aren't able to deal

And there are so many interesting opportunities too.

Like I know that like in the Clojure community and the Ruby community, a lot of these like

dynamic language communities, or am I going to get hate for calling Clojure a dynamic

A lot of these, it's a dynamic language for me, but a lot of these communities swear by

having like inspectable code and being able to hook in with debuggers.

And when I was doing Ruby development, I loved using Pry and IRB to go in and look at the

application state and work with things.

There are definitely interesting opportunities there with Elm.

I think we can do a lot of things.

Like just inserting like a debugger statement in the output JavaScript.

That would be very cool already.

Also, like making commands inspectable could be really cool for the, not just for like

testing tooling, but also for the debugger.

If you could see which commands are being emitted and sort of inspect that, that could

be really interesting for debugging.

I know for Elm pages, I've been thinking about like, how could I make data sources more inspectable?

So if that data type carried sort of metadata about it that could be used in debugging.

So if there's like a, if there's a data source error, can it then include metadata that lets

you flow through to see what this HTTP error happened, but give me some context as to what

HTTP data source you were performing that caused that error.

So lots of cool opportunities there in Elm.

I think we really can do a lot more debugging tools because it really feels like an under

appreciated aspects because we don't have the tooling for it.

But we have the language for it, right?

We have the language that gives us all of these really interesting possibilities.

So one last one I wanted to bring up and one last sort of category I think is sort of runtimes.

I think Elm is better than people realize at creating runtimes to build onto different

platforms, like ways to hook into different platforms.

So for like one example I have on my list of experiments that could be cool.

There's a React tool called Inc, which is a sort of binding to creating like a higher

level way of creating CLIs where you have this React way of rendering views.

Well that view, what if that view was a CLI and what if you had view components that were

spinners, input boxes, things like that, but for a CLI.

I think that the Elm architecture would work quite nicely for that and that could be an

interesting space to explore.

So Elm review has a CLI obviously and it's using some dependencies for that, for making

very nice things.

And if that was written in Elm, we would have dead code elimination and I wouldn't be injecting

everything for that.

So yeah, that would be quite nice I think.

I think so there's a tool called Inc that does this in React.

I think there are a lot of opportunities of like X for Elm and I think Inc is a cool one

and I think just in general like Elm is really cool for building platforms because you can

really explicitly lay out the data that you get and what you build in a type safe and

well constrained way in some of these contexts.

So many opportunities.

I think as people can tell, we have a lot of ideas that we don't have time for.

We would love to have more time for these things, but hopefully people have some inspiration

to get out there and do some experiments and build some cool things in Elm.

We also have GitHub sponsors pages if you want to give us something that can help us

have more time.

But there are plenty of other people who ask for sponsorships.

We will have a link to.

Yeah you've got an awesome Elm sponsors GitHub repo.

We could link to.

So yeah, please work on these things.

Please get in touch with us if you want and make cool things.

And Jeroen, until next time.

Until next time.