=20
This looks interesting, although I would only use it if I need a shell
framework. You do not mention a few downsides of ripl:
=20
- it is not automatically there as IRB is because it's part of a
standard Ruby installation (or present in the package system)
So... you only advocate using 100% ruby-core + stdlib. Right.
And they didn't need to learn irb. That's a ridiculous point to try to =
make. You have to learn EVERY tool and EVERY library you use.
Also, I don't find the argument of 5,000 vs. 270 loc very appealing:
every software acquires some "weight" as it grows older. Even if
ripl's core does not gain that much - the gain then simply will be in
the plugins. Over time the loc gap will likely shrink so this is at
best a temporary argument.
Well, that's entirely inane. You've obviously never looked at the guts =
of irb.
IRB _started_ at 5k (actually ~7k) and has been monotonically increasing =
every since:
3063 % find ruby_1_6/lib/irb* -type f | xargs wc -l | tail -1
7779 total
3064 % find ruby_1_8_6/lib/irb* -type f | xargs wc -l | tail -1
11136 total
3065 % find ruby_1_8_7/lib/irb* -type f | xargs wc -l | tail -1
12519 total
3066 % find ruby_1_9_2/lib/irb* -type f | xargs wc -l | tail -1
16052 total
It is to the point where it is downright _painful_ to try to maintain, =
much less enhance.
If ripl starts at 270 lines, it isn't even in the same league (in a good =
way) as irb. That means that it'll be orders of magnitude easier to =
understand (more than really; the complexity in a system like this is =
probably geometric, if not exponential).
Side note: funnily enough I have become more conservative in the
course of time; maybe it's because I see the cost of change clearer
nowadays. At least I rather invest energy in new things that are
needed than in creating replacements for things that work. Probably
I'm approaching grumpy old man state...
apparently. grumpy irrational old man at that...=
