Zed Shaw - Ruby has dodged a bullet

[Chad Perrin]

Not that I blame Chuck, but I find it unfortunate that this thread is
getting about 50 or more posts then the usual code related thread.
Perhaps its just me.

Well . . . to be fair, "the usual code related thread" is a question that
gets answered before most of us even see it in our inboxes, generally by
half a dozen people in varying (but generally all helpful) ways.

I think it's a good thing that when someone asks a question it gets
answered promptly, with some detail, with varying approaches, by several
skilled coders, while a slur of the community gets examined to determine
whether we have any shortcomings that need addressing -- rather than just
discarding the rant as baseless without even checking it for hidden
truths.

. . and I've seen some of the more interesting code-related and
programming theory-related threads get much longer than this.

 

[Chad Perrin]

There's a fine line between opinionated and bigoted.

There can be -- but "opinionated" is often good, too. There's more to a
personality than the strength of its held opinions.

 

[Chad Perrin]

I did in no way take offense, but thanks anyway.
BTW I love the point you made, Rails is exactly a powerful tool making
things easy, that has to have downsides of course...

One doesn't typically hand a power drill with 100 foot-pounds of torque
to an accountant to use for hanging pictures -- or, at the very least,
one provides the manual complete with safety guidelines in it. For some
reason, software isn't treated the same way as power tools in that
regard, especially in a commercial setting.

 

[tho_mica_l]

You make it easy to make, but you also make it

easy to break

Sounds nice but I'd say a program written in assembler is easier to
break than one written in ruby.

because the developer using the underlying tools didn't
understand some fundamental concepts

Many of these tools are made so that you don't have to care about the
underlying concepts but so that the whole problem can be moved to
different level where it's easier to handle. I remember a friend who
once said that you don't know anything about whatsoever unless you
don't
understand basic atomic laws -- he was a physicist of course. But no,
that's not necessary, which may of course hurt the narcistic mind of
somebody who invested years of his life in understanding something. I
have always thought the basic idea of ruby is to be easy to use (for
everyone[1]). I haven't thought it was to make you feel like a rock
star
(to cite another posting in this disturbing thread).


[1] BTW Smalltalk was also created to enable kids to develop computer
programs and I always thought of ruby as a practical descendent of
Smalltalk.

 

[Sam Smoot]

Some things are (a) still hard in pure Ruby and (b) much more useful

without depending on a C extension.

-austin

Absolutely. Projects like FasterCSV, REXML, Merb, etc are invaluable
to my daily work.

Pure-ruby projects I don't personally use like Sequel, or Nitro are
obviously great achievements with very high standards.

I just meant to highlight that the ability to build bridges for Ruby
to "the outside world" is often a task that might be best done as a C-
extension, and generally speaking, it seems to be a fairly small pool
of people capable or willing to build those bridges for us.

 

[Farrel Lifson]

Absolutely. Projects like FasterCSV, REXML, Merb, etc are invaluable
to my daily work.

Pure-ruby projects I don't personally use like Sequel, or Nitro are
obviously great achievements with very high standards.

REXML is pure ruby.

Farrel

 

[Giles Bowkett]

One of my biggest gripes about Rails, and I see this a lot, is that it

*doesn't* completely encapsulate the lower layer; that's not its goal. It
makes the easy things easy.

I think that's actually a strength. It's not like you can *really* get
away with *just* learning Rails. Rails is like a gigantic set of
power-user shell aliases that make common use cases simple, clean, and
powerful. But if you want to get anything done, you still need Unix. I
think that's actually really what made Rails successful.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[Robert McGovern]

I liked the Ruby community better when it placed more emphasis on code
and less on personalities.

I kind of second this, I used to read Ruby-talk quite actively
possibly between 2001 to 2004 but slowly drifted away from it because:

a) the noise levels started to go up
b) a number of quite interesting people, whose opinions I though where
worth the time and effort to read start to leave / drifing away
c) Rails exploded which flooded the community somewhat and I think
expanded it to fast, making it less friendly.

I think the latter started leading to the increase of noise and
vitriol that turns up from time to time.

Rob

 

[Michael Schuerig]

The very same arguments people use about "write your own
authentication system so you know what it does" can be extrapolated
to "write your own framework" - and, from there, to "write your own
language", "build your own computer", and "don't believe anything you
haven't seen with your own eyes".  It's all of a piece.

I'd consider it bad advice to tell people to "write your own X so you
know what it does." It encourages people to ignore work that has
already been done and particularly ignore the thinking that has gone
into that work already. What's the point of having your homebrew X that
you fully understand, but that is broken-as-designed? Write your own X
if you understand the existing alternatives and they can't be made to
do what you need.

Michael

 

[H. joseph Solbrig]

I'm dangling my legs in two pools at the moment; I try to keep up with
computing, and I also try to attend Berklee. Which is, in fact, chock
full of next year's rock stars. Only they're not rock stars yet. There are
no cliques in that school; there are no rappers dissing other rappers, or
rock stars making bold philosophical statements (other than when they get
high after class). Nobody spends any time criticizing someone else's
fretboard technique. It's all about the music, and about learning from each
other.

This is an interesting comparison because I'm not at all a musician but
I live in Portland, Oregon, one center of Indy Rock. I'm sure the
Berklee students have a good shot at stardom after school, some of our
self-taught rockers will famous soon as well. But with the Indy Scene,
the star posturing starts much earlier.

What interesting about this is that communities do matter. Some nurture
ego and some don't nurture it as much.

We should each keep in mind what behavior we're nurturing.

Joe Solbrig

 

[M. Edward (Ed) Borasky]

Sure, and when they succeed, it's beautiful. I haven't had to think about
the number of cycles a CPU instruction will take in two decades.

I haven't had to think about that since 1990, but I still *enjoy* it.

 

[M. Edward (Ed) Borasky]

I'd consider it bad advice to tell people to "write your own X so you
know what it does." It encourages people to ignore work that has
already been done and particularly ignore the thinking that has gone
into that work already. What's the point of having your homebrew X that
you fully understand, but that is broken-as-designed? Write your own X
if you understand the existing alternatives and they can't be made to
do what you need.

Michael

Well, except for Forth. The traditional way of learning Forth is to
write your own.

 

[Eivind Eklund]

I haven't had to think about that since 1990, but I still *enjoy* it.

There's still some embedded work where cycle twiddling matters - I
last did some in 2001 (?). I had to hit external hardware every 64
cycles - on the cycle - while multitasking other processing. That's
probably the most fiddly code I have ever done. I ended up writing a
little ruby script that worked as roughly half an assembler and
counted cycles for me and colorized my source code if my counts where
off - it made everything way easier. Ah, memories...

Eivind.

 

[Eivind Eklund]

I'd consider it bad advice to tell people to "write your own X so you
know what it does." It encourages people to ignore work that has
already been done and particularly ignore the thinking that has gone
into that work already. What's the point of having your homebrew X that
you fully understand, but that is broken-as-designed? Write your own X
if you understand the existing alternatives and they can't be made to
do what you need.

My opinion: You often cannot do this evaluation until you have written
your own or have been badly bitten by existing alternatives. For
instance, in the web application framework I work in (which is written
by one of the guys I work with and modified quite a bit by me) we have
a few external dependencies, and they bring us an inordinate amount of
grief.

For instance, authentication. The perl library we used to do this has
an extreme amount of configurability, and it end up being very hard to
debug when we have problems. Rewriting the major part of this took us
under an hour, resolving the problem and making things easy to handle
and debug. It used to take us several hours to debug every error; the
rewrite was actually part of a single authentication debugging
session.

Another instance is the session library. It is a complex mess of
spaghetti, due to solving a bunch of problems we don't need solved,
and a direct implementation should be about 40 to 100 lines of code
(probably closer to 40). Alas, we've not dared replace it, since
since it is used all over the place over many hundreds of thousands of
lines of code, and some subtle issue could crop up and be nasty. If
we'd just written the code when we first needed sessions, we wouldn't
be in this mess.

An external solution very seldom satisfies the following requirements:
- Totally seamless upgrades and integration along with the rest of the project
- Having somebody local that completely understands the code
- Having it be the minimal amount of code necessary to handle your requirements
- Follows your coding standards

In addition, with an external library you get extra olution search
costs (finding the library), evaluation costs, integration/setup
costs, and potentially debugging costs at later points - in addition
to costs from not fitting the above soft requirements.

You should use external libraries when the benefit from the library
exceeds these costs. You should use a locally written solution when
the costs of using something external exceeds the benefit.

I personally like to erri on the side of writing locally rather than
on the side of adding too many dependencies, as I find that I tend to
underestimate the particular amount of grief from an external
dependency more than I underestimate development time, and that
particularly in aggregate external dependencies give grief at more
random times when I need things to get easy.

Eivind.

 

[Francis Cianfrocca]

[Note: parts of this message were removed to make it a legal post.]

My opinion: You often cannot do this evaluation until you have written
your own or have been badly bitten by existing alternatives. For
instance, in the web application framework I work in (which is written
by one of the guys I work with and modified quite a bit by me) we have
a few external dependencies, and they bring us an inordinate amount of
grief.

There's a great deal of merit in both points of view. But there may be a
basic architectural consideration at work here too.

It's axiomatically a good thing to leverage the good thinking (and
debugging) done by others. Any number of Unix heavyweights have made the
point about "standing on the shoulders of giants."

But the task of debugging and maintaining a production-quality piece of code
is correlated strongly with its size and even more with its heterogeneity.
Adding in a lot of external libraries, no matter how well designed and
executed, is going to create problems simply by virtue of the number of
points of contact.

But I don't necessarily think the whole answer is to develop local solutions
to standard problems. For really standard pieces of basic functionality,
tightly-focused small external libraries are usually the right answer. (You
probably won't roll your own XML parser, for example.) But sbove that level,
things get very fuzzy, very fast.

The world still hasn't found a really good solution for creating
loosely-coupled applications that can leverage external functionality
without incorporating it in-process. And there are many reasons for this:
impedance mismatches, performance problems, lack of integration standards,
and many others we've discussed many times already.

The enterprise world, which has strong economic motivations to solve this
problem, is finally creeping tentatively toward a commitment to SOAs, after
talking about it for years. The problem in this space is that the discussion
has been driven by vendors, who all want to control the network standards
used for loose-coupling. But none of the standards (XML-RPC, SOAP, REST,
many others) is really ideal. As a result, people have been focusing on all
the wrong things, and there is a lot of home-grown mish-mash out there.

We're still years away from a real solution.

 

[Jeremy McAnally]

Maintaining third party libraries becomes exponentially easier when
you know and intimately understand how they work (usually by at least
building a basic prototype of a similar solution).

--Jeremy

There's a great deal of merit in both points of view. But there may be a
basic architectural consideration at work here too.

It's axiomatically a good thing to leverage the good thinking (and
debugging) done by others. Any number of Unix heavyweights have made the
point about "standing on the shoulders of giants."

But the task of debugging and maintaining a production-quality piece of code
is correlated strongly with its size and even more with its heterogeneity.
Adding in a lot of external libraries, no matter how well designed and
executed, is going to create problems simply by virtue of the number of
points of contact.

But I don't necessarily think the whole answer is to develop local solutions
to standard problems. For really standard pieces of basic functionality,
tightly-focused small external libraries are usually the right answer. (You
probably won't roll your own XML parser, for example.) But sbove that level,
things get very fuzzy, very fast.

The world still hasn't found a really good solution for creating
loosely-coupled applications that can leverage external functionality
without incorporating it in-process. And there are many reasons for this:
impedance mismatches, performance problems, lack of integration standards,
and many others we've discussed many times already.

The enterprise world, which has strong economic motivations to solve this
problem, is finally creeping tentatively toward a commitment to SOAs, after
talking about it for years. The problem in this space is that the discussion
has been driven by vendors, who all want to control the network standards
used for loose-coupling. But none of the standards (XML-RPC, SOAP, REST,
many others) is really ideal. As a result, people have been focusing on all
the wrong things, and there is a lot of home-grown mish-mash out there.

We're still years away from a real solution.

--
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

 

[Michael Schuerig]

Maintaining third party libraries becomes exponentially easier when
you know and intimately understand how they work (usually by at least
building a basic prototype of a similar solution).

I think both points of view -- use existings libs and write your own --
when applied responsibly boil down to the same principle: understand
the code you're using.

Incidentally, that's the advice I tend to give (Rails) people when they
ask if there's a plugin to do something. Be prepared to take over
maintenance of the code yourself when something breaks; the original
author might have abandoned it by then. In the case of Rails plugins
that's not entirely unlikely.

Even given this caveat, if at all possible, I prefer using established
existing code over DIY. Even more so when there already is a community
of people using the existing lib, plugin, whatever. I like to have some
common coding ground with others, instead of lots of one-off solutions.

Michael

 

[M. Edward (Ed) Borasky]

I've seen people, from time to time, chime into a slightly heated debate
with the words "What would Matz do?" or something to that effect.

Well, what Matz *did* was create a new language because none of the
others were exactly what he wanted. Now, I've been there -- decades ago,
actually. None of the existing languages were exactly what I wanted
either. But there wasn't a way one could build a world-wide community in
those days without being a multinational corporation or being part of
one. APL, for example, probably would never have taken off if Kenneth
Iverson had invented it in a university instead of at IBM.

 

[Paul Stickney]

APL, for example, probably would never have taken off if Kenneth

Iverson had invented it in a university instead of at IBM.

APL took off like the Spuce Goose.
[http://www.sprucegoose.org/aircraft_artifacts/exhibits.html]

 

[Paul Stickney]

Research. Research. Research.
Then, steal... err, borrow the best ideas that suit your goal and
make your own X.

The problem with most software products (including languages) is that
they ignore the lessons of the past--there is nothing wrong with
making your own wheel (because you can make it rounder or with
year-round studs or anti-gravity or bright red...) as long as you
progress to a BETTER (for various definitions of "better") wheel. And
then, of course, software without a purpose is...

(Sometimes it might just be *fun* to write X.)

Of course, the above should be taken in a context where making X
doesn't impede on your ability to earn a living, live happily, or
delay other [software] development.