Only replying partially as I don't want to repeat myself.
Ok, then let's just ignore continuations as they are somehow available in both languages although the Scala one feels a bit more officially endorsed to me.
> def upcase(s: String): UppercasedString
Even with that type signature of course the compiler can not check that for input "a" the output will be "A". Your code could have a bug and upcase "a" to "B" (Off-by-one errors are quite common) and your compiler would be perfectly happy. That is the whole point why unit test are more valuable than compiler type checks: checking specific code behavior and not only static types.
I am sure there a lot of very smart people with great programming skills and without a degree. However at least in Germany I see another problem: Almost every job ad for a programming positition starts with "Computer science or related degree required". Without a degree you are just filtered out by the Human Resources Department that doesn't know anything about programming at all. They are just checking formalities and doing buzzword matching. You won't even get to an interview or get an opportunity to prove your skills. :-(
It seems we have different definitions of what type inference, higher order functions and Turing completeness means. :-) Regarding coroutines in Java: I don't know if libraries using native continuation mechanisms or bytecode manipulations prove that Java (the language) has continuation support. :-) I don't have anything against Scala. In my very first message I even said that I see the odds for Scala winning higher than the odds for Clojure winning - because I already see some enterprise adoption of Scala. Although I see the probability of Scala winning quite low. As you noticed with Java 8 Java is already borrowing a lot of useful things from Scala. I am sure conservative corporate decision makers will see less and less reasons to switch to Scala as time passes by. Also I don't think that Java sucks. I was just making a point from personal productivity experience. Your experience might differ from that.
If I have a function:
def upcase(s: String): String...
The compiler with its static type system can tell me if e. g. I am trying to call the upcase function with an Int argument. But in my experience something like that just does not happen very often. Most programmers are not so stupid that they try to fit a square peg in a round hole. ;-)
A unit test can check if the returned string is really the upcase version of the input parameter. Plus if the programmer would really assume that he could upcase an Int it would just as well give the feedback that his assumption was wrong-like the compiler.
I don't want to sidetrack that thread as it was about Clojure. Just a quick correction: Java has no type inference, higher order functions, coroutines, implicits (it has some standard implicit conversions but not implicit conversions that can be added by the user) and no Turing complete type system.
And of course: Using a statically typed language is no excuse to not write unit tests. Unit tests serve as a safety net checking if the behavior of the implemented unit is (and stays) correct. As a side effect this will also find all type errors a compiler will find. I have programmed a lot in Java and also in dynamic programming languages and in my opinion type errors just don't happen often enough to justify the additional amount of work and complexity that comes with static type systems. However I'd agree that if you want to get the best possible performance you probably need a statically typed language as the compiler can then optimize the generated code better.
Well, with "Scala with its everything and the kitchen sink feature set" I mean that Scala incorporates almost all language features one can think of for a statically compiled programming language (I don't think it makes sense to distinguish if a certain feature is provided by the language itself or a library as in Scala that distinction is fuzzy):
- type inference
- classes
- interfaces (sort of: traits)
- methods
- variables (var)
- immutable values (val)
- higher order functions
- singletons
- functional programming: map, flatMap, reduce/fold, ...
- actors
- coroutines (I think there was a compiler plugin for that)
- implicits
- powerful type parameters
- Futures
- it even has a turing complete type system
That is good and bad. Good: you can probably find good use for every feature Scala has. Bad: On a sufficiently big project with one or more extra clever developers most probably every feature will be used and that will make it extra hard to understand for normal software developers that have to maintain it for long years after the original extra smart developer already left the company. See it a bit like that: On a hard to understand scale with 1 being easy to understand und 10 being extremely hard to understand Java projects can go from 1 to 6 and Scala projects can go from 1 to 10.
Personally I like simple languages more. And I don't need a compiler to catch errors that a unit test would also catch.
I like Clojure but I currently don't see any enterprise adoption of it. I see some startups and some students and hobbyists using it. Interestingly Scala seems to get some traction in enterprises here in Germany. I think enterprises love a lot of language features, complexity, security. Maybe Scala with its everything and the kitchen sink feature set, static type system, Java-like syntax and last but not least OOP appeals more to the "manager-friendly conservatism" as the blog author says.
I like the submitted blog post although the blog post does not really try to explain why pigs get fat when fed milk, corn or sugar. Actually I am not a pig specialist but I heard a lot of times that the pig body chemistry works quite similarly to human body chemistry. So I will try to explain why people get fat when fed milk, corn, sugar.
The central mechanism to understand is insulin. Quoting http://en.wikipedia.org/wiki/Insulin:
"Insulin is a peptide hormone, produced by beta cells of the pancreas, and is central to regulating carbohydrate and fat metabolism in the body. Insulin causes cells in the liver, skeletal muscles, and fat tissue to absorb glucose from the blood. In the liver and skeletal muscles, glucose is stored as glycogen, and in fat cells (adipocytes) it is stored as triglycerides.
Insulin stops the use of fat as an energy source by inhibiting the release of glucagon. ... Porcine insulin is especially close to the human version."
That means whenever you consume a meal that produces a high insulin response your body stops burning fat immediately and in addition stores all the fat in the meal you just consumed in the form of fat. That is what makes pigs and people fat (in addition to another phenomenom which makes you hungry again much quicker).
You can index food by the insulin reaction it causes. This index is called insulin index. Different food has a different index value. See e. g. http://en.wikipedia.org/wiki/Insulin_index Unfortunately there are no really detailled insulin index tables as there are for the glycemic index. The glycemic index measures how fast your blood sugar will rise after consuming a specific food. In most cases however high glycemic index will also mean high insulin index and you can substitute the missing insulin index data by using the glycemic index data with one exception: milk. Milk although having a low glycemic index (caused by milk sugar/lactose) has a high insulin index! See e. g. http://www.marksdailyapple.com/dairy-insulin/
Corn and Sugar have high glycemic (and thus insulin) index.
Milk protein causes an abnormal high insulin index.
There are a lot of diets that can be explained by optimizing mostly this insulin effect: Atkins, Low Carb, Sears/Zone, Paleo. Although I am not an expert in any of them. All I can say is that by only taking care for what I ate I lost 60 pounds over the course of 1.5 years (I used a similar german diet called "Schlank im Schlaf"). The interesting thing to me is: When I am eating food with a low insulin effect I stay satisfied for much longer. When I eat food with high insulin effect I get hungry again in 1-2 hours. It feels almost like drinking salt water against thirst...
Ok, then let's just ignore continuations as they are somehow available in both languages although the Scala one feels a bit more officially endorsed to me.
> def upcase(s: String): UppercasedString
Even with that type signature of course the compiler can not check that for input "a" the output will be "A". Your code could have a bug and upcase "a" to "B" (Off-by-one errors are quite common) and your compiler would be perfectly happy. That is the whole point why unit test are more valuable than compiler type checks: checking specific code behavior and not only static types.