Great post. I think that skill floor/skill ceiling is a great framework for thinking about programming language accessibility. But I think there is more as well...
https://twitter.com/joelquen/status/1446125654345277445
An important factor is not just the skill floor needed to get started, but the skill floor needed to understand (and maintain!) other people's code. That is, what skill level do you need to participate in a programming community?
For example, lisps have a very low skill floor, but my guess is that you need a high skill to participate in the current CL programming community. It's interesting to see the difference between CL people and Clojure here :)
OTOH, Go was explicitly designed to have a low "skill ceiling" which limits what you can do, presumably with the goal that all code would be maintainable by anybody.
Python is great example of a language with a very low skill floor and also a high skill ceiling. What's nice though, is that Python community eschews clever code, and so the vast majority of Python code is straightforward and easy to understand.
C# and Java also have a reasonable low skill floor (but not nearly as low as a scripting language -- you have to understand complicated stuff like builds, jars/dlls etc). You can also do complicated stuff in them, but again, the vast majority of C#/Java code is straightforward.
So that's why I like #fsharp. A low-ish skill floor (for a statically typed FP language, anyway!), and more importantly, the F# community values straightforward code. Let's keep it that way. If you want more complex features, use another language!
Seriously, I love that there is a whole ecosystem of programming languages, each with its own style & philosophy. Rather than forcing a language into something it wasn't built for (OO Cobol, anyone?), just take each one as it is, and switch to a different language if you need to.
Finally, what's considered "straightforward" obviously changes over time. Generics were exotic at first, but are now widely accepted. Ditto for LINQ style pipelines, and lambdas, and more recently "async". And we can see the "pipe" operator becoming mainstream as we watch!
So, maybe in 10 years, type classes (or dependent types, or effect systems) will be considered common knowledge, and in that case I would have no problem with them in F#. The trick is to be able to innovate without getting too close to the bleeding edge!
And please read this excellent follow up by @algo_luca
https://twitter.com/algo_luca/status/1446392793459462144
And going back to F#, here's a great example of what I'm talking about in terms of accessibility
https://twitter.com/dzoukr/status/1446377599215808518
• • •
Missing some Tweet in this thread? You can try to
force a refresh
