12/28/2012 7:42:30 AM #
Book recommendations? Yeah, I can think of one or two... or twenty .
You've already got "Code Complete" in your list. I highly recommend two of Steve McConnell's other books. The first is "Software Estimation". Estimation is an important - dare I say critical? - skill that every developer should possess. As developers, we need to be able to accurately answer the question "When will X be finished?" It's an integral part of our job to give the correct answer and, just as important, the reason why the answer is correct. If we can't do that, we'll be handed an overly optimistic schedule composed primarily of wishful thinking, and that's never a good thing.
The second McConnell book I recommend is "Rapid Development". Although targeted more towards managers and consultants, it has a lot to offer to developers.
"Peopleware" by Tom DeMarco and Tim Lister is a good book developers can use to create a better working environment.
"The Algorithm Design Manual" by Steven S. Skiena. Half textbook/half reference. I keep my copy close at hand. It's surprising how often things like backtracing or weighted graphs crop up in everyday programming.
I think Haskell is a good starting point for learning functional programming (FP), if only for the reason that there's no other way to program in Haskell - it's functions or nothing. Kinda like being thrown in the deep end of the pool.
A great intro level book is "Learn You a Haskell for Great Good!" by Miran Lipovaca. It's available in both hard copy form and online at http://learnyouahaskell.com/chapters. Don't let the title throw you off. The book can be a little silly at times, but I never found it condescending.
Another intro book is "Programming in Haskell" by Graham Hutton. Hutton is a professor at the University of Nottingham, England, so his writing style is that of a professor teaching an Intro to Programming class (that's not a criticism; it's just the way he writes). He does a good job of taking the reader from zero knowledge of Haskell to a simple (and elegant) language parser in 183 pages.
(As an aside, Haskell really shines when it comes to writing language parsers, and anything that can be presented in a mathematical fashion.)
Finally there's "Real World Haskell" by Byran O'Sullivan, et al. Like "Learn You a Haskell", it's available in both book form and online at http://book.realworldhaskell.org/read/. It's a large book and has introductory material, but I found it lacking as an introductory text. My main objection is the authors' style of introducing a programming technique by first showing the difficult way, and then (sometimes much later in the book) showing the easier "Haskell" way. Aside from that criticism, the book is comprehensive and covers advanced topics the other two don't.
Another good language for learning functional programming is Common Lisp (CL). CL is a multi-paradigm language which supports imperative, OOP and FP. FP is the preferred mode of development, with OOP being second. Writing imperative code (i.e. global variables and destructive updates) in CL is frowned upon when it's not absolutely necessary.
The introductory text "Practical Common Lisp" by Peter Seibel is available in hard copy and online at http://www.gigamonkeys.com/book/. This book is well written and fun to read, and it shows off some of CL's more powerful features early on.
"ANSI Common Lisp" by Paul Graham is another introductory text, but he moves fast and there's precious little hand-holding. Another book by Graham, "On Lisp", is an advanced CL text that's out of print, but available for free as a .pdf at http://www.paulgraham.com/onlisp.html.
A great CL book that I feel the need to mention is Peter Norvig's "Paradigms of Artificial Intelligence Programming". It has some good introductory chapters on CL before jumping into the AI topics. I use the word "great" because Norvig presents the thorny combination of CL and AI in a clear and understandable manner. Not an easy feat.
I don't know enough about Clojure to comment on it. But I have some experience with F# and I don't recommend it. Like Common Lisp, F# is a multi-paradigm language, providing imperative, OOP and FP programming facilities. Unlike CL, it's extremely difficult to restrict F# code to only one paradigm, especially FP. I feel F# is too tightly coupled with the underlying .Net CLR to be a good FP platform without the programmer exercising a lot of effort.
Regarding SQL Server, my experience is as a database programmer, not a DBA, and I assume you're looking for programming resources. I've found SQL Server's accompanying documentation to be very good, if a bit overwhelming. Even though you're looking at SQL Server 2008, programming SS2012 is almost the same as SS2008, and it looks like the developer documentation for SS2012 has been greatly expanded.
The only two books I've needed to refer to for specific SQL Server 2008 knowledge are "Inside SQL Server 2008: T-SQL Programming", and "Inside SQL Server 2008: T-SQL Querying", both by Itzik Ben-Gan, et al. They cover the same topics as the SQL Server docs, but in a different, sometimes better, way.
One SQL book I value highly is Joe Celko's "SQL for Smarties". It's not SQL Server specific, and truth be told, Celko can come across like cranky Dr. House, but he (Celko, not House) is right more often than not.
Two SQL Server bloggers I follow are Aaron Bertrand and Erland Sommarskog.
Bertrand's blog is at http://sqlblog.com/blogs/aaron_bertrand/.
His "Bad Habits" series of articles has saved me a lot of pain over the years:
Sommarskog's blog is at http://www.sommarskog.se/. He has a comprehensive series of articles covering the day-to-day problems SQL Server developers run into, like arrays, lists and dynamic SQL.
Chris R. Timmons
12/31/2012 12:47:47 AM #
Wow, an outstanding post. I'm giving you Comment of the Week!
Thanks very much for the great info, and great to hear from you.
1/9/2013 11:52:46 PM #
Regarding which FP language to choose, I don't think you can go badly wrong with any of the languages you've listed. The most important thing will be to find a class, book, or tutorial which focuses solidly on functional programming fundamentals. Probably the worst way to make a mistake getting started is to attempt to build a web application. There are many, many web frameworks for the languages you've listed, without, really, in the clear winners, and dealing with them will be a big digression from core functional programming fundamentals. I think that when you're getting started with functional programming, the best thing to do is to build simple, command line applications, in whatever environment you've picked. Move on to Web or GUI apps after you've mastered this.
I agree with Chris's comments about Haskell. I also agree with his book recommendations on Haskell. Haskell is probably my favorite programming language of all that you have listed, because it forces you to think differently about how to get programming tasks done. of the languages you've listed, Haskell has the strongest type system, though not the most complex.
I agree with Chris when he notes that using a multi-paradigm language such as F#, Scala, or Clojure means you run the risk of choosing to fall back on, say, OOP code rather than functional code while you are learning. Yes, that is not a choice in Haskell. But I would not necessarily let that stop you from picking F#, Scala, or Clojure. You just have to be aware of the risk.
A good book or self-study course which focuses solidly on functional programming in that environment should be enough to keep you on the right track. For example, I took the Coursera course on Scala from Martin Odersky. Even though Scala is a mixed paradigm language, I found this course to be a good intro to functional programming. A view additional comments about Scala: I found the Typesafe Scala IDE to be too buggy to use (multiple crashes with data loss) and had an actively hostile user experience. I much preferred using Sublime Text 2 for Scala development. One of the interesting things about the Scala language is the mathematical formalization underlying it. ( http://lampwww.epfl.ch/~odersky/papers/mfcs06.pdf ) Another interesting thing about Scala is that the type system itself is Turing complete.
I found Chris's comments about F# To differ significantly from my own experience. I really don't think that it is "difficult" to do real functional programming in F#. One can rather easily, for example, choose to ignore F#'s OOP features altogether. Also, F# has some really interesting features not found in other functional languages, like type providers, which are the most interesting system I've seen for bridging a statically typed language with a fundamentally dynamic dependency such as a web API. F# has, IMHO, the best IDE of any of the languages you've listed.
Of the languages you've listed, only Clojure is dynamically typed. Another thing which stands out about Clojure is the strong emphasis on metaprogramming in idiomatic Clojure code. I personally find Clojure a bit more interesting than Common Lisp insofar as it distinguishes references from values in a really useful way. Whereas Haskell and the others mostly attempt to avoid application state wherever possible, Clojure formalizes the notion of state changing over time in a way reminiscent of database MVCC. Clojure is not necessarily my first choice for an FP language, but I think that there is a lot to be learned from it.
(Third time attempting to post this comment. Crossing my fingers and clicking "Save.")
1/10/2013 12:41:48 AM #
Great stuff, thanks very much. I've pretty much settled on Haskell for the reasons Chris outlined. I've started in on:
and it is pretty good. I think I know the basic idea of FP, but of course, thinking and knowing for sure are two different things.
I really appreciate you taking the time to read and reply.
The views I express here are entirely my own and not necessarily those of any other rational person or organization. However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right. Most of the time. Except when I'm not, in which case, you shouldn't agree with me.
Powered by BlogEngine.NET 220.127.116.11
Theme by Mooglegiant and modified by Nick Hodges