Slashdot Mirror
Why not Ruby?
flounder_p queries: "I have recently started playing with the
Ruby programming language and think it's really great. I was just wondering why you
guys think Ruby has not caught on more in the open source community than it has? How many of you guys are using it? Will it ever catch on or will it always be looked at as yet another scripting language? Don't get me wrong scripting languages are great (and I live by Perl) but I still hope to see Ruby catch on more. I would like to hear opinions on things on why Ruby is good or bad not on why OOP is good or bad. We have already had that discussion
here." On a side note, a little birdy tells me that BlackAdder has plans for Ruby support in its next beta.
RubyX11 is Xlib being rewritten from scratch in about 80k of Ruby source code (no C code). I don't know any smaller implementation. That should demonstrate the power of Ruby. http://hostname.2y.net/~matju/RubyX11/RubyX11-0.4. tar.gz
this should be going beta by the end of the month; watch for new versions on RAA.
It's called RAA: ruby application archive
http://www.ruby-lang.org/en/raa.html
So why did Scheme never take off? It is one serious, kick-ass, efficient, clean, compileable gem of a language, and believe me, I've programmed one hell of a lot of languages.
My theory is that Scheme never really took off because of a lack of useful standardized libraries. Utility libraries is really the only reason why Perl is popular, and Python is making tremendous inroads with its ever-growing collection of libraries.
Ruby is suffering from the same problem. People like me do not want to have to write an HTTP parser, binary tree library, socket interface, whatever, Yet Again.
How about because all those languages are broken in some way? Would you still use DOS when W2K is available? Or Minix when you can grab Linux? Sure the languages can do everything you need to do..they are Turing complete after all..that's not the point. How easy does a language make things? How easy is it to learn? How error prone is coding in it? Can it be efficiently implemented? Especially on modern machines its getting harder and harder to efficiently implement some languages.
This is bullshit. Unlambda and intercal are turing complete. Are you saying that you would be just as productive with these languages as you would be with a more mainstream (read: usable) language? You can express exactly the same things in pig latin as in english, but you cannot say that pig latin is as easy to say and understand as vanilla english.
QuakeC??
:-) Is that really a language? I wonder what the IDE would be like...run around with a shotgun and shoot the functions you want to use?
--
If run-time efficiency is so damned critical, where even the insignificant performance penalties of member overloading are so costly, then a compiled language would be best suited for implementation.
The commentary regarding variable punctuation is in the same league as negative criticism of python's indentation scoping mechanism, which some deemed as being fascist. Fortunately these coding pedants seem to be a vocal minority; hopefully the variable punctuation critics are a mere permutation of the same species.
MAC | A polar bear is a cartesian bear after a coordinate transform.
Perl very much encourages hacks. For throw-away scripts that fine, I suppose -- though the thing you think you'll throw away now will probably still be around a couple years from now.
TMTOWTDI is a horrible, horrible way to make maintainable code. Yeah, it has nice post-structural connotations (though I hate post-structuralism with a passion for all sorts of other reasons). But it's much better to have one compelling, intuitive way to do something.
And I'm not the only one to think this. There's not a whole lot of languages that get as much disrespect as Perl does. Ada, APL, COBOL perhaps. Java, Python, C, C++ -- they all get critiques, but seldom engender the sort of distaste that Perl receives. Now, despite this Perl is popular -- I can't deny that. It has its benefits. You can make a quick hack real fast with it. But that is, by definition, not good programming. Expedient, perhaps pragmatic, but not good.
I'm just saying it like it is. It's not unfair to say something that's true. When you compare the contribution made by Japanese programmers, and the projects led by them, there are noticable differences when compared to, say, Germany or Sweden. Projects led by people in Japan tend to stay in Japan -- maybe there's less marketing, maybe people are biased, I dunno. And there are relatively fewer Japanese programmers contributing to projects compared to other similar countries. There's a divide between communities -- a divide that doesn't exist between North America and Europe. Except maybe France, though to a lesser degree. Though hell, even KDE/GNOME has a certain Europe/North America rivalry going on.I think I sound a little bit too anti-Perl in that post. I don't like it, but I don't think it's sinful or anything. Nothing, you know, personal towards, you know, anyone.
That of the message pass being an intrinsic part of the language. Message passing (some would say "simulation") is the key insight that OO has given the world of programming.
Other tools like inheritance, polymorphism, etc. are important factoring tools that follow as corollaries to the notion of message passing.
In C, if I put function pointers into a struct, and call them with a "->", while this may seem to you as a message pass, it really isn't. It's de-referancing a pointer to a function. It destroys the abstraction of the message pass by exposing the programmer to the underlying nature of pointer tables.
On the other hand, you are quite correct that some languages are a super-set of OO features. LISP can allow the creation of mini-languages inside of it, like CLOS, that represent the message pass (using generic functions, for example). This is granted, but I also would like to state that such languages are far from the mainstream of language usage; the world would be wonderful if they were used more, but alas, this is not the case.
So my view is that at least an OO language provides a certain "water level" of assumptions in constraining the programmer's means of expressing intent -- and I would claim that constraints on expression are a necessary evil to simplify the environment for mainstream use.
-Stu
Take a look for your self here: http://search.cpan.org/
Why is that ugly? The order of ops seems pretty clear there, to me.
(This isn't a troll, incidentally... I just don't see what you find objectionable there.)
There are are limited number of developers out there, and once most of them have found thier fav languages - whether it is Perl, C/C++, Python, java or (gasp) Tcl - they dont always feel the need to pick up another language when thier current tools do the same things... Ruby is suffering because of the existence of decent competition, not because its bad. Heck, a lot of people write decent little languages that never take off.
man is machine
Hello McFly!
I said "one element of OOP is the sub-typing. That actaully lends itself to another feature common to OO languages". Did I say Exception handling is a nessesary part of OO-language? Nope. Did I say that a element of OOP, sub-typing, is complementary to exception handling? Yes.
Your comment was orthogonal to my point.
-- I am not a fanatic, I am a true believer.
You are wrong. Subtyping doesn't have anything to do with exception handling
Man! You've sliced and diced me with cogent argument. I am humbled.
You have to set and identifier of the exception to throw in order to catch different exceptions. You can do this this at least two ways I can think of. 1) A single list of identifiers, ala IOCTLs or 2) a namespace of identifiers.
The first is really not scalable in a large distributed collection of libraries. People are going to start stepping on each others exception numbers.
The second could be implemented in a non-OO language. But amazingly enough the namespace oriented typing of OO languages is a perfect match for needs of catch clauses in exception handling. WOW! That is just like what I originally said (closely paraphrased) "sub-typing lends itself to Exception Handling".
You know, examples and arguement are pretty cool tools in communication. Sure, you can't write a complete thesis in a slashdot comment, but you can throw enough out there for people to get your drift.
-- I am not a fanatic, I am a true believer.
I've written several modules for Ruby in C, and integration is easy. What's more, you get free garbage collection in your C code, just from calling Data_Wrap_Struct, because the object gets handled by the Ruby garbage collector and is garbage collected (it's free() function is called) sometime after you return to the Ruby interpreter (or as soon as you run out of memory and the GC gets invoked). If you want your code to be automatically wrapped, then there is also Swig support (though the Ruby module for Swig lacks the documentation that the TCL, Python, and Perl modules have).
Where the integration becomes tricky is when you try to interface with C++ code. Ruby uses setjmp and longjmp for its exception handling, so if you call rb_raise, you'd better make sure you don't have any objects sitting on your stack that might need to be destructed! I don't think Perl or Python do much better at this (though I could be wrong).
There is the Ruby Application Archive (RAA), but it's pretty disorganized and there aren't nearly as many modules available as there are in CPAN. RAA.succ (the successor to the RAA, for those who don't speak Ruby) is a big topic right now. A project called RubyGems is in the works, and many other ideas have also been proposed.
it has several prefixes (@ and $) for varaibles to change the interpretation of those variables,
No, Ruby uses @ and $ to denote scope of a variable. Many people do the same thing in other languages (such as adding a trailling underscore to member variables in C++), because it's easy to get confused. Ruby forces the issue on you so that your code will be clean and easy to maintain; this is not a bad thing.
Python has several implementations available, whereas Ruby has only one.
Ruby currently has only one non-developmental implementation, but there are a couple of projects in the works for "Ruby-in-Ruby" and for a "Ruby to C" compiler (see rb2c and rubyjit in the RAA, for example).
and CSS is another scripting language. hmm
---
I've been playing with OCaml lately and it's kind of neat.
Something similar to your reject example might be:
List.filter (fun c -> c = Char.uppercase c) ['a';'A';'b';'B';'c'];;
outputs:
- : char list = ['A'; 'B']
-Kevin
Are you sure there aren't a lot of those books
because there's a big market for them?
There's a ton of production Cobol and Fortran
code, and tons of it still being written.
All the Java docs are online. Same with
Perl. Why do I need a book? I have like
two Java books related to performance and
even those were a waste. Those books are
outdated as soon as you get them home too.
-Kevin
That's odd, because an assembler is a program that assembles assembly code into machine code.
For the programming I do, C++ and Perl are adequate. I looked at Ruby some time ago and was really quite impressed. I'll probably look into Ruby again periodically, but so far, I haven't seen anything to convince me it's worth using myself.
Untrue. They have been added to Python 2.1. See this document
BTW, Python 2.1 also has garbage collection for reclaiming cyclic datastructures. I'm not sure if it helps extension writers, though.
Han-Wen Nienhuys -- LilyPond
A language that supports encapsulated ADTs is object based. A language needs to support runtime polymorphism to be called "object oriented". Object based languages aren't necessarily object oriented, but object oriented languages contain all the functionality of object based languages.
Heheheheheh. TCL is a command interpreter, ;)
where commands have the form commandname arg1 arg2 arg3 etc
and some various kinds of quoting. Its not exactly a language
Hamsters are at least as feathery as penguins. HamLix
do not forget our friends TCL and SmallTalk.. they used to be somewhat popular... but not anymore.
Why Ruby? Cuz it doesn't suck.
Why not Ruby? Cuz no one else does.
If Ruby really is that good, it will get its 15 minutes of fame. The simple fact that it is appearing on slashdot in such a style shows that a community is evolving for it. Once that community matures, it could easily takeover the positions of Perl and Python as they join the ranks of TCL and SmallTalk.
It is a vicious downward Spiral.
Just what the world needs, a hard to parse LISP!!!
Scuttlemonkey is a troll
It's a real bummer that you had to research Ruby before Dave and Andy wrote Programming Ruby. Now all the hard work has been done for you, and the experience could've been much more pleasurable.
Regarding your benchmark, no, I don't see a problem with that. I never write programs that have to increment an integer from 1 to 1_000_000, so I don't particularly care what the performance for that task is.
Spot on! I switched to Ruby out of necessity. I knew both Python and Perl very well, and am an expert in Java. I had the need to be able to be more productive when programming. Ruby has made me much more productive.
To rephrase your question, does it make me an order of magnitude more productive? Well, that depends on which base you use for numeric comparisons. I'd have a hard time saying that in base 10, I'm an order of magnitude more productive in Ruby. But I am at least two to four times more productive in Ruby than in Python or Perl (and at least 8 to 16 times more than in Java) which does add up to a few orders of magnitude in base 2! *wink*
I love this type of thinking that you promote. It is what ensures that those of us who promote the proper technical solution over the politically correct one will continue to corner the market on innovation.
For an insightful writeup on this phenomenon and how it practically guaranteed one company's success, read http://www.paulgraham.com/avg.html as well as the juicy followup http://www.paulgraham.com/lwba.html
If your boss doesn't let you choose the right technology for the job, get a new boss.
OK, so for english speakers the Programming Ruby book is the best one, but following that, you have to check out Ruby Garden (www.rubygarden.org) which hosts the RubyWiki.
Also, ruby has excellent support on the ruby-talk mailing list (see http://www.ruby-lang.org/en/ml.html) where you can chat with matz (author of the ruby language), Dave Thomas (authoer of the first english-language Ruby book), and a host of experienced, friendly ruby developers.
For iteration:
sum = 0
[1, 2, 3].each { |x| sum += x }
For generic methods:
def waitAndDo(delay)
sleep delay
yield # calls the passed code block
end
waitAndDo(60) { puts "Hello" }
As closures:
def getCounter(increment)
sum = 0
return proc { sum += 1 }
end
c = counter(2)
c.call
And much, much more!
I would say that "scripting language" have a real difference in the "little programs".
A C program under 100 lines length is "nearly empty", a Perl script under 100 lines can be quite powerfull under typical usage (obfuscated usage doesn't count).
Think about Eiffel,Ada, Modula functionnal languages etc.
There are MANY languages and very few are widely used..
The "scripting language niche" is quite already filled by Perl and Python..
IMHO Ruby is more readable than Perl (not difficult!) but it competes head to head against Python, and there are many more Python users than Ruby users..
I would say that the odds are against Ruby, we'll see..
Wouldn't this actually be classified as flamebait?
domc
Yes, but not Ruby the scripting language that is sort of like python, but Ruby short runs of text along side the main text.
In answer to the orginal question, Ruby doesn't have a lot to offer over other scripting languages, and not long real has any big wins over python. (it closest relative) Python no has full fleged garbage collection and the Functional programing extenstion has closures, etc.
Grey (Chris Lusena)
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
An interesting language is F-Script, which is a smalltalk-like language with array-processing constructs like APL - so if you have an array of objects, it has an economical syntax for doing matrix operations consisting of messages on them.
Choice of masters is not freedom.
"If you're going to bash a language, you really should make it a point to at least learn the language first."
rage, rage against the dying of the light
Pascal. P-Code. Almost 40 years ago.
rage, rage against the dying of the light
Depends on what you're writing. Sometimes, non-OOP is the quickest, most efficient, and *best* way to do a job. Other times, OOP is what you need. Like operating systems, use the best tool for the job.. :)
If you were me, you'd be good lookin'. - six string samurai
> Just because some clown learned to write an interpreter at school, he decides to convert the world to yet another scripting language.
.|` Clouds cross the black moonlight,
Which would you rather have, a generation of programmers who know how to write interpreters, or a generation of IT consultants who can't?
*Duh*.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
Well I have been working with Python for a little bit and I checked out Ruby just to see what it was about. From what I could see they are very similar in most ways and the ways they are not, do not really matter, i.e. more stylistic then structural. Another big argument for Ruby over Python used to be that Ruby was GPL but since there is a GPL Python this really does not stand, as well Perl is not GPL, so not much water there.
If you specifically check out The great language shootout you will see that in most cases Python does come out ahead of Ruby not by a huge amount but ahead, and in many cases ahead of Perl as well.
Thanks for the David Korn interview link. Good stuff for shell and ksh enthusiasts.
I personally think that a good shell is superior to Perl for many quick scripting applications, just because a person can use the same syntax for long interactive commands and short scripts. I enjoy being able to do a for-do iteration on the command line, then pop it into a script (possibly by copying it from history) if it seems I might reuse it.
> So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping.
No, that is not the most important aspects of OOP. My choice is Data Abstraction and Encapsulation. I think you're looking at the wrong parts of OOP.
Everytime I've thought, 'my language ought to do...' ruby usually does it. It manages to combine extreme utilitarianism - it does a good a job as perl in most places that perl does best - with elegance and simplicity in the language design.
If you like perl because it makes handling regex easy, but you think that the way perl handles OO is a little strange you'll love it.
If you like python because it makes building OO apps simple, and without verbosity, ruby is even nicer (it wasn't a hack on a procedural language).
.
Why doesn't Ruby pass that closure as a normal object (with a `yield' method)?
Somehow special-casing this closure thing, which is supposed to be a Proc-object, looks icky to me.
"Learning a new programming language" is a task without a well-defined completion condition. Yes, you can learn the core syntax of a language in a week or two, but that's just a start. I know Perl well enough to get paid writing it for a couple of years now. But I'm still learning it, and getting noticeably better and more productive with it the longer I study and use it. It would take more than a couple of weeks' study of Ruby to approach my current level of productivity in Perl.
I can see applying myself to further study of Perl; I've been meaning to sit down and grok Parse::RecDescent in its fullness. I can see studying something wildly different from Perl, to broaden my horizons; enough people suggested studying Lisp that I'll be looking into that next. And I can see looking at tools that apply to a different problem domain; that was why I learned Perl in the first place, while I was still gainfully employed hacking in C and Java.
But Ruby uses the same basic paradigm as Perl, and applies to the same problem domain. Even if it's (by some measure, say) 20% better than Perl, it still won't make me more productive than I am now in Perl without a lot more than "a week or two" of study and practice. And no one's paying me to learn or use it. So why bother spending a couple of weeks gaining a superficial understanding of Ruby, when I could be learning something completely different, or getting better at Perl?
I wrote a BASIC interpreter, which is definitely NOT object-oriented, that has try-throw-catch error handling because I thought M$'s "on error" construct was a big kludge.
Consequently, that construct is not a feature that solely belongs to OOP languages.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
Actually, I don't bang my head too often when programming in C. C may not be object-oriented, (C++ is, but C++ is a kludge that never should have existed) but there are no limitations to what you can do with it.
But then again, comparing Ruby, Perl, and Python to C and C++ and to Java is like comparing apples to oranges to pears. They each have a target use, notwithstanding that each can reasonably fill the shoes of others.
For instance, I'd never use any of the above language, except C, for embedded applications where resource limits are an issue.
I can bang out a quick network app in Java or Perl, and have it very portable, and development time is small compared to doing it in C and C++. Not sure about the others.
So, overall, comparisons are moot, unless outside requirements for a project limit language choice, because in the end, it's the programmer's preference, and the ease of doing something in a particular language that wins out.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
What in the hell are you talking about?
How is the fear that the one employee using ruby would leave and nobody would support the app stupid, untechnical and irrational?
Stupid? I don't think so. Many program languages come and go. You really do need to be able to maintain the thing.
Untechnical? How? Because all of the pros and cons of the language were not evaluated? When it comes right down to it, aren't things you can do in ruby that you can't do in perl/python, or vice versa, so really you are talking about the language that works best for the task. Why do you want the best language for the task? Well first to get it done quickly, and second for maintainablity. The latter was already covered and I haven't seen anything that can be done in ruby faster than perl or python.
Irrational? Come on, you just looked up stupid in a thesaurus didn't you?! That doesn't count.
Support
There seems to be this opinion that Ruby lacks support or libraries. Ruby, being fairly young, does have fewer extensions than many languages, but it has enough. It comes with a TK interface, and extensions for GTK, QT, FOX, dialog, curses, and others are available. There are a couple of XML parsers, as well as both client and server libraries for XML-RPC. There are copious extensions for web-oriented programming, and a very nice DBI with extensions for most of the databases that I know of (including MySQL, Postgres, and Oracle). In all honesty, I can't think of an application that you write in Ruby with what's available. Besides, this argument was often used by Microsofties to support why you shouldn't use, well, anything but Windows.
Learning curve
Another common argument is the old "Can't use it... nobody knows it," also known as the programmer-hit-by-bus syndrome. Really, Ruby code is more readable than anything else I've ever seen, if you come from a C-ish background. It is just as alien as anything else if you come from a Lisp-ish background. A good example of this is that my own experience. I'm a professional Java programmer. About one work week after I started learning Ruby, I realized that all of the pseudo-code that I was writing on my white-board was valid (or nearly valid) Ruby code. Further, on one mini-project I was tasked with improving the speed of a 426-line bash shell script. I had never seen the script before in my life; the conversion to a valid Ruby program took about an hour; getting functional validity took another hour or so. I spent the of day optimizing and "Ruby-izing" the script, eventually getting a tenfold speed increase and dropping about 1/5 of the code. Ruby, IMO, has a very low learning curve, and given halfway decent code, I suspect that any programmer familiar with OO and any C or sh style language could understand the code.Syntactic Sugar
Ruby isn't unique in this regard, but it does have a lot of nice syntactic sugar. First, code isn't rigidly formatted like Python. Neither is is verbose, as one post suggested. I strongly suggest looking at the "What is Ruby?" and the "Compare Ruby to other languages" pages for more information. To quote those two pages here would be excessive. The comparison page compares Ruby to Perl, Python, Java, and TCL.
Why switch?
If you have a language you know and like, why switch? I can sympathize with this position. I've long felt that way about Java and other "upstart" languages, like Python. For me, there weren't any compelling reasons to switch. I've found Ruby to be the first language that does (almost) everything right. It may not have the wide array of extensions that other languages have, but the core language is designed properly. When you write code in Ruby, you write code to do the job, rather than writing code to support the code that you write to do the job. My favorite example is:
Java JButton button = new JButton("Click");button.addActionListener( new ActionListener() {
public void actionPerformed( ActionEvent ae ) {
doClick();
}
});
which becomes
Ruby button = JButton.new("Click") { doClick() }Code is both terse and readable, and often elegant by virtue of the language syntax. It is easy to write good code in Ruby. This improves productivity and maintainability, and any time you can significantly improve these I'd say it is a good enough reason to switch.
True OO
This is a very strong argument in favor of Ruby. Everything truely is an object. I can't stress how much difference this makes in practice, and arguments to the effect that other languages that provide "work-arounds" for their non-OO types are arguments for hacks to fix flaws in the language design.
Lack of documentation
I'd argue that, while having a large library of documentation for Ruby might be nice, it isn't neccessary, and that this is a strength of the language. Really, all I have is one Ruby book, and that is sufficient to do anything I want. I have nearly 50 books on Java, and I need many of them. I'm not being absurd here; Ruby really is very simple. I'll agree that there is a minimum requirement for at least one good book, or at least, some good documentation, which Ruby didn't have until recently.
Too much diversity
Well, perhaps. But the idea is that with language development moving forward, you tend to get some progress in languages in general. I have known over a dozen computer languages, but I really only know two at the moment: Java, and Ruby. I use these because I believe that they are the pinnacles of their fields. I actually believe that Ruby could replace Java in my life, but I'll have to change jobs for that to happen... I don't get to choose what language I program in on my current job.
Scripting language
Ruby is an interpreted language, but I'd hesitate to call it a scripting language. Ruby certainly is suitable for large application development, and has all of the language features necessary for application development. It has classes, modules, includes, and mixins. That said, Ruby is also emminently suitable for scripting. I can easily write:
ls *.jpg | ruby -nalF. -e '`convert -geometry 320x240 #$_ #{$F[0]}_thumb.jpg`'or, from the Ruby man page:
ruby -p -i.bak -e '$_.upcase!'Again, an example of good design: everything in Ruby is OO, even if you aren't aware of it, as in a small script.
Summary
I'm a relative Ruby newby. I used to do Perl, I tried Python, I programmed in TCL for a while, and I do a lot of Java. I chose Ruby initially because I liked the look of the code and features of the language, and I've become an advocate because I've recognized that my productivity in Ruby is far greater than in any of the other languages I've tried. Ruby fits both the scripting niche, and the large application niche. I like Ruby precicely because it doesn't have any of the annoying features of other languages. So, why Ruby? Because it is better. Because it does things right.
This is about ecology, not pet languages.
Think of all the shelves full of books on Java, C, Perl, VB, etc. (also training courses, conferences, managers mindshare, etc.) Think of which languages got displaced from their niches by the currently popular ones (go into a medium size bookshop and see if they have anything still-in-print on Fortran, Cobol, RPG, Pascal or QBasic.) Perl won it's niche because awk and sh were weak in filling that niche before Perl/TCL/Python came along.
What makes anyone think that there is a niche big enough for Ruby to displace the existing species of scripting languages? My guess is that there are already too many solutions in the scripting language niche, and when the shelf space (and/or mindshare) for computer programming shrinks back to normal proportions, some of these languages will become fodder instead for books on the history of programming languages.
Ancient languages will still live on in tiny specialists microfactions; people still write Basic interpreters.
I just finished writing a Perl program that does password based blowfish file encryption and decryption.
First, it uses Getopt::Long to parse command line options. Then, it uses Term::ReadKey to read in a passphrase with no terminal echo. It uses Digest::SHA1 to hash the passphrase. Compress::Zlib compresses the data. Crypt::CBC and Crypt::Blowfish encrypt the data. MIME::Base64 translates the data two and from Base64 for easy inclusion in email/etc...
The entire script is less than 100 lines of code. Could you do that in Ruby?
-- The act of censorship is always worse than whatever is being censored. Always.
I'm sort of surprised you didn't bring up the fact that Python supports multiple inheritance and Ruby does not. This is a key issue for me, though from what I have seen, Python's syntax is also much cleaner.
I can't speak against OCaml though; I'm in the midst of an Eiffel obsession. And it can boast clean code and good compilers. Too bad it seems to be under the thumb of the well-intentioned ISE.
Daniel
actually, at 1.5.2 we had UserList and UserDict, which would let you "inherit" from the List type or the Dictionary type. It wasn't actually inheritance, instead it was an often forgotten object oriented concept called delegation. (The main reason people forget about delegation is because C++ does not support it). The idea is this: you have a subobject (in this case, a list or a dictionary) and you delegate all function calls or data requests to the subobject if you do not implement them. It's really quite simple to implement:
:)
class mylist:
def __getattr__(self, name):
return getattr(self.data, name)
def __init__(self):
self.data = []
and you can use this technique to pretend-inherit from any built in type. like I said, this feature is not supported in C++ so people have a tendancy to forget about it entirely. Of course, nowadays we can use UserList or UserDict (and with 2.0+, UserString) as a base for inheritance. All you have to remember is "self.data" is always going to be the string or list or dictionary you are emulating:
class mystring(UserString):
def __init__(self):
self.data = ""
will behave exactly like a string.
I'd like to see a good example of why one would want to inherit from integer or float before I'll understand why one would want that in the library.
I'd also like to see how one is supposed to use single-inheritance for any good if you can't use delegation either (Java, I believe).
Daniel
English doesn't exist based on rules. The way it works is that we all know how to speak it, and we can _try_ to come up with some rules that explain what we already do. You may have noticed that every grammatical rule in the book has exceptions. Yes, even by the best theories on phrase organization, there are simple English sentences which defy them. Another example of this is the apostrophe "rule", or the i-before-e-except-after-c "rule", and so on.
The study of classical Latin has done one major evil: it's given a lot of people the idea that languages are structured, logical and organized, and any exception to this logic is a kind of mistake. However nothing could be further from the truth.
Classical Latin is a constructed language (like Esperanto etc.); nobody ever spoke it. The people of Rome spoke what we call "Vulgar Latin", a much more human language, full of "exceptions", but Classical Latin was used for any official announcements or artworks. It's been suggested that some of the writers of the classical works (Virgil etc.) may not even have spoken any form of Latin.
You say you write "better English" now. This means you've learnt more of "the rules", and probably increased your vocabulary too. In the end though, "correct language" is what the people speak and understand. We aren't going to hold back the evolution of language, no matter how hard we try (1984 notwithstanding!)
To some people, "Zup in da hood" is better language than "How are things in your area?"
The best way to get over this mindset is to observe children learning their native language.
They sure don't care whether a word is a noun or a verb, or what the past tense was. Even if the language had no rules, children would still learn it (and, I daresay, people would come up with some rules anyway).
An interesting example of this was something I saw on /. yesterday, where the writer wrote "drug" instead of "dragged". The process involved here is known as imitation (the writer, perhaps unconsciously, tried to extend the 'rule' seen in "drink, drank, drunk" and other such verbs). This is the same way that children learn, and their parents correct them when they are "wrong" (I use quotes because what they did was perfectly logical, following rules, but it just happens that this word is different, and there was absolutely no way to know beforehand).
Think about how these rules might have come into existence in the first place... I'm quite sure that nobody invented them :)
Also, programming languages which have tried to make the syntax look like English have failed abysmally for the same reason. Sure, languages contain English words, but the phrase construction is very much unlike English (or any natural language), so in the end you have to learn the language just like any other and try to forget that it had anything to do with English. (Try writing a set of #defines to make Romeo and Juliet into a C program :)
The other rules I mentioned were not examples of grammatical rules, but examples of rules with exceptions (which includes grammar and spelling rules, among others).
I was a perl man too, but I have recently switched to cross-stitch.
Xenix was running on PCs eight years earlier, although it wasn't free. Perhaps you used the wrong boolean operator?
This is basically the Sapir-Whorf hypothesis, and it is not generally accepted to be true in its strong form (which you appear to be using).
Learning another language makes you understand your native tongue better because of the *similarities* in grammar, much more than the differences. I learned about English grammar at school, but of course I was more interested in looking out of the window... Then while learning Japanese I rediscovered subjects, objects, transitive and intransitive verbs, and all the rest. After that I started on Hungarian, and I was much faster learning it because I instinctively knew when to mark objects etc.
You don't really *need* to know why you form sentences the way you do, unless you want to learn another language!
Right...Python forces you to do it Guido's way. You can't use Python like Perl even though it has a strong, Perl-compatible regular expression library. And you can't ues it like Smalltalk even though it has OO and can even support meta-OO types of programming. And it doesn't support functional programming even though it has map, filter, lambda and list comprehensions.
I would suggest you actually use Python before you start guessing about what it is like.
That explains why you asked the question. You think about languages differently than most people.
Most people can't afford to learn every language that comes along, and port all of their projects over, and rewrite their extension modules and .... there are a finite number of programmer resources in the world and most don't consider the thrill of a new language to be worth the pain of incompatibility between their old code and their new code.
I have done projects in Python that I do not think I could have done in Perl or Ruby because of Python's clean namespaces, clear OO and portable, robust, native thread support. So there are practical reasons to learn Python. There are probably also projects that would be MUCH easier in Perl than in Python (e.g. those that are solved by a module on CPAN, or by Perl's great database support).
But on what sort of project would Ruby be uniquely qualified? When I understand that, I'll know why I should learn Ruby. I'll also be able to judge whether Ruby is the next big thing or just another language.
Maybe Ruby is the next big leap. But you haven't really made that case. All you said was that it had slightly better OO than Python. Help me to understand it in terms of the problems I have to solve. Show me a problem that would be hard to solve in Python but easy to solve in Ruby.
> I would suggest you actually use Python before you start guessing about what it is like.
Likewise, I would suggest you actually *use* Perl and Smalltalk before you start comparing Python to them. While I'll admit I don't know a lot about Smalltalk, I *do* know that it is based on a much more strictly Object-Oriented concept than Python. Like anothor poster said, even Java is more like Smalltalk than Python. Not that this is (IMHO) necessarily a good thing. But sheesh... just because something has OO features doesn't mean it's "like Smalltalk". Python's OO-ness is more like C++ than it is like Smalltalk.
> You can't use Python like Perl even though it has
> a strong, Perl-compatible regular expression
> library
So, Perl's sole feature is strong RegEx support? Wow, thanks for enlightening me. All along I thought it was a unique computer language, and it turns out it's just glorified grep. That's awfully dissapointing. Well, I guess I'll get back to my Python book...
Saying something is "like Perl" because it has good RegEx support is like saying a Gazelle is like a Studebaker because they both have horns.
The power of Perl is (to me) the ability to craft unreadable, unmaintainable little tools *incredibly quickly*. Ruby gives me the shortcuts to do the same, and then later clean them up into code that's just as structured and clean as Python. The attitude of all the python documentation I've read is that you should never, *ever* write quick&dirty tools, and that's why Python doesn't have the (admittedly ugly) shortcuts Perl offers.
--
--
CPAN rules. - Guido van Rossum
As someone who speaks Japanese natively, and learned English through "immersion" in the U.S., I have some points to add -
1) I think you are confusing the fact that children don't need to know "the rules" in order to learn a language with the idea that there are no such rules. There is no such thing as a language "without rules", excpet perhaps for crude hand gestures and grunts. My mother has more difficulty with English than I do, and that probobly has to do with her age - reaserch seems to show that children can instinctively pick up rules of grammar and other nuances of culture better than adults can. Check the works of Noam Chomsky, for example.
2) Languages can be demonstrated to have some level of rules - just take a sentence or two in some foreign language, and translate it word for word into English - it won't "look right", because it will probobly use different syntax and rules. This does not mean that you can't deviate from them, just that there are traditional and customary ways of arrainging words. The human mind is much more flexible than any computer-language compiler, and can tolerate idiosyncracies and minor variations in grammar.
3) Computer languages are not like natural languages, because natural languages evolved from a need to communicate between human beings, while computer languages are designed only to pass instructions to a computer. If(...)Then(...) phrases are only a small part of a natural language, and human languages encompass everything that humans experience, which is far more than what computers do.
Aha! Didn't think of that. True, very true. But P-code's use is, as far as I know, mostly insignificant today. [Icon has a decent following, and of course Java is inescapably gargantuan.] Pascal isn't a "modern" langauge in most people's eyes. I think that's more what I was talking about.
;)
I'm just saying.. Icon kicks Java's sorry little butt and nobody seems to realize that..
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
If Perl or Python were controlled by a single entity (as is the case with C#, and even to some extent Java.
Um wrong. Java is controlled totally by sun. You can't make any extensions to Java (look at the trouble microsoft got into).
C# on the other hand is totally open. Just look at the ECMA submissions:
Monash University
Microsoft
Better luck bashing Microsoft next time.
There's also a book by the same authors of that
Dr D article. It's online at
http://www.rubycentral.com/book/index.html
Alex.
I've been using python for years, and love it. I've just started to
= Ru by%2FPython
look at ruby; I'm reading through "Programming Ruby" at the moment.
Some of the control structures seem a little too elaborate to me, like
the range condition expressions, but on the whole, it seems like a very
nice language. I haven't done anything substantial with it, yet, but
I'm definitely going to as soon as I've finished my thesis. Anyway,
with regard to the more vigorous python community, etc., the ruby/python
extension looks like a really sweet set of training wheels. Basically,
it gives you access to python objects from ruby.
http://www.ruby-lang.org/en/raa-list.rhtml?name
HTH.
Alex.
However, in "conventional" compiled languages, it has always been (more or less) possible to mix and match: eg. code in C++ with older libraries in C, or with FORTRAN. The object code model (ie. anything that involves the linker) is largely independent of the programming language. There have been some attempts to do this with a common bytecode layer, but we aren't even close to the "features" of plain old .o files yet. Or am I wrong?
Why not be able to "link" different scripting languages? Jython has done this to a limited extent between Python and Java. And there is some talk about a "backend" vs. frontend separation in Perl. What is the current status of these? How far away are we from something like a cross-platform, scripting language targeted equivalent of ELF/libbfd etc (plus a common bytecode layer)?
The bottom line: a lot of people mentioned the pain of incompatibility with pre-existing code vs. the benefits of learning a new scripting language. But I don't think that the pain vs. benefits need be as tightly linked as people usually assume...
Jeremy
--
Looking for a Python IRC bot?
People who expect to read code written by themselves and others and understand it without effort are people who like Python. People who like their ideas to translate directly into code, with as few syntactical or semantic "gotchas" as possible like Python. People who consider such things are pragmatists. People who don't consider such things are, to some degree, not pragmatists, because they're ignoring (or they don't agree with) the practicality of the above disciplines.
Explain to me where I'm wrong, then. An iterator is an object that maintains the state of traversing a container class, and has several methods with which to affect that state. An iterator for a singly linked list would include a method to retrieve the next item; an iterator for a doubly linked list would include a method to retrieve the previous item and one to retrieve the next item. An iterator for a binary tree would probably include methods for traversing the tree inorder, preorder, or postorder.
Where is my understanding lacking?
What I'm saying is that such problems can be solved more flexibly and elegantly with higher order functions.
I believe iterators are more complex in terms of code complexity and in terms of time invested to achieve the same goal as a higher order function.
Jeremy
--
Looking for a Python IRC bot?
> 65.chr
"A"
What would that do on an ebcdic platform?
Exactly! Of course geeks don't want to have sex as much as they want to program, so that's probably the reasoning behind it.
- Steeltoe
http://www.debunkingskeptics.com/
You didn't really want to follow my argument. Yes, you can compare oranges with apples but they're still two different fruits. So is Ruby and Haskell. You can be biased in favour of one of the types, but that doesn't say much about the specific languages. You can't force a user to switch and expect him to be happy and productive. It's a bigger shift in paradigm for him/her. Of course you lack something in imperative languages that exist in functional ones, but that tune goes the other way too. Personally I hope functional and symbolic languages will lead the way of the future. However, pure imperative forms will continue to be necessary too.
:P
Mozard-Oz is one such language that includes pretty much about everything. It's too heavy for me to understand based on their web-pages, but from what I could gather it looks pretty impressive. That doesn't mean it'll become the One language though, because people like me are too dumb to understand it
- Steeltoe
http://www.debunkingskeptics.com/
Ruby supports including many separate modules into one class (mixins). This makes it much more simpler and powerful than multiple inheritance, because you can make classes with THEIR OWN range of module-ancestors by mixing-in many modules. This eliminates problems where a baseclass inherits something you don't want. I believe Ruby borrows this feature from Eiffel, I'm not confidently sure though.
;)
Someone once copied a past argument of mine about this onto the news group (which is 110% okay by me). I wish someone could explore benefits of such programming more in-depth and publish their results. I have strong belief this is the way of the future for OO, instead of the cludges of multiple inheritance. I also believe the technique can be developed further than now available in Ruby. Those who use it, speak up and publish!
- Steeltoe
http://www.debunkingskeptics.com/
No he wasn't. Avoiding side-effects is very commendable. I like Ruby, even its way with attributes. So the better solution to Ruby is to add a general constraint-package that can guarantee restrictions in code. Kind of like safelevel ($SAFE), but not so hackish.
Ruby is powerful, sometimes too powerful to work with in large groups or utilizing 3rd party code.
- Steeltoe
http://www.debunkingskeptics.com/
You should rewrite #3 to:
:-)
3) Threads - With perl you actually have to compile a special threaded version. Ruby threads work - even on DOS.
Cheers!
- Steeltoe
http://www.debunkingskeptics.com/
Most people learn Ruby in one or two days. Why do I have the feeling you don't have a clue what you're talking about? Not to mention the moderation *cough, cough*
- Steeltoe
http://www.debunkingskeptics.com/
Why compare Ruby with Haskell when they're two completely different types of programming languages? One is imperative while the other is functional. It's like saying Prolog (logical) is better than C (procedural). Different languages for different jobs and all that. Just because a language is XXXX, doesn't mean it doesn't have its merit or place to-be.
- Steeltoe
http://www.debunkingskeptics.com/
Ruby isn't like Java, which forces you to define classes. If you like, you can quickly hack together as many procedural scripts you like or skip procedures altogether. It's ideal for those small, straight-forward batch-jobs.
Yes, Ruby is still a "pure OO" language. The reason it may seem procedural at times is that every code you write is inside a bigger object-context. So when you call functions, they're really member-methods. You just skip context-handling for convenience. The default context for the program code is the Object object, which makes the defined methods global.
- Steeltoe
http://www.debunkingskeptics.com/
Actually, Borland's C++ Builder also supported this through a proprietary C++ extension. Then again, you were just trolling, so clarification doesn't matter to you.
As has been posted other places. There is a ruby equivalent to CPAN; it's called the Ruby Application Archive.
In Python, I think if there's a __setattr__() method on the class, it gets used instead of normal assignment to set attributes on objects of that class. Side-effects are possible and I agree that undisciplined use is bad practice. More often you might want to override the implementation of assignment (e.g. not use the default __dict__ to store attributes, do an assert on the value etc.)
-- What do you need?
-- Gnus. Lots of Gnus.
Exception handling has nothing to do with OOP; it is an entirely orthogonal feature!
My point was not that there is some sort of advantage of procedural languages over OO languages, but that there are more than just two paradigms! All other modern programming languages support modularity ("namespaces"), many in a nicer way than C++.
My whole point is that it is not just procedural and OO!!! Read it again!
My point is that these features (otherwise known as abstract data types) are available in all modern programming languages. SML, for instance, is a decidedly non-OO language, and yet it is easy (easier, I'd say) to do data abstraction and encapsulation.
Most of the things people like about OOP are features of all advanced languages, and that's why I say it is overrated.
An AC writes:
...
> You are also forgetting function languages, such as LISP, Scheme,
Actually, that is precisely what I had in mind, since my favorite language happens to be in that category.
The fact that everyone seems to think that me saying OOP is overrated implies that I think procedural is the way to go is emphasizing my point (and frustrating me). Read the post again!
You are wrong. Subtyping doesn't have anything to do with exception handling.
No -- I would say that procedural programming is obsolete.
OO is just one of the many good modern programming paradigms. It is overrated because there are several others, yet people seem to equate OO with most of the features of modern programming languages which are NOT exclusive to OO.
You are still missing the original point of my post. Though exception handling is part of most OO languages, and works well with it, it is by no means a feature that is found only in OO languages. It's found in most modern programming languages, such as SML, which is definitely not OO. The construct is orthogonal.
Since programmers like yourself tend to conflate constructs like exception handling with OOP, I say that many people believe OOP is more than it really is, and therefore it is overrated.
If indeed you have been arguing all along that you use the subtyping hierarchy frequently to catch a set of errors all at once (but not all errors or a list of specific errors, since those would be supported without subtyping), then perhaps you have a claim against my argument. I'm not sure if I'd believe it, but at least we'd be talking about the same thing. What you said here about namespaces would be true of any language (OO or not) with modules.
Often they are the same in OO languages, but they might not be the same in others.
Inheritance is simply a way of getting some code for free; you include all of your parent class's code. In OO languages, inheriting (unless like a private inheritance in C++, perhaps?) induces subtyping.
Subtyping says that you can provide an object of one type where a supertype is required. In OO languages, typically the only subtyping construct people think about is class subtyping due to inheritance. It may or may not be a mistake to think of char being a subtype of int being a subtype of float in Java, C++, and even C, for instance. In other languages, you might have subtyping relationships that have nothing to do with inheritance (perhaps because your language doesn't support/encourage it).
What I meant with regard to anonymous "classes" is the following.
In C++: (port to your favorite famous OO language)
struct intpair {
int a;
int b;
intpair (int aa, int bb) : a(aa), b(bb) {}
};
intpair twoxthreex(int x) {
return intpair(2 * x, 3 * x);
}
In SML:
fun twoxthreex x = (2 * x, 3 * x)
That's a win. Being able to do this is great for data handling, since we don't need to create structs or make reference arguments when creating a function which returns multiple values. (The latter is problematic for compiler optimization and a less natural way to write programs.) Anyway, this is beside my point.
I hear Python includes support for tuples; in this case the code would probably be more like the latter. That's good, but it's not because "Python is OO"!
Python incorporates some good features from other paradigms, such as higher-order functions and anonymous tuples. I hear that they screwed up with higher-order-functions, but you are saying that they are fixing it, which will be good.
For the case of the standard library, OO provides modularity, which is also found in any other modern programming language of any paradigm. It is not at all exclusive to OO.
So what I am saying here is, Python has already taken my advice and incorporated some ideas from other paradigms. Why does everyone think these come from Python being "OO"? Is it just a buzzword compliance thing? Are programmers really that gullible?
Please god, not C++. Let's pick something type-safe, even Java if we need it to be OO, so that our applications aren't crashing all the time. (Sometimes opening us up to remote exploits.) Who cares if it is a little slower? 1.2 ghz chips are $70, last time I checked...
;)
Anyway, I don't think sticking with one language is good, because it means that innovation will stagnate. There may not be many new ideas in all these scripting languages, but some of us at research institutions think we are coming up with some good stuff...
BTW, I like chocolate chip coookies.
Maybe the problem is that Ruby isn't known to everyone yet. Everyone's heard of C, and many have heard of Java outside of programming circles, but even if you're in the circle, you may have never heard of Ruby. (I think its that scripting language out of Japan).
I recently started an open source project and needed a language to prototype in. Perl doesn't have threads. Python is alright, but it hasn't ever struck my fancy and seems a tad anal. Ruby on the other hand has a host of great features that are very programmer friendly and, here's the kicker, are System Admin friendly!
It's a total non-java dream!!! I don't ever do this, but for the M$ developers in the crowd, you have access to that side of the world too. This isn't a scripting language in the same way that sh or perl is a scripting language, instead I think of it as an actual language that's viable for large projects as well as the small sysadmin scripts that I've historically written in perl. Because Ruby is easier to extend than perl (don't know about python) it tends to see library and package updates more quickly than most and it's got a whole host of libraries to choose from (see your local FreeBSD ports collection for an idea). It really gives perl a run for its money in terms of module support (and often times exceeds perl). Anyway, some food for thought.
-sc
PS Here's a list of ruby modules that are included in FreeBSD.
-- Sean Chittenden
Why did you have to step up on that soapbox and preach about 'real' operator overloading without giving Python the benefit of a doubt about having it and at least checking out what __mul__ does? That the naming convention isn't the same as in C++?
Bah:-/
-
-
Listen. Strange women lying in ponds distributing swords is no basis for a system of government.
You are right, of course, that calling accessors that simply read and write an instance variable is less efficient that directly reading and writing. But using direct access for efficiency is often a premature optimization.
You say there is a potential for abuse of accessors... what is it?
I am a C++ fan. I often defend C++ from the accusations of fans of other languages. But I have to say that if I'm going to give up some efficiency, universal accessor functions would be a good thing to get in return.
In Ruby, Everything Is An Object, and typing is dynamic, so you're not going to be able to write code that's as fast as C++ anyway. The accessors are cheap in comparison!
Certainly it's one of the main reasons I prefer C++ over C, even for relatively simple programs, because C doen't have any natural way of assigning namespaces in a clean way that's guaranteed not to clash.
This is the reason I like Objective-C so much. I like OO in it's purest form, but I could honestly be happy with just C-with-namespaces. Obj-C does this (plus everything else you could want from OO) while still feeling like C. Whereas a language like C++ feels much more like something like ADA, ie increasing the complexity of the language to meet the complexity of the problem, as opposed to increasing the fexiblilty.
Such a price the gods exact for song: to become what we sing - Pythagoras
I can't say I think Perl is a good way to program, even for other people.
You are missing the point. Perl is a syntax, not a "way to program". Programming is an art, and there are good and bad programming styles, the language has very little to do with that.
Ruby's syntax seemed to be an attempt to seduce Perlites to Ruby, when it would have been a better tactic to rally against Perl. People who would like Ruby probably weren't ever happy with Perl anyway.
I have been programming with perl for many years, and I love the language. I also, am not so biggoted that I won't expand my knowledge of other languages. Ruby seems to be a great language to learn, and I plan on doing so. Your theories smell as if they are being pulled straight from your anus.
Probably didn't help that it came out of Japan either, as Japan doesn't really seem to be in the loop when it comes to free/open source software (language barriers?)
Are you from Farm Town, USA? Your simple-mindedness is surprising, even for slashdot. Lots of great open source code comes from Japan, and regardless, it's unfair of you to say that the original author of Ruby has his cards against him simply because of the fact that he was Japanese.
> Python OO is, by the way, far more reflective than Ruby OO
This kind of statement begs more than "a cursory examination of the language"!
Ruby is quite reflective, but as a design choice keeps the implementation of objects private. You can get the list of any object's instance variables, but as an ordinary case you cannot set or read the variables independently of any accessors that may exist.
If you don't want this kind of encapsulation, you can add a (public) method to return an object's "binding" -- this is much like the __dict__ attribute, with the difference that Ruby objects are implemented in private namespaces rather than associative arrays. With the binding, you can munge the attributes to your hearts content.
An example from page 15 of "Programming Ruby":
a = %w( ant bee cat dog elk )
a.each { |animal| puts animal }
prints out the 5 animals names. The following pseudo code shows how the each method could be implemented in class Array:
def each
for each element
yield(element)
end
end
The yield call invokes the block, using it as a higher-order function.
I hope this clears up any confusion.
Then put the operator at the end of the line. In this sense, Ruby is reminiscent of Python--the language dictates style.
Though it would certainly be hard to make changes to the behavior of strings, every problem you mention (with the exception of native floats) is really just a library problem, and could easily be fixed when the time comes. If those particular annoyances are what would keep you from using the language, then by all means, fix the annoyances! This isn't Java, where opinions only count when coupled with deep pockets.
> Ruby's iterators exist to work around the fact that functions aren't first class objects in Ruby. They exist because a programmer can't write higher order functions in Ruby.
1. Iterator bodies are first class objects in Ruby (anonymous instances of the Proc class).
2. Iterator bodies in Ruby are used exactly as higher order functions (they act as true closures).
In the publication you're referring to, C++-style iterators are being compared to Lisp-style mapping functions. But Ruby-style "iterators" are in fact those mapping functions derived from Lisp. So those "weakness signs" actually do not apply to Ruby (that article actually tells that one of weaknesses of C++ or Java is that they do _not_ support iterators in the Smalltalk/Ruby meaning of this word).
> As beautiful as "pure" languages like Java and Haskell and Ruby are,
There is no more "pure" in Ruby than in Perl. You don't have to create objects at all. Just arrange your code in procedures if you like (you don't have to know that all procedures are in fact methods anyway). And you can use "for" construct if you don't like iterator syntax.
By the way, I'm not a fan of "object-oriented" programming and I don't like languages like C++ or Java. But I do like Ruby and probably I'll switch to Ruby programming in my future projects (I used Perl for several years).
And the main thing I hate in Python is it's indentation-dependent syntax. I don't mind other people might like it, but for me -- no thanks.
To get back on topic, I use Ruby too. I've built parsers to analyze code and automate some very hairy analysis tasks. We've written patents and sold projects with Ruby code. I think that Python would next best language that I could have done that work with, but I felt that Ruby gave me much more freedom.
The middle mind speaks!
No good economic reason to use Ruby, I use perl. When I want to OO, I can OO. Most of the time, I don't have the time to plan for OO. OO programs without sufficient thought put in them are a bear to maintain and use. When OO programs have had sufficient thought put in them, they work great! Most of time, I only have time to crank out a simple procedural program with functions I have reused since I started with Perl 3 years ago. Why learn a new language that won't really count as a resume builder? That's the only reason I learned Java, C++ and Visual Basic. Now that I work at the system level, I need only C, SQL and Perl.
"In fact, on the whole, they are simply slowly retracing the early evolution of Lisp and Smalltalk. Perl and Python could have started out being as good as Perl 5.6 and Python 2.1 if they had built on what had come before" Well, but if perl and phyton just retrace the early evolution of lisp and smalltalk, shouldn't you be able to predict where they will end, rather than telling us "they could have started out beeing as good as 5.6/2.1"? Saying "they could have started EXACTLY where they are now" sounds more like trolling, that like a serious statement about those languages. But, of course, we are just retracing a discussing of 20 years ago, and this post ist EXACTLY where it lead ;-))
And they all stink in one way or another. Language biggots should get over themselves. If you can do it in assembler or Java, great, if you can't then debate what language would be best to write your killer app (if only you could). I've yet to see the ONE language and doubt if I ever will. They all have good and bad points. Just pick one and write some code that's worth a damn!!!
o.k. I didn't read every comment posted so far but I hope I got the important ones.
;)
:)
Back to it:
I read about ruby 2 or 3 month ago in a german magazine. It told something about "What's ruby" and a small comparison between ruby and perl.
It sounded interesting enough for me to have a look at the ruby web site and to read a few of the examples shiped with the "distribution".
Well, first of all I should tell that I'm an active Smalltalk developer for a company in germany.
Perhaps everybody knows that Smalltalk is one of the most OO'ish languages around.
As Java began to become more popular I thought I should have a try. I developed one or two little applications and sometimes it was really hard to get along with the OO/non-OO parts of it. There are a lot of workarounds for the one or the other thing but the one most annoying were the int's and long's and char's, etc.
Who needs an int if you've got an Integer???
And here's the point I like about ruby!!!
It's OO, isn't it. At least the most of it.
You don't have to care much about casting this type to that and that to this.
For me, I don't want to care about if it's an int or an Integer.
I really don't know much about perl and python. I never got the time to learn it.
I really don't want everybody to use ruby because it's the best language around. It definitely isn't.
But it's the one I understood in about a few minutes. Because I know OO.
I heard CmdrTaco's speech at the LinuxTag in Stuttgart/Germany (Congratulation! IMHO the best together with Eric S. Raymond).
I wouldn't go as far as to say if you're not using ruby YOU'RE WRONG
But maybe we should give it a chance. Let it grow. Let it be a scripting language for the ones who WANT it.
Perl's o.k. as far as I can say. Python might be really cool.
But ruby is too. Just for me!
P.S. No flames for my really bad english please.
I bend my knees and hail everyone who knows *this* language
What either Python or Ruby should do in order to gain share, is to get a perl-compatible syntax mode written which would enable you to use the massive CPAN libraries. It seems a shame to have to reimplement vast amounts of programming.
.NET
Hmm... wait a second, I think I am describing a specific subset of
Dave
Freedom of speech won't feed my children
>tk if you use cPython
Sorry, but Tk isn't those things.
For one thing, it's about as far from portable as you can get.
--
Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
Currently if you are doing Application development you have a choice of: Java, C/C++, and maybe VB. Then if you are doing scripting, you have a choice of: Perl, Ksh, Python. Do we really need another language to the mix? What does Ruby offer that someone can't do using the above languages?
In theory, languages are not libraries. In practice, I'm sorry, they are. How many people do you know using Java that don't use the classes in java.lang and java.util?
I'm not saying libraries are unimportant, or that the availability of libraries for a particular language is not an important factor for many users. What I am saying is simply that libraries have nothing to do with the quality of a language design.
But anyway, if your language has a foreign function interface, then lack of libraries is not a big deal anyway.
BH
BH
Fools! They laughed at me at the Sorbonne...!
Answer: Because Ruby doesn't have the the support behind it that other languages do.
------
C'mon, flame me!
No sig for the moment.
Sheesh! am i the only one who actually uses comments anymore? it's hard to have too many comments, but i try. :)
Java is the blue pill
Choose the red pill
Have you ever studied Latin? The language used by Caesar, Vergil, Ovid and the like was hardly regular. The number of irregular words (often borrowed from Greek) is not insignificant. The idea that Classical Latin is "constructed" is on its face interesting, but higly suspect... it might be a formalized version of a specific dialect but it wasn't produced largely from scratch. There are analogies to this in French, High German, American English used in legal documents, and probably most every major written and spoken language in the world.
And all languages have rules, otherwise they don't work. We can learn to speak it because it has rules. Sure there are lots of exceptions to the primary rules, but those are just more rules. BTW, spelling is not language, so neither the apostrophe rule or i-before-e relate at all to English grammar rules.
As to why no one is using Ruby? Well, it's brand new isn't it? And it mostly fills a need already met by several much older and well-established languages, does it not? I'd be glad to learn it in addition to Perl, except that I am already productive in Perl and it does a LOT of stuff really easily. I haven't found any library of extensions for Ruby that even comes close to the modules on CPAN.
I do not have a signature
No, not really. Some languages are more functional than others since you can write much more readable code and you don't have to waste time working around limitations and/or bugs. For an extreme example, compare 80x86 Assembly to Python: 80x86 Assembly: ; This program displays "Hello, World!" ; From http://www.latech.edu/~acm/helloworld/asm.html dosseg .model small .stack 100h .data
hello_message db 'Hello, World!',0dh,0ah,'$' .code
main proc
mov ax,@data
mov ds,ax
mov ah,9
mov dx,offset hello_message
int 21h
mov ax,4C00h
int 21h
main endp
end main
Python:
def hello():
print 'Hello, world!'
So for most applications, Python is better than Assembly. (I feel safe making that claim. Assembly partisans are few and far between these days.) So it isn't all personal taste, and it isn't all inertia. The job you have to do plays a role, so does the machine you're programming on. (Does Visual BASIC even exist on non-Windows machines? I ask merely for information.) In my opinion, a one-size-fits-all language is doomed to failure, and the best we can do is to create a few very good, somewhat specialized languages to do different jobs.
How can you use my intestines as a gift? -Actual Hong Kong subtitle.
Dump Python? Are you kidding? Countless man-hours have been invested in creating and becoming proficient in the language. Check out some of the +4 or 5 posts below that explain about some of Ruby's weaknesses. It's not like Ruby is the end-all and be-all of programming! My gosh!
I said *TOO MUCH* diversity is bad. Not *ANY* diversity. Open source is about COOPERATION, and the only way that can happen is if those who are cooperating have a common reference point. If there were 300 different programming languages, each with their own compiler, used throughout things like the linux kernel, and GNU utilities, how much help could people give in their spare time? I mean that's rediculess, but basically there has to be a balance, and I think that balance has already been achieved. Perl is great. Python is great. Java is great. They all do different things well, and if you want to use Ruby that's fine, but don't expect other people to learn it or extend/enhance what you are doing, it's a big burden on people who already spend too much time every day programming as it is! I'm not meaning to be a troll here, but I think there has to be *SOME* form of unity for Open Source to work. Right now we have that, as most projects are done in C, C++, Java, Python and Perl (with occasional lexx/yacc stuff). This is one reason open source has been so successful, the sheer volume of people working together. We really don't *NEED* another language, as good as Ruby may be.
If this offends you, I'm sorry that's not the point. And I"m not saying that any group needs to decide for the rest of us which languages to use, but in a way when Linus made Linux in the first place, he decided a lot of it, same with the FSF and GNU software.
This was not meant to be a troll. Sorry.
In Python classes are first class citizens (i.e objects), and having a (temporary) name for them is not that big a hassle.
really nice features typically not in OO languages, such as higher-order functions
Python has these... and this feature will get better in the next version (2.2) when nested scopes become a "standard" feature, instead to having to import them from the future.
So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping.
I don't think so. With Python you don't have to inherit all that much: if you have an object "a", and you call its method (a.doSomething() ), the engine will look is a supports such operation and will call it. You don't have to inherit to implement interfaces.
So I guess what I'm saying is, be sure you know what you mean when you say "OOP", since there is very little which is particularly special about OO languages. In my opinion, there is not much need in scripting language for subtyping.
Not for subtyping, but for objects, yes. OO makes using various libraries quite easy, even if you don't have an idea how that library is implemented. And as far as Python goes, it's not just a scripting language, it scales excellently to Java-C++ type of tasks.
All in all, I am yet to see Ruby compared extensively with Python. I can't believe would have any advantage in such comparison, even if it might (and probably will) compare favorably to perl.
Save your wrists today - switch to Dvorak
two, three = twothreex()
twothreex returns a tuple, (two, three) is another tuple. The code above becomes an operation of assigning a tuple to a tuple. That is, invocation of "assign" operation on a tuple, with one argument - another tuple.
I hear Python includes support for tuples; in this case the code would probably be more like the latter. That's good, but it's not because "Python is OO"!
No, it isn't - but it's implemented in an OO way, which makes it simple to understand and the language stays orthogonal.
I hear that they screwed up with higher-order-functions, but you are saying that they are fixing it, which will be good.
It is fixed already, but the fix breaks up some code, so you have to mention in your source that you are using this feature. In 2.2 it is no longer optional.
For the case of the standard library, OO provides modularity, which is also found in any other modern programming language of any paradigm. It is not at all exclusive to OO.
Standars library often provides entities that are most naturally represented as objects - sockets and mutexes, for example.
So what I am saying here is, Python has already taken my advice and incorporated some ideas from other paradigms. Why does everyone think these come from Python being "OO"?
Python being OO surely helped to make these features easy to use and understandable. Dynamic typing also helped, though - an advantage that C++ and Java lack.
Save your wrists today - switch to Dvorak
Actually, the formatting isn't that big of a problem and you will learn to like it with time. And BTW, you not using Python is your own loss, and possibly also a loss for the company you are working for.
Save your wrists today - switch to Dvorak
You can hardly compare Python with Perl. Perl excels at trivial tasks (simple sysadmin things) while Python delivers stuff that software engineers need (excellent OO, dynamic (but not loose) typing, and scalability).
Save your wrists today - switch to Dvorak
IT IS A MERE MATTER OF TIME BEFORE RUBY EMERGES AS THE PREEMINENT PROGRAMMING LANGUAGE OF THE EARLY 21st CENTURY. Why? The pure elegence of design. Ruby is simply the best. Pure OO, clean syntax, etc. For the first time ever, I was able to rapidly learn a new programming language and churn out a fairly complex program with very few bugs, right off the bat! Of the many tounges I have ciphered, no other has done nearly so well. And from the rumors I hear, Ruby is on course to take over, even the likes of (dare I say it) C++. (Read: Complied Ruby) ALL PROGRAMMERS BE ADVISED: RUBY IS IN YOUR FUTURE.
:T:R:A:N:S:
While I do like Ruby, it doesn't have the support behind it that Python does. Thats why I use Python, and not Ruby.
/. that
ksh can do most anything
perl can. Why not use ksh, then? Ad nausaeum.
This is a nice example of path dependence. You use it becuase more people use it, and so on and so on. Things that don't catch on sometimes don't catch on because of tiny, idiosyncratic, reasons, but then the competition snowballs. The canonical example of the QWERY keyborad is overused (and sometimes disputed), but you get the idea.
Besides, there are so many scripting languages. David Korn pointed out here on
"Never bullshit a bullshitter" All That Jazz
What's wrong with asm?
It's fundamentally non-portable, and less readable than C.
Paul Anderson
"I drank WHAT?!" -- Socrates
I don't call that procedural. I can create static container classes in Java too.
It is not just the function namespace itself, it also means having straight types which aren't OOP contained.
One of the major uses of this is that you can write gluecode to external code/data in the language itself.
Because it is purely OOP. I like to be able to switch between OOP and procedural programming depending on the job (or the part of the program I'm working on), without switching languages.
It is also said to be slow (not an own experience)
C++ is not ideal to standarise on. It carries too much legacy.
A redesigned cleaned up C++ might do it (though it would pretty much look like Delphi's Object Pascal I think)
I know that in IT you HAVE to spend your whole life learning; that's just the problem - if you want to learn another language, something else has to go by the board to make time for it. But in my case that "something else" is something I don't know about and I need to use, whereas the languages I know already are more than good enough to get me by. Learning a new one is therefore not a priority nor a productive use of my time. Mind you, for somebody starting IT from scratch, Ruby could well be a better choice than the languages I started from scratch with. Come to think of it, I don't think I've had the chance to actually choose a language on its merits.
No, your children are not the special ones. Nor are your pets.
You wrote:
Sometimes, we need a scripting language within some other given program. C++ just wouldn't work well, with all its flexbility and power; your standard user out there doesn't want to worry about memory allocation and such. Imagine if your web page incorporated C++ instead of Javascript.
You also wrote:
I agree that a programming language is much like a paintbrush, but consider that your better artists tend to use a variety of brushes to achieve a given effect. So it goes with computer languages; some languages lend themselves better to solving certain problems than others. As ever, do whatever works best for you.
ObTopic
Personally, I haven't used Ruby because I haven't found a need to, yet. It looks intriguing, but Python seems to be easier to work with, as scripting languages go. But then, that may be because I've gone through Python tutorials and such.
Still, with so few people knowing Ruby, and so many more people knowing Perl or Python, I would sooner incorporate Python or Perl in an application than Ruby. One doesn't perform 14th century chromatic Italian madrigals for a country-western crowd. It just isn't accessible.
And so it goes.
Ah...
Minor point of clarification:
Imagine if your web page included client-side C++ instead of client-side Javascript.
And so it goes.
Anyhow, that's why I don't use it.
Zero Sum (don't amount to much). [root@localhost]
Also, I still have not mastered Perl yet (lathough I am quite good with it). Which puts meat a disadvantage when trying to compare. I doubtless will learn Python. But at first glance - there is no hurry. Using formatting as a language construct is still a bad idea. I remember when almost all languages required such formatting. Believe me, format dependant code is something from prehistory. To be avoided.
Zero Sum (don't amount to much). [root@localhost]
Similar to COBOL and the various BASICs out there, a legacy language could be defined as any language which is _ONLY_ supported because there are systems which critically depend on their maintanance.
The more commonly pleasnt languages like C and C++ exist because they are required to support a vast majority(? okay, a _lot_) of software out there; but most notably, they do what they were designed for well.
If any new language intends on surviving, it needs to focus on an aspect of what the language needs to achieve to exist, and do it more elegantly, with more coordinated tools libraries than any other language in its category currently supports. This is why Microsoft can and will ram C# down societies throat. (If only all the genieii of the language development society could coordinate development better).
Now, getting back to the topic:
For any mainstream programmer (non fringe), what they're currently using as a language is more than adequate at aiding them in what they're developing. As soon as they need a different language (one that tackles a different paradigm/problem), they'll look for the best there is; the most documented; etc; etc.
Hopefully that'll be ruby, mabey it wont. But whatever it is, it needs a lot of support because any programmer hates/detests the maintainance of old software.
Once in a while a language will shine and all that documentation and support grows because:
a) The language solves a perticular problem well;
b) There is nothing as well suited to solve the problem
c) The language is elegant
Its late, i need coffee.
Maybe you should check it out again. The documentation is much better now and I'll bet you will see that it has came along since then. Mind you I didn't use it back then but I know that it for most things is now faster than python but still slower than perl.
-- Tyler >+++++++[-]++++.---------.+.++++.++.
Actually no my pet language is Perl. But Ruby is pretty cool and yes It being on slashdot would attract a little attention but how else will it be discovered.
-- Tyler >+++++++[-]++++.---------.+.++++.++.
Wow! yeah such a novel idea. Lets put all of are eggs in one basket and only use one language. Why has no one thought of that before. But really can that be a good idea? Maybe we should all switch to VB who needs anymore than that. Follow this guys plan and lets kill innovation.
I am sorry to sound so rude. But I have never heard of such a... Well, such a dumb idea.
Stupid people should just wear a sign then you would know not to depend on them.
Here's your sign
-- Tyler >+++++++[-]++++.---------.+.++++.++.
Some of you have made comments that a company would not want something this new or YOUR COMMENT HERE. Well, I agree for most situations it may not make since to use Ruby in the corporate world yet. It is pretty new and managers like something tried and true. And I see the point of not being able to find someone to update a program written in Ruby very easily yet. But I as the question stated I was asking you all as developers from the open source world not as code monkeys slaving away at work. I wanted to know more reasoning based on you and not that the suits would not approve. Right now for most businesses will stick with Perl, JSP or uck even VB or something I realize that. So I guess maybe I am asking in a more academic since. Forgive my spelling
-- Tyler >+++++++[-]++++.---------.+.++++.++.
I love these lists. Come on everyone, drop your drawers and starting measuring your penis!
I looked at Ruby once, but gave up bothering with it fairly soon. I guess the learning curve was just too steep. I couldn't find out what the language's actual paradigm for values / variables / types / objects was. The tutorial was telling me that even integers always were objects and had some quite confusing examples to show just that off. Showing how you still get normal things done first would have been better...
Just my 2 euro-cents.
-chrisp
"If that makes any sense to you, you have a big problem."
NewRiders just published second edition of amazing "Python Essential Reference", updated and expanded for Python 2.1 it's the best Python book money can buy...
I believe it may even have been designed to look like perl's.
Take a look at ...
Ruby DBI
Seriously, though, I don't know anyone who's played with Ruby who hasn't thought it was very nice and an incredibly productive language to work in.
Admittedly, some of those people still write perl or python, or whatever, because they're forced to at work or because they need some library that's not available (yet) for ruby.
But many of those still write ruby for fun, when they can, because it really is very productive and intuitive.
The only such book I've ever heard of is Programming Ruby from Addison-Wesley.
There are a couple of other books from O'Reilly, but currently only in Japanese.
Of course, I'm not sure we need a hundred books on Ruby. The one we have is excellent, the on-line support from newsgroups and mailing lists is fantastic and the language is just so darned intuitive that most of the time you can guess how something works, without needing to read about it.
I guess some books on things like doing database or web development or using library X might be nice.
I'm a PHP and Perl person myself, and they are perfectly adequate. If there was a well-written, non-biased article outlining why Ruby would benefit me, I might consider it. But as of now, I've only heard of it...I know nothing else, and have no desire to learn anything about it.
----------
qslack.com
Yup. I use it quite extensively.
I quite simply *hate* Perl - Tcl is infinitely easier to read and understand old code.
I've just implemented a large image processing (production) system
using Tcl as a 'glue' language - it's great string-processing and regex tools made life *much* easier than doung it in C or Java or something. (IMHO).
One thing I like about Tcl/Tk is the wide range of available extensions.
If you need something, it's probably out there -- if not, it's pretty easy to write extensions of your own.
There are certain extensions I wouldn't be caught dead without:
Tclodbc (odbc interface - with odbc/odbc bridge from Easysoft, can also talk to Windoz DB's from unix)
Metakit (Nic lightweight embedded Db - no more using MySQL for a 100 line script)
TclX (Various things missing from base Tcl, including named pipes, etc.)
iTcl (Object-oriented Tcl, for those nice *big* complex apps)
For fun and excitement, I like Borland C++ Builder. Is there anything you really can't do with that?
On topic, I want to pose the following: what would motivate me to explore Ruby, as opposed to C#, beyond my disdain for Redmond? Looking for technical arguments, not political ones.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Well, if you are constantly hassled by more codebase to use (more to learn, more bloat to be added), better development tools (that take more time to learn than the time you might save), more documentation (for new products that does exactly the same as the old products, except everything is different), how are you supposed to get the time to work? When are you going to sit down and simply hack?
Yes you're right. Keep it simple and complete. Thats why I code in brainfuck. That way I can get started faster than the Java developer using JBuilder. I'm bound to be more productive right?
Besides, I doubt more shit means better jobs. A good job is somewhere where you can simply do your thing, and get paid for it, not somewhere where you will have to incorporate every buzzword in a project description to be able to get something done (even if you get paid more). Let's face it, new doesn't mean better. For what it does, Fortran is a great language. It lets you get things done.
Agreed. I'm just saying more perl users --> more perl jobs --> more perl users.
And if you really believe open source will magically give you faster development, then you really need a reality check. While it might be true of some specific projects, it is certainly not a universal truth. Put 3-5 fulltime developers on a project, or 100 student hobbyists and watch who can keep up with deadlines. Open source certainly has some benefits (especially for the customer), but it is certainly not a silber bullet.
I'm not saying open source gives faster development, period. I'm saying open source Java development moves faster than open source Ruby development mainly because there are are more Java coders. If a language is growing it makes sense to jump on "the bandwagon" to reap the rewards. And if that isn't clear enough, I'll state it more clearly.
Ruby is a well designed, very easy to learn, language. It's userbase is growing. "Jumping on the bandwagon" will have many advantages.
-... ---
the bandwagon?
Being on the bandwagon is what gives you more codebase to use, better development tools, more documentation/faqs/books, better jobs, faster development with open source, etc...
I'm on the bandwagon.
-... ---
No kidding. Have you checked out the speed of Java? How absurd!
How do companies like Sun get away with such apparent industry-acceptance of such ludicrous "products"?
Suppose there are dozens of examples of the same :-) Doesn't make it any less puzzling.
While we're on it, can we mod the article ("Why not Ruby?") as a troll?
i have to agree. i was a PERL-man but have finally switched to python. the syntax is SO clean and it does everything that i want.
keep it simple.
I mainly use Perl, but have written a few utils in Python just to get a feel for the language. I've got to say, while Python appeals aesthetically, I can write anything an order of magnitude quicker in Perl (thought familiarity is doubtlessly an issue here.)
Ruby is, IMHO, even more attractive than Python for its more thoroughgoing object orientation, for example in Python you would write:
foo = "HeLLo"import string
bar = string.swapcase(foo)
Whereas Ruby treats foo as an object with its own methods from the word go:
foo = "HeLLo"bar = foo.reverse()
Add to this other goodies like block iterators and Ruby is looking very good.
What would stop me using Ruby is firstly the relative lack of maturity. (Though for some it would be an attraction to get into a language at the ground storey). And secondly the relative (and related) lack of Ruby programmers. The fact that Ruby can be written in a dialect that can be easily understood by Python (and even Perl) programmers, mitigates against this to some extent.
I'm not sure about support, but the availability of a free on-line text Programing Ruby (you can also but the hard copy), and a discussion group at Ruby Garden might go some way to alleviating your fears in that regard.
All in all Ruby looks like one of the nicest little scripting languages around -- Smalltalk meets Perl meets Python -- and I wish it the best of luck. With a bit of maturity I might even consider applying it in a production environment.
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
It is available for Win32, and MacOSX. AFAIK, it does not run on ealier MacOSen, but if I'm wrong I will surely be corrected.
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
errrr ... I meant to write:
bar = foo.swapcase()for the Ruby example ... of course!
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
Oops, about time to upgrade from 1.5.2 then :} That addresses one of the major complaints I had about Python then, do the various numbers etc also have their own methods now (as they do in Ruby)?
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
Huh????? Ruby is exactly as strict as Python is.
I think Python is much more suitable for Java programmers for a very simple and pratical reason : Jython, the Java implementation of Python. Jython can use Java packages with zero overhead, and you can inherit Java classes in Python, and inherit from Python classes in Java. That's extremely convenient.
Thus there is no proof. In fact on some tasks, Python is faster, on other Ruby is faster, and more importantly, neither is faster than the other by an order of magnitude.
As for Stackless Python only being about continuations you are wrong. Stackless Python also allows for OS level threads in Python. This allows for system calls not to block ALL interpreter threads. As for the utility of continuations, I too haven't heard anything compelling, but my imagination can come up with vague ideas about many many concurrently running state machines with out using threads or explicitly building a framework by hand.
Continuations break some semantics, and always slow down code, whatever the implementation. The showstopper of continuations is that they can't be implemented in Jython, and they break user C extentions, each of them and hundred of times more useful in the average case.
Guido has OVERLOADED the meaning of white space.
And why is this a tragedy ? Your reasoning is essentially: "AAAAAAAAArrrgh ! I'm *NOT* accustomed to *THIS*! I *cannot* stand *this*! It *must* disappear". This is mostly irrationnal since Ruby code is essentially Python code with "end" added at every end of block and vice-versa.
Oh yes, and note that Ruby is using newline as a statement delimiter, something in most other procedural/oop languages isn't done. Ruby is overloading newline. So what's your point?
Getting reference counts on variables was hard. Python has the same issue. Ruby doesn't have this issue due to it's mark-sweep memory management.
Python 2.1 has some GC ; you are mistaken if you think Python programmers couldn't write a mark-sweep GC. Guido & friends, have choosen deliberatly to use GC, to avoid problems with C extensions. Simple example: imagine you have a 128 MB array which include a reference to one C++ object, which could (or couldn't) have a reference to a Ruby object. Are you sure Ruby doesn't need to scan the 128 MB array ? And reading memory at random might lead to segfault.
Lexical scopes...Python doesn't have them. It has the namespace scope (global) and the function scope.
Python 2.1 has lexical scopes as an option, and Python 2.2 will have them.
I must admit I am doing some amount of speculation here, but I believe (with a tiny bit of support) that because blocks were relegated to second class language constructs, Guido didn't want lexical scopes (prolly to confusing for the slope headed Python programmers ;).
Blocks aren't first class language constructs. But this is a choice. Like, in Ruby, functions aren't first class objects.
However, Python has many idiosyncrasies.
Wow, and Ruby has absolutly none ?
It has its own share of historical oddities like tuples (constant arrays, why not constant hashes, or constant variables, or even a 'constant' modifier on all types)
But Ruby has none, 100% sure guaranted ? And Python oddities are so numerous that they cripple every single line of Python code, turning it into a unreadable mess ? Is this what you are contending ?
I dunno, is there a CPAN equivalent to Ruby ? I'm really not on the mood to re-invent the wheel.
healyourchurchwebsite.com - WWJB?
Actually, language doesn't limit thought, it limits communication of ideas. This means that when you have a new idea that doesn't fit in your language, you invent new terms and, sometimes, grammar.
Reboot macht Frei.
Why don't I use Ruby?
I looked at it. It's only different from Python/Perl/TckTk in insignificant ways.
If readers really want to learn something different, try Haskell.
Oh sure you will come back and end up using Perl/Python/TclTk with C/C++ like I did, but you will at least know how expressive and elegant a programing language really can be! That is if you can make it past the front door...
In any event, dispite all that, I dont use Haskell either. The implementations that are available leave much to be desired. That is a shame, but it is a research language, and is not at all popular.
But its fun. After looking at it, I have never looked at language wars the same way again. Maybe someday someone will put together a usuable (by the masses) implementation...
Ruby ? Blah.
Cheers!
-> Ron Legere I can never think of anything clever to put here.
If too many people think like you, we will not see IBM invest in Linux, we won't see people switch from AmiPro to WinWord, we won't see AMD taking more market share from Intel... I don't see why Slashdot rate your article "Insightful"...
That is definately a lang worth learning
Screw 3...
Screw 3...
big whoop? ^_^
Screw 3...
Besides, if you can write in that, you can hyper-speed programs and better understand the intricacies of them.
Screw 3...
C++ is absolutely horrible if you're doing anything numerically intensive. C++ is high overhead combined with slow execution time. FORTRAN is very good for numerical stuff, but it still has quite a bit of overhead in actually getting a program to work. Perl, Python, and MATLAB are good when you're willing to sacrifice execute time to get a program written quickly... and Ruby looks interesting for this as well...
There are 10 types of people in this world, those who can count in binary and those who can't.
One thing that no one has mentioned in this discussion is that Ruby implements Perl to a significant degree -- (very) trivial scripts can be compatible with both Perl and Ruby.
Another important thing to keep in mind is that no one is forcing you to use iterators in Ruby, just as no one will force you to use them in Python 2.2. You can write a for-loop if you want. It's significantly easier to write an iterator, however, in terms of time and resulting code complexity.
It's not that I don't understand it. I do completely understand the idea of an iterator (with a name like that, who couldn't?)
No, you don't. Really. You perhaps understand the concept of iteration, but not the concept of an "iterator" as implemented by languages such as Sather, Ruby, and (if I recall correctly), a forthcoming version of Python.
I mean, you must be joking:
as beautiful as "pure" languages like Java and Haskell and Ruby are,
multiple programming paradigms well, like O'Caml, and Lisp, and Python.
That decides it for me. How can I turn down that kind of guaranteed job security? But I think I'd go this one better by my own idiosyncratic language to write mission-critical code which nobody else can maintain.
Oh wait a minute, they already did that. It was called Fortran.
(No, I'm not serious.)
Inventor of the LOLbalrog meme.
Just because some clown learned to write an interpreter at school, he decides to convert the world to yet another scripting language. ...). Persuade everybody using that one to abandon it and switch to one of the others. Translate all scripts in the abandoned language to one of the others. Persuade all the sysadmins in the world to delete the interpreters and libraries for the abandoned language from their machines. Benefit to the community: petabytes of diskspace saved worldwide, forests saved by not printing more books about the abandoned language, person-centuries of programmer time saved by not having to debug a script in an unfamiliar language, and more. ...
Maintaining support for a scripting language takes resources - not just disk space for the interpreter, but also sysadmin time to keep up-to-date with the latest version, versions of libraries, etc. This is a significant burden, in return for (at best) a tiny benefit in programmer convenience. If some kid wants to really benefit the community, I suggest he/she take on this assignment: Pick one of (Python, Perl, Tcl, Ruby,
But it's so much easier to write yet another interpreter
With sub-typing, you can catch a whole class of exceptions with one statement. This way, you don't need a different handler for each conceivable error type. Ex: in Java you can just catch all I/O exceptions with the same statement instead of worry about the different exceptions that fall into that category (end-of-file, zip, file not found...). Each of the sub-classes will produce their own specific error message when the toString() method is called so that you don't have to have some gigantic switch statement to provide relevant information).
Aren't inheritance and sub-typing basically the same thing?
It's interesting how you choose data abstraction and encapsulations as the most important aspects of OOP. Those are the features that can be implemented in a procedural language with the most ease. Trying to get inheritance working in a language like C is a lot harder than having a few private fields and making accessor methods.
Check it out if you like.
CSMaster
It's all done with C++ CGIs.
I'm not opposing your statement, I'm upholding it only you left out a piece. C++ is really great for some things, but in certain cases you need scripting languages (even scripts generated on the fly by c++ programs). =)
-----------------------------------------
Remove the Greed which plagues mankind.
I think that there is a lot more than mere functionality to look at when one considers OOP vs porcedural etc. I prefer OOP just because I find it VASTLY easier to conceptually deal with. I think the beauty of the approach derives from the fact that we have been dealing with real objects sinse we were born, and it more closely mirrors our natural ways of thinking.
For instance, if I offer you a Flaming Flamingo, your first question would probably be "what's that?" i.e. "what class does it extend?" I would say its a cocktail, and you would make your decision based on the information you know about the superclass "cocktail" (e.g. it will get me drunk)rather than relying on an exact explanation of the chemical composition of the fluid, as the metaphor would extend to describe the same thing only if it were in purely procedural programming.
-The art of programming is the pursuit of absolute simplicity.
No, the analogy stands. For example, why doesn't all business application development get done in COBOL, or FORTRAN, or C, or C++? Because newer languages are more productive. They have substantial improvements in areas like automatic memory management, type safety, etc. There's no question that we've had significant advances in programming languages, so the only thing you can really argue is whether we've somehow reached a final plateau of language efficiency. Even a small amount of research into past, current, and cutting-edge language features makes it clear that this is highly unlikely to be the case.
You seem to think that functional languages are somehow more "advanced" than procedural languages. There is no objective reason to support this conclusion -- it is like saying chocolate ice cream is more advanced than strawberry
There are plenty of objective reasons, but they probably go beyond the scope of a /. discussion. I come across these time and again as I move between commercial work in languages like Java and C++, and other projects in languages like Scheme and ML. First-order procedures are a good example: the lack of these in languages like Java and Visual BASIC makes all sorts of tasks much more difficult, requires more code, and may even require code generation to achieve dynamic behavior.
In fact, it can be argued that many of the more advanced features in modern programming language derive from functional roots - see Mainstream Influence Of Functional Languages. The reason for this is that the mathematical formalism behind functional programming, e.g. the lambda calculus, provide a far more consistent basis for the development of higher-level features than the ad-hoc design of many older programming languages.
All of them (sans a few mini-languages) are Turing complete and so are objectively exactly the same.
This is such a common claim that you'd think people would have figured out how meaningless it is by now. As another poster mentioned, Unlambda and Intercal are also Turing complete, and their existence alone effectively disproves your argument. However, to make it clearer, I'll go back to my analogy: all methods of transportation are equally capable of getting you from point A to point B. The question is how long it will take, and how much effort you will have to expend to get there. Advances in programming languages are quite closely analogous.
I *know* that new languages can't really make me more productive
How do you know this? And which languages do you know? If you've never experienced the productivity differences between different languages, you can't be familiar with much of a variety of them.
My point is that today, the majority of new business applications are not being written in these languages. The reason is that they lack features that can be found in more modern languages like Java, or even Visual BASIC.
Any such "proof" of the superiority of one language over another can be easily denied by the supporters of another language exactly in the manner of religious arguments.
I'm not talking about religious wars kinds of things, or saying that a particular language is best. What I am saying is that over the past 50-odd years, programming languages have become more sophisticated, and that the features of more advanced languages provide significant efficiencies over older languages. Older languages that lack these efficiencies tend to fall out of use.
FORTRAN and COBOL are two examples, notwithstanding their continued use in somewhat evolved forms. Their evolution, in fact, only proves my point. No-one is using FORTRAN I or FORTRAN II today, because they are too restrictive and lack useful features.
One example of an important "new" programming language feature that is difficult to refute is automatic memory management. It's easy to demonstrate the productivity differences in programming in a language without this (e.g. C) vs. one with it. The use of languages in the marketplace reflects this difference.
Functional languages have comparatively little support outside academia, and even there they are fading somewhat because their typical use, symbolic AI, is no longer the "hot" area of CS.
In academia, fading and being replaced by what? My experience is the opposite - functional languages are the focus of much CS research, driven by the development in formalisms such as polymorphically typed lambda calcus. There are few other areas of computing science with as rigorous a basis, or that so directly provide powerful language features.
But I won't argue that the pure functional languages have little support outside academia. That's not my point. I brought them up as an example of a rich source of advanced features, some of which have been assimilated into mainstream languages over the past few decades, but many of which have not. My point is that mainstream languages have not even come close to reaching any kind of plateau in terms of their features and capabilities. If the history of language development is anything to go by, mainstream languages will continue to adopt functional features over time, and increased efficiency is likely to follow from this.
Someone writing in a language that they like and know well is more productive than someone writing in a language they hate or don't know well.
Yes, but to make a meaningful comparison, one has to compare people writing in languages they know roughly equally well. Anecdotally, my own experiences and those of other people I know between C/C++ and Java, for example, would seem to support the idea that language features can provide improved development efficiency. The fact that C/C++ is not used to write most business applications is another data point in support of this contention.
There's another aspect to this which may be closer to what you're thinking of. Programmers who are unfamiliar with advanced programming language features tend to take a naive approach to development in which each problem is addressed anew. The "cut and paste" antipattern is an example of this. They write essentially the same code over and over, varying the details to achieve the desired results. Many reports or data entry screens written for business applications are an example of this. In such cases, advanced language features may indeed be wasted. However, such programmers are only capable of writing trivial programs. When writing programs to solve difficult problems, advanced features can become essential, or in their absence, a great deal of effort has to be expended to compensate. For example, an advanced programmer forced to write reports or screens in C might develop a generalized, data-driven reporting or screen layout engine. This, in effect, is developing a new language, in a sense to make up for limitations in C. In this sense, good programmers develop domain-specific languages all the time. It is in these areas that mainstream languages tend to be fairly limited. It's certainly not unlikely that the mainstream may never "need" (or realize that it needs) such features, but many of them may be added "under the hood", as with features like garbage collection.
I know from experience, and I know quite a few, languages having programmed since 1981. let's see:
Basic, Pascal, C, C++, Java, Forth, Actor, Perl, Python, Ruby, tcl, awk, Smalltalk-80, Emacs Lisp, ML, Eiffel
Our experience intersects to quite a degree - I can't claim any real experience with tcl or Ruby, but I've either written real code with the rest, or at least played with them quite a bit. Pre-1980, I can also add COBOL and FORTRAN to the list, and more recently, things like Self, Scheme, Haskell, and OCaml.
I'm amazed, though, if you have real experience with Smalltalk, that you can't see the productivity advantages it can have over something like Java. Are you familiar with programming techniques which parameterize behavior using first-class functions, for example? This isn't directly possible in Java, which forces one to use workarounds such as a functor-style approach, or actually generate Java code. Either way, it's less productive for the same kind of reason that dealing with memory management in complex C programs is unproductive: it takes additional time, leads to its own class of bugs, and has nothing to do with the application domain.
I notice your list is heavy on procedural/OOP and light on functional. ML is a nice language, but I'd recommend you pick up a copy of The Structure and Interpretation of Computer Languages (SICP) and spend some time with it (from your comments, I can't imagine you've read this). It's probably one of the best introductions to some of the concepts I'm talking about.
Personally, I think it sucks. I don't want "obj.foo = bar" to be able to have side effects.
XHTML 1.1 incorporates Ruby.
I think you'll find that Python 2.x has string objects that know about string methods without having to import a string module. Ruby sounds like its worth a look though :-)
For me, Ruby is the language which, after many years with C++, Java, VB(ahem), and Perl, finally made programming fun again. The sense of power I felt when I realised how flexible, orthogonal, and expandable the Ruby package was, was just like using C for the very first time!
Of course, I could have experienced that flexibility and orthogonality by using Smalltalk or one of those other academic languages. But the real power of Ruby is that you get all that stuff, but you can still do actual useful things with it that get results.
Within minutes (quite a lot of minutes, but hey) of compilation on my W2K box, I was scripting MS Office, bringing up a TK GUI, calling native C code, and animating a web page, all in Ruby -- and simultaneously I was coming to terms with the fact that at last I was doing all this in a language that was actually fun.
Oh yes.
BEGIN NITPICK
That said, considering that the language originates in Japan, it's quite wonderful how appalling the internationalization features are. If you want to use any calendar or character encoding other than the ones it comes with, you are f***ed, and even THEN it sticks to this weird-ass 'one byte == one character' belief.
This is being fixed in version 1.7 -- badly.
Still love it, though.
END NITPICK
Whence? Hence. Whither? Thither.
Yes, the Open Source Scripting Language Steering Committee should finally decide on an official scripting langugage for all of us.
In many ways I agree. Not too many programmers even know that there are other types of perfectly useful paradigms besides procedural and OO. I didn't fully appreciate this until I took a 4th year programming languages course. The theory behind some of these other paradigms is rather fundamental in nature. The pure simplicity and elegance of the lambda calculus makes it something that I think everyone should know before they consider themselves an excellent programmer. Believe it or not, this type of knowledge will be good to know in practice, especially if you're ever working on a compiler or interpreter, or designing or choosing a language for some particular application. If you are ever working on some kind of meta-language type construct to facilitate your work, you may find it invaluable to know about things like closures and such. Even for very routine tasks in an imperative or OO language, simply knowing something what higher order functions ARE and how you can implement them may make your designs easier to create and understand.
That said, in the real world you'll probably rarely use a functional language. But they are out there. Lisp-like functional languages are not uncommon as extension languages in large applications. And something like Prolog can be useful for quickly prototyping certain things. To limit yourself to OO and procedural paradigms is short-sighted I think, especially to think that one is a silver bullet. The paradigm really has little to do with the language too. There are languages like OCAML and that make it easy to program in either OO, functional, or imperative style. To say that one paradigm is best for scripting, and one is best for large applications is also limiting, I think. OO tends to work well in large applications, but there's no reason you couldn't mix it with a functional style, or use an imperative (procedural) extension language to develop certain parts, if appropriate.
I think the moral of the story is that it's good to learn and be familiar with as many different styles and languages as possible. Be familiar with the theory behind all of them as well.
In the past I've programmed in C, C++, Java, Jython, Python, Perl, Clips, Scheme and Tcl/Tk. What I like about Ruby is the 'everything is an object' mentality; this has saved me a lot of time and hassle learning the language.
.jp page. Many of the hooks or modules that would be standard on Python or Perl are also not available for Ruby at this time.
What I don't like is all the 'end' statements (mostly because I tend to forget or mis-place a few of them).
If anyone at "BlackAdder" is reading this I would love to have a Ruby IDE. One thing that I would love to have is the ability to 'compile' the scripts. I'm not interested in preventing reverse engineering or improved performance; I write code that may be put on a firewall or other secure machine. We don't allow interpreters or compilers on the systems, therefore I can't use rb2exe or similar programs as they require the interpreter.
I think part of the problem Ruby has, at least for now, is that most of the original work is in Japan. When I try to find information I usually have to work from a translation, or read code on a
--
Sounds like you perl junkies are looking for an excuse to ignore Python! -Paul Komarek
But since there are orders-of-magnitude problems that sometimes need to be solved, how does Ruby do in integration with C? Python seems to do fairly well -- though I haven't used it myself -- and putting certain operations in C is a good way to speed things up. Numeric Python seems to do a lot with this, for instance. How hard is it to do this in Ruby?
But that aside, Python isn't perfect, and there are definately places where it is too loose (mostly in its object system, IMHO), and too strict (the indentation thing can be annoying sometimes -- and damn the person who invented tabs!)
But Python is pretty okay. And it's only like Perl in that they are both mostly procedural languages. I'd like Ruby for its OO system, and the clever tricks it allows. (I haven't actually used it, but I've used Smalltalk, and the abstractions that Smalltalk made and Ruby copied are really good) But why, oh why, did it have to use Perl syntax? Who would ever want such a thing? If they did, they'd use Perl. Or awk. Or bash. Or C. Or all the other stupid languages Perl took its syntax from. People who like Perl seem to like Perl. People who hate Perl come to Python. Ruby's syntax seemed to be an attempt to seduce Perlites to Ruby, when it would have been a better tactic to rally against Perl. People who would like Ruby probably weren't ever happy with Perl anyway.
Python was the right thing at the right time (and even then it was just Yet Another Scripting Language for some time). It defined itself in a compelling way. Ruby was just a little too late and not compelling enough to any one audience -- somewhat compelling to several audiences, but you need to do better than somewhat.
Probably didn't help that it came out of Japan either, as Japan doesn't really seem to be in the loop when it comes to free/open source software (language barriers?)
I think the real benefit of OO for scripting is it is a good metaphor to use when organizing the standard library. And a good scripting language should have a good standard library. Not only that, it should have a good set of third-party libraries, which means you can't just hard-code the organization.
Why is it stupid? The majority of the total-cost-of-ownership of any system is in maintenance and support. It's nothing to do with "politics". Do you whine and complain about having to comment your code too? To write documentation? To submit to code reviews? Those nasty political managers, making you do your job like a professional!
Using a new language for its own sake, with no thought to its suitability is foolish. Its rare to find a specification which doesn't stipulate that a system should be developed with ease of maintenance and extension as key success criteria.
I for one hate office politics but they are a fact of life and explains why MS is so popular.
Like most slashbots, you can't let a post go by without a dig at MS, can you? Not that it's even slightly relevant here, of course.
Nah, part of building on what came before is knowing what to throw out. Perl 1 was very much a knockoff of `sh' scripting and `c' coding mixed with `awk' and `sed'. Larry Wall wanted a common interface and a more rational data model to tie them together with. From a broken but standardized scripting language to a cleaner syntax stolen from `c' and two of the best tools' tricks built directly in was athe basic plan there. Building on sh would have made it a nightmare.
And Python started out building a core OOP language with a script heart and syntax that was miles from it's closest rational starting point (Java).
Which language would you recommend we start from? To make it work well would require some nasty bolting-on in some languages.
The reason so many languages have become popular and why Ruby hasn't is one simple koan. "It must have a compelling reason to change."
Perls 1-4 had it (better, faster, cleaner shell scripting that was shell independent, regex). Perl 5 had it (oop and better code reuse, mush improved data model for an (by then) old standard. Python had it (clean pre-planned syntax, clean oop, death to braces). Scheme had it (throw out the old, revamp the syntax, speed up the core). C++ had it way back when (oop). Java had it (c++ ish with scriptability thanks to garbage collection, bytecode model). Javascript had it (ran in browser, simple syntax a "web programmer" could use and a real programmer didn't start crying [too much] over.) TCL had it (tk hookup, meta shell system, shell-ish syntax). Bash had it (un-borked sh, added kitchen sink).
What does Ruby really offer as a compelling reason to change? Honestly. Just a "better" perlish syntax and newer oop? Is that compelling enough? Better international support? Compelling for the Japanese users sure but for the english-speaking coders is that useful or a hinderance?
(Note the .sig, I might be _bit_ biased. =)
--
$you = new YOU;
$you = new YOU;
honk() if $you->love(perl)
It's not an excuse, I think it's more a case that if you are familiar enough with any language, the incentive to change must be pretty large to make it worthwhile.
:)
For example, I only learnt Perl originally because I had a problem I was originally using AWK for, but fell off the end of what AWK would do (filehandling in my case).
I've looked at Python on and off for a couple of years, and for most things I do, I find that doing them in Perl would be easier (for me, as a Perl user), and not worth the additional learning-curve time of Python. For larger projects, one of these days, I'll have another go
--
the telephone rings / problem between screen and chair / thoughts of homocide
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
Check out this link for what might be some interesting benchmarks. Ruby seems to do quite well against Perl and Python (and in some cases better), but in other cases it is downright awful (look at the recursion problems). Ruby is not as mature as Perl or Python, so there are definitely some places where it could be optimized better.
One thing you may want to consider is that Ruby has many different ways of doing loops; some of them open a new scope (which takes time), and others just iterate in the current scope. So where you may have:
1..1000000.each do |i|
j = j + 1
end
You may want to rewrite as:
for i in 1..1000000 do
j = j + 1
end
or even:
1000000.times do
j = j.succ # faster than j = j + 1
end
An Anonymous Coward writes:
In Perl, "missing data" normally generates "Use of uninitialized value" warnings. You are using -w, right?
Yes, I use -w, and even "use strict" but that doesn't stop me from using
my ($a, $b, $c) = split("\t", $_);
on tab-delimited data. If one of the fields is not there no warning will be issued (and that's the way I like it)
I'm not familiar with Ruby, but it sounds like Ruby's "nil" is equivalent to Perl's "undef" and C/Java/etc's "null", which is generally considered a good thing as it catches many logic errors before they can do more serious harm.
Of course, at some point you have to admit that a scripting language that is as strict as a compiled language is pretty useless (because then, why not write in the compiled language?). Of course, where that point lies is a matter for debate.
That's like saying "why complicate things with another means of transportation when we already have horses, feet, dogsleds, etc. etc.?"
Bad analogy. There is real progress in transportation -- new methods are cheaper, faster, etc. There is no real progress in programming languages. All of them (sans a few mini-languages) are Turing complete and so are objectively exactly the same. Everything else is merely a matter of taste. Quite a few engineers and natural scientists still use FORTRAN, after all.
You seem to think that functional languages are somehow more "advanced" than procedural languages. There is no objective reason to support this conclusion -- it is like saying chocolate ice cream is more advanced than strawberry
On the other hand, I have to admit that I'm a sucker for new languages myself. I *know* that new languages can't really make me more productive, but they sure are fun.
I have been fiddling around with Ruby and while I think that it is much cleaner than Perl and even Python, I am still mostly using Perl. One of the reasons is the relatively uninteresting reason that other people I work with use Perl, but some have to do with annoyances of Ruby:
.to_i, etc., but it is too easy to forget to use them when needed.
1) In Ruby, strings and Numbers both use < and > for comparison. Why is this bad? Isn't it cleaner to do this rather than bother with Perl's "le" and "ge" for strings and <, >, for numbers? Yes, but: In Ruby there is no autoconversion like in perl. If I use "split" to generate an array of fields from a columned list of numbers, those numbers will not be numbers, but strings. This means they will be compared as strings, screwing up numerical order. Bad, Bad, Bad, Bad! Yes, I *know* Ruby has
2) nil is not equal to zero. This means in data with variable numbers of fields, you have to write code that handles this case -- it isn't like Perl where missing data is treated as 0 or "" depending on the context. Yes, maybe Ruby's way is cleaner, but it is annoying in practice.
You just defined the class chair. It wasn't an existing type. Nobody is claining that Puthon doesn't allow inheritance of user classes.
For example, why doesn't all business application development get done in COBOL, or FORTRAN, or C, or C++? Because newer languages are more productive
Certainly not all code is written in those four languages, but the majority of business applications *are* written in one of them. Functional languages have comparatively little support outside academia, and even there they are fading somewhat because their typical use, symbolic AI, is no longer the "hot" area of CS.
There are plenty of objective reasons, but they probably go beyond the scope of a
There is a reason why arguments about editors and programming languages are termed "religious wars". Any such "proof" of the superiority of one language over another can be easily denied by the supporters of another language exactly in the manner of religious arguments.
As another poster mentioned, Unlambda and Intercal are also Turing complete, and their existence alone effectively disproves your argument.
Oh, hardly. Those joke languages are hard only because they are so *different* from what we are used to. To give an analogy from human languages, I can say Chinese is hard because it has all those tones, and Chinese speakers can say English is hard because it has all those verb tenses. It's all about what you are used to.
The question is how long it will take, and how much effort you will have to expend to get there. Advances in programming languages are quite closely analogous.
Not really. Someone writing in a language that they like and know well is more productive than someone writing in a language they hate or don't know well. To bring this back to the topic of the article, which scripting language is best? It's all subjective. I hate tcl, for example, but some people love it.
How do you know this? And which languages do you know? If you've never experienced the productivity differences between different languages, you can't be familiar with much of a variety of them.
I know from experience, and I know quite a few, languages having programmed since 1981. let's see:
Basic, Pascal, C, C++, Java, Forth, Actor, Perl, Python, Ruby, tcl, awk, Smalltalk-80, Emacs Lisp, ML, Eiffel
What I have found however, is that different *implementations* of languages can provide quite a productivity difference. For example, some FORTHs have quite a few words defined, and others have only the basics. But that isn't a function of the language itself.
mod_ruby has been around for a while, and last I looked there were several templating systems.
Got time? Spend some of it coding or testing
> Just substitute RUBY with LINUX, and language with operating system.
Ballocks. Linux is Unix, or close enough that I could find my way around it on the first day after using Solaris after a year. Unix software has been around for eons compared to most equivalent windows solutions, not to mention the OS itself. There's expect scripts still running that are older than NT. Linux was hardly an odd shape that required a new hole to be carved for it.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
> What I think is missing is a good scripting language implementation that takes full advantage of C++.
:)
Take a look at ColdStore sometime. It's an interesting approach to designing languages, and IMHO a better one: writing the runtime environment first, then targeting several languages to the environment, including existing ones like OpenC++ (C++ with a meta-object protocol) and Python (as a module), and new ones like Chaos (a "toy" RPN language that's a cross between forth and tcl) and freon (a "real" language deriving from C++ and smalltalk). It supports orthogonal object persistence (the "store" in coldstore, which lets you stop the program, start it again, all your objects are there like you never stopped, no need to explicitly save and load), and an introspective interpreter able to modify the parse tree at runtime (lets you have "interesting" control structures, MOP, intentional programming, etc). Since it is knowledgeable about the C++ ABI (gcc's ABI anyway) from object layout to symbol mangling, it should be able to script arbitrary C++ classes as well. And since the persistent store can be dlopened as an ordinary C++ shared library, other applications can make easily use of it.
It's still a work in progress, but the persistence does already work with OpenC++ and Python, and the way it implements it makes it super fast compared to any other persistence scheme currently in existence. It's shaping up to be an awesome language runtime too, and of course it's written in C++
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
The easiest answer is: Because it's not Perl.
The second easiest answer is: Because it's not what I'm using now.
Seriously, Ruby has some nice features, but most of them are 100% sugar and *really* weird to someone who expects it to be "perl, only clean and logical"...
I'll stick with my dirty Perl, thank you.
-- To dream a dream is grand, but to live it is divine. -- Leto ][
Good point. I'd like to add that the reason I currently use Perl and not Python (or Ruby) is similar to (one of) the reason(s) I use Vi and not Emacs - Vi or a clone is available on most every platform, and is a quick download if it's not. Emacs isn't. Perl is available on most everything I use [as a sysadmin in a mixed Linux/Win32/Mac environment]. Therefore, when choosing a language/editor to get proficient at, I choose the language that will give me the most bang for my buck. Perl does darn near everything I need easily, and is far and away the easiest way for me to write apps that will run on *nix, Win32, and MacOS with no changes (Java doesn't count, because I really dislike it ;)).
That said, as soon as I find a problem that Ruby looks better suited for than Perl (I'm looking), I'll take the time to learn it. Being really good at something is good, but flexibility is a good thing too... :) Is Ruby available for Win32 and/or MacOS?
Huh????? Ruby is exactly as strict as Python is.
I do not agree. Ruby implements TMTOWTDI, which Python generally doesn't. Perhaps I expressed myself unclearly, so that you interpreted me as meaning loose as in e.g. "loosely typed". I was reffering to syntax.
Let me explain.
Say I want to do something if a certain boolean variable is false. In Python, I do that in this way:
if not var:
dosomething
In Ruby I can select one of four different syntaxes:
if not var
dosomething
end
unless var
dosomething
end
dosomething if not var
dosomething unless var
These four different syntaxes perform exactly the same thing, but uses different keywords in different orders. That is the TMTOWTDI idea, and it makes Ruby a lot "looser" than Python, syntax-wise.
I'm sure Ruby is better than Perl. But 1st I don't have time to learn another language which isn't "different" enough. And 2nd I don't know what to do with another language. Can't use it at work, because no one else knows Ruby. And can't use it for me and my friends and people I know. They would have to install Ruby and all the cool libraries for it.
No, these things, for all practical purposes, can't be fixed "when the time comes." The time came and went. If you're going to create some classes that are going to be reused by lots of other people, you can't go making all your methods take a StringValue rather than a String. Nobody will ever use that. (Especially when they're also confronted with another package that takes ImmutableString as parameters, and a third that takes....well, you get the idea.) You instead take the expedient, inefficent route of cloning every String parameter you get.
The world's most portable OS: http://www.netbsd.org.
In theory, languages are not libraries. In practice, I'm sorry, they are. How many people do you know using Java that don't use the classes in java.lang and java.util? Would you do that? It's even been pointed out here time and time again: one of the huge advantages of perl is the massive number of modules out there to do the work for you. People use perl for just that reason. Anyway, I think I can put an end to the argument this way: given basically one language change (the 'char' primitive data type holds a Unicode character), and all the library changes I asked for, yes, I'd be far, far more inclined to use Ruby. So I'll just sit tight now until someone presents me with that version to compile up and run on my system, and shows me that lots of modules for that version of Ruby are becoming available, so I don't have to write much stuff from scratch....
The world's most portable OS: http://www.netbsd.org.
1. Python supports HTTPS natively. Brian Gallew contributed OpenSSL support for the socket module in Python 2.0. At the same time the httplib and urlllib modules were modified to support https URLs.
2. tk if you use cPython, swing if you use jython.
3. use the right tool for the right job.
4. see #2.
5. This doesn't make sense to me. A stack is something you can push and pop. What other operations do you want? Pushing and popping IS a real stack.
I rather like Ruby. And I don't like Python's use of whitespace.
OTOH:
1) I don't read Japanese, so many of the extensions aren't useable.
2) Like Python and Java, it's slow. (What do you expect of an interpreter?)
3) I like to use IDE's. I like to use Linux. But the only IDE that I know of for Ruby is win32 only.
OTOH:
1) It's crossplatform to every platform I use.
2) It's supposed to be easy to link to c (I haven't tried yet).
3) It's got an free source license. Python has one for 2.0a, and the next release should have one...but 2.1 doesn't, quite. Forget java here, except for gcj, and a few other independant Java clones. (And I'm going to wait until gcc 3 comes with the distribution before I install it. Too many problems otherwise.)
The upshot is: Sometimes I use Ruby. I like it, but I haven't used it enough to really learn it.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Free is subject to many definitions. My favorite is GPL compliant. 2.1a or 2.1.1 will be. 2.0.1 is. Please check the Python website.
This doesn't matter much any more, but the UCITA in combination with Python's current "Laws of Virginia" clause have caused me to refrain from using it recently. Which is one of the reasons that I checked out Ruby.
I will agree that the license is, barring the "Virginia" clause, an excellent one. But Virginia is a UCITA state, and until I feel clear about what the UCITA can and cannot do, then I will avoid agreements that invoke it.
So far, the only good thing I heard attributed to the UCITA is that it breaks the MS license. And that's the Maryland version. And there have been some rather scary potential interpretations of pieces of it. I'll wait until various courts have their say. And until they have, I'll just avoid it.
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
Change aversion compounds on itself. People avoid new things that replace their old things, because they fear change. The more they do this, the more risky and costly it is to change. The fear grows. Why else would such a large percentage of desktops be running Windows when MacOS, BeOS, Linux, *BSD, etc. have been around to provide something that is in many cases much better?
To quote from your post:
"I say Object Oriented Programming is highly overrated."
If it's "not just procedural and OO", then why are you saying OOP is highly overrated? That implies that procedural programming is not overrated, and thus better than OOP.
This may not be what you meant to say, but that's how it sounds.
A Government Is a Body of People, Usually Notably Ungoverned
We tend to switch languages not because something is 'better' in some way.. there will *always* be some new language that is 'better' than the previous one. We switch through necessity.
Example: People started using perl because it was better and more convenient than sed/awk/shell. Then came the internet, and cgi-scripts... perl just happened to fit in there nicely. Other developments followed as it gained in popularity, and now it's used for tons of stuff. Lots of work has been put into speeding it up; embedding it into web servers for faster execution of code. Lots of supporting work and material out there. CPAN. Etc....
Then Python. Python is unique enough to warrant a good following; OSS, elegance, nice OO language. Doesn't stop people from using perl though, although some people switched because they like OO better.
Now Ruby. What cna I say about Ruby? I don't know much about it.. but does it offer an order of magnitude more flexibility than perl and/or python currently offers? I doubt it. Sure, it may be nicer, more elegant.. but perl and python are rather elegant at doing what they do.
Irrational prejudice against (or for) "hacker" versus "corporate" things is silly - but preferring familiar, well-known, well-documented, easily-supported tools over more avant-garde or experimental things, where reliability and uptime and long-term persistence is important is not silly.
That's the same argument that works for open-source tools in the long run - while they don't always look as safe as their closed-source competitors in their early years, as they get more mature and a userbase develops, they become safer - e.g., Commodore can kill off the Amiga, IBM can stop making OS/2, and Microsoft can stop selling MS-DOS, but nobody can kill Linux or Perl, because there's such a big installed base that they'll be user-supported for the next 20 or 30 years, no matter what happens.
Ruby is being used as an optional extension language for Vim 6. Much of the documentation of Ruby is just now being translated to English. Python lacks true closures, whereas Ruby does not. Love it or hate it, Ruby has operator overloading. In the case for "scripting" languages, this seems useful. Ruby is faster than Python. Ruby is not statically typed.
-Gwizdak.
Often? No. Recomputed instance variables like that are *vastly* outnumbered by instance variables that are simply read and written, by one or two orders of magnitude. Why optimize for the extremely rare case? The same effect can be had with explicit accessors, which also give a clear signal to the programmer that there might be side effects and don't double your stack size by filling the stack with accessor frames (yes, it matters in some environments). A convenient notation for accessor functions would be nice for when they are appropriate, but making them the default is just a mistake.
Any non-trivial accessor function might have side effects, including not just obvious side effects such as modification of a global but also delays (causing timeouts elsewhere in the code) or locking errors. Such problems, "hidden" in what the programmer might think is a simple variable access, can be a pain to debug. Besides that, there's always some idiot who thinks it's clever to override an accessor in a way that's incompatible with the original class designer's intent - leading to even "spookier" kinds of errors. Accessor functions have their uses, but using them safely requires more care than I give the average programmer credit for. Again, they should be available but not the default.
Slashdot - News for Herds. Stuff that Splatters.
For me, a good scripting language must have three features:
As it turns out, Perl and Tcl both fail with regard to #1 and #3, so I use Python. Ruby seems fully competitive to Python with regard to #1 and #2; sure, I find the use of variable punctuation to indicate scope abominable, but a lot of people loathe Python's use of indentation to indicate program structure, so I'm happy to call the race even.
That leaves #3 as the most important aspect distinguishing Ruby from Python. Does anyone know of a good description of Ruby's extension interface, or perhaps a good example of an extension module? I've become pretty comfortable with Python's extension interface, but there's some room for improvement. If Ruby's extension interface is cleaner and/or more powerful than Python's, then I might actually consider it as an alternative for my next project. Probably not, because it seems highly unlikely that Ruby's extension interface is *so* superior to Python's that it justifies the time investment and short-term loss of productivity that switching would inevitably require. The key point though, is not about what *I* as an established Python user might do. What's more important is how I should answer the next time *someone else* asks me which language to learn or use. If Ruby can meet this standard, my recommendation might well be to go with Ruby (even as I continue to use Python myself).
Slashdot - News for Herds. Stuff that Splatters.
Why even spend the 2 days for something I don't need? (And really, there's no way the total cost of adopting a new programming technology could ever be 2 days.)
As for not having a clue, here's my clue: I don't need a new programming technology. That's enough of a clue to decide not to go chasing after promises of new programming technologies. Good enough for me. Is it good enough for you? (Who cares.)
While it is true that UTC is not GMT, they are close enough to each other for nearly all practical purposes in a programming context. If you are handling astronomical or navigational data, you will care about the differences, but otherwise, probably not.
:)
I should also note that there are two UTC definitions. These days, when we say UTC, we usually mean UTC2, which is based on atomic clocks. Both GMT and UTC(1) are based on astronomical observations, with UTC(1) compensating for some local variations. Generally speaking, the differences ammount to not more than a few seconds.
Time zones are civil structures, where UTC/GMT times are really observations. Thus, time zone handling can be nearly irrational (after all, civil law makers were involved). In this context, using the observable time for all internal comparisons/storage/calculations makes a great deal of sense. This relegates time zones to input/output, which makes almost everything much simpler. You just need to remember that the hours value in the object is probably UTC, with the zone retained only for convenience.
Having said that, I'll note that the usual abbreviations for time zones are not unique, world wide, with some 3-letter abbreviations being used for several zones that are widely separated geographically. An additional complication comes from the various rules for going to/from daylight savings times.
If you were not already convinced, UTC is far simpler to use and stay sane with, and that is totally independent of your language of choice.
have a nice day
I think as long as it's use is based on it's usefullness (which has been the case with most scripting languages), it's only a matter of time.
Ruby has been as much of a pleasent surprise to me as Perl was back when I first learned it. No, it's not "Perl with Objects"; Perl itself does that quite well. It's more like Smalltalk, only readable, pragmatic rather than idealistic, and as expressive and concise as Perl when you want it to be. Personally, i think Ruby is a much greater threat to Perl than Python is, in the long run. Rather than forcing you to do it Guido's Way, you can do it the Perl Way, or the Smalltalk Way, or the Functional Way... or any combination of the above. No wonder the Pragmatic Programmers wrote a book on it. It does TMTOWTDI better than Perl does TMTOWTDI; while remaining relatively simple and clean.
So just give it time. I think it's well on it's way to world domination.
Oh, and as for a CPAN-like code archive for Ruby, there's a somewhat embrionic one here. There is discussion currently going on at the RubyWiki on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.
--
--
CPAN rules. - Guido van Rossum
Java takes up incredible amounts of RAM on my box, even accounting for shared memory. And why do we need another virtual machine language? Wasn't Icon first? True, Icon wasn't much like C, but C handles almost everything, and what it is poor for C, Perl or PHP will cover well.
These new languages like Ruby and Python don't seem to add anything to the realm of existing ideas. Maybe mix and match them in better ways, but nothing particularly innovative. (Feel free to contradict me through example!) I've always found Icon interesting though, since functions can return more than one value (called "generators") which is great for avoiding the messes of raw link-list programming etc.
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
I think that a lot of people feel a bit nervous to start a big programming project that will go through all the stages of development, right through to maintainance for two to five years, when the language used is not standardised.
You simply can't afford to let the language and the supporting libraries change too much when developing for the future. Using a language whos "version number" changes faster than Walt Disney's web site counter is simply not acceptable.
That's why C, C++ and Fortran are still so popular -- they haven't changed too much over the years. There's a new Fortran standard being released every four years, but if it was more frequently, people would stop using the language since they simply wouldn't trust the structure of the language to be stable.
Sure, yet another scripting language with all the bells and whistles is great fun and may be suitable for getting the small things done (small things == no real need for OOP), it's no use trying to deny that, but do you really want to put too much money into a project based on ad hoc standards?
It's 11pm, do you know what your deamons are up to?
New languages like Ruby usually require the programmer to reinvent libraries that have already been developed, tested, revised, retested, etc. in other languages.
In languages like Perl, Java and other really popular languages more than likely someone has already done what you want and you can build off of that. In Ruby, you may find yourself starting from less of a developed base than in other languages.
The good news is that people who want to make a name for themselves in the open source world can jump into the Ruby world and do some good work. Once a well-tested comprehensive base of library code is available then the language will develop some momentum (my opinion).
Also, how many books are there for Ruby...ONE, right? That's not enough to attract attention at a bookstore. It also makes it more difficult for people to learn.
I "played" with Ruby under Windows and have the so-called Pick-axe book and found the language nice but in terms of usage now: how many hosting services allow server side scripting with Ruby? For simple utilities my Perl skills are better than my Ruby skills so I don't change since I want to get tools done fast.
So, my opinion is that Ruby isn't "popular" simply because it needs more time to be accessible to more people and not because of technical reasons.
I should also mention that an overview of Ruby syntax, for those interested, can be found at Dr. Dobb's Journal.
Let's say I want to iterate over a list in Python. I'd "map(a_function, a_list)". "map" applies a_function to each element of a_list, creating a new list as it goes along. It doesn't entail side effects; the original list isn't modified. You'll find a function similar to this in nearly every language; any implementation of lists in any language should provide such a facility (and Ruby provides that facility via its iterators.)
I prefer the Python/Lisp/O'Caml way. I, like more intelligent people who have gone before me, see iterators in object-oriented languages as a sign of weakness. Ruby's iterators exist to work around the fact that functions aren't first class objects in Ruby. They exist because a programmer can't write higher order functions in Ruby.
As beautiful as "pure" languages like Java and Haskell and Ruby are, they'll always lose in practice to languages that implement multiple programming paradigms well, like O'Caml, and Lisp, and Python. Programmers don't need to be contrained by their language, restricted to programming in a particular way or paradigm because that's the way the author/designer of the language decided it should be. In O'Caml or Python or Lisp, they're not. In Ruby, iterators are a perfect example of how they are.
Jeremy
--
Looking for a Python IRC bot?
Pop pops an element anywhere in the list. Not just at the end, as the Perl version does. You can use .append and .pop to treat a list like a stack very easily. Complaining because .append isn't also called .push seems remarkably petty to me.
Perhaps "overloaded" is defined differently in your dictionary, but whitespace has one purpose in Python: as a delimiter, for blocks and for tokens. Indent your code as a good coder would indent his code (note: I didn't say how you would indent your code, I don't know what your Perl code looks like :)) and you'll experience absolutely no difficulties writing your own code or reading others'. And believe me, when you leave the Perl world and learn that code can actually be read by someone other than he who wrote it, you'll be astounded.
Please, explain how this is so. I'm curious.
Do you prefer proof, or unsupported assertions? Me, personally, I'm a big fan of proof, but I'm having some trouble finding it in your posts. Maybe you can enlighten me.
I found the assertion, but again, I couldn't find the proof. Perhaps you can provide some.
Stackless provides continuations. Their utility is questionable, at best -- there's a reason Scheme includes it, but Common Lisp doesn't -- Standard ML includes it, but O'Caml doesn't. The argument has raged a long time on both sides, with no signs of letting up.
I'd like to see them in the language, but not if it costs the simplicity of the language. It's definitely not something that is required for Python to be "truly unique and kickass" -- it already is.
Jeremy
--
Looking for a Python IRC bot?
I think the fact that you find Ruby's iterating style strange is because you didn't understand it. I know I didn't get it when I first looked at it. For example, what you'd do in Java with something like: Iterator i = myList.iterator() while (i.hasNext()) { SomeObject a = (SomeObject) i.next(); //some stuff on a...
}
you'd do in Ruby like this:
myList.each { |a|
#some stuff on a...
}
What's happening is that the stuff in the curly braces gets turned into a Proc object (Oh, by the way, instead of just making functions objects, Ruby lets you turn blocks of code into objects which retain their context.) which gets passed to the each function, which in turn assigns each element of the list to a and executes the Proc.
I have no idea how you'd do that in Python... (which certainly isn't to say that you can't...)
No, I don't mean that the argument is old (though it is), but that this post smells of a template with filled-in blanks.
Anyway, since I'm here, let me bait.
Bosses of bosses don't care about which language or operating systems or other technical mantra you are using, as long as it works. When it doesn't, well, then _YOU_ are in deep sh*t, not them.
And technical managers worthing their wage know that in today world either you innovate or you die. And today Very High Level Languages (like Ruby, Perl and Python) gives to software development companies so many advantages than you cannot ignore them and hope to be around tomorrow.
Ciao
----
FB
However, it does a number of new things which I don't think could have been included in either Python and Perl interprters (wrt to Python: Full garbage collection, everithing is an object approach (including built-in types), and more
That is why a new language. And if a community forms around it, it means that maybe it was needed.
Ciao
----
FB
In the Church-Turing sense, we only need one programming language (or processor, for that matter), but practically speaking it would make programming hell. The question is when do we reach the point of diminishing returns in writing yet another scripting/prototyping language, and how do we know? I personally would just as soon people experiment, until such time as we can prove a language optimal for a class of problems.
CPAN.
That's the draw of perl for rapid application development using reusable (well-tested) code. It's awesome.
--
-- @rjamestaylor on Ello
I must admit, one of the things I do like about Ruby is it's sensical enumeration/iteration, which really borrows from Smalltalk. C++ and Java with their Iterators, Perl with foreach, Python with for x in... - they all just seem so messy compared to the Smalltalk and Ruby way of doing things.
:object | object someMethod ].
:object | object hash ].
:= #(1 2 3 4 5 6 7 8 9 10). "array literal"
:num | num > 5].
:= #($a $b $C $d $O). "array of characters"
:aChar | aChar isLowercase].
Your example in Smalltalk:
myList do: [
It doesn't end there. Smalltalk's Collection classes have a bunch of really cool methods that do various kinds of iteration.
"returns a new collection with the results of sending the #hash message (or in the parlance of other languages, calling a method) to each of the objects in myList."
myList collect: [
"returns all objects that are greater than 5. this can be used for anything, not just numbers. returns a collection with all objects that respond with true."
| anArray | "declare a temp. variable"
anArray
anArray select: [
"returns a collection with uppercase characters"
| anArray |
anArray
anArray reject: [
There are a bunch more, but I would say those are the most common. It just makes for a really clean way to deal with all sorts of collections, and I'm glad to see that Ruby adopted this way (roughly), and didn't stick with the archaic ways found in Perl, Python, C++, and Java.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Iterators ala C++ and Java are not an inherent weakness of OO language, simply of languages that use them. Smalltalk, the original, fully OO language has nothing like Java/C++ implementors. I don't think you understand the way Ruby interates/enumerates, as it also doesn't have iterators like Java/C++. Things between begin and end in Ruby are first class closures, IIRC.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
A necessary part (as stated by Alan Kay) of OO is that it must support inheritence, or else it's not truly OO. While you may not yourself think it important, it is a vital part of OO.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
You got it almost right. Simula is missing OO features that are found in Smalltalk. One is, Simula lacks class variables. Relatively minor, and a missing feature in a lot of so-called OO languages.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I've had a look at F-Script, mostly because it is a Smalltalk-like language that has is closely tied with Cocoa, can interact with Objective-C objects with no problem, and thus has a AppKit binding with Mac OS X. If you have a look at the Array class (in the Users Classes section of the F-Script manual), you'll see the \ method is basically a somewhat-more-sense-making #inject:into: method.
:subTotal :next | subTotal + next].
The F-Script example:
{1,2,3,4,5} \ #+
is executed as if it were 1+2+3+4+5 and returns 15.
In Smalltalk:
#(1 2 3 4 5) inject: 0 into: [
F-Script is pretty interesting, and looks like a promising alternative to Objective-C, C, and C++ for Mac developers.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
If you like Haskell, but want a mission critical ready implementation you will have to try a slightly different functional language called Clean, which has everything Haskell has as far as purity, expressiveness, elegance, rock-solid static type checking (most important feature IMO), lazy evaluation, and Clean has more like Linear (Uniqueness) Types ala Girard's Linear Logic, which allow you to have greater control over system resources, yet still maintaining functional purity and expressiveness.
GUI Spreasheet programs have been written in Clean. Video Games have been written in Clean, and even Clean's GUI integrated development environment and compiler are written in clean. There is only one problem with Clean... it is proprietary, but don't let that detract you for playing around with it for non-profit use.
Check out Clean here. You only have to pay money for the compiler if you want to use it for commercial purposes. I started out learning Functional Programming with Haskell, which is a favorite language of mine, but I ended up seeing the brilliance of Clean as a language that has the beauty of Haskell yet can still "get things done".
Imperative and functional languages can easily be directly compared to eachother, and it has been argued time and time again that imperative languages lack the type checking features available in modern functional languages. Imperative languages also fall short when you want to formally verify aspects of your code. Functional languages have wonderful easy to use algebraic properties that lend to easy verification compared to imperative programs which lack referential transparency. I think that I even remember the father of imperative languages saying at a key speech of his, that functional programming was the right way to go and that imperative programming was the wrong path.
However, it is my theory that the newer mobile calculi such as the pi-calculus and ambient-calculus will lead to a canonical generalization of all of the various paradigms, from imperative to object to functional to logic. Once that generalization is found, there will be one language for all jobs.
I still hold that FP and Procedural Programming can be compared directly, and many have done so over the past decades. Both languages are used to describe the same thing, so they aren't as different as apples and oranges. Anyway, FP nor PP will be the wave of the future. Read below...
Recent research in Linear Logic and Mobile calculi show the possibility of a programming language that is simple and elegant yet is a generalization of functional, imperative, and object-oriented programming languages. Mozart-Oz is kind of a hack compared to the more recent stuff (but still very interesting). Check it out here! The site has info on free mobile languages (don't think they are all ultra-complex like Mozart-Oz).
I first discovered Ruby about 1 1/2 year ago, and was greatly impressed. The language combines most of the good qualities of both Perl (ability to write compact code, TMTOWTDI, useful one-liners, etc) and Python (readability, orthogonality, actual language design and not just evolution), and adds a few other goodies from Smalltalk (code-blocks, garbage collection, etc).
But my immediate reaction was also: Why do we need yet another scripting language? We already have Perl, Python and Tcl, which together should fill most niches people have for scripting in the Unix world. And the few people who aren't happy with e.g. reference counting, but want something academically pleasing would probably not look for a "practical" scripting language, but go with something like Scheme, Haskell or other "clean" languages. (I know, as I've been using SML for scripting purposes myself, simply because SML was the programming language I worked in mostly at the time).
The timing of Ruby's arrival couldn't be much worse. Back in the days of only Perl and Tcl, many people (including myself) were looking for something cleaner. After Python arrived, this niche was mostly filled, and the few people who wasn't at least 80% happy with one of the three scripting languages doesn't make up enough people to really make a difference. Besides, Ruby had all the disadvantages of a newcomer, immaturity (I notices some serious GC performance problems when I tested it on some toy problems in mathematics), incomplete documentation, few users, and so on.
So who would the Ruby user be? To be true, I wouldn't want to convince my company to use Ruby. Ruby is still immature, underdocumented, and it still haven't found it's niche market. For problems suitable to Perl, I use Perl, not Ruby. Why? Because code has to be maintained later (hopefully not by me), and because we don't want to install third party software everywhere to suit every developers whim.
Unless you can point me to a task where Ruby is really much better than all of Perl, Python and Tcl, then I will not adopt it. It is too much of a hassle for me, compared to the tiny benefits it might have if I took the time to learn it properly enough for me to be as effective in Perl.
In summary, the enthusiasm over Ruby is not bad. It is a great language, and certainly better than Python, Ruby or Tcl when it comes to language design, although most likely not implementation (unless something drastically happened while I were away). But the benefits of using it is simply not great enough for all the disadvantages in learning yet another scripting language and supporting it where we need to use it.
Besides, I doubt more shit means better jobs. A good job is somewhere where you can simply do your thing, and get paid for it, not somewhere where you will have to incorporate every buzzword in a project description to be able to get something done (even if you get paid more). Let's face it, new doesn't mean better. For what it does, Fortran is a great language. It lets you get things done.
And if you really believe open source will magically give you faster development, then you really need a reality check. While it might be true of some specific projects, it is certainly not a universal truth. Put 3-5 fulltime developers on a project, or 100 student hobbyists and watch who can keep up with deadlines. Open source certainly has some benefits (especially for the customer), but it is certainly not a silber bullet.
as I write this, modded up two, and down two.
A good sign you have written a valuable and thought provoking post. Too bad there's no way to elevate a post that generates a lot of modding that leaves it about even with where it started as these are often the most worth actually reading and responding to.
KFG
I'm not a Ruby advocate, but your post illustrates issues which are common to nearly all of the /. posts on programming language issues.
Another thing I often see on /. is people praising language X because it has an IDE, or a debugger, or a profiler, or fast garbage collection, or good error messages, or dynamic linking, or an interactive interpreter or a fast compiler. These are properties of the language implementation, not the language itself, and thus say nothing of interest about the quality of the language design.
Lastly, if you choose one language over another solely on the basis of surface issues such as the size of its available libraries, its syntax or the quality of its implementation, then that suggests that there really is not much difference between the two.
The only solid criterion I know for comparing languages which does not revolve around holy issues (e.g., static vs. dynamic typing) is locality. Language X is better than language Y with respect to feature F if in X you can use F to write code localized to one part of the program, which in Y you would be forced to spread globally all over the program to get the same effect. Features which satisfy this criterion are things like objects, higher-order functions, first-class continuations, logical constraint variables, etc. It can be shown that, thanks to such a feature F, programs of language X may be exponentially smaller than programs of language Y. Features which don't satisfy this criterion will lead at wost to linear size differences in the lengths of programs, and can thus be adequately addressed by macro-processing. (Not that I advocate macros...)
BH
BH
Fools! They laughed at me at the Sorbonne...!
Anyway, by your definition, ANSI C supports operator overloading since you could write a couple of "int MultiplyInt(int, int);" etc. etc. functions.
Generally, "operator overloading" means overloading the specific character(s) that make up the operator. By my (and I think the general) definition, C++ allows operator overloading, C (any, by your description, Python) doesn't.
Anyway, I like Ruby even though I'm just learning it now. I think the reason I like it better than any other language I've dealt with recently is that, since it's new, many people are learning it together. The people I've asked for help are friendly and helpful.
Try going to comp.c.plus.plus.moderated and enter a snippet of code that starts "void main(void) {". Half the people there will act like you pissed on their mom no matter what your question is... It doesn't affect me -- I'm past that level of C++ coding -- but it bothers me that so much mental bandwidth is wasted.
Waltz, nymph, for quick jigs vex Bud.
If anybody who's read Programming Ruby would like to review it on The Assayer, it would be greatly appreciated. Review it here.
The Assayer - free-information book reviews
Find free books.
It is an ultra cool geek language. You can program and see results immediately. The syntax is ultra-clean. It's WORA. And the whole system is under an extremely liberal license.
It's almost perfect, but there are drawbacks to it.Python is missing:
Native HTTPS support.
Good widget set (small, portable, and simple - preferably built in too).
Native compiler (bytecode is great...but for some things it's too slow. Gimme a binary).
Powerful graphics primitives.
Easier stack manipulation (hacked pushing and popping isn't a real stack, guys)
Some of these shortcomings are present in other languages, like REBOL and Java, and of course the incredible Squeak (add your own primitives and customize the entire VM in a subset of the language itself)!
But overall, Python is still my favourite language, and I know a few (Squeak/Smalltalk, C, tons of Basic variants, Java, Shell, and a bit of Perl)....but it WOULD be nice if the Python team addressed the concerns above.
"A few atoms won't even light a match" - Dr Jones, 1933
I would have to agree. With what you have said. I think I may be a little different though I love to learn new languages and I tend to use the best language for the job not what I learned first. Except for the whole english thing I always use english even though it may not be the best. But I mean how many programmers really talk to people if it was not for slashdot we would not need english damn you slashdot :-)
-- Tyler >+++++++[-]++++.---------.+.++++.++.
What I said was modified slightly. Here are some things you may want to know. I have been programming perl for many years and it is great. I have just been looking at Ruby lately and it has some great features. All of you that say OOP is bad have you used smalltalk or ruby? The way they handle it is great. In my opinion(remeber my opinion) OOP in java, c++, python is kind of clumsy and with perl I think creating classes is clumsy but I think using them is pretty slick. I think that OOP is handled pretty good in Ruby it is there but is not got the hack feel that say IMO java does. Mind you these are all good languages and have there place. I believe that every language has its place. And like mentioned before the more you learn and the more views you view programming from the better you will be. Also so you know I am a language whore I learn all that I can so I tend to play with a langauge before most people may even have heard of it. Now back to Ruby here is a link that has a great list of some of the coolest features of ruby. http://www.hypermetrics.com/ruby37.html
I know some say not another f*cking langauge. Well what I have to say to that is I am sure all people were saying that about C. They were probably like man what the hell is wrong with asm C is soooo slow. But now C is one of the top lanauges used today.
As you can tell I have a habit of just rambling on and not orginizing what I am saying oh well this is all just my 2 cents.
-- Tyler >+++++++[-]++++.---------.+.++++.++.
Um, no.
Speaking as a guy whose done a little maintenance programming, developers really need to at least try to make the rest of the software's life cycle tolerable. A company should attempt to restrict itself to as few technologies as are necessary both for its budget and for the sanity of the IT/programming staff.
Secondly, not all programming languages are the same. Some are radically different lisp . When I first looked at LISP and scheme it looked like gibberish. Now it looks like very clever gibberish. At any rate its not easy to transfer to an entirely different programming style.
Sure a good programmer ought to be able to learn a new language at an intermediate level in a month or two, but what if you've got to work with 15 different languages and you only know 8?
Finally, even if good programmer's could pick up languages quickly in a day and if it were worth their time to do so... we come across the problem that not everyone out there is a good programmer. A good programmer knows that and codes appropriately.
Another big argument for Ruby over Python used to be that Ruby was GPL but since there is a GPL Python this really does not stand, as well Perl is not GPL, so not much water there.
A couple of details: Pyton is not GPL, but it is available under a license which is GPL compatable, and certainly in any event good enough to satisfy the definitions of both Open Source and Free Software. Perl is (if memory serves) dual licensed, and one of the two license is in fact the GPL.
-Rob
PHP is good for the web, Perl is unbeatable as text processing language.
What is Ruby's advantage over all the rest that would make me take the time and learn it?
--
Two witches watched two watches.
--
Two witches watched two watches.
Which witch watched which watch?
That seems like a strawman. Larry could have built on any number of existing scripting languages, interpreted languages, and syntaxes. Whether he deliberately ignored prior art or just didn't know about it, I don't know. But it seems pretty clear that he took a kind of perverse pleasure in combining the most oddball elements of sed, awk, sh, and C syntax.
[ ...a good scripting language implementation that takes full advantage of C++.]
Which language would you recommend we start from? To make it work well would require some nasty bolting-on in some languages.
Huh? Why would implementing Perl6 or Python3 in C++ require some "nasty bolting-on"? God knows, the current implementations of those languages are messy enough internally that they could benefit from some abstractions.
What does Ruby really offer as a compelling reason to change?
I dunno, why do you ask me? I think Python and Perl are already superfluous, let alone Ruby. I think the only reason for using them is that they are widely available and have user communities. Technically, as far as I'm concerned, they seem to be much less efficient implementations of the interpreted dynamic languages we already had in the 1970's and 1980's
To me, the real question is why people keep reinventing the wheel. Technically, none of those languages break any ground compared to their predecessors of 30 years ago. In fact, on the whole, they are simply slowly retracing the early evolution of Lisp and Smalltalk. Perl and Python could have started out being as good as Perl 5.6 and Python 2.1 if they had built on what had come before.
In any case, I use Python for any kind of complex scripting and Perl as a replacement for many simple shell scripts. Lua is great for embedding because it's so compact. If Python didn't exist, I would probably be using Ruby, but Python 2.1 cleans up most of the rough corners of earlier versions of Python (scoping, etc.).
What I think is missing is a good scripting language implementation that takes full advantage of C++. Perl, Python, and Ruby (?) are C-based and require laborious manual bookkeeping when interfacing with C/C++ code (Swig helps but isn't a complete solution). The implementations themselves would also benefit from C++'s abstraction facilities.
I think the answer to the poster's question as to why Ruby hasn't gained as much support as other languages is that it doesn't add enough perceived value to persuade people to move away from they currently use. After many years of using Perl, I switched to Python because I was looking for something that I reckoned was more object-oriented, cleaner and more explicable - I imagine similar reasons would be given by others who made the same move. But before making the move I had to weigh up the cost of switching. I've since had a look at Ruby, and though I'm prepared to concede that it may, perhaps, be a better language technically, it doesn't offer me enough perceived added value to warrant the cost of switching.
Why not use both Ruby and Python/whatever? Though there is truth in the maxim "Use the appropriate language for the task", it's also true that there are many benefits from having a body of work in the same language. Leaving aside the time and effort to learn Ruby, for me to do a project in Ruby would mean ending up with some code that I probably couldn't use from my other projects. That's why I've characterised it as a switch.
A while back I was required to do an extensive research paper and a presentation on a particular programming language. The language I was assigned was Ruby...mostly because my professor at the time had heard it mentioned once and really knew nothing about it. I will regret that encounter until the day I die. When I researched it (and I'll admit that this WAS a longish time ago) there were NO books published in english on the subject and all I had to go on was the tiny bit of documentation that came with the distrobution. Anyway, here's my point. I benchmarked Ruby against various other programming languages doing a very very simple loop in which an integer variable was incremented from 1 to 1 million. It was marked against Perl, Python, and (unfairly) C++. The results were rather interesting. C++ approx. 1.01 seconds Perl approx. 18.3 seconds Python approx. 21.2 seconds Ruby approx 47 seconds Does anyone other than me see the problem with that?
-----------------------------------------
Remove the Greed which plagues mankind.
That's like saying "why complicate things with another means of transportation when we already have horses, feet, dogsleds, etc. etc.?" Or "why complicate things with another means of communication when we already have smoke signals, morse code, etc. etc.?" You get the idea.
Existing mainstream languages are all hopelessly primitive when compared against a checklist of powerful capabilities well-known in academic circles, and found in languages such as the functionally-inspired languages like ML, Haskell, and Scheme. If you're using C, C++, or Java, you hit your head against walls daily, to the point where it becomes such second nature that you treat better methods with suspicion ("But it doesn't *hurt* to use this language - why should I switch?")
Programmers who are a little more discerning usually realize how limited the languages they use are, but the realistic alternatives are mostly more of the same. In fifty years time, today's languages will seem incredibly primitive.
Unfortunately, Ruby doesn't really advance the state of the mainstream-language art significantly, although it does have a nice collection of features so can be argued to be an incremental advance. The incentive to switch languages needs to be more than incremental, so Ruby probably isn't going to take over the world anytime soon. However, that doesn't mean development of new languages should stop. The incremental improvement of languages is an incredibly slow process: Java only recently introduced to the mainstream features which were introduced by Smalltalk around 1970 - and Java still doesn't even come close to doing everything that Smalltalk can!
It took me one day to learn ruby, using the online version of the excellent book Programming Ruby.
The next day I wrote a program to log in to a website, extract some information and email it to me. While that might not seem like a great achievement, it was the first time I had ever used hashes, iterators (which is definitely a cool feature of ruby), exceptions, http or cookies.
I was able to do this because ruby makes it so easy. Things tend to work the way you expect them to.
I would expect that if you have already used Perl or Python, you will find ruby even easier to learn.
Some other posters have mentioned the lack of "community support". I find the people on comp.lang.ruby to be extraordinarily helpful, with the creator of ruby (Matz) and one of the authors of Programming Ruby (Dave) often helping people with their problems.
Or 'who needs Linux when we have UNIX®', 'who needs Netscape when we have Mosaic', etc.
Don't write Ruby off until you play with it. And, having played with it, I've written it off. I was looking for something on the client side that was more powerful than JavaScript but not as hefty as Java. Perl moved across the wire would be beautiful and that was the goal of the Penguin module. Alas, it seems to have withered on the vine.
Be a little more open. It'll keep you young.
http://www.ruby-lang.org/en/compar.html claims to compare Ruby to other languages, and such it does. Unfortunately it's full of half-truths and downrigth lies about other languages, that doesn't make me feel warm and fuzzy. A few examples follows from the Python section:
Python types are more limited (no inheritance/subclassing; cannot add methods to existing types). What are they smoking ? No inheritance in Python ? Python has had inheritance since day one as far as I know. Cannot add methods to existing types. Not ? How about:
class chair:
"Class with no methods"
pass
def siton(obj):
print "You sit on the chair"
chair.siton = siton
Just an example, I don't know Perl or tcl well enough to comment, but when I find mistakes in simple factual claims I get a whole lot more skeptical of other claims that I am myself unable to verify.
Use the right tool for the job. If your domain does not fit an object oriented paradigm, then by all means don't use it! Procedural languages are algorithm-centric while OO languages are data-centric. So pick your language based on your problem.
When you domain model is appropriate for OOP, then by all means use an OO language. Sure, you can do it in C. But you could also do it in assembler. If you're going to use OO, then use a language that supports and facilitates OO.
A Government Is a Body of People, Usually Notably Ungoverned
What annoys me, and always has, is that people associate namespaces with OO. It makes no sense. Namespaces are a scope construct, and would be increadibly useful in procedural languages, if people would just add them.
What annoys me more, is 'OO' languages which tie namespaces to modules or objects, instead of the other way 'round.
-- Crutcher --
#include <disclaimer.h>
-- Crutcher --
#include <disclaimer.h>
Such orthogonality has aesthetic merit, but is bad for performance. There are a lot of things one can do to reduce the cost, but there is a cost.
Variable punctuation is evil regardless of whether it determines scope or type. Sure, some people like putting an MFC-ish "m_" before member names etc., and they should be free to do so, but they shouldn't be forced to do so by the language.
Again the performance issue rears its ugly head, and also the issue of assignments etc. having side effects. Sure, it can be "cool" to overload access/modification, e.g. to enforce range/consistency limits or to create "magic" variables such as r/theta when what you're really storing is x/y. However, the cost and potential for abuse aren't worth it. You can already get almost the same effect with explicit accessor functions, or with a keyword attached to declarations. People who really like being able to go in after the fact and change the semantics of an assignment in one of their classes can just always use the keyword; people who want to be able to do the same for other people's classes generally have no business doing so lest they cause all sorts of "spooky" failures when they violate the class implementation's internal dependencies.
BTW, I'm not really that hung up on performance, in the usual sense. If your application doesn't run fast enough in an interpreted (including byte-code interpreted) language, you should profile, refactor, and rewrite necessary portions in native code. However, I am concerned with performance in the sense that I hate to see billions upon billions of cycles wasted for little or no functional benefit. Machine cycles are cheap, but programmer cycles aren't. If a language runs 10% faster then that might be enough for some large number of applications, so instead of all that refactoring and rewriting I just mentioned the programmers can spend more time on adding features or making the program more robust.
Slashdot - News for Herds. Stuff that Splatters.
Try checking out the __add__, __radd__, __mul__, __rmul__, __div__, __rdiv__, etc. methods in Python. If you want to override the "*" operator for a class, all you have to do is write your own __mul__ (and, optionally, __rmul__) method and presto, operator overloading.
If you're going to bash a language, you really should make it a point to at least learn the language first.
Python 2.1 is free software; it is simply not GPL-compatible free software, due to the clause which specifies Virginia as the state of jurisdiction. Python 2.1 meets every single freedom listed in the Debian Free Software Guidelines.
Please don't spout FUD regarding Python's license. Instead, call a spade a spade and say, "Python is free software, but is not GPL-compatible. In this sense, it's no worse than the Mozilla Public License."
It could be said, as well,
Currently I'm using, and loving, Perl. It has a very active and helpful community, plus tons of modules that come with the system. While I do like Python, it doesn't have the support behind it that Perl does. Thats why I use Perl, and not Python.
Java seems to have the mark of the corporate beast on it: while it has its benefits and benefactors, it hasn't kept steam like Perl has. Personally, I'm liking the looks of JDK 1.4, with select(), assert(), faster Swing, and mostly-Perl-friendly regex classes built in.
[
If Ruby has some features that I need and no scripting language I already know fits the bill, I might make an effort to learn it, but I'm not going to go out of my way to pick up Yet Another Scripting Language.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I've seen Ruby used for AI/machine-learning code as well as some math applications. It turns out that one may extend the language using other code, such as C. Add in the untyped OO as others have discussed and you can easily write programs for multiple platforms/languages without giving up speed (write speed-critical code in a C extension).
Doctor Dobb's Journal
For more Ruby info, check out their homepage
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
Well, I'll bite.
... In scripts??
I say Object Oriented Programming is highly overrated.
Many programmers I know seem to believe there are about 2 ways to program in the world: procedural (uncivilized, messy spaghetti code, no support for large programs, etc.) and object oriented (civilized). The fact is that all modern languages spanning many different paradigms support civilized programming, even if they are not "object oriented". And what I infer from this is that objects are primarily useful only when the data you are processing are neatly expressed as objects, that is, they actually *are* objects. (For instance, if they describe operations, then higher order functions are much handier.)
Every civilized language that I know of supports the features that I believe most people think of as object-oriented. Even languages which are adamantly *not* Object Oriented (such as SML, of which I am a stalwart fan) support them.
Some examples are aggregate data (in the case of SML, aggregate data is supported much more cleanly than OO languages I know of, since one can make anonymous "classes"), abstract data types, exceptions, threads, polymorphism, garbage collection, and type safety. (The advanced languages I'm implicitly referring to also support some really nice features typically not in OO languages, such as higher-order functions, static typing, parameterized modules, and generics or "parametric polymorphism".)
So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping. Essentially, if you are not making use of subtyping (using it for polymorphism doesn't count, since other modern languages support polymorphism in their own way) in your program, then you aren't using any OO-exclusive features. Do you actually write programs the way that they introduce OO in textbooks? (A motorcycle derives from wheeled_vehicle, which derives from vehicle?)
So I guess what I'm saying is, be sure you know what you mean when you say "OOP", since there is very little which is particularly special about OO languages. In my opinion, there is not much need in scripting language for subtyping. So I say that emulating Java or C++ is not a very worthwile goal, except inasmuch as it might engender comfortable syntax/semantics for those who have only used those kinds of languages. Let's look to some other advanced languages to get us useful features in our scripting languages, and encourage the use of them.
Why not Haskell?
Why not Mozart-Oz?
Why not Prolog?
Why not Pict?
Why not Programming Language X?
The truth is, most people do not choose a programming language based on the technical merits of the language, but instead, most people choose a programming language based on a mix of the following list of reasons:
Hey, its the reason most have for why they use their natural language. I use English because it is the first language I learned, but English is not necessarily the best natural language.
For example, most people simply aren't educated in computer science, and therefore don't understand Object-Orientation, functional programming, declarative programming, etc, and therefore, these people are turned off my languages that they simply cannot understand. Why do you think that Visual Basic is so popular?
Never under estimate the horrible effects of legacy. It comes in many forms, from having large amounts of code written in previous languages, to only having experience with writing code in previous languages. If you have legacy code, then moving to another language requires allot of work to migrate the code or you could end up complicating things by keeping the old code base and introducing the new latest and greatest programming language. And the other form of legacy, mindshare legacy, is even worse. A programmer should constantly be on the hunt for tools that will make him/her more productive, but the fact is that most people are lazy and really only know how to efficiently code in one programming language... even when something better comes out, people that have already become efficient in their one favorite programming language are very reluctant to change. Why do you think that C++ is so popular?
Its obvious that hype and its flip-side, FUD, heavily influence the average person's choice in programming languages. Over the past 5 years, the ultimate way to sell a programming language was to fill the description of the language with all sorts of "Object-Oriented" buzz words. However, big dollar marketing campaigns have made at least two programming languages catch on: Java and Visual Basic. Meanwhile, FUD has been used to slam alternative programming languages into the background. Whoever thought that the words "procedural programming" would become programming language profanity?
There's so many scripting languages out there already, and it takes time to become proficient in each one. It is better to have a few that are widely used, and then some like Ruby that are nice but mostly used by code hackers who enjoy new and different things.
Too much diversity can be a bad thing, especially in open source where people have to be able to read the code to extend it.
Just my two cents.
Given the number of posts above to the effect of "What the heck is Ruby?" -- as well as the lack of any critical details in the post (such as comparisons between Ruby and the alternatives) -- one can't help but get the impression that the poster is merely looking for free advertising for his/her pet language.
Toronto-area transit rider? Rate your ride.
I don't know how many times I've heard a fellow techhead complain "Yeah, I went to work for these guys. But they have a proprietary system that they have to teach to people. It took weeks to understand." In this world, "proprietary" means "rarely used and I've barely seen it before". That's why you see ads in the paper for jobs requiring Perl and C++ and less requiring Ada programmers.
Give Ruby time, a strong open source (or not) base, and people using it to create prefabricated programs not requiring little reprogramming, and it will get the audience it deserves.
In my case, I came to Ruby from the Java world. A friend forwarded me an email announcing the release of the Programming Ruby book and so I decided to check out the language. Since I enjoy learning about new programming languages I wasn't agaist learning "yet another language." A search on Google yielded the main Ruby-lang web-site, and after some reading I decided it was worthwhile to take the time to really learn it. That was about 4 months ago.
Since then, I've read through the on-line version of Programming Ruby as well as the printed version, which I recommend very highly. It is one of the best computer language books I have ever read (and I have a Computer Engineering degree.) I have also gotten very good at programming Ruby after only a month and half of serious study. In fact, I'm probably as good (or better) at programming Ruby as I am in Java (which I've been using for 3 years.) Now that is impressive. Of course I will admit I've been somewhat obsessive with Ruby and have studied it very extensively over this last month and a half, so your mileage may vary. But still: 3 years versus 1.5 months? Hmmm....
Of course I can't say the same wouldn't happen if I seriously studied Perl or Python, but I will say I don't intend to learn those languages now. They are fine and dandy for what they do, but just like all those out there who don't want to switch to Ruby since they know Perl (or Python), I don't want to switch to them because I know Ruby. So given that, I can probably respect those who decide not to learn Ruby for this reason.
But I have heard other Ruby users who have used Perl or Python say it is an improvement to them in some ways, so it may actually be worthwhile to at least take an hour or so to give Ruby a good look. I would say the same for Java programmers. If you've never touched a so called "scripting language", learning Ruby will change how you think about programming permanently. I'm sure former Java users now using Perl or Python could say the same thing. Of course Ruby is much more than a scripting language. In fact, I really wish I could just totally stop programming Java and just use Ruby (since it can solve the same problems), but I really don't think that is possible now since Ruby is so new (to the United States.) And of course Java is pretty much the corporate mantra these days.
But in the long run I could certainly forsee Ruby replacing Java in the enterprise. In fact, I think this should in some way unite Perl, Python and Ruby users, since we have a "common enemy" in Java, heh. Of course Java has it's uses too I suppose. And before Java advocates flame me, consider that I hold this view after 3 years of being a Java advocate and switching to Ruby for about 1.5 months (as noted above.) That's how much better I think Ruby is compared to Java.
Now other complaints about Ruby usually revolve around it's newness:
- It's doesn't have a big library like Perl's CPAN.
- No one uses it.
- I can't get paid to use it.
- I don't know it and won't learn it.
Now the first argument is valid (in fact I'm working on my take on the solution), though of course like the others it is kind of a self-fullfilling prophecy. If people had used these arguments and logic with Linux, this web site wouldn't be here right now, and the world would be a much different (and probably worse) place. So given this, at least give Ruby a chance before you just bash it because it is new and you perceive it as a "threat" to your own personal favorite programming language (why are languages so much like religions to programmers?)So, to conclude, at least give Ruby a chance and try not to be so fanatical about programming languages :)
--
Ryan
"I don't need it." seems to be the consensus answer to the "Why not Ruby?" question.
If people don't need it, it doesn't stand a chance. The helpfulness of Ruby is outweighed by the cost of learning it.
The cost is greater than the benefit, just like [insert your other underused neato technology here]. Come back when the benefits are greater than the costs; preferably when they're MUCH, MUCH greater.
If you are writing simple scripts, by all means, OO is a disaster. If you are building a large scale system with components, OO helps you get there. It all depends on what you are doing.
If you are doing sysadmining, you may or may not want OO. Perhaps you have some conceptual objects, perhaps you don't. For the most part, I'd suggest that you don't.
I found for web applications, the database handles so much of your processing, that many of your public display components are simple are simple procedural displays.
However, if you are building an infrastructure, real OO style approachs can help you build up your concepts. I've found that we can often take advantage of OO design, even if not implementation.
We try to do, as you call it, text-book OO. It helps as the project scales. We have tremendous code-reuse for our client projects. This lets us stay in business despite being smaller than our competitors, because we can reuse so much of our code base. It also lets us undercut the big-boys, because we've maximized code reuse, not just taken what we've got.
Alex
I really like coding in object oriented languages. Right now I'm working on quite a major project in Python, and objectising everything is making it a lot more convenient. I'm using inheritance and polymorphism and so on, but it took me a while to figure out how that was useful in a scripting language where there isn't any strong typing.
I don't have anything against procedural languages, although I tend to write in objects more when they're available just because I'm more used to the technique. In general though, I think one of the most useful things that I get out of using objects besides all the polymorphism stuff is namespaces.
Classes are simply a really convenient way to package related things together without getting them messed up. I know this can be done without too much trouble without objects using packages or naming conventions, but classes are a much more general way to do it. Certainly it's one of the main reasons I prefer C++ over C, even for relatively simple programs, because C doen't have any natural way of assigning namespaces in a clean way that's guaranteed not to clash.
===
Here's some references ...
DDJ's January Article on Ruby (Thomas and Hunt)
Ruby Presentation (Thomas and Hunt)
Programming in Ruby Book (Thomas and Hunt. Available from Addison Wesley, online version is under an open content license)
And some web pages ...
Ruby Home Page
Ruby Central
I think the simple answer is that most people are quite happy with the scripting languages they already use.
Many people enjoy Perl, many enjoy Python, some enjoy /bin/tcsh. The latter population should however, needless to say, be put into working camps. Many also enjoy other languages, but I see Ruby mostly as a contender with Python and Perl.
So why should people switch to Ruby? Because they can do everything in Ruby they can in their current choice? Not likely. They can by definition already do that already. Because Ruby has an extensive library of ready-made code? No, because it doesn't have one compared to Perl or Python. Becuse it's a nice language design? Thats not enough reason to learn a completely new language if the one you use does what you want.
I might be prejudiced here, but i basically believe that many who like Perl do so because it's a very free-form (write-only :-) language, suitable for quick hacks. And those who like Python do so because it is a "cleaner" language, suited to write easy-to-read code. Both camps also enjoy the fauna of ready-made objects/functions/classes/modules that lets you do things easily without reimplementing the wheel.
There are probably Perlies that think Perl is a bit too loose, and Pythonettes that think Python is a bit too strict, and these people can probably find a new friend in Ruby once it gets the library support Python and Perl has.
But for most people that are already into Perl or Python, I think that the potential gain of switching languages simply isn't even close to the effort. And most Python-lovers don't want a looser language, just like most Perl-lovers probably don't want a stricter one. They're quite happy with what they've got.
In order for a new language to be able to make it as a strong contender to Python and Perl, I think it would have to supply something that neither language has, but that all programmers want (I can't think of anything matching that criterium at the moment, if I could I would've implemented that super language already! :-) If the language was then inbetween Python and Perl, both sides would have an easier time switching.
But only being between Perl and Python, which is just about everything Ruby seems to be at this point, isn't a reason to switch. It's just an advantage to ease migration if you happen to have something unique. Until Ruby actually invents something that makes it that much more valuable, I think most people will stay with the language they already use.
I do however wish the Ruby developers the best of luck. It is indeed a quite nice language, one I could definately imagine myself switching to if it gave me a clear advantage.
1. Strings are not value objects. Ouch! So you constantly have to worry about aliasing when you're passing strings around. Java got this right. (Though both languages fail on this count when it comes to date/time objects...sigh.)
2. I18N support is poor. Again, Java did this right (or got it much better, anyway)and made Strings sequences of characters, not bytes. This forces you to worry about your character set at the place (input) where you're actually in a position to deal with it, and then you never have to worry about it elsewhere. Ruby has some things (such as the Integer#char method) that just make no sense from an I18N point of view. Return the character represented by the receiver's value? In what charset?
3. Float uses the native architecture's floaing point. So FP programs' behaviour may differ (in very interesting ways, if you work with numbers such as the infinities and NaN) from system to system.
4. It's only related to certain styles, of course, but the semicolon-free syntax is, for me, more annoying than the semicolons. For continuation lines, I often try to split at operators (+, =, etc.) and put the operator at the beginning of the continuation line. Since a statement can't start with an operator (aside from C/Java constructs like ++, which I don't use in those situations), this makes it very natural to see the continuations, but in Ruby I have to put backslashes at the ends of all the continuation lines, now, and worse yet, make sure I edit them in and out properly when reformatting.
5. The Time object includes time zone information. This is confusing. Most stuff (such as comparating two times) seems to operate on the UTC value of the time, regardless of the time zone. But does #hour return the UTC hour or the hour in that time zone? If the latter, we can have two time objects that compare equal but where a.hour != b.hour.
Time zones are complex things. UTC and GMT are not the same thing (as Ruby seems to claim). Time zones do not have standardised unique three-character abbreviations (which is what Ruby seems to use for them. The time zone support, besides being fundementally broken in this way, is also implemented poorly; there's no easy way even to figure out the offset of the time zone of a given Time object.
And all this even before we start to get into date processing. Ruby doesn't seem to acknowledge the existence of different calendars. (Yes, even today different calendars are in use in a fairly major way. Take a look at a Japanese driver's licence if you don't believe me.)
I'm sure I could find more. And there's a bunch of stuff in Ruby that I like, too. But just from this glance, the language seems to have enough annoyances of its own that I can't see any reason for it to take over from Perl, Python, Java, or whatever.
cjs
The world's most portable OS: http://www.netbsd.org.
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
Yes, it does.
A Few Things I like about Ruby, by Joshua Haberman
> 65.chr
"A"
> "hello".length
5
> [1, 2, 3].last.to_s
"3"
def initialize(foo, bar, baz)
@foo = foo
@bar = bar
@baz = baz
end
class Song
def durationInMinutes
@duration/60.0 # force floating point
end
def durationInMinutes=(value)
@duration = (value*60).to_i
end
end
And now you can read to or write from someSong.durationInMinutes as if it were a simple attribute when in truth they're methods!
I'm not a Ruby expert, and I'm sure that some of these features can be found in other languages: my point is that people shouldn't just assume that Ruby is another Perl or Python, because it offers several advantages that differentiate it from Perl or Python. (and these are just a start: it features iterators, blocks-as-arguments, threads, and more)
However I completely agree that not having something like CPAN is a serious disadvantage in comparison to perl.
--
Here are the reasons I'm not, and haven't ever chosen to use Ruby:
First, I don't like the syntax[*]. Python has a beautiful, simple, typing-economic syntax that no language I've seen can compare to. Ruby doesn't -- it uses "end" to denote the end of blocks, it has several prefixes (@ and $) for varaibles to change the interpretation of those variables, and it has a strange (to me) syntax for iterating through data structures.
Second, I don't buy the speed argument. I've tested various trivial scripts and a few non-trivial ones in both Ruby and Python, and found them about equal -- Python is faster in some operations, Ruby is faster in others. In either case, neither is ever much faster or slower than the other. In the world of scripting languages, a 10% difference in speed makes very little difference -- if you need more speed for what you're doing, you likely need an order of magnitude increase, and thus, a compiled language. A 10% increase in speed isn't generally worth switching scripting languages, and except for some pathlogical cases (which exist in both cases!) you won't find Ruby or Python differing by more than 10% in their total execution time.
Thirdly, while many claim that Ruby is "more OO" than Python because even the basic types are classes which can be inherited from, it's not that simple. First, Python provides UserList, UserDict, and UserString modules for those that do need to subclass a basic type (believe me, it doesn't happen often :)). Also, functions in Python are first class objects, whereas functions in Ruby aren't. You can argue about which language is "more OO" all day long, but there are points for each side, and at the end of the day, whichever helps you do more work, no matter how OO it is, is the superior one.
Python OO is, by the way, far more reflective than Ruby OO -- you won't find anything in ruby that's as flexible as python's getattr/setattr functions and __getattr__/__setattr__/__dict__ attributes of objects. Esoteric stuff like the Meta-Object Protocol is thus far easier to implement in Python than in Ruby.
Python has a more active user community in the US and Europe (though I hear Ruby has a more active community in Japan.) The standard library in Python is to die for, and much more extensive than that included with Ruby.
Features that don't affect me as much, but still played a part in my decision not to use Ruby: It's less portable than Python and the C interface is (in my opinion) not as cleanly implemented. Python has several implementations available, whereas Ruby has only one.
In short, Ruby and Python both have their advantages and disadvantages. I prefer Python (and feel that compared to Ruby is comes out way ahead,) but even if Ruby ended up slightly ahead after an objective evaluation, it would be hard to justify learning an entirely new language for the barely incremental increase in productivity.
Jeremy
[*]: Yes, those of you who know/have looked at O'Caml have seen its syntax, and probably noted that it's far worse than Ruby's. I can agree, however, O'Caml has numerous features to compensate: static typing, tail recursion optimization, blazingly fast native code compilers, support for several programming paradigms...the list continues. O'Caml has an ugly syntax, but in most cases (and definitely in O'Caml's case) syntax is a one-time cost, and O'Caml pays back that cost nicely.
PS.: If I'm wrong on any of the above points, please correct me -- that's what I've learned from a cursory examination of the language, I don't claim to know it in-depth.
--
Looking for a Python IRC bot?
Currently I'm using, and loving, Python. It has a very active and helpful community, plus tons of modules that come with the system. While I do like Ruby, it doesn't have the support behind it that Python does. Thats why I use Python, and not Ruby.
Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
Politics.
If I were a boss I would be nervous to let a programer use a langauge like RUBY for a project. My fear would be that the employee would leave and no one would support the RUBY based app. I know this sounds stupid, untechincal and irrational in chosing a langauge but politics in the bussiness world is very important. I was reading a comment here a few days ago about slashdotter who needed a firewall solution. His boss chose an inferior solution over openBSD because the users and his boss was more familiar with the company name. Picking a political solution also looks good on my resume and to reports to directors and CIO's.
Second fear: what if the RUBY project turned out to be a diaster and nothing got done? MY boss and my boss's boss would like to know why in a detailed report. What would they think if they found out it was based on this so called experimental langauge called Ruby made by some hacker and not a corporation? I would not be employed for long if this ever occured.
Programming langauges are just as political as chosing a platform. I would encourage open source developers to increase the amount of projects based on ruby and if Ruby becomes more popular then it might be less risky for a Ruby based solution in the bussiness world.
I for one hate office politics but they are a fact of life and explains why MS is so popular.
http://saveie6.com/
The question to me isn't "Why not Ruby?" The question I would need answered is "Why Ruby?"
We've already got Perl and Python. Both scripting languages are quite powerful (way beyond what simple shell scripting can do). Both have strong communities behind them and are well supported. Both have a lot of programmers working on extentions and modules. And, importantly, both languages are open and free. Perl and Python are different enough in structure that they appeal to different people. Some like both, some like one or the other. I wouldn't want either language to go away; I don't want to see Perl "beat" Python or vice versa, since they are different enough in concept. There is a place for both of them.
But, given that we have Perl and Python as free scripting languages, and that both are powerful and supported, why do we need yet another? Mind you, I don't really know anything about Ruby; perhaps it provides something which Perl and/or Python simply can't. But unless it does, I simply don't see the point of having Ruby. If Perl or Python were controlled by a single entity (as is the case with C#, and even to some extent Java), I would see the point of having another language. But given that Perl and Python belong to anybody who want to have it belong to them, unless Ruby provides something they don't, there is simply no point to Ruby, so far as I can tell.
If you want a scripting language to do something, rather than writing a whole new one, I would say put your effort into writing a module for Perl and/or Python. The world will be better served by that. Again, all of this is unless there is something fundamental and useful about Ruby which Perl and/or Python simply can't do.
-Rob
- I already know a language, and it is perfect.
- I don't have time to learn something new.
- Someone once told me that a friend of theirs knew someone whose uncle said it was slow.
- It's new.
There are valid reasons not to deploy applications with Ruby. It doesn't (yet) have a library the size of CPAN. It doesn't (yet) own a stack full of books at your local bookstore. It doesn't (yet) have the performance of Java (although it is faster than Python in most benchmarks). That's why the people who currently use and love it tend to be more adventurous, and more forward looking. They believe that Ruby will be a significant language. In Japan, where there are a number of Ruby books, and where there is currently more Ruby support, the language has more users than Python.So, a couple of years from now, we'll probably see Slashdot readers saying "but I already know Ruby, why should I switch to xxxx?".
In the meantime, the book Programming Ruby is available online. Maybe it's worth a look. You can download Ruby from ruby-lang. Maybe it's worth a play. You never know...