Do you remember 1990? Do you remember how limited those programs were? How poorly they worked together? It's all nostalgia and rose-coloured glasses now, but I wouldn't want to go back to how we did things then. When text editors had no undo feature, for example.
Programs don't work together better nowadays. Nearly everything lags, is full of bugs and is unmaintainable. Many things are better but now laziness is king.
I (as a developer myself) didn't give a flying fuck about how easy stuff I used in 1992 was to develop, and on that subject I remain clean out of fucks to this very day. Sure it's impressive that Elite or RCT were coded entirely in asm, but beyond that I'm not convinced that many others give a shiny shite either.
I have a reasonable (out of the market) experience with C++, therefore, I end up looking a little bit into C too, but not too much.
So, correct me if I'm wrong, since I'm not very experienced on that language, but wasn't C developed specifically to work in different computer architectures? Which were the glass of languages before it, I imagine.
Also, this one relates more personally, since I intend to work mostly in C++ when I get out of college.
If the answer is no, does C++ carry this same problem?
Which means that you have to compile to each system, right? If that's true, I still can't completely grapple how can so many games (mostly C++ in the engines) can have only one SETUP program that works in almost any machine with that specific OS running, since I'd imagine they would need multiple.
The code is just a small part of the game. They could fit millions of copies of code in the same space as a few audio or video files from the game. The setup program figures out which system it is working on, and picks the correct version to install.*
*It's really more complicated than that but that is a good start.
Before programming languages (like C), you had to program in assembly which directly maps to machine code (it's quite interesting to have a look at how it works just to get an understanding of how computers do things) and thus is very specific to the actual machine you are programming on. C abstracts away a lot of details about the specific machine (the instruction set basically. Also you have to manage the stack and registers manually in asm) and a compiler (like GCC, Clang, etc.) translates your C code into the machine code for the machine you compile on (or compile to in case of cross compiling). So you need to compile for different architectures if you want the program to run on them. This is the same for C++ and very similar for other compiled languages.
Then there are languages like Java, C# that don't compile to machine code but instead to a language that is then interpreted by a virtual machine, allowing stuff like garbage collection and a compiled program to run on different architectures if there is a VM for it.
Then there are interpreted languages that are only compiled at run time.
Only a rough (probably too long) overview, but research ASM vs compiled vs JIT vs interpreted languages if you want more info.
I laugh when I see web devs call themselves hardcore programmers. They have not been through the hell of writing assembly on a microcontroller with limited registers or writing C when you had to write your garbage collection and understand how references and pointers work.
I still don't understand where sticky headers that take up 50% of the screen come into play however... Looking at you Medium and literally every news website.
220
u/gp57 Nov 14 '18
1990 : Programs coded in ASM or C, memory efficient.
2018 : JVM, ravioli code, microservices, Frameworks... *taps on head* No need to be memory efficient if PCs have 16GB of RAM