If a noob, who knows nothing about computer programming, wishes to embark on the painful journey of developing software, what is the best paradigm to start with and why? Procedural? OO? Functional?
I've been thinking about this lately because at college Java is the first thing to be taught and I noticed there to be a lot of confusion among the students. Those who have never been close to computer code are having an extremely hard time grasping the concepts. Those who have programmed before are having less of a hard time, but are still utterly confused (try explaining to them what the "this" keyword does, for instance).
I personally started out with BASIC when I was 14, and much much later I decided to learn about OO. I think it's a lot easier to learn a procedural language before learning OO.
What do you think?
Best programming paradigm for noobs?
From the perspective of acquiring good habits as early as possible I think both procedural and OO fail. Procedural because it makes it easier to go hacking and slashing through a codebase without giving real thought to what you're doing, OO because it can encourage boilerplate and over-architected solutions that contribute little to actually solving the problem.
I partially subscribe to the school of thought that says that making programming easier to learn (or at least to start learning) just produces a lot more bad programmers. Maybe I'm getting more jaded and cyncial as I get older.
I've no experience with functional, and I must remedy that, but I do like a lot of what I read/hear about it. From what I understand, the concepts that functional programming teaches you are genuinely useful and are going to be more useful as we move more and more into an era where writing good, robust, thread-safe code is of paramount importance. So if my understanding is correct, then that's what people learning programming today should be learning. It's not something I've given a great deal of thought to I must admit, but it is something that seems obvious enough to me.
I've no experience with functional, and I must remedy that, but I do like a lot of what I read/hear about it. From what I understand, the concepts that functional programming teaches you are genuinely useful and are going to be more useful as we move more and more into an era where writing good, robust, thread-safe code is of paramount importance. So if my understanding is correct, then that's what people learning programming today should be learning. It's not something I've given a great deal of thought to I must admit, but it is something that seems obvious enough to me.
It seems that a number of universities agree with you - as I recall, my alma mater used to teach Java as a first language, but now uses Racket, a dialect of Lisp.
OO because it can encourage boilerplate and over-architected solutions that contribute little to actually solving the problem.
YES. I think this may have been what went wrong with me... I struggled with over-engineering solutions and not beginning my code until I had gone over every possibility in my head for a very long time. Think I'm getting better now, but it may have been starting with the OO mindset being so popular that led me to such madness.
Has to some better compromise that doesn't get students caught up in extreme OO adherence, but also doesn't lead to spaghetti code and confusion.
I feel a lot more confident and interested now that I've decided to drop some of my excessive planning and fear of having to change things down the line.
From the perspective of acquiring good habits as early as possible I think both procedural and OO fail. Procedural because it makes it easier to go hacking and slashing through a codebase without giving real thought to what you're doing, OO because it can encourage boilerplate and over-architected solutions that contribute little to actually solving the problem.
I started to reply earlier and then thought better of it because I didn't feel I was being clear enough. I'm glad you've come in and made my point for me so articulately.
On the topic of functional languages, I'm of a split mind -- on one hand, the concepts they emphasize are those that will continue to hold whatever languages you come to work with in the future and their signal-to-noise ratio (lack of boilerplate) is famously excellent; but on the other hand, the concepts themselves seem hard to grasp for many (perhaps these concepts are things that come easier to a mind yet untainted by baser paradigms) and that functional languages are so high-level in many ways that they make even languages like Java look positively remedial. Lazy evaluation, Abstract Data Types, Continuations, Monads, all the run-time optimizations that the environment can make for you... hard things to really wrap your head around. That said, among programmers who started in other languages and paradigms, those who have taken the time to learn functional programming almost universally praise it as a mind-expanding experience, which is perhaps the highest compliment that can be given to such a thing.
I've delved some into a handful of functional languages. I like Haskell best (in general, I prefer the syntax of the ML-lineage rather than the lisp lineage), and Learn You A Haskell for Great Good is a very approachable and well-conceived book to learn from (its also available for free as a website). Scala is also good, and incorporates object-oriented notions as well as running cross-platform on the JVM (which is certainly a better use for it, IMO, than running Java). I suspect Functional languages can be an excellent place to start, but that they also might require a little more structured guidance to get started -- unfortunately I lacked the perspective of a green programmer by the time I began to approach functional languages, so I can't say with certainty either way.
Another language I've been keen to look at more deeply soon is Nim (formerly Nimrod) -- which is syntactically similar to python (e.g. indentation is significant, like python and many functional languages), but its a multi-paradigm language that has some really awesome meta-programming capabilities that seem at a glance to be less complicated than in other languages. It also compiles to optimized C code (or C++, or Objective-C) which means you can write Nim code anywhere there's a C compiler, and it has a runtime (it gets built into the C output) that provides a garbage-collected heap when you want to use it (you can ignore it and manage objects explicitly, or use both approaches as appropriate in one program).
Personally, I feel that it doesn't matter. If you start programming procedurally, you will write bad procedural code. If you start programming in an OO fashion, you will write bad OO code (and probably bad procedural code too :) ). Same with functional.
When you start programming, you will suck. Same as when you start anything. and the only way to get better is to practice.
As for languages, some are easier than others, but eventually you will have to overcome the same hurdles anyway. Whether that's better done early on or later is a matter for debate.
Personally, I feel that it doesn't matter. If you start programming procedurally, you will write bad procedural code. If you start programming in an OO fashion, you will write bad OO code (and probably bad procedural code too ). Same with functional.
When you start programming, you will suck. Same as when you start anything. and the only way to get better is to practice.
That's an important point -- there's no language in which you're going to write good code in right from the start. In turn, this means your goals matter -- if your goal is to be a reasonably compenent programmer who can whip up scripts and little programs for yourself, that's a different goal than if you want to write operating systems or engines for AAA-games. Even still, either goal is pretty far removed from the absolute beginner, so it might be better to divorce the decision of which language or paradigm is best for early learning, from the decision of which language or paradigm that you want to grow into -- although the choice of the latter might influence the choice of the former.
I think you should learn everything. If you only know how to do one thing, you'll try to use it no matter how inapplicable it might be.
QFE.
It really doesn't matter what language/paradigm you start with. What matters is that you go on and learn all the rest, once you are comfortable with the first one.
When you start programming, you will suck. Same as when you start anything. and the only way to get better is to practice.
This. Noobs are noobs. Pros are pro. Practice, practice, practice.
