- CI servers could do much more and their findings should be merged back into the IDE UI: integration tests, CVE analysis, tracking possible merge conflicts from concurrent feature branches
- 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.
I have to say I really disagree with the thought that one should bake a whole bunch of custom functionality into their ide. My company did this. A special, custom version of eclipse was required to even build or deploy their applications. What happened? It was abandoned, and since that build / deploy functionality never existed as independent utilities it was completely lost. I had to piece together how to build my application by pulling build files off of our old ass legacy cicd server and even that process is pretty horribly broken. As things stand, the legacy app I'm tasked with keeping alive is held together with bailing wire and chewing gum and almost all requests for new features are turned down. This is not a unique problem to my team, it's org wide. Tons of legacy apps are limping along because 'the knowledge' of how to do things properly was bundled up into eclipse plugins we no longer have access to.
I totally agree a specific IDE shouldn't be _required_ to operate the software platform. The IDE should ever remain a catalyst, accelerating a process that could be done by hand from the CLI whenever required. The good IDE should know about these different tools and present them in a a coherent manner. The I in IDE should mean more than integrating a compiler and debugger with a text editor.
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 used to do this, on and off, with vim. Hey customize this, and that, and add some special key bindings and plugins. Then you go to ssh somewhere and you're totally lost. Ya, I know there are ways to manage your config for vi but it's not perfect. I find it's sort of like keyboard layouts like Dvorak. Sure it might be more efficient, which is debatable, but there is a huge value in being able to sit down at just about any keyboard and knowing the layout.
That's no different to requiring an arcane incantation of shell scripts that call maven, git, curl, docker, , etc. The advantage of having it built into IDEs or CI servers (and by built in I mean TeamCity/Jenkins providing it, not a self inflicted third party plugin) is that you can build around these steps. Imagine if all CI servers supported merge previews or mergebots - that workflow gets unlocked for everyone!
at least with the shell scripts I can quickly see what it does. I much prefer the unix philosophy of small bits of code that do one thing, and do it well. Such things can be combined to make bigger things. Want to make a plugin out of those individual scripts? Knock yourself out! Meanwhile, a decade from now, some engineer can actually reconstruct if needed. Much better than a 'binary blob' plugin that gets abandoned.
At one point it takes longer to implement a simple feature then it takes to rewrite the whole program, that's when you rewrite the whole program (using a sane amount of dependencies - as few as possible)
Just a addition to the _TeamWorkflow_ it would be great if there was a standardized Way to have a kan-ban pipeline mapped into the IDE. Like Icebox -> First Implementation -> Review -> etc -> Deploy & DevHops
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.
As someone on a team heavily reliant on CI, I think we really need better support for running things locally without CI, though having integration with the server for looking at results is great too.
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.
There’s a lot of interesting thoughts here. Especially in points 2&3, around integration between dev and deployed environments and workflows being integrated into the tooling.
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've worked in 4 different software shops over the last 15 years. My general observation is the developers who rely on heavily automated/magic tooling are significantly outclassed by those who use the terminal + a basic text editor.
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?
Not OP, but I guess his point is that all those things are either accessible from the command line (linting) or available as plugins from vim.
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.
> 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?
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.
> 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.
This sounds strictly worse than what IDEs have to offer (I am thinking specifically about C++).
> Now I just remember most of the definitions or quickly look them up
May I ask with which languages you work and how large the code bases are?
Personally, I work with what I'd call medium-sized C or C++ code bases (100k - 200k LOC) with hundreds of functions/methods. There is no way I can remember their signatures. When I start typing a method, my IDE will immediately show all the possible overloads with their parameters. When I hit F2, it immediately jumps to the definition. I seriously can't imagine how abandoning these features could make me more productive.
I'm always stumped when I hear people saying they are more productive in a text editor, even if they had already tried IDEs. I honestly like to understand how this is possible.
Remembering the core syntax and api's are like magic for productivity, you no longer think in words or variables, you think in data structures and how different endpoints and functions interact, your hands type the code via muscle memory.
Only problem is that the code can sometimes become a bit terse if you do not have an autocomplete, a dumb autocomplete is often enough though.
It depends how you manage scope. When there are thousands of global variables it will be impossible, but if the language (like Dlang) allows local scoping of imports it's manageable... If you are very strict about what is an actual dependency or just a magic global.
The rule is that if the import can be used in other programs/code-bases you can import it. But if it's just a way to get around using global variables you should rethink the architecture.
... Yes IDE's will find the definitions in your spaghetti code-base, but then they become part of a problem loop where the code-base would be unmanageable without the IDE.
Namespaces are also a good solution to use instead of globals or magic globals. But it might become a category theory problem like where in the hierarchical structure you should put something.
The best solution of course is to keep the code base small :)
Hmmm, the whole program still consists of hundreds of functions and I would have to memorize all of them... I don't just work on a single module, I work on the whole code base (open source development).
> The best solution of course is to keep the code base small :)
Hehe, that's the trick. Unfortunately, I came late to the party.
Well. Typically I review the code and say “what kind of twisted sadistic prick wrote this” and then realize that it was me 5 months ago. It’s amazing the level a detail a person can drill into when it’s the locus of focus, and amazing how quickly context is forgotten.
Stream of consciousness audio notes would arguably be more useful in such settings than code completion, as the muscle memory is still there, it’s merely the “why” that disappears
I especially love (!) the Java projects that run only if you have eclipse with specific plugins. "I don't know how to make it work with IntelliJ" is one comments I often hear from some Java devs. I personally would be too embarrassed to say something like that. I guess the same applies to some VS projects, msbuild was dragon territory when we had to deal with it (so, before dotnet cli came).
I strongly disagree. It’s true that people who do not understand how to use something basic to accomplish their goals are far behind in terms of fundamentals compared to those who do, but it’s provably false that primitive tooling is superior to modern IDEs.
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”.
For me, it comes down to one's affinity with the command line. I've known developers who use an IDE but who are still very fluent in the command line, and in fact could probably do just fine if you took the IDE away and made them work in Vim for a while instead.
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.
Agree 100%. Moving off an IDE fixed my impostor syndrome and instantly made all my code more readable and maintainable. Even my manager has commented on how much profit our team is generating ever since we moved to text editors.
I used to do my share of vim in the past, but I really don't have time for this shit anymore. I just want something that works out of the box across languages, without having to tinker around.
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.
Managing a large project with basic tools is a nightmare, it also sucks for learning an API. I've tried to use VS Code for C++ and C# stuff, but it's such a poor tool compared to Visual Studio proper.
I don't feel I'm learning anything useful by wrestling with the fiddly JSON build configurations in VS Code.
This. Let me state my assumption and philosophy first. I believe strongly in learning and investing in the fundamentals — things that stay more or less the same for a long time.
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.
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.
I would tend to agree for most languages I have touched (Python, C, ...) but I have mostly worked in medium codebases.
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.
I work "unofficially" on Java code because the Swift code I'm officially responsible for executes Java code (via HTTP request). I'm "not licensed" to use real Java IDEs.
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.
My experience is that those who still use Vi/Emacs to code are close minded and unwilling to change.
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.
"that those who still use Vi/Emacs to code are close minded and unwilling to change."
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.
>On the point of manual renaming, Vim is perfectly capable of project based search and replace.
I think that is my point, stated better than I could, code is not just text.
I have no issue whatever accepting that Emacs/Vim is much much better at dealing with text - I use Emacs for text in preference to just about everything else.
My preference is IntelliJ, but essentially all the IDEs treat the code as a representation of the abstract syntax tree it is. Put your cursor over an identifier and IntelliJ will highlight all the other instances of that identifier. It will not highlight the same word when used in a comment, because it is not the same.
When you treat code like text, you are limited to search and replace. When you treat it as an AST, your editor can rename your private backing field without renaming your property, because it knows they are two different things. In Java it can push methods up and create a new parent class, all while updating all the code that uses it and give you the confidence that it does so without screwing up your code base.
VIM people are very bad at explaining this. Basically, VIM allows you to compose commands together, so that learning one command means that you can compose it with another to do things very quickly.
The best example is this, imo. you have a function call that is: `combineFirstAndLastName("John", "Smith")`
If your cursor is in the `"John"` part, and you want to change that, you can just input `ci"`, (c)hange (i)nside ("), to instantly start typing with John being removed. Lets say you want to change all the text inside the parenthesis, you just type ci), (c)hange (i)nside `)`.
There's commands like this all over, and you can compose all of them. For example, `ct"`, (c)hange un(t)ill ("), which will erase any text until the next available `"` on the line.
Or, (d)elete un(t)ill `char`. It's a whole language when you're editing with VIM, and while it might sound like that's very hard to learn, it's not. Because you can slowly add these verbs and sentences into your habits until it's completely natural
You start in a file where you aren't even editing yet. From there, to start almost every type of navigation, highlight, or edit action will often be a few character combinations. Go to the end of a file and adding text to the end of the line would be "GA", for example. Most actions don't require adjustment of your hand placement (and its even better if you remap capslock to escape) or use of a mouse. Whatever action you take can be repeated with a simple period (big time saver if you need to repeat an action mutliple times).
More powerful commands like find and replace are available with the command mode. It works perfectly well over a remote session, also
Once you learn the keys that correspond to your desired actions, everything else feels wasteful (Especially as I'm writing this on my phone). I turn on vim keys for anything that has it. It takes a long time to build up your vim vocab (I recommend you learn the simple stuff and incrementally look up better ways to approach things as you go). A great way to get started is vimtutor, which is built in when you install vim; just run vimtutor from shell and start reading. There's a lot more depth to what is possible, buffers, plugins, etc. but that's what stands out to me.
Vim has a concept of an object and actions/motions that can be applied to the object. You can think of it as nouns and verbs. Vim objects can be letter, words, sentences or paragraphs. Say you have the following sentence:
"How much wood would a woodchuck chuck?"
If you cursor is on the letter "H", you can type the "dw" to delete the word "How".
You can use "dt" to delete up to a letter. If your cursor is at the letter "H", "dtw" deletes up the letter "w" which will delete "How much ".
This barely scratches the surface. There is a steep learning curve involved but it's totally worth it if you need to edit text on a regular basis.
At the risk of being pedantic; it's just a feature, it does not have anything to do with LSP. Plenty of non-LSP IDE's have these features as well (XCode, Visual Studio Classic, etc).
Using toys since Turbo Basic 1.0 and Turbo Pascal 3.0.
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).
I've seen this be sorta true over the last 25 years at numerous places but only in limited environments where 99% of the code written was scripting based web languages. I most often work in Python now professionally (mostly security), at home it's C++ and Swift (gamedev). In Python/Js web work that holds some truth, in Security a little more, but in data science/engineering A LOT less where Jupyter and PyCharm are huge. My outside work is 100% in IDE's, XCode - CLion - PyCharm - Intellij, and in game dev or mobile native app dev? The vast majority of great developers are on IDE's. So to me drawing that conclusion is very risky in general and often bad advice to give to Jr's IMO unless they have a very narrow focus on the Web.
I might have agreed with you, until I saw an experienced Java/Kotkin guy work with IJ and a large code base. He was narrating his thought process and coding at the speed of though / speech. It was a thing of beauty that no text editor can help you achieve.
Sometimes I worry that powerful IDEs just make people write more complicated code.
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...
Yes, this. I wouldn't ever dare to put my development in the hands of some third party service. It's just far too risky. But self-hosting such a system is something that I'd at least consider.
Also, self-hosted or not, if the system is web-based, that's a dealbreaker.
In the beginning, you can. Then as code size, build times, testing requirements increase, they will upgrade the server. After a couple of years it will be impossible to run the server on your laptop.
These types of services are mostly not aimed at established tech shops. Similar to Wix or Squarespace or Appian, if you already have an in house tech team, you don't need this, probably.
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'm sure you could set up a VPN on your home WiFi, forward its ports, and login from an external WiFi, assuming the relevant ports aren't blocked on the external network you're on (in that case, I hear stunnel works wonders).
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.
It definitely counts for me! I set up something similar a couple of years back when I wanted to do GPU-accelerated programming from my couch on my anaemic Chromebook (while connected to a 1st get Threadripper in my office). Initially I was using Jupyter, then realized I could work on my other projects using VS Code remotes (Virtualized Linux on Chromebook is great!).Immediately after, I realized I could VPN from the coffee shop or meetups, instead of doing the git push/git pull dance on the heavier Macbook
Funny, it's the opposite for me: Would someone please host the serverside so I don't have to? I'd love to pay for an IDE-as-a-service that updates itself, syncs itself everywhere, has all the right extensions, auto-configures Docker and data stores and secrets and Git and linting and Webpack interation and and and... etc. Something like Vercel but for the IDE.
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.
I think that the 1-click (or 1 command) create-react-app style of development is part of the reason that JS has become so bloated. It encourages thinking in terms of framework and bundling of tons of dependencies as well as closely tying software with any underlying bundle/development/analysis process. The problem with this is that it doesn’t compose well…
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.
It's really unfortunate that JS won out in the web wars, another instance of the lowest common denominator winning out against technically superior options. If Microsoft hadn't been so evil, .NET is really a much better framework... but it didn't get enough traction.
By contrast, PHP has actually evolved quite gracefully over the last decade, incorporating more and more desired features into the baseline language. Sadly it has no browser clientside option.
Javascript is a victim of its own rapid success :(
I think there's many advantages to it. Whole one company might be stuck in slower webpack/Babel hell, nextjs, remix, those that don't let the developer muck with the toolchain have been able to switch out for much faster & smaller bundlers. CRA is in a decent position to do similar.
Because laziness, frankly. I'm just too jaded to care about optimizing the toolchain anymore, when more often than not it results in 30% more performance, one cool new feature, and ten new bugs.
If you enjoy that sort of tinkering, more power to you... you're probably a better dev & devops person than I am.
Doesn’t IntelliJ sync most of that? I use IntelliJ on 3 computers and all my extensions and even themes are synced.
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.
I've used IntelliJ for a decade (including several hours today) and it's never very seamless. The sync features are hit or miss, especially across platforms -- I've used it on various Windowses, Linuxes, and macOS. The hotkeys aren't the same, the interpreters aren't the same, the containers (Docker or Python) don't function the same, the linters don't present the same, the NPM modules don't always compile on different architectures (sigh, M1), the memory settings don't always persist, some are synced to Jetbrains and others are stored per-repo... it's a nightmare to untangle. The syncing is there, sort of, but it's far from seamless. There is still a lot of complexity and points of failure between the bare metal and my code (whether it's PHP or Python or Javascript). And if you can't afford IntelliJ ultimate and use separate products (like PyCharm and PHPStorm), the integrations are even worse, along with trying to figure out which product offers which feature (like Javascript support, or SQL).
What I'm hoping for is an easily reproducible dev environments with common-sense images that can be maintained and edited in the cloud, almost like Docker images, with all that stuff preconfigured... the latest interpreters, node, yarn, xdebug, webpack, blah blah all just preconfigured and ready to go. Next.js does some of that, the dev tool Lando tries to do that (but is pretty buggy), but all of it still requires a lot of manual configuration. And coding across platforms (like Windows desktop + Mac laptop) is still a huge PITA even though it all gets deployed to bog-standard LEMP stacks in the end.
It's just such a far cry from, say, being able to seamlessly use the Adobe Suite or Slack or Zoom or Microsoft Office across platforms and projects. I guess it's a bit unfair to compare first-party vendor software to messy open-source ecosystems, but that's what I'm ultimately griping about... I don't want to spend time doing devops instead of coding visitor-facing features. Some companies have dedicated people for that; our org can't afford that, so I just have to figure it out as I go, doing a piss-poor job most of the time. Wish there was a vendor + service to take care of that, and present just a usable IDE in the end, with all the internals abstracted away and maintained in the cloud. Ideally it would be a thin local client with native GUI but offloaded processing, vs a laggy screenshare.
I haven't tried Cloud9 in particular but have tried other cloud IDEs, which just felt like remote desktops running on someone else's machine that I still have to do all the same tooling and maintenance for myself. If Cloud9 or others DOES do what I want and I just missed it, please let me know.
shrug Maybe I'm just getting too old for this stuff. I miss the simple jQuery days when there was the DOM and that was it, not a bazillion layers of tooling and the super complex packagers and containers and other enterprise tech required to support them.
I have had some luck with working across Linux and MacOS. I prefer MacOS shortcuts and use https://github.com/rbreaves/kinto to use MacOS shortcuts on an Ubuntu machine.
I also use JetBrains’s products extensively. I used to have on intellij settings repository for all products (PHPStorm, PyCharm, Webstorm), but I found the same issue that the settings wouldn’t sync in the way I wanted. I now have separate settings repositories for each product. This seems to be working better, although, it does require copying new shortcuts to each product.
I haven’t tried solely using IntelliJ Ultimate, so maybe I will see if I can configure that to work for different programming languages. I have been reluctant to do so, because the appeal of IntelliJ for me is that it makes it easy to work with a programming language. I don’t want to have to configure IntelliJ Ultimate when I want to use Kotlin or want to use Python. Maybe it has a nice way of handling that?
> I don’t want to have to configure IntelliJ Ultimate when I want to use Kotlin or want to use Python. Maybe it has a nice way of handling that?
Hmm, that's actually the point of the Ultimate version, I believe: it supports multiple languages quite nicely, from what I can tell. Finally convinced my work to pay for Ultimate so I no longer have to switch between PHPStorm and PyCharm.
To add support for a new language, you just download the first-party plugin pack (like Python plugin by Jetbrains for Python). Then point it to the interpreter/compiler, which can be set as a per-machine default and then overridden on a per-project basis as needed (like if you needed to use NumPy for a specific project, or a different NPM version). Most of the time it's just auto-detected and works out of the box... it only gets tricky if you have, say, macOS Python 2.7, homebrewed 3.x, and some strays in a Docker container. It'll detect all the ones it can and ask you to choose.
But other than that, projects can use multiple languages simultaneously with no additional configuration. You can even (in the IDE) combine multiple repos into one project, each with a separate git but presented together in the editor. Or use SQL/GraphQL inline in a JS file, for example. It all works pretty seamlessly if you DO have the right license (Ultimate).
In fact I believe the language-specific products are, for the most part*, stripped-down versions of Ultimate. It's all built on a relatively modular plugin system, with each language or module (like the database browser) as a plugin -- but they can't all be activated on every product, like you can't add the DB plugin to PyCharm Community Edition. Ultimate just allows you to enable every plugin.
*That's not 100% the case, maybe only like 90-95%. I have noticed some minor GUI differences between the products, such as being able to collapse buttons... but they are very minor compared to the benefit of being able to use all the languages in one IDE.
I think VSCode works like that too, but you'll need to install a lot more plugins to reach near-feature-parity with IntelliJ.
Personally, I have gone from IDEs to vim + language-servers. I get all the benefits of an IDE that I want, and no useless clutter of features I never use or are better solved in CLI.
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.
> 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.
I agree. Even more: I saw vim users who manually edited dozens of files which could be done by running inspection by name on the entire project in IntelliJ. Even (questionably) superior text editing capabilities of vim won’t help here.
I think many vim/emacs users are not aware of the functionality of modern IDEs and development speed is mostly defined by text editing speed. Sadly, many users of sophisticated IDEs also are not using these functions, so the experienced vim user will likely be more performant than inexperienced IDE user.
As long as your LSP server support it, you can rename it with LSP and it's the same than your rename function in IntelliJ on Neovim. Actually in most languages I use the same LSP server than vscode.
I switched from Vscode/Intellij to Neovim +1 year ago and I couldn't be happier. I get why Neovim/Vim/Emacs is not for everyone tho.
Well, this is exactly what I meant: you need to know your tools. Rename is very basic functionality. What makes real difference is, for example, automatic removal of unused variables/classes (quickly search for all occurrences, review the list, and then apply). Or rewrite some deprecated construct with a new one. Or structural search and replace (works on a code structure, not text).
There is way more to a fantastic language support in an IDE than symbol rename.
I mean, all the features you're mentioning here are part of the LSP server, in the future I think this will be even more consistent across editors because the new languages like Go, Rust, etc. provide better integration tools and LSP servers so the IDEs and editors just use this server instead of implementing one for each language by themselves. If you use the same LSP it will be the same more or less but yeah, the average IDE user doesn't even know what is LSP because they don't need to.
This is similar to MacOS/Windows vs Arch Linux. If you love building and tweaking things, custom builds to suit your needs, knowing every tool that is present in your editor and/or extending it, terminal editors and arch linux is for you, if you prefer something pre-configured that just works out of the box then IDEs and MacOS/Windows is way better ofc. But I don't think that we, the vim/emacs/neovim users, stick to our editors because we are not aware of the capabilities of other IDEs. We are very aware, we are very advanced users in most cases.
I've given Emacs a handful of good tries, but it always lets me down. I've tried out "vanilla", Spacemacs and Doom (the last one being my favorite so far), but it's not working for me. I keep going back to good old Vim.
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.
It can be, because it is :) If you want a really technical explanation, you can profile the application. If that is too much work, I'll generalise and say that the tendency for the UI to lock when performing CPU heavy computations makes it feel slow. Because of the things you will be asking it to do (i.e. solve modern problems), sometimes such computations exist and lead to blocks of 1s or more. That will never feel fast.
> Also we are talking here about Emacs "distributions" (Spacemacs, Doom Emacs) which come with a lot of code, and ELisp is not particularly fast.
I've just tried Doom Emacs on 27.1, with the default stuff plus some minor additions, and it starts within 900 ms on my laptop (Intel(R) Core(TM) i7-9850H CPU @ 2.60GHz).
It isn't. I still use it once in a while on an old netbook with a couple of gigs of memory, and it flies for any editing task. In comparison, no IDE can even hope to run on that unit.
HOWEVER, a heavily and naively reconfigured emacs, possibly with uncompiled elisp code and copy-pasted invocations that wait for network responses could take ages to open.
If you are finding emacs to be slow, try it vanilla first ("--no-init-file") before deciding it's the program and not your configuration.
Wish I started out with Emacs, but after 10 years of curating my vimrc, I don't have time to replace all my custom plugins/bindings by figuring out elisp.
I liked Doom as a vanilla editor, but I went back to vim.
For what it's worth `vim-iced` is pretty cool for Clojure. I didn't like Fireplace at all.
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.
I don't think you can easily do this in vim, but search over the entire code base ignoring anything ignored by git. You can obviously do this with git itself, but it is nice having an interactive list of results.
I work in games, and my applications require beefy hardware to compile (but much less to run). Using projector would let me use my own hardware locally (e.g. my Macbook) and remotely ruin the 32 core, 128GB ram behemoth to compile the damn app. _this_ would let me work on train rides!
There's the future that is likely and then separately the future that would be ideal or preferred.
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.
There are some benefits to usages of cloud-based tech, and there are some drawbacks.
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.
Remote IDEs managed by the employer? A deal breaker for me. IMO that opens the gates of micromanagement. I consider myself a fair productive and successful guy, in my development job, with gaps of non productivity here and there during the day and I consider them physiological. IMO again, Developers should stay away from centralized coding collaborative platforms, despite all astonishing tech accomplishments I see burnout right around the corner. Plus since I have an M1 development machines that's super performant, that I planned to use for at least 4 years, that's just like paying 1euro/day.
On the other hand, if a company wants to micromanage its employees there isn't much that will stop them. It's possible to get the advantages of remote IDEs without the managerial snooping, you just need to work for a company that trusts its employees.
Not saying I prefer remote IDEs, just that they are more a symptom here and not the root cause.
Right - an employer who is willing to use cloud based IDEs for that is willing to install something like Teramind to just record your screen and webcam.
there are plenty of good reasons to use cloud ides. Biggest one being onboarding. New guy joins the team, we can spin up a ready to go system for them to hop in on and start browsing the codebase.
The last job I had I was thrown head first into things. Here's a guide on how to set up things. Use your ide of choice and you're off and running. You learn quite a bit on day one about the common flow you will be using immediately
Or you spend two days thrashing around because someone forgot to document a hidden dependency and nobody can remember what it is but everyone remembers that they hit it on their first day.
I need around two days to set up a machine with all the necessary components and settings for our development environment. I wouldn't mind not having to do this for myself or new people.
I work in games, where it's unlikely that you'll have the prerequisites installed for even setting up the dev environment, and where CLI usage is not common. Visual Studio licenses require interactive logins to microsoft accounts, perforce isn't installed by default (and is configured by the GUI often times, requiring things to be set up before syncing) and then syncing the content can take hours - my current projects' workspace is 42GB, and my last project was >150GB.
I agree with you. I always turned down companies that do micromanagement and I was lucky enough to not get in touch with many during interviews. My point is my current employer trust me and I trust them. It took a while to build that trust however and I fear that, if remote IDEs becomes the norm, the abundance of data points would be abused and building trust for new hires could be more difficult.
and then I'll just write a script to use GitHub Copilot to write a bunch of crap during my down times and when I get back I'll just make another commit that says, "Changed my mind, refactoring...wheeeee".
Dev A writes a lot of small commits and then re-orders them before pushing. Dev B has hours where his environment seems idle and then has a typing spree in between 9PM and 2AM. Dev C knows a lot more than A and B about the debugger.
What’s the difference between company-provided notebook and remote IDE in regard to micromanagement? Employer may provide you shiny new M1 MacBook with all necessary spyware. Even if you use your own machine, you should check every script in the project if it is not installing anything if you don’t trust your employer.
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).
Seems like you think your employer should trust you but you don't trust them? Not every employer is a nightmare. If you think of it as a partnership (and you have the right employer), work is much more rewarding.
If only it works like that. Maybe you find yourself lucky with a manager that looks at your productivity stats with all warm and fuzzy feelings, but the manager above that sees only ROI, and in your review that productivity dip a 3 o'clock stands out. If you don't have this now, then YAGNI.
An employer is a soulless construct that exists for the purpose of extracting as much value from the world as possible in order to deliver it to shareholders. I hesitate to call it 'psychopathic' but it's not at all bound by human morals.
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.
Isn't then an employee a soulful being that exists for the purpose of extracting as much value from the employer as possible with the least amount of work delivered to only provide value to itself in a form of an end-of-month salary?
Employers and companies are built of people. Calling them a soulless construct and pretending everyone in the world is out there to get you is not a healthy attitude.
I see it as realistic, not toxic. A single employee is a human that has greed as one of their drives. Not everything is about money. I'm quite certain I could earn more if I applied elsewhere, but my current company is a nice place to be.
On the other hand, a company is an entity almost singularly driven by the need to maximize profit for shareholders. I have seen multiple teams work months of crunch time, only to be cut loose shortly after they delivered for the sake of 'streamlining'. Now, did the management who did the firing agree with that course of action? Heck no! They were livid. Many walked. But the C suite decision makers found cost savings that would give them fat bonuses and decisions were made.
I often wonder why the same people who are so hesitant to trust government turn right around and blindly trust corporations. The snake is not evil. The snake is a snake. Calling this view toxic or unhealthy does not change the facts on the ground.
To ease on the toxicity, I think I would replace the grandparent's argument by this:
The employee is one person, which you can choose to trust or not.
The employer are multiple people. Of these, maybe dozens or hundreds can impact employee's work. You can trust all of them or not. This is the crucial difference.
Remote IDEs will not prevent theft, of course. But they certainly can do things that make it more difficult than simply dragging and dropping a folder onto a flash drive.
With a title like this I was hoping for something a little bit more grandiose, like discussing whether editing text files is the right way to describe computations.
Battlefield 2042 has a portal mode (their name for it) that allows gamers to "design" a mixup of a variety of older and current battlefield game assets, maps, and modes to create a new game experience with other gamers. For a similar concept in platformers look at Super Mario Maker 1/2 which are AMAZINGLY good games and software for designing mario levels. Here is a link to the Battlefield 2042 documentation: https://help.ea.com/en/help/battlefield/battlefield-2042/bat...
Not a massive fan of Blueprints, as a game developer who is also a long time software developer/security engineer. I think for non-coders it's a great system and can be helpful to view data flow/execution paths in a visual way. I wish the C++ and blueprints systems where better integrated. For example being able to generate one from the other or directly import and use each other (you can sorta do that but with limited access and some boiler plate). I'm not disparaging it, it is really a great attempt at visual coding but as a developer it's not a setup I'd choose to use pretty much ever. For me the best use would be for a non-coder game designer to use it to script levels and for me to integrate seemlessly from C++ as a dev and since I'm a single person indie dev it's of less use to me. It doesn't seem quite ready for that. Most games and examples I've seen with it are either blueprints or C++ not a lot of mixing yet that I've seen, though there is certainly some.
To be clear on my opinion you can integrate blueprints and CPP code but it's not as seemless as I'd like. Given that blueprints run in a VM and your CPP code doesn't there are certainly blocks. They are working on fixing that (https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScrip...) for example. I'm impressed with the quality of blueprints but would still rather approach software from a text based approach and a low level approach. I also hate working in JS frameworks and big collections of libraries all bundled together.
What's old is new again. We were doing this (and with any application, not just IDEs) back in the early 90's with X-windows. X-server local, compute engine where-ever you could borrow/steal/hack it.
As recently as the mid-2000's, my personal computer had virtually nothing in terms of development setup, except for a terminal and an IDE. Even our files were stored remotely (although within a local datacenter, not on the Internet) and we either edited them directly on the terminal in VI, or in an IDE, with the repository working directory Samba-mapped. All builds, tests and deployments were on remote servers. Compared to those days, today's build and test setups seem nightmarishly complex.
Sun Microsystems went all in on this approach. I never worked there, but as I understand it everyone simply had a dumb graphical terminal at their desk.
You might(?) be thinking of the SunRay stuff, which was certainly not X-windows based, though similar in concept/architecture. There was never a time when "everyone simply had a dumb graphical terminal".
(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.)
Hi Gianluca, great article, really.
If you didn't know him, this guy developed Uniwhere, an app for university students that had to compete with a much worse one, funded by taxpayers money.
They really tried every shady trick to make Uniwhere fail, they even banned it at some point, but at the end Gian won and nowadays his app is helping thousands of students.
You made a very motivational speech at the CLab meeting some years ago, really thanks for sharing with us your experience.
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.
Seems I am rather alone with using a boring code editor (Atom) with only necessary plugins (sometimes not more than syntax highlight for my current language)
And do everything else in a tiled terminal window, I have always open anyway.
Same, but replace Atom with Sublime. Vim is too much of a time suck (I will customize until the end of time and get nothing done), VS Code is a bit busy and hectic for my tastes. Sublime is just lean and solid, I love it.
I work on what you might call a 'database IDE' and we have actually gone in the opposite direction, adding more features for offline development and maintaining state offline. We were pretty open either way but our users pulled us this way. Interestingly I think the enterprise may be more open to this remote environment thing, as long as it operates within their network.
For me, IntelliJ is pretty much already there except speed. Too long to startup (I can live with that since I can keep the windows open for a while) but then it starts to slow down after few days and becomes quite slow, say, after a week or more. My opinion is that they should take a release or two to not add any new features and basically only focus on speed.
I suspect there needs to be some newer patterns in open source build systems that help the cloud-based IDEs become a "thing".
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
Remote dev environments certainly have a future, especially for larger teams working on cloud software, which usually is deployed to Linux servers. If you deploy on Linux then you should also develop on Linux. With regards to what will run remotely, the question is where do you draw the line? E.g. Will at least your editor run locally, aka (VS Code remote mode)? The additional latency of the network when typing could be very annoying. The big advantage of remote environments is IMHO not that they are easier to setup. E.g you can also achieve the same locally, but it is rather that you get access to potentially unlimited resources and you can potentially speed up builds, because you can have a high performance cache for build results close to where your development environment runs.
> Software-wise, a fully remote environment helps avoid dual-boot madness and incompatible-drivers fighting: my dev environment sits on an Ubuntu server, making tooling dramatically easier.
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.
If you treat a local VM as a remote server, this can also work well, without relying on working in a «remote desktop» style. This tends to cause UI lag which is more annoying than sending the run unit test» command to the remote server which anyway will take a few seconds to run.
Browser based IDE's are not great for those that want a customised terminal or depend on applications that have key-bindings. For example Cloud 9 was good for getting started in the AWS account I was granted access to but was unable to run tmux or give me a full screen terminal. I am also conscious of the trap certain companies are laying where we end up paying ever increasing subscriptions for enhanced IDE sugar in the same way designers are dependent on paying Adobe for Creative Cloud.
Higher end local hardware (like MacBooks) also have really nice displays. If you go cheap on the laptop then expensive on the remote server, you end up with a terrible screen and keyboard.
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 recently playing around with a bit of a self assembled version of this using VSCode dev containers and exploring what a “GitHub Codespaces first” workflow could look like.
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.
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.
Honestly, I've been seeing the future of IDEs using GitHub Co-Pilot in the last few weeks. It has increased my productivity many-fold.
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.
At a previous job, I was happily working away on a large project when our VPEng ambled by. We had this conversation, and I swear I'm representing this honestly:
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."
And thus we are completing a huge circle that starts with the world where computation is concentrated on a handful of large computers and users having only thin clients and we will end up more or less in the same state with PCs being nothing more than thin clients to run a think client layer like projector client, web browser, rdesktop, ssh, etc.
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.
Despite the developer pushback, I believe remote IDEs will be the standard in 5-10 years. There are many benefits to provide a standartised developer environment for productivity as well security point of view.
IDEs will likely increase their use of so-called AI, and Apple will finally not be the only one who understands the link between a platform, it’s standard libraries, and the IDE linking environment.
I suspect that they will resolve this in the usual bloated manner of simply including everything all over again as the primary unnamed platform I am referring to won’t be able to merely merge some headers… now, I’ll go read the article and see how this was actually about racehorse fiber intake and rectal cancer prescreening, doh, horses for courses?
I was always wondering how it would be if IDE could treat curly braces blocks as virtual indentations. So you could work with language that uses curly braces as if it used indentations. Text file would still contain braces, but IDE would display them as indentation blocks.
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.
What is the gain of deriving the braces from the indentation instead of deriving the indentation from the braces?
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.
Braces by itself are very poor visual indicators of a block, so they are almost always (except in one liners) coupled with indentation of the code inside the block. So, in a raw text form (ignoring newline and space chars) it's two characters to start a block (brace and a tab).
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've made a web based editor (https://webide.se/) that does automatic indentation. You can copy any JavaScript code into it and it will parse and indent. When using other editors i find it annoying to have to manually manage indentation and I do not miss the syntax errors that comes when there is a block mismatch and you have to figure out where that missing } should be...
There are languages like Python that uses "significant white space" where there are no curly braces and instead you use indentation to decide where a block ends.
The problem with Python is that my editor has no way to know
> Chromebooks are going in the right direction, and not by chance. They’re an attempt to fulfill Google’s vision of “everything in the cloud”. I don’t think, though, that they could ever be a great machine to code on: terrible keyboard, terrible screen, terrible shell experience.
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.
I find the author is missing the forest for the trees.
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.
It's funny he mentions running on an iPad, because being able to use Vim or Emacs from on my iPad Pro with the Smart Keyboard via Blink is one of the big advantages of not using an IDE for me. Yes, web based IDEs/editors are becoming a thing, but if you really want something portable to any work environment no matter the platform/security concerns etc. there's really only terminal based editors.
In most use cases I don't see the benefit over a RDP access to that remote server. With RDP you as well have control over all the over things that you might want there, starting with a proper Terminal, File Manager, Process Monitor etc.
Personally, I run my beefy Win/GPU/ML setup in the basement, while using it via RDP from my Mac. Awesome experience for me.
One really nifty thing one can do in VS Code if you use Bitbucket at least (possibly others) is to open pull requests in VS Code using the Atlassian plugin.
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.
I think it's about the thin client, I imagine something like double 4k displays on light-weight googles and advanced finger tracking sensors so that you can "type" anywhere, even laying down. And plugged into a network cable, giving you close to zero latency while interacting with a high powered machine - in a data center fairly local.
I’ve done all my dev work in a remote vm in azure for 3-4 years now and really like the model. I can start coding on one machine, pick back up on another, and zero dev-cruft on my local machine. I’m interested in container based ides for similar reason. The downsides he mentions are legit, but on the whole, I recommend trying the approach.
The one feature I think lacking from IDEs is a way to remote collaborate. I know VSC does have a plugin that works (after a bit of tinkering) but I think having something built in would be a killer feature for teams who are on boarding and training junior developers in today's remote working / post COVID society.
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.
IntelliJ's "Code With Me" plugin still has a long way to go but is really good already: On the "client side", it feels like working in your own IDE (sometimes, you run into "not implemented yet" spots, but for the most part it just works) with zero latency, HiDPI resolution and a color scheme of your liking. Plus, you can work independently (all participants can type at the same time), look stuff up if your pairing partner scrolls too quickly (or too slowly) and you can even share a terminal (if you want) and run tests on the "host". There is also built-in port forwarding, so that you can run a webapp in your local browser.
I don't understand why you are trying to convince me that Code With Me is a solution since I precisely mentioned it in my post with everything that, imo, lacks in it (and in all the "live edit" collaboration tools).
Those tools cannot work, IMO, because programming never happens only in the IDE.
Netbeans had just this about 10 years ago (or was it more?) You could share editing, build, debugging live via a stock XMPP server. Until Sun killed it in favour of some half-arsed imitation that was supposed to make them money.
I would also mention code-server[0], created by Coder[1] for their hosted VSCode service. You can self-host it with Docker and login from outside your network.
How about performance? The current paradigm seems to be either choose a huge bloated Java monstrosity like IntelliJ that has all the features you want, or settle for just a text editor. I would kill for something like Webstorm implemented in Rust or C++.
I am hoping that IDEs start adopting accessibility over design. Yes most have some way to make text larger and higher contrast but those function often make the experience unusable.
Feels like we are going in a giant circle, back to when I ran LSE under DECWindows displaying on my local X11 terminal. Makes me wonder if at some stage we took a wrong turn.
Everything goes in circles, but at the same time gets better -- or, "better" -- so when we get back to the same point "on the ground", it's "at a higher level": Evolution is a helix.
AKA, a screw -- so in the long run, we're all screwed.
I think that most IDEs (with exceptions) are junk that do nothing but occupy disk space, it is far better to use only a text editor and command line compiler.
I don't know if they are a mistake, but they certainly cover up a lot of cruft, which should have been handled.
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.
This point is exactly what I mean, IDE bloat keeps creeping into the codebase and other tools, making parts of IDE a hard dependancy. I'm seeing that happen with VSCode where people are polluting the codebase so VSCode can work.
- 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.