Here is the only way I know to ask it at the moment. As Understand it Scala uses the Java Virtual Machine. I thought Jruby did also. Twitter switched its middleware to Scala. Could they have done the same thing and used Jruby?
Could they have started with Jruby to start with and not had their scaling problems that caused them to move from Ruby to Scala in the first place? Do I not understand what Jruby is? I'm assuming that because Jruby can use Java it would have scaled where Ruby would not.
Does it all boil down to the static versus dynamic types, in this case?
Scala is "scalable" in the sense that the language can be improved upon by libraries in a way that makes the extensions look like they are part of the language. That's why actors looks like part of the language, or why BigInt looks like part of the language.
This also applies to most other JVM languages. It does not apply to Java, because it has special treatment for it's basic types (Int, Boolean, etc), for operators, cumbersome syntax that makes clear what is built in the language and what is library, etc.
Now, Scala is more performatic than dynamic languages on the JVM because the JVM has no support for them. Dynamic languages on JVM have to resort t reflection, which is very slow.
No, not really. It's not that the JVM is somehow magic and makes things scale by its magic powers; it's that Scala, as a language, is architected to help people write scalable systems. That it's on top of the JVM is almost incidental.
I don't really think that the language is the biggest problem here. Twitter grew insanely fast, which always leads to a code mess. And if you do a rewrite, it is a good idea to go for a different language - that bars you from building your own mistakes again and/or to "reuse some parts". Also, Ruby is not really meant for that kind of heavy data handling that the twitter backend does.
The frontend remains Ruby, so they still use it.
You have to separate out different meanings of scaling:
Scaling in terms of growing the number of requests per second that can be handled with a proportionate increase in hardware
Scaling in terms of growing a code base without it becoming a tangled mess
Scala helps on the first point because it compiles to Java bytecode that's really similar to Java, and therefore usually has the same performance as Java. I say "usually," because Scala there are some cases where idiomatic Scala causes large amount of boxing to take place where idiomatic Java would not (this is slated to change in Scala 2.8).
Performance is of course different than scaling. Equivalent code written in JRuby would scale just as well, but the slope of the line would be steeper - you'd need more hardware to handle the same number of requests, but the shape of the line would be the same. But from a more practical perspective the performance helps because you rarely can scale in a perfectly linear fashion with respect to adding core or especially servers and having better performance slows the rate at which you have to add capacity.
Scala helps with the second point because it has an expressive, compile-time enforced type system and it provides a lot of other means for managing the complexity of your code, such as mixins. You can write spaghetti code in any language, but the Scala compiler will tell you when some of the noodles are broken while with JRuby you'll have to rely solely on tests. I've personally found that for me Python breaks down at about 1000 closely related LOCs, and which point I have to refactor to either substantially reduce of the LOCs or make the structure more modular. Of course this refactoring would be a good idea regardless of what your language, but occasionally the complexity is inherent. Dealing with a large number of tightly couple LOCs isn't easy in any language, but it is much easier in Scala than it is in Python, and I think the analogy extends to Ruby/JRuby as well.
Scala is a statically typed language. JRuby is dynamically typed. That is why Scala is faster than JRuby, even though both run on the JVM. JRuby has to do a lot of work at runtime (method resolution, etc.) that Scala does at compile-time. For what it's worth, though, JRuby is a very fast Ruby implementation.
Scalability is not an inherit language capability. You are talking about speed.
A better question to ask would be "Why is Scala faster than other JVM languages (or is it)?". As others have pointed out, it's a static vs. dynamic language thing.
There's an interesting discussion from the Twitter developers themselves in the comments of this post.
They've evaluated the different options and decided to implement the back-end in Scala because: it ran faster than the Ruby/JRuby alternatives and they felt they could benefit from static typing.
Related
First off, I'm aware that there are many questions related to this, but none of them seemed to help my specific situation. In particular, lua and python don't fit my needs as well as I could hope. It may be that no language with my requirements exists, but before coming to that conclusion it'd be nice to hear a few more opinions. :)
As you may have guessed, I need such a language for a game engine I'm trying to create. The purpose of this game engine is to provide a user with the basic tools for building a game, while still giving her the freedom of creating many different types of games.
For this reason, the scripting language should be able to handle game concepts intuitively. Among other things, it should be easy to define a variety of types, sub-type them with slightly different properties, query and modify objects dynamically, and so on.
Furthermore, it should be possible for the game developer to handle every situation they come across in the scripting language. While basic components like the renderer and networking would be implemented in C++, game-specific mechanisms such as rotating a few hundred objects around a planet will be handled in the scripting language. This means that the scripting language has to be insanely fast, 1/10 C speed is probably the minimum.
Then there's the problem of debugging. Information about the function, stack trace and variable states that the error occurred in should be accessible.
Last but not least, this is a project done by a single person. Even if I wanted to, I simply don't have the resources to spend weeks on just the glue code. Integrating the language with my project shouldn't be much harder than integrating lua.
Examining the two suggested languages, lua and python, lua is fast(luajit) and easy to integrate, but its standard debugging facilities seem to be lacking. What's even worse, lua by default has no type-system at all. Of course you can implement that on your own, but the syntax will always be weird and unintuitive.
Python, on the other hand, is very comfortable to use and has a basic class system. However, it's not that easy to integrate, it's paradigm doesn't really involve type-checking and it's definitely not fast enough for more complex games. I'd again like to point out that everything would be done in python. I'm well aware that python would likely be fast enough for 90% of the code.
There's also Scala, which I haven't seen suggested so far. Scala seems to actually fulfill most of the requirements, but embedding the Java VM with C doesn't seem very easy, and it generally seems like java expects you to build your application around java rather than the other way around. I'm also not sure if Scala's functional paradigm would be good for intuitive game-development.
EDIT: Please note that this question isn't about finding a solution at any cost. If there isn't any language better than lua, I will simply compromise and use that(I actually already have the thing linked into my program). I just want to make sure I'm not missing something that'd be more suitable before doing so, seeing as lua is far from the perfect solution for me.
You might consider mono. I only know of one success story for this approach, but it is a big one: C++ engine with mono scripting is the approach taken in Unity.
Try the Ring programming language
http://ring-lang.net
It's general-purpose multi-paradigm scripting language that can be embedded in C/C++ projects, extended using C/C++ code and/or used as standalone language. The supported programming paradigms are Imperative, Procedural, Object-Oriented, Functional, Meta programming, Declarative programming using nested structures, and Natural programming.
The language is simple, trying to be natural, encourage organization and comes with transparent implementation. It comes with compact syntax and a group of features that enable the programmer to create natural interfaces and declarative domain-specific languages in a fraction of time. It is very small, fast and comes with smart garbage collector that puts the memory under the programmer control. It supports many programming paradigms, comes with useful and practical libraries. The language is designed for productivity and developing high quality solutions that can scale.
The compiler + The Virtual Machine are 15,000 lines of C code
Embedding Ring Interpreter in C/C++ Programs
https://en.wikibooks.org/wiki/Ring/Lessons/Embedding_Ring_Interpreter_in_C/C%2B%2B_Programs
For embeddability, you might look into Tcl, or if you're into Scheme, check out SIOD or Guile. I would suggest Lua or Python in general, of course, but your question precludes them.
Since noone seems to know a combination better than lua/luajit, I think I will leave it at that. Thanks for everyone's input on this. I personally find lua to be very lacking as a high-level language for game-programming, but it's probably the best choice out there. So to whomever finds this question and has the same requirements(fast, easy to use, easy to embed), you'll either have to use lua/luajit or make your own. :)
Is it possible to design something like Ruby or Clojure without the significant performance loss in many situations compared with C/Java? Does hardware design play a role?
Edit: With significant I mean in an order of magnitudes, not just ten procent
Edit: I suspect that delnan is correct with me meaning dynamic languages so I changed the title
Performance depends on many things. Of course the semantics of the language have to be preserved even if we are compiling it - you can't remove dynamic dispatch from Ruby, it would speed things up drmatically but it would totally break 95% of the all Ruby code in the world. But still, much of the performance depends on how smart the implementation is.
I assume, by "high-level", you mean "dynamic"? Haskell and OCaml are extremely high-level, yet are is compiled natively and can outperform C# or Java, even C and C++ in some corner cases - especially if parallelism comes into play. And they certainly weren't designed with performance as #1 goal. But compiler writers, especially those focused onfunctional languages, are a very clever folk. If you or I started a high-level language, even if we used e.g. LLVM as backend for native compilation, we wouldn't get anywhere near this performance.
Making dynamic languages run fast is harder - they delay many decisions (types, members of a class/an object, ...) to runtime instead of compiletime, and while static code analysis can sometimes prove it's not possible in lines n and m, you still have to carry an advanced runtime around and do quite a few things a static language's compiler can do at compiletime. Even dynamic dispatch can be optimized with a smarter VM (Inline Cache anyone?), but it's a lot of work. More than a small new-fangeled language could do, that is.
Also see Steve Yegge's Dynamic Languages Strike Back.
And of course, what is a significant peformance loss? 100 times slower than C reads like a lot, but as we all know, 80% of execution time is spent in 20% of the code = 80% of the code won't have notable impact on the percieved performance of the whole program. For the remaining 20%, you can always rewrite it in C or C++ and call it from the dynamic language. For many applications, this suffices (for some, you don't even need to optimize). For the rest... well, if performance is that critical, you should propably write it in a language designed for performance.
Don't confuse the language design with the platform that it runs on.
For instance, Java is a high-level language. It runs on the JVM (as does Clojure - identified above, and JRuby - a Java version of Ruby). The JVM will perform byte-code analysis and optimise how the code runs (making use of escape analysis, just-in-time compilation etc.). So the platform has an effect on the performance that is largely independent of the language itself (see here for more info on Java performance and comparisons to C/C++)
Loss compared to what? If you need a garbage collector or closures then you need them, and you're going to pay the price regardless. If a language makes them easy for you to get at, that doesn't mean you have to use them when you don't need them.
If a language is interpreted instead of compiled, that's going to introduce an order of magnitude slowdown. But such a language may have compensating advantages, like ease of use, platform independence, and not having to compile. And, the programs you write in them may not run long enough for speed to be an issue.
There may be language implementations that introduce slowness for no good reason, but those don't have to be used.
You might want to look at what the DARPA HPCS initiative has come up with. There were 3 programming languages proposed: Sun's Fortress, IBM's X10 and Cray's Chapel. The latter two are still under development. Whether any of these meet your definition of high-level I don't know.
And yes, hardware design certainly does play a part. All 3 of these languages are targeted at supercomputers with very many processors and exhibit features appropriate to that domain.
It's certainly possible. For example, Objective-C is a dynamically-typed language that has performance comparable to C++ (although a wee bit slower, generally speaking, but still roughly equivalent).
What is the most performant (fastest) lisp implementation on the JVM?
By lisp implementation I consider all implementations of any language in lisp family, like Common Lisp, Scheme, Clojure, ...
I know that Clojure can be made pretty fast using type hints, that ABCL is in general not considered to be fast. I don't have experience using any Scheme on JVM, but heard that Kawa is pretty fast too.
With Clojure you can get to the speed of Java (with type hints of course) and you can not get faster than java (exept in some very rare cases). I don't know about the other lisps the are maybe the same speed but not faster.
So that said about the standard speed of calls and so on.
Clojure has data structures are not always as fast as possible but the really make up for that with there other properties like thread safety, immutable and fast reading.
To make the data structures faster Rich invented transient with make them mutable in a way that they are still functional (and the are a LOT faster) and he is already working on the next big thing (read about the Emerging Languages camp talk of rich).
Its much easier to write concurrent code with clojure so that is really imported for to make fast programmes.
So the next thing is math. There are three levels of Speed on the JVM. Math with boxed Types,primitiv Types with overflow checking,or without overflow checking. Clojure provides all of those so no limit there.
So the next thing is how fast can you work with Java, if you have to use wrappers you wont perform as good and java calls are used often in most JVM languages. To implement clojure in clojure, clojure needed to add a low level construct so that you can interact with java without any overhead.
So clojure is as fast as it gets on the JVM.
P.S.
Protocols are like really fast multmethods witch are not that generic but the dispatch fast enough to use them in clojure core (and so not depend on java anymore). Look them up the are way cool.
not a whole lot of good data though this and some others seem to indicate the obvious. Immutible languages suffer slightly when doing non-immutable tasks, and non-immutable languages suffer when doing highly parallel tasks.
When considering these questions it helps to consider the "fail back option". Clojure can fall back to java for any part of your code that the profiler tells you is not pulling its wight.
in short: I vote clojure :)
I'd be surprised if it is not clojure. No other JVM lisp I know of has had as much attention paid to performance. The fastest Scheme is probably SISC - it's compiled to a FASL format, but still not "native" JVM instruction level.
I've been testing various lisps over the last few weeks. Kawa is the fastest JVM implementation I've tried so far in terms of startup time, REPL response time and running basic scripts. The author posted some performance statistics in 2010, which shows that Kawa outperforms clojure by a clear margin. YMMV.
http://per.bothner.com/blog/2010/Kawa-in-shootout/
I have recently been looking around to learn a new language during my spare time and Scala seems to be very attractive.
I have a few questions regarding it:
Will not knowing Java impose a
challange in learning it? Will it be
a big disadvantage
later on? ( i.e How often do people rely on
Java-specific libraries? )
How big of a difference it is
compared to Ruby? (Apart from being
statically typed) Does it introduce
a lot of new terms, or will I be
familiar with most of the language's
mechanisms?
What resources would you recommend?
I have my eye on Programming Scala
and Beginning Scala books
Although subjective, is Scala fun to programme in? : P
Thanks
There are many concepts that are shared between Ruby and Scala. It's been a while since I've coded Ruby, so this isn't exhaustive.
Ruby <==> Scala (Approximately!)
Mixins <==> Traits
Monkey Patching <==> Pimp My Library (Implicit Conversions to a wrapper with extra methods)
Proc/Closure <==> Function/Function Literal
Duck Typing <==> Structural Types
Last Argument as a Proc <==> Curried Parameter List (see Traversable#flatMap)
Enumerable <==> Traversable
collect <==> map
inject <==> foldLeft/foldRight
Symbol.toProc <==> Placeholder syntactic sugar: people.map(_.name)
Dynamic Typing conciseness <==> Type Inference
Nil <==> null, although Option is preferable. (Not Nil, which is an empty list!)
Everything is an expression <==> ditto
symbols/hashes as arguments <==> Named and Default Parameters
Singleton <==> object Foo {}
Everthing is an object <==> Everthing is a type or an object (including functions)
No Primitives <==> Unified type system, Any is supertype for primitives and objects.
Everything is a message <==> Operators are just method calls
Ruby's Features you might miss
method_missing
define_method etc
Scala Features you should learn
Pattern Matching
Immutable Classes, in particular Case Classes
Implicit Views and Implicit Parameters
Types, Types, and more Types: Generics, Variance, Abstract Type Members
Unification of Objects and Functions, special meaning of apply and update methods.
Here is my take on it:
Never mind not knowing Java.
Scala relies a lot on Java libraries. That doesn't matter at all. You might have trouble reading some examples, sure, but not enough to be a hindrance. With little time, you won't even notice the difference between reading a Java API doc and a Scala API doc (well, except for the completely different style of the newest scaladoc).
Familiarity with the JVM environment, however, is often assumed. If I can make one advise here, it is to avoid Maven at first, and use SBT as a build tool. It will be unnecessary for small programs, but it will make much of the kinks in the Java-lang world easier to deal with. As soon as you want an external library, get to know SBT. With it, you won't have to deal with any XML: you write your build rules in Scala itself.
You may find it hard to get the type concepts and terms. Scala not only is statically typed, but it has one of the most powerful type systems on non-academic languages out there. I'm betting this will be the source of most difficulty for you. Other concepts have different terminology, but you'll quickly draw parallels with Ruby.
This is not that big of a hurdle, though -- you can overcome it if you want to. The major downside is that you'll probably feel any other statically typed language you learn afterwards to be clumsy and limited.
You didn't mention which Programming Scala you had your eyes on. There are two, plus one Programming in Scala. That latter one was written, among others, by the language creator, and is widely considered to be an excellent book, though, perhaps, a bit slow. One of the Programming Scala was written by a Twitter guy -- Alex Payne -- and by ex-Object Mentor's Dean Wampler. It's a very good book too. Beginning Scala was written by Lift's creator, David Pollack, and people have said good things about it to. I haven't heard anyone complain about any of the Scala books, in fact.
One of these books would certainly be helpful. Also, support on Stack Overflow for Scala questions is pretty good -- I do my best to ensure so! :-) There's the scala-users mailing list, where one can get answers too (as long as people aren't very busy), and there's the #scala IRC channel on Freenode, where you'll get good support as well. Sometimes people are just not around, but, if they are, they'll help you.
Finally, there are blogs. The best one for beginners is probably Daily Scala. You can find many, many others are Planet Scala. Among them, my own Algorithmically Challenged, which isn't getting much love of late, but I'll get back to it. :-)
Scala has restored fun in programming for me. Of course, I was doing Java, which is booooring, imho. One reason I spend so much time answering Stack Overflow questions, is that I enjoy working out solutions for the questions asked.
I'm going to introduce a note of caution about how much Java knowledge is required because I disagree that it isn't an issue at all. There are things about Java that are directly relevant to scala and which you should understand.
The Java Memory Model and what mechanisms the platform provides for concurrency. I'm talking about synchronization, threads etc
The difference between primitive types (double, float etc) and reference types (i.e. subclasses of Object). Scala provides some nice mechanisms to hide this from the developer but it is very important, if writing code which must be performant, to know how these work
This goes both ways: the Java runtime provides features that (I suspect, although I may be wrong) are not available in Ruby and will be of enormous benefit to you:
Management Extensions (MBeans)
JConsole (for runtime monitoring of memory, CPU, debugging concurrency problems)
JVisualVM (for runtime instrumentation of code to debug memory and performance problems)
These points #1 and #2 are not insurmountable obstacles and I think that the other similarities mentioned here will work strongly in your favour. Oh, and Scala is most certainly a lot of fun!
I do not have a Ruby background but nevertheless, I might be able to help you out.
I don't thing not knowing Java is a disadvantage, but it might help. In my opinion, Java libraries are used relatively often, but even a trained Java coder don't know them all, so no disadvantage here. You will learn some parts of the Java library by learning Scala because even the Scala libraries use them.
--
I started out by reading Programming Scala and turned over to read the source of the Scala library. The latter helped a lot to understand the language. And as always: Code, Code, Code. Reading without coding wont get you anywhere, but I'm sure you know that already. :-)
Another helpful resources are blogs, see https://stackoverflow.com/questions/1445003/what-scala-blogs-do-you-regularly-follow for a compilation of good Scala blogs.
It is! As you stated, this is very subjective. But for me, coming from a Java background, It is a lot of fun.
This is very late, but I agree to some extent with what oxbow_lakes said. I have recently transitioned from Python to Scala, and knowing how Java works -- especially Java limitations regarding generic types -- has helped me understand certain aspects of Scala.
Most noticeably:
Java has a horribly broken misfeature known as "type erasure". This brokenness is unfortunately present in the JVM as well. This particularly affects programming with generic types -- an issue that simply doesn't come up at all in dynamically-typed languages like Ruby and Python but is very big in statically typed languages. Scala does about as good a job as it can working around this, but the magnitude of the breakage means that some of it inevitably bleeds through into Scala. In addition, some of the fixes in Scala for this issue (e.g. manifests) are recent and hackish, and really require an understanding of what's going in underneath. Note that this problem will probably not affect your understanding of Scala at first, but you'll run up against it when you start writing real programs that use generic types, as there are things you'll try to do that just won't work, and you won't know why unless/until you understand the limitations forced by type erasure.
Sooner or later you'll also run up against issues related to another Java misfeature, which is the division of types into objects (classes) vs. primitive types (ints, floats, booleans) -- and in particular, the fact that primitive types aren't part of the object system. Scala actually does an awesome job hiding this from you, but it can be helpful to know about what Java is doing in certain corner cases that otherwise may be tricky -- particularly involving generic types, largely because of the type-erasure brokenness described in #1. (Type erasure also results in a major performance hit when using arrays, hash tables, and similar generic types over primitives; this is one area where knowing Java will help a lot.)
Misfeature #3 -- arrays are also handled specially and non-orthogonally in Java. Scala's hiding of this is not quite as seamless as for primitives, but much better than for type erasure. The hiding mechanism sometimes gets exposed (e.g. the ArrayWrapper type), which may occasionally lead to issues -- but the biggest problem in practice, not surprisingly, is again with generic types.
Scala class parameters and the way that Scala handles class constructors. In this case, Java isn't broken. Arguably, Scala isn't either, but the way it handles class constructors is rather unusual, and in practice I've had a hard time understanding it. I've only really been able to make sense of Scala's behavior by figuring out how the relevant Scala code gets translated into Java (or more correctly, into compiled Java), and then reasoning over what Java would do. Since I assume that Ruby works much like Java in this respect, I don't think you'll run into too many problems, although you might have to do the same mental conversion.
I/O. This is actually a library issue rather than a language issue. In most cases, Scala provides its own libraries, but Scala doesn't really have an I/O library, so you pretty much have no choice but to use Java's I/O library directly. For a Python or Ruby programmer, this transition is a bit painful, since Java's I/O library is big and bulky, and not terribly easy to use for doing simple tasks, e.g. iterating over all the lines in a file.
Note that besides I/O, you also need to use Java libraries directly for other cases where you interact with the OS or related tasks, e.g. working with times and dates or getting environment variables, but usually this isn't too hard to figure out. The other main Java libraries you might need to use are
Subprocess invocation, also somewhat big and bulky
Networking -- but this is always somewhat painful
Reflection, i.e. dynamically examining the methods and/or fields on a class, or dynamically invoking a method by name when the name isn't known at compile time. This is somewhat esoteric stuff that most people don't need to deal with. Apparently Scala 2.10 will have its own reflection library, but currently you have to use the Java reflection API's, which means you need to know a fair amount about how Scala gets converted to Java. (Thankfully, there's a -print option to the Scala compiler to show exactly how this conversion happens.)
Re. point 1. Not being familiar with Java the language is not necessarily a problem. 3rd party libraries integrate largely seamlessly into Scala. However some awareness of the differences in collections may be good (e.g. a Scala list is not a traditional Java list, and APIs may expect the latter).
The Java-related skills that carry over are related to Java the platform. i.e. you're still working with a JVM that performs class-loading, garbage collection, JIT compilation etc. So experience in this is useful. But not at all necessary.
Note that Scala 2.8 is imminent, and there are some incompatible changes wrt. 2.7. So any book etc. you buy should be aware of such differences.
This is another late answer, having recently come to Scala myself, but I can answer 1, 3, and 4:
1) I ported a large, multifaceted F# project to Scala without any use of either Java or .NET libraries. So for many projects, one can stick totally to native Scala. Java ecosystem knowledge would be a plus, but it can be acquired gradually during and after learning Scala.
3) Programming in Scala is not only great for learning Scala, it's one of the few truly readable computer books on any language. And it's handy for later reference.
4) I've used close to a dozen different programming languages, from assembly languages to Prolog, but Scala and F# are the two most fun programming languages I've ever used -- by a wide margin. (Scala and F# are very similar, an example of "convergent evolution" in two different ecosystems -- JVM and .NET.)
-Neil
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.