8 ms·
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
by fsloth 9y ago
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.
- oblio 9y agoYou'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 (which is a sort of hidden assumption for many of these attitudes).
- inceptionnames 9y agoI 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 easily rename variables and functions without breaking stuff WHAT
- oblio 9y ago> 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.
- bunderbunder 9y agoI'm a fairly light user of VSCode, so I may be wrong here, but the integration goes even deeper in Visual Studio. It lets you view a pull request's changes right there in a standard IDE window, so that you can get full code navigation features during code review, including stuff like peeking the docstring or implementation of any functions the code references. Or, if you notice something amiss while reviewing your changes before submitting a pull request, you can just make the change, re-run tests, and commit, without ever leaving the diff viewer. Or being able to just toggle gitblame annotations on and off right there in the editor. It's nothing worth switching platforms or programming languages over, but, since switching away from .NET and seeing the gulf between the level of seamlessness you get out of Visual Studio and what's available in other IDEs, I can now see why they've come to have such a poor reputation. Visual Studio isn't exactly lightweight, but it manages to pack in enough cool tricks to justify itself. (Until you install ReSharper. Then it becomes as memory-hungry and unstable as everyone else.)
- agumonkey 9y agoEven 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 -_-;
- oblio 9y agoTrue, 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.
- arximboldi 9y agoEmacs 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.
- wmccullough 9y agoThis is true for me :( I'm a career-long .NET dev and I've wanted to step away and begin learning C++ on a non-Windows platform with VIM and my only attempts were met with so much frustration that I gave up. To be clear, I believe in the power of VIM, I just never got acclimated to it. Maybe this year is the year I stop making excuses and just learn. P.S. I see lots of arguments elsewhere about whether VIM is an IDE. Either way I think your first point stands in my case @oblio.
- oblio 9y agoDo it one step at a time. Use dotnet core on Windows, with Visual Studio. Use dotnet core on Windows, with Visual Studio Code. Use dotnet core on Linux, with Visual Studio Code, etc. Then maybe try dotnet core on Linux, with Vim. But don't believe the hype. I use Vim as an editor because I do a lot of scripting. I use it even on Windows. But I use it because I'm already used to most of its commands, I have a decent config file for it (somewhat lean, not that many plugins) and for my job I need to know it cause I often interact with various systems which use it. Despite being a touch typist and knowing most of the commands, I'm still a Vim heathen. That is, I don't use numbered yank buffers, I just use the default one, I also remapped Ctrl-c, Ctrl-v to do visual block operations for when I'm too lazy to come up with fancy selections, etc. Anyway, my point is, using Vim might not pay off fully. My brain just isn't wired to work in Vim commands. And I know and use w, W, b, B, f, t, folds, blah, blah. I definitely don't use it to "magician" level. You know what? I think in the end it doesn't matter. The only time Vim's nature actually helps is when I pre-process some sort of text data dumps. For the other moments I'm thinking way more than I'm writing or editing. So it's not the text editor that's the blocking point. Damn blocking IO. Getting outputs from the brain is hard and slow!
- wmccullough 9y agoI 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 a Wandows kid by day! EDIT: Seems I can't reply to you anymore. Thanks again for your recommendations. I think a VM is a good route too. I'm not too concerned with purity at this point as much as learning. I can find beauty in most systems regardless of ideology :)
- mannykannot 9y agoI 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's own help system, as it is so rarely productive. Stack Exchange often makes the difference, but unfortunately many of both the questions and their answers are version-specific, but do not state the version they apply to. There is a real art to making an IDE in which how to do all the common things is easy to find, and all the more esoteric features are discoverable. Maybe game designers could help?
- oblio 9y agoI'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.
- bunderbunder 9y agoI 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.)
- cup-of-tea 9y agoSo you got to the third bullet point on the first page, forgot the first two, stopped reading and decided to comment?
- fsloth 9y agoThe charitable way to put that would have been "I don't see how the features you listed are related to to the first two bullet points". I might have misunderstood some technical nuance in the article but I could honestly use the exactly same statements as in the first two bullet points to describe my workflow with VS. This is not with Git though, so that might complexify the process. Maybe someone who is working with Git repos using a Visual Studio integrated tool can comment on this detail.
- loup-vaillant 9y agoVS lets you save a sandbox per branch? May I ask since when? (The most recent version I have used was 2012).
- fsloth 9y agoIn my work I use VS with TFS as the source control. Each branch is in a separate directory, and one can store explicit change sets at any point in time as "shelve sets" without actually committing them into the repository. So there are the two hierarchy levels to experimentation - one can create a new parallel branch on the fly, or do experimentation on top of a branch using shelve sets. That's not explicitly a sandbox, but provides for most cases where one needs to experiment / have distinct development lines / put away random experiments etc. So, uh, depending where you need a sandbox the features may or may not exist.
- sobani 9y agoOn the other hand, in Git there is no difference between a branch, a check-in, a shelve set and a code review (which is also a shelve set). How nice would it be if you could just compile and run the code review yourself, reject it, and then immediately continue with your own work? Or even better, just run both the code review and latest at the same time and see the difference, not just read it.
- pjmlp 9y agoWorse, that interface would be a child's play to implement in Turbo Vision on MS-DOS. Released in 1990.
- loup-vaillant 9y agoLooks 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.
- thedufer 9y agoIt can be done from the command-line (https://www.janestreet.com/tech-talks/code-review/); 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.
- darklajid 9y agoVisual 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.
- always_good 9y agoGood ol smug, dismissive top comment with bonus um-my-favorite-tool-is-the-best-why-would-anything-else-exist.
- fsloth 9y agoI disagree on being dismissive or smug. I did not claim VS was superior - my intent was to point it out as obvious prior art since the article and several comments in this thread gave the impression that an integrated view to development was a 'new' way to look at things or that one required this or that combination of third party tools to manage it. In this context I feel pointing out that VS has this 'single view' methodogy as the default setting was merited. How would have you liked me to expose the prior art on Visual Studio, other than state that it existed, that it was very nice, and that it was a bit strange it was not mentioned in the article?