rebeccaskinner

For all of the author's bloviating and self-congratulating navel gazing, the article manages to largely overlook values, the only mention of them being to dismissively reduce them to irrational tribalism.

In truth, values and ethics are fundamental to effectively discussing politics. After all, all political decisions are ultimately about how we want to shape the world that we as humans live in. There can be no agreement about economic policy without a shared understanding of the ultimate goal of an economy. No agreement about foreign relations without a shared understanding of the role of nations as representatives for groups of humans, and how we believe one group of humans should interact with another group of humans through the lens of nations.

For the last 20 years at least, the leadership of the two main political parties in the US have largely invested in messaging around the values that they represent. The policies are different too, but over time we've gone from a world where there were at least some cases where the two parties had different policies for how to reach the same goals, and into a world where the parties policies are aiming to realize fundamentally different visions of the world, based on fundamentally different values.

In this world, asking "who did you vote for" isn't a matter of tribalism, but it is a (good) proxy for asking someone "what are your values". If you discover that someone has completely different values from you, then discussing policy isn't going to be useful anyway, because there's no way you'll agree on a single policy when you have different fundamental values.

I've never looked at scala, but that's really interesting. Do you find that's useful in practice?

> So what's the difference between a map and a dictionary then?

You're asking good questions and catching me being imprecise with my language. Let me try to explain what I'm thinking about more precisely without (hopefully) getting too formal.

When I say "a function is a mapping of values" I'm really trying to convey the idea of mathematical functions in the "value goes in, value comes out" sense. In a pure function, the same input always returns the same output. If you have a finite number of inputs, you could simply replace your function with a lookup table and it would behave the same way.

When I talk about dictionaries, I'm speaking a little loosely and sometimes I'm taking about particular values (or instances of a python Dict), and other times I'm being more abstract. In any case though, I'm generally trying to get across the idea that you have a similar relationship where for any key (input) you get a particular output.

(aside: Literally right now as I'm typing this comment, I also realize I've been implicitly assuming that I'm talking about an _immutable_ value, and I've been remiss in not mentioning that. I just want to say that I really appreciate this thread because, if nothing else, I'm going to edit my blog post to make that more clear.)

The main point is that dictionaries are made up of discrete keys and have, in Python at least, a finite number of keys. Neither of those constraints necessarily apply to functions, so we end up in an "all dictionaries are functions, but not all functions are dictionaries" situation.

> Yeah that's pretty much what I had in mind, and yes it's possible but it feels forced. For one you're not actually removing an element, you just make it impossible to retrieve. A distinction that might seem moot until you try to use it, depending on the compiler magic available.

This is a great example of the kind of thinking I'm trying to address in the article. You're completely right in a very mechanical "this is what memory is doing in the computer" sort of sense, but from the standpoint of reasoning about the problem space deleting an element and being unable to access the element are the same thing.

Of course in the real world we can't completely handwave away how much memory our program uses, or the fact that a function encoding of a dictionary turns a constant time lookup into a linear time lookup. Those are real concerns that you have to deal with for non-trival applications, even in a pure functional language.

The benefit you get, and I apologize because this is hard to explain- let alone prove, is that you can often end up with a much _better_ solution to problems when you start by handwaving away those details. It opens up the solution space to you. Transformations to your architecture and the way you think about your program can be applied regardless of the specific representation, and it's a really powerful way to think about programming in general.

I'm really focusing less on the idea that Dict the data type with it's associated methods is like a function, and more on the idea that a dictionary in the general sense is a mapping of input values to output values, and you can think of functions that way.

That said, there are some pretty reasonable analogies to be made between common dictionary operations and functions.

For example, adding and removing items can be done with function composition so long as you are okay with partial lookups. Here's a really short example I put together:

  module Example where
  import Control.Applicative

  type Dict a b = Eq a => a -> Maybe b

  emptyDict :: Dict a b
  emptyDict = const Nothing

  singleton :: a -> b -> Dict a b
  singleton k v target
    | k == target = Just v
    | otherwise = Nothing

  unionDict :: Dict a b -> Dict a b -> Dict a b
  unionDict dict1 dict2 k = dict1 k <|> dict2 k

  insertDict :: a -> b -> Dict a b -> Dict a b
  insertDict k v dict = singleton k v `unionDict` dict

  removeDict :: a -> Dict a b -> Dict a b
  removeDict k dict target
    | k == target = Nothing
    | otherwise = dict k

This particular representation of dictionaries isn't necessarily something you'd really want to do, but the general approach can be quite useful when you start working with something like GADTs and you end up with things like:

  data Smaller a where
    SmallerInt :: Smaller Int
    SmallerBool :: Smaller Bool
  
  data Larger a where
    LargerInt :: Larger Int
    LargerBool :: Larger Bool
    LargerString :: Larger String
  
  someLarger :: Larger x -> x
  someLarger l =
    case l of
      LargerInt -> 5
      LargerBool -> True
      LargerString -> "foo"
  
  embedLarger ::
    (forall x. Larger x -> Smaller x) ->
    (forall smallerI. Smaller smallerI -> r) ->
    (forall largerI. Larger largerI) -> r
  embedLarger mapping fromSmaller larger = fromSmaller (mapping larger)

(I'm actually co-authoring a talk for zurihac this year on this pattern, so I have quite a bit more to say on it, but probably not ideal to cram all of that into this comment).

I think that understanding the (moral) equivalence is useful in both directions. In particular, I think helping people understand the "function-as-container" analogy is a useful way for people to understand pure functions- another thing that's conceptually simple but a lot of people struggle to really wrap their mind around it.

I've recently started writing a series of blog posts (https://rebeccaskinner.net/posts/2024-10-18-dictionaries-are...) trying to explain the idea and my approach has been to explain the idea using comprehensions. I haven't had a lot of people review the post yet, and I still have at least one if not two more follow-ups before it's done, so I'm not yet sure how well the idea will land.

> A function a->b is a container for bs

Anecdotally, this is one of those things that's trivially true to some people, but really hard for other people to internalize. I think it's why the "container" can lead people astray- if you haven't internalized the idea of functions as being indexed by their argument, it's a really mind twisting thing to try to make that leap.

I think it's great that people are excited about Haskell and want to write about it, and it's unfortunate that the author had to deal with a less thank tactful response to their work. I hope the author keeps spending time with Haskell and continues to make time to try to write more and help other people!

That said, here is a bit of a long comment on my thoughts about writing about and teaching these things:

It's true that teaching Monads, Applicatives, and Functors can be tricky and there are a lot of articles that end up doing more harm than good- either by teaching things that are outright incorrect, or more often, teaching people a particular way to use them but setting people up for a lot of trouble when they run across uses that diverge significantly from the mental model they've built up.

Functions are a classic example of this. There useful definitions of Functor, Applicative, and Monad for functions, and depending on the mental model you've built up they can be either fairly easy to understand or very difficult to understand. This ends up being a big problem because Applicative and Monadic functions are so pervasive, but they are incomprehensible if your stuck in the traditional data structure mental model. IO is a great example of this- it's really just a specialized State, but it can be really hard to understand how it works if you're thinking about data structures. Parsers are another good example.

I generally prefer to start people off with the "monad-as-computation" mental model, roughly "An `m a` is an m-computation that can have side effects and when evaluated returns a value of type a", where Maybe are computations that could fail, Lists are computations that can return multiple times, and IO are computations with all of the normal IO side effects.

Starting with IO has the nice benefit that you can also help people come to terms with monadic IO as a means of dealing with lazy evaluation. It's a good gateway both into helping people come to terms with the challenges of lazy IO, and it also helps to provide a concrete motivation for IO in haskell that doesn't result in people going off thinking that Monads are a hammer and every problem in the world is a nail.

From there, I think it's helpful to talk not just about bind but also join. Showing someone how to implement join in terms of bind and vice versa is a nice thing to do early because it helps to differentiate Monad from Applicative and it demystifies the "a monad is a monoid in the category of endofunctors" thing a bit (not that I'd proactively bring that up when teaching someone how to use them).

I like to characterize the high level difference as something like "Monads are computations that can _call out to_ other computations and integrate their results", "Applicatives can run computations in parallel and combine the resulting structures / side effects", and "Functors allow you to lift pure functions into a computation". At each step, highlighting both how you are getting less powerful (because you can implement functors in terms of applicatives, and applicatives in terms of monads, but not the other way around), and how having less power can help you reason better about your programs (pros/cons of applicative vs. monadic parsers are a good example here).

Finally, I think it's important early on to make sure your reader understands higher kinded types. A lot of people are used to languages with generics, but many of those languages aren't expressive enough to let you express something like Functor, and people often lack practice in thinking about something like `Maybe` separately from `Maybe Int` or `Maybe a`.

In the end, I think these things really aren't that complicated, but they are built on a different view of programming that a lot of readers have the first time they encounter them, and the best approach isn't to translate the concepts into something people are already familiar with. Instead, I think you need to help the reader adapt their mental model. It's a harder path, but one that I think pays off more in the long run.

I just subscribed. They had already been on my radar as having done some good reporting lately, and this was a good nudge to get a subscription.

Along very similar lines I’m a longtime subscriber to lwn.net even though realistically I tend to catch up there every couple of months and am almost always reading content that is free by that point. I find the service they provide valuable and the subscription fee very reasonable and I’m happy to support it.

Reading the article was helpful to understand the other side of it. I definitely understand how it's a hard problem to solve on the part of the server owners.

I noticed in the linked post that there's not a clear way forward in the short term for people to submit their own room directories. Do you think there are other ways someone might be able to help with the need for discoverable fun community spaces on Matrix? I suppose running a server is one option, but it's both difficult to bootstrap a userbase and I suspect that anyone running a server that's open for public signups risks running into exactly the same problem.

I really want to like Matrix, and just last weekend I re-downloaded a matrix client and tried to give it another shot. Maybe I'm holding it wrong, but from what I can tell it's suffering from the same problem that all of the fediverse services seem to suffer from: The only thing to talk about is the fediverse itself.

Back in the heyday of IRC I spent a lot of time in technical channels on networks that were mostly technically focused, but I started using IRC in the first place because of the social channels where you could join games, talk about music, or find people with other shared interests.

Then there was a moment in time where community slack groups popped up, and again I mostly joined tech focused slack groups, but it still felt social and there were channels to talk about movies or games in addition to talk about careers or particular programming languages. Slack killed those kind of communities but they moved to discord. I left discord when they introduced ads.

Open up a Matrix client and look at the public rooms on any large server and you'll find places to talk about... the matrix protocol. and matrix servers. and matrix clients. If it's a really popular server you might also be able to talk about mastadon clients and servers too.

Even as someone who is enthusiastic about the idea of federation who might actually be interested in talking about the Matrix protocol or implementing particular servers, I still want to also talk about math or programming languages or movies. Without anything like that Matrix as a whole just gives off this general vibe of being kind of unwelcoming and not _fun_.

For what it’s worth I don’t think that being promoted into a staff or principal role is about intelligence per se any more than going into management is. I was a principal engineer at my previous company, joined my current company as a senior engineer, and this time opted to try out the management ladder.

If anything, I think I probably exercise my technical expertise more as an engineering manager than I did as a principal engineer, but that’s probably a matter of difference in company culture and my current team. Generally I think both roles end up leaning on a mix of systems thinking, interpersonal skills, and generally the ability to have a vision and sell it to other people. As a principal engineer I was focused on the technical systems and the vision was about ways to make the organization I was working in more effective by setting a vision for what areas we invested in technically, how systems owned by different teams worked together, and in some cases involved getting hands on to help out or build a prototype.

As a manager I’m focused on an area of the product, business outcomes, and how to ensure that my team is productive over both a short and longer time horizon. It means setting a product vision, understanding the technical and organizational work needed to get there, and selling that vision to get the time and resources needed. Sometimes it means getting my hands dirty to build a prototype, or to take things off my team’s plate so they can be more effective.

I’ve been lucky that my recent jobs have all had enough interesting deep technical problems to go around and I’ve still been able to do some of that work, but neither role has involved the kind if regular deep technical work I had as a senior IC.

I think real senior roles are generally the place with the hardest technical problems, and moving up in any direction sets aside some of those problems in favor of learning to get leverage from influence.

I really wanted mastodon to take off but in practice it just hasn’t seemed to, or at least any spaces that are worth using are also not discoverable.

Anecdotally, as someone who mostly used Twitter for math and theoretical CS (plus some news and current events) I feel like I ought to have been able to fairly easily find a community on mastodon but I never did. BlueSky is doing much better as a replacement for tech twitter and math twitter.

I suspect the centralization is necessary to an extent to get critical momentum. You could replicate something like that in mastodon maybe, but nobody seems to have done so in practice and I’m skeptical they will. Truth Social is probably the best example but from what I know, but it never hit the scale of Twitter even with a fairly ravenous core audience.

> BlueSky became immediately political in its narrative and many people just view it in the same light as Truth Social now.

I don't see this at all. Quite the opposite in fact.

From what I've seen, BlueSky is trying very hard as a company to stay apolitical in an extremely naive way that's going to ultimately drive away users. There's simply no way to to be apolitical as a general social media platform today when social media is so widely used for discussing politics and current events, is a key target for propaganda campaigns, and in a highly fractured political climate.

BlueSky gained momentum primarily from people who were driven away from X as it started to move further right, with a lot of engagement driven by left and center-left leaning people, along with people who might not have been directly engaged in politics except for being the target of right-leaning hate campaigns (LGBT people in particular).

If they'd doubled down on that, I think they'd be a lot more successful in the long run. Sites like Truth Social, Parler, and X have demonstrated that there's a significant market for politically aligned social media spaces for the right, and both the significant activity in left and center-left spaces in Twitter before the buy-out, and the growth in Bluesky point to there being a significant market for an unapologeticly left leaning social media site as well (I'd point to Tumblr here as another example, although I don't use it and only have a passing idea that it seems to be a predominantly left leaning space).

Instead of embracing product market fit with an underserved market though, BlueSky seems to be both-sides-ing themselves into a situation where they're likely going to see an exodus. By inviting and protecting right-wing provocateurs on the platform they are driving away their core audience in order to attract people who already have their choice of established competitors (X). The only value they can add over sites like X and Truth Social is a group of users ready to be the target of trolling and bullying, but having recent experience with migrating away from Twitter I don't see them sticking around BlueSky for long in that environment.

In the end, the attempt at being apolitical will doom BlueSky to being a worse less populated X or Truth Social, rather than making the most of the opportunity to be a more decidedly left-leaning social media platform for an audience that prefers to avoid a strong right-wing presence in their social media experience.

These days I mostly write Haskell, so I'll focus on that. When I'm writing Python, Rust, or C the stories are similar broadly, although may vary a bit in the specifics.

I don't think the way I work is all that different from the way people who use a lot of IDE-like features work. The main difference is that I prefer a pull-based approach to getting information, rather than having my editor push information at me or try to do things for me.

My typical setup for a project is to have my editor (emacs) open with code, and separately to have my project open in a REPL (ghci). For smaller projects I use haskell-mode, which lets me open a REPL with the file I'm working on loaded automatically. At work our codebase is a bit too big and our build system a bit too complicated for haskell-mode to be able to manage my repl, so I use a separate tmux buffer to open ghci.

I can do a lot from my repl. If I want to know the type of something, I can either look it up using the repl if it's a top-level binding, or I can add a type hole and reload the file if it's something that's not directly available in my repl. I can also see what instances are defined for a type, what functions are available in those instances, and where the type is defined.

In addition to my repl, I'll usually have a shell open in my project. If I'm trying to figure out where something is defined, I can just run a command to query hiedb, although in reality it's often fast enough to just use ripgrep.

If I'm trying to remember the name of a file or where it lives, I will typically use fzf, either in my shell or in emacs. I can usually remember enough about the name to at least narrow it down to a couple of options.

For things that live outside of my project, I wrote rofi-hoogle (https://github.com/rebeccaskinner/rofi-hoogle/) to let me search packages and documentation from my desktop with a simple keyboard shortcut. It also lets me jump to the online documentation if I need to read more than the type.

I don't use copiolot or any other sort of AI auto-complete at all. Occasionally I'll present a simplified version of a problem to ChatGPT and ask it to write code, or I'll ask it to review some code, but I typically do that through the web UI. I keep intending to get it set up in emacs but I haven't bothered yet.

I wouldn't necessarily say that other people should adopt my way of working, but it's the best way of working that I've found for me and my own quirks. I've tried IDEs every so often, but I find that the constant distractions make it hard for me to focus on the task at hand- whether it's things popping up in my field of view, auto-complete moving my cursor around, or error messages popping up because I haven't finished the code I'm writing. I'm probably slower at the IDE-specific tasks than people who are really good with IDEs, and maybe even slower at those specific tasks than I would be using an IDE, but the benefit of being able to eliminate distractions and focus on the code I want to write outweighs the cost for me.

I’ve been working with perceptual hashes a lot lately for a side project, and my experience is that they are extremely resilient to noise, re-encoding, resizing, and some changes in color (since most implementations desaturate the image). Mirroring and rotation can in theory defeat perceptual hashing, but it’s fast enough to compute that if you care you can easily hash horizontal and vertically mirrored versions at 1 degree increments of rotation to identify those cases. Affine transformations can easily defeat some perceptual hashing algorithms, but others are resistant to them.

The big weakness is that most perceptive hashing algorithms aren’t content aware, so you can easily defeat them by adding or removing background objects that might not be noticed or considered meaningful by a human observer.

Personally I’ve always found working with docker to be pretty frustrating, especially dealing with docker compose. Most of what I run on my server is at least in nixpkgs already if not already a NixOS module, and I just find it less frustrating to write nix than to deal with Docker.

That said, I know nix pretty well at this point and I would probably have a different opinion if I hadn’t spent so much time learning nix.

I think it's great to document this, and some people are going to prefer working with containers no matter what. That said, personally I've moved away from it and these days I just use nixos modules and run all of the services on my home server directly on the host. You don't get the same isolation that you might get with proper containers, and that might be an issue for production machines, but I find the simplicity is a win for a home server.

> If they use their rights from the GPL, they must retain the GPL option for others (copyleft principle); if they use their rights from the CC-BY-NC-ND-4.0 licence, they cannot make derivative works so won't be allowed to continue developing the project!

If they own the copyright to all of the code that was published, then they can use that right to relicense the code however they like without violating either of the licenses. That would, however, presume that they either did not accept contributions from anyone else prior to the change, had contributions assign them copyright, or removed code by those contributors.

And, of course, changing the license on new code doesn’t revoke the rights granted to people by the previous licenses if they had the code already.

My (probably somewhat incorrect) understanding of most European governments was that you might end up in a situation where you vote in the curb setbacks party and then afterwards they decide to form a coalition with the kill cancer kids party because they see it as the most expedient means to get a majority that can increase curb setbacks. Now you have a real problem because maybe you really do care about curb setbacks but not to the point of wanting kids killed.

My understanding is that’s more or less what recently happened in France.

It might make it easier to talk to your neighbor, who can more plausibly say “don’t look at me, I just voted for curb setbacks”, but it does come with some substantial downsides too, and in the end you still have broad multi-interest umbrella coalitions.

> Why tho? Just because we might disagree on the details of gender doesn't mean we can't discuss NIMBYism. I don't see what gender has to do with housing.

Imagine you have cancer, and thankfully there’s a medication that you can take that keeps your cancer in remission. You’ve been taking it for 15 years, and you’ve been living a pretty good life. Lately though, a bunch of people have been claiming cancer doesn’t exist, and if it does, your form of cancer definitely doesn’t. They’ve already made it illegal for kids to get treated for this cancer in several states, and as you’d expect a lot of kids are dying. Some states are trying to make it illegal for anyone to get treated for their cancer. Companies that used to sell merchandise to raise awareness during cancer awareness month. Oh, and you can’t get a drivers license anymore because your cancer suddenly means that you are “biologically dead”. A major political organization has a policy platform that would make it illegal for anyone with cancer to go into public, because they claim it’s contagious and kids might catch it, and later in that same document they say anyone who risks kids catching a disease should be put to death. One of the major political parties has essentially adopted this platform, and several states have started rolling out parts of the plan.

Now, your neighbor just wants to talk to you about the rules for how far back new houses should be set from the curb, but every other sentence is about how sick those people are who think they have cancer, and how great party is with all of the policies that would basically ensure you die.

Can you really have a polite with them? If so, then I guess we are just of very different dispositions, because I absolutely could not.

> Those larger parties still have to work together with other parties to form a coalition/anti-coalition. Those coalitions then end up running the country.

Although I think there might be some benefits to this style of government, I also think people over-index on it. One way or another these groups end up forming coalitions and making compromises in order to govern. In one case it happens before the election, and mostly behind the scenes with some influence from the primary process. In the other case, it happens after the election when the parties are figure out how to form a majority after the representatives have been selected. One advantage to the former is that at least you know who what other policies your special interest are going to align you with ahead of time, rather than finding out after the fact that your vote brought along more baggage than you bargained for.

> You and your friend might disagree about UBI, or trans rights, or whatever, but you both understand that you more or less agree on the other 9/10 issues.

But if one the people in that discussion is trans, and the other person doesn't believe that trans people are real, have a right to exist, deserve health care, etc. then it doesn't matter if they agree on 9/10 other issues. Same with abortion. If one person in a discussion believes in the value of rational evidence based decision making, and the other believes in woke 5g space lasers, there's simply no foundation on which to build a shared understanding upon which to base a conversation.

Many of the central arguments that are causing polarization in politics today are due to fundamental incompatibilities in values- the kind that no amount of agreement on other matters of policy

> Contrast that with american politics where it's all or nothing. If you like abortion and low taxes, there is no way for you to vote.

There absolutely is. There's no perfect candidate, but there's still going to be a better choice. You pick what matters most to you, and how many things you are willing to compromise for those things, make the best choice available, and work to push the discussion of one party or the other closer toward your views in the areas you don't like.

Neat. It seems to me like this is filling three separate gaps:

  - fixed point arithmetic
  - tagging values with units
  - localization for parsing currency names into units

I'm curious if Kotlin's type system is expressive enough to allow you to catch at compile time cases where you might be trying to, e.g. add USD to GBP.

I think you are on the right track, but realistically I think the answer is even more cynical: the last 20 years in software has been all about refining business models that remove choice and disempower customers. Quality doesn’t matter. Privacy doesn’t matter. Price matters a little, but only in the sense that you need to make your monthly SaaS fee low enough to avoid sticker shock- you don’t need to provide real value though. Just keep milking those monthly fees and make the UI a little worse every year or so.

Lack of interoperability and vendor lock-in, the move toward SaaS software that you run on behalf of your customers, making network effects fundamental to your value prop, bundling, and the enterprise sales tactics you pointed out are all ways that quality of software has been removed from the conversation entirely.

At best it may indicate that there's something worth looking into, but it doesn't tell you much about the actual productivity of the engineers. One engineer may be producing low quality output that requires a lot of re-work later, or they might be gaming the system by over-estimating work, or picking up lower priority work that was accidentally over-estimated in order to improve their numbers. They may be a domain expert in a particular system while the other developer is getting up to speed. One developer may be spending significantly more time mentoring or helping their team work better. They might be writing design documents or spending more time with customers. They might have been around longer and are regularly getting pulled into supporting things they worked on years ago, or getting asked for help from other teams who need their expertise.

Probably the same way it does with groups like actors and writers?

4 weeks after 6 years seems absurdly bad to me. The last job I had with fixed PTO had unlimited sick time plus 20 days per year of vacation starting (pro-rated) on your first day, and most places I’ve worked in the last decade have had “unlimited” PTO, which typically works out to around 6 weeks of vacation time plus unlimited sick time.

I’ve had good luck hiring contractors for Haskell related problems for much the same reason that hiring full time engineers to work with Haskell has gone well: the average quality of Haskell developers is high, and there are more people who want to work with Haskell than there are opportunities.

That probably wouldn’t scale up if you were hiring many tens or hundred of contractors. My experience with that degree of outsourcing hasn’t been positive irrespective of language though.

I still think this is an unnecessarily dire and antagonistic view of things.

> 1. You already have a confident haskeller or two on your team, ideally senior

There are really only three reasons any particular tech stack is ever selected for any project.

1. It's the standard at the company and you don't have a choice 2. You happen to be working in an extremely specialized field where one language is dominant (e.g. Haskell for compilers, python for AI) 3. Someone picks a language that they like and are confident in

I'd suggest that across the entire industry, (1) dominates by a large margin. It doesn't apply as much to startups though, because by definition startups aren't going to have a lot of existing code and won't have developed restrictive standards.

So yes, the biggest reason to choose Haskell is that you have a confident senior haskeller on the team.

> 2. Your tech needs are vanilla and back-end heavy -- writing UIs in haskell is a nonstarter, and heaven help you if you're not doing vanilla web apis + postgres etc

I agree with you about UIs. It's not a good experience and I wouldn't suggest Haskell for that. There are other specific areas where I wouldn't suggest it outside of a hobbyist project, like games or mobile development. There are still a lot of programs that need to be written and benefit from Haskell's strengths though, and sure, a lot of them are CRUDy web API things, because frankly that's most of all software that gets written.

> 3. You want primarily junior- to mid- talent (great for keeping burn low)

Haskell is perfectly viable if you want to hire a team of junior and mid level developers (so long as you have a more experienced person on the team to help them learn), but not exclusively useful in that situation. There are experienced Haskell developers out there, and there are a lot of highly skilled and experienced developers who are interested in- or at least willing to learn- haskell.

In general, I'd say that Haskell is a great choice for _most_ types of development, and can work for teams with a wide variety of experience levels. It's a real asset for hiring because there are more people who would like to work with Haskell than there are Haskell jobs out there, and in general I think Haskell still benefits from the python paradox (https://paulgraham.com/pypar.html) where people who know or are interested in it tend to be above average.

There is an extension that lets you do this now (OverloadedRecordDotSyntax) but truthfully I think it’s a really bad idea. The (.) operator already has a very concrete meaning in Haskell, and record dot notation means that you suddenly need to care about the specific details of how values are calculated. Field accessor functions are much better imo even if they seem a little odd.