In spite of all your arguments even today most important software powering modern computing are written in C, this speaks volume about its simplicity.

I am sure there will still be critical software powered by C 40 years later. Rust will take another decade or two to reach that level of simplicity and ease of use still not sure if it will cross the threshold to replace C, when an average developer needs to spend years just understanding basic syntax, use of language and its traits.

C is like English, Hindi or simplified Chinese not very pure with flaws and ambiguity, still became lingua Franca of the majority world due to simplicity.

Yet Google, Apple, Microsoft are driving C's replacement for better alternatives, go figure.

https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

https://security.googleblog.com/2019/08/adopting-arm-memory-...

https://android-developers.googleblog.com/2019/10/introducin...

https://developer.apple.com/swift/#fast

English only became the lingua Franca after the two big wars, and even then, good luck trying to make use of English in some world regions.

I recommend reading a bit about the history of lingua francas since the beginning of mankind.

"The Last Lingua Franca: English Until the Return of Babel"

https://www.amazon.com/Last-Lingua-Franca-English-Return/dp/...

> even today most important software powering modern computing are written in C, this speaks volume about its simplicity.

C code is simple in the sense that it closely matches the simple binary interfaces of the compiled code: plain symbols with simple calling conventions. Anything more complicated than this presents a seemingly insurmountable barrier to code reuse thats leads people to rewrite stuff in C.

The current situation is any code that's meant to be reused will be written in C so that every other language has access to the resulting functionality. The higher level languages either have much more complicated binary interfaces or are completely virtualized so code reuse is extremely difficult. C++ and Rust can export C interfaces but the benefits of those languages are not available to the users of the code because the interface has been reduced to C.

> this speaks volume about its simplicity.

No, it's just an indication of how many existing C code already exists that you have to conform to.

Not having graphical tooling is a net positive in my experience. I’m a programmer, not a graphic designer.

Also the UI while visually clunky is neat and free of distractions.

The only IDE I use these days in IntelliJ for Java - because Java is one of those few languages that really benefits from integrated development. Great as it is, I do find myself having to relearn a few things every year or so, and often having to readjust to changes in look and feel, and for what?

I happen to be a programmer that also does graphics, GUIs and GPGPU debugging, graphical display of data structures.

Then there are those architecture design documents, DB tooling integration, bug ticket/source control/task management.

Sounds like fairly specialised tools for that stuff.

I typically use a document editor, to you know, write documents ...

Sorry I thought we were talking about development tools here.

Text editors

And how they lack features to match what IDEs are capable of.

Given that James Gosling created XEmacs, my go-to editor back in the day, I think you will find this interview interesting, although most certainly it won't change your opinion.

https://thenewstack.io/a-conversation-with-the-creators-behi...

Thanks for this, nothing jumps out at me vis-a-vis our exchange here but since you took the time to post it I will take the time to read it.

It's not so much that I have strongly held beliefs so much as a combination of experiences that have led me to the juncture where I see most codebases as being quite unstructured, and I appreciate the benefits of a more unstructured tool for dealing with them.

The baseband for nearly everything I work with is text, pretty much all of Latin form (ASCII, UTF-8, ISO-8859-x etc). When it comes to having to switch context between various languages and codebases, all of many and varying levels of hygene, I've come to a conclusion that I have "a particular tool" that is more suitable than most others.

Of course, when I have the luxury of working with "more structured" code, I will use the appropriate tools, but quite often the tools don't work as effectively once the code deviates from more idiomatic structure (Eclips is notably robust in this sense - but I find it can be quite clunky).

But if I have the time to learn the tools, and the tools can make the code more "fluid" to work with then I'm all for it.

In particular "Java" (which is I presume why you're linking Gosling) lends itself to this, and I did make this point above. The language itself is so robust, and the development culture seems to value best practices well enough that making the investment to learn these tools is worthwhile (EDIT - exactly in the sense that Gosling describes in TFA).

Another example in recent times has been Apple XCode when doing IOS development. The tool-chain is far too complex for me to get a "bottom up" appreciation of how it works, and the IDE in that case works just fine for me.

But these are exceptions in my 20 years or so of experience. More often than not I've a big mess to be dealing with that demands a powerful text editor.

As a younger guy I used to spend hours trying to set up my IDE and get projects to work with my tools, but I've got kids to feed now and have other stuff to do.

EDIT - read it now. Still unclear of what point you are making, unless you are erroneously assigning me to the "real men use vi" camp ... vi (or vim) has it's place, but I wouldn't really put it in the same category as Emacs, except for the fact that maybe Emacs has a terminal mode of operation. vi to me is more like windows notepad. It's always there when I need to quickly edit a configuration file.