Live data from Hacker News

Putting the I back in IDE

blog.janestreet.com

11–20 of 152 posts

Re: Putting the I back in IDE

#11
It sounds really cool but also very opinionated workflow. Not to say I don't agree with it but I can only imagine the amount of effort making this whole workflow was also what went into defining what that workflow was.

There are a lot of workflows and I personally don't think it's on an IDE to enforce that. Yeah sure it's "integrated" but it's to the extreme which I somewhat disagree with.

If their workflow and emacs scripts were open sourced, I could actually try it and watch my tongue but since it's all proprietary all I can really say is good for you, thanks for sharing but I probably wouldn't use it myself.

Re: Putting the I back in IDE

#12

This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.

There's nothing about terminal-like windows that precludes using the mouse. The magic of escape sequences makes e.g. mouse selection in Vim possible. I just don't find it very useful when there are keyboard shortcuts for everything.

When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? I much prefer the tab-completion I get with the former, especially in hierarchies with high branching factor.

Re: Putting the I back in IDE

#13

This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.

I agree. Another reasons why I prefer GUI are auto complete, tooltips and context menus. Also for some documents like xml, also when working with other people’s code, I find it useful to collapse/expand blocks of text. All these features pretty much require a GUI-based editor.

There are vim plugins for auto-completion and it supports code folding out of the box. I'm not sure what you use tooltips and context menus for, but that functionality is probably available via some : command.

But then most command-line editors are actually GUIs in the terminal with excellent keyboard support.

Re: Putting the I back in IDE

#14
post #9
post #8

So what does this do that IntelliJ and other IDEA-based IDEs can't do for me? They already have Github API integration plugins.

I think (as @cromwellian pointed out), IntelliJ has most of this covered with tasks, contexts, shelving, etc. Better, possibly, as it has quite a number of built-in tracker integrations. Not sure about the code review aspect though. I haven't tried any of the code review plugins (gerrit etc). They could be good if they integrate with diff viewer, as it is IMO one of IntelliJ's best features.

I agree on the diff viewer.

Check out Upsource for code reviews. It's pretty much exactly what you would expect from a JetBrains-built code review tool.

Re: Putting the I back in IDE

#15
This is pretty cool. Although, on large codebases a la facebook or google size, I would think having a copy of the repo per branch might be intractable - also, somewhat unnecessary since one can just switch branches...

Re: Putting the I back in IDE

#16

This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.

Just want to make sure that people realize that Emacs has decent support for pointing devices and can link with the native GUI libraries on Windows and Mac and GTK+ on Linux.

So for example although the (very old) version of Emacs (/usr/bin/emacs) that comes with OS X was built in such a way that it can communicate with the user only via the terminal, the following command line will install a GUI-capable Emacs:

brew tap railwaycat/emacsmacport && brew update && brew install emacs-mac

(The simpler command line `brew update && brew install emacs` would install a GUI-capable Emacs, too, but delivers the pure-FSF version of Emacs, which for mac for many years now has been buggier than the FSF version plus Mitsuharu's patches, which is what the first command line delivers. In the past there have been times when `brew install emacs` would install an Emacs that is just not usable because of bugs while `brew install emacs-mac` would install and Emacs that works fine.)

Whether or not the code Jane Street added to Emacs can be used with a pointing device I do not know.

Re: Putting the I back in IDE

#17
post #9

Earlier quoted context omitted.

I think (as @cromwellian pointed out), IntelliJ has most of this covered with tasks, contexts, shelving, etc. Better, possibly, as it has quite a number of built-in tracker integrations. Not sure about the code review aspect though. I haven't tried any of the code review plugins (gerrit etc). They could be good if they integrate with diff viewer, as it is IMO one of IntelliJ's best features.

I agree on the diff viewer. Check out Upsource for code reviews. It's pretty much exactly what you would expect from a JetBrains-built code review tool.

I've glanced at Upsource out of curiosity only (I mainly work solo). It looked good of course. I was commenting about code review here with regard to the Jane Street article -- it does seem IntelliJ does nearly everything their custom tool does out of the box.

Re: Putting the I back in IDE

#18
post #12

This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.

There's nothing about terminal-like windows that precludes using the mouse. The magic of escape sequences makes e.g. mouse selection in Vim possible. I just don't find it very useful when there are keyboard shortcuts for everything. When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? I much prefer the tab-completion I get with the former, especially in hierarchies with…

> When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI?

Really depends on the workflow. If I know where I'm navigating then I prefer cd, if I don't then a gui is better than a cd/ls loop. Fortunately programs like ranger cover the latter quite well too.

Re: Putting the I back in IDE

#19

This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.

I agree. Another reasons why I prefer GUI are auto complete, tooltips and context menus. Also for some documents like xml, also when working with other people’s code, I find it useful to collapse/expand blocks of text. All these features pretty much require a GUI-based editor.

vim supports all of those things out of the box, both in GUI mode (gvim/MacVim) and terminal mode (vim).

Emacs supports all of those things out of the box as well.

Re: Putting the I back in IDE

#20

This is cool, I guess. Personally coding in a terminal like window for me would be awful - I like using my mouse to navigate among folders and save stuff etc in Atom/VSCode like environments. Plus, how often are people switching branches of code that the number of key strokes for git becomes a problem? Seems like an overengineered solution for a very niche audience - if it works for them great though.

I agree. Another reasons why I prefer GUI are auto complete, tooltips and context menus. Also for some documents like xml, also when working with other people’s code, I find it useful to collapse/expand blocks of text. All these features pretty much require a GUI-based editor.

Spacemacs has excellent context menus. It was suprising how discoverable everything is!
Post reply on HN