This is dead on: "Whatever you choose to learn as your first language, the key is to learn from great code."
It's also worthwhile to learn a lot of other languages. Do it as soon as possible in your career, especially Lisp and C. No matter what language you may use, you'll probably benefit from knowing these two. The danger with any "first language" is that you may never learn a second.
Not always true. I learned Pascal, and then Ada first (in college). Haven't used since then, but I had no trouble learning C, Java, Lua, or Python later on. Lisp was slightly confusing, and I remember hating C++.
I think the key is learning well at least few kinds of languages. C (is a must), an object oriented language (Java), then a scripting language (Python, Lua, Ruby, Javascript, or Perl), then a pure functional language.
Of course, often in real life, often you end up using what is being dictated to you, but a good programmer should be aware of what's out there.
I think Lua is a particularly good language to learn early: it's quite small and very approachable for somebody vaguely familiar with the C languages, but it has coroutines, tall-call optimization, and quite a bit of flexibility via its meta-tables. I haven't used it on anything big enough to know if it's really practical for me as a getting-stuff-done language, but it's really growing on me.
Also, can of worms and all, but the borders between "an OO language" and "a scripting language" are quite thin. You could learn OO from Python or (I suspect) Ruby. OO design made quite a bit more sense to me when it didn't have to work around flaws in C, C++, and Java's type systems.
My favorite thing about Lua is the way you can fit all of the syntax in your head. I never have to go to a reference
when writing everyday code in Lua.
Why Lisp? Wouldn't any functional language do the same? I'm not flaming here, just wondering... I learned SML which was OK, but it didn't change my world. I still like writing code in Ruby better.
In short, no. ESR had it right. "That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot."
My primary bread-and-butter language is Javascript. When done "right", Javascript is a very expressive functional/prototypal object oriented language with a lot of very interesting features. If you can do it in lisp, you can do it in Javascript: http://foohack.com/tests/ycomb.html
I've seen in myself and in coworkers, the best Javascripters know at least a little lisp, and as their lisp skills increase, so do their javascript skills. I suspect it would have the same effect on Ruby or SML or Erlang programmers.
Their attitude towards boilerplate code tends to change as well, and they begin seek solutions that are as concise and expressive as possible.
Lisp is unique because it effectively has no syntax. You write the abstract syntax tree directly. By removing the scaffolding, Lisp exposes the programmer to the fundamental nature of any programming language in a way that no other programming language does.
That's why C and Lisp are the best languages to learn, as early as possible: if you know these two pretty well, you're in a good position to master any language you might come across.
Misc is a promising cousin of Lisp: http://will.thimbleby.net/misc/ I've played with it a little, but not enough to really have a strong opinion of it.
There are some great books for Scheme in particular. Many of them are geared toward the art of programming itself, rather than how to do X in Y days, which frees up the curriculum for exploring things like recursive forms that a student in a hurry would almost certainly just hack around, without learning the fundamental idea.
Also, learning Scheme as a first language almost guarantees you'll have to learn a second language. ;)
I learned SML which was OK, but it didn't change my world.
This seems odd to me. Working with Haskell for a while changed how I think about state. I usually avoid (non-trivially) mutable objects now, and instead return a modified copy of an object. (For an example, see the process method here: http://git.jrock.us/?p=Template-Refine.git;a=blob;f=lib/Temp... )
Also, Haskell's type classes (and CL's CLOS) are a different approach to OO compared to Smalltalk-style "send a message to the object". It is definitely good to be able to think about OO both ways.
It is still shooting yourself in the foot. There are a lot of questionable design decisions that will take a while to unlearn when PHP is your first language. The OO model is still a little screwed up, and uglier than C++ even, because of lack of namespace. There are arguments for and against it, I wont get religious. But if you want to be a "programmer" then you must move quickly from PHP. If you want to only be a web developer... fine. PHP is a baby step, even if you stick to dynamic languages.
My first was PHP, I was able to get useful things off the ground, mostly by trial and error, from what was initially very simple examples.
PHP's strength is it's so damn easy to write useful, simple scripts. And it's so fast to provide feedback, and it works with an existing metaphor many people understand (upload file to FTP, hit it in your web browser, bob's your uncle).
I found it very, very difficult to learn OO as the stdlib at the time was full of nothing but functions. I think you learn a hell of a lot from working with well designed APIs, and let us be brutally honest, PHP's stdlib is about as well designed as a shit-moulded santa claus.
I tried learning Java well enough to get some kind of commercial project off the ground but was befuddled, book after book why it took so damn much code to do _anything_. Though I did learn a lot about OO from reading these books, I never got an opportunity to get stuck into any Java to learn how to do things, at the time I perceived as the 'right way'.
But unlike PHP to get anything off the ground in Java, you had to install Tomcat, write about 20 lines of something and set up a web container and god knows what else. Compare this to plonking <?= $_GET['test'] ?> in a text file, call it 'blah.php' and hit it. Instant feedback.
Since then I've been working with Ruby for about 3 years, and I've finally got my head around how to write decent code, and it's mostly been because of exposure and experience with nice APIs, and being able to work with the higher level patterns that you are just simply not exposed to with rudimentary PHP.
Sure, today you have CakePHP, the Zend Framework but they only popped up in the last couple of years, and mostly in response to Rails' influence.
In between Rails and PHP I had toted with Perl and Python and enjoyed them thoroughly. I would suggest writing as much damn code as you can in a bunch of popular, and different languages, and you'll be fine :) I'm still yet to play with LISP and OCaml, though I'm keen to have a crack at Lua...
I've often wondered if the PHP community in general is more reactive than enterprising. Had it not been for Rails would we see the crop of well engineered PHP frameworks? (when I say well engineered I mean these frameworks work hard to put lipstick on a pig sort of way).
Yup, One thing to add is PHP is good language to start out if you want to be a PHP Programmer / Web Developer and no plans to move over to something else.
But if you want to be a generic programmer or get in to the field, it will save a lot of time and hassle if you start out with C/C++/Java. Those cover all the major concepts to begin with, and switching to PHP or any similar language would be very quick if not instantaneous.
Then again, I think it's even a better idea to start with something fun and something you really and feel like you are getting rather than jumping to something really complicated.
There is no one-size-fits-all language to start with, it depends from person to person.
Could you think of any big flaws with starting out with PHP? Problems you'd want to avoid?
I don't care much for programming: I'm much more interested in design. As such, I really don't think I'll need to learn anything beyond PHP and Javascript. Are there things that I, and people like me, will run into because we don't know any better from other languages?
The main problem is the popularity of PHP. There are some great PHP developers out there, but because of the popularity many of them are not good. And you learn how to code from the people around you.
The other problem is that both Javascript and PHP encourage implicit casts, which are great but lead to subtle issues you probably won't understand unless you learn a stricter language.
And seemingly the good ones tend to know more languages than just PHP. PHP is just another tool in their toolbox unlike the masses of PHP monkeys out there that no nothing but PHP.
> [I]t will save a lot of time and hassle if you start out with C/C++/Java. Those cover all the major concepts to begin with [.]"
That's just blatantly false. They're probably good languages to know because they are collectively the lingua franca of programming at the moment, but there is quite a bit they never touch upon. Learning Scheme, Haskell, Prolog, or Forth would introduce you to ideas you would never encounter while using C & co.
PHP is no different from any other scripting language in that it's a language tailored to get things done, and done quick. If you do something quick with ruby, perl, python you can make it as crappy and sloppy as you can with php.
The problem though is that almost every thing written in PHP looks like shit. So PHP programmers trying to learn a good writing style by looking at PHPbb or similar are shooting themselves in the foot. Aha! I could put PHP code in the database and run it by 'eval' - smart idea! Must be really secure templating / programming design since this is such a big project... And what's up with wordpress, a more programmer hostile templating engine is hard to find still people use it.
Each task has a language or two which will fit the task the best, but don't get hung up in the finer details like which language you should use. Use which ever language feels right, and invest your time into the application itself.
Good point. I was trying to convey that, taken all together, the code was an unmaintainable mess of spaghetti. It was difficult to read and it was difficult to change.
When done right, all of those things have a place. My point is usually (with PHP at least) it's not done right.
> Making something more complicated does not make it better.
I think the confusion here is that strong OOP is actually simpler. Breaking code into smaller chunks (such as objects) makes it more modular and easier to understand. That's the point.
It's also worthwhile to learn a lot of other languages. Do it as soon as possible in your career, especially Lisp and C. No matter what language you may use, you'll probably benefit from knowing these two. The danger with any "first language" is that you may never learn a second.