As far as I can tell, there is no such thing as a good programmer who knows only one programming language.
There just isn’t. The nature of the field is that raw computation is quite alien to ordinary human thought; and that the best way to get anything even remotely resembling a reasonable grasp on it is to come at it from multiple angles.
You should know about functional abstraction, which you’re not going to get very much of out of C or Perl, but you might get out of Lisp or Haskell.
You should know something about how the machine operates, which you’re not going to get out of Java, Python, or Haskell, but you might get out of C, Forth, or assembly. And reading about the actual architecture you’re working on. (It’s easier to do this on a dinky architecture. I recommend 8-bit AVR microcontrollers.)
You should be eager to reuse other people’s code to solve your problems, which you’ll learn from an open-source, big-library language like Python, Perl, or Ruby, but probably not from a small, standardized language like C or Scheme.
You should learn about data structures, which you’ll only get deeply if you have to implement them yourself, which is really only something you do in a CS class — but you should also learn about not reimplementing data structures that someone has already done for you better than you can do yourself. You can pick that up in any language with good data-structures libraries, like C++ with STL, Python, Haskell, etc.
You should learn about types as an expressive system and not merely a burden, which you’ll get from a strongly-typed, type-inference language like Haskell, but not from a heavyweight manifest-typing language like Java or C++.
You should know how the OS works, which in most systems today you can really only get by learning C. You should know about system calls, the standard library, sockets, and so on. You should know why we don’t use gets(3) any more.
You should know about Lisp macros because there’s really nothing else comparable in any other language. Template Haskell doesn’t really count, and C macros especially don’t count.
You should learn about parsing the traditional way; and then learn about monadic parser combinators in Haskell, because they are fucking awesome.
You should know what a buffer overflow is, what a format-string exploit is, what an SQL injection is.
You should know about relational databases. I could go on about relational databases because they are deeply misunderstood by most programmers and actually contain a wealth of hidden awesomeness; but I won’t, because it would go on forever, and much smarter people like Chris Date have written it already. Suffice it to say that a relational database is not just a place to stuff variables that you want to keep around for a while; it is a place to stuff facts that you want to draw inferences from. There — that makes it sound suitably AI an’ shit.
You should learn how to work with a nontrivial runtime that does things like garbage-collection, which you won’t get out of C or C++ but you might get out of Lisp, Java, Python, Ruby, or Go … if you pay attention.
You should learn about concurrency, which you can maybe get by learning about threads and the like in a language like Python, C++, or Java, but you’ll probably learn better in a language like Erlang, Go, or Clojure that treats concurrency as a first-class concern.
Anyway, as should be obvious, computation is big and there is a lot to learn. But you can pretty much jump in anywhere. There’s no right or wrong starting point, so long as you keep in mind that it’s a starting point. Don’t let anyone convince you that their personal pet language or system is all you will ever need. They’re just trying to get you to join their phyg, and phygf exist at your expense.
Computing is a field that you can keep doing for a long time and still have lots to learn. This is, in fact, part of what makes it awesome.
If you are looking to learn the conventional mechanics of using relational DBs, The Learn X The Hard Way series is well-regarded, and there is an (in progress) SQL edition (I don’t have specific experience with this book).
As far as I can tell, there is no such thing as a good programmer who knows only one programming language.
There just isn’t. The nature of the field is that raw computation is quite alien to ordinary human thought; and that the best way to get anything even remotely resembling a reasonable grasp on it is to come at it from multiple angles.
You should know about functional abstraction, which you’re not going to get very much of out of C or Perl, but you might get out of Lisp or Haskell.
You should know something about how the machine operates, which you’re not going to get out of Java, Python, or Haskell, but you might get out of C, Forth, or assembly. And reading about the actual architecture you’re working on. (It’s easier to do this on a dinky architecture. I recommend 8-bit AVR microcontrollers.)
You should be eager to reuse other people’s code to solve your problems, which you’ll learn from an open-source, big-library language like Python, Perl, or Ruby, but probably not from a small, standardized language like C or Scheme.
You should learn about data structures, which you’ll only get deeply if you have to implement them yourself, which is really only something you do in a CS class — but you should also learn about not reimplementing data structures that someone has already done for you better than you can do yourself. You can pick that up in any language with good data-structures libraries, like C++ with STL, Python, Haskell, etc.
You should learn about types as an expressive system and not merely a burden, which you’ll get from a strongly-typed, type-inference language like Haskell, but not from a heavyweight manifest-typing language like Java or C++.
You should know how the OS works, which in most systems today you can really only get by learning C. You should know about system calls, the standard library, sockets, and so on. You should know why we don’t use
gets(3)any more.You should know about Lisp macros because there’s really nothing else comparable in any other language. Template Haskell doesn’t really count, and C macros especially don’t count.
You should learn about parsing the traditional way; and then learn about monadic parser combinators in Haskell, because they are fucking awesome.
You should know what a buffer overflow is, what a format-string exploit is, what an SQL injection is.
You should know about relational databases. I could go on about relational databases because they are deeply misunderstood by most programmers and actually contain a wealth of hidden awesomeness; but I won’t, because it would go on forever, and much smarter people like Chris Date have written it already. Suffice it to say that a relational database is not just a place to stuff variables that you want to keep around for a while; it is a place to stuff facts that you want to draw inferences from. There — that makes it sound suitably AI an’ shit.
You should learn how to work with a nontrivial runtime that does things like garbage-collection, which you won’t get out of C or C++ but you might get out of Lisp, Java, Python, Ruby, or Go … if you pay attention.
You should learn about concurrency, which you can maybe get by learning about threads and the like in a language like Python, C++, or Java, but you’ll probably learn better in a language like Erlang, Go, or Clojure that treats concurrency as a first-class concern.
Anyway, as should be obvious, computation is big and there is a lot to learn. But you can pretty much jump in anywhere. There’s no right or wrong starting point, so long as you keep in mind that it’s a starting point. Don’t let anyone convince you that their personal pet language or system is all you will ever need. They’re just trying to get you to join their phyg, and phygf exist at your expense.
Computing is a field that you can keep doing for a long time and still have lots to learn. This is, in fact, part of what makes it awesome.
I keep meaning to try drinking some of the relational kool-aid—any links you’d recommend?
If you are looking to learn the conventional mechanics of using relational DBs, The Learn X The Hard Way series is well-regarded, and there is an (in progress) SQL edition (I don’t have specific experience with this book).