Guilty as charged! :D Short essays are definitely not my forte. (and this one is definitely longer than I wanted it to be, but in my typical style I kept adding to it after I wrote the initial version, and I'll probably add even more content after I go over all the discussion here)
Well, I guess that means I'm still a pretty poor writer. :D (I'm the author of the article) These days I do use AI to touch up my grammar and fix my typos, but I'm still write my articles myself and you feel that the article lacks substance - that's on me.
For me essays are something very personal, so it'd hard for the AI agent to read my mind about my thoughts on a subject.
I think these days F# is probably a big more polished than what you remember, so perhaps it's worth giving it another shot.
Being a hosted language always requires certain compromises (something that was also apparent in Scala). I used to do Scala professionally in its early days, but for me it felt it added just as much complexity as it addressed. I focused on Clojure back then (on the FP side at least), and I do think that F# probably brings more to the table than Scala. (if one is not constrained to Java, that is)
The tooling story is not great, but I've almost never seen great tooling for a language that's not super popular. I'm guessing what you get today with Rider is more or less as good as what VS has to offer.
> "I'm gonna someday" is not "addressing" the complaint that things aren't documented, other than to make an excuse.
By acknowledging a complaint as valid I'm kind of addressing it. :-) Some things are real problems that I don't have the time to fix quickly. I can either make promises that I can't keep or be open about this. From time to time someone gets inspired to help.
> "It's not Clojure specific" is immediately followed by "so there are some protocol responses that people had to reverse-engineer that are tightly coupled to Clojure metadata".
That's a side-effect of under-specification in the protocol and it's mostly related to the names of keys in the responses. The data itself is quite generic, but the names of the keys came from Clojure terminology and in some cases it might be better to change them. Not a big deal for sure, but rather an area for small improvement.
> "We added the other serializer options much later and almost nobody uses them so we must have made the right decision" - there's a huge amount of conceptual inertia when there's a default; the only thing this observation supports is that the default isn't _unpleasant enough_ to compel users to switch.
Perhaps that's just inertia indeed. From my perspective if something is really needed/much better it tends to get used. I can only speculate at this point why the new serializes didn't take off.
Hopefully this follow-up makes my responses a little bit less odd.
That's a fair point, although I can think of examples in the IDE reals as well - e.g. in the world of Java Eclipse and NetBeans were popular (and open-source), but gradually IntelliJ IDEA dominated them for various reasons. I also remember all the Borland tools (super popular in the 90s) that have mostly disappeared by now. I definitely think that open-source projects are more likely to survive long-term, but it's not like they don't fail.
Btw, I think TextMate is open-source these days as well.
Yeah, I mostly had in mind the first group you've described, but in my experience they are by far the biggest group. Truly "professional" recruiters are very rare.
I agree that referrals often yield the best results, but that's quite orthogonal to the problem I wanted to tackle with my article.
reply