Considering all of the learning required to go from Perl5 to Perl6 and the fact that Perl6 probably won't exist for a couple more years, I wonder if the growth in Ruby users (traffic is steadily growing on comp.lang.ruby) is attributable to Perl folks jumping ship?
Ruby seems to offer a lot to current Perl programmers, especially when it comes to OO programming - I don't think anyone will argue that Ruby's OO model is much cleaner and more beautiful than Perl's.
Perl6 does seem to have some promising features (like being able to define grammars as shown in the current exegesis) though.... however, I suspect that these ideas don't require wholesale changes to a language (this could be a Ruby module for example).
I'm hearing a lot of positive things about OSX and would really like to start running it at home (I'm pretty sure that my wife would prefer to use OSX instead of Mandrake Linux that she currently uses)... but I consider new Macs to be too pricey, so I'm looking into used Macs.
So what is the 'oldest' (cheapest) Mac that can run OSX? (and what is the oldest/cheapest Mac that can run it effectively)
My parents called me up a few months ago and asked me to find a new computer for them - their old Pentium 100 running Win95 finally died.
I told them that I could put together a system for them, but that it would not include Windows and they seemed to be open to that idea. Basically all they need to do is email, web surfing and some word processing so I figured that Linux was ready.
I put Lycoris on their new box and delivered it to them a month ago - so far it's working fine for them.
Now, of course they want to hook up their digital camera and an all-in-one scanner/printer, so there could be some challenges ahead.
However, if your computer-challenged parent just needs to connect to the net, send email, surf and do some simple word processing, I don't see why they can't use Linux at this point.
So what's the problem? Jesus himself was Jewish as were all of the first Christians. Christianity was originally considered to be a branch of Judaism which believed that the Messiah was Y'Shua (Jesus).
Having done actual hardware designs (used to be a hardware engineer - now I've crossed over to the software side) targetting ASIC and FPGAs with both schematics and VHDL, I'd have to say that your facts aren't quite right.
In all probability when you use schematic capture these days (which is becoming rare) the schematic gets translated into what's called a 'structural' netlist which gets translated into either VHDL or Verilog and then passed on to your synthesis tool. Or, perhaps you get an EDIF netlist from your schematic capture tool and pass it to the synthesis tool (though most would probably be converting EDIF to something else).
Now, I can only agree with your point in so far as with schematics you do tend to have to instantiate every little gate in your design so you do (might) end up with sort of a hand optimized design (perhaps). However: 1) You can do this with VHDL or Verilog as well by writing your critical sections in a structural style. 2) With the current state of synthesis tools I would tend to trust them to do a better job of optimization than I can do. 3) You're not going to design anything sizable (like a real microprocessor) in a structural style or with schematics - it would take like forever and never get done. That's pretty much what we were doing back in the '80's - designs now are much to big to have to lay down individual gates.
The trend is always toward higher levels of abstraction (just like in software - we don't develop sizable pieces of software in assembler anymore). In fact, some of the newer C/C++ based hardware design methodologies seem to be pushing to even higher levels of abstraction than VHDL or Verilog (see: http://www.systemc.org )
I tend to agree that "this will mark the decline of perl", but I'm not sad about it. It's progress. Perl just doesn't cut it when it comes to OO design - sure you can do OO in Perl, but it's so UGLY. (And I used to like Perl a lot).
"how many here are using ruby?" I am! After doing OO Perl for a while I find Ruby to be oh so much cleaner.
"There is Like no Documentation on it" Hmmm.... let's see there are five English language books on Ruby now: "Programming Ruby: The Pragmatic Programmer's Guide" "Ruby In a Nutshell" (by Matz himself) "The Ruby Way" "The Ruby Developer's Guide" "Teach Yourself Ruby in 21 days" (actually very good book)
And in fact the full text of "Programming Ruby" can be read online at http://rubycentral.com
I'm not sure how you can say there's no documentation.
"and most bindings are buggy" I'm not sure what you mean by 'bindings' here.
"There are lots of features part of Python which have no counterpart in Ruby"
Such as?
(lets see, docstrings, tuples, what else?)
The same thing could be said the other way:
Ruby has features which have no counterpart in Python (of course Python 2.2 added some of these features (like iterators and a more unified type/class system (but Ruby had these from day one) )- but since they've been added so late in the game Python's built-in libs do not use them, so you end up with a patchwork of Python pre 2.2 and PYthon post 2.2. As mentioned, Ruby had a unified type/class system from day one meaning you could extend and subclass built-in types from the start. Ruby also had iterators from the start as well - the significance being that Ruby's collection classes (like Array and Hash) use iterators. Python couldn't till now.
True, Ruby doesn't have multiple inheritance. But as you point out using Ruby's mixin feature (allows you to mix a module into a class thereby adding a module's behavior to a class) can often be used in place of MI.
Using MI tends to get messy anyway, especially when you end up with some kind of diamond inheritance tree. I personally tend to avoid MI even in languages that allow me to do it. I have to say that I much prefer Ruby's approach of using Mixins.
Actually, O'Reilly already seems to have a couple of books that are oriented towards teaching Biologists Perl programming. I'd like to see a book targeted towards programmers who are interested in exploring bioinformatics (so it would assume you already know how to program). It would be oriented towards teaching some of the needed biology/genetics concepts to Programmers interested in the field of bioinformatics.
There are some excellent Ruby titles recently available:
"The Ruby Way" by Hal Fulton
"The Ruby Developer's Guide" by Micheal Neuman
...in addition to the two others already available.
But I suspect that you're right - there will be room for more Ruby titles that cover specfic areas, like dRuby.
Also, how about:
*Ruby for PDAs
*Creating Servlets with Ruby and Webrick
_OR_
*Web services with Ruby and Webrick
I also think the Parrot idea is good - about a year from now it should be starting to have an impact so a book on Parrot released around then should do well.
They're including encryption, so there must be some worry that the neighbors could tap into your network. What's the range? Would this be alternative to the 802.11 wireless WANs?
Peer2Peer networking with each house acting as a peer?
OK, I guess Java is kind of popular out there, but not as much in the Linux community or open source communities.
I think Ruby would be an excellent choice of programming languages for this thing. Ruby:
*is small - less than 800K (can be made even smaller if you get rid of a few libraries that you may not need)
*is Free (as in Open Source)
*has Qt bindings
*is easy to write distributed apps in dRuby - this would especially be good if they can get a wireless link for this thing.
*has reasonable performance
*is (IMHO) a much nicer language to program in than Java.
* There's iterators & blocks
*A unified class/type system (meaning you can extend built-in types like String,Array,Hash,Kernel, etc)
* fully OO - 42.times { |i| puts i }
but it doesn't get in the way when you don't want OO, like it seems to with Java.
* Design patterns - Observable,Delagator,Singleton,...
* dRuby - Ruby's very easy to use distributed object system.
For now it's great fun, hopefully someday it'll pay the bills too.;-)
Certainly valid fears, but when one cogently presents the advantages of Ruby over, say, Perl (much better maintainability for one, I can go back to my Ruby code after a month and know right away what the script was doing, takes longer with Perl) oft times management will let you experiment.
Two different groups within the organization where I work recently started using Ruby (niether knew that the others were using it, they were stealth projects till recently). One of the groups convinced their management to let them rewrite much of their infrastructure (currently in Perl) in Ruby.
The moral of the story: It can't hurt to try. We are the engineers, if we actually think that Ruby can offer us significant advantages its up to us to sell management.
Don't get me wrong, I use Perl too, but I'm using it less and less these days. I've been programming in Ruby since about the start of the year and these are the advantages I find:
1) RUby has much nicer OO syntax than Perl - advantage is that when you go back to read the code after a month you can tell what's going on.
2) Perl's alarm doesn't work on the windoze platforms (sometimes in the corporate environement they make you use windoze), Ruby's timeout does.
3) Threads - With perl you actually have to compile a special threaded version. Ruby threads work - even on windoze.
4) Ruby has dRuby a distributed object system that is very easy to use (compared to SOAP, and other XML based approaches).
5) Hashes, arrays, strings have many more builtin functions (methods since they are objects) than Perl's Hashes, arrays and strings.
6) ease of writing extensions in C for Ruby(though Perl's Inline is supposed to make this a lot easier than it was in Perl)
And then there are lots of other things like about RUby like iterators, the ability to extend buit-in classes, built-in support for some design patterns.
Slashdot Mirror
Considering all of the learning required to go from Perl5 to Perl6 and the fact that Perl6 probably won't exist for a couple more years, I wonder if the growth in Ruby users (traffic is steadily growing on comp.lang.ruby) is attributable to Perl folks jumping ship?
Ruby seems to offer a lot to current Perl programmers, especially when it comes to OO programming - I don't think anyone will argue that Ruby's OO model is much cleaner and more beautiful than Perl's.
Perl6 does seem to have some promising features (like being able to define grammars as shown in the current exegesis) though.... however, I suspect that these ideas don't require wholesale changes to a language (this could be a Ruby module for example).
I'm hearing a lot of positive things about OSX and would really like to start running it at home (I'm pretty sure that my wife would prefer to use OSX instead of Mandrake Linux that she currently uses)... but I consider new Macs to be too pricey, so I'm looking into used Macs.
So what is the 'oldest' (cheapest) Mac that can run OSX? (and what is the oldest/cheapest Mac that can run it effectively)
My parents called me up a few months ago and asked me to find a new computer for them - their old Pentium 100 running Win95 finally died.
I told them that I could put together a system for them, but that it would not include Windows and they seemed to be open to that idea. Basically all they need to do is email, web surfing and some word processing so I figured that Linux was ready.
I put Lycoris on their new box and delivered it to them a month ago - so far it's working fine for them.
Now, of course they want to hook up their digital camera and an all-in-one scanner/printer, so there could be some challenges ahead.
However, if your computer-challenged parent just needs to connect to the net, send email, surf and do some simple word processing, I don't see why they can't use Linux at this point.
--don't panic
"isn't Mulder presumed to be Jewish?"
So what's the problem? Jesus himself was Jewish as were all of the first Christians. Christianity was originally considered to be a branch of Judaism which believed that the Messiah was Y'Shua (Jesus).
Having done actual hardware designs (used to be a hardware engineer - now I've crossed over to the software side) targetting ASIC and FPGAs with both schematics and VHDL, I'd have to say that your facts aren't quite right.
In all probability when you use schematic capture these days (which is becoming rare) the schematic gets translated into what's called a 'structural' netlist which gets translated into either VHDL or Verilog and then passed on to your synthesis tool. Or, perhaps you get an EDIF netlist from your schematic capture tool and pass it to the synthesis tool (though most would probably be converting EDIF to something else).
Now, I can only agree with your point in so far as with schematics you do tend to have to instantiate every little gate in your design so you do (might) end up with sort of a hand optimized design (perhaps). However:
1) You can do this with VHDL or Verilog as well by writing your critical sections in a structural style.
2) With the current state of synthesis tools I would tend to trust them to do a better job of optimization than I can do.
3) You're not going to design anything sizable (like a real microprocessor) in a structural style or with schematics - it would take like forever and never get done. That's pretty much what we were doing back in the '80's - designs now are much to big to have to lay down individual gates.
The trend is always toward higher levels of abstraction (just like in software - we don't develop sizable pieces of software in assembler anymore). In fact, some of the newer C/C++ based hardware design methodologies seem to be pushing to even higher levels of abstraction than VHDL or Verilog (see: http://www.systemc.org )
(don't) Panic
I tend to agree that "this will mark the decline of perl", but I'm not sad about it. It's progress. Perl just doesn't cut it when it comes to OO design - sure you can do OO in Perl, but it's so UGLY. (And I used to like Perl a lot).
"how many here are using ruby?"
I am! After doing OO Perl for a while I find Ruby to be oh so much cleaner.
"There is Like no Documentation on it"
Hmmm.... let's see there are five English language books on Ruby now:
"Programming Ruby: The Pragmatic Programmer's Guide"
"Ruby In a Nutshell" (by Matz himself)
"The Ruby Way"
"The Ruby Developer's Guide"
"Teach Yourself Ruby in 21 days" (actually very good book)
And in fact the full text of "Programming Ruby" can be read online at http://rubycentral.com
I'm not sure how you can say there's no documentation.
"and most bindings are buggy"
I'm not sure what you mean by 'bindings' here.
"There are lots of features part of Python which have no counterpart in Ruby"
Such as?
(lets see, docstrings, tuples, what else?)
The same thing could be said the other way:
Ruby has features which have no counterpart in Python (of course Python 2.2 added some of these features (like iterators and a more unified type/class system (but Ruby had these from day one) )- but since they've been added so late in the game Python's built-in libs do not use them, so you end up with a patchwork of Python pre 2.2 and PYthon post 2.2. As mentioned, Ruby had a unified type/class system from day one meaning you could extend and subclass built-in types from the start. Ruby also had iterators from the start as well - the significance being that Ruby's collection classes (like Array and Hash) use iterators. Python couldn't till now.
True, Ruby doesn't have multiple inheritance. But as you point out using Ruby's mixin feature (allows you to mix a module into a class thereby adding a module's behavior to a class) can often be used in place of MI.
Using MI tends to get messy anyway, especially when you end up with some kind of diamond inheritance tree. I personally tend to avoid MI even in languages that allow me to do it. I have to say that I much prefer Ruby's approach of using Mixins.
Actually, O'Reilly already seems to have a couple of books that are oriented towards teaching Biologists Perl programming. I'd like to see a book targeted towards programmers who are interested in exploring bioinformatics (so it would assume you already know how to program). It would be oriented towards teaching some of the needed biology/genetics concepts to Programmers interested in the field of bioinformatics.
There are some excellent Ruby titles recently available:
"The Ruby Way" by Hal Fulton
"The Ruby Developer's Guide" by Micheal Neuman
...in addition to the two others already available.
But I suspect that you're right - there will be room for more Ruby titles that cover specfic areas, like dRuby.
Also, how about:
*Ruby for PDAs
*Creating Servlets with Ruby and Webrick
_OR_
*Web services with Ruby and Webrick
I also think the Parrot idea is good - about a year from now it should be starting to have an impact so a book on Parrot released around then should do well.
They're including encryption, so there must be some worry that the neighbors could tap into your network. What's the range? Would this be alternative to the 802.11 wireless WANs?
Peer2Peer networking with each house acting as a peer?
OK, I guess Java is kind of popular out there, but not as much in the Linux community or open source communities.
I think Ruby would be an excellent choice of programming languages for this thing. Ruby:
*is small - less than 800K (can be made even smaller if you get rid of a few libraries that you may not need)
*is Free (as in Open Source)
*has Qt bindings
*is easy to write distributed apps in dRuby - this would especially be good if they can get a wireless link for this thing.
*has reasonable performance
*is (IMHO) a much nicer language to program in than Java.
How about it Sharp?
There's been a lot of talk about it in
comp.lang.ruby
It would be cool if Ruby could play with Parrot too...
It's a joy to program in...
;-)
* There's iterators & blocks
*A unified class/type system (meaning you can extend built-in types like String,Array,Hash,Kernel, etc)
* fully OO - 42.times { |i| puts i }
but it doesn't get in the way when you don't want OO, like it seems to with Java.
* Design patterns - Observable,Delagator,Singleton,...
* dRuby - Ruby's very easy to use distributed object system.
For now it's great fun, hopefully someday it'll pay the bills too.
Certainly valid fears, but when one cogently presents the advantages of Ruby over, say, Perl (much better maintainability for one, I can go back to my Ruby code after a month and know right away what the script was doing, takes longer with Perl) oft times management will let you experiment.
Two different groups within the organization where I work recently started using Ruby (niether knew that the others were using it, they were stealth projects till recently). One of the groups convinced their management to let them rewrite much of their infrastructure (currently in Perl) in Ruby.
The moral of the story: It can't hurt to try. We are the engineers, if we actually think that Ruby can offer us significant advantages its up to us to sell management.
Colonel Panic
Don't get me wrong, I use Perl too, but I'm using it less and less these days. I've been programming in Ruby since about the start of the year and these are the advantages I find:
1) RUby has much nicer OO syntax than Perl - advantage is that when you go back to read the code after a month you can tell what's going on.
2) Perl's alarm doesn't work on the windoze platforms (sometimes in the corporate environement they make you use windoze), Ruby's timeout does.
3) Threads - With perl you actually have to compile a special threaded version. Ruby threads work - even on windoze.
4) Ruby has dRuby a distributed object system that is very easy to use (compared to SOAP, and other XML based approaches).
5) Hashes, arrays, strings have many more builtin functions (methods since they are objects) than Perl's Hashes, arrays and strings.
6) ease of writing extensions in C for Ruby(though Perl's Inline is supposed to make this a lot easier than it was in Perl)
And then there are lots of other things like about RUby like iterators, the ability to extend buit-in classes, built-in support for some design patterns.
Colonel Panic