I started learning C++ when I was a freshmen in high school with a copy of Borland Turbo C. I didn't get far.
In the summer I graduated from high school, I lived in Seattle and worked for my uncle who runs the King County Library System, doing basic Unix stuff. This is months before the WWW went mainstream. I got bored one day and started playing with Unix commands to see what they'd do (I had, let's call it, a "tfile's understanding" of Unix at that point).
I vividly remember C clicking for me the moment I figured out how to deal with system calls that returned structures (via pointers). C clicked for me with "getpwnam()". I started writing little utilities that printed out structures returned from system calls.
I learned design from Leendert van Doorn's NFS shell. Y'all are too young to remember this, but in the '90s, the NFS shell was the most important piece of offensive security code out there (try to imagine an Internet where the biggest security problem is the fact that 10-50% of your systems are exporting '/' to the world). NFS shell had a command prompt driven off an fgets loop and an array of string commands and function pointer handlers. Mind: blown. I started writing utilities with arrays of string commands and function pointer handlers. Then I hooked them up networks and made little protocols. Brief dark period of Perl. Back to C. Working at an ISP, wrote a program to scan arbitrary ranges of IP addresses for live hosts. My girlfriend at the time taught me recursive linked list delete. Got _C Interfaces and Implementations_. Shortly thereafter: first dev job. Off to the races from there.
Seebach had MUDs and curses games. I had security tools. Otherwise, similar stories. Helps to come up on Unix instead of DOS.
That can't be emphasized enough. I know my own understanding of how computers and computing work was strongly stunted by having been constrained to Windows for years. I've learned so much more using Linux and FOSS, especially the nix commandline, for a quarter of the time I've used Windows.
And of course that's the way it's supposed to be. Windows is specifically designed to abstract and hide the details so non-tech users don't have to figure it out. But for a tech-oriented person trying to grok it, that's just no good.
I really don't think it's because Windows is designed to be programmer-unfriendly; I just think C is the lingua franca of Unix, and something else is that for WinAPI.
I learned C++ with Borland C++ on DOS. It was really cool that I could do anything with the machine! Of course, most of the time it just crashed when working with pointers... Later, working on UNIX, I found it much easier, but less fun.
Before floppies and CDs existed or were viable to distribute with a magazine, computer magazines used to come with giveaway software in the form of source code printed on a cheap paper booklet. Somewhat similarly to the author, I learned BASIC as a kid mostly by typing in dozens of pages of code from those supplements.
Initially I was just drawn to the free software; the laborious typing was just a means to get it. It was when it started failing due to my or the author's typos, rotting tapes and shortage of memory that I had to actually look into the code, look commands up in the user manual (which was otherwise unattractive since it was totally cryptic for a kid), and find practical ways of fixing things, which then led to a desire to learn what was actually going on, and the feeling of "It's not magic; I can do it too".
The mere abundance of doing, even of the rote and uninteresting variety, can teach you things in a particular subtle way that's hard to attain otherwise.
When I was 8 my classroom had a subscription to 3-2-1 Contact magazine. Every issue they would include a BASIC program that you could type in and play around with. Since I couldn't take the magazines home, I hand-copied the programs to note cards (and the first time, being a total noob, didn't differentiate the zeroes from the O's - my first experience with "debugging"). Those were the days...
I remember days I would print my source so I could write code in school, long before every child had access to a computer and long before laptops were anything anyone besides CEOs and very important traveling businessmen owned. Revision control consisted of printing to carbon-copy paper.
I still have a few reams code printed on Dot Matrix-perforated paper in my basement.
making sounds on a violin does not make you a musician just like coding up some statements does not make you a programmer. But it is how everyone, great or small, starts. Nice read.
First it was BASIC for me (Apple ][), then Turbo Pascal 3.00, 4.00, 5.00 for DOS and at that point I was writing a File Manager (like Norton Commander, but single page).
I got stuck due to missing move file (move(), RenameFile()) function in the Turbo Pascal Library. I was not familiar at that time with Interrupt List, or how I can call assemnly from Pascal (it was rather easy).
Someone also told me that all games and serious things were written in "C/C++". A friend of mine moved to "C" and he made his first mistake of putting all code in the header files (in Turbo Pascal, you only code in the .pas files, they become binary objects - called units .tpu).
So I spent a year just reading the "green C book" that was released in Bulgaria. After spending rereading, rereading, without touching (and no internet, not newsgroups, that was 1992 - only few people had modems, and my first experience with the internet was ... 1998 :)).
Then after switching to Borland C/C++ I felt a little more advanced than my other programming folks (we all went to a computer club in my city of Burgas).
But then, some things strike me - the executables were bigger, the compile time was bigger - more memory, but yet I was on the right language.
So I moved back to Pascal, and it was not until I started real job in a company that I moved to C/C++.
Borland (Inprise now, or whatever their name is) kind of lost it - Delphi was good - but nothing was better than TurboVision and the BGI libraries at their time.
Now, more than 10 years later - I can barely read Pascal code - and I use to write this extensively. I can't even remmember how you open files (and I did couple of small antivirus programs back in the day for DOS in it).
I learned C, after having learned BASIC and Pascal. I was 14 and read somewhere that C was the main language of UNIX. It clicked pretty quickly for me since I thought pointers made a lot of sense. When I first saw p++ in a C book and realized that the actual value of p would advance sizeof(whatever p points to) rather than 1, it just kind of made sense.
I've found after learning C I have a much better appreciation for writing resource conscious programs on a computer than I did before when I was first introduced to Java.
It has certainly helped me learn Objective C and C++ a lot quicker.
I'd even go as far as to say for new people to programming and put off by C, Objective C could be a good stepping stone for them.
I wonder if there will be a next generation of hackers that learn this way. I had a similar story, learning "programming" by poking around inside giant dungeon crawl type games written in basic. However, any game that is interesting enough for "kids these days" won't be a text interface written in a couple thousand lines of basic. Are there languages and tools simple enough to create a game that would be interesting enough for a potentially budding hacker to bother digging in to?
Löve, PyGame, JS, Scratch, and Shoes, to name a few. The trouble isn't that you can't write a fun game in a few thousand lines of a high-level language — after all, lots of kids spend plenty of time playing Tetris and Bejeweled and so on, which you can implement in a lot less than a couple thousand lines of code — but rather that a randomly chosen game is unlikely to be accessible this way. There are two obstacles.
First, you can always make the game better by adding more code. In 1979, that wasn't the case, because you could easily make the game too big to fit in memory. So even though you can make a playable, enjoyable game in 50 or 100 lines of code, you can make it noticeably more fun in 1000 lines of code, and marginally better than that in 10 000 lines.
Second, most games, especially casual games, aren't distributed in source-code form at the moment. Seebs had the good fortune to be working on Unix, where people distributed things in source because it was the easiest way to make them runnable on everybody else's Unix system. JS has the same advantage, but with Flash and Win32 and Linux, it's easier for users to run your code if you distribute an inscrutable binary than if you distribute the source code. So that's what game authors do.
In 1984 I was working for a small company that made Z80-based desktop computers running CP/M. All of the software was written in Z80 assembly language. MS-DOS was gaining traction, so we built a machine that contained both a Z80 and an 8088. It could run CP/M or MS-DOS.
However converting a bunch of Z80 assembler to x86 assembler for all our system utilities etc was a daunting task. There were tools available that would translate the code, but the quality was poor and the resulting output was not really readable [maintainable]. I expressed my annoyance in a planning meeting, saying "We should have written some of this in a high level language." One of the other guys on the team had done a small amount of C programming at university and was aware of its portability advantages. He suggested I look into it.
Although I had used several high level languages in the past (Basic, Fortran, Pascal), I was completely unfamiliar with C. So I bought a early edition of K&R. I started reading it from the start; got about 4 chapters in and thought, "This looks easy enough." So I sat down and wrote a rudimentary VT100 terminal emulator (something I knew a great deal about at the time). I tried to compile it: a dozen errors on the first line, a dozen errors on the second line, etc. I thought, "Hmmm, maybe not so easy after all."
The one guy I knew who had done any C programming at all, had done so little as to be useless as a source of knowledge, and we didn't really have a great deal of C source code available to us at the time. So I sat down with K&R and started doing the examples 1 at a time. Hello World going forward.
I picked it up pretty quickly, and within months our source was about 80% C and 20% assembler. Although I wasn't a self-taught programmer, I was pretty much a self-taught C programmer. The scary thing was, I was then considered "the go-to guy" for C programming advice for the rest of the team. I probably ruined them for life.
I wish this had been my back story. Maybe someone here can help me out, or maybe I'm just a terminal under-achiever.
I never learned a lick of programming until I hit school. I tried, using the limited resources I had at my disposal. But I lived in a small remote town of 6000 people, and that was the major urban center for well over 200km. Being Canada, we had no access to any of the major online services, and any services available in Canada were long distance. My parents only had one phone line, so I never got to explore the one bbs that was available in the town.
Around 1992, I was 13, my parents finally got a computer. MS-DOS/Windows based. I was familiar with computers, having become addicted to many games at friends' houses. But, being DOS, getting games to run forced me to learn the hard way. Mostly this involved destroying things and reinstalling them. I wish I'd known anything about unix/linux, but I'd never heard of it. Dos was the only thing I had seen or knew. I didn't even know anyone with an amiga.
I tried to do things with basic, but I could find no documentation, and the basics were beyond me. I tried modifying things, the odd bit of hex hacking (my crowning achievement was modifying Civ to give me extra gold when I negotiated -- but only because it was stored as plain text in the dialogue files).
I knew programming -- and especially games -- held interest for me, but I could not penetrate it myself. In 1997 I finished high school and went off to an overpriced game programming school which shall remain nameless. I left with not a lick of programming ability.
I learned fast, and with just the first few weeks of C courses, and a couple hints on how to draw a bitmap, I set off like a rocket, and was whipping out games before anyone else. Programming just clicked for me. I graduated with one of the highest marks (and turned almost every assignment
in to a playable game of some sort in the process).
Fast forward nearly 12 years, and I am a successful and decent coder. I know a bunch of languages, I can learn any new one in a few hours of puttering around (often without a book, though I do like having reference manuals), I've done web stuff, and windows apps, but mostly just games.
But in reality, I have done very little outside of work. I'm good at what I do, I have my pick of companies any time I want, my last two games were Assassin's Creed 1 and 2, responsible primarily for the combat systems. I am apparently good at it but I've never felt like a great programmer.
This is never more obvious than when I try and do personal projects. My harddrives and perforce depots are a wasteland of started and abandoned projects. I hit a technical challenge and I don't have that drive I did when I was a kid. I'm not really happy with my job, I don't find it as satisfying as I once did, and I want to do things on my own, but, somehow it just doesn't click for me.
Often I just chalk it up to being addicted to big development -- I'm used to having a massive support team for art, level design, etc. And I'm not multi-disciplinary. I can't do any art at all. Even placeholder, it's just horrible. I can do design, and I can do code, and most other things are beyond me.
But I feel this is just an excuse I use to avoid actually working on my own projects. I'm pretty sure I have the ability, but I can't really find the focus.
I guess this has been rambling, but I do hope maybe someone can give me some pointers as to what my problem is. Like I said, maybe I'm just a terminal underachiever when it comes to my personal projects.
Go learn erlang, and otp. It will change the way you think about software development forever. It'll also make you stop saying you can learn any language in a few hours. Really, lisp, Haskell, scala, F#, and others could do that too.
Regarding abandoned projects and such: raw talent is great, but it's not nearly as important as drive, determination, and tenacity. I think it was michaeangelo who said: people rave about my talent, but if they saw how hard I have to work for it, they wouldn't think it so amazing. This is very true. Raw talent and coding excellence is really important. But still, this biggest difference between a true professional and a tinkerer, in all kinds of professions, is keeping on going.
I remember as a kid, I was trying to figure out how games work, by writing my own games. I was writing text adventures and stuff. But I remember feeling unsatisfied; I wanted to write a "real" game with lots of things moving at the same time in real time, like asteroids. How do they do it, I wondered, since you can only have the computer do one thing at a time. I reasoned that it would be possible to do, but the only ways i could think of doing it were a ton, a metric ton, months, of work. So i never really got into serious game development until much later.
What I didn't realize then was that yes, it really is a ton of work to write the magical software that the Professionals write. And that's their main secret: tons and tons of really hard work. Either in figuring out how to make it easy, or in just gutting it out long after it's not so fun anymore, or both.
Yeah, true. FWIW, I was oversimplifying with the coding example -- I'm sure it would take me forever to learn a functional language, but while I love programming, I don't necessarily have the passion for it that would lead to me learning a functional language. I need a reason to learn it, and then I'll love it when I do -- without that reason, I don't really see the point.
And yeah, I probably just don't hard enough at it at home. I wish I didn't have the day job -- if I could spend 8 hours a day working on my own stuff, I'm sure things would be different.
Thanks for your perspective though, it is helpful. I do know the secret of hard work, after all, that's how I got where I am today. I just tend to only deploy said hard work when I'm at work. Though this is changing, I think, as I become less and less attached to my current job. I spent five years personally invested in the AC projects, but now I don't have as much to give on my current work project.
you have ability but not skill. skill is the application of ability to a problem over time (with good feedback!)
you are 12 again at anything you haven't really dug into. for many people who have specialized, the frustration of being a total NOOB can give off the impression "wtf!? this SHOULD BE EASY. i am smart at other hard things, so why is this hard for me? maybe i just cant do this."
Well, sorry. Most people exhibit very low transfer of skill from one domain to another. That's totally fine!! It just means to have to take new things on like a total beginner.
As for getting ish done, try very, very small things so you can build momentum and self-confidence.
Yeah, that's certainly a part of it. I did prove to myself recently that it's not necessarily application of focus that's the problem -- I successfully completed 50k words for nanowrimo last month.
Very awesome and inspiring ... I do the same thing all the time (hack at codesy things that I have no real understanding of ... like the time I spent 2 whole days trying to get Phusion Passenger to run on Windows) and feel ashamed to say it out loud for some reason.
In the summer I graduated from high school, I lived in Seattle and worked for my uncle who runs the King County Library System, doing basic Unix stuff. This is months before the WWW went mainstream. I got bored one day and started playing with Unix commands to see what they'd do (I had, let's call it, a "tfile's understanding" of Unix at that point).
I vividly remember C clicking for me the moment I figured out how to deal with system calls that returned structures (via pointers). C clicked for me with "getpwnam()". I started writing little utilities that printed out structures returned from system calls.
I learned design from Leendert van Doorn's NFS shell. Y'all are too young to remember this, but in the '90s, the NFS shell was the most important piece of offensive security code out there (try to imagine an Internet where the biggest security problem is the fact that 10-50% of your systems are exporting '/' to the world). NFS shell had a command prompt driven off an fgets loop and an array of string commands and function pointer handlers. Mind: blown. I started writing utilities with arrays of string commands and function pointer handlers. Then I hooked them up networks and made little protocols. Brief dark period of Perl. Back to C. Working at an ISP, wrote a program to scan arbitrary ranges of IP addresses for live hosts. My girlfriend at the time taught me recursive linked list delete. Got _C Interfaces and Implementations_. Shortly thereafter: first dev job. Off to the races from there.
Seebach had MUDs and curses games. I had security tools. Otherwise, similar stories. Helps to come up on Unix instead of DOS.