I would love to see more interpreted languages offer shells with native constructs for operating as daily drivers shells (not just REPLs). When I first started learning Ruby I used `rush`[0] as my main shell. Being immersed in the language, even if there were a few helpers for shell operations, really helped me reason better about Ruby and think in the language. `scsh`[1] was enlightening as well. Ultimately the ergonomics of both pushed me back to more conventional variant but they were really helpful learning mechanisms.
But who cares really? I am not using Ruby for HPC. I use it for prototyping, oneliners for ETL and to glue different moving parts in a system or network together. That's it. Its not doing the heavy lifting anyways.
Yea. Modern Ruby is "fast enough", but it's very real that when Ruby was hitting its peak it was dog slow. It's hard to shake those sorts of reputations (similar to the "can't scale" reputation that Rails got because of Twitter)
The speed argument never convinced me in general, in that whether it is perl, ruby or python, they are all slower than C. So the comparisons really are odd to me.
The "scripting" languages should of course not try to be slow, but people rarely use them for speed-reasons; they use these languages for gains in productivity and ease of writing code, adding features and so forth. That should be the primary focus point.
In the future we may no longer have such a speed penalty anyway.
I would “up” this a little and say that scripting languages “should” be slow in comparison to low level compiled languages. We want eg. runtime evaluation of multis dependent on type. For (cod) example:
subset Even of Int where * %% 2;
subset Odd of Int where * !%% 2;
multi foo(Even $i) { ‘fizz’ }
multi foo(Odd $i) { ‘buzz’ }
say foo for ^9;
There's also "slow compared to C" and "slow enough that you notice when using it as an interactive shell". Running something like `Dir.each_child('.') {|x| p x}` in the interpreter completes in 1.3 milliseconds, which includes all the separate print calls. It could be much faster if we compute the string to print first and then only issue a single print call, but this is deliberately inefficient to show it doesn't matter in this usecase.
I wouldn't use Ruby for high performance computing. But for scripting (where runtime is not critical), web services (where transport latency will usually far outstrip the few milliseconds your handler takes) or shell use (where humans aren't fast enough to issue a new command every millisecond anyway), Ruby is more than fast enough.
Usually when I see a project flaunting its language like this it elicits a sigh. (You probably know what I am talking about.) This is a happy exception since this project actually promotes a deep integration with its language of choice, so the title and name are fully warranted. Kudos for that.
Your comparison is not quite optimised as you use () which is not
necessary. But I understand the comparison you make.
But, you can write an optimised pipe in ruby too. I actually did
that, because I could not want to be bothered to be restricted via
ruby's syntax for pipe-like operations.
Even aside from that, the original claim was about pipes versus
method chaining. To me these are not orthogonal to one another;
they are very similar. Just with the pipe focusing on tying together
different programs and focusing on input-output functionality.
Method chaining in ruby is a bit more flexible, we have blocks,
and usually the methods chained occur in one class/object or
the toplevel namespace (less frequently though, usually). Even
the pipe comparison is not ideal, because traditional UNIX pipes
don't support e. g. data manipulation via an object-oriented
focus. And I want that (see avisynth, but extend the idea there
via a) nicer syntax and b) data manipulation for EVERYTHING).
I don't see pipe as being exclusive over method chaining or
reverse.
One interesting idea was to add |> elixir's pipe-like operator
to ruby. I like that, but indeed, the net-gain in ruby is quite
minimal since method-chaining + blocks already offer a ton of
flexibility, so I am not sure how |> would fit into ruby 1:1.
Still I like the idea, but anyone proposing |> needs to come
up with really convincing ideas to matz here. Because people
WILL ask what the real difference is to method chaining. Even
fail-safe method chaining in ruby though I absolutely hate
the syntax via ? there ... it reads like garbage to me. Example:
(It has moved since then, so the above link no longer works,
been some years since I first saw it. Upon seeing it my brain
instantly cancelled any use of "&.", even though I understand
the rationale. It is just ugly to no ends. I still like the
|> syntax in Elixir though, even though I can not really see
what this should do in ruby.)
Note that I just elaborated what I thought was being asked. Parantheses - see what switching professionally to Ruby wonderland to Python does to a person! Just in about half a year needed..
But why would it be a first april article? Are there any arguments to be made for this statement? Because the shell works, I just tested it. It may not be everyone's cup of tea but that's always the case for any given software. The primary reason I use bash over, say, zsh, despite thinking zsh is more advanced, is that I use bash mostly because it is very simple. I like simplicity. (Bash could be even simpler, I would not mind. I don't use shell scripts for instance, ruby or python are much more convenient than shell scripts.)
Hmm. The name is a bit awkward since people can call
it "rubbish". The idea is also not quite new in that
many years ago people worked on an ruby-like shell
with OOP support from the get go and they used a
ncurses drop down box too. I forgot the name, but it
must have been before 2010 already, as I vaguely
remember it from talking on IRC back in those days.
I think the main developer was from South Africa, but
I don't remember that much anymore.
A few years ago irb got a facelift, so rubish probably
represents a more modern take on the shell concept.
I tested it and it works too. I wonder how much the
everything-is-an-object idea is extended here. Many
years ago I learned avisynth + virtualdub and I always
liked how they approached filtering. Ffmpeg is great,
but I absolutely hate the filter system it uses and the
ABSOLUTELY horrible syntax. The ffmpeg devs do not seem
to know avisynth, or any alternatives here - so I want
object manipulation with a convenient syntax at all times,
not just for audio/video data but literally for any data.
Naturally ruby would be a good fit by default, but I am
unaware of many ruby developers even wanting to go that
route. If there are still any ruby developers left that
is - ruby has been tanking hard in the last few years,
approaching extinction level, just like perl did before.
There has to be a better influx of new users; the old
+50 years generation isn't going to keep languages alive
really.
Edit: Also I forgot: the idea and implementation is fine,
I just think we need much more of that in general. Ruby is
kind of in a patchy patchwork situation. Where are the epic projects? Rails is also ancient already.
Tangential:
I would love to see more interpreted languages offer shells with native constructs for operating as daily drivers shells (not just REPLs). When I first started learning Ruby I used `rush`[0] as my main shell. Being immersed in the language, even if there were a few helpers for shell operations, really helped me reason better about Ruby and think in the language. `scsh`[1] was enlightening as well. Ultimately the ergonomics of both pushed me back to more conventional variant but they were really helpful learning mechanisms.
0: https://github.com/adamwiggins/rush 1: https://github.com/scheme/scsh
People think Ruby is a slow language, but little do they know Ruby is a slower language than Go. But ruby these days is faster than Python.
But who cares really? I am not using Ruby for HPC. I use it for prototyping, oneliners for ETL and to glue different moving parts in a system or network together. That's it. Its not doing the heavy lifting anyways.
when ruby was trendy the 1.9 branch was still cooking so in a lot of people's mind it is veery slow
Yea. Modern Ruby is "fast enough", but it's very real that when Ruby was hitting its peak it was dog slow. It's hard to shake those sorts of reputations (similar to the "can't scale" reputation that Rails got because of Twitter)
The speed argument never convinced me in general, in that whether it is perl, ruby or python, they are all slower than C. So the comparisons really are odd to me.
The "scripting" languages should of course not try to be slow, but people rarely use them for speed-reasons; they use these languages for gains in productivity and ease of writing code, adding features and so forth. That should be the primary focus point.
In the future we may no longer have such a speed penalty anyway.
I would “up” this a little and say that scripting languages “should” be slow in comparison to low level compiled languages. We want eg. runtime evaluation of multis dependent on type. For (cod) example:
There's also "slow compared to C" and "slow enough that you notice when using it as an interactive shell". Running something like `Dir.each_child('.') {|x| p x}` in the interpreter completes in 1.3 milliseconds, which includes all the separate print calls. It could be much faster if we compute the string to print first and then only issue a single print call, but this is deliberately inefficient to show it doesn't matter in this usecase.
I wouldn't use Ruby for high performance computing. But for scripting (where runtime is not critical), web services (where transport latency will usually far outstrip the few milliseconds your handler takes) or shell use (where humans aren't fast enough to issue a new command every millisecond anyway), Ruby is more than fast enough.
Oh my god this is the best name to the application. You win the weekend.
Exactly. Very clever name!
Usually when I see a project flaunting its language like this it elicits a sigh. (You probably know what I am talking about.) This is a happy exception since this project actually promotes a deep integration with its language of choice, so the title and name are fully warranted. Kudos for that.
Cool project!
Just for fun, looking at code count as a rough measure of complexity.
rubish: 26,842
rc (plan9 shell): 5,888
To be fair, rubish does a lot more than rc. rc is pretty minimal.
rc source:
https://github.com/9front/9front/tree/front/sys/src/cmd/rc
Measures below:
rc:I much prefer the pipe to method chaining.
Could this be elaborated?
ls | grep file.txt vs ls().grep("file.txt")
Your comparison is not quite optimised as you use () which is not necessary. But I understand the comparison you make.
But, you can write an optimised pipe in ruby too. I actually did that, because I could not want to be bothered to be restricted via ruby's syntax for pipe-like operations.
Even aside from that, the original claim was about pipes versus method chaining. To me these are not orthogonal to one another; they are very similar. Just with the pipe focusing on tying together different programs and focusing on input-output functionality. Method chaining in ruby is a bit more flexible, we have blocks, and usually the methods chained occur in one class/object or the toplevel namespace (less frequently though, usually). Even the pipe comparison is not ideal, because traditional UNIX pipes don't support e. g. data manipulation via an object-oriented focus. And I want that (see avisynth, but extend the idea there via a) nicer syntax and b) data manipulation for EVERYTHING).
I don't see pipe as being exclusive over method chaining or reverse.
One interesting idea was to add |> elixir's pipe-like operator to ruby. I like that, but indeed, the net-gain in ruby is quite minimal since method-chaining + blocks already offer a ton of flexibility, so I am not sure how |> would fit into ruby 1:1. Still I like the idea, but anyone proposing |> needs to come up with really convincing ideas to matz here. Because people WILL ask what the real difference is to method chaining. Even fail-safe method chaining in ruby though I absolutely hate the syntax via ? there ... it reads like garbage to me. Example:
https://github.com/ruby/ruby/blob/trunk/test/ruby/test_threa...
(It has moved since then, so the above link no longer works, been some years since I first saw it. Upon seeing it my brain instantly cancelled any use of "&.", even though I understand the rationale. It is just ugly to no ends. I still like the |> syntax in Elixir though, even though I can not really see what this should do in ruby.)The docs literally says that the () on the first ls is required.
Note that I just elaborated what I thought was being asked. Parantheses - see what switching professionally to Ruby wonderland to Python does to a person! Just in about half a year needed..
Good April 1 article.
But why would it be a first april article? Are there any arguments to be made for this statement? Because the shell works, I just tested it. It may not be everyone's cup of tea but that's always the case for any given software. The primary reason I use bash over, say, zsh, despite thinking zsh is more advanced, is that I use bash mostly because it is very simple. I like simplicity. (Bash could be even simpler, I would not mind. I don't use shell scripts for instance, ruby or python are much more convenient than shell scripts.)
Is it just me of did others also read rubbish instead of rubi-sh...I think that might be the joke. hm...
The repository owner is a true ruby hero. I am not sure if the name is a joke, and he was just fooling around, but the code is real.
Hmm. The name is a bit awkward since people can call it "rubbish". The idea is also not quite new in that many years ago people worked on an ruby-like shell with OOP support from the get go and they used a ncurses drop down box too. I forgot the name, but it must have been before 2010 already, as I vaguely remember it from talking on IRC back in those days. I think the main developer was from South Africa, but I don't remember that much anymore.
A few years ago irb got a facelift, so rubish probably represents a more modern take on the shell concept. I tested it and it works too. I wonder how much the everything-is-an-object idea is extended here. Many years ago I learned avisynth + virtualdub and I always liked how they approached filtering. Ffmpeg is great, but I absolutely hate the filter system it uses and the ABSOLUTELY horrible syntax. The ffmpeg devs do not seem to know avisynth, or any alternatives here - so I want object manipulation with a convenient syntax at all times, not just for audio/video data but literally for any data. Naturally ruby would be a good fit by default, but I am unaware of many ruby developers even wanting to go that route. If there are still any ruby developers left that is - ruby has been tanking hard in the last few years, approaching extinction level, just like perl did before.
There has to be a better influx of new users; the old +50 years generation isn't going to keep languages alive really.
Edit: Also I forgot: the idea and implementation is fine, I just think we need much more of that in general. Ruby is kind of in a patchy patchwork situation. Where are the epic projects? Rails is also ancient already.