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 these tools built around text streams printed into a window that emulates a late '70s terminal.
> 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.
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.
Nothing to stop you adding the Shift+F9 shortcut to the gui.
Gui's are often preferred for the speed at which new hires can use them. In environments with high turnover this is important. You can have the best of both worlds with a GUI that has good shortcuts and clever cursor placement. I agree though that most gui implementations have not put enough effort into this.
Yep, you want to see ultra effecient computer usage go to Fry's Electronics and watch them wiz around the TUI POS system. Actually that goes for most TUI POS systems like, say, your standard grease smudged terminal at the local UHaul office.
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 come up short on arguments. Not only do they get to have an efficient workflow, they also get to weed out developers whose opinions would make for a poor fit naturally.
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.
On the contrary, I think Jane Street's entire modus operandi is doing things in a novel way, to attract/keep talent (and this is self perpetuating). There are many firms as successful as Jane Street, or more so, that use completely boring, but functional tools: Java, C++, Visual Studio, IntelliJ, and so on. But Jane Street PR is through the roof - everyone knows it, everyone wants to work there, whether any of it is practical or not. It's a counter-example to the mantra of "choose boring tools".
Only those that never took their eyes out of UNIX culture.
Those of us that made a pilgrimage in other more graphics friendly environments, Xerox, ETHZ, Amiga, Atari, ...., have long left the 70's AT&T concept of programing behind.
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.
Similar to the sibling's comment, be sure to look at the freshly released 2018.1 version: they finally included partial commits, and did so in a fantastic way
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 these tools built around text streams printed into a window that emulates a late '70s terminal.