Hey!
I’m relatively new to Ruby, but for damn sure consider it
the most important language to the future development of operating
systems.
Is there any material out there on this?
Or does anybody have any thoughts or experience?
I keep thinking that if all the Bash scripts in FreeBSD instead were to
be
Ruby, things would take less code and perhaps even move faster.
I’m sure there are other parts that could be replaced by Ruby as well,
anybody know?
All the best,
Kyrre
Have a look at Heretix:
http://www.h-e-r-e-t-i-x.org/doc/website/AboutHeretix.html
It’s a source based Linux distro that uses Ruby for all it’s setup.
Farrel
On Jun 9, 2006, at 9:51 AM, Kyrre N. wrote:
I keep thinking that if all the Bash scripts in FreeBSD instead
were to be
Ruby, things would take less code and perhaps even move faster.
I wouldn’t be so quick to dismiss the value of shell scripting
languages. They target a different problem space: gluing programs
together. It’s easy to write shell scripts using redirection and
pipes that would be significantly bigger when translated to Ruby.
James Edward G. II
At 17:21 09.06.2006, James Edward G. II wrote:
James Edward G. II
Hello James,
You’re making a good point here. But to me it feels like a “if it works
don’t fix it” kind of thing. I mean, all in all, wouldn’t Ruby prevail?
Feel free to show me some examples though.
Also, what if this operating system were to use a Ruby shell?
All the best,
Kyrre
At 16:57 09.06.2006, Farrel L. wrote:
Have a look at Heretix:
http://www.h-e-r-e-t-i-x.org/doc/website/AboutHeretix.htmlIt’s a source based Linux distro that uses Ruby for all it’s setup.
Farrel
Thanks Farrel, thanks a lot 
On Friday 09 June 2006 15:51, Kyrre N. wrote:
I keep thinking that if all the Bash scripts in FreeBSD instead were to be
Ruby, things would take less code and perhaps even move faster.
I’m sure there are other parts that could be replaced by Ruby as well,
anybody know?
Don’t forget the portupgrade tool is written in Ruby. It’s not part of
the
base system but it might as well be - virtually everyone uses it.
I started thinking I might start writing shell scripts in Ruby but I
realised
for most simple cases, standard bourne shell is easier. It’s only when
you
get to complex variable handling or lots of control structures Ruby’s
advantage takes over.
Ashley
On Jun 9, 2006, at 10:52 AM, Kyrre N. wrote:
Feel free to show me some examples though.
Well, try anything were you need to write to STDIN of an external
process, read it’s STDOUT and STDERR, and check its return code.
Shells make that pretty trivial.
James Edward G. II
On Sat, Jun 10, 2006 at 12:21:25AM +0900, James Edward G. II wrote:
James Edward G. II
Also, some people are wary of having the “core”* functionality
dependent on complex technologies that are in a state of flux.
It can be pretty annoying if a “minor” language version upgrade
results in syntax errors all through the core system, while most
shells have had a stable, dependent “base language” for ages.
I seem to remember some distro (I think it was debian or one of
the *bsds) wanted to remove perl dependencies from the base os
for the same reason. That was a couple of years ago and I can’t
seem to find any reference to that story now.
Joost.
Louis J Scoras wrote:
Question (maybe a bit off-topic):
The example may be quick, but in what way is it dirty?
More generally, why do those two words get used as if they were joined
at the hip? Is there a bias against being quick, a belief quick only
comes at the cost of clean code?
This “quick and dirty” dismissal comes up fairly often when describing
Ruby to the skeptical (“Well, Ruby may be good for quickandirty scripts,
but …” ).
My usual response is that I prefer quick and dirty to slow and dirty;
Java or C# (the usual suggested alternatives for “real” programming)
offer no more assurance of clean code than using Ruby; indeed, the
opposite is likely more the case.
Just curious.
–
James B.
“Programs must be written for people to read, and only incidentally
for machines to execute.”
At 17:21 09.06.2006, James Edward G. II wrote:
I wouldn’t be so quick to dismiss the value of shell scripting
languages. They target a different problem space: gluing programs
together. It’s easy to write shell scripts using redirection and
pipes that would be significantly bigger when translated to Ruby.
Precisely as James said. This is part of the Unix Philosophy and
what makes command-line interfaces so powerful. Well behaved programs
can be used in pipelines to do far more than their creators originally
intended.
On 6/9/06, Kyrre N. [email protected] wrote:
You’re making a good point here. But to me it feels like a “if it works
don’t fix it” kind of thing. I mean, all in all, wouldn’t Ruby prevail?Feel free to show me some examples though.
# mp32ogg [untested] - quick and dirty conversion:
mpg321 -w - somesong.mp3 | oggenc -o somesong.ogg -
Also, what if this operating system were to use a Ruby shell?
I believe this has been tried w/ several different languages before.
You could do it, but it’s not awefully convienent because most general
purpose languages weren’t designed for this (i.e.: they can’t be typed
as quickly).
James B. wrote:
Louis J Scoras wrote:
Question (maybe a bit off-topic):
The example may be quick, but in what way is it dirty?
More generally, why do those two words get used as if they were joined
at the hip? Is there a bias against being quick, a belief quick only
comes at the cost of clean code?This “quick and dirty” dismissal comes up fairly often when describing
Ruby to the skeptical (“Well, Ruby may be good for quickandirty scripts,
but …” ).My usual response is that I prefer quick and dirty to slow and dirty;
Java or C# (the usual suggested alternatives for “real” programming)
offer no more assurance of clean code than using Ruby; indeed, the
opposite is likely more the case.Just curious.
–
James B.“Programs must be written for people to read, and only incidentally
for machines to execute.”
- H. Abelson and G. Sussman
(in "The Structure and Interpretation of Computer Programs)
I’d have to agree in Java you are just as likely to scan hundreds of
lines looking for that missing curly bracket as you are in ruby to
search for a missing closure, and static typing brings up it’s own
problems just as much as duck typing.
On 6/9/06, James B. [email protected] wrote:
Question (maybe a bit off-topic):
The example may be quick, but in what way is it dirty?
It is “quick and dirty” in that it is an incomplete solution in-so-far
as converting between the two formats in the most general sense. That
is, if one were to stick that line into a file, chmod +x mp32ogg, it
wouldn’t be very featureful (setting bit rates, meta information, et
cetera).
Then again, the whole point is the flexibility of using two or more
programs in all sorts of original and interesting ways. If all I want
is to change the encoding, the above suffices admirably. There’s no
reason that extra options couldn’t be specified either.
More generally, why do those two words get used as if they were joined
at the hip? Is there a bias against being quick, a belief quick only
comes at the cost of clean code?
I think I used that phrase because for as much as I hate them, I am
weak and easily fall into the temptation of using cliches smirks.
This “quick and dirty” dismissal comes up fairly often when describing
Ruby to the skeptical (“Well, Ruby may be good for quickandirty scripts,
but …” ).My usual response is that I prefer quick and dirty to slow and dirty;
Java or C# (the usual suggested alternatives for “real” programming)
offer no more assurance of clean code than using Ruby; indeed, the
opposite is likely more the case.
I totally agree; don’t get me wrong. I gave the example as a positive
one. When presented with a problem, the first thing I often try is to
see if I can’t pull a solution right on the command line.
On Sat, 2006-06-10 at 02:54 +0900, James B. wrote:
Question (maybe a bit off-topic):
The example may be quick, but in what way is it dirty?
Personally, I tend to use ‘quick and dirty’ when I really mean
‘only-lightly-tested’. As in: “Here’s a solution that seems to work”
rather than just “Here’s a solution”.
Also, a lot of scripts I write for myself are ‘quick and dirty’. Mostly
they work, but I don’t actually remember how with all of them 
Louis J Scoras wrote:
On 6/9/06, James B. [email protected] wrote:
More generally, why do those two words get used as if they were joined
at the hip? Is there a bias against being quick, a belief quick only
comes at the cost of clean code?I think I used that phrase because for as much as I hate them, I am
weak and easily fall into the temptation of using cliches smirks.
I didn’t mean to single you out; I hear it all the time, and use it
myself without thinking, and it struck that it may get used (by most
people) more from habit and bias than astute observation.
Maybe there is some value in calling people on it when they use it to
bring some awareness: quick != dirty, and the choice to omit various
behavior (robust error handling, for example) is not always a sign of
weakness. The cost of such behavior may be greater than its value.
–
James B.
“A principle or axiom is of no value without the rules for applying it.”
On Jun 9, 2006, at 18:54, James B. wrote:
Question (maybe a bit off-topic):
The example may be quick, but in what way is it dirty?
More generally, why do those two words get used as if they were
joined at the hip? Is there a bias against being quick, a belief
quick only comes at the cost of clean code?
I think it’s a linguistic quirk of English more than anything else.
Like the canonical example of ‘kick the bucket,’ it’s an expression
that doesn’t quite parse for native speakers if you substitute
otherwise-equivalent words or grammatical constructions. For example
“quick and grubby”, “speedy and dirty” or “fast and filthy” don’t
quite have the same meaning (though I do like that last one quite a
bit).
In my experience, ‘quick and dirty’ doesn’t necessarily mean bad -
a quick and dirty meal can be tasty - it’s more a description of the
process or role of the activity; informal, slightly tangential to
your goals, but has to be done anyway. In other words, it’s the
means to an end rather than an end in and of itself. And Ruby is
really good at that sort of programming, precisely because it’s quick.
My usual response is that I prefer quick and dirty to slow and
dirty; Java or C# (the usual suggested alternatives for “real”
programming) offer no more assurance of clean code than using Ruby;
indeed, the opposite is likely more the case.
Regardless of the speaker’s intention, I think that’s a great
response. Even better if the phrase is just being used as an idiom,
since it focuses the speaker’s attention on what ‘dirty’ code would
actually mean.
matthew smillie.
On 6/9/06, James B. [email protected] wrote:
Louis J Scoras wrote:
I think I used that phrase because for as much as I hate them, I am
weak and easily fall into the temptation of using cliches smirks.I didn’t mean to single you out; I hear it all the time, and use it
myself without thinking, and it struck that it may get used (by most
people) more from habit and bias than astute observation.
Oh I know. I was just trying to poke some light-hearted fun at myself
=). I didn’t take it as being singled out. To go totally off-topic
here, I think the worst is “step up to the plate.” Seriously, it
makes it very difficult to enjoy watching “The Apprentice”.
Maybe there is some value in calling people on it when they use it to
bring some awareness: quick != dirty, and the choice to omit various
behavior (robust error handling, for example) is not always a sign of
weakness. The cost of such behavior may be greater than its value.
Very well said. I would say that “dirty” implies “unpolished”, not
“unclean”, and I agree with you–in some circumstances robustness is
certainly less important than getting the job done. As Ken Thompson
said: “When in doubt, use brute force.”
On 6/9/06, Kyrre N. [email protected] wrote:
Hey!
I’m relatively new to Ruby, but for damn sure consider it
the most important language to the future development of operating systems.Is there any material out there on this?
Or does anybody have any thoughts or experience?
Syllable (http://www.syllable.org/ – an alternative BeOS-like OS,
forked from Atheos) for now uses Ruby for at least a couple
substantial tools (the “Installer” and “Builder” apps I believe), and
probably for many more smaller system tools. They’ve got 1.8.4 running
there. I think they also use regular bash scripts for lots of other
stuff, like everyone else.
It seems that there was some interest in integrating Io into the OS
for a while, but then (quite recently) they decided to use REBOL
instead. I think part of the idea is that, besides using it for
command line scripts, they will provide a slick way to also write
Syllable apps using REBOL and their own IDE (called “sIDE”). The open
source implementation they’re using is called Orca (possibly more info
here: http://wsrebol.sourceforge.net/ ).
That said, I’m sure they wouldn’t mind having someone write some nice
Ruby-libsyllable bindings, just to give REBOL a run for its money. 
They might even have some Ruby bindings already underway – dunno.
On 6/9/06, John G. [email protected] wrote:
Syllable (http://www.syllable.org/ – an alternative BeOS-like OS,
forked from Atheos) for now uses Ruby for at least a couple
substantial tools (the “Installer” and “Builder” apps I believe), and
probably for many more smaller system tools.
I’m planning on doing what I can to make Ruby a major scripting
language for Haiku[1], the open source recreation of BeOS. Mostly this
is just combining some of my two favorite things in the tech world:
Ruby and BeOS. If other people like it, great.
Ryan
I’m producing a fine Env, Linux based using the Ruby magic.
I’m looking for a team so see skp-it.eu (en version).
I pretty much gave up on shell scripting about a decade ago. I was so
used to real programming languages with real syntax that I only used
shell scripting for “quick and dirty hacks”. As far as I’m concerned,
anything with a loop or an if-then-else in it is worthy of a real
programming language with a real syntax and semantics.
Shells were an improvement over JCL, to be sure. And the C shell was
better than the Bourne shell, KSH and Bash are better than the C shell,
in terms of programmability and readability.
But once Perl (4) came along, I tossed out “awk” and “sed” and even
“grep” for the most part. I still type stuff like
du -sm * | sort -k 1 -nr | more
and
emerge -puvDN world 2>&1 | tee world-update.log
at the command line, but if it’s a program, it goes into a script with
comments and configuration management, etc., and it’s written in Perl. I
fully intend to learn Ruby as a Perl replacement, but for now, the
neurons fire in Perl.
James Edward G. II wrote:
James Edward G. II
–
M. Edward (Ed) Borasky
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs