Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear JetBrains, Don't mess with your UI

neil.computer

Post reply on HN
Print view View original

341–350 of 420 posts

Re: Dear JetBrains, Don't mess with your UI

#341

Post by jen20 »

uwuemu wrote: post #188
colordrops wrote: post #96

Earlier quoted context omitted.

If you are a professional developer, and plan to be working for several decades, is it really that much of an investment to maintain your editor config a la vim or emacs? I did a lot of work setting up vim 10 years ago, and have only had to tweak it since. It works exactly as I expect, anywhere, in a terminal, for free, and setup is as easy as checking out a repo and running a script. JetBrains is good for stuff I ra…

You can't possibly call yourself a "professional developer" (and it sounds like you're not pointing out that you're paid for the work, but that you're a "pro") and then talk about debugging as something you rarely do. If debugging (with a debugger) is something you rarely do, you may be paid for your work, but I wouldn't call you a pro. You should be debugging alongside development to gain deep understanding and redu…

This kind of post is unhelpful and unnecessary.

Debugging and using IDEs are entirely orthogonal. DTrace and lldb are far more valuable to me than a graphical step debugger, which I effectively never use. As it happens I use JetBrains IDEs full time.

Re: Dear JetBrains, Don't mess with your UI

#342

Post by gorjusborg »

ntp85 wrote: post #269
sgt wrote: post #176

Earlier quoted context omitted.

Why would one do remote development with laptops being as powerful as they are today (think: the raw power of an M1 Mac Book Air even).

"Remote development" does not necessarily imply that development happens on a remote machine. I use remote development extensions to work directly on projects inside WSL2.

Same here. 'Remote' development for me isn't about how far away it is, it is about developing across (virtual/container/cloud) 'machine' boundaries.

Re: Dear JetBrains, Don't mess with your UI

#343

Post by rc_mob »

faizshah wrote: post #52

Eh, I have used vim, spacemacs, sublime, vscode, atom, eclipse and netbeans. Jetbrains IDEs have superior functionality out of the box across languages and don’t require me to mess with and debug a million plugins. I don’t mind a UI refresh, it’s going to be just like the gmail refresh everyone hated it and now we’re all fine with it. I just wish they would invest more money into things that are actually a problem cu…

I still hate the gmail ui but what can I do about it?

Re: Dear JetBrains, Don't mess with your UI

#344

Post by jen20 »

sylv3r wrote: post #141
happymellon wrote: post #38

Earlier quoted context omitted.

On the flip side, the only thing I want Jetbrains to do is implement proper UI scaling. I want to be able to hit Command+Plus and scale up the whole interface for presenting something to the team or when I have to code pair with someone who doesn't have as large of a monitor as I do. Presentation mode is an absolute mess, and does not help with code pairing or code review presentations, and font scaling only affects…

> On the flip side, the only thing I want Jetbrains to do is implement proper UI scaling. Oh man I'm still mad that if I want to present my Jetbrains IDE screen and make it readable, I have to change 2 fonts, one for the editor, one for the interface.

Shift shift -> Enter Presentation Mode.

(Replace shift shift with whatever you have the “everything” search bound to).

Re: Dear JetBrains, Don't mess with your UI

#345

Post by drewpc »

I see your points and understand the frustration. The minor changes over the years haven't bothered me too much. What really messed with me was when the commit pop-up (with diffs) was changed to a tab, nestled in the same space as my files. Nooooooooo! I want the pop-up. I want to know that this is different from what I was doing before.

Re: Dear JetBrains, Don't mess with your UI

#346

Post by jen20 »

happymellon wrote: post #167
sylv3r wrote: post #141

Earlier quoted context omitted.

> On the flip side, the only thing I want Jetbrains to do is implement proper UI scaling. Oh man I'm still mad that if I want to present my Jetbrains IDE screen and make it readable, I have to change 2 fonts, one for the editor, one for the interface.

It's nice that it's being an accepted point of view this time. Usually I get a lot of aggressive responses about how I don't understand presentation mode. I do, and it's crap.

By contrast, I only want the content to scale, and actively cannot stand entire UIs scaling and looking and feeling like web pages. If this was ever implemented, it would need an opt-out to please us both.

Re: Dear JetBrains, Don't mess with your UI

#348

Post by jen20 »

sirwhinesalot wrote: post #320

I've been looking for a reason to leave the comfort of JetBrains tools for VSCode, and this might be it. I don't have a particularly strong opinion about the new UI, other than that it looks way too much like VSCode and way too little like the current one. The main reason I use JetBrains stuff is that I'm familiar with the interface, it's messy but I know where to find all I need. VSCode is unusable without writing j…

> I've been looking for a reason

If you’re looking for a reason, you’d have found one regardless of anything else.

Re: Dear JetBrains, Don't mess with your UI

#349

Post by KallDrexx »

wruza wrote: post #288
selfhoster11 wrote: post #231

Earlier quoted context omitted.

I think that parent’s point was that debugging is an exceedingly powerful tool, and therefore leaving it out of your toolset by definition makes you less powerful as a programmer. It’s not even such an esoteric skill - operating the simplest kind of a GUI debugger is maybe learning 5-6 different actions, and the IDE often takes care of the details of setting up the debugger for you.

On the contrary, I find a common debugger (see questions below) an underwhelming experience, not a powerful tool. Can it: - assign (scenario, subsystem, level, description) to breakpoints and watches, so they can be turned on/off or selected in groups for debugging without removal? - commit these scenarios of bps and watches into a repository? - edit/read them in a textual form to patch or share over an IM? - store t…

> - assign (scenario, subsystem, level, description) to breakpoints and watches, so they can be turned on/off or selected in groups for debugging without removal?

In Jetbrain's tools they definitely can. I can

* create a bunch of breakpoints

* give them descriptions

* only have them break on execution under certain conditions (conditions stated via the programming language being debugged, so `my_struct.some_func() == 5`)

* disable and enable breakpoints with a click of a button

* have a breakpoint only become active when another breakpoint got hit (and therefore only cause the debugging logic to execute in certain code paths

* Have a breakpoint not stop execution when it gets hit, which is useful because I can then

* Log when a breakpoint gets hit, including it's stack trace (so I can see exactly the flow that got me to that breakpoint)

* Evaluate some variable when a breakpoint is hit and log that evaluation.

All of this with an extremely simple UI that can be manipulated without any recompiles and while the application is running. I've gotten tons of value of debugging complex scenarios in both C# and Rust via this constructs.

So while I'm not going to convince you that debuggers are worthwhile, to call them "too dumb to be useful" is pretty naive.

Re: Dear JetBrains, Don't mess with your UI

#350

Post by sgt »

suchar wrote: post #264
sgt wrote: post #245

Earlier quoted context omitted.

I guess if your IDE is as responsive as anything else locally and only the compiling and runtime happens in the cloud it might be somewhat pleasant to work with. But what if you decide to do something from a coffee shop and the WiFi is super laggy. Or doing something while traveling etc. I like to know that my dev station is independent of an Internet connection.

With crappy Internet connection you still can do remote development (it doesn't take much bandwidth, after all it's mostly text). But what if you need to download dependencies/docker images or upload e.g. docker image? With a remote development you can offload that to a beefy server with gigabit connection.

That is indeed a good point.
Post reply on HN