4 ms·

Aah this brought me back memories! Waaaaay back in the day (90's) I would implement my own methods I stead of say including stdlib.h or other libraries because

Aah this brought me back memories! Waaaaay back in the day (90's) I would implement my own methods I stead of say including stdlib.h or other libraries because I had the (wrong) idea that including it would bloat my C programs (didn't know how a like worked uh?) . 12 year old me would choke seeing NPM, pip, or bundle these days... or Electron! We could do so much with so little!

dheera 3y ago
I've always loved programs that didn't even need "make". The ideal build and install experience should be: $ gcc foo.c; cp a.out ~/bin/foo $ foo Now that is a REALLY good build experience.
- tomcam 3y ago
  You probably know that this is routine and even simpler in Go: $ go run main.go
  - dheera 3y ago
    Yes, and it boggles my mind why C/C++ hasn't come up with a better built-in build system already. I 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.
    - morning-coffee 3y ago
      > Yes, and it boggles my mind why C/C++ hasn't come up with a better built-in build system already. Wait... you didn't get the memo? They did, and renamed the language in the process... it's called Rust. ;)
    - tomcam 3y ago
      I’m annoyed too, because I love C and back in the 90s languages like Turbo C and Microsoft C were quite intuitive to use from the command line and using whatever old editor you wanted. I would still very happily be using modern C if the overall experience were like Go.
    - lelanthran 3y ago
      > Header files should be done with. Poof. Gone. There is zero reason for them to exist. 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.
  - lelanthran 3y ago
    Even simpler in C, when using tcc as the compiler.
- chungy 3y ago
  You don't need a Makefile, but you can just run "make foo" and it'll automatically run "cc -o foo foo.c" for you.
  - anyfoo 3y ago
    Almost thirty years and I never knew that.
    - wruza 3y ago
      Make has builtin rules for most obvious build jobs: https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html https://www.gnu.org/software/make/manual/html_node/Catalogue... You also can pass env vars to it: $ CC=clang make foo https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html https://www.gnu.org/software/make/manual/html_node/Implicit-... And (with care) define your own in: https://www.gnu.org/software/make/manual/make.html#MAKEFILES-Variable https://www.gnu.org/software/make/manual/make.html#MAKEFILES...
kstrauser 3y ago
I helped interview a front end developer who bragged about and insisted on hand-writing every bit of JavaScript so that we’d have the leanest possible website. 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.
- tambourine_man 3y ago
  You may have lost a good developer. Enthusiasm is valuable. Trying to do the best possible thing, even if misguided.
- intelVISA 3y ago
  Nice, you really showed him.
- GuB-42 3y ago
  GP was talking about stdlib, you are talking about react. Not the same thing at all. 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.
- kstrauser 3y ago
  Replying to myself: 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.
anyfoo 3y ago
Oh god, fun related memory. When I was 10 or 11 or so, I programmed in Turbo C on my PC. At some point, I messed up some pointers that I passed to strcpy(), so young, smart me decided that "string.h must be broken" (I actually also thought it contains the actual definitions), and moved the file away so that I don't accidentally used it. 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.
- xtracto 3y ago
  Great stuff! Back in the msdos/win3.11 days I experimented with TSRs and viruses (following tutorials and the like) . At one point i borked my (Dad's) computer running some stupid "virus" I created that infected COM files... had to basically delete the whole disk.
- glandium 3y ago
  > young, smart me decided that "string.h must be broken" I mean, fundamentally, you weren't completely wrong.

dheera 3y ago

I've always loved programs that didn't even need "make". The ideal build and install experience should be: $ gcc foo.c; cp a.out ~/bin/foo $ foo Now that is a REALLY good build experience.

tomcam 3y ago
You probably know that this is routine and even simpler in Go: $ go run main.go
- dheera 3y ago
  Yes, and it boggles my mind why C/C++ hasn't come up with a better built-in build system already. I 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.
  - morning-coffee 3y ago
    > Yes, and it boggles my mind why C/C++ hasn't come up with a better built-in build system already. Wait... you didn't get the memo? They did, and renamed the language in the process... it's called Rust. ;)
  - tomcam 3y ago
    I’m annoyed too, because I love C and back in the 90s languages like Turbo C and Microsoft C were quite intuitive to use from the command line and using whatever old editor you wanted. I would still very happily be using modern C if the overall experience were like Go.
  - lelanthran 3y ago
    > Header files should be done with. Poof. Gone. There is zero reason for them to exist. 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.
- lelanthran 3y ago
  Even simpler in C, when using tcc as the compiler.
chungy 3y ago
You don't need a Makefile, but you can just run "make foo" and it'll automatically run "cc -o foo foo.c" for you.
- anyfoo 3y ago
  Almost thirty years and I never knew that.
  - wruza 3y ago
    Make has builtin rules for most obvious build jobs: https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html https://www.gnu.org/software/make/manual/html_node/Catalogue... You also can pass env vars to it: $ CC=clang make foo https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html https://www.gnu.org/software/make/manual/html_node/Implicit-... And (with care) define your own in: https://www.gnu.org/software/make/manual/make.html#MAKEFILES-Variable https://www.gnu.org/software/make/manual/make.html#MAKEFILES...

kstrauser 3y ago

I helped interview a front end developer who bragged about and insisted on hand-writing every bit of JavaScript so that we’d have the leanest possible website. 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.

tambourine_man 3y ago
You may have lost a good developer. Enthusiasm is valuable. Trying to do the best possible thing, even if misguided.
intelVISA 3y ago
Nice, you really showed him.
GuB-42 3y ago
GP was talking about stdlib, you are talking about react. Not the same thing at all. 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.
kstrauser 3y ago
Replying to myself: 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.

anyfoo 3y ago

Oh god, fun related memory. When I was 10 or 11 or so, I programmed in Turbo C on my PC. At some point, I messed up some pointers that I passed to strcpy(), so young, smart me decided that "string.h must be broken" (I actually also thought it contains the actual definitions), and moved the file away so that I don't accidentally used it. 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.

xtracto 3y ago
Great stuff! Back in the msdos/win3.11 days I experimented with TSRs and viruses (following tutorials and the like) . At one point i borked my (Dad's) computer running some stupid "virus" I created that infected COM files... had to basically delete the whole disk.
glandium 3y ago
> young, smart me decided that "string.h must be broken" I mean, fundamentally, you weren't completely wrong.