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. :)
I am struggling to see the real-world benefits of loosely coupled code. Why spend so much effort making something flexible to work with a variety of other objects? If you know what you need to achieve, why not code specifically for that purpose?
To me, this is similar to creating untyped variables: it makes it very flexible, but opens itself to problems because perhaps an unexpected value is passed in. It also makes it harder to read, because you do not explicitly know what is being passed in.
Yet I feel like strongly typed is encouraged, but loosely coupling is bad.
EDIT: I feel either my interpretation of loose coupling is off or others are reading it the wrong way.
Strong coupling to me is when a class references a concrete instance of another class. Loose coupling is when a class references an interface that another class can implement.
My question then is why not specifically call a concrete instance/definition of a class? I analogize that to specifically defining the variable type you need.
I've been doing some reading on Dependency Injection, and they seem to make it out as fact that loose coupling better design.
First of all, you're comparing apples to oranges, so let me try to explain this from two perspectives. Typing refers to how operations on values/variables are performed and if they are allowed. Coupling, as opposed to cohesion, refers to the architecture of a piece (or several pieces) of software. The two aren't directly related at all.
Strong vs Weak Typing
A strongly typed language is (usually) a good thing because behavior is well defined. Take these two examples, from Wikipedia:
Weak typing:
a = 2
b = '2'
concatenate(a, b) # Returns '22'
add(a, b) # Returns 4
The above can be slightly confusing and not-so-well-defined because some languages may use the ASCII (maybe hex, maybe octal, etc) numerical values for addition or concatenation, so there's a lot of room open for mistakes. Also, it's hard to see if a is originally an integer or a string (this may be important, but the language doesn't really care).
Strongly typed:
a = 2
b = '2'
#concatenate(a, b) # Type Error
#add(a, b) # Type Error
concatenate(str(a), b) # Returns '22'
add(a, int(b)) # Returns 4
As you can see here, everything is more explicit, you know what variables are and also when you're changing the types of any variables.
Wikipedia says:
The advantage claimed of weak typing
is that it requires less effort on the
part of the programmer than, because
the compiler or interpreter implicitly
performs certain kinds of conversions.
However, one claimed disadvantage is
that weakly typed programming systems
catch fewer errors at compile time and
some of these might still remain after
testing has been completed. Two
commonly used languages that support
many kinds of implicit conversion are
C and C++, and it is sometimes claimed
that these are weakly typed languages.
However, others argue that these
languages place enough restrictions on
how operands of different types can be
mixed, that the two should be regarded
as strongly typed languages.
Strong vs weak typing both have their advantages and disadvantages and neither is good or bad. It's important to understand the differences and similarities.
Loose vs Tight Coupling
Straight from Wikipedia:
In computer science, coupling or
dependency is the degree to which each
program module relies on each one of
the other modules.
Coupling is usually contrasted with
cohesion. Low coupling often
correlates with high cohesion, and
vice versa. The software quality
metrics of coupling and cohesion were
invented by Larry Constantine, an
original developer of Structured
Design who was also an early proponent
of these concepts (see also SSADM).
Low coupling is often a sign of a
well-structured computer system and a
good design, and when combined with
high cohesion, supports the general
goals of high readability and
maintainability.
In short, low coupling is a sign of very tight, readable and maintainable code. High coupling is preferred when dealing with massive APIs or large projects where different parts interact to form a whole. Neither is good or bad. Some projects should be tightly coupled, i.e. an embedded operating system. Others should be loosely coupled, i.e. a website CMS.
Hopefully I've shed some light here :)
The question is right to point out that weak/dynamic typing is indeed a logical extension of the concept of loose coupling, and it is inconsistent for programmers to favor one but not the other.
Loose coupling has become something of a buzzword, with many programmers unnecessarily implementing interfaces and dependency injection patterns -- or, more often than not, their own garbled versions of these patterns -- based on the possibility of some amorphous future change in requirements. There is no hiding the fact that this introduces extra complexity and makes code less maintainable for future developers. The only benefit is if this anticipatory loose coupling happens to make a future change in requirements easier to implement, or promote code reuse. Often, however, requirements changes involve enough layers of the system, from UI down to storage, that the loose coupling doesn't improve the robustness of the design at all, and makes certain types of trivial changes more tedious.
You're right that loose coupling is almost universally considered "good" in programming. To understand why, let's look at one definition of tight coupling:
You say that A is tightly coupled to B if A must change just because B changed.
This is a scale that goes from "completely decoupled" (even if B disappeared, A would stay the same) to "loosely coupled" (certain changes to B might affect A, but most evolutionary changes wouldn't), to "very tightly coupled" (most changes to B would deeply affect A).
In OOP we use a lot of techniques to get less coupling - for example, encapsulation helps decouple client code from the internal details of a class. Also, if you depend on an interface then you don't generally have to worry as much about changes to concrete classes that implement the interface.
On a side note, you're right that typing and coupling are related. In particular, stronger and more static typing tend to increase coupling. For example, in dynamic languages you can sometimes substitute a string for an array, based on the notion that a string can be seen as an array of characters. In Java you can't, because arrays and strings are unrelated. This means that if B used to return an array and now returns a string, it's guaranteed to break its clients (just one simple contrived example, but you can come up with many more that are both more complex and more compelling). So, stronger typing and more static typing are both trade-offs. While stronger typing is generally considered good, favouring static versus dynamic typing is largely a matter of context and personal tastes: try setting up a debate between Python programmers and Java programmers if you want a good fight.
So finally we can go back to your original question: why is loose coupling generally considered good? Because of unforeseen changes. When you write the system, you cannot possibly know which directions it will eventually evolve in two months, or maybe two hours. This happens both because requirements change over time, and because you don't generally understand the system completely until after you've written it. If your entire system is very tightly coupled (a situation that's sometimes referred to as "the Big Ball of Mud"), then any change in every part of the system will eventually ripple through every other part of the system (the definition of "very tight coupling"). This makes for very inflexible systems that eventually crystallize into a rigid, unmaintanable blob. If you had 100% foresight the moment you start working on a system, then you wouldn't need to decouple.
On the other hand, as you observe, decoupling has a cost because it adds complexity. Simpler systems are easier to change, so the challenge for a programmer is striking a balance between simple and flexible. Tight coupling often (not always) makes a system simpler at the cost of making it more rigid. Most developers underestimate future needs for changes, so the common heuristic is to make the system less coupled than you're tempted to, as long as this doesn't make it overly complex.
Strongly typed is good because it prevents hard to find bugs by throwing compile-time errors rather than run-time errors.
Tightly coupled code is bad because when you think you "know what you need to achieve", you are often wrong, or you don't know everything you need to know yet.
i.e. you might later find out that something you've already done could be used in another part of your code. Then maybe you decide to tightly couple 2 different versions of the same code. Then later you have to make a slight change in a business rule and you have to alter 2 different sets of tightly coupled code, and maybe you will get them both correct, which at best will take you twice as long... or at worst you will introduce a bug in one, but not in the other, and it goes undetected for a while, and then you find yourself in a real pickle.
Or maybe your business is growing much faster than you expected, and you need to offload some database components to a load-balancing system, so now you have to re-engineer everything that is tightly coupled to the existing database system to use the new system.
In a nutshell, loose coupling makes for software that is much easier to scale, maintain, and adapt to ever-changing conditions and requirements.
EDIT: I feel either my interpretation
of loose coupling is off or others are
reading it the wrong way. Strong
coupling to me is when a class
references a concrete instance of
another class. Loose coupling is when
a class references an interface that
another class can implement.
My question then is why not
specifically call a concrete
instance/definition of a class? I
analogize that to specifically
defining the variable type you need.
I've been doing some reading on
Dependency Injection, and they seem to
make it out as fact that loose
coupling better design.
I'm not really sure what your confusion is here. Let's say for instance that you have an application that makes heavy use of a database. You have 100 different parts of your application that need to make database queries. Now, you could use MySQL++ in 100 different locations, or you can create a separate interface that calls MySQL++, and reference that interface in 100 different places.
Now your customer says that he wants to use SQL Server instead of MySQL.
Which scenario do you think is going to be easier to adapt? Rewriting the code in 100 different places, or rewriting the code in 1 place?
Okay... now you say that maybe rewriting it in 100 different places isn't THAT bad.
So... now your customer says that he needs to use MySQL in some locations, and SQL Server in other locations, and Oracle in yet other locations.
Now what do you do?
In a loosely coupled world, you can have 3 separate database components that all share the same interface with different implementations. In a tightly coupled world, you'd have 100 sets of switch statements strewn with 3 different levels of complexity.
If you know what you need to achieve, why not code specifically for that purpose.
Short answer: You almost never know exactly what you need to achieve. Requirements change, and if your code is loosely coupled in the first place, it will be less of a nightmare to adapt.
Yet I feel like strongly typed is encouraged, but loosely coupling is bad.
I don't think it is fair to say that strong typing is good or encouraged. Certainly lots of people prefer strongly typed languages because it comes with compile-time checking. But plenty of people would say that weak typing is good. It sounds like since you've heard "strong" is good, how can "loose" be good too. The merits of a language's typing system isn't even in the realm of a similar concept as class design.
Side note: don't confuse strong and static typing
strong typing will help reduce errors while typically aiding performance. the more information the code-generation tools can gather about acceptable value ranges for variables, the more these tools can do to generate fast code.
when combined with type inference and feature's like traits (perl6 and others) or type classes (haskell), strongly typed code can continue to be compact and elegant.
I think that tight/loose coupling (to me: Interface declaration and assignment of an object instance) is related to the Liskov Principle. Using loose coupling enables some of the advantages of the Liskov Principle.
However, as soon as instanceof, cast or copying operations are executed, the usage of loose coupling starts being questionable. Furthermore, for local variables withing a method or block, it is non-sense.
If any modification done in our function, which is in a derived class, will change the code in the base abstract class, then this shows the full dependency and it means this is tight coupled.
If we don't write or recompile the code again then it showes the less dependency, hence it is loose coupled.
What do you lose in practice when you choose a statically-typed language such as Scala (or F#, Haskell, C#) instead of dynamically-typed ones like Ruby, Python, Clojure, Groovy (which have macros or runtime metaprogramming capabilities)? Please consider best statically-typed languages and best (in your opinion) dynamically-typed languages, not the worst ones.
Answers Summary:
Key advantages of dynamic languages like Ruby over statically-typed language like Scala IMHO are:
Quick edit-run cycle (does JavaRebel reduces the gap?)
Currently community of Scala/Lift is much smaller then of Ruby/Rails or Python/Django
Possible to modify type definitions (though motivation or need for that is not very clear)
In principle, you give up being able to ignore what type you're using when it is not clear (in the static context) what the right thing to do is, and that's about it.
Since complex type-checking can be rather time-consuming, you also probably are forced to give up fast on-line metaprogramming.
In practice, with Scala, you give up very little else--and nothing that I particularly care about. You can't inject new methods, but you can compile and run new code. You do have to specify types in function arguments (and the return type with recursive functions), which is slightly annoying if you never make type errors yourself. Since it compiles each command, the Scala REPL isn't as snappy as e.g. the Python shell. And since it uses Java reflection mechanisms, you don't have quite the ease of online inspection that you do with e.g. Python (not without building your own inspection library, anyway).
The choice of which static or dynamic language is more significant than the static/dynamic choice itself. Some dynamic languages have good performance and good tools. Some static languages can be concise, expressive, and incremental. Some languages have few of these qualities, but do have large libraries of proven code.
Dynamic languages tend to have much more flexible type systems. For example, Python lets you inject a new method into an existing classes, or even into a single object.
Many (not all) static languages lack the facility to construct complex literals. For instance, languages like C# and Java cannot easily mimic the following JavaScript { 'request':{'type':'GET', 'path':mypath}, 'oncomplete':function(response) { alert(response.result) } }.
Dynamic languages have very fluid semantics. Python allows import statements, function definitions and class definitions to appear inside functions and if statements.
eval is a staple of most dynamic languages and few static languages.
Higher order programming is easier (in my subjective opinion) in dynamic languages than static languages, due to the awkwardness of having to fully specify the types of function parameters.
This is particulary so with recursive HOP constructs where the type system can really get in the way.
Dynamic language users don't have to deal with covariance and contravariance.
Generic programming comes practically free in dynamic languages.
I'm not sure if you lose anything but simplicity. Static type systems are an additional burden to learn.
I suppose you usually also lose eval, but I never use it, even in dynamic languages.
I find the issue is much more about everything else when it comes to choosing which language to use for a given task. Tooling, culture, libraries are all much more interesting than typing when it comes to solving a problem with a language.
Programming language research, on the other hand, is completely different. :)
Some criticism of Scala has been expressed by Steve Yegge here and here, and by Guido van Rossum, who mainly attacked Scala's type system complexity. They clearly aren't "Scala programmers" though. On the other hand, here's some praise from James Strachan.
My 2 cents...
IMO (strong) statically-typed languages might reduce the amount of necessary testing code, because some of that work will be done by the compiler. On the other hand, if the compiling step is relatively long, it makes it more difficult to do "incremental-style" programming, which in the real life might result in error-prone code that was only tested to pass the compiler.
On the other hand, dynamically-typed languages feel like there is less threshold to change things, that might reduce the responding time from the point of bug-fixing and improvement, and as a result might provide a smoother curve during application development: handling constant flow of small changes is easier/less risky than handling changes which are coming in bug chunks.
For example, for the project where the design is very unclear and is supposed to change often, it might have been easier to use dynamic language than a static one, if it helps reduce interdependencies between different parts. (I don't insist on that one though:) )
I think Scala sits somewhere in between (e.g. you don't have to explicitly specify types of the variables, which might ease up code maintenance in comparison with e.g. C++, but if you end up with the wrong assumption about types, the compiler will remind about it, unlike in PHP where you can write whatever and if you don't have good tests covering the functionality, you are doomed to find it out when everything is live and bleeding). Might be terribly wrong of course :)
In my opinion, the difference between the static and dynamic typing comes down to the style of coding. Although there is structural types in Scala, most of the time the programmer is thinking in terms of the type of the object including cool gadgets like trait. On the other hand, I think Python/Javascript/Ruby programmers think in terms of prototype of the object (list of methods and properties), which is slightly different from types.
For example, suppose there's a family of classes called Vehicle whose subclasses include Plane, Train, and Automobile; and another family of classes called Animal whose subclasses include Cat, Dog, and Horse. A Scala programmer would probably create a trait called Transportation or something which has
def ride: SomeResult
def ride(rider: Someone): SomeResult
as a member, so she can handle both Train and Horse as a means of transportation. A Python programmer would just pass the train object without additional code. At the run time the language figures out that the object supports ride.
The fact that the method invocations are resolved at the runtime allows languages like Python and Ruby to have libraries that redefines the meaning of properties or methods. A good example of that is O/R mapping or XML data binding, in which undefined property name is interpreted to be the field name in a table/XML type. I think this is what people mean by "flexibility."
In my very limited experience of using dynamic languages, I think it's faster coding in them as long as you don't make mistakes. And probably as you or your coworkers get good at coding in dynamic language, they would make less mistakes or start writing more unit tests (good luck). In my limited experience, it took me very long to find simple errors in dynamic languages that Scala can catch in a second. Also having all types at compile time makes refactoring easier.
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
Does Google's Golang address the problems with languages addressed in Paul's Graham's post 'Why Arc isn't Especially Object Oriented'?
My initial feeling towards this is "It is too soon to tell"
1) Object-oriented programming is exciting if you have a
statically-typed language without
lexical closures or macros. To some
degree, it offers a way around these
limitations. (See Greenspun's Tenth
Rule.)
Go supports Function literals (see docs) which if I am reading this correctly allow you to pass functions as params, whether defined elsewhere or created ad-hoc.
2) Object-oriented programming is popular in big companies, because it
suits the way they write software. At
big companies, software tends to be
written by large (and frequently
changing) teams of mediocre
programmers. Object-oriented
programming imposes a discipline on
these programmers that prevents any
one of them from doing too much
damage. The price is that the
resulting code is bloated with
protocols and full of duplication.
This is not too high a price for big
companies, because their software is
probably going to be bloated and full
of duplication anyway.
This point is far to subjective to answer.
3) Object-oriented programming generates a lot of what looks like
work. Back in the days of fanfold,
there was a type of programmer who
would only put five or ten lines of
code on a page, preceded by twenty
lines of elaborately formatted
comments. Object-oriented programming
is like crack for these people: it
lets you incorporate all this
scaffolding right into your source
code. Something that a Lisp hacker
might handle by pushing a symbol onto
a list becomes a whole file of classes
and methods. So it is a good tool if
you want to convince yourself, or
someone else, that you are doing a lot
of work.
Since go isn't a truly object oriented language, you can probably solve the problem in whatever fashon you are comfortable with.
4) If a language is itself an object-oriented program, it can be
extended by users. Well, maybe. Or
maybe you can do even better by
offering the sub-concepts of
object-oriented programming a la
carte. Overloading, for example, is
not intrinsically tied to classes.
We'll see.
Go seems to have an interesting approach to objects, where you are not required to worry / develop large object trees. It looks like the tools are present in the language to structure your data in an object oriented fashion without locking you in to a pure object oriented environment.
5) Object-oriented abstractions map neatly onto the domains of certain
specific kinds of programs, like
simulations and CAD systems.
...
Paul has some interesting points, in general, I've read a lot of his musings. In this matter, we disagree. He's a lisp nut, and a crappy program nut. He seems to pawn off hard to understand programs as the work of great programmers. Yes, I realise it's more nuanced than that, but it really boils down to just that. At the end of the day, either your code is easy work with, or it's not. And some programmers, programmers that Paul would deem great, will be able to put up with more crap than others and still be able to make heads or tails of what the code intends. It's a skill, but most assuredly not the only one a good programmer needs.
Speaking of Arc, it sucks, and unless I'm mistaken even people in the Lisp community think so -- my point here being that even smart people make mistakes.
Again, Paul is a smart guy, but his entire approach in this particular piece is off the mark it seems.
Wait up, though, is Go really object-oriented? It seems entirely agnostic on that front. You can use OOP or FP or Imperative programming within Go. I mean, prolog-style "programming" would be a stretch, but otherwise...
In fact, I'd argue that Go resembles scala in this respect: there's some object paradigms lying around, and yet, there are also lambdas and typecasing lying around.