# "The problem (with) modern Fortran is that there is not a good IDE .. on Windows" **URL:** \ **Category:** Help\ **Created:** [November 25, 2022, 5:35pm UTC](https://fortran-lang.discourse.group/t/the-problem-with-modern-fortran-is-that-there-is-not-a-good-ide-on-windows/4808 "2022-11-25T17:35:11Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![gnikit](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/gnikit/32/1213_2.png) [@gnikit](https://fortran-lang.discourse.group/u/gnikit)\ **Post date:** [November 25, 2022, 6:42pm UTC](https://fortran-lang.discourse.group/t/the-problem-with-modern-fortran-is-that-there-is-not-a-good-ide-on-windows/4808/2 "2022-11-25T18:42:02Z")
I am obviously biased on this but I think that VS Code + Modern Fortran + fortls make for a good development environment that in many aspects is more capable in terms of Fortran support, than VS. The main problem I can identify with my proposed solution is that Intel compilers do not have a debug adapter for Windows so you have to rely on GDB for debugging, see this post I made a while back that did not have any real engagement about the issue: > [@Debugging Intel compiled code on Windows - Visual Studio Code](https://fortran-lang.discourse.group/t/debugging-intel-compiled-code-on-windows-visual-studio-code/4426): > > I am following up from an issue a VS Code user encountered a while back with Intel Fortran compilers on Windows and Debugging. Essentially, the problem faced was that there was no suitable Expression Evaluator for Intel compilers on Windows. Therefore, the Debug Adaptor cppvsdbg (closed-source and IP owned my Microsoft) is not capable of resolving the symbols from the object file. This ultimately means that code compiled with Intel compilers cannot be debugged in VS Code on Windows. I was wond… Relying on GDB for debugging comes with some challenges, I identified some of them in this thread and why it is in the best interest of Intel and the other compiler vendors to aid in resolving them > [@The state of GDB in Fortran](https://fortran-lang.discourse.group/t/the-state-of-gdb-in-fortran/4726): > > GDB and GFortran are two amazing tools, that have helped many of us with our research and work. Personally, without them my MSc and PhD research would not have been possible. Unfortunately, even though GFortran has made great strides in implementing [F2003](https://gcc.gnu.org/wiki/Fortran2003Status), [F2008](https://gcc.gnu.org/wiki/Fortran2008Status) and a good part of [F2018](https://gcc.gnu.org/wiki/Fortran2018Status) GDB[[1]](#footnote-29260-1) for Fortran has been lagging behind, specifically the pretty printing of OOP constructs and the Python API. This causes a cascade effect and ultimately affects the Fortran debugging tools that we are able … In general, the thing **drastically improves** the coding experience are features provided by the Language Server Protocol. VS is lacking a modern extension for integration with the `fortls` Language Server, currently the only language server in active development, and hence it’s stuck in its current state. I don’t have free time to develop such an extension as a side project, but someone else in Fortran-lang could probably do so. --- _[View the full topic](https://fortran-lang.discourse.group/t/the-problem-with-modern-fortran-is-that-there-is-not-a-good-ide-on-windows/4808)._