Bitcoin isn't a currency by most textbook definitions. As Bitcoin is now, it will never replace fiat currencies because it is not a stable store of value (among other reasons). For now, Bitcoin is just another way to send fiat and something of an investment.
So Bitcoin fanatics who believe Bitcoin will replace fiat are wrong - unless they're willing to accept major changes to the system that go against their usual beliefs. (And even then, I doubt many governments would sit idly by, for good reason.) But for practical people who don't want to deal with buyer fraud, exorbitant fees, and lack-of-privacy, Bitcoin is great.
Buffett may be a killjoy and trying to preserve the current system which tends to benefit the wealthy and well-connected. I'd guess he probably has a lot of stake in that. But he is correct for now.
That was Charlie Munger, but Bitcoin fans tried to pin it on Buffett too, because he is a billionaire and happened to be in the same room as Munger at the time.
I suppose I can use my limbs to buy illegal drugs. If only they were virtual and could be transferred internationally with little or no fees - all done more easily than sending an email.
"Not involved with Bitcoin" leaves the door open to having been involved with Bitcoin in the past. I wonder if he was trying to deny past involvement with Bitcoin but worded it poorly, or if he was merely being clever in his wording, like a politician. Perhaps we'll find out.
Drinking alcohol has many health benefits. Even a beer a day, something that 'common sense' would lead you to think was unhealthy, demonstrates to be good for your overall health. And eating processed foods while smoking and drinking would likely be more detrimental than eating well, while smoking and drinking. The hard part is determining what eating well is.
> The hard part is determining what eating well is.
Eating well in seven words: "Eat food. Not too much. Mostly plants.". ...where "food" is defined more or less as: "as little processed as available, mostly plant-based food in as close to it's natural form as possible".
But that's kinda my point, we don't know that, anymore than we know an all meat diet is okay for us. Most of the "science" around nutrition would only be acceptable in theoretical physics and paleontology. We're starting to see nutrition studied a little better, but it's the past half decade where we seeing actual science around nutrition, and we'll need at least a couple hundred years before we can say with certainty what is best for human longevity. Until then, we're guessing.
We think cholesterol is bad in excess, and conventional wisdom dictates, that since eggs are high in cholesterol, that eggs should be avoided. Except, the body doesn't metabolize much if any dietary cholesterol, and instead it's the cholesterol that you synthesize that's dangerous. There are some interesting observations with high fat dairy, which actually reduces cholesterol instead of increasing it. Again, conventional wisdom is demonstrating itself to not be correct. Calories in, calories out sounds good on paper, eat less, and you will lose weight. But this also is proven incorrect over and over. I have seen this in studies, and witnessed it first hand with a girl I was living with who was trying to lose weight. She would eat a fifth of the calories that I would eat, and would gain weight, where I would chow down on meat, fats, and green beans and lose weight. What does appear to be apparent is it's easier to maintain a healthy weight if you never gain weight in the first place; essentially your body attempts to return to it's heaviest when calories are available. Many new studies show that the war on salt is based in bad science, and it may not have as much of an impact as we thought. So is a little haiku the answer? I don't know what the right answer is, but I know it isn't that simple.
People keep yapping on about the health benefits of alcohol, red wine in particular, but I'd be impressed if you could find me a single drinker who only ever drinks that one unit of alcohol a day. At that point it very quickly stops being beneficial to your health.
I'm not sure I understand. Are you saying that light drinkers inevitably become heavy drinkers, and thus the benefits of light drinking are irrelevant?
Where do you live? I'm fascinated by your use of the word 'drinker', as if people who ever drink any alcohol aren't in the vast majority. Where I live (UK), pretty much everyone drinks alcohol at least weekly. Most people drink socially, within healthy boundaries (3-4 units per day is the current guideline), occasionally overindulging, often detoxing for a period of time. Whilst there are social problems caused by alcohol abuse, there is no way that in our society we would 'look down' on each other for consuming alcohol, nor define anyone as a 'drinker'. In my whole life I've met 2 people who are not 'drinkers', and one of them has a very rare drink from time-to-time.
As to your point, yes, of course hardly anyone who ever drinks never drinks more than one unit of alcohol per day; that is practically impossible. But many will drink on average, no more than one unit per day.
What's wrong with drinking a small amount of alcohol? There is a small amount of evidence that it is good for you in small amounts* and it is [or can be] a social experience. You can meet a lot of interesting people in pubs. Beer and wine contain antioxidants.
I really really enjoy a beer or two now and then, and I'm not going to feel the least bit guilty about it.
I also happened to meet my (now) husband in a pub.
I've not used Scala since ~March 2013. I sure hope compilation times have improved since then. That was one of the main reasons I stopped using Scala. Scala is one of the easiest languages to read and write once you master it, but the compilation times were frustrating. Excited to try out 2.11 later tonight.
> Scala is one of the easiest languages to read and write once you master it
I beg to differ with this. Any languages gets easy to read & write once you master it. After having finished the Scala course and spending considerable time trying to get grips with the language, I was still totally clueless about a majority of the features.
Although I really liked how powerful Scala it is even if you grok 30% of its features but the learning curve required to master it is extremely steep. Prof Odersky has been quite vocal about the feature bloat and lets hope the future releases are more conservative in that sense.
Before Scala, I have "mastered" until now Ruby, Python, Perl, PHP, Java, C# and Javascript as in I used them for real projects in production for at least 1.5 years each and whenever I learn a new language, I always go in depth. And I also played with half a dozen others.
Scala is the language that helps you write better code. In the kinds of projects that I've been working for the last 3 years, requiring parallelism, efficient usage of resources, asynchronicity, redundancy, scalability, throughput, reliability on the whole, I can honestly say that none of the other languages could do a better job.
On features, it actually doesn't have many, but the features that it does have are powerful enough that you can have bigger abstractions. For example, "async" is not a language feature such as in C#, but a library. Of course, there's much to learn, especially concepts that have been borrowed from Haskell or other FP languages with a Scala-ish twist, like persistent data-structures, type-classes, futures/promises, iteratees and in general, what's the deal with monads, monoids and applicative functors. In training beginners explaining these concepts was the most difficult part of the training, trumping all others considerations, starting from the basics like "don't use vars".
Scala is difficult because it's a functional programming language, beautifully blended with OOP, being in fact a better OOP language than most mainstream OOP languages. Learning FP and then learning OOP in a way not exposed by languages like Java and then learning what good design looks like, grokking a lot of FP design patterns in the process, that can be very overwhelming. For any developer that is not familiar with a good FP language already, or that thinks OOP is what Java gives you, the transition can be pretty painful. On the other hand - I'm of the opinion that if learning a new language is not painful, then it doesn't give you anything of value, so learning it is pretty useless.
2. subscribe to the scala-user mailing list and ask any questions you may have - some developers there are very advanced, so don't get intimidated by the topics, as beginners' questions are very welcome
I got started with "Scala for the Impatient" and I like its style. You can still get about one third of the book from TypeSafe's website, which is enough to get the ball rolling. It's written for Scala 2.9 so it doesn't have Futures in it, plus you should ignore the stuff about actors in later chapters (actors from the standard library are deprecated, Akka actors have been the norm for some time - and at first you should ignore actors completely, since that's a big topic). But that's OK. In case you'd prefer another book, make sure to not read anything published before 2010 as (IMHO) everything published before 2010 is awful.
Since I wrote that article a couple of newer books happened, that I haven't read, like "Scala in Action" or "Atomic Scala" and thus cannot recommend, but I've heard good things about, so ask others or read reviews, etc...
There's also an advanced book called "Functional Programming in Scala", by Paul Chiusano and Rúnar Bjarnason, I've read about 8 chapters from it and it's a really, really good book on FP design & concepts. However it's a hard read, because while the language is approachable and doesn't assume much Scala knowledge, it's the kind of book that's designed around mind-bending (SICP-style) exercises - it takes me about 1 week to get through a chapter and right now I don't have time for the rest, but with each chapter my knowledge expands :-)
If you like an IDE, IntelliJ IDEA 13 for Scala is everything you'd expect out of an IDE, but as I've said in my blog post, when I'm learning a new language I don't want to bother with learning a new toolset too, so I start with a comfortable plain-text editor and work from there.
When you get stuck, I must emphasize on nr.2 - ask questions on scala-user - beginners are always welcome.
Scala for the Impatient (you can get part of the book as a free pdf from Typesafe). Although not designed for learning the language the O'Reilly Scala Cookbook is also very good.
After several months playing with Scala I felt much the same, with other languages I use regularly such as C# or Ruby I could look into any libraries I use and understand the code, make changes if required etc.
With Scala I felt like the level of understanding/mastery required to truly feel at home was significantly higher than I've encountered before. Looking into some of the code in the wild gave me instant headaches. Developing in a language where you can be presented with code and draw a complete blank is not a reassuring experience.
It's still a beast id like to tame, but not when I have work to get done anytime soon.
If learning is not painful, then you're not learning.
How long did it take you to go from zero to being able to get stuff done, when you started to learn programming?
Complaining that Scala is unlike C# or Ruby doesn't make sense, since if you want C# or Ruby, might as well stick with C# or Ruby. And what came first anyway? Guess you started out with C#, since it's more popular in universities, right? Well, when you got into Ruby, where you able to understand all the meta-programming going on in like all the popular libraries?
Speaking of which, after working a lot with Ruby, I still have problems in grokking other people's code when meta-programming is involved, since it's almost always a fragile design that's stitched together with spit and glue and I can never wrap my head around all the things that could happen in the right context. This is very, very unlike my experience with Scala. Yes, it's difficult to learn because many new concepts are involved, but once passed that learning curve, everything becomes much clearer instead of going down a rabbit whole.
There's definitely parts of any language I feel I'll probably never understand, at least under the requirements of what I need to get done in my day to day work. With Scala though that percentage was much higher, and the code that I didn't understand felt much more daunting.
I went into Scala wanting to use it for a new project, expecting to pick it up like I had other languages but unfortunately I was unprepared for the task/sheer scale and had to switch back to a language I knew well.
Whenever I have time I'll continue to study it fully aware of the rewards, but with a better understanding of the time required to get to grips with it.
Paul Philips is an awesome developer, contributed a lot to Scala and he did quit because he thought that Scala was headed in the wrong direction. These are the facts. On the other hand the kind of problems he described are problems that happen in every mainstream language, either due to the pressure of keeping it stable and of backwards compatibility (you know, real world concerns) or because current languages aren't equipped to handle it or because of pragmatic reasons with which he doesn't agree with. And in fact, speaking of "academic papers", some of the problems he cares about can only be fixed for real in languages with dependent types (ever heard of one?).
As for "fixing bugs and streamlining the libraries", if you bothered reading the release notes on Scala 2.11-RC1 before commenting, you would know that this release is exactly about fixing bugs, modularizing the compiler, improved compilation times, streamlining the libraries, eliminating deprecated stuff and so on. By all accounts, it will be an awesome release even though it doesn't add features to the language. It won't solve all of Paul's concerns of course, but there are people that actually care and work on these problems.
But then, whenever that happens, people start complaining that Scala breaks backwards compatibility too often. Apparently you can't please everybody. And btw, the Scala core devs also have plans for breaking source compatibility by implementing a Go-like source-code migrator to get rid of deprecated syntax sometimes in the future.
Most importantly - at the end of that talk, Paul Philips still claims that Scala is his favorite language. But then again, you weren't really interested in what he actually had to say, did you?
I was wondering about the persistent negativity about Scala since it runs counter to my own very positive experiences with Scala and Play. For me it hits just the sweet spot between monadic goodness and getting stuff done in the JVM eco system.
For Scala 2.11 I'm excited about the focus on performance of map and flatmap in List. Those are my bread and butter at the moment. It's amazing how intuïtive that becomes once you use it everyday for dealing with futures, collections etc and you forget about the mathematical monad etc underpinnings for a moment.
I hope that splitting xml parsing off into a module will reinvigorate xml support that's highly performant and easy to use. Of course json is all the hotness. But there's a lot of xml services out there to be used. So that's a core tool for a lot of applications.
I can't wait to try out the compiler/sbt speed improvements in sbt 13.2.
I seem to recall that there are talks on unifying the compilation of sbt and the IDE. That's something I look forward to since I tend to use the ~ continuous run/test/compile options of sbt and then having another compilation going on at the same time within my IDE seems wasteful.
I do hope that the Eclipse Scala IDE gets enough love and will continue to improve. A lot of companies in the Java space got used to free IDEs. (I know that's penny wise) So having a good free IDE is a strong enabler for grass roots Scala adoption.
Together with the super support for JS MVC applications that's coming up in Play 2.3 I'm looking forward to putting this to use.
Lauren Y is a sock puppet account used by Cedric Beust. Primary account activities are promoting his own blog and criticizing Scala, pretending to have worked with it for several years in production before finally deciding that the language is not production ready.
There were a lot of really complicated things added in 2.10, so now I wouldn't be so certain. I used 2.9, and personally I found it very easy to read and write, most of the time.
> Any languages gets easy to read & write once you master it
What complicated things were aded 2.10 that do not require the -experimental flag to be set? Experimental means what the name implies. An experimental feature can disappear or change in the next release. It's there to experiment with but generally not to use in production code.
2.11 is definitely more conservative in terms of new features.
I've been coding mostly in Scala for a couple of years now and am still learning new things. The more I learn the more I realise how powerful the features are.
Compilation has improved with scala 2.10, and 2.11 purports to speed things up even further. (Note: haven't tried it yet.)
Compilation speed is also drastically improved by using the type system. If you give your code well defined internal interfaces, there will be very little recompilation needed by SBT's incremental compiler. Your code will be cleaner too.
Compilation is also slowed down by the type system as inference is expensive. Scalac wasn't very aggressive with incremental compilation when I was working with it 8 years ago, it only worked at the file level (not the AST tree level) and the dependency manager didn't handle traits very well. I would hope things are better now.
Scala's type system computations themselves are expensive, even if you ignore dependency recompilation. Typers is doing lots of heavy lifting if you've ever looked at the code.
Definitely type inference also leads to volatile member signatures, but if the compiler could reach the 1 million lines/second level, then it wouldn't be such a big deal.
On the other hand, the type system being very static and expressive, the compiler does the kind of work for which in other languages you'd need to run more specialized tools or to write more unit tests. When I'm doing time comparisons, I take into account the whole development workflow, that's why the compiler's speed doesn't bother me as is - I mean, what's slower, compiling code with Scala, or running unit tests in Ruby?
In Scala you get things like this:
scala> Option(3) match { case Some(nr) => println(nr) }
<console>:9: warning: match may not be exhaustive.
It would fail on the following input: None
Or like this:
val stillAMap: Map[String, String] = Map("hello" -> "world").map {
case (key, value) => (key, value + ", Alex")
}
val iterOfInt: Iterable[Int] = Map("hello" -> "world").map {
case (key, value) => value.length
}
And because immutable sequences are covariant, it has no problem in doing this (i.e. in Scala types usually have a natural flow, no need for explicit castings or shoving round pegs in square holes):
val iterOfAny: Iterable[Any] = iterOfInt
Actually, traits can be used as tags, so say you wanted to model the states of a state-machine, instead of having something like this, which is error prone:
trait Foo {
def isOperational: Boolean
def isDispatched: Boolean
}
object Available extends Foo {
val isOperational = true
val isDispatched = false
}
object RampUp extends Foo {
val isOperational = true
val isDispatched = true
}
object Fault extends Foo {
val isOperational = false
val isDispatched = false
}
// ...
You could do this:
trait Foo
trait IsOperational extends Foo
trait IsNotOperational extends Foo
trait IsDispatched extends Foo
trait IsNotDispatched extends Foo
object Available extends IsOperational with IsNotDispatched
object RampUp extends IsOperational with IsDispatched
object Fault extends IsNotOperational with IsNotDispatched
// ...
And then you could have a pattern matcher definition, for you know, convenience:
object IsDispatched {
def unapply(state: IsOperational) = state match {
case ref: IsDispatched => Some(ref)
case _ => None
}
}
Question: what would be the inferred return type of the above unapply function? That's right, it's Option[IsOperational with IsDispatched].
Basically Scala is the type of static language with which you can enforce correctness of the business logic with types. Yes, the compiler is slow, but it's slow because it does so much and IMHO, that's time well spent.
Now I also like dynamic languages and on the issue of static versus dynamic, I think David Pollak said it better than I could - static type systems work better if the shape of the data you're working with is well defined, whereas dynamic type systems work better if the shape of the data is not well defined. So usually people are on either side of this debate depending on what they are working on ;-)
