I had a similar experience with MSFT docs when working at Sun. The docs were not very good, and though they seemed somewhat redacted, it felt like in fact their internal docs probably weren't much better.
Many years ago I knew an ex-microsoft engineer. Microsoft had poor interoperability with something, and I speculated that engineers in microsoft didn't know what 3rd parties were doing and accidentally broke things.
He told me, "don't be naive - microsoft would have meetings saying 'how can we own this?'"
Not to cast doubt on your friend's story, I worked on both the SQL Server team and later on the Windows kernel team in the early 2000s (the bad years). I came from "outside" meaning I had already had a career at non-Microsoft-related companies (mostly startups using linux on the server). I was continually shocked at how _little_ the MSFT employees seemed to know about the industry, or how their customers used their own products.
As an example, this was the era of the J2EE App Server. Almost none of the people I worked with knew what an App Server was, despite the #1 database in use by App Server customers being MSFT SQL Server.
During the Ballmer era MSFT was famous for the lack of cooperation between and within teams. That's what you get when you use stack ranking to decide compensation.
I still don't know what an app server is. Isn't that one of those things from the enterprise programming era where they'd get "architects" to design an "enterprise system" and it would come with twenty different things with names like "message bus" and "dependency injection" that no program in history has ever actually needed?
In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now. The two most common in my career were JBoss and Tomcat. Since Java packaged applications into Jars which could be run anywhere (up to environmental assumptions made by developers), you could simply scale up by sending these jars to the app servers to run. Actually, the Alibaba group was quite annoyed in the JCP that western members had given up on these aspects of the Java platform and were moving to support containerization. Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such. App servers standardize what it means to start an application which makes operating many applications much easier.
Message buses were generally in memory or in process streaming brokers. Most of these have moved externally today via Kafka, RabbitMQ or cloud proprietary versions like SQS. Some people may lean on ZeroMQ to build similar behaviors when doing multiprocessing and some people may even do it in process if they like the api. Definitely very much part of large scale application development today although the terms of art have changed.
Dependency injection is just a fancy name for polymorphism via fields in your struct, although if you have too much exposure to spring you will associate it with that plus an inversion of control on the actual injection part: that is, you will associate it with heavy use of annotations. If you have polymorphism with a switch (or chained ifs) on a parameter, you don't have dependency injection but if you have polymorphism by having different inplementations of a field of your struct then you are doing dependency injection. Very much part of good software design today, the annotation driven wiring possibly not so common outside of Java + Spring.
I think of dependency injection as a generalization of LD_PRELOAD, the point being that the "injection" is done via configuration that is external to the application's code.
That's a good take, I hadn't really thought of that one before and I had certainly used LD_PRELOAD or some incarnation thereof (forgive my memory is was more than a decade ago) to swap out different implementations of the same API.
> In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now.
Sure. I have worked on JVMs before, but not server side, and I never had to touch anything sold by IBM.
> Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such.
No, I think there's a difference. The deployment story for PHP was that you copied it to the web server and that was that. The mandatory part was a webserver you had anyway. There is FastCGI, but in PHP's case it can be thought of as purely a cache and is not necessary.
> App servers standardize what it means to start an application which makes operating many applications much easier.
A PHP web app does have some moving parts like needing to start nginx/fastcgi/mysql, so in that sense it still needs a container.
But the difference between the PHP source itself and Java is that PHP is 1. stateless and 2. doesn't take nearly as long to start up.
The first one is the big one and means you don't need to restart anything to update the app. This part of PHP is so well designed it practically makes up for how bad the rest of it is.
The second one was more of a Java flaw; the runtime is undercooked (which is why it had all that other super complex stuff on top of it) and everything has to go on the heap, instead of having more of a concept of constant data that could just be mapped in from the binary/jar file. That's what they got for not adding value types I guess.
The C# documentation was, at least in its initial years, very good. It even had working examples that demonstrated functions. Compare that to typical javadoc of its time.
