I am trying to self-study both object oriented design and parallel programming using the following books:
"agile software development" by Robert C. Martin
Bruce Eckel's "Thinking in Patterns with Java"
"The Art of Multiprocessor Programming" Maurice Herlihy
"Programming Massively Parallel Processors" by David B. Kirk
But to practice I need to work on some project. Can you please help me finding a project where I can practice both these skills. I am looking for a project which involves both working with design patterns (and basic OOP principles) but also some heavy parallelizable algorithms.
Writing a server is a good real-world test of parallel programming skills.
Here is a step-by-step tutorial on the subject.
Related
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.
Can you please suggest a book for studying objected oriented approaches and programming.
http://headfirstlabs.com/books/hfooad/
This is the bible of OOP:
http://en.wikipedia.org/wiki/Design_Patterns
You can find a hard copy on the Amazon but if you Google you should be able to find an html version on the net somewhere.
Here are few links I found for supporting your cause. Hope these might help you -
http://oad.humansize.com/
http://www.itmweb.com/essay554.htm
http://cplus.about.com/od/learnc/ss/csharpclasses.htm
The standard work on object oriented design is Larman:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development
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.
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