i've been programming for a while, but have never had a formal computer science education. i would like to know if there is a resource that goes over the key programming concepts like construct, polymorphism etc, that would be applicable to different languages. also it would be highly helpful if the resource would give examples.
Concepts, Techniques, and Models of Computer Programming (by Peter Van Roy and Seif Haridi): the title says it all. (From the same author and based on the book comes this cool poster with ~30 of the most important programming paradigms.) [Note: this book is colloquially known as CTM, you might stumble across that acronym from time to time.]
Structure and Intepretation of Computer Programs (by Harold Abelson and Gerald Jay Sussman). SICP, as it is colloquially known, is probably the book about programming. Period. Don't forget the 1986 video lectures by the authors themselves or one of the other courses based on the book.
The main difference between SICP and CTM is the approach: CTM teaches programming concepts by giving examples in a very powerful programming language (Distributed Oz) that already implements them, while SICP teaches programming concepts by implementing them in a language (Scheme, or rather a small subset of it) which doesn't already have them. IOW: CTM would teach OO be showing programs written in an OO language, SICP by implementing an OO system in Scheme.
Design Concepts in Programming Languages (by Franklyn A. Turbak and David K. Gifford with Mark A. Sheldon) is more about Programming Language Theory than Programming. It's still pretty interesting, even though it doesn't directly address your question about Programming Concepts. But after all: how would you program without a programming language?
Concepts of Programming Languages (by Robert W. Sebesta) explains, well, Concepts of Programming Languages, starting with Konrad Zuse's Plankalkül, continuing with the first real programming languages like Fortran, Lisp, Cobol, Algol, BASIC and on to C, C++, Java and Ada. [Again, more of a Programming Language book than Programming.]
Programming Language Pragmatics is a pretty accessible but in depth overview of programming language concepts. It does a good job of explaining programming language fundamentals without being overly academic or theoretical.
I really enjoyed reading Concepts in Programming Languages by John C. Mitchell.
The book covers a little bit of everything. It includes an introduction to mathematical foundations such as computability theory and lambda calculus, but I found it quite readable (at the time when I was reading it, which was early during my undergraduate studies). It also includes a tiny bit on the semantics of programming languages (that is, how to describe the meaning formally).
Then it talks about many programming languages and concepts that come from them and are interesting including LISP (which is a basis for Clojure), ML (a basis for Microsoft's F#) but also Simula and Smalltalk (two fundamental OO languages) and C++ with Java (practical OO languages with quite different approach). There are also a few notes about different approaches to concurrency (quite important nowadays!)
It doesn't go into much details and covers wide range of topics, which I consider as a benefit if you want to read it to get a broad overview of the programming language theory. The book actually motivated my current interest in programming languages :-).
I noticed that the book has some negative reviews on Amazon, but it seems like most of them are from people who had to take Mitchell's course based on the book and didn't like the course.
Related
Are all design patterns described in GOF programming language independent? By programming language I mean any OO language.
I see people talking about PHP design patterns, C++ design patterns and so on. I guess by prefixing the programming language they specifically mean about the design patterns applicable for that specific language by making use of features unique to that specific language.
This made me wonder about the GOF patterns. Do all patterns in the book guaranteed to be applicable in any OO language? In other words, if I master the design patterns in GOF book using Java, and then if I had to use another OO language, Can I still implement all those patterns?
Yes, they're supposed to be prose descriptions for common object-oriented programming problems. They don't depend on any language.
The proof is that the examples in the book that came out in 1995 were in C++ and Smalltalk, the two leading object-oriented languages of the day. They've since been translated and adapted by Java and C#, two languages that didn't even exist when the book was first published.
"Guaranteed" is too strong a word.
The one thing you want to avoid is "small boy with a hammer" syndrome. It happens to everyone after reading that book for the first time: they run around looking for ways to implement patterns whether they fit or not.
You should aim to write the clearest, DRYest, most readable code you can. Don't worry about patterns.
I've read that functional programmers scoff at the design patterns, saying that they are band-aids on defects in object oriented programming that don't exist in other languages. I'm not a good enough functional programmer to know if this is true.
I'm thoroughly intrigued by Scheme, and have started with some toy programming examples, and am reading through Paul Graham's On Lisp.
One thing I haven't been able to find is a book or website intended to teach Scheme to "OO people", i.e. people like myself who've done 99 % of their coding in c++/Java/Python.
I see that closures are sort of object-y, in the sense that they have local state, and offer one or more functions that have access to that state. But I don't want to learn Scheme only to port my existing habits on to it. This is why I'm learning Scheme rather than Common Lisp at the moment; I fear that CLOS might just serve as a crutch to my existing OO habits.
What would be ideal is a book or website that offers case studies of problems solved in both an OO language, and also in Scheme in a Schemey way. I suppose I would most appreciate scientific computing and/or computer graphics problems, but anything would do.
Any pedagogical leads would be much appreciated.
I doubt CLOS would serve as a crutch for old habits, I found it to be pretty different from the OO style in C++/Java/Python, and very interesting. I don't understand all the details, but I would recommend Peter Seibel's Practical Common Lisp. If you are reading On Lisp without much trouble, you should be able to dive into the chapters introducing CLOS in PCL. Also, I'd recommend his Google Tech Talk comparing Java and Common Lisp.
Here's a few more recommendations to make this a more full-fledged answer:
The classic text Structure and Interpretation of Computer Programs covers quite a few examples in chapter 3 of building modular systems using closures (and addresses issues with introducing state and mutability). Chapter 2 includes some generic and data/type-directed programming which could be helpful for motivating study of CLOS. This book really needs no introduction though, it's a towering work, and I've only been reading it slowly since the spring. Highly recommended if you are interested in Scheme.
While SICP is a great book, it's not without its flaws: A really interesting look at these is the essay "The Structure and Interpretation of the Computer Science Curriculum" which elaborates on a few criticism of SICP, and is written by the authors of How to Design Programs (I haven't read HTDP but I hear it's very good). While this essay won't teach you specifically what you are looking for - comparing functional and OO programming - it is really interesting anyway. Their freshman undergraduate course starts with a first semester introduction to functional programming using Scheme (I think, PLT/Racket) and is followed by a semester of OO programming with C++ or Java... at least that's the course they describe in the essay.
These slides from Peter Norvig address some of the design patterns common in OO programming and show why they are missing or unnecessary in dynamic, functional languages like Scheme and Lisp: http://norvig.com/design-patterns/
I cautiously recommend the book by the same authors as the Little Schemer books: A Little Java, A Few Patterns. I can't say for sure if this is a really a good book or not, it was incredibly strange and there are some really bad typesetting decisions (italic, serif, variable-width, superscript doesn't belong in a text on programming), but it might be interesting to take a look at. You can probably find it cheap, anyway. Don't take this recommendation that seriously. I think it would be better to stick to the Scheme texts.
p.s. I have to disagree with one comment stating that functional programming is not as complicated at OO programming, I think that's grossly misstating it. Functional programming in all its breadth is truly mind-boggling. When you go beyond map/filter/reduce and first-class functions, and take a look at other things in the functional realm like lazy evaluation, avoiding side effects and mutation, and the strong, static-typed languages, it gets pretty interesting, and is certainly just as complicated as traditional OO programming. I've only just scratched the surface myself but have discovered a great deal of new ideas. Programming is complicated business, whether OO or functional.
Congrat you, my friend ! Love cs, love functional programming.
If you are python developer it takes 3-4 days to think in scheme
Here is the best simple tutorial I have ever met http://www.shido.info/lisp/idx_scm_e.html
I found this course http://cs.gettysburg.edu/~tneller/cs341/scheme-intro/index.html and it may be useful for you
One beginner's resource that is very helpful and geared very much toward the casual reader is "The Adventures of a Pythonista in Schemeland". It's written (obviously) from the point of view of a Python programmer taking first steps with Scheme. One especially nice thing about it is that it includes an overview of the current implementations and compatibility issues between each scheme implementation, which, unfortunately, can cause some headaches when you're just starting out.
With regards to object systems, these two documents (linked from here) give nice examples of very simple toy implementations using closures that I found helpful in understanding their use in capturing state.
If you are starting off with Scheme, have a look at How to Design Programs. This book presents the "Schemey" approach to problem solving. I don't think there is a book that compares OO and functional solutions to the same programming problems. But there is a nice presentation that shows how dynamic languages like Scheme could provide simple solutions to problems that demand complex design patterns in statically typed OOP languages.
OOP is probably the most used programming paradigm in today’s software design. My question is – what other paradigm(s) can compete with it and can stand in the place of OOP? To clarify that question, I’m not asking about what other paradigms there are. There are many of them, but I’d like to know which one…
Has been used in practice, not only in theory.
Can compete with OOP, so it can be used in a large project with a minimum of pain.
Can be used to develop a desktop app with business logic, databases, and so on.
Is not used alongside OOP, but as a replacement for OOP.
And if there is any, what are the pros/cons of it, why it is better/worse than OOP, what languages are the best to use it, what about using it in popular languages, has it any design patterns, and can it totally replace OOP?
Functional programming is another programming paradigm that is popular, mostly in academics. The best example of a functional programming language is Haskell and Standard ML.
The fundamental difference between functional programming and object oriented programming is that you are programming in the sense of data flow instead of control flow. See the presentation Taming Effects with Functional Programming by Simon Peyton-Jones for a good introduction.
A good example of functional programming used in the industry is Erlang. It is mostly used in telecommunication, distributed and fault tolerant systems. See the presentation Erlang - Software for a concurrent World by Joe Armstrong.
There are also newer functional programming languages that combine functional programming with OOP. Two good examples are F# for the .NET platform and Scala for the Java platform; they can often use existing libraries on the platform written in other languages.
The trend of new programming languages now is Multi-paradigm, where multiple paradigms like object oriented programming and functional programming are combined in the same language.
Procedural processing was everything before OOP turned up, has produced some large real world applications (in fact, most of them originally) and many operating systems.
It can certainly be used in large scale products with a minimum of pain, and a maximum of performance
First of all please note that many of the programming languages currently in use (especially "higher level languages") are multi-paradigm. That means you are never building programs which are purely OOP (except if you use Smalltalk or Eiffel to build your big projects maybe).
Have a look at PHP for instance:
Has many elements of OOP (since version 5)
Was mostly procedural before
Has elements of declarative programming (e.g. the array functions)
Implemented many elements of functional programming (since version 5.4)
Basically PHP is gluing a lot of different paradigms together (and is a "glue language" itself).
Also Java implements a lot of concepts which are not from the Object-Oriented paradigm (e.g. from functional programming).
Have a look on the list of programming languages by type in Wikipedia: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Imperative_languages (not 100% accurate).
Functional programming (subset of declerative programming)
Wideley used in practice (it became part of glued languages like PHP, also Java and many others have implemented concepts of functional programming)
Many ideas originate in LISP which is definitely worth a look
You can build whole applications e.g. with Haskell therefore it can "replace" OOP
Procedural programming
C (as a mostly procedural language) is still one of the most widely used languages
Many modern glue-languages were procedural in the beginning
Still many programs are mostly procedural (so if you want it can "replace" OOP)
Logical programming
Most prominent example is Prolog. This is used for specific tasks that benefit from rule-based logical queries
Can not "replace" OOP in terms of building a large project but may replace it in other terms
Declarative / Domain-specific languages in general
Using SQL in your projects? Then they are not purely OOP, SQL is essentially declarative.
Many domain-specific languages (like CSS) are declarative
Imperative programming in general
Tons of applications are not "object-oriented" but simply written in imperative style (e.g. assembly)
Look here for a great thread: https://softwareengineering.stackexchange.com/questions/117092/whats-the-difference-between-imperative-procedural-and-structured-programming
This list is not complete it shall just give an idea. Just note that you usually are using a lot of different paradigms when writing a big application and even each language you are using is implementing multiple paradigms.
OOP is usually considered a good choice for structuring large, complex relationships when modelling data. It is not always the paradigm to go with for many other tasks.
Vector Relational Data Modeling is used to create executable information models with domain relevant semantics within the Global Information Network Architecture, a network resident model broker.
FP - Functional Programming is an extremely popular programming paradigm that has been around for a very long time and has, in more recent years, started becoming more and more prominent. FP favors immutability over mutability, recursion, and functions with no side effects. Some examples of popular fp languages are Erlang, Scala, F#, Haskell and Lisp (among others).
There are no paradigms currently that can genuinely replace OOP. The issue with (benefit of) OOP is that it does a vast amount of work for you- automatically releasing resources, validating data, etc, and it makes it easy to validate code- not to mention that the vast majority of the world's existing libraries are written in an OOP language like C++, C# or Java. The reality of getting along without such large-scale libraries and such is exceedingly doubtful.
In niche or academic worlds, you'll find a lot of Functional Programming. However, if you really want to do a large project, OOP is the only way to go.
I think that generic programming is going to come up as a new paradigm. However, it's really still in the development phase and only C++/D offer genuinely good generic programming.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I want to ask you to provide me with some articles (maybe books), which you possibly have found very convincing criticising the OOP methodology.
I have read some in the WWW on this topic and I didn't really find a 'definitive demotivator'.
It's not much about my personal attitude to the OOP, but I really would like to have something constructive, rigorous foundation for any kind of discussion and just abstract thinking.
You can post some original research too, but please be very constructive (as my personal request).
Which version of OOP? Alan Kay's original vision? The bastardized modern form of it that misses the point entirely and thus encumbers us with bizarre access control, member variables, etc? Inheritance-centric? Prototype-based? Compositional OOP?
Each form of OOP has its strengths and its weaknesses; its advocates and its detractors; its domains of utility and its domains of uselessness. There's nothing magical about OOP that makes it the Killer Paradigm and there's nothing infernal about it that makes it the Killer (of Programmers) Paradigm.
I can't really point you to any books or articles that killed my interest in OOP as a Silver Bullet (as opposed to one of many techniques I can use to keep my projects survivable). I can point to the funniest critique of a specific brand of OOP, however: Steve Yegge's classic "Execution in the Kingdom of Nouns".
Rick Hickey's Are We There Yet ? - A Deconstruction of Object Oriented Time was an eye opener for me. It's the most logical OO criticism I have come across.
If you want a criticism of OO programming, here's what I'd recommend:
Learn Smalltalk
Learn Erlang
Learn Scheme
Once you've done that, you will have plenty of criticism of the common interpretation of OO programming.
(Hint: OO was in many ways intended to more closely resemble the Actor model of computation, but the common interpretation of it is effectively a modification of the procedural/structured model)
Problem is - most people don't really know Object-Oriented Programming, so many designs SUCK.
Read the works of Scott Ambler, including his (now pretty old) Building Object Applications That Work. This has been eye-opening for quite a lot of people.
Maybe not quite what you were looking for but have a look at the Jan/Feb issue of IEEE Software magazine: Object-Oriented Analysis: Is It Just Theory?. The basic conclusion is that OOA does not provide a good cost/benefit ratio so is poorly utilized.
Given that OOA is not effectively utililzed or supported in the "real world", I suspect that for larger development projects the overall system architecture, deployed object model and class hiearchy end up being sub-optimal and poorly understood (implemented) by various parts of the development team. A second article in the same journal: Four Trends Leading to Java Runtime Bloat point to some common OOP issues that detract from deploying high-volume Java (OOP) systems. The observations made in this article probably apply to most highly architected OOP applications.
Do not take this as OO bashing, it just reflects that as software practictioners we have quite a bit of work to do toward developing better person-to-person communication mechanisms to convey highly complex and abstracted process models.
When you define a process in natural language. You use sentences where you define the subject who will do an action on one or more objects.
The only fix point is the action, the predicate of the sentence.
I don't think assigning actions to objects is a good idea.
There is only one verb, but can be multiple nouns.
In OOP you can write a file in at least 3 ways:
file.write(data);
or
data.writeToFile(file);
or
OperatingSystem.write(file, data);
Which object should implement the method? You need to think about this too.
While in the procedural way, you probably write
write(file, data);
And the only thing you need to think is the order of the operands which is usally does not matter.
(Well file and data may not be the best example but you probably see the point)
You should really see Mr. B. Jacobs's:
OOP Myths Debunked
(also known as OOP Oversold.)
http://cat-v.org has a great page on Object Oriented Programming.
Most of the page consists of humorous but not terribly informative quotes. However, at the bottom of the page are a number of links to articles challenging OOP. They are:
Bad Engineering Properties of Object-Oriented Languages by Luca Cardelli.
Why OO Sucks by Joe Armstrong
Pitfalls of Object Oriented Programming – By Tony Albrecht of Sony Computer Entertainment Europe, Research & Development Division.
Object-Oriented Considered Harmful by Frans Faase.
Object Oriented Programming Oversold!
I Hate Patterns – By Parand Tony Darugar.
Why arc Isn’t Particularly Object-Oriented – By Paul Graham.
The questions about inheritance in the Java IAQ.
Stop Writing Classes – Great talk about how classes are often used and abused. By Jack Diederich.
If you are interested in alternatives to Object-Oriented Programming:
cat-v.org. From their 'about' page: Cat-v.org hosts a series of sites dedicated to diverse subjects that share an idiosyncratic intellectual perspective, questioning orthodoxy and fomenting elitism and high standards in topics from software design to politics, passing by art and journalism and anything else interesting.
Structure and Interpretation of Computer Programs. Specifically teaches functional programming. Available free online here, for sale here. I cannot recommend this highly enough. It is absolutely revolutionary. It will change the way you think.
Any and all writings/videos/lectures by Rob Pike and Steve Yegge. Of particular interest is Yegge's Whirlwind Languages Tour.
I'd recommend learning a different programming paradigm or reading pro arguments for specific paradigms (http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf). Besides OOP, I think the most widely used is the functional paradigm (search f.e. "Why functional programming matters"), but also have a look at the other ones. When you start looking at programming from a different perspective, the flaws of OOP start to appear automatically.
Simple exercise: define the objects IPerson, CMale and CFemale and implement the methods "sex" and "reproduce".
hows about steve yegge's execution in the kingdom of the noun
for java style OO
The Gideon Bible of object-oriented design patterns, aptly named Design Patterns. One of the best software design books I've ever read.
Is there an equivalent of DDD in FP? It seems to me that DDD is only valid in OOP paradigm.
It depends how seriously you preach the DDD gospel:
If you buy into all the details of Erik Evans's book, especially the stuff in Part II that is heavily object-oriented, than no sane person would try to duplicate that in a functional language.
If your interest is primarily in Part I of the book, that everyone on the project should have in common a language in the domain, then the leaders in the functional-programming movement have been in the area of embedded domain-specific languages. These are common currency now, but a paper by Erik Meijer and Daan Leijen at DSL'99 did a great deal to make these techniques popular. Constructing an embedded DSL is now a very popular technique in functional programming, and if you search for embedded domain specific Haskell you will find many examples.
So my answer is: the important, foundational ideas of Domain-Driven Design can be applied in a functional setting, but many of the object-oriented details are irrelevant.
Domain Specific Languages. See for example this book.
DDD eXchange 2012: Greg Young on Functional Programming with DDD
http://skillsmatter.com/podcast/design-architecture/ddd-functional-programming