Clojurians Log v2

@cfleming In this particular case, we’re talking about someone going from a very dynamic context to a very statically typed one. I realise that people normally probably attribute the “overwhelmedness” that he is feeling to the learning curve that anyone would experience going from one language to another, and in particular from dynamic to static or vice versa. And therefore, a lot of people might brush off this sort of feeling, saying, “Ah, well, that’s to be expected.” At the same time, I feel like developers are expected (or expect themselves) to move between a lot of different languages in their day job, e.g. when undertaking devops tasks on multilingual projects. Having whatever editors support the developer’s “style of reading” is worth considering imo. And it is considered, to some degrees - observe, for example, the “Distraction Free Mode” in IntelliJ, or the ability to show or hide line numbers or whitespace characters in whatever editors. And were it that easy to implement, I’m sure someone would have done it for e.g. Java in IntelliJ already (for example, a disgruntled Clojurian forced to work with some legacy system 🙂 ). I suspect that there is a need, or that it could prove valuable and create the need if it existed, but that it doesn’t weigh up against the effort needed to implement it. Do you have any idea of what kind of effort it would take to implement something like that in a plugin for IntelliJ, for example? I seem to recall you praising JetBrains for providing such an excellent platform for you with so much stuff working out of the box, and so many affordances for building stuff on top of that box. I’ve also been surprised myself at times with IntelliJ’s capabilities. So, maybe it’s easier than I think, by some definition of “easier” 😉

@jeroen.dejong that might be a good low-effort solution!

> a lot of people might brush off this sort of feeling, saying, “Ah, well, that’s to be expected.” It’s not so much that, it’s that I think the types are a fundamental aspect of working in a statically typed context, and I’m not sure it’s a good thing to hide them. Your colleague will have to get used to them at some point, at best hiding them will delay that moment. As soon as they start writing code, they’re going to need to both read and write them.

I’ve actually been considering the opposite, a mode which would show the types that Cursive has inferred - Kotlin has this, for example.

Let me think about it, it’s probably not hard to implement but I’ll have to decide if I want to implement it or not 🙂

Sure! It was actually just meant as an open question, not as a feature request 😅

Showing inferred types sounds really cool, too!

And, to be perfectly clear, my colleague is not working in IntelliJ, and he is not working with Clojure. I was just curious whether somebody had thought about this or seen examples of it already, and I couldn’t think of a better place to ask off-hand 🙂

Oh, I see - I had assumed this was someone having problems with type hints in Clojure. What’s he working in?

He’s coming from vanilla JS to Flow, using Vim 🙂

Pardon the confusion! I’m beginning to realise that this channel is primarily used for communication between you and users concerning bugs and feature requests. I thought that other users might also partake in general discussion about editors and editor usage, but it’s not quite as lively in that regard as I had hoped - rather, you loyally respond to everything, which is awesome, but I don’t want to burden you personally with extraneous musings. Perhaps I should look for a more apt forum for such subjects.

#editors is always there for you 🙂

Awesome, thanks!

Yes exactly @cfleming

Sorry, but is this possible?

It’s not possible in Cursive right now, no. I’ll take a look when I get a moment to see how hard it would be to add.

Thank you!