Fork me on GitHub
#cursive
<
2020-10-05
>
reefersleep12:10:22

A colleague of mine is used to coding without type annotations, and has now landed in a project that is full of them, and he is overwhelmed when reading code. I was wondering if there are any examples of editor support for hiding types? Just any editor, any language, just an example. We can “fold away” code in a wide array of editors, hide docstrings, stuff like that. I have no trouble imagining that an editor could be capable of hiding all of that type noise as well, at least in a read-only mode. But I wonder if there’s ever been a need strong enough to actually generate in-the-wild examples.

cfleming22:10:29

It’s definitely possible with folding, yes. I’d question how bad it really is, though - I have tons of type annotations in the Cursive source, and I can read it fine. I’d definitely question the “need strong enough…” aspect.

thumbnail06:10:42

I've seen styling in emacs where typehints are way lighter colored than the rest of the params. I don't think this is possible in cursive yet, but might be a good alternative

reefersleep08:10:18

@U0567Q30W 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” 😉

reefersleep08:10:33

@UHJH8MG6S that might be a good low-effort solution!

cfleming10:10:36

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

cfleming10:10:31

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

cfleming10:10:57

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 🙂

reefersleep10:10:49

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

reefersleep10:10:06

Showing inferred types sounds really cool, too!

reefersleep10:10:48

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 🙂

cfleming10:10:42

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

reefersleep10:10:58

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

reefersleep10:10:07

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.

cfleming21:10:54

#editors is always there for you 🙂

reefersleep12:10:58

Awesome, thanks!

jacklombard13:10:34

In the color scheme for clojure, function definition styles are inherited from symbols. Is there anyway to separate function definition from symbols? Basically I want to have a color scheme like this https://github.com/tonsky/intellij-alabaster which is unfortunately not able to highlight function definitions because they are symbols

jacklombard13:10:34

In the color scheme for clojure, function definition styles are inherited from symbols. Is there anyway to separate function definition from symbols? Basically I want to have a color scheme like this https://github.com/tonsky/intellij-alabaster which is unfortunately not able to highlight function definitions because they are symbols

cfleming22:10:11

Just to be clear, you’d like to highlight the function definition symbol differently from the rest? So the foo in (defn foo [] nil)?

jacklombard07:10:05

Yes exactly @U0567Q30W

jacklombard04:10:20

Sorry, but is this possible?

cfleming01:10:27

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.