The critique about excessive and opaque operator use in libraries is fair, though I think it actually exposes an interesting philosophical issue. Scala is unabashedly written to be a flexible language. This is in opposition to Java, which was written to be a very strict language in terms of expressiveness on the part of the developer (it's perhaps the most strict of the languages I've worked with, hence it being my example). I personally think a lot of criticisms leveled against Java's verbosity and inflexibility are unfair, by virtue of the following: Many incredibly successful and complex open source projects are written in Java. While you could say this stems from Java's enormous popularity, one interesting property of huge Java open-source projects is that I can usually crack open the code and quickly get a sense of how I could contribute to the system without breaking it. While other languages often do a better job of giving me a sense of how the system works, I generally have much trouble with extensibility unless it's Java. This I believe is because Java was designed from the ground up with the goal of limiting individual developer expressivity in favor of imagining large development teams with limited cross communication.
So--I am far less anti-Java than most. But I am a big fan of Scala. Unlike Java, Scala was written to maximize developer expressivity. While writing Java can feel like putting together a legal contract, writing Scala can feel like creating a poem. I'm not making a value judgement in either direction there--I feel that poetry is a good metaphor, because things in Scala tend to fall apart in the reading department. One of the easiest things to do in poetry is to lose the reader--a great poet can put an incredibly complicated multilayered concept onto a small amount of paper--and require a graduate-level understanding from the reader to understand it. Similarly, one can very easily make Scala into an exercise in unpacking
So isn't that a bad thing? Why am I a Scala fan? Going back to my initial praise of Java--Java is so simple and predictable that it's really easy to see how the plumbing works. But because the plumbing must be laid out so meticulously and in every situation, it is often hard to see how things work at a high level. You can't see an architectural sketch in Java, you can only see endless classes in endlessly nested subdirectories. This is a very low level of abstraction, and helps the layperson (such as someone approaching a new open source project) build up an understanding from the base elements. But what's lacking is the high level abstraction.
Outside of programming languages, almost every knowledge discipline has a high level abstraction language--sometimes multiple languages. Usually the abstraction language is opaque to newcomers, and frustratingly so. Examples are the mathematical notations of various disciplines, the jargon-laden meta-language of historical theory/literary criticism, and what is popularly known as 'legalese'. But even less high falutin' fields have similar languages--listening to sports fans talking about what's happening can be quite mystifying to me, given all of the shorthand they're using. Similarly people talking about pop culture in areas I'm not familiar with.
These ubiquitous high level languages usually share two important facets: first, in a few lines of text/speech, you can pack in many books' worth of concepts. Second, unless someone has read those books, they will have no idea what you're talking about (or in the case of pop culture jargon, having spent the requisite hundreds of hours watching movies). Scala is trying to provide a language that can express the low level plumbing as Java can, but also that can express the high level meta-language. In doing so, it opens itself to the same type of criticism that mathematical notation can receive--opacity.
The pitfall, then, of Scala library developers is to create a high level meta-language (a DSL), that doesn't have industry acceptance. This is tantamount to mathematicians who create their own notation to establish proofs--such proofs can be completely unreadable to their colleagues. But this isn't a criticism that should be leveled at the idea of notation period--it's a matter of people learning to accept useful obfuscation (where jargon can reduce textual size and increase understanding) and reject useless obfuscation (inventing your own dialect of shorthand and forcing your readers to learn non-transferrable knowledge to understand what you wrote).
Because they are working with such a flexible language, and one that is targeted at building high abstraction languages, Scala library developers need to think of their audience--terseness by itself is not useful, unless you're writing throwaway code. If you're going to unleash a DSL on your reader, make sure it's in a real dialogue with the reader's expected level of knowledge with regards to how such a DSL should be structured in terms of what the symbols should mean and how they fit together.
I don't know how the Scala story will end, but I do believe that it is one of the few languages that reaches for an expressivity goal that needs to be achieved by at least some future language. Its reaching opens it to much criticism, and rightfully so, but I appreciate it for its ambition.
The poetry thing is really dead on -- when Larry Wall spoke of Perl -- he said he explicitly wanted you to be able to write poetry with it. This led to the write once, read never reputation of Perl... that Scala is quickly stealing.
Scala is on my "will not work with" list of languages/technologies -- which is generally limited to old languages/tools that I have experience with (like Progress 4GL, Mumps, etc), but don't want to touch. It is a maintainability blackhole and generally horrible (to me) to work with, despite being fairly comfortable with the core (1400 or so hours billed).
Just curious, what are the some languages/platforms you like or enjoy using? (Mine are Python, Erlang and Go for ex).
I agree that it becomes tricky to get an overview of the whole project in C/Java/etc, but I very much disagree that it actually becomes easy to get that high level overview in Scala/Ruby/etc. As soon as the project becomes 'interestingly large' and full of the corner cases that comes with interacting with reality, all languages fall down here. Regardless of the level of the language, you are still communicating with a machine. I'd guess that for a mathematician who has spent most of their lives looking at equations and little time talking to people, a mathematical functional language may seem easier to read than a novel - but for most people this isn't the case.
The best way I've seen to handle this regardless of language is to have the high level overview outside of the code in a human form document describing the reason for components and not just what they are.
This is also why I prefer simpler languages (like Java or C, as you say) - they are very good at specifying exactly what is going on with little room for creativity to confuse things. We use legal contracts for a reason - imagine if our laws were written in poetry? Writing a computer program is much closer to a law than a poem as you need to limit ambiguity as much as possible and specify as many corner cases as possible to prevent undefined behavior. Plus being at a lower level means optimization strategies are easier to see.
There's a reason C/Java/C#/etc are still the most popular languages, imo. The only real outlier being Javascript which gets its popularity from being the only option for the browser.
This is probably the reason for Javascript's popularity, but if you ignore some bad language design, Javascript is a very simple language with a very small number of concepts that you need to understand to start getting work done in it. Even Python (which I think is the simplest of the widely used dynamic languages) has a larger number of concepts that you need to understand than Javascript.
So I don't think Javascript it's an outlier according to your theory, it's very much a simple language, the only remarking features compared to C/Java/C#/etc are the fact that it's dynamic and that some corners of it are badly designed, plus exceptionally badly designed API if you're doing anything in the browser that's not abstracted by a platform library.
But when I read production code it was aweful because of all the DSLs.
Scala does much to reduce code to whats necessary, like python, but there is so much more that it does, which confuses the code readability later :\
The DSLs also lead to bad API design.
The devs are always like "uhuuu if you don't like the DSL just use the normal functions" and write the horrible DSL stuff without the DSL.
(asd ~! fdd %%% sdasd) gets to asd.doSomethingRatherComplicated( with( fdd ) ).alsoGetSomeStrange( sdasd.compile() )
It looks like they are using the ability to build "easy" DSLs as excuse for bad API-design.
The next chapter delved deeper into the typing system, and I recoiled in horror.
I still want to do Scala some day just to use their actor messaging, but there really is a very strict limit to how far a sane person can look into Scala. At some point, the Abyss looks into you, and if you're not careful, you'll also start building crazy DSLs with incomprehensible operators based on Type Declarations Man Was Not Meant To Know, just to maintain rigid type safety in some situation nobody really cares about.
I've been working with Scala full-time for the past 2 years. Prior to that I worked with Perl, Python and Ruby and I still work with these languages for quick scripting or if the codebase demands it.
Scala code-bases tend to be based to a higher degree on good engineering practices. Scala itself is a much more static language than a language like Java, hence it gives you plenty of compile-time safety, with its static type system being one that helps you, instead of staying in your way. Even a tricky feature (now market as experimental SIP-18 and so they have to be explicitly enabled), like implicit conversions, is far more safer than the monkey patching that goes on in Ruby/Python, as it's lexically scoped, doesn't modify anything and the compiler throws errors if there are conflicts.
There's this joke about how a Haskell programmer's style on a hello world programme evolves with experience, starting from a very readable, sort of down to earth implementation, and turning out in its last iteration into a complex "mess" of abstract concepts, for sensibly the same result.
It's always possible to keep things simple, even in Scala, and the opposite is also true with a language known as simple, Java, because the type system happens to be quite powerful actually. People are tempted to make things complicated also because there is this prevalent programming style in the community.
I can't speak for SBT because I don't use it, but Spray is probably the nicest library for defining HTTP APIs I've ever used, in any language. As for type inference, yes it's imperfect, and maybe disappointing for someone used to Haskell, but coming from Python I found the set of type annotations I needed to add to make my Scala compile was a subset of the ones I wanted to document anyway.
Also, I think you exaggerate the 'Scala is bad because DSLs' point. There are indeed a lot of libraries which overuse symbols but you are not obligated to use them. I have found the Scala I've written and read personally to be both concise and readable.
And, Scala isn't the first or the last to 'reach for the expressivity goal'. See: Haskell, Scheme, F#, & ML.
I think he meant the language that lawyers might use amongst themselves. Legalese is actually fairly low level. It's like a fully type annotated version of English that redefines all library functions each time.
I worked on a large C++ project. Most code was written in a very concrete way. This lead to reams of boilerplate code which bothered me a lot. I thought it was difficult to grasp because there was so much code and there was no explanation of concepts. To me concepts are important. Instead I wrote high level but quite abstract code, but with good documentation of concepts I used.
Sadly I noticed people had big problems understanding my code. I tried to analyze why. My best explanation would be that they were not interested in software architecture like me so they could not recognize concepts and patterns as easily. Furthermore they were not used to reading documentation about concepts. They just wanted to look at the code right away. That is what they were used to. But that was hard, because my code was quite abstract.
I have no idea what the solution to this contradiction is.
Take clojure. Both very expressive and very readable.
The problem of Scala is not that it is oh so awesome and expressive. It is in a failed attempt to marry two very complex worlds: OO and FP. Of course the complexity of language explodes on unsuspecting developers.
Scala is a cautionary tale for every language creator out there. Chose carefully what you pack into your language.
There's absolutely no need to create a monstrosity like scala in order to reduce boilerplate. Even such complex language as haskell is much simpler and more readable than scala.
That's the reason both OO and FP camps reject scala. It is OVERENGINEERED.
rust-http is, at present at least, rejecting the standard practice of stringly typed headers and is using strongly typed headers.
> ... and even types for every ‘known’ HTTP header.
> The known HTTP header part was particularly ridiculous. HTTP headers are defined as simple key/value pairs. You’re supposed to be allowed to add arbitrary headers. You’re not supposed to be constrained by the framework you’re using not having any support for CORS yet.
He has taken a strong position against this strong typing; I take a similarly strong position for such strong typing.
Yes, HTTP headers are defined as simple key/value pairs. But headers are not text; they are data. XML is defined as text. Should we use regular expressions to work with it? (True, it also has the DOM defined. But HTTP headers also have a grammar defined—it just happens to include the admissibility of extension headers.)
HTTP is a serialisation format for messages; messages made up of computer-readable data, not text.
I wrote a handful of paragraphs about this subject at https://github.com/chris-morgan/rust-http/issues/1 where using a map instead of typed headers was suggested.
As I also note there, I would not attempt such a scheme in a language like Python (my primary language for some years) because its type system is not well adjusted to something like this; I am certain it would cause many problems and feel it likely it would cause more than it solved. But in a language with a solid type system capable of expressing these things, taking advantage of it should lead to a faster, more correct program.
In the end, I believe strongly typed headers are a good thing to have (it will actually make most code distinctly nicer—e.g. ``response.headers.date = Some(now())`` instead of ``response.headers.set("Date", now().to_http_header())``). The implementation of the scheme in rust-http is certainly not perfect yet; I'm not happy with it at present; I'm expecting to turn the extension headers into a trait object, and I've even considered crazy ideas like allowing users of the library to make their own header collection (request.headers and response.headers) types—that would allow custom headers to be made first-class citizens but could lead to compatibility problems.
Still, I don't want to make something that I believe should be the best HTTP library around and find that people hate to use it. What do you think about this header matter?
And I'm not sure there's a good solution. The obvious approach, as you already know, is to separate headers into two groups: one group is "properly" handled, and the other group gets tossed into an "other" bucket of key/value string pairs. But it's going to be awfully tempting over time to have "proper" support for the most common non-RFC2616 headers, especially those which have widely-accepted standards of their own.
But that's a bit messy and much less than ideal, as you've also discovered. And I don't know of another way to approach the problem that still lets you have the stuff you want from the type system, and doesn't cut people off the minute they start using extension headers your library doesn't know about.
And that's without getting into all the completely stupid things it's technically legal to do in an HTTP header, and the even more stupid things that aren't legal but that people do anyway. My usual torture test of an HTTP library these days runs through things like non-ASCII content in header values (legal if properly encoded, and not everything in the wild properly encodes), looking to see how large a value a library will accept, whether it will let me throw newlines into headers, etc. etc.
I'll give you a real-world example. Mono. HttpWebRequest used to store the Content-Size value as an int32. What about files larger than 4gb? Oops...
That was a big problem for us. Thankfully Mono is open source, we were able to peruse the code and come up with some magic incantations using reflection to work around the fact that the framework libraries would not allow us to set the Content-Size header without going through the int32 property.
Now, normally you would file that as a bug, however, it (A) took years for a version of mono to be released with that fixed this and (B) could easily have been some misunderstanding in the implementation of the HTTP spec that was overlooked. You're implementing a spec right now. Can you guarantee that the your implementation is 100% correct? Can you guarantee that the spec is 100% correct? Can you guarantee that the spec is implemented 100% correct everywhere?
No, you can't.
So, don't limit me. Help me, but do not prevent me from doing what I need to in order to do my job.
https://groups.google.com/forum/#!searchin/golang-nuts/s3/go...
The short summary is that Amazon S3 does not behave like a normal web server and expects HTTP path's to be "url encoded". S3 is pretty obviously something you would want to interoperate with. Go's http client (which isn't very strict at all) causes friction here.
In the past when I have used such libraries they have been a pain - especially for loose formats like HTTP headers. Type system come with a cost, you need to carefully consider the burden you are placing on the programmer to see if the benefits out way the cost.
Remember Postel's law: "Be conservative in what you do, be liberal in what you accept from others."
Unfortunately, you will have to return URLs to your users that are invalid. You will have to parse slightly malformed dates. Your clients will expect to be able to pass through malformed values from bad endpoints and not introduce a point of failure in your library. (Do you know about the "Cneonction: close" trick, for instance? All real-world proxies do all sorts of batshit-crazy HTTP header munging.)
If your library can't accept and pass through arbitrary strings for arbitrary headers, and return them to users, and then accept them back again, then it is unlikely to be successful in any sufficiently complex and robust HTTP service.
As a (albeit poor example), I once inherited a click tracking system that uses Java Jersey. The standard response object has a .redirect(URI uri) method. Unfortunately, many "URI"s we receive from the world are not actually value, and the java URI object refuses to build URI objects from the string. Fortunately, one can simply call .setHeader(String, String) and be done with it.
You can be both . . .
IMO, all the fields need to have a Printable and Readable trait (or whatever Rust's version of those are). If you want to do special things for certain fields to make them easier to work with, I think that's cool too. But if you force people not to treat headers as text, I think you're going to have a problem.
It seems to me that, in the worst case, the downside of your current scheme is an extra field dereference, as in `request.headers.extensions.get("crazyNewField")` instead of `request.headers.get("crazyNewField")`. I think that cost is easily outweighed by the benefits.
response["headre"] = ...
People say the same thing about null pointer exceptions, but null pointer exceptions are a huge problem in practice. Every bug is "obvious" in retrospect.
I love that there are people who say things like this totally seriously.
If people like OP are dissing a language because they don't like a particular library's API, they have very strange expectations from the language. And if you are worried about this section of users, then I would say in order to make good use of your time, it is best to ignore them.
If it's hard to do X in your language, but easy in other languages - then that's a weakness for your language, despite that 90% of X's will be outside of the language core.
And even 'optional extras' in your language can be weaknesses instead of features - if they are often used by library makers for less readable/maintainable code than the other options.
Why not add a weak checking for k-v strings? Something like during compile time:
if not k in LIST_OF_WELLKNOWNS
warn('Bad header maybe?')
I really like the spray way. You can add a custom/nonstandard header by using RawHeader(key, value), but most of the time you use e.g. Headers.ContentType(MediaTypes.`application/json`), and it just completely eliminates a class of trivial but annoying bugs.
Solution: author should abandon the JVM ecosystem and use Go.
- Fast compiles.
- Ultra simple, non extensible syntax, yet not verbose in practise.
- The code you see is 100% of the code.
- A culture of implementing the simple algorithm.
- Stable, with version compatibility guarantees.
- Nobody is trying to make the types jump through hoops, so the type inference works.
Groovy's static typing is quite recent, written by one person only, and not actually used in many codebases. Neither Grails nor Gradle uses it.
There's only really 2 or 3 use cases for Groovy:
* quick & dirty scripts for Java class testing and manip
* Grails
* more recently, Gradle (which still ships with Groovy 1.x)
If you want static typing on the JVM, best use a language designed from the ground up to be staticly typed, e.g. Java, Scala, Kotlin, Ceylon.
I'm starting to wonder when, when I mention C++, I'm going to be told that Go will fix all my problems. (Rust might; Go won't.)
But, esp when working with collections, I take advantage of Scala's features. It's not perfect, but it works wonderfully. I can always revisit/refactor my code again later.
Here are a couple examples:
myVar match {
case Some(val) => doSomething(val)
case None => handleNone()
myVar.getOrElse("else")
In both of these cases, we eliminated the possibility of a NPE through the use of a language feature. :)
(edited for formatting)
I think he's aware of that - he said he's using Scala as a better Java, what would Java be without the odd NPE?
Things I have in Scala that I like and Java 8 won't provide (many are syntactic sugars and non critical stuff, I know, but I like it, I'm spoiled)
- implicit conversions. some hate it, I love it. It allows much better "pimp my library" mechanism than Ruby's and it's very easy to write extensions to your or 3rd party extensions in a safe and easy manner
- duck typing, e.g. allows to write a "try with resource" without native support for anything that implements "close"
- automatic tuples
- better type inference
- semicolons, hate them
- automatic equals and hashcode for case classes
- case classes
- futures and promises
- by name parameter passing (passing a block of code without running it)
- partial functions, multiple parameter lists
- for comprehensions
- pattern matching
- nested functions
- lazy vals
- everything is an expression
- String interpolation
- multiline string
- default parameters
- named parameters
- pattern matching
- everything is immutable by default
- very string type system
I think that's it. Yes, Scala is infamous as the language that took many many features from other languages and piled it all together, well, fine with me! you say more features that are great in other languages and make people productive? (and are kind of expected, like default parameters etc) I say bring them on and the more the merrier. I can choose which features I want to use out of the way too many features the languages, much better than waiting years for features to be added. Hater's gonna hate, I'm still going to write Scala until something better comes around. (Nimrod? Kotlin? Ceylon? TypeScript? Dart? perhaps even Go? Don't know... time will tell)
You lose out on most of the features of Scala, and IntelliJ supports Scala very well.
In Java's OO paradigm, instance variables are inherently defined separately from their initialization, making it quite difficult to make sure they're always used when initialized, properly.
The nullability stuff bites me over and over :(
Forgetting to use .start() on a thread is a stupid runtime error, instead of using some design where it isn't possible to forget .start() or at least get a compile-time error.
I am also using a lot of C in parallel, and with the C preprocessor, I am finding that C is often more expressive and nicer to use than Java!
Everything takes ridiculous amounts of code.
For example, in Haskell, I can write:
threadIds <- replicateM 10 . forkIO . forever $ do
code .. here ..
In Java, this requires so much effort!
Not to mention the utter lack of sum types and pattern-matching, making tons of Java code that looks like:
if(msg.what == Foo) {
msg.obj1 ...
msg.obj2 ...
} else if(msg.what == Bar) {
..
}
Coming to Scala from experience including C, Java and Haskell, I intially found Scala quite difficult. It is true that there are some things in Scala that are not obvious to newcomers, and that are difficult to discover for yourself - such as the use of Implicits, and the strange precedence and binding rules for operator syntax.
That said, it doesn't take long to learn, and once you do, it all makes sense. There are other great languages out there (I'd say Haskell is one), but compared to for example Java, or one of the dynamically typed languages, Scala is superb.
Types, whilst not having the full H-M inference, are brilliant. That the author complains about having types rather than a simple map for keys shows a misunderstanding of what they are there for - the idea is to allow the compiler to prove at run-time what is valid code and what isn't. He comments that tests run too slowly in Scala (they don't - for our production systems building in SBT, a typical test run is significantly less than 10 seconds) but a lot of the time I don't even need to go that far - my IDE already highlights errors in the code as I type, where I have passed in incorrect or insufficient data.
Also, the author makes a strange comment that H-M 'enabled' Monads, and the comment is written in a way that implies that Scala does not have Monads. This is incorrect. Scala has monads, and the Scalaz library has huge support for Monadic programming. We use Monads and Applicative Functors (a close relative) daily to build high level abstractions, and we couldn't live without them. In Scala we say flatMap rather than bind (or >>=), but we mean the same thing. Although thanks to the same flexible method naming that the author complains about, you can in fact say >>= if you wish.
If you've only got a couple of days to use a language, and you're using it for a tiny project, then Scala is not for you. If want to learn a language that can make you vastly more productive whilst at the same time making your code safer and more robust, Scala is a very effective candidate. It's not the only candidate, but you should at least consider it.
I'll give an example of the power of Scala's type system. When I first convinced one of our founders to give Scala a try, he used it to write the first pass of our analytics service. He'd never written Scala before but once it compiled, it ran correctly on the first try, that's the power of its type system.
I mean mistakes can happen and if the type system can catch it for free, so to speak, that is great. I'm not about to argue that it is completely useless. But in terms of probabilities of what kind of bugs might be introduced, type errors seem to be on the low end.
To infer that Scala's type system is powerful enough to catch the more common types of mistakes programmers make, that is quite an impressive claim. I am curious to know more.
There's some evidence from what the author wrote he's aware of the benefits of type systems. The question he raises is whether the developers who wrote Spray modeled the problem domain well by choosing this particular set of types (his opinion is clearly no).
> the author makes a strange comment that H-M 'enabled' Monads, and the comment is written in a way that implies that Scala does not have Monads.
Given that the author immediately follows his "enabled" statement with the idea that monads can be used in a type-free language, I think it's most likely he means that H-M has been the ground where the use of monads has been largely developed/defined, not that monads can't be used in either Scala or even something with a considerably less expressive type system.
I think because it allows you to do OOP and FP, Scala becomes difficult since it is so easy to mix the styles. Similar to C and C++, this is very powerful, but also very dangerous. The main learning curve is programming in a way so you don't shoot yourself in the foot while using its flexibility.
Eclipse allows very fast compilation times, but when I tried sbt, I gave up because I CAN'T wait for compilation: we're in 2013, I'm using a quad core at 3.4GHz, 12GB of RAM and SSD, so I'm not ready to wait. Eclipse allows fast incremental compilation.
Scala's type system is very rich. I don't know if there exists any type that can't be expressed in Scala. Since I don't know if such a type exists, I don't miss it. But that's probably too much, and in the end, idiomatic Scala emerges: some libraries use the type system in an idiomatic way. It's working, but understanding method signatures turns into a nightmare. Then you must learn the arcane of Scala to understand how the library works.
However, if YOUR Scala is simple enough, then the language can be cool, cooler than Java, and productive. Can be mixed with Java, runs fine for J2EE...
Scala has a very rich type system, but let us not get ahead of ourselves--Scala, being non-dependently typed, cannot type many useful programs.
For an example of a useful dependent type, consider giving division the type Number -> {x : Number | x != 0} -> Number. Giving division the type Number -> Number -> Number is similar to how older Javas would type List<String> as List and require all get operations to cast from Object--in both cases, the type system is unable to guarantee that your program won't crash.
If you want a glimpse of the state of the art of programming with dependent types, try Agda[0].
However, I wonder how much actual utility they can provide, seeing as (1) dependent typing is generally acknowledged to be rather difficult (and that's a statement coming from those who generally tend to already be good at a language like Haskell), and then also (2) the fact that a great deal of real-world applications, such as FFI, accepting data over a wire, dealing with exceptions and faulty input, etc, mean that no matter how bullet-proof the code you write is, you'll still have to account for all of the ugliness which the world can throw at you, which means unit testing, exception handling and other things which seem to undermine - to a degree - the strengths of strong typing in the first place.
Or am I exaggerating things? I've written a lot in Haskell and enjoy it a great deal, but at work I use Python and JavaScript, and honestly, although there are some things that would be streamlined away by a strong typing system, particularly in the development cycle, there are still a ton of ugly, mundane real-world things that would still need to be dealt with in much the same way if they were written in Haskell. I would still love to have the opportunity to write in Haskell (or Agda or Idris, etc) at work, but I'm not sure how much trouble it would save me from at the end of the day. Would it? And would the additional mental hurdles of dependent typing add real tangible benefits on top of this?
object Positive { def unapply(x: Int): Option[Int] = if (x>0) Some(x) else None }
val onlyPositive: PartialFunction[Int, String] = { case Positive(x) => s"check out this positive number: $x" }
This would throw a MatchError for non-positive Ints, but you can also handle the failure case like so:
def onlyPositive(n: Int) = n match { case Positive(x) => s"check out this positive number: $x" case _ => s"not a positive number: $n" }
This is a quick example, but in practice the lack of dependent types is not a huge handicap.
sbt ~compile
So for someone like me who wants a statically typed language (there goes Ruby, Python JavaScript, Clojure), who thinks Haskell is too academic to be really productive (I have to think too much to get things done with it) and who don't get what is all the rage about Go (perhaps because I'm not a system programmer, in any case I still don't get it, sorry) This leaves me with no other options (except C#, which I would probably use if it was really portable)
Scala is not perfect, but I feel more productive with it than with any other language, if anyone who never used Scala will decide not to even try it because of this article, I wish them luck, but I doubt this will be the case. for those who use it, they will still continue.
So I really don't think I understand what is the point of such an article. Try the language for yourself, if you like it use it, if not, and you have a choice, don't.
p.s. for all those poor bastards who are forced to use Java at work, Scala is by far a gift from the Gods, so it helps to keep things in proportions, one man's source for a rant article, is other's source of means to finish work at 5pm and go back to the SO and kids. (they would go back at 1pm but their Sun Certified Java EE team lead brain will explode if they will use Clojure, with Scala your EJBs or Spring code can still look recognizable, perhaps a bit more pretty) p.s. did I forgot to say I love Scala?
As an aside, insofar as you have some sort of willingness toward C#, you should check out F#, which is functional with really nice type inference and none of the syntactic woes that I have come to associate with Scala. (Not sure how portable it is, I have heard stories of people using it with Mono, but I haven't tried it myself.)
I mistakenly wrote a Java anonymous inner class that called a closed over variable from the outer scope like one would do with Scala closures. Of course the Java compiler threw an error because I didn't mark the variable as final.
When programing in Scala, one never has to deal with such low level rigidness. It just let's you get shit done.
The Scala team does have a plan to fix this though. Of course, if you aren't operating asynchronously or you're only closing over immutable values it doesn't matter anyways.
P.s. I did mention I chose it via elimination, and due to a very subjective preference to typed languages.
Another plus for scala for me is this: I can use it at work.
Though, this could just be me getting more comfortable with the language, knowing where to look, or a combination thereof.
Has scala become a readable alternative to java, while most of the future focus is on clojure? Does anyone know how real life performance compares between both.
From my viewpoint, scala is in use at several banks and Twitter - clojure doesn't really have a big name advocate behind it. From a startup standpoint, isn't talent/hiring an issue?
Performance is probably the last thing you need to care about when choosing a programming language for most businesses - unless you are doing hard-core analytics or handling huge scale, you just won't hit the sort of performance problems that are solved by a faster programming language (as opposed to a faster algorithm or architecture).
It really frustrates me that people _still_ put such weight on low level performance. In 1997 I had people saying "don't use Java, it's performance is far worse than C++". It was mostly untrue for business problems then - and computers are many orders of magnitude faster now.
Well-written Scala and Clojure can provide comparable (ie Java level) performance.
Clojure has tools (like core.typed and Prismatic's schema library) to optionally provide you with static typing where you want it, without the burden where you don't need it.
Clojure does regular releases every year (that continue to be high quality and maintain backwards compatibility) and now has paid developers and support that will continue to accelerate progress. Because of the flexibility of the language, a great deal can be done outside the language in libraries (such as the entirely new concurrency paradigm in core.async).
Slow build times complaint
> It is essentially impossible to practice TDD in Scala simply due to the time it takes to compile.
Hrmm, that's interesting, because it sure seems like other people are able to do this. I agree, the slow build times are annoying, but let's not exaggerate.
SBT critiques
>That punctuation-strewn build system I was forced to use was just taking advantage of Scala’s ridiculously flexible syntax.
Yeah, I get it, everyone makes fun of SBT's syntax.
Language is complicated
This is where it just kind of descends into whining about how 'hard' the language is. He claims javascript is a "simple" language. Does he just not count the weird edge cases when thinking about complexity?
Type inference complaint
> And this is the real death knell for Scala. Hindley-Milner Type Inference is a fantastic thing.... It’s enabled monads, which you want to be able to understand and then use in a type-free language.
WAT. I don't think those words mean what you think they mean.
>In my mind, Hindley-Milner was always the promise and the pay-off for Scala...I know this is the fault of the JVM’s use of type erasure. I don’t care.
O REALLY? Go on...
Maybe if this guy had cared enough to do a five second google he'd realize that Scala doesn't use hindley-milner type inference.
Bottom line is, I think I have a good understanding of the type of programmer this guy is, and it's exemplified nicely in this quote right here:
>Sure, with another couple hours we would have been able to figure it out… [but] We ended up copying and pasting the same four lines into all our endpoints. A dark moment.
For an intelligent critique of the scala langauge see here:
http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...
That's his point. Scala doesn't use HM and it needs to. He says the reason it doesn't is because of the JVM, which seems misguided.
Instead, I learned Clojure. I use Ruby, the epitome of comfortable languages, for most things, and when the hard problems come up, I use clojure. My next major scientific computing problem, rare as they are, will be in Julia instead of Matlab for prototyping and java for production. Scala seems to be the hard language for easy problems. No thanks.
The Clojure community has its navel gazing of course, but every time I've been exposed to some crazy idea in that community it was always through the lens of providing real leverage for real problems. Most of the time when I've dealt with people trying to explain concepts to me for Scala code, I've walked away wondering what the point of it all was (beyond the fun Computer Science.)
Actually, I spent some time over the weekend trying to get familiar with Scala by using it to solve some Project Euler problems, and it was pretty entertaining. Still, the language's bias towards there being more than one way to do anything does worry me; it does seem that the kind of mutually incomprehensible code bases the OP talks about are likely. I would assume that, like C++, you need a strong style guide for a Scala project laying down which parts of the language you are going to use. Does anyone have any recommendations for guides on writing comprehensible, maintainable Scala?
Scala does have some rough edges but they are not the kind of C++ ones, and even the complexity of the most powerful features (implicits) is very controllable.
Seriously - which features would you like to remove from Scala? I'm really curious because I don't find any redundant ones. All are pretty complementary and very useful.
I think in truth, though, if there were a web framework in Clojure as well received as Play I would be bounding down that path instead. Clojure seems to be where a lot of the JVM interested is heading yet we're not there yet for some reason.
The Luminus micro-framework (http://www.luminusweb.net/) is a great choice providing a starting structure around existing libraries. Caribou (http://let-caribou.in/) is a more full-featured framework for building web apps. Pedestal (http://pedestal.io/) provides heavy-duty tools for creating data-heavy single-page apps.
And there's a new book on the way about Clojure web dev http://pragprog.com/book/dswdcloj/web-development-with-cloju....
I don't really know that I miss anything. The things I might've thought I'd miss are the things that ended up souring the taste of Rails.
Having to come up with my own abstractions or recreate familiar conventions or set up a database were areas where I had to cut my teeth, but I also had to cut my teeth on Rails when I was learning it.
Rather than missing anything from Rails, I find myself using Rails' conventions as a loose model and then simplifying it. For example, my "templates" are now just functions that render html. My "layouts" are just functions that get applied to templates. I don't need to read Rails' template rendering guide to come up with a hack. Instead, modifying my templating system is trivial and obvious.
There's nothing so terrible about that per se--it's a great way to learn--but it can feel like a high friction workflow compared to Rails, especially getting started. I think it's primarily a function of community size and library maturity, but there's a cultural element as well. Rails has more of a beginner-friendliness-is-good mindset (even when library internals are fugly), while in Clojure the focus is more on the strength of the functionality and less on easily grokkable apis (though there are notable exceptions).
My belief though is that there is some peace of mind that comes from the idea of what you might call "page composition" -- that this piece of data sits in this template, that it rides on top of this simple model, that it is in ORM from database. There is a huge amount of linearity and convention throughout the stack and because of the dynamic nature of Ruby lots of gems can be sprinkled throughout without one really understanding what they do.
Now, I'm certain this level of abstraction and functional/mixin kindof stuff can be achieved in a Clojure framework but I think it is generally perceived as being a bit more non-linear and DIY (libraries not necessarily playing nicely together). As in "yes I can get all of these pieces together but then if down the line I have to change this piece, how will I accomplish it without breaking everything". Essentially, I think the perception of OO is more alluring in terms of project cohesion, whereas functional programming is seen more of a supposedly incorrect assumption that an HTML document is simply an assembled mass of text.
I'm really just trying to convey that RoR and the like seem to be making a COMPLETE ("in a few lines I can do anything short of my business's custom domain logic") framework out of the box and perhaps there is some stigma attached to the nature of Lisp that makes it seem as though framework developers are not striving to cross these bridges and there is less of a community to keep them in check.
Eh, I wish that made more sense but this is a lot of conjecture based on perceptions -- it's clear that a lot of these communities emerge from hype & reactionary values moreso than anything else. People wanted to shift away from PHP and be more productive without getting radically far away conceptually. I just got dizzy thinking about this lol... but yeah I think Java developers are a bit more open-minded when it comes to application development, seeing things more matter-of-factly than the languages with only MVC/Model2 kind of frameworks. I think if an attractively-packaged Clojure library were to emerge and get the right publicity (sad but thats how the web dev world is...) it could steal the hearts of many Java devs.
In my limited experience with Clojure it seems fun AND powerful. Yes there is a learning curve but that is to take it above and beyond. The simple functionality of most web apps could probably be achieved without writing anything too mind-bending.
Please do respond even if that response involves completely ignoring my rambling... I'm very curious to understand the Clojure community better :)
1) src/main/scala/com/thingy/actualthingy JUST to get to the root of your code. 2) Recompiling/restarting is slow because liftweb and other frameworks are overly complex. 3) I'm 90% sure it would be possible to create a PRY-like debugging tool that runs your code in interpreted mode and drops you into the REPL at a certain point in your code. And yet, it'll never get built because Scala hackers are stuck in the halcyon java days of 1998. 4) Variable names first, types second = okay, now you're just being different for the sake of being different.
That said, it seems like if you use scala as a more concise java with some handy functional syntax thrown in, you can make something that isn't terrible for future maintainers.
2) Compiling Scala is slower than Java (sometimes much slower) but that's not the frameworks' fault. scalac is just slow, though getting better.
3) This does exist. In fact, it's built into the language. You can also use "sbt console" to load a REPL with your entire project in the classpath.
4) As the other reply said, type annotations aren't required. In that light, Scala's syntax for type annotations makes sense.
Sounds like Kotlin.
We all want more powerful tools and infinite expression but at what point are we bikeshedding languages instead of building transparently clear solutions?
Scala seems to be solving problems i dont have.
As a long-time Java dev myself, Scala is solving problems you don't even realise you have, because you don't know to look for them.
Powerful types, immutable state and FP make a world of difference for writing clear solutions, with better abstractions, less code, less bugs and less bullshit than the horrendous status quo of corporate Java development.
It may take some getting used to syntax and design wise, but being able to code things up in 1/10 the size of other languages completely blows away the disadvantages of Scala.
Note: It's been a while since I've seen traits, this might have changed for better.
To me Scala is essentially if Java, Haskell and C++ went to a wizard to have a child. The result is a magical mess. I seriously think that Scala has at least twice as many concepts as C++ and same if not greater number of really weird edge cases. I don't want to keep Scala in my mind, no more than I want to keep Necromicon.
Still, it's a shame that most people interested in programming languages have never heard about Eiffel, or ever read the superb book "Object-Oriented Software Construction" by Eiffel's creator, Bertrand Meyer. Eiffel has many flaws (the most proeminent being the complete lack of support for functional idioms), but it has very good ideas as well. (Perhaps the most popular influence Eiffel had on other languages is Design by Contract and the uniform access principle, which you see in most "modern" languages.)
If you can't override variables, you can't silently change the structure to depend on trait order. You'd have to explicitly state order.
PS. Of course if you have several same signature methods that call super, which is generated depending on order, same problem persist. So, forbidding variables and calling super elements should deal with most "magical" interactions.
http://play.lighthouseapp.com/projects/82401/tickets/98
I loved Play 1.x(early adopter also) but I have since moved on. I gave Play 2 a solid chance. Scala programmers seem to turn everything into some kind of academic paper.
I wanted to create pretty urls but I couldn't do it in a simple way because the developers thought that in a path can not be optional parts, like: /article/1/article-slug and /article/1
So they removed a useful feature. And it was in a 2.x -> 2.x+1 release... Yesterday it worked, today not. I was not happy. :)
http://stackoverflow.com/questions/14980952/routes-with-opti...
My othern concern with scala, what is mentioned in the article, is the operator usage.
How am I supposed to "invent" this <:< notation for adding headers? (dispatch lib) `val svc = url(object_url) <:< Map("User-Agent" -> "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)")` or in squeryl, converting a boolean into a "query boolean": ``` val fls = false fls.~.? ```
Other than these, I like it. When I am coding in JS or PHP I always praise the scala types/ compile time checks. I am almost afraid of dynamic typing since I tried scala. :)
I should say one thing however:
I'm using Scala because of Akka. An extremely powerful library that does a good job of hiding the complexities while still allowing you to be flexible.
An immutable List of Foos is a List of Bars if a Foo is a Bar. A function taking X and returning Y is a function taking A and returning B if A is a X and Y is a B.
It's just answering the question "Can I use type relationships to guarantee that I will have no run-time conversion failures?"
Show me a statically typed language on the JVM that trumps Scala -- it doesn't exist.
Show me an ecosystem in that statically JVM based language that trumps that of Scala (Akka, Play, Slick, sqltyped, Squeryl, Spray, Scalatra, Lift, Blue Eyes, Unfiltered, etc., etc.)
Yes, compile times are a hassle (for deployment that is, incremental compilation combined with sub projects are plenty fast, usually around 1-3 seconds, it's a non-issue).
Yes, IDE support is nowhere near that of Java's, but it has improved immensely during the past 2 years. Either IntelliJ or Eclipse + ScalaIDE do the trick, am happy on the latter here.
There are only two kinds of languages: the ones people complain about and the ones nobody uses --Bjarne Stroustrup
I'd just put any kind of application, whether built in Scala, node.js or Go or ruby on rails behind a nginx proxy and use that for setting the headers. That simplifies a lot of things. I hope your HTTP headers aren't really so dynamic that you need to build software that changes them so much, especially not for a RESTful application.
The last thing you want is to make the deployment harder.
But once haircut fascination is over - people expect you to do mundane tasks, like cook food or take out the garbage. Or they won't pay you.
And then you realize that when Scala cannot do what you want - you can always revert to Java.
And then you realize that you don't really need Scala-ing if you can do the same stuff in Java or any other strongly typed language.
That's the turing completeness fallacy. Why not just write everything in C? And java's types are inadequate for doing really generic methods - how would you go about writing scalaz's "sequence" in java?
Can you give an example of what you mean? I used ocaml for a few years, and never encountered anything I would consider academic at all, much less unapproachable.
http://www.scala-lang.org/old/node/4654
How this post got voted up to the front page really makes me wonder. "Clojure programmer gives Scala 1 star", what next "Ruby programmer gives Python 1 star"?
That sounds like the most stupid way you could do things.
The things I don't like in Scala:
1. Compile times. It is a problem for big projects. SBT / FSC helps quite a lot, but IMHO it is still not enough. I hope they get them much better in Scala 2.11. Also performance and correctness of the IDE plugin typechecking could be better, so I don't have to compile that often.
2. Lack of backwards binary compatibility. Source compatibility is ok, but selecting the right version of all the libraries is pretty painful, especially if the authors of the library didn't make the packages (yet) or they haven't been deployed to maven repo, etc.
3. That some elegant code constructs come with sometimes huge runtime performance penalty. It got much better recently (e.g. for loops are as fast as while loops now in Scala 2.10), but I feel it could be better. Again - hope Scala 2.11 addresses those concerns at least partially.
The things I don't agree with the OP:
1. Documentation - it is awesome.
2. Syntax flexibility - many times DSL is a better way of expressing things than just a bunch of methods, and easier to learn.
3. Tooling - good enough now, and improving fast.
4. Type inference - I consider it good enough, albeit not perfect. And types in method signatures add a lot to code readability.
There may be some languages that have better IDE support, faster compile times, better type inference, richer type system etc. But none of them supports full feature set of Scala, particularly all the available libraries. So IMHO taking every single feature out from Scala and comparing it let's say to Haskell or ML is ridiculous.
"The... the the the... the language spec... oh, my god. I've gotta blog about this. It's, like, ninety percent [about the type system]. It's the biggest type system you've ever seen in your life, by 5x. Not by an order of magnitude, but man! There are type types, and type type types; there's complexity...
They have this concept called complexity complexity<T> Meaning it's not just complexity; it's not just complexity-complexity: it's parameterized complexity-complexity. (mild laughter) OK? Whoo! I mean, this thing has types on its types on its types. It's gnarly.
I've got this Ph.D. languages intern whose a big Haskell fan, and [surprisingly] a big Scheme fan, and an ML fan. [But especially Haskell.] He knows functional programming, he knows type systems. I mean, he's an expert.
He looked at Scala yesterday, and he told me: "I'm finding this rather intimidating.""
[1] http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.ht...
I am not from CS background, but I took time to learn it and by far it's THE most natural and expressive language I have found AND I don't even know what functional programming and the theory is, all I know I learned through Scala.
Please guys, let's not project our laziness as a fault of Scala.
What I care about is that a language lets me express easily the concepts that are in my head. Scala does that and because of its type systems makes it even possible to document these concepts in a mechanically verifiable way (only up to a certain extent, of course).
I even thought to create readable adapters for common APIs like SBT API.
On the library criticism ... Well, pick better libraries, use java libraries, or roll your own. You have twice the choice you have in java. Is that bad, or good?
Yes, there is immature stuff. Well for the lawyer rate you are charging, should be able to separate that from the good bunch?
The complexity - In my experience, learning curve is gradual in that you can pick new features when you need them. You can pretty much get by writing javesque scala with a bit of closures in the begining. Then take mixins, then take the hardcore stuff when you feel comfortable.
About the build system - here I was surprised. You seem pragmatic, why use it? To me SBT is totally useless because it solves nothing existing tools do not solve. The Scala support in Maven is perfect, and i feel so productive and mature in it these days, I would never trade unless there is a very strong selling point (meaning more free time for me to drink beer, whatever) If you don't like Maven, code in Ant. But using a build tool which is a general-purpose language? I agree with you. Baaaaad idea
On the one hand it's an improvement over the verbosity and rigidity of Java. And often it is fun to write in (lots of clever tricks you can use and feel good about... until you have to come back to the code several months later).
On the other hand, I absolutely hate to dig into Scala code written by others. To me it feels like C++ all over again. There are so many concepts in the language that more often than not you find your knowledge of the language lacking, and have to put the task at hand on hold to brush up on your Scala skills. If there are more than a couple of (Scala loving) codevelopers on the project, you end up spending more time learning about the language than actually using it.
So, to sum it up: I would use Scala if I absolutely had to use JVM and I had control over the the subset of the language used in the codebase. Otherwise, I'd pick something else. Thankfully, there are saner alternatives to JVM these days when it comes to high level/static typing/high performance (e.g. Go).
Legit issues: compile time (of course), library docs (maybe), bad HTTP header API (maybe), tooling (maybe). I thought the automatically generated (doxygen style) library docs were fine when I was playing with Scala two years ago.
that's still a thing? i thought i was just being dumb back in the day.
Let me first say where I'm coming from. I like: a static typing. b support for FP and OO c targeted for JVM.
Compile times It is my experience that compile times are not that bad if you use the support by SBT for continuous compile-deploy-test. Have a look at Typesafe Activator to get a feel what they're moving towards.
Libraries and community I do agree that some frameworks, like Spray f.i., tend to overdo the concise DSL aspect. This seems to be especially prevalent with Scala developers coming from the academic world of monads. Or with a strong tendency to show of how clever they are to the detriment of usability. Scalaz had a strong similar tendency. I have noticed that frameworks like SBT and Scalaz are de-emphasising unpronouncable ungoogleable unintuitive operators. So far I have hope that the Scalaz community will veer away from this. To a certain degree every language community develops a culture about good vs bad code. Twitters Effective Scala guidelines are a wonderful contribution.
Magic syntax I've been using the Play framework for webapplications. And in my experience that is largely a pragmatic tool where I can just get things done. My main criticism would be that sometimes new features seem to be not very well tested. F.i. multi project support did not really work for quite a few versions. That shouldn't take up much time. I hope they address that.
Type inference Coming from Java I like Scalas type inference. Although the compiler feedback can sometimes still be challenging. There has been great work in compiler messages giving advice on how to fix mistakes. F.i. the well known mistake of forgetting the = between a function declaration and implementation. But there are still hairy situations. If you've ever had the infinite recursion type error (being addressed in newer version of the language) you know what I mean. Or using the json parser combinators in the Play framework with classes with one attribute f.i.
Other issues he mentions: - build tools. This has significantly improved since Typesafe started. I'd say that before that Scala wasn't suitable for non academic use. There are still improvements to be made like speed, usability of SBT, maturity of the Eclipse based Scala IDE... - repetition of case classes. I have no idea what is meant with that. I think that writing a model of your domain in scala is a truy joy compared to java. And pattern matching and standard marshalling/unmarshalling to json etc is great. - the language being inaccessible and experimental. This is not my experience at all. Like any language it takes learning. But if you're looking for a language that supports both FP and OO I find it very coherent and well thought out. I'd say beautiful even. For me the coursera courses on FP with Scala and Reactive programming with Scala have been the critical power boosts in becoming proficient enough to make the transition from hobby interest language to professional everyday tool. - 'if you want true strong type systems use Haskell'. To me the 'impurity' of FP in Scala is it's strong suit. On the one hand for getting stuff done and on the other for using the vast ecosystem of JVM libraries and frameworks. Also I think that the writer will encounter quite a few inscrutable operators and overwrought type systems (like his complaint about Spray) in the world of Haskell.
To finish up I'd like to state what I like about Scala: - FP in the real world of web applications and mutable state. Accessibility to colleagues who come from OO & Java - Well thought out coherent language. Especially in combination with the Coursera courses I have just become a better programmer and system engineer. - Good interoperability with Java frameworks etc - good support for horizontal scaling, near realtime processing, non-blocking processing etc ie reactive programming.
Some things I have mixed feelings about: - reinventing the whole Java stack. It is true that f.i. non-blocking support has a pervasive 'disruptive' influence. But for me there's great value in mature well know libraries, server, frameworks that just work. - sometimes there are very common use cases that need quite a bit of research. F.i. it's not easy to find out what the 'canonical' way of processing xml is. - stability and documentation
MMDV (=My Mileage Did Vary)
The compile times criticism is probably one of the more valid ones. Was incremental compilation enabled in Gradle, though? It was only specified that daemon mode was used.
The libraries and community criticism, I think, is completely unfair. There are lemons in every community. Part of getting to know an ecosystem is learning the parts you don't like. For example, I don't think that anyone should attack the entire Java ecosystem simply because Java EE with its EJBs exists, or because Struts exists, or WebSphere.
Is the magic syntax criticism specific to Spray and SBT? But I thought that Gradle was the build system, and that's in Groovy. I'm a bit confused, here. Again I think this is about picking libraries you find readable, and again I think it is not fair to judge an entire ecosystem because of one or two bad library choices.
The HTTP header criticism...is this about Spray again?
Not using Scala because it doesn't have Hindley-Milner type inference is not fair, either. This seems like an unusual standard for which to hold any language, really. Is it only ML languages like Haskell that have this?
Really I'm not sure why any or all of these would make Scala an inaccessible language, or even what inaccessible means in this context. Is it simply that Scala has too many language features? So should we all go back to BASIC? Or is Java the answer? But wait, Java is adding more language features, too! Where do we draw the line? In the Java world, there are so many libraries that provide the functionality that Scala has baked in. Are using third-party libraries such as Guava, Project Lombok, and LambdaJ really preferable to using Scala?
I definitely agree that you can make code unreadable by using too many language features or libraries, but it should be agreed upon what the best practices are for a project between its developers. For instance, on a Java project, everyone might be using JUnit and Mockito for unit testing. Then one day, a single developer decides he wants to introduce PowerMock or something, instead. His pairing partner could explain to him why this is a bad idea; or it could be rejected in a code review or similar. The same idea holds for Scala, I think. If not everyone understands something like implicit types, they should be avoided.
It starts with a criticism of a build system that is most likely SBT. Now, for all its strengths, you could not pick an easier target than SBT if you wanted to bad mouth a piece of Scala software, but what we get is:
* It is slow to recompile the build definition (true, not the most complex build files I ever saw ever took anywhere near that time); * I didn't bother to learn the syntax (or what was going on).
Is that it? If all you have to complain about SBT is this, then you never actually made even a passing attempt to learn to use it. That doesn't make me much confident about the author...
Next, the author has been writing Scala code for the past two weeks. Scala is not, I argue, as complex as people make it to be, but it has enough different concepts than what most other languages offer that you simply don't pick it up in two weeks, just like you didn't learn your first programming language in two weeks.
If you come from Java, two weeks of Scala let you use Scala like Java: you'll produce working software, though not in any idiomatic style. Well, we pick later on that the team is using Spray, and Spray is a very idiomatic library. You do have to unlearn many habits to pick it up, and the author doesn't seem interested in unlearning anything he "knows".
He picks Scala because, hey, there were doing XSL and doing XML processing, so Scala must be good at it, right? Well, actually, no, but I can see why one would think that, and also why one would be disappointed that it actually isn't, but picking the wrong tool doesn't mean the tool is bad: it's just not the tool for that.
So we go to TDD, where he comes up on Scala awful compile times (which troubled him with SBT before). That is a problem that Scala community has faced, and it has produced solutions to that problem. Specifically, it has adopted SBT, a build tool which can compile incrementally (and automatically on change), and even execute just the tests that are affected by a change (automatically as well).
Of course, the author, having chosen Scala, decides to ignore the existing solutions and picks up Gradle, which supports none of this. Now, Gradle is a very nice build system, but, again, the author picks the wrong tool and proceeds to blame the wrong thing from it.
Next, the author proceeds to have problems with libraries -- problems somehow not shared with the rest of the community (see comments by other Scala users). He mentioned stability problems, and then mentions two pieces of software with excellent documentation, extremely stable, and supported across a broad range of versions of their dependencies.
Now, choosing Spray when you are not familiar with Scala was a terrible decision, and I can well see where the author had trouble using it -- while not agreeing there's any problem with Spray itself. Having trouble with Specs2, however, makes me seriously doubt his abilities -- if he truly had trouble with it.
Next he proceeds to some discussion of simplicity, and I'd grant that Scala is not simple. However, he ties that to a lack of regularity, which is interesting in that Scala is highly regular, much more so than Ruby. It just allow different things than the languages he is used to, so it looks different.
I can buy "looks different" -- yes, it does. But the author's inability to realize how regular it is just goes to show that he has a very, very poor knowledge of Scala. That's not a problem with Scala, it's just that he didn't learn Scala, and it keeps showing.
So, having not learned Scala, he tries to accomplish something that required a specific Scala knowledge he lacked and fails. And somehow that's Scala's fault and Spray's fault, not his.
Well, I admit it: if you don't learn Scala, it is very difficult to program in Scala. That's certainly not the case with PHP, for example, but I have certainly struggled with rather simple tasks in Ruby when trying to write code in Ruby without learning it. I just never blamed Ruby for it.
Next, "everything is a type". I disagree that this is in any way a problem -- if you are going to complain about that, how about just writing "Scala is a statically typed language" and leave it at that? We all knew that, didn't we?
So, having chosen a statically typed language, he dislikes the fact that it actually tries to use types? Weird, but at least he doesn't make it a problem of Scala itself.
On the other hand, it took me thirty seconds to find RawHeader, which allows arbitrary headers, which indeed would be a weird thing to be missing. It's right there, among the other headers. Among, say, Origin and either Access-Control-* headers, which happen to be the CORS headers, all of which appear in the API docs, so what gives?
Maybe they are new headers? Well, the CORS headers are new, if not that new, but maybe the article refers to something that happened months ago. The raw header is there for quite a while, as you can see for yourself here: https://github.com/spray/spray/blame/master/spray-http/src/m...
At this point, I don't even know where the author is coming from, that he failed to spot this. It is certainly not Spray's fault, much less Scala's.
Next comes a rant on lack of H-M type inference. Well, we all would have liked to have more type inference (without making the compiler even slower!), but separate compilation, subtyping and full type inference is not a solved problem. Which doesn't mean we can't gripe about it.
But there's a damning comment among it: the error message he describes in his "workflow". Hey, Scala infers the return type, so he doesn't need to add it, unless he's doing recursion of calling overloaded methods. If he were doing that, however, the error message would be different.
What the error message says, however, is that he is using procedure syntax -- that is, a method returning void in C/Java parlance -- when he actually intended the method to return something. He doesn't need to add the type, he just needs to use the correct declaration:
def method() { body } // procedure (unit-returning method)
def method() = expr // function
He spent two weeks programming in Scala, then went on to write a blog about it, but he still hasn't figured out a simple detail like this, despite the compiler telling him what the problem is?
Yes, beginners might well struggle with this oddity, but for two weeks??? And despite having fixed it throughtout the program? Really?
Now, detour briefly through long vs int, which I actually agree with, but saying he was "reminded" of it shows a complete lack of familiarity with statically typed languages.
Again, fine that you don't like statically typed languages, though I think one ought to first learn one of them before criticizing, but you could start and end your post with "I don't like statically typed languages".
Then there are other issues which he enumerates but don't describe, and which I can only disagree with. Horrible repetition required by case classes? Err, what repetition?
So, in the end, it seems that what the author really wanted to say is: I don't like statically typed languages, and I tried to use one for the wrong reasons, in the wrong way, without learning it, and failed. No need to blame Scala for his bad decisions.
Scala seems to have a huge image problem. I think part of the problem is that Odersky and crew have never written the treatise on how to use Scala's OO and FP effectively. I'm surprised that Typesafe didn't come up with their own web framework instead of using Play.
One lesson to be learned is that these days you need good IDE integration and fast compiles (incremental) for rapid development. But Scala IDE support has come a long ways in the past year or so. The Eclipse Scala worksheets is awesome. I like it better than a standard REPL. Intellij support is still going strong too.
