Terminal + Vim or Emacs/VSCode (depending on configuration) is not only all you need, it also produces developers who understand the systems they work with.
I know a lot of people will disagree but my advice to more junior guys is always get rid of the toys and learn the tools.
A good IDE is not a toy, it is a very powerful tool.
How do you work in a large C++ code base using only a text editor? You will certainly need a couple of plugins, e.g. for linting, definitions/implementation look up, auto complete, etc. Then what is the actual difference to an IDE?
As an additional point: I've been working on a "polyglot" project for some years now, most of it is in Python (data-analysis) and C# (Unity), but there is also C/C++ (real-time components) and even some Haskell (some small "scripts") in there.
I do all my programming in vim with basically just syntax highlighting, relying on the web for "definition look up" and typing fast instead of "auto complete".
Code lookup (i.e. "where did that function go") is handled by RipGrep, continuous builds are handled from the command-line (with fsnotify), etc.
=> Definitely just "my 2 cents", but I've been using Vim for so long that every IDE text editing feels very sluggish in comparison.
In the beginning I felt I needed linting, definitions, etc, so I began by stuffing Vim with plugins. Then I discovered that I was much more productive when I didn't use any of that, but actually kept the documentation close by.
Now I just remember most of the definitions or quickly look them up and combine the usage of console applications like grep, find, sed, etc. with Vim. I have about 3 custom made Vim functions that serve as shortcuts for at few of the things I need often.
Personally it's the most productive for me and the tool gets out of the way.
Even just adding NERDTree or ctags to vim dramatically improves productivity. Repeat ad nauseam and you have the modern IDE.
The advice “get rid of the toys and learn the tools” doesn’t do much other than reveal your (subjective) bias for “toys” vs “tools”.
The problem is when a developer can't make that jump when necessary. A big part of our ability to build systems for computers relies on our ability to traverse those computers at a low level, and that means command line instructions. It means being able to work with the filesystem, and streams of input/output. I don't use Vim because I think it's a superior text editor, I use it because of the fluidity it offers me in terms of getting streams of text from the console in and out of an editor. I can just pipe things to it, or execute arbitrary commands and capture the output, and so on.
Now, granted, seasoned developers can often get that same degree of command-line fluidity while still working in an IDE. But I think that requires them knowing the importance of that fluidity in the first place, which is something that you aren't necessarily going to learn as long as the IDE is holding your hand and doing a lot of it for you.
I couldn’t agree with you more. I feel like at some point in a career, a developer should try to shove off from an IDE if that is their daily driver.
I also feel this way about high level languages.
Speaking personally, I have ALWAYS benefited by doing those uncomfortable deep dives.
Vim is a great text editor, and that is exactly what I want it to do. The IdeaVim plugin gets the job done for me.
I would never go back to VIM for coding.
I don't feel I'm learning anything useful by wrestling with the fiddly JSON build configurations in VS Code.
There will be another new and _modern_ IDE tomorrow. Why invest and learn something that keeps changing? It’s like spending most of your time learning React or Angular, while you could have spent the same time learning JavaScript itself. I am not saying tools are not useful. IDEs, high level frameworks absolutely boost productivity. If your goal is to get something done fast, sure use these tools. But if you want to make long term investments, you should learn the fundamentals and later potentially use these frameworks (when you understand how they work) to further boost your productivity.
But people often get used to the tools they use, so people with a learning mindset, who start with the fundamental tools tend to stick with them. That’s why I think a correlation exists between engineers who have a good deep understanding of how a system works and engineers who use basic tools.
Maybe that needs to be controlled for, too.
I learned to code like you suggest. I started with C, in vi, I learned it from the words of Kernighan and Ritchie and I had no forums or syntax highlighting or anything to hold my hands, and when stuff didn't work, I got compiler error messages so obtuse they might as well have been in Linear B, I walked uphill both ways and it was -40 and blizzard even in the summer. I do absolutely concede the type of language-understanding and skill set this promotes does make you a better developer.
However.
I do not think that stubbornly refusing to use an IDE makes you a better developer. A good IDE is powerful, and can be a real force multiplier that makes you able to work with much larger systems and significantly cuts down on the amount of time you spend doing menial repetitive typing.
You can absolutely subsist on the simplest of tools, but you can absolutely do more with the more powerful ones.
Do people think it is still the case for large code bases and Java? I find the ability to quickly jump to definition in the IDE a huge help when on boarding into a new codebase.
Visual Studio Code's Java support is not great and I do not have jump to definition. Find " name_of_function(" in files is good enough and catches a few useful cases outside Java's understanding, particularly when you have naming consistency throughout a codebase.
Code's not as good as Emacs, but it's reliability installed on nearly every developer's machine regardless of discipline or at least the subset who are willing to ask for help when they encounter problems.
It’s certainly possible to code without support, but if you value your productivity, why spend five minutes doing a manual renaming when your ide can do it in a few seconds? Why wouldn’t I want my ide to indent correctly, according to eslint rules in the given project?
Sure for none coding task emacs is great, and git is more powerful on the command line. I therefore use the most powerful tool I can.
Edit: this comment became overly critical, it is quite possible that it is a coincidence, my N is quite low.
Vi is not just an text editor in the terminal. It's a different way to interact with text. To say that Vi users are close minded is like saying people who use the terminal are closed minded.
GUIs and the mouse have significantly improved the way we interact with computers. However, many things are still better in the terminal with a keyboard.
In that same vein, IDEs have improved the way we write code but it has not improved on the way we interact with text enough. For those of us who love Vi as an expressive language to interact with text, we choose to forgo the benefits that IDEs give us when writing code.
Personally, when I write code, I love the experience of tmux with neovim. It's something I try to replicate in the gui every couple of years in MacOS but it always so bad.
On the point of manual renaming, Vim is perfectly capable of project based search and replace.
That's a LSP feature, you do not need an IDE.
Somehow my 35 years of coding experience have shown me that I rather play with those toys than be frozen in past I grew up on (ZX, MS-DOS, UNIX and CP/M).
If all you have is a basic text editor, you are limited by what can fit inside your head. If your IDE makes navigation too easy, you end up writing callbacks that call callbacks that call callbacks until you end up in abstraction hell and have no idea what your code is doing anymore.
Then again, better tooling makes refactoring/simplifying code easier so it may just as well lead to easier to understand code...
To me it’s a red flag when developer uses notepad++ instead of jetbrains.
Also, self-hosted or not, if the system is web-based, that's a dealbreaker.
But if you're just starting out, with a small and quite possibly partly outsourced team, this could be a cheaper and faster way to spin things up. Just like many companies don't have their own datacenter anymore, and even fewer have them literally onsite in a server closet.
I too would rather do this. Trusting Amazon with my personal development setup doesn't sound like a good idea; they have the power to shut that down completely at the click of a button.
Not that client is your browser, but locally installed VSCode.
I hate fighting IDEs (whether it's IntelliJ or VSCode) before I can write useful code. Javascript has gotten so bloated that half the challenge of any new project is setting up tooling. God, I'd love a 1-click "create new project" and then a GDocs-like IDE in the cloud, and would happily pay to never have to configure that again myself.
However, it is a catch-22. As more things want to become frameworks and wrap the entire process (for ease of use), there’s more monolithic stacks created, and it ends up with making it even more inaccessible without 1-click/command solutions.
Not sure why this needs to be something developers can’t fine tune for themself.
And are you aware of platforms like Cloud9 that have been available for 10 years that give you an online developer environment?
Honestly the only two reasons I personally don’t use them is because (1) I’ve never been at any company or place in the world where the Internet was truly 100% available with dependably low latency and near zero jitter and (2) nothing beats IntelliJ for me.
Not saying I prefer remote IDEs, just that they are more a symptom here and not the root cause.
You can just take a look at the pull requests and commits.
Actually, if you decide to use your own computer for work then remote IDE is probably better solution in terms of security and privacy of your own computer. You don’t have to worry that something nasty will be installed (be it malicious NPM package or spyware from employer).
Fully agree, this direction sounds like nightmare fuel to me.
IME employers can actually sense this when it happens and a lot of the ridiculous bullshit you would otherwise have to put up with melts away.
You ain't ever being a partner working on the checkout tills at walmart ;-)
Trusting any given company is akin to trusting a snake not to bite you if your hand smells like a mouse. You might like to think there is some affection there, but you're simply anthropomorphizing something which is incapable of more than its nature.
One reason is that IDEs' vim-plugins never work quite well. Another one is speed and resource usage. Resource-usage may be solved with thin clients, but not speed. Also I don't want to give up control to some platform.
Less is more. Tools should do one thing and do it well. I don't want to install a huge package and dependencies just to get one feature. Generally feel pessimistic about the "future" of IDEs. The phrase brings bloat to mind.
If I need the feature, let me add it to emacs. In most cases someone else has already provided a config.
That sounds like a good approach when you need 5 features. But for development the number is probably in the hundreds and I have no time to try to manage all that.
Besides many features are simply not available for editors like emacs. As an example, data flow analysis warns you about logical mistakes in your code (e.g. dereferencing nullable variable without a check first). This happens as you type, the closest you can get without an IDE is probably running it on some static analysis tool in your CI => getting feedback an hour later.
For example, when I was learning Clojure I used Doom Emacs for a few months, but gave up because:
- Emacs is slow. There's no way around that. It's even slower than VSCode or other IDE-ish editors. If you're used to Vim speeds, that's pretty annoying.
- The Vim keybindings are not available everywhere, for example in some plugins you would fall back to pinky-breaker, wrist punishing Emacs standard keybindings.
- There's some uncanny valley where keybindings are mostly like Vim but you have constantly paper cuts from small differences here and there, among the occasional Emacs-mode fallback.
Don't take me wrong, I can see how Emacs is a great editor, but for me, it's way too late it seems. Seems like I'm going to keep on vimming until the end.
Org-capture, tramp mode, ansi-term. Tight integration with any workflow. Flycheck, flyspell, it’s all so good.
Much love for emacs. I would refuse to work where I can’t use it. Steep learning curve, but the view is beautiful after the climb.
I have a love hate relationship with vim. It's super fast and efficient to edit huge quantities of text, but as a tool to really understand a code base? IDEs reign supreme. This is coming from someone who steadfastly refused to use an ide until his last year of college, and then switched, being able to see call hierarchies, having smart completion, etc made my life much easier. I still fall back to the term and vim if I need something quick and dirty.
https://marketplace.visualstudio.com/items?itemName=asvetlia...
- Bake the distributed nature of the software process into the IDE. What environments and servers is the developed software running on? That information is currently spread out over multiple tools and should be synthesized and presented coherently from the IDE, so one could dive straight from it's IDE into a problematic server and start debugging using the appropriate code without having to spend 2 hours reproducing the build configuration locally.
- Finally, _Team Workflow_ is especially taken for granted, ground rules being implicit in most organisation but having the most actual impact on team productivity. How long should a PR take? How is the software qualified for release? How should new git branches be named? Important, basic stuff that changes across teams and projects that should be formally documented to lower friction for newcomers and small-time contributors. This would turn perceived arbitrary "gatekeeping" into a rational, safe processes.
addendum: the "team rules" being kind of novel, these should be encoded in a human-readable file, actionable from the CLI as well as the IDE. I've been pondering for a while how such a workflow tool could be like.
I always found that "assign" to person of gitlab to be clunky and the use of CI/CD Piplines to map the concept even clunkier.
If every pipeline station becomes something abstract, and the people just check in with their station, in the IDE, with the IDE even pre-configured to the current Station (basically pipeline-modal) that would be real neat.
Some of us already have that, as IDE Presets, switching manually, but having that baked in, would be a benefit.
For example, I want a workflow where I can click on a failing test from the CI and have it pull up the source code of the test in the IDE and run said test locally with a debugger.
Our company Coherence(withcoherence.com) is pre-launch but is working on these exact problems if anyone is interested in helping to solve them!
(I never worked directly for Sun, though I did have a hell of a lot of dealings with both the Church and State sides of their business.)
Employers that standardize on a single IDE (e.g., enterprise Java shops and eclipse - blech) are always terrible places to work.
VP: What editor is that?
Me: That's Emacs.
VP: Oh. Let's get you an IDE!
Me: I have an IDE: Emacs.
VP: I think you'd be more efficient with an IDE.
Me: This is an IDE, and anyway, I've been using this for decades.
VP: I think we can all be more efficient if we're using consistent tooling.
Me: Are you happy with my work? Have I met my deadlines?
VP: Yes...
Me: Then don't fix it. I'm sticking with this.
I was senior enough to get away with that. If I weren't, I'm sure I would've been stuck with whatever Eclipse-style thing he liked that year. Oh, this was the same VPEng that asked me when we should "upgrade from Python to Java". I don't think he loved me answer of "downgrade to Java? Never."
I'm curious why you went with spacemacs.
We're moving towards a world where ML can generate code that compiles from a single comment.
We have games like Battlefield now providing no-code options to FPS gamers.
There are literal super computers that can spin-up environments in seconds, run a test suite and report back, all to give a little tick on a PR.
Yet the IDE still just gives a messy error message if you forget a semi-colon or quote in the wrong place.
Can you elaborate on that or drop some keywords that will help with a web search?
But tbh, I've never found those tools to be useful. In my experience, Pair Programming is not only about code but also about processes (git, pull requests, the CI, IDE features, company internal tools ...). It's also inefficient if the involved team mates have different IDEs or habits ...
As of today, I've found nothing better than screen sharing. And screen sharing could totally be improved because, afaik, you have to choose between correct interaction (ability seamlessly to take control of the distant screen) or correct image quality (Zoom is pretty impressive).
Also, I'm open if you know collaboration tools with good screen sharing quality AND intuitive collaboration tools / distant control.
I'm not completely sure if UX would work out. There would be less visual noise, so reading would be easier. Writing is harder to solve as IDE would need to be smart and convert indentations to pairs of braces underneath in appropriate contexts.
This feature would of course need to be togglable on/off.
You still have one character to start (tab?) and end (backspace?) a block, but now they are overloaded with the edition keys, and still need to keep track of the block with the same visual aid (indentation).
The small changes I see are to the worse, that is overloading the keys and not letting you see the text verbatim.
Sure, a good IDE will automatically create indentation when you type '{', so you need to only type a single character to start the block. We could actually say '{' is a shortcut key to start a block. IDE creates an indentation and draws a vertical line to enhance visual presentation of the block. Visually, braces are more or less just a noise, so removing them would improve "signal to noise ratio" and enhance reading experience.
However, logically braces are better at defining blocks of code than tabs. With braces we have start '{' and end '}' characters, but with tabs each line needs to be indented by a correct number of chars (tabs/spaces).
I am wondering, if we can have best of both worlds.
In some cases we are trying to draw visual indications with text. Wouldn't be better, if we let the IDE do the drawing? Eg.: two vs four spaces of indentation? It doesn't matter, if you can configure visual indentation depth on the fly in the IDE.
I'm no big Atlassian fan to put it mildly, but this is actually more brilliant than it sounds:
Reviewing a pull request from the comfort of your IDE/editor, complete with ctrl-click navigation working, that is sometimes a game changer.
We now have languages which can't really be used without an IDE, like C# or Java. That in turn result in programmers who can't actually program very well. I started seeing it way back in 2007, where some coworkers basically just used tab-completion in Visual Studio until types matched what a method required, rather than sitting down and doing actual design.
The latter:
* eliminate dependence on the cloud - the entire idea of "everything through port 80" was 100% wrong in the 1990s and it's even MORE WRONG today. Centralization is never the answer except as an instance within some cycling change. Distributed tools are still the better answer under all reasonable circumstances!
* focus on implementation of both parsers and IDEs. New languages will always be created and anything that makes both parser AND IDE creation easier and more "automatic" is a good thing.
Most everything else good can come from these to start with.
The cloud inherently attempts to decentralize computation (duh). If you can have multiple servers across a country, chances are, one freak accident (weather, power-grid failures, etc) is less likely to bring down your ecosystem. If it's well architected, your users may not even notice. In that sense, it can be fantastic for reliability and scalability since a lot of these cloud server companies allow for easily creating new instances of the same project.
If your software is written poorly or your environment is poorly architected, then you can encounter issues using the cloud like centralization as you mentioned, and you'll also have to manage difficult or arcane deployments. You also run into a problem of dependence on your cloud platform of choice. No one likes vendor lock; it hurts flexibility and increases costs in the long run. If your project is AWS based for instance and has a dependence on Lambdas, for instance, what are you going to do if Amazon suddenly raises their costs beyond what your company can reasonably accommodate? There are some workarounds, but they obviously aren't as nice or immediately available.
But also, what are your alternatives to using a cloud provider? Your company could create physical infrastructure in safe places, but all the prime spots would be taken up extremely quickly not to mention that it's waaay more costly to build a mainframe on or offsite than it is to spin up an EC2 instance or ten. And if your system isn't on-prem or thereabouts, then it seems like cloud is the only real solution there.
Agree 100% with the IDE stuff though
And do everything else in a tiled terminal window, I have always open anyway.
This setup honestly sounds envigorating; I'm currently in a predicament where my course requires the use of Windows-only software, so I've got a dual-boot on the laptop. Whenever I forget to shut down Windows properly and boot into Linux, I find out the NTFS drive is read-only to prevent corruption. This means booting back into Windows, finishing up any work I might have on there, restarting to Linux, and getting personal development work done.
The author hasn't specifically mentioned any Windows-specific setups here, but I'm sure it's possible with QEMU, a VPN, and some other tricks.
AKA, a screw -- so in the long run, we're all screwed.
The year is 2030. You're a software engineer at a company, writing tests for your program. After you write a few tests, your IDE is like, "hey, I noticed you were testing this; do you want this more general thing to hold?" and spits back a specification for you. You're not sure. You say, "give me some examples," and your IDE generates more tests for you. One of them looks off, so you tell your IDE, "no, not that one." Your IDE sends you another specification. This one looks better, so you approve it. Your IDE tells you to hang out for a bit while it tries to see if it actually holds. After ten seconds or so, it generates a failing test. You fix your code and try again. This time it's like, "I couldn't find any counterexamples, but I'm also not positive it's true. Can you help me prove it?" You say yes, of course. It asks you a couple of specific questions about your code. Thinks for a bit, and then tells you that your code is verified. In fact if you are an advanced user you can go check out the proof yourself. No need to, though. A couple of days later, you change your code. Your IDE notices this and tries to check the specification again. It tells you that it is no longer true; but based on the change you made, there is an analogous change in the specification, so maybe you want this new specification? You're not sure so you ask for some tests. It looks good. And this time the tool doesn't need to ask you any questions to prove it; the proof is similar enough to the proof of the old specification, so you're good. After a few more weeks of this, your IDE notices something else, though. You keep changing that function, and changing your specification to go with it. So it recommends a new abstraction for you that would have captured all of the past examples. It tells you, hey, if you use this, things might break less often to begin with . It looks good so you're like, "oh cool, yeah let's do that." And it drops into a guided refactoring mode, helping you through the change, asking you just a few questions but automating all of the tedium. Does this for your program, then for your proof. And your proof doesn't break again for months after that. Good shit.
It's the build systems that give me confidence that my IDE choice isn't some permanent lock-in. I almost always add .gitignore rules to never check in preferences from anything made by JetBrains, and you know what? It always seems to work fine. For example, my Java project structures are defined by Maven and Gradle, not IntelliJ. IntelliJ uses those conventions.
For this to _really_ take off, I sense we just need to be able to bounce offline or online if we want to. And the way that's going to happen is just via the build system defining the structure and workflow.
This could happen, but it requires a lot of build work that I don't see happening right now. At least, not in the open
I think remote IDEs make sense if you’re a massive company with an insane number of microservices that need to run for testing, but 99% of devs would be better off with local dev.
I was honestly pretty happy with where I landed on it even in the context of a fairly complicated setup running a Flutter web app, a backend and an envoy sidecar proxy.
I was also able to set up a consistent IDE experience by specifying the various plugins I wanted to use along with other tooling I needed like gcloud SDK etc…
But just last week I did a remote pairing session with someone on a full stack web application entirely within a remote codespaces environment with zero other tooling (even the pairing was taken care of thanks to VSCode live share plugins). I thought that was a pretty cool experience overall. The thing I love most though is that I’m not specifically tied to a remote development environment I can get the exact same experience by just running the devcontainer locally on my machine.
1. Back to easy indirection resolution (https://youtu.be/baxtyeFVn3w?t=1786, re: gtoolkit)
2. Comments that are not inline, but can point to various blocks/parts of code and overlap (multiple comments can apply to single parts of code).
3. More support for unit testing. function call tracking (https://stackoverflow.com/questions/51901676/get-the-lists-o...).
4. Conducting behavioral studies via opt-in submission of eye tracking data. A great deal of data is flowing through IDEs and not being leveraged to improve the daily tools of developers.
I was so positively shocked by its suggestions that I kept positing videos of it in action with the team.
It adapts to the structure and peculiarities of a specific project and you only really understand it once you are in a flow; you almost forget about it until one time you press return to write a new line of code and it correctly writes exactly what you wanted.
It's creepy and absolutely incredible at the same time. Almost as if you're pairing with someone that you never speak with.
Here's Co-Pilot finishing a coding kata for me: https://i.imgur.com/ih32sCy.mp4 (trimmed to 60s b/c of imgur limit).
The final step will be take away users' ability to do anything on the machine other than just reach cloud premises of their employers and service providers. This most likely will happen in the name of increased security and convenience.
What? There are chromebooks by many different manufacturers, and they all have a terrible keyboard and screen? As for the shell experience, that's not going to matter if development happens in the browser.
The magic of their experience was created by automatic environment configuration. It's the magic that let them start working without spending a day preparing an environment to start working within.
It's something that VSCode does quite well, not perfectly, but well. It installs a decent environment automatically for most popular languages and toolkits.
Emacs has _finally_ caught on, and lsp-mode will attempt to automatically install language servers for you.
If remote coding was the norm it would be an open door for corporate surveillance on a massive scale.
I don't feel good about this idea, I think we should resist and fight back, this is not only a technical discussion.
On the other hand, the thin client idea is cyclical but is usually short-lived and is often the wrong solution to a real problem (bloatware).
Most recently I've been really impressed with the Remix IDE for Ethereum smart contracts. https://remix-project.org/
When working in cloud IDEs, I just need the safety net of backup/versioning via git commits.
[0]: https://github.com/cdr/code-server [1]: coder.com
If not, terrible awful idea that will enslave us all.
Joking, but also not.
This sounds like a problem with one device, not the whole concept. I have used devices with great keyboards and screens. You just have to pay more.
> terrible shell experience
In what way?
