4 ms·
besides all the reasons others listed: - "the common dev" isn't familiar with it as well the hen/egg (half) problem of - if most users are "specialists" then
by dathinab 2y ago
besides all the reasons others listed:
- "the common dev" isn't familiar with it
as well the hen/egg (half) problem of
- if most users are "specialists" then you don't need compiler/tooling/doc with very good UX for non specialists, but until you have very neat UX even for non specialists you will not get a lot of traction with non specialists and in turn it might seem pointless to fix the UX
I say half problem because in my experience fixing it is also beneficial for "specialists".
This problem also overlaps with perceived (and sometimes actual) gate keeping and/or elitism.
Basically the same reasons why e.g. Haskell is much less widely used then it could be (and why most usage is in companies mostly filled up with people from Universities which have it as a required (or strongly recommended) course.
Just with more issues (listed in some of the other responses) added on top of it.
- estebank 2y ago> I say half problem because in my experience fixing it is also beneficial for "specialists". This is critical. Once I realized that even experts didn't necessarily have homogeneous advanced knowledge of the entire language, it became easier to justify to myself spending time on improving the diagnostics of uncommon errors for clarity and learnability. An expert requires less explanation, but they still require one. And I also suspect that spending time on better DX at the right time of the adoption curve has an outsized impact on it. The bad part is that it is a hard, slow, endless and somewhat thankless job (you're going against the grain of the compiler design half the time, adding logic that needs to be maintained, and for every case you handle ten more pop up elsewhere that need to be handled in a different way).