"The Economics of Programming Languages" by Evan Czaplicki (Strange Loop 2023)

For me, my favorites were: 0. "Computational Physics, Beyond the Glass" by Sam Ritchie (Strange Loop 2023) - [link] - This guy created an interactive Lisp-based Physics visualizer and got started on it by reading Structure and Interpretation of Classical Mechanics . He now has a full-fledged project, and touches upon many ideas for educating people through innovative means. Really loved this video. Connected the ideas of Logo programming environment and something like a LISP-Physics visualizer. 1. "The Economics of Programming Languages" by Evan Czaplicki (Strange Loop 2023) - [this video] - How does creating a new programming language work really? Who are the players, and what goes behind? Very highly recommend this funny, informative talk to understand aspects of creating a programming language other than the theoretical ones. 2. Function Composition in Programming Languages - Conor Hoekstra - CppNorth 2023 - [link] - This is actually about array languages and Haskell and not C++. Encountered "tacit" programming for the first time, and it opened a slightly new way of thinking for me. And others that I liked were: 0. Ruby on Rails: The Documentary - [link] - Not a Rubbyist, but still liked this documentary. 1. "Software & The Game of Go" by David Nolen (Strange Loop 2023) - [link] 2. "Making Hard Things Easy" by Julia Evans (Strange Loop 2023) - [link] - I always liked Evans' written content and zines, as they were fun to read and helped people. It was nice to see how she operate

> if you don't care about the feature ... all you're left with is a broken window. Maybe. Or maybe I'm left with a building that works fine for me. It might be lacking some features that some people want, but maybe thats ok. > Maybe the onboarding is the real issue. ... the maintainers are too busy to do that themselves most of the time. Yeah; I saw a great talk from Strange Loop the other day by the developer of Elm on the economics of opensource software[1]. He pointed out that a "good" opensource project really wants good dev work, a maintained issue tracker, infrastructure (CICD, etc), a good website, documentation, blog posts, onboarding of devs, community stuff, conference talks, trademarks, a roadmap, and so on. But it takes more than one person to do all of that. It takes a whole team. And we're spoiled by opensource projects like React or Rust which are sponsored by companies with money. My little opensource projects just have me, in my hobbyist time. And I'm not very good at all the non-programming things. And I'd much rather be programming than doing all of that other stuff. I think a lot of projects really want fulltime maintainers. But instead they just have the unpaid, overworked authors doing what we can. Of course users want better. But, well, thats how it is at the moment. Honestly, its surprising that everything works as well as it does. [1] [this video]

I am not an OSS contributor, so I have no personal experience whatsoever in this context. But I saw this talk by Evan Czaplicki (author of Elm) a while ago.[1] The talk is primarily about the economics of open-source programming languages, but I think that a lot of the issues discussed overlap with other areas of OSS. From the description of the youtube video: > In the mythology of open source, programming languages are created by people who seemingly have no direct economic function. They are just really good at compilers (somehow) and have a house to live in (somehow) and have a lifetime to devote to creating a useful programming language (somehow!) > We will examine specific organizations that create programming languages. Where do the salaries for compiler engineers come from? How does Go end up with 5 engineers and Dart end up with 30? Who signs off on these expenses and why? Does this put any boundaries on language design or development practices? And how do the economics work for people outside of the major tech corporations? > My goal is to give the talk I needed to hear 10 years ago when I was just starting on Elm. By clearly delineating the many variations of corporate funding and independent funding, I hope users will come away with a better foundation for evaluating and comparing programming languages. [1] [this video]

We haven't talked enough about the second-order effects of open source on the economics of programming as a profession. I'm glad to see that starting to change[1]. Open source makes it harder to make a living as a programmer (at least an author of libraries, tools and infrastructure). Keeping server utilities closed source while still allowing clients to have full access to the source for client tools and self-hosting utilities seems like a pragmatic approach to the user-centric principles of open source. This way, companies can continue to maintain some competitive advantage with their own investment into closed source code while still enabling users to own, control and contribute to software that runs on their machine. The crucial element here is maintaining low switching costs by allowing a marketplace for _real_ competition on quality and cost of compatible services (as well as allowing self-hosting). This is the kind of software freedom that actually benefits users. [1] - Evan Czaplicki's talk at Strange Loop this year made some similar points: [this video]

I don't agree with the person's suspicions, but I can speak to your question. If you're making over $1M/year or have more than 250 employees, you have to pay for Visual Studio or the C# DevKit in VS Code. Microsoft has been taking the open-core of VS Code and putting proprietary extensions into it. However, this isn't just C#. Microsoft has also replaced the open-source Python extension with something closed source. There is an alternative to Microsoft's tooling with JetBrains' Rider. Rider is pretty amazing. It's much higher quality than any of the other JetBrains tools and part of that is that the .NET ecosystem is really amenable to tooling (and paying for tooling) and that JetBrains had been creating ReSharper for Visual Studio for a long time (so they already had all the .NET intelligence built out). There was a thing where Microsoft was going to remove hot-reload from the dotnet CLI tool and make it only available in Visual Studio. I kinda felt like some of this was motivated by timing more than strategy, though. The CLI's hot reload had some rough edges and .NET has corporate style release dates with fanfare like .NET Conf. But the .NET hot-reload is quite excellent. Most edits can be hot reloaded and you can set it to simply re-compile and re-run for the ones that can't hot reload (and it just takes a couple seconds). It's dead simple to use and works (and the amount of time I've wasted to get hot reloading in Java is just incredible). Really, every ecosystem tries to

I think Evan's pointing at something, and everyone's looking at the finger. I don't think this is really about Elm at all, but the preparation for Arcadia. In his talk, Economics of Programming Languages [this video] , he does reveal a peek at what he's been working on for the past seven years: a query language with functional ideas applied to them. He points at the boundaries in web apps that typically destroys type information: - language <-> storage - storage <-> wire What if we could preserve the type information across these boundaries? What would that buy us? One answer he had was easier migrations. They'd just be a type diff, rather than hand-written SQL. So I think the right question is, can we infer what Arcadia is going to be like given the changes he's shipping with Elm? What does incremental compilation give query languages?