Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
As I try to increase my knowledge of functional programming, I'm finding it quite difficult to re-imagine the solutions to problems I've solved in an OOP language in terms of functions, particularly where widgets are involved. Sites like Project Euler and 4Clojure are great for learning core functions and techniques for manipulating primitive data, but what I'd really like is a resource that discusses how to idiomatically translate OOP constructs into FP, with particular attention to identifying when and how to use state. (To use a concrete example, what is the best way to implement a piano keyboard in Clojure?)
what I'd really like is a resource that discusses how to idiomatically translate OOP constructs into FP
Don't. That's a classic XY problem.
I hate analogies but an equivalent in engineering might be to say that you've mastered metalwork and want to learn plastics by recreating the same shapes in plastic. In reality, you never want to translate what you know into what you're learning. What you really want to do is learn how to solve familiar problems using new techniques. Going back to engineering, good plastic designs are not the same shape as good metal designs. In terms of programming, solutions build using one paradigm never translate well to another. You should re-solve the problems from scratch.
I know two books that might help:
"Functional Programming for the Object-Oriented Programmer" by Brian Marick.
"Clojure Programming" by Chas Emerick, Brian Carper and Chirstophe Grand. Chapter 12 is about how to "translate" Object-Oriented Design Patterns to Clojure.
I'm not aware of any book that will teach us how to translate OOP constructs into Functional ones. Just give yourself some time and you will grasp the functional idioms.
Don't try to map between OOP code and FP code. The best way to learn a language (spoken language) is to immerse yourself in it and think of it. The same goes for programming languages.
Three years ago I started learning Clojure. At that time, I don't even know what is Lisp and what are functional programming languages. I said: Huh? really what is that? Can I do something useful with Lisp? I read a lot, studied a lot and even better, I got a job in Clojure!
Now programming in functional languages feels natural to me, it makes sense. Programming in data structures and functions are all of what I need. Simplicity!
One thing to keep in mind that functional programming languages aren't difficult by default and OOP languages aren't easy by default.
I've not read this book, but it sounds like quite a good fit for what you're looking for (and I'm very happy with the other Pragmatic Bookshelf books I've read)
Functional Programming Patterns In Scala And Clojure
From the blurb:
By using both the statically typed, type-inferred Scala and the dynamically typed, modern Lisp Clojure, you’ll gain a broad understanding of functional programming.
For each pattern, you’ll first see the traditional object-oriented solution, and then dig into the functional replacements in both Scala and Clojure.
Re: your piano question, you might find core.async and David Nolen's blog posts on UI design with core.async (specifically http://swannodette.github.io/2013/07/31/extracting-processes/) interesting.
In the blog post, he proposes that a user interface (and by extension, a piano), consists of 3 elements - event stream processing, event stream co-ordination and interface representation. And he shows that these are a much more powerful abstraction than the typical OOP Model View Controller. All pretty new though (I don't think core.async is even officially released yet). But if you're looking for the idiomatic Clojure way to model a piano, I think that it may well be along those lines...
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
As the title says, what's the appeal of LISP?
I've seen it raised to high heavens and back and then put on a pedestal over an over. I've seen it done by by people here, by actual programmers that I know, by university professors that try to look like the kind of enlightened guys who have obviously transcended the plebeian language-war and would rather die than commit the heresy of saying that one language is better than another.
I tried to learn it, I looked at a few tutorials, at the "learn x in y minutes" page for both lisp and clojure(since from what I understand it's lisp running on the jvm with more FP thrown in), and I understand the syntax and how to do stuff in it. And I went back to tutorials about it several times over the last few months but every time the syntax made me want to look for a high-school kid and yell at him for messy code because looks like a C-style if-condition gone wild with all the nested parentheses and simple things seem to become a chore. What lisp seems to do in a few lines, other FP languages like Haskell or F# or even non FP languages like C# who just discovered that map and filter are a thing seem to do in much less in a much more expressive way.
Am I looking at this wrong?
Is there some click that needs to happen?
Did I only find crappy resources?(if yes please give me some good resources for learning lisp/clojure, preferably with some exercises)
What in the ... is the appeal of lisp? Honest to God question here.
Thank you in advance!
When I first heard about Clojure in 2009, I wrote a blog post titled "Clojure: Where's the Elegance?" I was a big fan of Python's style of elegance at the time ("executable pseudo-code"), and Lisp was deeply unfamiliar. I continued wrestling with Clojure, though, because "list processing" seemed like an important programming paradigm to have in my toolset. I used a lot of JavaScript, Ruby, and C# for a while, and on my own time played with ClojureScript. When I finally came back to Python in 2017 to do some data-munging, I discovered I was writing a lot of Clojure-inspired functions to help. Finally, I just started writing the data-processing in Clojure, and I wouldn't go back. So while you've asked a question that may not be answerable, perhaps I can shed some light on what accounts for the difference between your perspective and the enthusiasm of the Lisp community.
First, while Lisp is very alien coming from the rich grammars of C, Python, and Ruby, the lightness of Lisp's syntax turns out to be a tremendous blessing. It relieves a lot of cognitive burden. Many kinds of syntax errors completely disappear. But by far the most good I get out of Lisp's consistent grammar is how easily it can be transformed. What I miss most when working in other languages is the ability to rearrange the AST without having to fiddle with the actual text of the code. Working with Lisp is far more fluid than any other language I've experienced.
Second, it's trivial to control how code is evaluated. A lot has been written about the glory of macros, but to me the fundamental superpower is that you can prevent code from being evaluated, evaluate it in a specific order, or evaluate it multiple times, all without the syntactic overhead of wrapping that code in a function. That said, I don't write macros very much, but when I do, a function is a poor substitute.
Third, most languages don't have very good support for live coding. I typically don't use the REPL itself, but rely on an editor integration to evaluate code. Clojure's tooling is good enough that I can mold an entire codebase with dozens of namespaces without ever having to restart the JVM process or split a single big code file into separate modules.
Fourth, Lisp code tends to compose extremely well. Between everything being an expression that returns a value and the language being built on a relatively small set of data structures, you can mix and match language constructs with great liberty. That opens up a lot of possibilities where other languages put up walls.
The common factor of all these is that the language does its best to get out of your way. When I was a novice programmer, the complex grammars of C and Python and Ruby was an aid to programming. It kept me on the straight and narrow. The language constructs were like landmarks to navigate by. Lisp, without those landmarks, can feel like a foreign country. But as you get more familiar with Lisp, other languages feel artificially constraining and hard to move around in, like driving on roads when you could be flying. Lisp is very freeing, but from my personal experience, I can tell you that, like flying, it takes practice before the strangeness of it turns from fear to freedom.
I have started experimenting with Clojure, and I am impressed by what it can do. However, I don't think I have really 'got' functional programming design. My background is in Smalltalk, and that colours how I think about design. I would like to really understand how FP differs from OO, and one approach would be to have a good side-by-side comparison of a solution.
I don't think the problem needs to be that complex. Maybe it is would be enough to show how FP would implement the typical bank account problem?
Does anyone know of a suitable resource?
I think that most books on Clojure will have something like a simple bank account program, which I view as a little database in which states get updated. For example, Halloway and Bedra's Programming Clojure has a program that keeps track of music recordings. When you read through a description of that program, you'll immediately see how to map it into an OO solution. However, I don't think you're going to "get" FP from such a simple example. Programming Clojure also has functional snake game. You could compare that to an OO snake game. (I'm not promoting Programming Clojure; it's a worthwhile book but I think it has a number of flaws. It just happens to be the Clojure book that I know best. A lot of people seem to like it, though.)
I'd suggest another strategy, maybe as a supplement to yours, for grokking FP: Read something introductory that immerses you in an FP worldview. My favorite is Friedman and Felleisen's The Little Schemer. It uses Scheme, not Clojure, but the ideas translate. There is a Clojure website devoted to it, but I recommend working through the original book in the way that it recommends, covering parts of the page as you go. I think the book that gave me an understanding of parts of FP that go beyond The Little Schemer, extending to much of what you find in the Clojure world, was Bird's Introduction to Functional Programming using Haskell. I feel funny suggesting a Haskell book, though. Why not a Clojure book? Well, maybe one of the Clojure books will have the same effect of giving you a pure baptism in the FP Way of Thinking, but the Clojure books I've read (P.C, The Joy of Clojure), though very good books, are somehow less immersive--maybe because they're more practical. On the other hand, P.C (and probably some other Clojure books) is (are) largely targeted toward OO programmers, so that might actually be what you want.
A few random observations on Clojure from a Smalltalker's perspective.
The Clojure data structures will remind you of Smalltalk's collection classes, but immutability/persistence takes a bit of getting used to.
You already use do and its relatives to abbreviate control structure. You'll find that the sequence library (map, reduce, and the rest), with laziness offer you another level of power and concision.
You're already used to writing your code in little pieces. The pieces will get smaller and there will be more of them.
But
Clojure is less pure than Smalltalk: not everything is an object.
Nothing like the wonderful Smalltalk browser is standard.
If you like Smalltalk, you'll love Clojure.
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 3 years ago.
Improve this question
I plan to pick up the clojure language.
I have at my disposal an old book:
The Little Lisper
I know there are more recent versions of it (The Little Schemer) but I'm wondering if it will help ease me into picking up Clojure. Or should I find other learning resource ?
stop eating snacks for big meals. they are food to get between meals... :D
meaning, if you want clojure, go for that :
go to rubylearning and register for a clojure online course
get one of the books on clojure (the joy of clojure, clojure in action or programming clojure)
read through this quite comprehensive article at heroku : Clojure - Functional Programming for the JVM
register for feeds on clojure by registering at planet clojure
as for that book, i think that's like food for thought, when you want more insight into functional programmming
Having read "The Little Schemer" recently, yes, I definitely think you will get a lot from reading the book. What it teaches you is the recursive style of programming which is very prevalent in the Lisp world. The beauty of Lists is that it satisfies the closure property (not the Closure, the programming language concept, but Closure as in Mathematics where an operation on two elements from a set produces another unique element of the same set). The book teaches you all these advanced concepts without naming them and much more (for example, chapter 9 talks about Y Combinator, one of the most beautiful concepts in the Programming-Language/Logic theory).
I would suggest you to read it by all means, whether you learn Scheme or Clojure or any language.
There are more direct ways of easing yourself into Clojure and Clojure emphasized things like lazy sequences instead of recursion. When reading the little lisper be aware that Clojure has no tail recursion and does not really require it, so some of the recursive patterns in the book wont always work.
It may be more useful to start with clojure and then use the lisp literature to expand your view of the world once you have your foundations in place.
If you are looking to learn more about advanced lisp programming I would suggest On Lisp by Paul Graham. The tag line for the book is learning to write the kind of programs you could only write in lisp.
ps: it's free :)
It will help you with every language and yes you get a feel of lisp witch will help you when you pick up Clojure. You could do the examples and then try to rewrite them in Clojure.
If you're confused by recursion, read The Little Schemer, i.e. The Little Lisper--either one.
When I was first learning Lisp, my textbooks dealt with recursion, and I kind of got it, but nothing sunk in. No real understanding. Recursion has been second nature ever since I read The Little Lisper, though. It's not a Clojure book, but it teaches basic concepts of functional programming. Everything you learn from The Little Schemer will be useful, or at least fun.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
HI all.
I have started a new job recently where I am supposed to work with C++/ I have been doing programming in C language for past 5 years. I am looking for ways to get me up to an acceptable level in OOP. I have all the basic concepts of C++ and OOP but don't have much experience of actual class designing.
What I really am looking for is ways to learn class library designing as I will be working in a team who is writing C++ libraries for other programmers to use. Please suggest principles like "responsibility assignment" which can help me design classes in general.
Give a loook to Bob Martin SOLID principles:
SRP The Single Responsibility Principle: A class should have one,
and only one, reason to change.
OCP The Open Closed Principle: You should be able to extend a classes
behavior, without modifying it.
LSP The Liskov Substitution Principle: Derived classes must be
substitutable for their base classes.
ISP The Interface Segregation Principle: Make fine grained
interfaces that are client specific.
DIP The Dependency Inversion Principle: Depend on abstractions, not
on concretions.
I know this isn't the type of answer you've been looking for; it's more like a extension of the other answers (already done and yet to come). I thought I'd add some general stuff...
Write one class declaration per .hpp file, one class definition per .cpp file. Name files like the class they contain. (It's surprising and frustrating to find how much code doesn't get this basic rule right.)
Be aware that C++ is a multi-paradigm language. Some things are better solved without a class hierachy. (Some things call for templates, some things are best done in good old procedural style.)
Learn about the Boost libraries, and how they do things. They're a good showcase of well-done C++, especially on the user interface side. And they are useful in your everyday work, too.
Read "Effective C++", "More Effective C++" and "Effective STL" by Scott Meyers. If in doubt, just get the first, and you'll find out why you should read the other two yourself.
Couldn't resist giving these basics, seeing a newcomer to the language that actually asks for advice before getting into lots of bad habits. ;-)
There are a number of posts here on SO dealing with this, for instance:
What is the best source to learn C++?
A good C++ book
In general, Scott Meyers books are a good place to start.
Books by Andrei Alexandrescu are also very good.
I still like Bjarne Stroustrup's book. It has several chapters devoted to design and it's also a great language reference. It can be pretty dense reading at times, but it's worth the effort.
I found C++ to be a great tool, but only after I really learned how to use it. Read all the references suggested here by others, and there's no substitute for practice!
The SOLID principles are good guides, but don't forget that you have to have concrete use cases if you are going to be able to do good OOD. If you are designing a class (for other programmers) to inherit from, you need at least three concrete (and as different/realistic as possible) cases where you actually inherit from the class, or you will not be able to see how the classes should work.
Try designing everything in UML before you code using proper sequence of diagrams down to class and sequence. Despite all (rightly) criticisms of UML, it will force you to treat program as a system of interacting objects and not sequence of code.
Most of "principles of OOP" are easily reduced to absurdity if you try to design program following them exactly. Refactoring is another story.
Otherwise, make sure you really know C++ and STL. Good or bad, STL is what is expected in C++ code.
Designing C++ class hierarchies for others to use is a minefield. I would highly recommend reading up on some of the common pitfalls in class design. Two books I suggest:
C++ Coding Standards (Herb Sutter & Andrei Alexandrescu). Packed full of concrete examples of how to create proper classes in an easy to understand way.
Effective C++ (Scott Mayers). How to write correct C++, starting from the transition from C to C++. A classic.
Refer this link. This pdf consists of "Design Principles and
Design Patterns"
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
The above link will help u a lot.
Depending on how STL oriented your new job is, you'll either get praised, or shot, for reading: Modern C++ Design by Alexandrescu.
Even if you don't use any of the patterns in it, it will open a new world of C++ to you.
I'd put that book second on your reading list, after some Meyers books. Alexandrescu is pretty... intense.
It takes a few years to become proficient in C++. The books that have been suggested will help. I also suggest that you read Herb Sutter's Exceptional C++ series.
For the short term, you should find a C++ mentor to help you get up to speed in the new company. Each company has its own "culture" around C++. Dos and don'ts. This may be more relevant to your job than what you read. For example, your company may not use STL, so learning it may turn out be just an academic exercise. Many companies practice "Cargo Cult" programming - in this case, avoiding powerful but scary features of the language - so you may find you're frustrated that you can't use what you learn from the books.
It's hard for me to imagine trying to learn a language as complex as C++ just for the job. Reading all those books and practicing takes time. You can learn what you need for the job, and make a useful contribution. I think you have to love it to become proficient.
You should read Tony Albrecht's Pitfalls of Object Oriented Programming.
I recently started working with C++ too, and this is what I did:
First, I got the book C++ In Action from a coworker, and went through its 'Language' part, doing all the exercises. The 'Techniques' chapter is also an important one.
Then, the thing that helped me the most, I think, is reading a lot of my team's already written code and trying to understand the reason for everything in it. If your team members know how to code well, this is quite educating. And anyway, it definitely helps you understand the purpose and methods of your project, and what's expected of you.
Reading part the project's code might be something you'd have to do anyway, I believe (in order to use library functions, implement similar functions, or add to existing code), but sometimes people skip that part or do it very superficially.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm something of a new, reluctant convert to C++ from a Pascal, Ruby, and PHP background. I haven't worked with Pascal since a few months of torture with "Delphi Turbo;" since then I've practically been eating and sleeping Ruby and PHP. I'm already well acquainted with object oriented programming and many various subjects.
My main trouble is that I already know the rudiments of C/C++ programming, less the actual experience of working with C++. I worked with C for long enough to realize that even without macros, etc, I didn't want to work with it. (Some of the disgust was from maintaining a CGI application in C, when accustomed to Pascal's automatic string management.) I know just enough C++ to be dangerous to myself and anyone else unwitting enough to use my "code."
I'd really like to work up to a good enough understanding of C++ to use libraries like Crypto++ and Boost without major problems or in-depth knowledge of the language's intricacies. I just need to figure out how to work with C++ without killing myself (either with C++, or with the long-standing dislike that I'm already battling).
What are effective resources that will teach me C++ without assuming that I must be retaught all basic programming? I'd rather not relearn concepts that I already know, unless the paradigm in C++ is significantly different. I'm also learning on my own time, so don't recommend me a book complex enough to need a guru to explain to me, please! And I have an effective budget of $0 for learning C++, so please keep suggestions to quality online resources or books common enough that I could likely find them at the library.
Read Effective C++ by Scott Meyers - it's a good guide for getting past the basics of C++ and showing how to write and use "correct" C++ code
The C++ FAQ Lite is a great resource.
I highly recommend Stroustrup: The C++ Programming Language (Third Edition). As the author of C++ he is the authority on the language, and the book is useful as a reference as much as it is for learning the language. It's common enough that most good general purpose libraries will have a copy. He goes into quite some depth on all the features of C++, including explanations of why certain design decisions were made in the language. Personally, I think this is the best book around for programmers to learn C++.
Once you have a good grip on core C++, David Abrahams and Aleksey Gurtovoy's book, C++ Template Metaprogramming, goes into further depth and provides many examples of how C++'s template system allows you to perform complex compile-time programming, a highly valuable skill these days. This one is a little less common but you can probably find it at a university library.
I can give you a couple of keywords you might want to research in more detail:
RAII (Is pretty much the technique that ensures you don't have to worry about memory leaks. Very convenient)
Generic Programming (The STL in particular. Experiment with iterators and the standard library algorithms, and see just how powerful these abstractions are. They're a key part of what I like about C++)
Functors (Perhaps too simple on their own, but the way they can be used instead of function pointers with the algorithms mentioned above is interesting)
And just get familiar with templates, and "mild" forms of template metaprogramming. (Traits classes, for example, and (partial) specializations.
And just keep an eye on the C++ questions here on SO. A lot of interesting topics are regularly brought up.
But the best advice is probably to keep it completely separate from C. Forget everything you learned about how to use C. It either doesn't apply in C++, or leads to inferior code that is harder to read and maintain.
It's an interesting language in its own right, and has a number of unique features. Leverage those, and it can actually be fun to work with C++. Treat it as an overengineered Java, PHP or C, and it'll just make you want to throw up.
You need to write code. A lot of code in C++. There is no substitute. You also need to read good code.
I agree with the suggestion for Scott Meyers' books though. Those are pretty good.
Part of your learning will be the leap from procedural programming to OO.
I would highly recommend the book "C++ Common Knowledge" by Stephen C. Dewhurst. Don't know if it's common enough to be found at the library (it's not at mine, but my library sucks for computer books that aren't 5-10 years out of date), but it does an excellent job of taking the complex aspects of C++ and making them easy to understand, without dumbing anything down for beginners. Definitely worth the investment.
To quote from the back of the book:
This book is for you if
You're no "dummy," and you need to get quickly up to speed in intermediate to advanced C++
You've had some experience in C++ programming, but reading intermediate and advanced C++ books is slow-going
You've had an introductory C++ course, but you've found that you still can't follow your colleagues when they're describing their C++ designs and code
You're an experienced C or Java programmer, but you don't yet have the experience to develop nuanced C++ code and designs
You're a C++ expert, and you're looking for an alternative to answering the same questions from your less-experienced colleagues over and over again
C++ Common Knowledge covers essential
but commonly misunderstood topics in
C++ programming and design while
filtering out needless complexity in
the discussion of each topic. What
remains is a clear distillation of the
essentials required for production C++
programming, presented in the author's
trademark incisive, engaging style.
Here is a link to a question with answers that should help you.
https://stackoverflow.com/questions/1227764/i-need-to-improve-my-c-skills-fast-is-this-realistically-possible/1227805#1227805
For effective stuff you can find online Cplusplus.com has a pretty good reference and information.
If you can find the book "C++ Common Knowledge" (Stephen Dewhurst) at the library or cheaply online, I would add that to the list posted on the StackOverflow link above as well as "The C++ Programming Language" (Stroustrup). Going through the questions under the C++ tag right here on SO should give you some good pointers and code examples to get you on your way.
Here's a list of good C++ books which teach you C++ rather than basics of programming.
Sit down and write some C++ code.