Eating sandwiches in the park

[Eivind Eklund]

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

Eivind.

 

[Chad Fowler]

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

 

[James Britt]

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.

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.

I, too, have been earning a living using Java. It's not so much
stressful as boring. I, too, am expected to be conversant with far too
many tedious frameworks and APIs and XML formats and vendor
implementation quirks. But I guess that's why they call it work.

There are numerous reasons why such-and-such a tool, app, lib, or
whatever might be mandated. The typical case is management
misunderstanding of the difference between technical value and corporate
hype. Sometimes it's more like betamax vs VHS; something just
happens to gain traction, and the network effect kicks in. Worse is
better, or worse is worse but too damn bad, or something like that.

But you still have to wonder why mouse poop sandwiches are so common,
and it may be that a given language does not readily lend itself to a
clear expression of subtle ideas, so garish hacks are needed.

People generally make a good-faith effort to solve a problem in a clean
way, but the nature of B&D languages is such that anything out of the
ordinary is considered irresponsible, and so should be hard to do.

It will also motivate others to write a replacement. And if that never
happens, it may be because the language makes it hard to do it; the pain
of using the bad features of given lib or tool is still less than the
pain of trying to devise a better alternative.

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.

All in all, Ruby gives one plenty of opportunity to write painful code.
This is probably true of any reasonably complete programming language.
Ken Arnold has recently written an article (well, an
op-ed piece), "Style is Substance" [0] wherein he argues that languages
should be so restrictive that code formatting anomalies should be treated
as compiler errors. Really. In his world, writing if(foo) instead of
if (foo) would cause a program to fail. Illegal syntax. (I'm not sure
if he would allow if ( foo ), though.)

I find that intriguing but psychotic. It is double-plus ungood. I
guess I'm one of those who prefer not emulate a machine, one who tends
to think of code as being more like music or painting than an endless
sequence of text existing only to please the compiler gods. But maybe
it's just a personal quirk.

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.

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.

A while ago I decided I wanted to be able to code in a message-oriented
style, where one would specify a message, and dispatch it to any and all
objects, at once, without know the specific receivers.

Instead of receiver.message( args ...) it would be
message(args ...)->/some dynamic criteria for target receivers/

So I could, for example, send the 'close' message to all open File
objects, without having to know where they were or what they were called.

I had a hard time scheming up nice syntax for this, and I suspect the
ability to define free-form operators would have been quite handy.

I find that the arguments for allowing such things are more persuasive
than those calling for a more restrictive or conservative approach. I
tend to believe that misuse will simply be lost to the ages because Ruby
makes it easier to just re-write bad code; if any one devises a
super-useful lib that just happens to have an MPS (mouse poop sandwich)
implementation, it will simply get fixed faster then it would in, say
Java or Perl.

"Ruby: MPS-free for over 10 years!"

James

[0] http://www.artima.com/weblogs/viewpost.jsp?thread=74230

 

[David Ross]

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.

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 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

 

[James Britt]

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.

*laugh/gack* Not another TLA!

Well, actually, it's YATLI (yet another three-letter initialism)

James

 

[Brian Wisti]

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

 

[Markus]

"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

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

 

[vruz]

mayonnaise, anyone ?

 

[Phil Tomson]

"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

Now that US programmers are classified as an endangered species...
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