Does anyone know if Google uses Ruby for application development?
What are the general job prospects of Ruby compared to other languages like Perl or Python?
Aaron's roughly right. We use C only for kernel work (and other maintenance on 3rd party stuff written in C) so I wouldn't count that as "application development", and Objective C for the very specific case of apps running client-side on Apple gear, etc.
Ruby is the embedded scripting language for Google Sketchup, see http://code.google.com/apis/sketchup/docs/gsrubyapi_examples.html -- that decision was made before Google acquired "#Last Software", Sketchup's makers.
Regarding Nishant's second question, in the wider job market, Ruby's kind of OK: still low absolute numbers but good growth, see http://duartes.org/gustavo/blog/post/programming-language-jobs-and-trends and http://blog.timbunce.org/2008/02/12/comparative-language-job-trend-graphs/ -- the data are getting a bit long in the tooth, but it's really hard to do these assessments in a very up-to-the-minute fashion;-).
Does anyone know ig google uses Ruby for any application development?
Nope: they use C/C++/Java/Python/JavaScript (I'll go find a reference).
Here's a post by Steve Yegge that makes it pretty clear they don't do Ruby.
About job prospects: If you want to work for Google, it doesn't matter which of Python, Perl and Ruby you are fluent at: Python hackers don't have an advantage over Ruby hackers etc. when applying for a job as a Software Engineer. If you want to do Perl or Ruby programming a lot, Google is not the place for you.
To get an approximation about programming language popularity in job openings, try searching for programming languages on job offer sites. For example, http://www.itpinoy.com/search/ says Java is more popular than PHP, which is more popular than Ruby.
I've been programming Perl for several years before I started using Ruby. Again, a few years later, I started using Python, while still doing Perl and Ruby as well. In general, I tend to be more productive in Ruby and Python than in Perl, so I don't do much Perl anymore. I like Python because it feels like mature, well-designed and clean for me (compared to Ruby, which I feel a little bit hackier), and I like Ruby because I can do powerful operations by typing only a little (in contrast, Python doesn't support assignment in the middle of an expression, blocks, regexps as first-class objects, mutable strings; and the standard library of Python is not so versatile, e.g. the list and dict types have less methods than in Ruby).
So for someone new to Perl, Ruby and Python, I'd recommend spending a day with Ruby, one more day with Python, and choose which of these two to concentrate on learning.
Related
Currently I have listed down learning Unix/Shell Scripting and reading CLR Algo book as the most important priority for me. I was thinking if I could solve the algorithms questions mentioned in CLR using shell scripting. Mind you I'm a complete newbie to Unix/Shell Scripting.
No, it's not. Shell scripting is definitely not designed for writing algorithms. You should use a general-purpose programming language like C, C++, Java, Python, or [insert your favorite general purpose language here].
That's not to say that you couldn't use bash or something for algorithms -- it's Turing-complete AFAIK -- but you really wouldn't want to. It'd be a huge pain, you wouldn't learn a lot of the skills you need (like modeling algorithms in common programming languages or styles), and your solutions would be cryptic. Do yourself a favor and use something else. Shell scripting is for automating tasks, not solving algorithms.
Also, most shell script languages (bash most notably) are weakly typed, which a.) hurts performance and b.) will make your program harder to reason about. Dynamic typing is OK for algorithms, weak typing, not so much. Performance will be abysmal, regardless.
If you're trying to learn both shell scripting and algorithms, you can still do it at the same time. Write scripts to compile and test your programs and write your programs in a general purpose-language.
Shells like Bash are quite powerful but I think you'll find that their limited support for arrays, no support for hashtables, and other limitations would make it tedious to implement anything more than very basic algorithms. Python or Perl would be a much better general scripting language.
(added later) Since learning that Bash 4 has associative arrays, I'd like to add that implementing some algorithms with shell scripts could be done. It wouldn't be fast, and wouldn't be elegant, would be tedious as hell, and limited in its application; but if you want to be forced to learn the intricacies of the shell while you learn to implement algorithms, that is, purely as a mental exercise, this might be a good thing for you.
Not at all. Shell scripting is good when you want a one point stop to perform all your UNIX/Linux system related activities. You can go for C/C++, Python, Java.
Universities usually prefer one of the following (not a complete list, just heard ones):
C
C++
Java
C#
Python
Matlab
Scheme
You should pick a language based on your need (learning programming is not a need, you do it for achieving something). some examples (not a complete list):
You have interest in unix-linux programming at system level: C, C++
You are interested in being a software engineer: Java, C# (maybe C++)
You are interested in web programming: PHP (maybe Python)
You are interested in mathematical/statistical programming, linear algebra etc: Matlab
etc. First: determine your programming aim, then search it on the web to see what people are using, then learn it
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know a lot of Java people have started looking at Scala since it runs on the JVM, and a lot of people in the Microsoft world are looking at F#, but what does Ruby have as a natural functional successor?
In a pure FP sense Ruby doesn't lack anything, instead it has too much some may say. A functional language forces the programmer to not use global variables and other idioms so much (although it is possible to use globals in functional languages)
There's two very different definitions of what "functional programming" means. You can kind-of do the one in Ruby, but you cannot do the other.
Those two definitions are:
programming with first-class functions and
programming with mathematical functions
You can kind-of program with first-class functions in Ruby. It has support for first-class functions. In fact, it has too much support for them: there is Proc.new, proc, lambda, Method, UnboundMethod, blocks, #to_proc and ->() (and probably some others that I forget).
All of these behave slightly differently, have slightly different syntax, slightly different behavior and slightly different restrictions. For example: the only one of these which is syntactically lightweight enough that you can actually use it densely, is blocks. But blocks have some rather severe restrictions: you can only pass one block to a method, blocks aren't objects (which in an object-oriented language in wich "everything is an object" is a very severe restriction) and at least in Ruby 1.8 there are also some restrictions w.r.t parameters.
Referring to a method is another thing that is fairly awkward. In Python or ECMAScript for example, I can just say baz = foo.bar to refer to the bar method of the foo object. In Ruby, foo.bar is a method call, if I want to refer to the bar method of foo, I have to say baz = foo.method(:bar). And if I now want to call that method, I cannot just say baz(), I have to say baz.call or baz[] or (in Ruby 1.9) baz.().
So, first-class functions in Ruby aren't really first-class. They are much better than second-class, and they are good enough™, but they aren't fully first-class.
But generally, Rubyists do not leave Ruby just for first-class functions. Ruby's support is good enough that any advantages you might gain from better support in another language usually is eaten up by the training effort for the new language or by something else that you are accustomed to that you must now give up. Like, say RubyGems or tight Unix integration or Ruby on Rails or syntax or …
However, the second definition of FP is where Ruby falls flat on its face. If you want to do programming with mathematical functions in Ruby, you are in for a world of pain. You cannot use the absolute majority of Ruby libraries, because most of them are stateful, effectful, encourage mutation or are otherwise impure. You cannot use the standard library for the same reasons. You cannot use the core library. You cannot use any of the core datatypes, because they are all mutable. You could just say "I don't care that they are mutable, I will simply not mutate them and always copy them", but the problem is: someone else still can mutate them. Also, because they are mutable, Ruby cannot optimize the copying and the garbage collector isn't tuned for that kind of workload.
It just doesn't work.
There is also a couple of features that have really nothing to do with functional programming but that most functional languages tend to have, that Ruby is missing. Pattern matching, for example. Laziness also was not that easy to achieve before Enumerators were more aggressively used in Ruby 1.9. And there's still some stuff that works with strict Enumerables or Arrays but not with lazy Enumerators, although there's actually no reason for them to require strictness.
And for this definition of FP, it definitely makes sense to leave Ruby behind.
The two main languages that Rubyists have been flocking to, are Erlang and Clojure. These are both relatively good matches for Ruby, because they are both dynamically typed, have a similar REPL culture as Ruby, and (this is more a Rails thing than a Ruby thing) are also very good on the web. They have still pretty small and welcoming communities, the original language creators are still active in the community, there is a strong focus on doing new, exciting and edgy things, all of which are traits that the Ruby community also has.
The interest in Erlang started, when someone showed the original 1993 introduction video "Erlang: The Movie" at RubyConf 2006. A couple of high-profile Rails projects started using Erlang, for example PowerSet and GitHub. Erlang is also easy to master for Rubyists, because it doesn't take purity quite as far as Haskell or Clean. The inside of an actor is pretty pure, but the act of sending messages itself is of course a side-effect. Another thing that makes Erlang easy to grasp, is that Actors and Objects are actually the same thing, when you follow Alan Kay's definition of object-oriented programming.
Clojure has been a recent addition to the Rubyist's toolbelt. Its popularity is I guess mostly driven by the fact that the Ruby community has finally warmed up to the idea that JVM ≠ Java and embraced JRuby and then they started to look around what other interesting stuff there was on the JVM. And again, Clojure is much more pragmatic than both other functional languages like Haskell and other Lisps like Scheme and much simpler and more modern than CommonLisp, so it is a natural fit for Rubyists.
Another cool thing about Clojure is that because both Clojure and Ruby run on the JVM, you can combine them.
The author of "Programming Clojure" (Stuart Halloway) is a (former?) Rubyist, for example, as is Phil Hagelberg, the author of the Leiningen build tool for Clojure.
However, Rubyists are also looking at both Scala (as one of the more pragmatic statically typed FP languages) and Haskell (as one of the more elegant ones). Then there is projects like Scuby and Hubris which are bridges that let you integrate Ruby with Scala and Haskell, respectively. Twitter's decision to move part of their low-level messaging infrastructure first from MySQL to Ruby, then from Ruby to Scala is also pretty widely known.
F# doesn't seem to play any role at all, possibly due to an irrational fear towards all things Microsoft the Ruby community has. (Which, BTW, seems mostly unfounded, given that the F# team has always made versions available for Mono.)
Java people are using a language on the JVM and want a more functional one compatible with their runtime, so they go to Scala.
C# people are using a language on the CLR and want a more functional one compatible with their runtime, so they go to F#.
Ruby people are using a language that's already pretty functional, and they're using it on a number of underlying runtimes (JRuby, IronRuby, MRI, MacRuby, Rubinius, etc...). I don't think it has a natural functional successor, or even needs one.
Any version of Lisp should be fine.
Ruby it self is a kind of Functional programming language, So I don't see any special dialects for FP using ruby.
In hype level, Haskell.
Assuming Ruby people don't just go to the JVM themselves, I think most would adopt Erlang, being another dynamically typed language.
Ruby isn't as functional as say Lisp, but it is just functional enough that you can do some functional programming in a good fun way. (unlike trying to do functional programming in something like C#)
Also, it actually forces you into functional paradigms in some of its syntax, such as the heavy use of blocks and yield. (which I fell in love with after learning Ruby).
if i like Ruby a lot, is there a reason I should learn another language now, such as Lua or Erlang?
New programming languages, much like spoken languages, can open up new perspectives. Learning new languages -- especially ones rather different from what you're used to (and Erlang will probably fit that bill) -- can teach you a lot of different things you didn't even know you didn't know about programming. So yes, I think you absolutely should, even if you just learn enough to tinker with it and get a feel for the new language.
Learning a functional language in particular can be extremely beneficial. Becoming familiar with the functional style of programming is a surefire step toward becoming a better programmer. Lisp (or its derivatives) in particular is a good language to study. Here's a list of past thread on SO that might offer you some insight along these lines:
Why do people think functional programming will catch on?
What’s a good Functional language to learn?
Benefits of learning scheme?
Leaving aside the (excellent) general reasons to want to learn another language, if you like Ruby a lot you might want to
Learn Smalltalk, which is a language very, very similar to Ruby but in purer form.
Learn a language that is very, very different—say something that is based on algebraic data types and functions rather than objects and methods, and something with a static type system rather than a dynamic type system—but something that, like Ruby, will support powerful methods of program composition and generic programming. Good candidates would include Standard ML and Haskell.
Learn a language that is very, very different—say something that makes you control every bit, address, and word in memory—something that forces you to understand and take control of the hardware. In other words, learn C.
Regarding the other languages you mention,
Lua is small and very elegantly designed and implemented. That may appeal to the Rubyist in you. But unlike Ruby it does not impose much of a worldview; it is more of a collection of piece parts. I would suggest you're more likely to appreciate and enjoy Lua after you've worked in three or four other languages first.
Erlang is interesting, but I have a gut feel it's either too different (purely functional, distributed) or not different enough (dynamic type system). But if it appeals to you, go for it.
On the other hand, there's something to be said for really knowing a language well. You'll be able to do a lot more with in-depth knowledge of a single language than you will with surface knowledge of a dozen.
If you like Ruby a lot you should definitely learn another language... one without sigils if possible.
Seems to me that a professional learns the tools he needs to use. Frameworks, containers, languages, all are fair game. I started out in Pascal, went to C and then C++. Then converted to Java. These days its mostly Java with a lot of Javascript and some PHP. Easy enough right? Well, I also need to learn Bash scripting and Perl. Never mind all the other crap I need to get on top of (if you say you understand all of web authentication I will call you a liar). There's a lot of stuff out there. Jump in. Be willing to try different things.
I always enjoy learning new languages for the mere challenge of it. It keeps my brain fit. I've also found it makes for good job interview fodder to be able to say "I'm flexible. I'm adaptable to whatever your needs may be in the future. And I can prove it with my long list of languages."
My main language is PHP. I am a script language fan, nevertheless I have dived into C#, Java, Python, Ruby and even OO JavaScript books to find new mechanisms, ways of thinking. I have found pretty many stunts in Java for example, that I could implement in my all day work. So learning or just studying new languages can widen your perspective.
Dynamic languages are on the rise and there are plenty of them: e.g. Ruby, Groovy, Jython, Scala (static, but has the look and feel of a dynamic language) etc etc.
My background is in Java SE and EE programming and I want to extend my knowledge into one of these dynamic languages to be better prepared for the future.
But which dynamic language should I focus on learning and why? Which of these will be the preferred language in the near future?
Learning Ruby or Python (and Scala to a lesser extent) means you'll have very transferrable skills - you could use the Java version, the native version or the .NET version (IronRuby/IronPython). Groovy is nice but JVM-specific.
Being "better prepared for the future" is tricky unless you envisage specific scenarios. What kind of thing do you want to work on? Do you have a project which you could usefully implement in a dynamic language? Is it small enough to try on a couple of them, to get a feeling of how they differ?
Scala is not a dynamic language at all. Type inference doesn't mean that its untyped. However, Its a very nice language that has nice mixture of OOPs and functional programming. The only problem is some gotchas that you encounter along the way.
Since you are already an experienced Java programmer, it will fit nicely into your skillset. Now, if you want to go all the way dynamic both Ruby or Python are awesome languages. There is demand for both the languages.
I would personally recommend Clojure. Clojure is an awesome new language that is going in popularity faster than anything I've ever seen. Clojure is a powerful, simple, and fast Lisp implemented on the JVM. It has access to all Java libraries of course, just like Scala. It has a book written about it already, it's matured to version 1.0, and it has three IDE plugins in development, with all three very usable.
I would take a look at Scala. Why ?
it's a JVM language, so you can leverage off your current Java skills
it now has a lot of tooling/IDE support (e.g. Intellij will handle Scala projects)
it has a functional aspect to it. Functional languages seem to be getting a lot of traction at the moment, and I think it's a paradigm worth learning for the future
My (entirely subjective) view is that Scala seems to be getting a lot of the attention that Groovy got a year or two ago. I'm not trying to be contentious here, or suggest that makes it a better language, but it seems to be the new JVM language de jour.
As an aside, a language that has some dynamic attributes is Microsoft's F#. I'm currently looking at this (and ignoring my own advice re. points 1 and 2 above!). It's a functional language with objects, built on .Net, and is picking up a lot of attention at the moment.
In the game industry Lua, if you're an Adobe based designer Lua is also good, if you're an embedded programmer Lua is practically the only light-weight solution, but if you are looking into Web development and General tool scripting Python would be more practical
I found Groovy to be a relatively easy jump from an extensive Java background -- it's sort of a more convenient version of Java. It integrates really nicely with existing Java code as well, if you need to do that sort of thing.
I'd recommend Python. It has a huge community and has a mature implementation (along with several promising not-so-mature-just-yet ones). Perl is as far as I've seen loosing a lot of traction compared to the newer languages, presumably due to its "non-intuitiveness" (no, don't get me started on that).
When you've done a project or two in Python, go on to something else to get some broader perspective. If you've done a few non-trivial things in two different dynamic languages, you won't have any problems assimilating any other language.
JScript is quite usefull, and its certainly a dynamic language...
If you want a language with a good number of modules (for almost anything!), go for Perl. With its CPAN, you will always find what you want without reinventing the wheel.
Well keeping in mind your background, i would recommend a language where the semantics are similar to what you are aware of. Hence a language like Scala, Fan, Groovy would be a good starting point.Once you get a hang of the basic semantics of using a functional language(as well as start loving it), you can move onto a language like Ruby. The turn around time for you in this way gets reduced as well as the fact that you can move towards being a polyglot programmer.
i would vote +1 for Groovy (and Grails). You can type with Java style or Groovy still (you can also mix both and have no worry about that). Also you can use Java libs.
As a general rule, avoid dynamically typed languages. The loss of compile time checking and the self-documenting nature of strong, static typing is well worth the necessity of putting type information into your source code. If the extra typing you need to do when writing your code is too great an effort, then a language with type inference (Scala, Haskell) might be of interest.
Having type information makes code much more readable, and readability should be your #1 criteria in coding. It is expensive for a person to read code, anything that inhibits clear, accurate understanding by the reader is a bad thing. In OO languages it is even worse, because you are always making new types. A reader just getting familiar will flounder because they do not know the types that are being passed around and modified. In Groovy, for example, the following is legal def accountHistoryReport(in, out) Reading that, I have no idea what in and out are. When you are looking at 20 different report methods that look just like that, you can quickly go completely homicidal.
If you really think you have to have non-static typing, then a language like Clojure is a good compromise. Lisp-like languages are built on a small set of key abstractions and massive amount of capability on each of the abstractions. So in Clojure, I will create a map (hash) that has the attributes of my object. It is a bit reductionalist, but I will not have to look through the whole code base for the implementation of some un-named class.
My rule of thumb is that I write scripts in dynamic languages, and systems in compiled, statically typed languages.
I got involved in a new project where Perl is a must. I'm coming from a good Ruby foundation and want a quick introduction or mapping between Perl and Ruby as I heard that Perl and Ruby are very close in syntax (know nothing about features).
Do you have any recommendations for me?
What great Perl book do you recommend as an extended reference?
What is the commonly used version of Perl right now?
I second Nathan's book recs, though I would also mention Beginning Perl. Two bonus features are (1) it's available freely (and legally) online in its first edition (note: this site is timing out right now, and I'm unsure if that's temporary or not) and (2) it covers about as much as Learning Perl and Intermediate Perl combined. A con is that it's at times more elementary that you might want. (Learning Perl goes faster and assumes a bit more - which can be a good thing.)
You might also check out this: To Ruby From Perl from Ruby's website. Just think of it in reverse.
In terms of versions, 5.10.1 is stable, but you will come across a range. Mostly you will find 5.8.x and up, I suspect. (Just as with Ruby 1.9.1 is stable but you will find plenty of places still using 1.8.6 or up.)
Since I'm somewhat going in the opposite direction (I know Perl reasonably well, and I'm using Ruby more and more often), I can mention things that stick out to me:
In Perl, you get automatic conversion between strings and numbers (and you don't need to explicitly ask for a float result by using .to_f or making one item a float).
Semicolons are not optional to end statements in Perl. Similarly parentheses are optional less often in Perl than they are in Ruby. (This gets complex quickly, but for example you must have parentheses for the test in a condition or a while block.)
0 (string, integer and float), undef and the empty string evaluate as false in boolean tests.
There are no separate booleans true and false.
You distinguish data types with sigils: $foo is a scalar; #foo is an array; %foo is a hash. (Arrays in particular will bug you: they aren't instance variables.)
You need to explicitly scope items in Perl, using the my keyword.
Arrays in Perl are automatically flattened when combined. (This constantly bites me in Ruby.)
Context, context, context. In Perl an enormous amount of what your code actually does depends on understanding what context you're in. Here's a link for a start, but it's a big topic with a lot of nooks and crannies.
(Note that I didn't mention the 1000 pound gorilla in the room. OO is part of what Perl is and can do, but it's not at the center of Perl, as it is in Ruby.)
Versions
In The Perl Survey 2007***, the majority of Perl coders used Perl 5.8, with 87% using 5.8.x at least some of the time, and 5.8.8 being the most common single version. A minority used 5.6.x for at least some projects, and a smaller (but occasionally quite vocal) minority uses 5.005. Since that point Perl 5.10 has been released and it's not clear yet what the adoption rate is; likely many businesses are being conservative and running 5.8.8 or 5.8.9, but many of what you might call "prominent hackers" are using 5.10.1 and even sometimes requiring its features.
References
Programming Perl is a winner for anyone with previous programming experience who wants to get up to speed on Perl quickly. The current edition is the third, which corresponds (unfortunately) to Perl 5.6.0.
The series Learning Perl, Intermediate Perl, Mastering Perl is also recommended; Learning Perl starts off rather slow because it targets beginners, but it eventually covers all of the major features of the language, including some that didn't exist in 2000 when Programming Perl was last revised.
Perldocs. Please, don't neglect the perldocs. The master index is at perldoc perl, or you can read online at perldoc.perl.org. These are nearly as good a reference as Programming Perl because in fact a decent portion of that book is drawn from the Perldocs. I would recommend at least a thorough skim of perlsyn, perlop, perlrun, perlvar, perlre, perlobj, perlmod, perluniintro, perlreftut, and perldsc. Reading straight through perlfunc once isn't a bad idea either.
Effective Perl Programming is a book I've always recommended for learning how to approach problems with a Perl frame of mind. Its 1998 publication date limits its usefulness a bit but I still think it's worth a read -- and fortunately, brian d foy and Josh McAdams are working on an updated edition, due (I think -- don't trust me too far on this) March 2010. [And the second edition is now here -- brian]
Perlmonks is a great resource, especially if you remember to use the search feature. A great many questions have been asked and answered there, and the best answers are indexed for posterity, along with lists of resources such as books and online FAQs.
***: I would love to provide a link to The Perl Survey 2007 but unfortunately the perlsurvey.org domain was allowed to lapse. A copy of the results PDF may be found at github, and the mostly-raw data is on CPAN as Data::PerlSurvey2007.
Do you have any recommendations for me?
Perl.org is a good site to get some resources
What great Perl book do you recommend as an extended reference?
Programming Perl and Learning Perl are very nice, but also take a look here
What is the common used version of Perl right now?
Depends of your platform, take a look here
People keep telling me Picking Up Perl is dated and they are right but it is such a concise introduction that I would recommend reading it and then jumping straight into Intermediate Perl and Perl Best Practices as well as Perl Cookbook. The Cookbook is great if you learn by better by concrete, bite-sized examples.
Further, I really recomend reading the FAQ List before doing anything else.
I recommend "Programming Perl", "Perl Best Practices" and the "Perl Cookbook" also.
The "PBP" book is good, not because it teaches you rules, but because it makes you stop and think about why you should do things a certain way, and make an educated decision when you decide to stray from Conway's recommended path.
As for documentation, I often use CPAN's documents as they're the most current and offer hyperlinks, something we don't get from the local perldocs on our drive.
One of the things I loved about Ruby when I first started using it compared to Perl, was gems vs. CPAN. Keeping a set of gems current seems so much easier than a set of CPAN-based modules.
And, like Sinan says, the FAQs are great reading. I've read and reread them many times because the knowledge is good to keep in your head.
And, though they can be rather blunt, the PerlMonks are a wonderful resource. Simply searching and reading how they recommend doing things can raise your Perl consciousness several levels, even if you don't engage them with a direct question.
And, in the way of the monk, contemplate Perl's hashes and learn about slicing them. They are the shiz.