Re: Eating sandwiches in the park
Brian Wisti
--- Jamis Buck <jg...@email.byu.edu> wrote:
> Unfortunately, that's a rather naive view of things (and I don't mean
>
> that to say that YOU are naive, only that you have apparently never
> been
> in a situation where you've been forced to "eat someone else's
> sandwich"). Many times, especially in our own pet projects, we have
> ultimate say over what we use and don't use. There are also times,
> however, when we do not have that freedom.
>
> - Jamis
Hmm ... I guess it's up to us to (nicely) slap down anybody who tries
to use Ruby to make an especially distasteful sandwich, then. That way,
all the widely-known options are nice and delicious!
Kind Regards,
Brian Wisti
http://coolnamehere.com/
Eivind Eklund
> Why the rabid objection to people putting broccoli on their
> sandwiches if they like it?
Because people are putting sandwitches everywhere, and a lot of us are
forced to eat other people's for a variety of reasons.
Many of us are working with a lot of open source code here; we end up
working with code from a lot of other authors, and any feature that
makes that code harder for us to comprehend witll get in the way.
I know at least that's why I'm sceptical: No matter what the feature,
I'm likely to end up having to deal with code that use it.
Eivind.
--
Hazzle free packages for Ruby?
RPA is available from http://www.rubyarchive.org/
Markus
> Also, my apologies for the "You must have lived a sheltered life"
> comment - that came out much harsher than intended.
No worries. It gave me a brief happy moment of wondering if it
possibly was true.
-- Markus
Markus
> --- Eivind Eklund <eek...@gmail.com> wrote:
>
> > On Fri, 15 Oct 2004 02:13:35 +0900, Markus <mar...@reality.com>
> > wrote:
> > > Why the rabid objection to people putting broccoli on their
> > > sandwiches if they like it?
> >
> > Because people are putting sandwitches everywhere, and a lot of us
> > are
> > forced to eat other people's for a variety of reasons.
>
> before I eat it, especially if some stranger offers it to me out of the
> blue, saying "Eat this. I made it special." Once I get a better idea of
> what sort of sandwiches a person makes, I might relax a little bit.
> It's also likely that this budding preparer of sandwiches will realize
> that not everybody likes pickled peppered broccoli on their peanut
> butter and jelly sandwiches, and not share the more exotic creations.
>
> If I'm desperately hungry, and there's a sandwich with creamed crab in
> peppered peanut sauce, I'll just take that creamed crab off and eat the
> part that doesn't make me gag. I will definitely warn all of my friends
> that this freak is making sandwiches with peanut butter and antifreeze
> simply because he can. My friends will probably avoid the freakish
> fabricator of crazed comestibles, leaving him to eat his razor blade
> and mouse poop sandwiches by himself.
>
> I like the sandwich analogy. I may have taken the idea into a new and
> more nauseating direction, but the analogy works. Code which abuses the
> flexibility of the language will not spread very far, simply because
> people won't use it. That has been my experience so far over the last
> few years, and I don't expect that pattern to change any time soon. If
> you see code which has had such abuse inflicted on it, you need to
> either fix it or avoid it. You're certainly not forced to eat it.
Exactly, save one point: it also pays to keep an eye on people who
choose to eat what you find unpalatable. If they die a miserable death,
or even just slink off to kneel in the bushes, you are justified to feel
smug if you wish. But if they prosper and thrive, you may want to see
if you're missing something full of yummy goodness.
I can still remember the transformational moments when I
reluctantly tried (or retried) several of my present favorite foods, and
discovered that they were in fact wonderful. As a child they seemed
inedible, but as I aged my tastes changed.
-- Markus
Markus
> Markus wrote:
> >>> Why the rabid objection to people putting broccoli on their
> >>>sandwiches if they like it?
> >>
> >>Because people are putting sandwitches everywhere, and a lot of us are
> >>forced to eat other people's for a variety of reasons.
> >
> >
> > they have a gun? If I write something you find distasteful, and even
> > post it on the web, are you required to use it? Even if millions of
> > others like it a start to use it, you don't have to if you don't want
> > to.
> No guns, but something just about as scary: the risk of losing my
> employment.
Bingo. I think that was the step I was missing. I feel quite
dense. I "took charge" of my career years ago, and have quite forgotten
what that feels like.
> Now, I don't do Ruby for a living. But I *do* write Java code, and we
> use many different open source libraries. I *do* have *some* say in what
> libraries we use, but I do *not* have absolute say.
I'm the opposite on almost every point: I do use ruby for a living
(even though I'm supposedly semi-retired); while I don't have absolute
say I am a part owner and the head of the technical side.
> There are some libraries we are using which were mandated upon us. My
> life would be a lot less stressful right now if I could choose an
> alternative, but that's not the case, unfortunately.
My condolences. That bites, no matter how you get there.
> >>Many of us are working with a lot of open source code here; we end up
> >>working with code from a lot of other authors, and any feature that
> >>makes that code harder for us to comprehend witll get in the way.
> >
> >
> > So don't work with code that you find to hard to deal with. One of
> > the fundamental tenants of Open Source (at least, as I see it) is that
> > you are never required to use someone else's code if you don't like it.
> > Maybe you don't trust it, or them, or think it's bloat, or buggy, or
> > just don't like their choice of identifiers. Whatever the reason, you
> > are free to decline to use it if you'd rather not.
>
> Unfortunately, that's a rather naive view of things (and I don't mean
> that to say that YOU are naive, only that you have apparently never been
> in a situation where you've been forced to "eat someone else's
> sandwich"). Many times, especially in our own pet projects, we have
> ultimate say over what we use and don't use. There are also times,
> however, when we do not have that freedom.
We differ on this. I would say using code you don't trust just
because you want the functionality is the naive (albeit more common)
point of view. I am actually more likely to use random things "just to
see how they taste" in my pet projects than I am professionally.
-- Markus
Brian Wisti
> - Perl, where the interpreter design and language is just icky, but
> I've had to deal with it because there are applications/modules my
> employer needs to work
> - MySQL, where a migration is too expensive
> - The NFS code for FreeBSD, where we had a spaghetti of C macros
> making the code almost impossible to deal with, but cleaning it up
> would result in divergence from NetBSD/OpenBSD so we had less
> bugfixes.
> - Donald Becker's ethernet drivers in Linux - the code was fairly
> horrible, but they were the only source of some functionality.
> - A million lines of C++ code in various styles and for various
> projects at a former employer, where I did troubleshooting and ended
> up debugging many of the "funny" problems that the people that had
> written the code couldn't debug themselves.
>
> If you don't have to deal with other people's bad choices on a daily
> basis, you live a sheltered life.
>
Sorry, I committed an error of omission with my message. I was
specifically talking about my Ruby experiences. The Ruby community has
been a bit more sane than a lot of other coders. Thinking of why_, I'll
need to modify that. The Ruby community may be insane, but so far it's
insane in a manner that fits in very nicely with keeping your fellow
coders happy.
My Perl/SQL/etcetera experiences were bumpy from the first time that I
had to read somebody else's code, and have continued to be on an almost
daily basis. I haven't had that yet with Ruby.
(knock on wood)
Richard Dale
>
> If I decide to lunch in the park, taking my sandwich and bag of
> assorted goodies to the shade of a likely tree, I may not, even in this
> idyllic environment, find everything to my liking. I could, of course,
> suffer silently. Or I could decide to change what fails to suit.
The difference between the expectations of programmers with respect to the
Java programming language design and Ruby, is is that ruby programmers are
expected to know what they're doing, and Java programmers are assumed to be
'just average'.
For instance, Java doesn't have operator methods because bad programmers
might misuse them. Well thanks guys! Or they crippled anonymous classes as
closures because it 'allocated too much stuff on the heap behind the
scenes'. Again thanks guys.
With Java you are not allowed to add exotic pickles to your sandwich, let
alone rearrange the park. Although I would personally like to ban brocolli
in sandwiches altogether, as a ruby programmer, that isn't how we operate.
With Java programming, xml configuration files everywhere are probably the
equivalent of brocolli. You are allowed to produce you own personal
mediocre sandwich in the same style as other people, but are totally banned
from having any say in sorting out the aesthetics of the park.
-- Richard
Mohammad Khan
On Thu, 2004-10-14 at 13:13, Markus wrote:
> If I decide to lunch in the park, taking my sandwich and bag of
> assorted goodies to the shade of a likely tree, I may not, even in this
> idyllic environment, find everything to my liking. I could, of course,
> suffer silently. Or I could decide to change what fails to suit.
>
> placement of the trees, or the season, or the reasonable conduct of
> others in the park, the proper choice would be to suffer them silently.
> Digging up my chosen tree to replant closer to the creek would, by
> almost everyone's standards, by inappropriate.
>
> But by the same token, hardly anyone would claim that I ought not
> add the condiments of my choice to the sandwich I'm about to chew. Be
> they pickled hot peppers or strange sauces, the choice is, and should
> be, mine, and very few reasonable people would dispute that.
>
> The difference, it seems to me, is that redecorating the park may
> well affect--for better or worse--the enjoyment others take in it, while
> decorating the sandwich affects only me. Thus I can undertake the later
> on my own authority, but ought not undertake the former without
> consulting everyone.
>
> The reason for my bringing this up, if it isn't already apparent,
> is that I have noticed a recurring theme on this list: some people seem
> to assume that a ruby program's extending/modifying of ruby's core
> classes is more akin to mucking with the park than to modifying the
> sandwich. Note that I say "seem to assume" because I am frankly puzzled
> by their position and do not claim to fully understand it.
>
> At first I thought they were acting as if one pragmatic picnicking
> programmer putting pickled peppers on his or her sandwich was going to
> ruin the park for everyone. This seemed unreasonable in the extreme.
> What business is it of theirs if some people take advantage of a feature
> of the language they do not care to use? Even if they share an
> installation of ruby with the people who prefer peppers, the effects,
> there will be NO EFFECT visible to them and thus no harm.
>
> I subsequently came to suspect that they were perhaps being more
> reasonable than that, but acting on the basis of an assumption that I do
> no share: that the park was a better analogy than the sandwich, and that
> any "local" modifications to the core classes must perforce affect
> everyone. As I enumerated elsewhere (when I first formed this
> impression) changes (especially extensions) to the core classes can by
> made quite local, though the basic fact that they are limited to the
> program in which they occur seems to me to handle most of the
> objections.
>
> A third possibility is that they are aware that the pickled peppers
> only affect the sandwich they are put on, but they still don't want the
> other guy to use them because they might someday want to eat the other
> guys sandwich. This is kind of a stretch, since no one is forcing them
> to eat someone else's sandwich, and they are free to reject any that
> they don't like the taste of. But in some ways this theory best fits
> the data.
>
> A fourth possibility is that their objections are more akin to
> moralizing than to personal objections. It isn't that they believe they
> have any reason to object, but still, "it isn't right" and thus "people
> shouldn't do such things".
>
> None of these are clearly the right way to understand the
> situation, so I ask:
>
> Why the rabid objection to people putting broccoli on their
> sandwiches if they like it?
>
>
If you work for my sandwich franchise, you will have to make it the way
it comply with my company's procedure. Because, our sandwich already
have fame in the market. People don't see what's inside the sandwich
before eat, if it is from my store.
If you want to put broccoli or whatever you want, do it outside my
sandwich shop !
--
Mohammad Khan <mk...@lextranet.com>
Legal Computer Solutions, Inc.
Eivind Eklund
> > > Why the rabid objection to people putting broccoli on their
> > > sandwiches if they like it?
> >
> > Because people are putting sandwitches everywhere, and a lot of us are
> > forced to eat other people's for a variety of reasons.
>
Employers, generally.
> Do they have a gun?
No, they can only deny me food, so it's slower than that....
> If I write something you find distasteful, and even
> post it on the web, are you required to use it? Even if millions of
> others like it a start to use it, you don't have to if you don't want
> to.
I work in contexts where I have to accomplish things, and where I
cannot make all choices on my own. If I had infinite time, enough
food, and wasn't trying to get anything specific done, sure, I'd have
that choice.
Alas, I have to eat, and I'm only getting 86401 (or less) seconds per
day, and I've got stuff I want done. All of this cooperate to force
some of my choices.
James Britt
> If I'm desperately hungry, and there's a sandwich with creamed crab in
> peppered peanut sauce, I'll just take that creamed crab off and eat the
> part that doesn't make me gag. I will definitely warn all of my friends
> that this freak is making sandwiches with peanut butter and antifreeze
> simply because he can. My friends will probably avoid the freakish
> fabricator of crazed comestibles, leaving him to eat his razor blade
> and mouse poop sandwiches by himself.
I'm still thinking of a semi-coherent addition to this thread, but in
the meantime, a quick poll:
How many people ever expected to read the phrase "mouse poop sandwiches"
on ruby-talk?
I tell ya, this list has *everything*!
James
Markus
> I spent a bit of time trying to create a good but short example of truly
> wack Ruby code. Given that you can override core classes and methods,
> it is fairly easy to create code that bears only a superficial
> resemblance to Ruby, requiring the user to think instead in a new,
> Bizarro world mini-language. It requires nothing that doesn't already
> exist in Ruby. Yet one does not often see this sort of code in the wild.
You see it (at least I do) but you don't recognize it as "a new,
Bizarro world mini-language." Why? Because it's almost always done in
the context of some problem domain that already supports it (sometimes
with a history far predating ruby, or even computers). Thus anyone who
knows the language easily switches gears without even noticing.
> Truth is, the cat's out of the bag, the genie is out of the bottle, and
> the poop is out of the mouse. As new changes to the mallardability of
> Ruby are suggested, the question is not whether we want people to be
> able to do odd, weird, convoluted things; they already can. The
> question is will the changes enable or encourage odd, weird, convoluted
> things that are indeed appropriate for a given task.
Exactly.
> "Ruby: MPS-free for over 10 years!"
*laugh/gack* Not another TLA!
-- Markus
Eivind Eklund
<michael...@gmail.com> wrote:
> If this means we can have supernatural parks where sandwiches turn
> into were-sheep, I'm all for it. Sometimes people want languages
> that keep themselves from shooting themselves in the foot, and keep
> poor programmers from doing damage. Ruby is not that language, and
> that's why I like it.
I think Ruby does a very, very good job of making the good stuff easy
and the bad stuff (that's sometimes good in context) possible.
It manage to be very, very mutable while still keeping a lot of
structure. I love the combination, and I'm afraid of anything that
might endanger it. At present, Ruby is the best programming language
I've ever used, and fit almost all domains I touch. I've seen Ruby
being troublesome only for the following five domains:
- Speed critical code
- Systems code (kernel level code)
- Code that needs to run on systems Ruby isn't ported to
- Some code that does heavy integration of Unix commands (shell
scripts are presently better at some parts of that problem domain,
though I suspect a Ruby library could resolve that)
- Code that relies on libraries in legacy languages too much.
Code that is written in Ruby has a very clear "Ruby flavour", and
there is much less variation in style than there is in (for instance)
Perl code - because Ruby has already taken a lot of the fairly
irrelevant choices for the programmer. Shift arguments off @_ or
access $_[2] or use my ($arg1, $arg2) = @_? Not an issue - Ruby has
argument handling. Use a my $var = {} for easy refactoring or my %var
for shorter access? Not an issue - Ruby only do references. Etc.
I like this clear dominating flavour without losing flexibility
(because there is still more than one way to do it), and feel the
balance we have as precious. That's why I'm sceptical of changes that
"give the programmer more flexibility to rewrite the language".
> (now if we could only get something as good as CPAN in the core...but
> that's another story...)
I think we need something BETTER than CPAN for Ruby. I consider CPAN
to have serious issues with code maintenance, and have never really
been a fan of it (though I *do* like a number of aspects of it).
If you could list up the things you like about CPAN, let's see if we
can replicate them better (hopefully, they're already in the roadmap
for RPA, but if not, let's try to put them there :-)
Chad Fowler
> On Fri, 15 Oct 2004 22:59:06 +0900, Michael DeHaan
> > that's another story...)
>
> I think we need something BETTER than CPAN for Ruby. I consider CPAN
> to have serious issues with code maintenance, and have never really
> been a fan of it (though I *do* like a number of aspects of it).
>
Same here with RubyGems (http://rubygems.rubyforge.org). We've never
set CPAN as a target. Nothing _against_ CPAN, but if you're starting
from scratch, you might as well set your sites higher.
Chad
Brian Wisti
--- Hal Fulton <hal...@hypermetrics.com> wrote:
> And I in the meantime have Tom Lehrer's song running through my head,
> or a variant of it: "Poisoning Programmers in the Park."
>
>
"When they see us coming, the coders all try and hide.
But they still go for coffee when mixed with some cyanide.
The sun's shining bright, everything seems alright
When we're poisoning programmers in the park."
Thank you, I'm here all week. Try the veal.
-- Brian Wisti
vruz
--
--- vruz
David Ross
>I am but a new convert here (coming from many languages, but loving
>Perl most) ... so anyhow, first post for me.
>
>One of the thing that draws me deeper into Ruby is the ability to
>completely muck with the internals of the language, more so even than
>Perl (where symbol table manipulation, for instance, was common).
>Rewriting builtins or other modules via included modules is more
>automagical than what Java-fans would push on us with AOP (shudder) or
>reflection. And it's totally transparent. Nice!
>
>If this means we can have supernatural parks where sandwiches turn
>into were-sheep, I'm all for it. Sometimes people want languages
>that keep themselves from shooting themselves in the foot, and keep
>poor programmers from doing damage. Ruby is not that language, and
>that's why I like it.
>
>(now if we could only get something as good as CPAN in the core...but
>that's another story...)
>
>
>
There is a project that is CPAN-like, its called RPA. It ca be found at
The purpose is to offer high quality packages and provide excellent QA
of ports. It takes the tiem off developers hands and puts it in others
which are experts at packaging. You can also create your own packages
and run the command with a web address. It'll automatically fetch and
install the package. rpa-base does install ruby documentation, if any,
to the ri document location. rpa-base can even build any modules that
require non-ruby code to be compiled. Batsman(Mauricio Fernandez), is
also on irc. If you have any questions, stop by and they will be answered.
David Ross
trans. (T. Onoma)
| (now if we could only get something as good as CPAN in the core...but
| that's another story...)
I have heard this before, but I am not familiar with CPAN. What is so good
about it?
Thanks,
T.
David Ross
CPAN - www.cpan.org
Comprehensive Perl Archive Network
it contains many modules that can be used in perl programs. Programs are
also in CPAN. Though.. the modules are not maintained well and don't
really have a sense of QA. Some of the libraries or programs don't make
use of `use 5.8` so when I go run it on 5.6 it doesnt work, *yay*.
Basically its a gigantic library full of perl software that are not
maintained by any QA team, its maintained by the authors. So expect
things to work.. and not work.. I hope RPA can cover some of the
features that PAUSE explains in their webpages.
David Ross
Markus
I'd love to try the veal if the source code is available (you see,
I've heard some unkind things alleged about the coffee...).
-- Markus
Phil Tomson
http://www.usatoday.com/tech/techinvestor/industry/2004-10-14-programming-jobs_x.htm
It would be illegal to poison us in parks ;-P
Phil
James Britt
> On Fri, 2004-10-15 at 08:27, James Britt wrote:
>
>
>>I spent a bit of time trying to create a good but short example of truly
>>wack Ruby code. Given that you can override core classes and methods,
>>it is fairly easy to create code that bears only a superficial
>>resemblance to Ruby, requiring the user to think instead in a new,
>>Bizarro world mini-language. It requires nothing that doesn't already
>>exist in Ruby. Yet one does not often see this sort of code in the wild.
>
>
> You see it (at least I do) but you don't recognize it as "a new,
> Bizarro world mini-language." Why? Because it's almost always done in
> the context of some problem domain that already supports it (sometimes
> with a history far predating ruby, or even computers). Thus anyone who
> knows the language easily switches gears without even noticing.
Good point. I have some Ruby code that does XML transformations sing
the REXML pullparser. I started out mapping input elements and context
to new elements and context using Ruby hashes and arrays, but decided to
(ironically, I suppose) use YAML, because it made it a bit easier to see
that a) this was not really meant to be code as such (though of course
it was), and b) the syntax a bit cleaner for expressing the associations.
But there is likely an even more clear way to express the relationships,
a transformation mini-language syntax, that would not be out of place in
such a context.
From what I gather, no one thinks it worth the effort to devise a new
and arbitrary way to express common structures and behavior, but that
for the unusual case, unusual syntax works quite well because you may
want to explicitly encourage a mental context switch, a visual cue that
tells the reader, Look, this is code, but it's special-purpose code.
>
>
>>Truth is, the cat's out of the bag, the genie is out of the bottle, and
>>the poop is out of the mouse. As new changes to the mallardability of
>>Ruby are suggested, the question is not whether we want people to be
>>able to do odd, weird, convoluted things; they already can. The
>>question is will the changes enable or encourage odd, weird, convoluted
>>things that are indeed appropriate for a given task.
>
>
> Exactly.
>
>
>>"Ruby: MPS-free for over 10 years!"
>
>
> *laugh/gack* Not another TLA!
Well, actually, it's YATLI (yet another three-letter initialism)
James