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

Putting the I back in IDE

blog.janestreet.com

Post reply on HN
Print view View original

111–120 of 152 posts

Re: Putting the I back in IDE

#111

Post by oblio »

mannykannot wrote: post #106
oblio wrote: post #29

Earlier quoted context omitted.

You'd be surprised. Our domain has so much snobbery and elitism that it's entirely possible that a developer tried 1 (one) IDE, maybe decades ago, didn't configure it at all (or couldn't, at the time) and decided for all eternity that IDEs are bad. It's quite funny sometimes when you show someone modern functionality in a modern IDE and they have to accept that the people making IDEs are, basically, not all morons (w…

I have jumped around platforms quite a bit, and I try to use the IDEs that are available (right now I have XCode and PyCharm open on a Mac), but there is a steep learning and setup curve, and I usually don't have the time to work through a start-from-scratch tutorial, at least not initially. I am familiar with the sinking feeling that comes with realizing that my last hope is to use the search feature of the product'…

I've found that many IDEs can just copy keymaps from one another. That makes things A LOT easier during the transition period.

I also like to play with the UI, they're generally quite configurable, you can move windows, panels, show/hide buttons, etc.

By using these two tricks I generally get the core stuff quickly and then I branch out.

Re: Putting the I back in IDE

#112

Post by mezzode »

rasjani wrote: post #70
Finster wrote: post #51

"Every branch of every repo gets its own sandboxed directory. Your revision history in each branch, including uncommitted stuff, is persisted, as are build artifacts. When you switch contexts, each project is just as you left it." Isn't that just svn? Why force a git-shaped peg into an svn-shaped hole?

Or git worktree

+1 for git worktree, it's great for making temporary copies of a repo when you need them

Re: Putting the I back in IDE

#113

Post by bunderbunder »

oblio wrote: post #29
fsloth wrote: post #27

Visual Studio does everything within the same window (source code management, code review, diffs). Yes, it's great. It does not need any 'new' paradigm, that's the standard operating modus. It's a good thing this ideology of tools that simplify the process is spreading. But it's not novel. This article sounds like the author never used Visual Studio.

You'd be surprised. Our domain has so much snobbery and elitism that it's entirely possible that a developer tried 1 (one) IDE, maybe decades ago, didn't configure it at all (or couldn't, at the time) and decided for all eternity that IDEs are bad. It's quite funny sometimes when you show someone modern functionality in a modern IDE and they have to accept that the people making IDEs are, basically, not all morons (w…

I wouldn't chalk a lack of familiarity with Visual Studio down to snobbery and elitism.

I'd chalk it down to Visual Studio only running on one operating system, not being particularly useful for developing apps that aren't targeted at that platform, and having a very high price tag.

(The last two have changed, but only recently.)

Re: Putting the I back in IDE

#114

Post by bunderbunder »

oblio wrote: post #100
wmccullough wrote: post #98

Earlier quoted context omitted.

I see, I see. Thank you for the advice! I tend to want to learn how things "on the other side of the tracks" work mostly because I get tired of the heated debates around tooling and I'm determined to learn as much as I can so that I can be well-rounded (that and C++ has been the beast I never finished taming). Do you have any recommendations for a distro of Linux that would be easy to switch to? Go gentle on me, I'm…

Well, if you're motivated enough, don't switch. Just fire up a VM. Unixen are generally the same, but you won't figure that out at first, so you do want something a bit friendlier. My personal opinion would be to go with the mainstream distributions, since you want support from fellow humans on chat, forums, etc. I'm more of an Ubuntu guy, but people seem to like and use Mint or Debian or Fedora. Don't fall into an A…

Could go even easier by installing Git for Windows and using the included bash prompt.

It's a MinGW environment with very good factory configurations. It won't let you apt-get and run any old app, but it does get you all the goodness of a bash prompt and all the standard Unix command-line apps. All right there in Windows, without having to also learn and get comfortable in a new operating system.

Re: Putting the I back in IDE

#115

Post by lozenge »

sjakobi wrote: post #103
rasjani wrote: post #70

Earlier quoted context omitted.

Or git worktree

Oh, I had never heard of that command before. Does it work well, i.e. does it improve your workflow?

I generally have a worktree to develop in, and one for code reviews. So I can leave some indexed and some uncommitted changes in the first one, open a second IDE against the second one and use "find usages", "go to implementation" and other code navigation features missing from GitHub.

You can also create a worktree for a quick experiment (eg how many conflicts when I merge X and Y) and just rm it when you're done.

Sure, all these things can be achieved with git stash and git reset... but they are both difficult to keep track of and will cause your IDE to run its expensive reindexing.

It's kind of like how you could use pushd/popd and open subshells to work in one shell, but people prefer to just open another terminal window.

Re: Putting the I back in IDE

#116

Post by aspett »

pjmlp wrote: post #56

Programming like 1980! At least has colors instead of having everything in green. Really the extent people go to avoid using modern developer tools.

And so they should when modern is not as efficient as the alternative.

Re: Putting the I back in IDE

#117

Post by thedufer »

loup-vaillant wrote: post #62
fsloth wrote: post #27

Visual Studio does everything within the same window (source code management, code review, diffs). Yes, it's great. It does not need any 'new' paradigm, that's the standard operating modus. It's a good thing this ideology of tools that simplify the process is spreading. But it's not novel. This article sounds like the author never used Visual Studio.

Looks like the killer feature here wasn't doing everything from a single window. It was dedicating a sandbox per branch, saving everything, including uncommitted work and build artefacts. This is the first time I hear of this functionality. And it would be great to do that even in a disintegrated way, like, from the command line.

It can be done from the command-line (https://www.janestreet.com/tech-talks/code-review/); many people just find the Emacs integration nicer. But there are plenty of vim users who use the command-line instead.

Re: Putting the I back in IDE

#118

Post by [deleted] »

pjmlp wrote: post #73
pavlov wrote: post #64

Earlier quoted context omitted.

No, HTML is limited in the same way as terminal emulation: it's not the right tool to describe UIs and interactions. I'd like to see more progress made in real desktop interfaces.

> I'd like to see more progress made in real desktop interfaces. Come to the macOS/Windows developer culture.

[deleted]

Re: Putting the I back in IDE

#119

Post by timrichard »

dmitriid wrote: post #110
rantanplan wrote: post #55

Earlier quoted context omitted.

What do you mean by "not git integration"?

I personally find git integration in IDEA cumbersome and rather poorly designed. But I've seen my colleagues use it.

I have to disagree there.... I think Git integration in the Jetbrains IDEs are amazing. There's a general attitude the command line gives more power and flexibility than fancy graphical interfaces, and I'm with that 99% of the time. For me, Git integration is the exception.

I've found in many shops that people memorise a few favourite Git riffs and then just try to make any VCS task fit those regardless.

I find the Webstorm/IntelliJ Git integration to be very flexible... the Log view gives a lot of useful options to reason about the state of the various branches when there are several features in flight across the team simultaneously. Selective log view modes and the ability to group/visually reorder commits is useful too. I get a lot of use out of the Branch Compare tool (which is integrated with the diff merge tool), to show a snapshot of the differences between any two branches at any point of time, and to selectively merge across any small pieces of code interactively when a cherrypick of an entire commit would be too broad a brush.

I expect there are ways of doing similar things in the CLI, but I find the Jetbrains IDE implementation gives a lot of clarity and confidence in what needs to be done and what's about to happen. Certainly more so than most dev shops I have experience of, where it's a small set menu of pull/commit/ push, merge, and optimism.

Re: Putting the I back in IDE

#120

Post by eadmund »

Const-me wrote: post #30
eadmund wrote: post #25

Earlier quoted context omitted.

Those features are available in emacs, and work in both the GUI and the terminal. For auto-complete, vanilla emacs has dynamic abbreviations; there are several packages for fancier auto-completion; company-mode, for example, works just fine in the terminal, as well of course as in the GUI (X11, macOS or Windows). Likewise with tooltips, which in the terminal generally are generally displayed in a special region of th…

> give emacs a shot. Both Prelude & spacemacs are excellent configs for it. Are there any advantages over Visual Studio + Visual Assist, for C++ or C# languages? Because I see many disadvantages. About text editor features, your workarounds have flaws compared to good GUI. For tooltips, that special region of the terminal is physically separate from the cursor. For folding, a separate, visually distinct indicators of…

> Are there any advantages over Visual Studio + Visual Assist, for C++ or C# languages?

A fully-extensible, flexible environment which anyone (even a secretary!) can easily extend.

> About text editor features, your workarounds have flaws compared to good GUI.

They're not workarounds; they are the features. emacs has a GUI. I repeat: emacs has a GUI. Tooltips in a GUI display as you'd expect. Folding in a GUI displays as you'd expect.

> Another text editor feature hard to do in text mode is spell checking for strings and comments. Color is already used for syntax highlighting, so wavy red underlines come handy.

Terminals support underlines!

> But visual studio is more than an editor, it includes a build system, debuggers and profilers, package manager, and many more related features.

Have you ever used emacs? It's more than an editor; it connects to build systems like make, maven, gradle, ant, what-have-you. It has its own elisp debugger, connects to gdb, SLIME provides an integrated Common Lisp debugger &c. It has a profiler. It has a package manager. It has a best-of-breed git interface, Magit. It has a best-of-breed personal organiser, Org-mode. It has multiple email clients (rmail, vm, gnus & notmuch come to mind, but there are probably more). It has multiple web browsers (emacs-w3m, eww, w3 & a new experimental WebKit-based browser). It has multiple image viewers. It has multiple terminals & its own shell.

Emacs is far, far 'more than an editor.' It's probably the single editor which is the furthest from being just an editor. Don't trust me: give it a shot! It really is a wonderful experience.

And yes, it has a GUI. Images, scrollbars, menubar, toolbar: the works. Runs on X11, macOS & Windows. And it also runs perfectly well in a VT100 terminal. You can use the same emacs locally and remotely, over SSH. It's pretty awesome.

Post reply on HN