bozhidar

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 put! To me - it always felt like this here. I have serious doubts that most people even read the articles linked to HN discussions.

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.

Great story! Thanks for sharing it!

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.

But it's Windows-only, so it's not an option for me.

> "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.

Thanks for sharing!

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.

I'm always around! :D Thanks for the kind words! Much appreciated!

Thanks for the kind words, everyone! They mean a lot!

You're welcome! :-) Thanks for the kind words!

Thanks for your support! Much appreciated!

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.

Thanks for the kind words! Much appreciated!

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! :-)

You're welcome! Thanks for the kind words!

Thanks!

You're welcome!

Can't fit all the great books in a single talk, right? :-)

Thanks, much appreciated! (RuboCop's author here)

Yeah, you're right. I was triaging and cleaning up the open issues prior to launching the new site.

Now that the guide has more editors I'm optimistic that we won't end up in a situation with that many non-triaged tickets down the road.

Then is also a keyword. :D

As for hash literals - I didn't like the addition of the new syntax simply because it's limited to one type of keys. We had a perfectly good universal syntax and introduced a second one just to save up on typing in one common usecase. Not to mention that in the 1.9 syntax you don't use keywords directly but labels, which are different syntactic construct (:keyword vs label:). I think I understand your perspective, but it seems you value typing less and subjective aesthetics and I value mostly simplicity (minimalistic syntax and uniformity being some of its key aspects).

You've missed my point about `&.` (probably because I didn't provide much of an explanation) - it's fine in certain cases (your example is a good one), but it's also something that can be easily abused. Very often I've seen people use `&.` even for methods that can never return `nil`, which is confusing for people who read their code. I've also seen plenty of methods which could have returned a en empty collection on an empty string that return a nil for no good reason, but it's easy to deal with nil now, so why bother to think carefully... Every feature that promotes sloppy APIs nil is a potential liability and should be used carefully.

Well, I'm sorry if it seems to you like this, but there were plenty of features I didn't like in the past as well. :D I just felt that recently things took a turn for the worse. Language design doesn't get easier with time - quite the contrary, because your options constantly shrink.

If that's your only take away I guess I've failed to communicate my points.

Yeah, that's right. Unfortunately different people put different meaning into "static analyzer". Obviously linting is also done via static analysis of the code.

Guilty as charged. :-)