What's the Future of IDEs?
giansegato.com
giansegato.com
- 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 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.
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.
Our company Coherence(withcoherence.com) is pre-launch but is working on these exact problems if anyone is interested in helping to solve them!
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.
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.
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.
Do people think it is still the case for large code bases and Java? I find the ability to quickly jump to definition in the IDE a huge help when on boarding into a new codebase.
Visual Studio Code's Java support is not great and I do not have jump to definition. Find " name_of_function(" in files is good enough and catches a few useful cases outside Java's understanding, particularly when you have naming consistency throughout a codebase.
Code's not as good as Emacs, but it's reliability installed on nearly every developer's machine regardless of discipline or at least the subset who are willing to ask for help when they encounter problems.
I would never go back to VIM for coding.
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?
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.
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.
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 :)
> The best solution of course is to keep the code base small :)
Hehe, that's the trick. Unfortunately, I came late to the party.
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.
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.
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.
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”.
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...
Maybe that needs to be controlled for, too.
I don't feel I'm learning anything useful by wrestling with the fiddly JSON build configurations in VS Code.
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.
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's a LSP feature, you do not need an IDE.
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.
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.
"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.
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
>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.
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.
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).
To me it’s a red flag when developer uses notepad++ instead of jetbrains.
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.
Not sure why this needs to be something developers can’t fine tune for themself.
If you enjoy that sort of tinkering, more power to you... you're probably a better dev & devops person than I am.
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.
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 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?
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.
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.
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 :(
Also, self-hosted or not, if the system is web-based, that's a dealbreaker.
I too would rather do this. Trusting Amazon with my personal development setup doesn't sound like a good idea; they have the power to shut that down completely at the click of a button.
Not that client is your browser, but locally installed VSCode.
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.
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.
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.
If you really want to fix it, running the nativecomp version solves that issue.
Booting up is normally not done so often, but also doing other stuff takes way too long for my taste (over the perceivable 300ms threshold).
> Emacs ran on hardware from the 1980’s. How can it be too slow on modern hardware?
Since then they've added millions of lines of ELisp code. The comparison is moot.
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 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.
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.
Which maybe I will, because I hate Vimscript.
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.
Org-capture, tramp mode, ansi-term. Tight integration with any workflow. Flycheck, flyspell, it’s all so good.
Much love for emacs. I would refuse to work where I can’t use it. Steep learning curve, but the view is beautiful after the climb.
https://marketplace.visualstudio.com/items?itemName=asvetlia...
Less is more. Tools should do one thing and do it well. I don't want to install a huge package and dependencies just to get one feature. Generally feel pessimistic about the "future" of IDEs. The phrase brings bloat to mind.
If I need the feature, let me add it to emacs. In most cases someone else has already provided a config.
That sounds like a good approach when you need 5 features. But for development the number is probably in the hundreds and I have no time to try to manage all that.
Besides many features are simply not available for editors like emacs. As an example, data flow analysis warns you about logical mistakes in your code (e.g. dereferencing nullable variable without a check first). This happens as you type, the closest you can get without an IDE is probably running it on some static analysis tool in your CI => getting feedback an hour later.
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.
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.
There is way more to a fantastic language support in an IDE than symbol rename.
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 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.
The latter:
* eliminate dependence on the cloud - the entire idea of "everything through port 80" was 100% wrong in the 1990s and it's even MORE WRONG today. Centralization is never the answer except as an instance within some cycling change. Distributed tools are still the better answer under all reasonable circumstances!
* focus on implementation of both parsers and IDEs. New languages will always be created and anything that makes both parser AND IDE creation easier and more "automatic" is a good thing.
Most everything else good can come from these to start with.
The cloud inherently attempts to decentralize computation (duh). If you can have multiple servers across a country, chances are, one freak accident (weather, power-grid failures, etc) is less likely to bring down your ecosystem. If it's well architected, your users may not even notice. In that sense, it can be fantastic for reliability and scalability since a lot of these cloud server companies allow for easily creating new instances of the same project.
If your software is written poorly or your environment is poorly architected, then you can encounter issues using the cloud like centralization as you mentioned, and you'll also have to manage difficult or arcane deployments. You also run into a problem of dependence on your cloud platform of choice. No one likes vendor lock; it hurts flexibility and increases costs in the long run. If your project is AWS based for instance and has a dependence on Lambdas, for instance, what are you going to do if Amazon suddenly raises their costs beyond what your company can reasonably accommodate? There are some workarounds, but they obviously aren't as nice or immediately available.
But also, what are your alternatives to using a cloud provider? Your company could create physical infrastructure in safe places, but all the prime spots would be taken up extremely quickly not to mention that it's waaay more costly to build a mainframe on or offsite than it is to spin up an EC2 instance or ten. And if your system isn't on-prem or thereabouts, then it seems like cloud is the only real solution there.
Agree 100% with the IDE stuff though
Fully agree, this direction sounds like nightmare fuel to me.
Not saying I prefer remote IDEs, just that they are more a symptom here and not the root cause.
That said, I can't speak for the Mac users of the world. I've watched people make $30 an hour hunting down DMGs online...
- IT doesn't have the hardware ready
- New team member is inexperienced in using an IDE, but the entire development environment setup is GUI based
- New team member is inexperienced in a CLI, but entire dev environment setup is CLI based
- New team member is working from home and hasn't received hardware for new start date on their first day
- New team member is a fresh graduate, and needs actual mentoring and training
- Link rot/outdated documentation on setting up a dev environment.
- New person may not be technical (I work in games, we have artists)
- Working from a location where internet speeds to download a toolchain, OS updates, docker images are slow.
You can just take a look at the pull requests and commits.
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.
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.
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.
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.
IME employers can actually sense this when it happens and a lot of the ridiculous bullshit you would otherwise have to put up with melts away.
You ain't ever being a partner working on the checkout tills at walmart ;-)
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).
We're moving towards a world where ML can generate code that compiles from a single comment.
We have games like Battlefield now providing no-code options to FPS gamers.
There are literal super computers that can spin-up environments in seconds, run a test suite and report back, all to give a little tick on a PR.
Yet the IDE still just gives a messy error message if you forget a semi-colon or quote in the wrong place.
Can you elaborate on that or drop some keywords that will help with a web search?
(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.)
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.
And do everything else in a tiled terminal window, I have always open anyway.
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
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.
I think remote IDEs make sense if you’re a massive company with an insane number of microservices that need to run for testing, but 99% of devs would be better off with local dev.
I was honestly pretty happy with where I landed on it even in the context of a fairly complicated setup running a Flutter web app, a backend and an envoy sidecar proxy.
I was also able to set up a consistent IDE experience by specifying the various plugins I wanted to use along with other tooling I needed like gcloud SDK etc…
But just last week I did a remote pairing session with someone on a full stack web application entirely within a remote codespaces environment with zero other tooling (even the pairing was taken care of thanks to VSCode live share plugins). I thought that was a pretty cool experience overall. The thing I love most though is that I’m not specifically tied to a remote development environment I can get the exact same experience by just running the devcontainer locally on my machine.
1. Back to easy indirection resolution (https://youtu.be/baxtyeFVn3w?t=1786, re: gtoolkit)
2. Comments that are not inline, but can point to various blocks/parts of code and overlap (multiple comments can apply to single parts of code).
3. More support for unit testing. function call tracking (https://stackoverflow.com/questions/51901676/get-the-lists-o...).
4. Conducting behavioral studies via opt-in submission of eye tracking data. A great deal of data is flowing through IDEs and not being leveraged to improve the daily tools of developers.
I was so positively shocked by its suggestions that I kept positing videos of it in action with the team.
It adapts to the structure and peculiarities of a specific project and you only really understand it once you are in a flow; you almost forget about it until one time you press return to write a new line of code and it correctly writes exactly what you wanted.
It's creepy and absolutely incredible at the same time. Almost as if you're pairing with someone that you never speak with.
Here's Co-Pilot finishing a coding kata for me: https://i.imgur.com/ih32sCy.mp4 (trimmed to 60s b/c of imgur limit).
Employers that standardize on a single IDE (e.g., enterprise Java shops and eclipse - blech) are always terrible places to work.
I'm curious why you went with spacemacs.
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."
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.
I'm not completely sure if UX would work out. There would be less visual noise, so reading would be easier. Writing is harder to solve as IDE would need to be smart and convert indentations to pairs of braces underneath in appropriate contexts.
This feature would of course need to be togglable on/off.
You still have one character to start (tab?) and end (backspace?) a block, but now they are overloaded with the edition keys, and still need to keep track of the block with the same visual aid (indentation).
The small changes I see are to the worse, that is overloading the keys and not letting you see the text verbatim.
Sure, a good IDE will automatically create indentation when you type '{', so you need to only type a single character to start the block. We could actually say '{' is a shortcut key to start a block. IDE creates an indentation and draws a vertical line to enhance visual presentation of the block. Visually, braces are more or less just a noise, so removing them would improve "signal to noise ratio" and enhance reading experience.
However, logically braces are better at defining blocks of code than tabs. With braces we have start '{' and end '}' characters, but with tabs each line needs to be indented by a correct number of chars (tabs/spaces).
I am wondering, if we can have best of both worlds.
In some cases we are trying to draw visual indications with text. Wouldn't be better, if we let the IDE do the drawing? Eg.: two vs four spaces of indentation? It doesn't matter, if you can configure visual indentation depth on the fly in the IDE.
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
And that's why better languages use the keywords "begin" and "end" in stead.
What? There are chromebooks by many different manufacturers, and they all have a terrible keyboard and screen? As for the shell experience, that's not going to matter if development happens in the browser.
The magic of their experience was created by automatic environment configuration. It's the magic that let them start working without spending a day preparing an environment to start working within.
It's something that VSCode does quite well, not perfectly, but well. It installs a decent environment automatically for most popular languages and toolkits.
Emacs has _finally_ caught on, and lsp-mode will attempt to automatically install language servers for you.
If remote coding was the norm it would be an open door for corporate surveillance on a massive scale.
I don't feel good about this idea, I think we should resist and fight back, this is not only a technical discussion.
On the other hand, the thin client idea is cyclical but is usually short-lived and is often the wrong solution to a real problem (bloatware).
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.
Most recently I've been really impressed with the Remix IDE for Ethereum smart contracts. https://remix-project.org/
When working in cloud IDEs, I just need the safety net of backup/versioning via git commits.
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.
Those tools cannot work, IMO, because programming never happens only in the IDE.
[0]: https://github.com/cdr/code-server [1]: coder.com
If not, terrible awful idea that will enslave us all.
Joking, but also not.
This sounds like a problem with one device, not the whole concept. I have used devices with great keyboards and screens. You just have to pay more.
> terrible shell experience
In what way?
AKA, a screw -- so in the long run, we're all screwed.
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.