> Good luck writing Makefiles for Fortran, OCaml or (whenever they will really, actually work) C++ modules.
I've successfully written Makefiles for Fortran and they worked with ifort/ifx and gfort. In my experiments I've also made GNU Cobol, GNU Modula-2 and Vishap Oberon fit within the Makefile paradigm without much trouble. You have failed to provide reasons as to why those languages in particular (or more likely any language that's not of C heritage) can't be used with Makefiles. For instance, you can definitely couple OCaml with Makefiles, just use ocamlopt and treat .cmx files as object files, generated beforehand by ocamlopt -c (like you'd do with GCC). I am not familiar with C++ modules and as such I didn't experiment with them.
> I've successfully written Makefiles for Fortran and they worked with ifort/ifx and gfort.
Did the samé (I'm not sure if gfortran did exist at all at the time, I guess it had been g95), plus they worked with Absoft, PGI and Pathscale too (yes, that has been some time ago). And it was a great PITA. Not the least because at the time no Fortran compiler did generate the dependency description, so you either had to parse the Fortran sources by yourself or use makedepf90, which didn't work with all sources.
> You have failed to provide reasons as to why those languages in particular [...] can't be used with Makefiles.
I have obviously badly worded that. I didn't mean it is impossible, just that is a great PITA.
> I am not familiar with C++ modules and as such I didn't experiment with them.
They have the same problem, you don't know the name of the module that is going to be produced.
Arguably, Tcl can do GUIs much easily and can integrate C less awkwardly than Perl. Both have their use cases, at any rate, and more people should use Tcl, Perl and any version of Expect. Nowadays it falls into the category of tools that were once somewhat used, but now are obscure, like fold/fmt, nl, comm and pr.
Perl/Tk has always been a red headed stepchild since it is a fork attempting to implement a C API that doesn't require Tcl to be linked. Because of that, it has long missed out on significant improvements to Tk over the years. Python Tkinter avoids that by just wrapping around a Tcl interpreter.
Either Rasmus Ledorf or Bjarne Stroustrup. Arguably, another Danish programmer contributed to the history of Pascal: Peter Naur (and also Jørn Jensen, but he was more into implementing ALGOL 60 compilers).
Honorable mention to DHH, although he didn't create a programming language. And also to Lars Bak for being the lead developer on V8.
Don't forget about the time Borland really thought they could outsmart Microsoft on .NET and gave us the wonderfully horrible Delphi 8. To put it into a metaphor, Delphi 7 was like XP, Delphi 8 was like Vista. People still use D7 while Borland and Embarcadero wants to forget they ever tried D8 (and Delphi Prism which is just rebranded Oxygene).
And at about the same time they also tried doing a native Delphi for Linux, which was so bad they pulled out after 3 versions and never tried Linux again until recently (and even then, you can only cross-compile, you can't run Delphi 12 on Linux or macOS).
And they also tried getting into the VCS sphere with StarTeam (which somehow still received updates well into 2017... Despite it being made in 1995). I don't know why OpenText decided to buy it in 2023.
Let's not forget about Turbo Prolog and the time they almost did a Turbo Modula-2, but it was actually published by TopSpeed and now lives in Clarion. Ugh.
Borland... Err, Inprise... Err, Embarcadero... Or CodeGear? Or Idera? Who keeps count? Anyway, that switched so many hands it's sad to see. They were doing way too much. A lot of bad decisions made them less and less popular (not like their current greed is helping their case). Oh well. Long live Free Pascal.
I've successfully written Makefiles for Fortran and they worked with ifort/ifx and gfort. In my experiments I've also made GNU Cobol, GNU Modula-2 and Vishap Oberon fit within the Makefile paradigm without much trouble. You have failed to provide reasons as to why those languages in particular (or more likely any language that's not of C heritage) can't be used with Makefiles. For instance, you can definitely couple OCaml with Makefiles, just use ocamlopt and treat .cmx files as object files, generated beforehand by ocamlopt -c (like you'd do with GCC). I am not familiar with C++ modules and as such I didn't experiment with them.