Live data from Hacker News

Putting the I back in IDE

blog.janestreet.com

131–140 of 152 posts

Re: Putting the I back in IDE

#131
post #84

Earlier quoted context omitted.

You may be interested in magithub (it’s on MELPA).

Is there something similar for Bitbucket and JIRA? We're stuck with those and the web UI's are very slow.

I wrote my own CLI (in C, just for the hell of it) for JIRA. It’s the server that’s the problem. Responses take seconds to return over my 100Mb/S connection. Horrible.

Re: Putting the I back in IDE

#132
post #116
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.

Efficiency is on the eyes of beholder.

For me, efficiency is a synonym of Xerox PARC’s vision of computing, not improved teletypes.

Re: Putting the I back in IDE

#133
post #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...

The trouble with 'just switching branches' is that it quickly gets very complicated, if not impossible, without either checking in incomplete code or stashing it.

Is stashing an issue?

Re: Putting the I back in IDE

#134
post #95

Earlier quoted context omitted.

> we developers are stuck No, only a subset is "stuck" not using the most fancy and shiniest. Janestreet seems to be interested in this particular subset. Maybe they found a correlation between robustness and efficiency, and not fooling around with tooling for the sake of optics too much. After all, finding correlations is what they do. If you want to argue "behind times," argue inefficiency, but I think you will com…

> they also get to weed out developers whose opinions would make for a poor fit Wow, that's aggressive. Such a policy would "weed out" people like Alan Kay or Bret Victor over a trivial difference in opinion about UI efficiency. Are you sure creating a monoculture of thought around this single issue makes sense for a company?

For Janestreet? Definitely.

If you do Ocaml, you do emacs, if you do emacs, you do GNU (or some other sane unix). Anything else means you're stealing your own or company time.

> a trivial difference in opinion about UI efficiency.

That's one way to look at it. Another is that the quest for UI efficiency is a timesink and an upgrade threadmill susceptible to fashions. The counter to that is to learn it once, learn it well, and be done with it for the rest of your career. Emacs fits that profile just about perfectly.

Re: Putting the I back in IDE

#135
post #131
post #84

Earlier quoted context omitted.

Is there something similar for Bitbucket and JIRA? We're stuck with those and the web UI's are very slow.

I wrote my own CLI (in C, just for the hell of it) for JIRA. It’s the server that’s the problem. Responses take seconds to return over my 100Mb/S connection. Horrible.

What are the good alternatives for JIRA then? Would be nice to command all of that from Emacs...

Re: Putting the I back in IDE

#136
post #129

Earlier quoted context omitted.

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.

If he has Windows 10 he could even go WSL, forgot about it.

Could, but, IMO, if you don't need to run arbitrary linux apps then gitbash is the better option. It's more performant for file operations, and you don't have to deal with gotchas like, "Don't edit files that don't belong to WSL from WSL, only read them."

Re: Putting the I back in IDE

#137
Magit combined with Magithub already offers much of what's described in the article and there's a lot on the roadmap. Jonas and Sean are doing mindblowing, amazing work in these projects. I've seen many different UI shells for Git - everything else feels childish compared to what's possible in Emacs. I learned Git mostly by trial, error and reading man pages, but only after a few months of using Magit I've become truly dangerous.

Re: Putting the I back in IDE

#138
post #95

Earlier quoted context omitted.

> they also get to weed out developers whose opinions would make for a poor fit Wow, that's aggressive. Such a policy would "weed out" people like Alan Kay or Bret Victor over a trivial difference in opinion about UI efficiency. Are you sure creating a monoculture of thought around this single issue makes sense for a company?

For Janestreet? Definitely. If you do Ocaml, you do emacs, if you do emacs, you do GNU (or some other sane unix). Anything else means you're stealing your own or company time. > a trivial difference in opinion about UI efficiency. That's one way to look at it. Another is that the quest for UI efficiency is a timesink and an upgrade threadmill susceptible to fashions. The counter to that is to learn it once, learn it…

Like I said: an unfortunate local maximum that works but hinders progress.

Re: Putting the I back in IDE

#139
post #87

Earlier quoted context omitted.

True, my comment was a bit mean/dismissive. People do have to stop chasing the trends, cause that's a full time job. And it's easy to not notice productivity gains you've missed for years. In my opinion Emacs/Vim: - except for some specific roles: Emacs -> Lisp development, Vim -> to be honest, not sure what to say, what is Vim's strong suit? except for core editing commands - and unless you put in a ton of hours int…

To keep it brief (mobile keyboards suck): Vim’s strong suit is editing text. That’s all. But, and it’s a big but, that’s enough. As a vim user, I have the rest of the shell and browsers for the rest of my development environment. Version control: git. Building and testing tools: make (or similar). Debugging: gdb, pdb, the browsers debugger. Lots of single purpose tools that operate cleanly and so integrate into my pe…

vi is unixy, in the sense of UNIX is supposed to be the "interpreter" or the IDE as some books said. vi let's you type a few keys and delegate to whoever is most capable of dealing with it. I'd love it if I was stronger with C and interprocess comms. My mind naturally wants everything into one core which is very lispy, so emacs suited me best at first.

Re: Putting the I back in IDE

#140
post #135
post #131

Earlier quoted context omitted.

I wrote my own CLI (in C, just for the hell of it) for JIRA. It’s the server that’s the problem. Responses take seconds to return over my 100Mb/S connection. Horrible.

What are the good alternatives for JIRA then? Would be nice to command all of that from Emacs...

I remember seeing one, though it may not have been under active development. Maybe search MELPA/Github.

If there’s nothing suitable it could be a fun thing to hack on! :)

Post reply on HN