Confession: I never learned CS
Jay Levitt
answers to it; I was also reading Steve Yegge's old but excellent "five
essential phone-screen questions"
(http://steve.yegge.googlepages.com/five-essential-phone-screen-questions).
And I realized something: In my 30-odd years of programming, I never
learned the stuff I think of as "Computer Science".
In the very beginning, I was on a Commodore using BASIC or ML, so there was
no such thing as data structures or recursion or parsing. Naturally.
But unlike most folks who went on to C, C++, LISP and/or Java before coming
to Ruby, I spent most of the next 15 years in PL/1, working on a
ridiculously high-volume distributed system, using relatively slow CPUs,
that had to have sub-second response times.
So I never learned big-O notation. I mean, I know what it means, but I
couldn't tell you what data structures are logarithmic and what data
structures are exponential, because we had exactly four kinds of data
structures: arrays, short linked lists, hash tables and everything else.
And those ran at four speeds, respectively: instant, fast, fast and way too
slow.
Parsing was likewise out of the picture. Any data I munched on had to be
pre-formatted in a structure that precisely matched the in-memory structure
it was being loaded into. The operating system even provided a standard
tool to describe "field-value" style tables and compile them into a binary
data file of repeated structs. Any notions of "parse trees" were out of
the question; only towards the end did we finally get fast enough
processors to consider occasionally *scanning* long strings for tokens.
And without parsing, there's little use for recursion.
And now I've jumped headfirst into the world of Ruby and modern CPUs, where
an interpreted language can parse itself, and I don't even know where to
start learning everything I missed. I'm not about to go learn LISP, even
though I'm sure it would be a fun experience - I've seen enough LISP in my
emacs startup to know it's not for me.
Yet I know I have much to learn, because I approach too many problems with
an iterative, loop-based approach, when Ruby has such nice tools for
parsing and list-processing and analysis.
So - any recommended reading? What books will help me change the way I
think about data?
--
Jay Levitt |
Boston, MA | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer
Wilson Bilkovich
> Yet I know I have much to learn, because I approach too many problems with
> an iterative, loop-based approach, when Ruby has such nice tools for
> parsing and list-processing and analysis.
>
> So - any recommended reading? What books will help me change the way I
> think about data?
>
Big hunks of it are fundamentally unlike Ruby, but that's probably a
good thing for your brain.
This book is a work of genius that I think every 'serious' programmer
should own: http://www.info.ucl.ac.be/~pvr/book.html
Sorry if that sounds too over-the-top. :)
ara.t.howard
On Sep 26, 2007, at 3:10 PM, Jay Levitt wrote:
> So - any recommended reading? What books will help me change the
> way I
> think about data?
http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp/0131774298
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-
Professional/dp/0201633612/ref=pd_bbs_sr_1/104-1681521-1481518?
ie=UTF8&s=books&qid=1190842864&sr=1-1
http://www.amazon.com/Reference-Manual-Samuel-P-Harbison/dp/
013089592X/ref=pd_sim_b_1_img/104-1681521-1481518
http://www.amazon.com/Introduction-Algorithms-Thomas-H-Cormen/dp/
0262032937/ref=pd_bbs_2/104-1681521-1481518?
ie=UTF8&s=books&qid=1190842923&sr=1-2
books you cannot live without.
cheers.
a @ http://drawohara.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
John Joyce
those books.
They won't hurt you. (unless you try to carry more than 2 of them at
any time)
But you can learn a lot from other people's code and from browsing
used bookstores.
Many of the algorithms and design patterns covered don't change all
that much.
You don't have to know everything to do stuff.
Data structures tend to differ somewhat depending on the language
(and framework) you are using.
Probably the best thing to do for data structures is just run through
some C books. Then hit a C Data structures book. That will give you a
lot right there. But it all really depends on what you want or need
to do. Much of it you may never actually use.
David B. Williams
> So - any recommended reading? What books will help me change the way I
> think about data?
If you want a book that deals with Ruby and the fundamentals you would
learn in any introduction to data structures and algorithms course, try
this:
http://www.brpreiss.com/books/opus8/
David B. Williams
http://www.cybersprocket.com
--
Posted via http://www.ruby-forum.com/.
Jeremy Hinegardner
>
> On Sep 26, 2007, at 3:10 PM, Jay Levitt wrote:
>
> >So - any recommended reading? What books will help me change the
> >way I
> >think about data?
>
> http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp/0131774298
This book is so much fun to read. I love the stories, I mean where else
are you going to learn about cron implemented in a lego brick.
enjoy,
-jeremy
--
========================================================================
Jeremy Hinegardner jer...@hinegardner.org
John Joyce
Cool!
I'm reading that one starting.... now!
Alex Young
> Yet I know I have much to learn, because I approach too many problems with
> an iterative, loop-based approach, when Ruby has such nice tools for
> parsing and list-processing and analysis.
>
> So - any recommended reading? What books will help me change the way I
> think about data?
It's worth going back to basics and watching the MIT SICP lectures.
They got a lot of ideas I thought I knew straight in my head, and a lot
of things that I thought were complicated turned out to be really
simple. There's also a free copy of the textbook that goes with it online.
The book: http://mitpress.mit.edu/sicp/
The lectures:
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
--
Alex
John Joyce
Berkely and MIT both have huge numbers of classes available as free
podcasts, both through iTunes and through their own web sites. Some
as videos.
The recording quality has even improved to the point of being
listenable!
Ilmari Heikkinen
> So - any recommended reading? What books will help me change the way I
> think about data?
I'm currently "reading" (i.e. turning two pages now and then)
Programming Language Pragmatics, and it's a good look at
how programming languages work.
http://www.cs.rochester.edu/~scott/pragmatics/
Introduction to Algorithms was a great book too.
I heard Okasaki's Purely Functional Data Structures
recommended as well.
http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf
HTH,
--
Ilmari Heikkinen
http://fhtr.blogspot.com
Jay Levitt
> On 9/27/07, Jay Levitt <jay+...@jay.fm> wrote:
>
>> So - any recommended reading? What books will help me change the way I
>> think about data?
Wow! Thanks for the many great recommendations, folks. Some comments:
* GoF: Yes, I have this one, and it's a classic; I've actually read both of
the Alexander books cover-to-cover while I was building a house. But I
also find that many of the GoF patterns are either unnecessary or greatly
simplified in Ruby. I know there's at least one project to codify the Ruby
equivalents, and I look forward to more work in that area.
* C programming books: I guess I didn't mention that I've got over a dozen
C and C++ books; I was following along on paper, I just never did much work
in those languages, and the books didn't really "change my thinking".
Great recommendation for someone who's truly jumped straight into Ruby,
though.
* Intro to Algorithms: I know it's the classic work, but I also see a huge
number of complaints on Amazon about the lack of provided solutions and
followup information; seems like it's intended more for a classroom setting
than as a self-study guide. I also admit a bias against older books;
technology writing has greatly improved as the field's expanded, and I find
it difficult to go back and read something like Date or K&R today. (Well,
Date was always tough.) Now, if Scott Meyers (Effective C++/STL) ever
wrote an algorithms book, *that* would be a best seller. Any thoughts?
* Data Structures and Algorithms (Preiss): I'm a little turned off by the
hard-to-read pixelated LaTex GIFs, the lack of a print version or even the
right to download it, the lack of a solutions manual, the web-0.5 FSF-style
page navigation, and the fact that the first "Ruby" code I saw defines its
own "abstract_method" declaration, which makes me think that the Ruby
"version" is more like a Babelfish translation of the Java version. (My
web site: Now in Senegalese!) OK, so I'm more than a little turned off.
Probably bears reading anyway, though.
* SICP, Programming Language Pragmatics (Scott), Purely Functional Data
Structures (Okasaki), Concepts, Techniques and Models (Van Roy, Haridi):
These look like must-reads!
Martin DeMello
> * Data Structures and Algorithms (Preiss): I'm a little turned off by the
> hard-to-read pixelated LaTex GIFs, the lack of a print version or even the
> right to download it, the lack of a solutions manual, the web-0.5 FSF-style
> page navigation, and the fact that the first "Ruby" code I saw defines its
> own "abstract_method" declaration, which makes me think that the Ruby
> "version" is more like a Babelfish translation of the Java version. (My
> web site: Now in Senegalese!) OK, so I'm more than a little turned off.
> Probably bears reading anyway, though.
Yeah, the obvious "blind" translation turned me off the book too. I'd
actually start by reading "How to Design Programs" (scheme, but very
well designed and written), and then try doing some of the exercises
both in scheme and in ruby.
martin
Rick DeNatale
> Jay Levitt wrote:
> > So - any recommended reading? What books will help me change the way I
> > think about data?
>
> If you want a book that deals with Ruby and the fundamentals you would
> learn in any introduction to data structures and algorithms course, try
> this:
>
> http://www.brpreiss.com/books/opus8/
A big -1 on that book. It's been discussed here before.
It's part of a series in which the author treats different languages
as plug-in replacements. It's not at all a good ruby resource.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Rick DeNatale
> On Thu, 27 Sep 2007 23:57:08 +0900, Ilmari Heikkinen wrote:
>
> > On 9/27/07, Jay Levitt <jay+...@jay.fm> wrote:
> >
> >> So - any recommended reading? What books will help me change the way I
> >> think about data?
>
> Wow! Thanks for the many great recommendations, folks. Some comments:
>
> * GoF: Yes, I have this one, and it's a classic; I've actually read both of
> the Alexander books cover-to-cover while I was building a house. But I
> also find that many of the GoF patterns are either unnecessary or greatly
> simplified in Ruby. I know there's at least one project to codify the Ruby
> equivalents, and I look forward to more work in that area.
I've got to agree here. I am/was friends with all four of the GOF and
I hope that the three survivors won't be offended, but it's really a
C++ book, and I fear that it has done as much harm as good for those
trying to apply it to languages with less draconian (or is it baroque)
design. Although Ralph put in some Smalltalk references they were
mostly in the way of commentary when they were trying to do similar
things in C++.
Patterns are all about picking paths due to the problem and situation
at hand, and for better or worse, the programming language is a big
part of the situation at hand. Most of the GOF book deals with the
issues raised by statically typed oo languages, and aren't as portable
as one might think.
John Joyce
On Sep 27, 2007, at 4:18 PM, Rick DeNatale wrote:
> On 9/26/07, David B. Williams <da...@cybersprocket.com> wrote:
>> Jay Levitt wrote:
>>> So - any recommended reading? What books will help me change the
>>> way I
>>> think about data?
>>
>> If you want a book that deals with Ruby and the fundamentals you
>> would
>> learn in any introduction to data structures and algorithms
>> course, try
>> this:
>>
>> http://www.brpreiss.com/books/opus8/
>
> A big -1 on that book. It's been discussed here before.
>
> It's part of a series in which the author treats different languages
> as plug-in replacements. It's not at all a good ruby resource.
Indeed I just read through it today and it is not good.
The html is horrible too. Contacted the author and he was pretty
"whatever" about it because the LaTeX2html software is apparently no
longer being updated...
So he's obviously too lazy to pick up xhtml and css in an afternoon
and / or simply use one of the languages he writes about with one of
the many converters in those language to produce a better site.
He's pretty wrong about Ruby though. He unfortunately describes
everything as if it's C++ but Ruby is whole different beast. Some
things are similar in ways that any programming language or OOP
paradigm are similar, but every language has its own vernacular and
for good reason: they're different and require different approaches.
There are better exercises in data structures out there, and
definitely better discussions of Ruby.
John Joyce
> at hand, and for better or worse, the programming language is a big
> part of the situation at hand. Most of the GOF book deals with the
> issues raised by statically typed oo languages, and aren't as portable
> as one might think.
The language itself IS a pattern/structure that will determine and/or
enable patterns and structures!
Frameworks/libraries will tend to enforce patterns and structures.
Ruby is pretty open and fully object-oriented by design, while
enabling you to do procedural things to objects.
Rails is an example of a framework that really establishes and
enforces particular patterns and structures.
Simply by using code by others and using the language, you'll find a
lot of these things quickly in Ruby.
Some things are well established patterns in C / C++ books (searching
& sorting algorithms) but they don't always make sense as Ruby since
Ruby provides mechanisms that would be oh-so-much boiler plate code
in lower-level languages.
Jay Levitt
> The html is horrible too. Contacted the author and he was pretty
> "whatever" about it because the LaTeX2html software is apparently no
> longer being updated...
I had *exactly* the same problem with EasyScript.[1]
[1] The best word processor available for a Commodore 64, bar none.
Jay Levitt
> I had *exactly* the same problem with EasyScript.[1]
>
> [1] The best word processor available for a Commodore 64, bar none.
Correction: SpeedScript.
MenTaLguY
> Most of the GOF book deals with the issues raised by statically
> typed oo languages, and aren't as portable as one might think.
I'd submit the issues have more to do with the lack of "nice"
higher-order functions than they do with object orientation or
static typing.
For instance: the Visitor pattern suddenly becomes trivial when
you have HoFs for traversal (Enumerable#each, anyone?).
-mental
Wilson Bilkovich
> On 9/27/07, Rick DeNatale <rick.d...@gmail.com> wrote:
> <snip>
> > I've got to agree here. I am/was friends with all four of the GOF and
> > I hope that the three survivors won't be offended, but it's really a
> > C++ book, and I fear that it has done as much harm as good for those
> > trying to apply it to languages with less draconian (or is it baroque)
> > design. Although Ralph put in some Smalltalk references they were
> > mostly in the way of commentary when they were trying to do similar
> > things in C++.
> >
> > Patterns are all about picking paths due to the problem and situation
> > at hand, and for better or worse, the programming language is a big
> > part of the situation at hand. Most of the GOF book deals with the
> > issues raised by statically typed oo languages, and aren't as portable
> > as one might think.
> >
> a different friend of your's "Smalltalk Best Practices" by Kent Beck.
> I know it is not about Design Patterns but Micro Patterns, I know it
> is not about Ruby but about Smalltalk.
> Anyway Kent calls Ruby Smalltalk in disguise for some reasons, I am of
> course referring to the "Smalltalk beating Java and being called Ruby"
> saying.
>
> Honestly I am only through the half of the book but there is just no
> item so far I would not apply to Ruby.
>
> This book is a must read anyway, gotta read *all* of his books ;)
>
The book's correct title is "Smalltalk Best Practice Patterns", and I
would like to second the recommendation. Gianni Jacklone turned me
onto it a couple of years ago, and I really found it helpful.
bpfurtado
> On Fri, 28 Sep 2007 06:31:47 +0900, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
> > Most of the GOF book deals with the issues raised by statically
> > typed oo languages, and aren't as portable as one might think.
You couldn't be more wrong, being statically typed does not interfere
in the runtime messages exchange between your objects.
Design Pattern or better saying Object Oriented Modeling is just about
how to better model the comunications of your objects in order to get
more *reusable* and *maintainable* code.
Those OO techniques are highly valid for Java, C++, Ruby or Python
world.
Rick DeNatale
> On Sep 27, 7:29 pm, MenTaLguY <men...@rydia.net> wrote:
> > On Fri, 28 Sep 2007 06:31:47 +0900, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
> > > Most of the GOF book deals with the issues raised by statically
> > > typed oo languages, and aren't as portable as one might think.
>
> You couldn't be more wrong, being statically typed does not interfere
> in the runtime messages exchange between your objects.
I didn't say that. However, it does AFFECT how you design. But if you
really look at GOF most of the patterns are tied up in technical
aspects of declaring interfaces, something which is crucial in C++ or
Java.
Although you can adapt some of the GOF patterns to languages like Ruby
or Smalltalk, they really do come primarily from the C++ school,
albeit many of them adapted Smalltalk practices. One of the reasons
that Smalltalk examples are rare in the book is because the Smalltalk
implementations of the ideas being expressed really didn't fit the
patterns as they are described.
> Design Pattern or better saying Object Oriented Modeling is just about
> how to better model the comunications of your objects in order to get
> more *reusable* and *maintainable* code.
>
> Those OO techniques are highly valid for Java, C++, Ruby or Python
> world.
You get good code by working with the characteristics of your language
and tools. Many of the techniques in the GOF book are far more
applicable to Java and C++ than Ruby, Smalltalk or Python.
At an abstract level, the GOF book's biggest contribution was in
providing a common vocabulary for a certain set of patterns, and for
those using C++ and/or Java it gives good implementation advice.
However I maintain my position that those who look at it as a language
independent implementation cookbook aren't using it well.
Rick DeNatale
> On 9/27/07, Rick DeNatale <rick.d...@gmail.com> wrote:
> <snip>
> > I hope that the three survivors won't be offended, but it's really a
> > C++ book, and I fear that it has done as much harm as good for those
> > trying to apply it to languages with less draconian (or is it baroque)
> > design. Although Ralph put in some Smalltalk references they were
> > mostly in the way of commentary when they were trying to do similar
> > things in C++.
> >
> > Patterns are all about picking paths due to the problem and situation
> > at hand, and for better or worse, the programming language is a big
> > part of the situation at hand. Most of the GOF book deals with the
> > issues raised by statically typed oo languages, and aren't as portable
> > as one might think.
> >
> a different friend of your's "Smalltalk Best Practices" by Kent Beck.
> I know it is not about Design Patterns but Micro Patterns, I know it
> is not about Ruby but about Smalltalk.
> Anyway Kent calls Ruby Smalltalk in disguise for some reasons, I am of
> course referring to the "Smalltalk beating Java and being called Ruby"
> saying.
>
> Honestly I am only through the half of the book but there is just no
> item so far I would not apply to Ruby.
>
> This book is a must read anyway, gotta read *all* of his books ;)
I recently re-read this book, it's certainly a classic.
I discussed it with Kent a few months back, and asked if he'd ever
thought about doing a Ruby version, he said that he would like to but
the book market just didn't pay enough to make it worthwhile. The
real payoff in writing books for the technical market is the fame, and
Kent is probably more than famous enough for his needs.
On the other hand, I can't completely agree about it being 100%
applicable to Ruby.
As I've said before, programming patterns, best used, are selected in
a world of tensions and pressures generated by the requirements and
the languages and tools.
If you look closely at Smalltalk Best Practice Patterns, many are
specific to Smalltalk. Things like the patterns of how to construct
Smalltalk objects don't really apply to Ruby. Patterns relating to
instance state are affected by the differences between Smalltalk in
which instance variables are declared in classes with slots allocated,
and Ruby in which instance variables are dynamically acquired. Ruby
instance variables are actually an example of the Variable State
pattern which Kent, rightly, recommends using sparingly in Smalltalk.
Many of Kent's patterns are related to interacting well with the
Smalltalk IDE, i.e. doing things which work with the IDE to make it
easier to read the code and find the code you need to read.
And most of the chapter on Collection patterns isn't applicable
directly to Ruby, although I would encourage Rubyists to get some
background on Smalltalk collections.
Maybe more on this in my blog.
bpfurtado
In that point I totally agree with you, you gotta learn more than the
syntax from one language to another.
Regarding Design Patterns, they will apply equally well with your OO
language regardless they force you to statically declare the types of
your variables, having duck typing or not [http://en.wikipedia.org/
wiki/Duck_typing].
There will be always a room for Visitor implementations on compilers
written in any language, always a room for Observer/Observable in
event oriented APIs, Template methods, etc. In Python, Ruby, Java,
etc.
There's a way to think in each language/platform but Design Patterns
are well applied to any OO design. You can look for than on good
frameworks or APIs in Python or Ruby.