Live data from Hacker News

Putting the I back in IDE

blog.janestreet.com

81–90 of 152 posts

Re: Putting the I back in IDE

#81
post #72

Earlier quoted context omitted.

Visual Studio without git .. is barely usable. The whole team system integration is a UI disaster, busy, slow and takes gazillion clicks to get anywhere. I like VS as an IDE. The TFS integration is a nightmare in my opinion.

Nearly everyone is getting off tfs, and using GIT. So its a non issue.

Doesn't tfs support git out of the box these days?

Re: Putting the I back in IDE

#82
> Code review happens entirely within the editor. You’re fed a series of diffs: one keystroke to approve, one keystroke to start editing. Dive in, make your changes, leave comments for the author, push, and move on.

But can the reviewer easily run the code they have just edited?

And does changing branches require a full rebuild?

Re: Putting the I back in IDE

#83
post #38

If you walked into an office and saw them using 1984 equipment — fax machines, landlines and Rolodexes — you'd think the company is hopelessly behind times. Jane Street is a cutting-edge technology corporation, but their internal tools use 80*25 text-mode UIs just like the ones you'd find on a 1984 IBM PC/AT. It's not the company's fault: we developers are stuck in the tar pit of an unfortunate local maximum with all…

> but their internal tools use 80*25 text-mode UIs A long time ago, I worked for a company wanting to sell advertising devices with an accompanying booking UI to Titan - we had a shiny web booking system; they had their crufty old 80x25 text mode system. Turns out that 80x25 text mode system was orders of magnitude faster for the day to day workflow of booking ads on devices, etc.

Indeed.

I've seen two AS/400 via Telnet(-like) systems replaced with a modern GUI (first case) and a web based GUI (second case) and aside from all the usual problems associated with an en masse migration they ended up been far slower for the end user.

TUI's with complete keyboard shortcuts are just hard to beat for domain specific software.

Things like "Click Orders - Click Open - Click Create New Order" vs SHIFT+F9.

The other thing is that once your users have learnt the shortcuts they become internalised and they don't even think about them anymore.

I've seen developers where you'd need crowbars and grease to seperate them from vim advocating for replacing a TUI with a web GUI.

That one did make me giggle from the sheer level of irony.

Re: Putting the I back in IDE

#84
post #6

That's really neat. I love the idea of doing as much as possible from text-based UIs, especially using Emacs. I see this is built on top of Emacs, but it looks like it's entirely custom. It would be interesting to build something like this integrating with standard Emacs features. For example, merge requests could show up in an orgmode agenda list, and reviewing the merge request could be done through a layer on top…

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.

Re: Putting the I back in IDE

#85
post #37

Earlier quoted context omitted.

Those stats are also probably skewed in favor of people actually bothering to fill their survey. Those are more likely to be active/proactive, which in my experience is correlated with tinkering with tools (ergo, using Vim or Emacs).

> Those stats are also probably skewed in favor of people actually bothering to fill their survey. Those are more likely to be active/proactive, which in my experience is correlated with tinkering with tools ( ergo, using Vim or Emacs ). and yet: > Most developers don’t use command line editors . Here’s recent data from this year: https://insights.stackoverflow.com/survey/2018#development-e... . As you see, 4 most po…

My point that those stats are not necessarily representative of the general population in that CLI editors are used by even less people than listed there. In my personal experience maybe 1% of the developers I know use them as their primary editors. They maybe edit some stuff with them on remote Unix systems, if you can call i:wq real editing :)

Re: Putting the I back in IDE

#87
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…

Even without impatience/ignorance/incompetence. It's very hard to follow what everybody's doing. Seriously hard. Everyday people are making stuff, and have been doing so for 50 years. I'm a regular emacs user and I keep being surprised by new modes/extensions that I never heard of, but were released 2 years ago -_-;

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 into Emacs/Vim: a lot more than you need to put into mastering a powerful IDE

don't have as many features or don't reach the level of quality offered by modern, mainstream IDEs, for their respective languages. By this I mean that you need to bundle a ton of plugins into these editors and their plugin ecosystems are not as well integrated and as mature as the finished product provided by these IDE creators.

And for most devs who roll their own on top of Emacs and Vim, the balancing out between editor speed and IDE features is really, really hard. I think maybe 1% of the devs actually doing this are more productive, many of the others are fooling themselves, or as you said, haven't had the time to re-check the alternatives.

That being said, generic programmable editors like Emacs or Vim serve as nice catch-alls for those times when you don't have the proper "high-tech" tool. For example you're using a DSL, a niche language, etc.

Re: Putting the I back in IDE

#88
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 recently switched over to Visual Studio Code and even though I previously had a bit experience with it, switching over was frustrating. It takes time to change your work flow, to set up the IDE as needed, to get plugins and what not fine-tuned. Now I can't imagine working without Visual Studio Code because all those seemingly little features add up and what do you mean I can seamlessly use Git to manage my code or…

> seemingly little features add up

You can say that again. These really polished software products such as Microsoft Office (don't laugh!), IntelliJ, Visual Studio Code, 7-Zip, Chrome, Firefox have tons of hidden features you can easily miss and that have tons of thought put into them.

For example I started using Visual Studio Code and I accidentally clicked things in the status bar. Did you know that the text there is actually buttons? They take you to the command bar, where they have a pre-filtered list of commands which set their respective options (!!!). That's power user UX Nirvana, embedding discoverability and teaching in a subtle way that doesn't interfere with your normal workflow.

You don't know what you're doing? You click the menus and your life is just fine. You read the Welcome page and maybe change some user settings, with full auto completion (!!!), or maybe you click around the app, and like a modern game with a physics engine, the app reacts to your action, doesn't just sit there like a slab of rock.

Re: Putting the I back in IDE

#89
post #82

> Code review happens entirely within the editor. You’re fed a series of diffs: one keystroke to approve, one keystroke to start editing. Dive in, make your changes, leave comments for the author, push, and move on. But can the reviewer easily run the code they have just edited? And does changing branches require a full rebuild?

They also build two build systems in ocaml http://jbuilder.readthedocs.io/en/latest/ and jenga, which support incremental fast compilation, so the answer is most likely yes.

Re: Putting the I back in IDE

#90
post #87

Earlier quoted context omitted.

Even without impatience/ignorance/incompetence. It's very hard to follow what everybody's doing. Seriously hard. Everyday people are making stuff, and have been doing so for 50 years. I'm a regular emacs user and I keep being surprised by new modes/extensions that I never heard of, but were released 2 years ago -_-;

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…

Emacs user here. I have used lot's of IDE's in the past until I decided to take Emacs seriously. The problem with IDE's is that you have to learn one for each language. Working on multi-language projects becomes really annoying. With Emacs I can remain in the same place. If I spend a little bit configuring it I get most of the IDE features. I am always at home. Git is there too. Now I even check my email there, great for emailing about technical stuff. Muscle memory works until it is almost part of yourself.

A couple of things might take a bit more to configure (C++ smartness). But it is a free software program that has been around like 30 years. I am confident it is a tool I can invest in and it won't let me down. I can not say the same about proprietary IDE's and editors.

Post reply on HN