On Sat, May 31, 2014 at 12:35:22AM +0100, Magdalen Berns wrote:
> I am not sure I get your comment about 'buying into OOP' I am used to the
> concept.
Perhaps I should not have thrown that in. I was merely reacting to
software patterns (see below). Ruby is a language that allows for both
OOP and Functional style programming. My taste runs towards the
latter, mostly because with growing software projects I find OOP gets
in the way. But, it is the way that programmers handle OOP. OOP itself
is not evil.
In fact the Ruby standard libraries are a pretty good example on how
to use OOP. Compared to the JAVA standard libraries, for example,
you'll find that the Ruby libraries are pretty flat (little hierarchy,
thanks to mixins), carry as little state as possible and are used
mostly as a form of name spacing. Unlike with JAVA I never (or very
rarely) have to think about different BufferedStreams types, for
example. That is why programming with Ruby stdlib feels so natural to
most programmers.
Anyway, if you want to know more about FP, I can suggest Joe
Armstrong's Programming Erlang book. It was the one that drove the
usefulness home to me (Erlang has no support for OOP). But also for
functional programming in Ruby there are Internet resources. E.g.,
http://code.google.com/p/tokland/wiki/RubyFunctionalProgramming
Ruby is a mixed paradigm language, so you get a bit of both OOP and
FP. For me it strikes a useful balance (that is why I like Ruby!) and
as I grow as a programmer I still discover more about Ruby that I
like. I miss some things available in true FP languages, in particular
(deep) immutable data and expression matching, but that is about it.
> I had not realised it was a philosophy but one I have found most
> useful for navigation through C is C for java programmers as this
> book basically says 'you know when you do X in java, well, it's Y in
> C' and I find that kind of useful. Is that what 'patterns' does?
No. Patterns describe common 'themes' in software architecture. The
simplest one is the Singleton, a class/object that is guaranteed to
exist once in a program. Another pattern is the adapter, which may be
an object that presents a different interface to another object. Both
these patterns are code smells in my book ;), though using them may be
justified. A useful pattern, meanwhile, is the iterator pattern, which
comes natural to Rubyists. Read up on these if this interests you.
> If so, I think that can have some value for me based on my C book
> but if not, maybe I should be careful in case there is something
> more sinister in the pages of this book?!?
There must be some Internet resources 'Ruby for Javaists' etc. I would
ignore design patterns for now.
Pj.