$ gcc foo.c; cp a.out ~/bin/foo
$ foo
$ go run main.goI shouldn't have to specify a ton of flags to g++ something, it should find them within the project directory and pull in dependencies automatically.
Header files should be done with. Poof. Gone. There is zero reason for them to exist. I know exactly why they exist, but it's an artifact of a system where preprocessor, compiler, linker are separate. I should be able to do "import<foo/bar>" multiple times and it should pull in all the classes and functions in "./foo/bar.cpp" or "./foo/bar.so" (whichever is available), just like Python, and cache the ".so" files just like Python caches ".pyc" files.
Improving C++'s build experience would have absolutely zero impact on execution speed.
Yet they're busy adding some stupid spaceship operators and other things people almost never use.
Wait... you didn't get the memo? They did, and renamed the language in the process... it's called Rust. ;)
The reason they still exist is due to how useful they are.
The majority of Android applications probably wouldn't exist if C had done away with headers.
You also can pass env vars to it:
$ CC=clang make foo
And (with care) define your own in: https://www.gnu.org/software/make/manual/make.html#MAKEFILES...
He did not make it past me.
Not that we don’t care about those things, but we have better uses for our time and money than implementing an in-house version of React. Also, our other engineers would probably have strangled him.
Using stdlib is almost free on most systems. It is usually preloaded so it doesn't even use up ram. Unlike functions you write yourself. And with static linking, linkers will only take the functions you actually use, not the whole library.
A js library needs to be downloaded and compiled in its entirety by the user browser. There are techniques to make it less bad, none of them ideal.
The way I interpret GP post is that 12 year old didn't want to bloat his code but had a misguided idea of what causes bloat. You are saying that bloat is fine if it saves on dev costs. Two very different ideas.
Please give me a little credit! It wasn't that I'm against writing code in-house. That's my favorite part of my job! But someone insisting that they want to write everything themselves is a huge red flag. I mentioned React to give it a contemporary context. The interview was a few years ago, and they were ranting against the bloat in jQuery.
That also wasn't the only reason I said no, and I won't go into detail about the rest.
Yeah sure, that's what must be broken. Not my code.
A while later I got smarter, and progressed enough to hook into DOS interrupt handlers with my C code and some assembly glue code. I decided to make a program that would click the PC speaker every time the hard drive is accessed (not a new idea, but a good exercise), by hooking into INT 13h (in DOS/x86 in general, sw interrupts were basically used as system calls).
To my delight, it worked, and it suddenly seemed like I had a very loud hard drive. But DOS would also spit out strange I/O errors when trying to list the current directory.
Huh, weird, I wonder if the same happens in the root directory? So, "cd \", followed by "dir", and, yep, I/O error.
Okay, let's reboot and... doesn't boot?
It dawned on me pretty much immediately what must have happened: I didn't restore all registers correctly before calling the old hard drive sw interrupt handler (again, system call in modern parlance). It must have been unlucky enough to convert some reads into writes. And by trying the same thing on the root directory, I probably converted some reads to the sectors making up that root directory into destructive writes... oops.
12 year old me would choke seeing NPM, pip, or bundle these days... or Electron!
We could do so much with so little!