Pip has changed a lot in the last few years, and there are many new ecosystem standards, along with greater adoption of existing ones.

> I'm often dealing with files with several thousand lines of code and heavily nested functions.

This is the problem. Also, a proper editor can "fold" blocks for you.

> Being able to see the type of data at a glance tells me a LOT about what the code is doing and how it's doing it - and Python doesn't let me see this information.

If you want to use annotations, you can, and have been able to since 3.0. Since 3.5 (see https://peps.python.org/pep-0484/; it's been over a decade now), there's been a standard for understanding annotations as type information, which is recognized by multiple different third-party tools and has been iteratively refined ever since. It just isn't enforced by the language itself.

> Mix other languages in and suddenly it becomes pain.... This isn't always true for compiled->compiled.

Sure, but then you have to understand the assembly that you've stepped into.

▲

Night_Thastus 5 days ago | parent [-]

>This is the problem. Also, a proper editor can "fold" blocks for you.

I can't fix that. I just work here. I've got to deal with the code I've got to deal with. And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope.

>Sure, but then you have to understand the assembly that you've stepped into.

Assembly? I haven't touched raw assembly since college.

▲

zahlman 5 days ago | parent [-]

> And for old legacy code that's sprawling, I find braces help a LOT with keeping track of scope.

How exactly are they more helpful than following the line of the indentation that you're supposed to have as a matter of good style anyway? Do you not have formatting tools? How do you not have a tool that can find the top of a level of indentation, but do have one that can find a paired brace?

>Assembly? I haven't touched raw assembly since college.

How exactly does your debugger know whether the compiled code it stepped into came from C++ or Fortran source?

	▲	fluoridation 5 days ago \| parent \| next [-]
		>How exactly does your debugger know whether the compiled code it stepped into came from C++ or Fortran source? I don't know what IDE GP might be using, but mixed-language debuggers for native code are pretty simple as long as you just want to step over. Adding support for Fortran to, say, Visual Studio wouldn't be a huge undertaking. The mechanism to detect where to put the cursor when you step into a function is essentially the same as for C and C++. Look at the instruction pointer, search the known functions for an address that matches, and jump to the file and line.
	▲	exDM69 4 days ago \| parent \| prev [-]
		> How exactly does your debugger know whether the compiled code it stepped into came from C++ or Fortran source? Executables with debug symbols contain the names of the source files it was built from. Your debugger understands the debug symbols, or you can use tools like `addr2line` to find the source file and line number of an instruction in an executable. Debugger does not need to understand the source language. It's possible to cross language boundaries in just vanilla GDB for example.