- 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] speed_spread|4 years ago|reply
- 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.
[+] [-] wing-_-nuts|4 years ago|reply
[+] [-] OneTimePetes|4 years ago|reply
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.
[+] [-] slaymaker1907|4 years ago|reply
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.
[+] [-] withcoherence|4 years ago|reply
Our company Coherence(withcoherence.com) is pre-launch but is working on these exact problems if anyone is interested in helping to solve them!
[+] [-] pjmlp|4 years ago|reply
[+] [-] ARandomerDude|4 years ago|reply
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.
[+] [-] spacechild1|4 years ago|reply
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?
[+] [-] egeozcan|4 years ago|reply
[+] [-] sombremesa|4 years ago|reply
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”.
[+] [-] notpachet|4 years ago|reply
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.
[+] [-] tylerscott|4 years ago|reply
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.
[+] [-] beertoagunfight|4 years ago|reply
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.
[+] [-] fn1|4 years ago|reply
I would never go back to VIM for coding.
[+] [-] TillE|4 years ago|reply
I don't feel I'm learning anything useful by wrestling with the fiddly JSON build configurations in VS Code.
[+] [-] uvdn7|4 years ago|reply
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.
[+] [-] mrfox321|4 years ago|reply
Maybe that needs to be controlled for, too.
[+] [-] marginalia_nu|4 years ago|reply
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.
[+] [-] artwr|4 years ago|reply
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.
[+] [-] tomjen3|4 years ago|reply
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.
[+] [-] pjmlp|4 years ago|reply
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).
[+] [-] jaegerpicker|4 years ago|reply
[+] [-] martythemaniak|4 years ago|reply
[+] [-] iio7|4 years ago|reply
[+] [-] dzhiurgis|4 years ago|reply
To me it’s a red flag when developer uses notepad++ instead of jetbrains.
[+] [-] jimjams|4 years ago|reply
[+] [-] the_gipsy|4 years ago|reply
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.
[+] [-] aww_dang|4 years ago|reply
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.
[+] [-] smitty1e|4 years ago|reply
[+] [-] wing-_-nuts|4 years ago|reply
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.
[+] [-] bayesian_horse|4 years ago|reply
[+] [-] ngrilly|4 years ago|reply
[+] [-] vaylian|4 years ago|reply
[+] [-] xyzzy21|4 years ago|reply
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.
[+] [-] inherently_juxt|4 years ago|reply
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
[+] [-] hollowturtle|4 years ago|reply
[+] [-] Jyaif|4 years ago|reply
[+] [-] mikro2nd|4 years ago|reply
[+] [-] Lucasoato|4 years ago|reply
[+] [-] mh8h|4 years ago|reply
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.
[+] [-] herbst|4 years ago|reply
And do everything else in a tiled terminal window, I have always open anyway.
[+] [-] epberry|4 years ago|reply
[+] [-] noisy_boy|4 years ago|reply
[+] [-] mr_tristan|4 years ago|reply
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
[+] [-] kohlerm|4 years ago|reply
[+] [-] tentacleuno|4 years ago|reply
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.
[+] [-] pletnes|4 years ago|reply
[+] [-] omar_alt|4 years ago|reply
[+] [-] itake|4 years ago|reply
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.
[+] [-] mhoad|4 years ago|reply
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.