[DMcCunney]

Originally Posted by Katsunami

- In the beginning, programming languages didn't have enough structure, so Pascal was created, with very strict data typing.

Bear in mind that Pascal was created by Niklaus Wirth as a teaching language, to help programmers learn to craft algorithms. The original assumption was that the language would "compiled" on paper by the instructor when he graded student submissions. He hadn't intended it to be implemented on a machine. Because of that, basics like I/O were not defined in the original language specification.

Borland's Turbo Pascal (which was actually a Danish product Borland acquired and sold) created a generation of Pascal programmers with a cheap compiler that included IDE and debugger. But because Pascal didn't define things like I/O, the result was a small step above BASIC. Every vendor bundled BASIC on machines, and every version was customized for the hardware and what it could do. Cross-platform BASIC was essentially impossible, and a complete rewrite was needed to move the code to a different platform (assuming what your code did could be done on the new platform. Graphics, anyone?) Pascal wasn't a great deal better.

- Pascal didn't have enough power, so C was created for low level access and data casting from one type to another (Pascal later gained these things as well).

C was designed to be a systems programming language. The intent was a language with the high level control structures that made programmer's lives easier, but with enough power and efficiency that you didn't have to code in Assembler to get performance. It was also intended to be relatively easy to bring up on other architectures.

Dennis Ritchie was developing C at AT&T Bell Labs at the same time Ken Thompson and Brian Kernighan were developing Unix. Unix was being written in the version of Assembler offered by the DEC PDP machine they were using, but around Unix version 6, C was mature enough to rewrite Unix in it, with only about 10% of the low level code that talked to the hardware still in Assembler.

That portability became a major feature. The next step for Unix at AT&T was a Honeywell machine, and one of the selling points for Unix internally was that Unix with the full screen vi editor was a friendlier platform for the folks writing and submitting patent applications. (Vi? Friendly? Compared to line editors used from printing terminals like ed or SOS, Yes! Much friendlier!)

Then software got too large, with too many variables and functions splintered into too many files, so C++ was created to keep everything together in objects.

The object orientation was the point. And bear in mind, the earliest C++ implementation was on Unix in the form of cfront. Cfront parsed the C++ code and "compiled" it to standard C, which was compiled by cc to assembler, to be assembled to machine code by as, and linked into an executable binary by ld. C++ compilers that compiled to native code came rather later.

But people didn't want to do memory management, so you get languages like Java and C#.

And for good reason. Memory management is probably the single biggest source of bugs in code. The less programmers have to be aware of and handle those details, the better. (The machine can do a better job of keeping track of that stuff than you can, and if the tools exist to let it do so, you should use them.)

But Java and C# have a different basic objective. Java is "write once, run anywhere". Java code compiles to a tokenized binary that is executed by the Java Runtime Engine on the target system. Java code targets a virtual CPU implemented by the JRE, and the JRE abstracts away the differences between the virtual CPU and the real one.

The key to Java is that the object code is always the same, regardless of what it's compiled on. You should be able to compile Java on Windows, and run the result on Linux or OS/X, as long as a current JRE is installed. (I have IBM's open source Eclipse programmer's IDE here. It's written in Java. The same binary runs on Windows and Linux.)

C# is similar. C# code is executed by the .NET framework. Microsoft has made .NET open source, and MS engineers are major contributors to the Linux Mono project which was already implementing .NET on Linux. So C# code ought to also be portable to any place a .NET runtime exists.

Handling memory management for you has become a basic for current languages. Google's Go and Mozilla's Rust both try to do it. The question is how to implement garbage collection, reclaiming memory no longer in use, with the least possible impact on performance.
______
Dennis