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.
I guess for the terrible jobs they'll still have the benefit of a better pitch working better with the not-so-great candidates that'd be willing to do that job. :-) Obviously there's a limit to how much a recruiter can do in such cases.
One can argue that things stay the same until someone (and by this I don't mean a single person) tries hard enough to change them - e.g. now there are dating apps where men simply can't start the conversation. Accepting the status quo as the law of nature certainly won't change anything.
Fair point, although as others have mentioned Prelude does look like stock Emacs in many ways. :-) I'll put a note to record some screencast in the future, as I think it will give a better idea of prospective users about the nature and features of Prelude.
Great feedback about the bundled packages - I've mentioned a few of them on the homepage. Unfortunately I haven't had much time for OSS lately and I never got to writing proper docs. Future goals! :-)