My Scala/EJB post generated plenty of attention, as I expected. I left the comments there for others to discuss the post - this is my reply to a few of the points.
EJB 2 comparison
A number of comments arose about the comparison, especially those feeling it didn't make sense. Basically, EJB 1/2 was one of those technologies that appeared at first glance to have a lot of promise, targetting known pain points. But over time everyone figured out that the approach was needlessly complicated and created more problems than it solved. Collectively, developers who lived through the era wonder how on earth it got adopted - in hindsight it seems obviously bad.
As I indicated in the blog, I was trained in EJB, but it was obvious to me that the technology was deeply flawed. So, I argued against its adoption, and never had to use it in anger. I see Scala as equally deeply flawed, thus am arguing against its adoption, and endeavouring to avoid using it in anger.
Since I had that same reaction in my gut as I did with EJB, I used the analogy - a high level analogy, not a low level one. To me, Scala really does feel as bad an idea as EJB 2 did.
Fantom
The trouble with today's tweet based soundbites is that it is difficult to have a slightly subtle position on something, and I'd say my position on Fantom is subtle. I think Fantom is hugely interesting because it shows what happens when you challenge your preconceptions about what a static type system should do (and also because of its ability to turn shared mutable state into a compile error).
The subtlety is that I don't see any evidence that the majority of the static typing community of developers (ie. Java) are willing to take the radical step that Fantom offers (paring down static typing to the bare minimum). For me, I think Ceylon and Kotlin are both being seduced into adding more to the type system than developers really need.
In my Devoxx talk, and in the evaluating Fantom blog post, I made the point about the type system. I also suggested that Fantom might well appeal to those from the dynamic side of the fence who have been bitten by an absence of static typing (like Ruby).
Thus, Fantom makes a good counterpoint to Scala. They are pretty much polar opposites in the static typing space. And I find it interesting and worth noting that Fantom spends its language complexity budget on things I care about, whereas Scala (over)spends its complexity budget on things I don't care about.
Thus, while it may seem like I'm saying "use Fantom, use Fantom, please use Fantom", I'm really just using it as an effective counterpoint. Pointing out something that in my opinion has better answers to the hard questions is not the same as saying go and adopt it. Linked yes, but not the same.
The other points
A number of comments from the Scala side noted that modules (of the type I was referring to) were a problem. I will also willingly acknowledge the heritage of the word module in other contexts.
On concurrency, some got the message and some didn't. My point is that you can design a programming language such that shared mutable state does not compile. Scala talks a good game in this area, but in forensic analysis it doesn't match up.
On the type system, some feel the strength of Scala's approach is valuable, while some like me see it as way too far beyond the point of sensible returns. I also maintain that if I add a string to a list of integers I should get a compile error, not a list of Any. With type inference and implicits, there is far too much potential for things that should be errors during maintenance/refactoring to not be spotted for my taste.
On syntax I was primarily driving at the open and flexible nature of the design. With optional method invocation dot, optional brackets, optional semicolons, symbols for methods/operators and implicits thrown in, it will necessarily be harder than many languages to work out what any individual piece of code does. And there are consequences. That flexibility leaves ample room for mailing list discussion about the "right way" to do something. It also makes it very difficult for IDEs and compilers to figure out what the code means - which is the reason for the slow compile speeds mentioned in a number of comments. Personally, I find the goal of the open and flexible syntax (arbitrary DSLs) to be not worth the pain. There are other neater ways to think about DSLs.
FUD, criticism and my goals
I was accused of spreading FUD. No big surprise there. My view is that if that was my goal I would have done a better job in showing the more complex interactions of the feature set, or just flat out lied. No, I think my goal was a bit more interesting than just FUD.
Basically, the key goal with the blog was to provide reassurance to others who feel as I do that Scala just isn't right. I opened my blog talking about the Scala community not liking dissent, and I stand by that. A number of reactions actually praised my bravery for being willing to stand up to the "Scala cult". I don't think its my imagination to suggest that Scala's enthusiasts have managed to stifle criticism and given the impression that you'd be crazy not to use Scala. If I have inspired confidence in others to speak out, or question what they've heard, then that is a Good Thing in my book.
Beyond that, the long term theme of this blog has been that we should look again at just how much Java threw away from C, and judge new languages as much on what they threw away as what they added. For me, Scala didn't throw enough away and added too much - a lethal combination.
In the end, as Dick Wall suggested, individuals should try it for themselves. I just ask those that do to think deeply before adopting it, and as I said in a tweet - make sure you get both the positives and negatives before deciding.
My personal favourite responses
These are selected because I found them funny, or the point they made was interesting to my biased eyes. I'll let you figure out which are which!
Colebourne is a sad, old twat.
Anonymous comment
He sounds like a naughty schoolboy who misses being spanked..
AlSpeer
I developed with Scala for about a year. I learn a lot and got to work with some smart people. However, then I had to maintain code and, oh boy, it was like being forced onto a diet of live insects.
Anonymous comment
I've only evaluated Scala at the surface, but simply want to back up Stephen in agreeing with the subjective scary feel of the language. I can think of no other languages where I've scanned examples and documentation, and wanted to run away as I have with Scala.
Casper Bang comment
I'm sure the type system is genius, but I'd prefer if it was sensible genius instead of mad genius. I like my sanity.
mcv comment
Years ago, I was pretty excited about it. I saw lots of things Java couldn't do, and that would make my life easier. But then more features. And more. But I think that even before I got totally turned off by the language, I got turned off by the community first. It felt very elitist and unwelcoming to people who may be just interested in a language to 'get things done' instead of one you can put on your resume and earn an immediate 'smart like hell' badge with.
chillenious comment
What can be worse than a likeness to EJB 2? A likeness to WS-*
Paul Sandoz tweet
You know who else compared Scala with EJB? Hitler.
Runar Oli tweet (which I took in good humour)
According to @jodastephen "Scala feels like EJB 2" http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html ... will the next article explain how #Scala will cause world war 3?
Mario Fusco tweet
FWIW, I've used Scala for two years, written tens of thousands of lines of code in it, and find your criticism incisive.
Coda Hale tweet
Not that I really should comment on Scala, but I feel that 50% of it would be better than 100% of it -- "too much of everything"
Tatu Saloranta tweet
i used scala for a few months. it sounded very promising, java without the verbosity. but in the end i decided to stop using it.
The biggest problem for me was readability. Scala is the first language that i've learned where at first i couldn't just read code and immediately guess what it does.
adabsurdo
My personal experience in wrapping non-trivial Java libraries in Scala and Clojure is that with Clojure it usually just works and it works quickly. In Scala I am usually reduced to an extra hour or two of adding manifests to signatures until the compiler accepts it.
I am disappointed with Scala and having lived through EJB 1, EJB 2 and then onto Spring and EJB 3, I agree with Steve it makes me feel exactly the same as I felt about EJB 1 and EJB 2 - that is I am being sold overcomplicated technology as a panacea.
Tim Clark
I have similar feelings about Scala. It's a bit like C++. The difference is: I found a subset of C++ I liked.
Glyn Normington tweet
Scala sucks, and i'm blessed to know that i'm not alone feeling that way.
Evgeny Shepelyuk tweet
And finally
I don't see myself writing a post in quite the same way about Groovy, Ceylon, Kotlin, Xtend, Clojure,... I may critique them (all do or will have flaws), but I don't see myself ripping into them in the same way. There is just something about Scala...
My final thought is that it is OK to look at Scala and decide against. You're not alone.
so you decide to take all favourable comments to your idea, while ignoring all the valid points made against your poor comparison of a strong language against random technologies?
ReplyDeleteIt's your blog and you can rant about any topic you like as much as you like, but at least try to make a decent comparison.
None of the points that you mention against scala are any of the biggest problems. the only one that really stands is binary incompatibilty, which you didn't mention. that shows that you have very little experience with the language, however, you decided to openly criticise whatever you thought was not good.
by the way, the fold operations, is far from noise, is actually very expressive once you know what's it used for.
Scala can teach you not just functional programming, but also to become a better programmer. so i suggest you try to learn it first, then post.
I'm curious, Stephen - is there any one feature or set of features without which Scala might be decent? Implicits? Methods that can be named anything? Flexible method invocation syntax?
ReplyDeleteI just love it to see how people who post such blog-posts forget how they make a complete fool out of themselves and give the java 'community' such a bad name that they're actually helping the scala community and destroying their own reputation (and hopefully career). Keep it it coming! *grin*
ReplyDeleteNeedless to say I hope people from the real java community also stand up against posts like these.
ReplyDeleteScala is a Formula 1 car created by a language theory expert. As such it excells. It handles great on the test tack. That doesn't make it a good general purpose car. It will win all fun benchmarks, but fail utterly in the boring real life tests.
ReplyDeleteCheers,
Mikael Grev
Meanwhile, did you find those type-type-types? Or was it just FUD? Ok - let's call it a joke. Or what is it?
ReplyDeleteI must be dense--I still don't get the EJB2 analogy. I too had a look at EJB2, said "that's ridiculous--I won't write all that boilerplate", and ignored it. It helped that I didn't really understand at the time what problems it was trying to solve. And then EJB3 came along, and I use it happily now.
ReplyDeleteWith Scala, I never had an EJB2 moment. I use it happily without having to know about any boilerplate. Sure, there is complexity with Scala, but it's not my complexity. What is it to me that somewhere out there someone is fretting over the difference between generic type parameters and abstract types?
I am willing to debate whether we have reached the limits of utility with strong typing. The creators of Dart surely think so. But that's an argument that one can surely have without emotional appeals to an unrelated enterprise technology.
You probably think you know what you are talking about. You don't, but I am not here to argue that point. Let me know if you wish to learn the subject matter at hand so that you can hold coherent discussion about the topic on which you are compelled to comment. I'm serious; maybe you are too?
ReplyDelete@fractal, Well aware of backwards compatibility problem. Thought it was covered under modules on previous post.
ReplyDelete@Josh, Its the combination of features which is a problem to me. That combination is well chosen for the goal of an open and flexible language good for DSLs, but I doubt the goal and reject the consequences. One of the best comments I saw in response was that Scala exposes stuff that would normally be inside the compiler/language. Thats why it might be feasible to write a new language with Scala as its hidden internals, like C# allows a drop through to C. But that language would be a long way from Scala in its style.
@User-unknown, The type-type-types were in Steve Yegge's mind, not mine. And I did lead the quote with the word "fun". Its definitely how Scala feels though.
@Cay, You're thinking too much about the detail of EJB. Focus on the last para in the EJB section above.
@Tony, Thanks for the offer, but I plan to stay a long way away from Scala.
@fractal '... None of the points that you mention against scala are any of the biggest problems. ...'
ReplyDeletePlease, excuse my wish for a code that is understandable and go create some powerful mess.
@Irmo to add to the discussion, would you mind adding what you don't agree? Why would he be wrong?
ReplyDeleteIt is his opinion. You can say he is making a fool of himself, but I don't think anyone would share your sentiment.
I would say his posts are about expressing his dislikes (well everyone has his/her own opinions) while at the same time being diplomatic about it. And he is saying points for points what he doesn't like and doesn't agree. And if you get different opinion, well, why don't you say so.
Well, maybe he is wrong in his opinion, but saying so is that FUD? A lot of people has a different opinion, everyone will think he is right. At some point its mature to agree to disagree.
I think everyone who is a spectator to this (not related to Scala to any way) will see that any opinion that is negative about Scala will be met with harsh counter attack by either saying its FUD, attacking the posters' character and saying it is just plain lie. Few people will bother to counter the *argument*, the rest is just saying anything bad about the poster is.
Can't anyone from the Scala community have seen this would be seen as "defensive" to an outsider? Nothing is perfect, not Scala, not Java, not Ruby, not LISP and so on. Everything is design for a certain trade off. If you see this kind of post, explain, advocate or even evangelize the trade off. And then move on. Any attacks to the character instead of the argument will be seen as a negative behavior to anyone outside the community.
Stephen, I am not referring to Scala specifically. I am referring to the fundamental theory that gives rise to valid complaints about Scala and whatever else you may choose to pursue. You are clearly lacking in this area and I think it would be in your interest to rectify this matter, especially given your (misdirected) enthusiasm for the topic. Perhaps you might also agree.
ReplyDeleteI admit to a tad of "cringing" in embarrassment on your behalf. I hope you understand.
You say the type system is too strong, but then just below that you say that it's not strong enough because it doesn't provide immutability guarantees. To me, this really doesn't sound liked a well reasoned argument, it sounds more like you're arguing that it is different from Fantom. Of course it is. Anyway, while I admit that tracking immutability would be nice, I've never had a problem with Scala lacking it in practice - and would give me far less in practical terms than Scala's type system does - I certainly wouldn't swap.
ReplyDeleteAdding a string to a list of integers - that is a rather odd example to use. How about being able to _safely_ add a Cat to a list of Dogs and getting back a list Mammals, that being the closest common supertype - now *that* sort of behaviour is *very* useful.
Your argue that Scala is too complicated, but you don't specifically say how it is complicated. It's all very well saying you don't like Scala (each to their own), but I find it hard to read a blog post that speaks so negatively about Scala (especially from such a highly respected Java developer) when it provides such weak arguments. Not only that, but when both posts you have made does not mention any good points of Scala, you must understand why people would think you might be biased in some way.
Lastly, I see very little response from you when people ask how much Scala you have actually written (this not being the first time). I think it is human nature to find arguments against learning something new. That's just something we all have to fight against. The benefits are worth it though - I have seen them in real and non-trivial projects. My Scala code is far less complicated than the Java code I write, and the business logic is much clearer - because in Scala, it is the business logic that I can concentrate on.
Personally, I appreciate these posts, as they can raise some valid criticisms (not everything in wrong... :-P), and the comment section is open and some comments are worth reading: so there is a healthy criticism of both pro and con arguments.
ReplyDeleteI will just ignore the insults, most of them come from anonymous people, so are pointless (and if you are paranoid, you could say some of them come from anti-Scala people willing to give a bad reputation on Scala fans... ;-)).
I am a bit skeptical when it is said that Scala is unusable for real projects. AFAIK, real companies, not small ones, have bet on Scala and get things done.
Yes, the type system is quite complex. But one has to hit it mostly when doing high level library stuff, like the collection one. Average developers like me can code happily without dealing with that stuff. And then learning enough to get more familiar with it, with time. I saw some useful things with this type system, like enforcing at compilation time what factory methods are mandatory when building an object, and in what order, if needed...
On small projects, it can be overkill, I suppose. On big projects, it can prevent some subtle bugs.
Personally, I don't buy the assertion that concurrency fails because immutability is not enforced. It can be a good idea to have the compiler to check that, but it seems a bit impractical when you deal with Java libraries: how to check if Integer is immutable while Date isn't? Rejecting all non language-specific objects is a bit extreme.
Scala relies more on programmers' common sense and experience. Yes, newcomers to the technology can make errors, like I did when I started to code in Java (and other languages!). But that's why sane teams enforce peer review by a more experienced coder...
Anyway, I am an average programmer, starting with imperative languages like Basic and C, progressively getting some hint of functional programming via Lua and JavaScript, learning OOP via C++ and Java.
I had a look at Fantom, and found it interesting, but for various reasons, didn't started to learn it.
I started to learn Scala on my own (no real work experience with it, yet?) and I enjoy the trip, despite some issues.
I like maths, but I am not good at them, not at ease with abstract concepts. Yet I can use Scala with fun and profit (not financial one...).
A last word on the community: some vocal members have rough edges (but can be helpful), some discussions go on high level (I just skip them), but overall, concrete questions (in the mailing lists and Stack Overflow) are quickly and precisely answered. The community is helpful, often passionate (sometime too much, taking attacks on their favorite language as personal attacks, perhaps because it questions their choice and involvement) and overall nice for newbies and experienced people alike.
Oh, last remark: I can see some rare job offers asking for Scala competence in France. I have yet to see one asking to know Fantom. This is not an attack on the latter, and certainly not a measure of merit, just a small fact.
There is a course "Programming Language Theory" in major universities now. You just didn't take that course. Or forgot it, I don't know. That is the reason of your difficulties ("type systems as sort of mumble-jumble").
ReplyDeleteType systems aren't apparently tied with Scala or whatever. It is just a good engineering. See: if you detect an error earlier, that error is cheaper.
And it doesn't require any sort of sacral knowledge. All you must know about the whole Programming Language Theory subject is packed in one- or two-semester course in universities nowadays. That's all, it is like, well, linear algebra. It is highly useful from an engineering viewpoint.
If you're in non-university mood than you can pick a book and teach you a linear algebra or programming language theory yourself.
It will make a better engineer from you, and your main programming language - be it python or scala - doesn't matter.
And for the note: the type declarations from your previous posts are actually pretty readable For people who don't know Scala, but know ML and OCaml, for example. It presumes some knowledge of type theory (which is a part of programming language theory), yes, but hey, it is taught in universities.
ReplyDeleteLanguages that requires taking a one- or two-semester course to understand are language that I will keep ignoring.
ReplyDelete@Anonymous
ReplyDeleteYou've just demonstrated why some perceive Scala to be a complicated language, not suitable for the larger developer audiences. The problem is that you are right, in the sense that if you did take that course, surely working with higher order functions, typeclasses, type variance becomes much easier.
Many developers just do not have that background, and perhaps Scala just isn't the language for them. Just see how much pain Java generics without co- and contravariance gave us. It is my opinion that people should not be using programming concepts they don't really understand. Java is relatively confining, but come with few surprises.
Fantom, Kotlin, Ceylon, etc. has the same feel, trying to find a common ground within a set of design parameters (e.g. portability for Fantom, metamodelling for Deylon). Some people prefer that, and live within those restrictions. Offering lecture isn't going to help, but languages that offer more than Java, but without needing lectures, will.
Meanwhile, I still prefer Scala. Just not all of its audience.
This comment has been removed by the author.
ReplyDeleteSome people are probably posting anonymously because of problems posting in another way. I tried several times with my Google account, but it didn't work, but anonymously did. Let's see if this time works...
ReplyDelete[Ah!! And now it has started to delete my text when it fails to post too! Beware future posters!]
But people don't come into designing bridges without knowing how to take a derivative or two. Software engineering is engineering, after all.
ReplyDeleteJust to clarify, Runar Oli post was a joke in continuation to another tweet from Alex Feinbeg : Godwin's law of software: as technology/paradigm approaches mainstream adoption, probability of comparison with CORBA or EJB approaches 1.0.
ReplyDeleteWith a minimal intellectual honesty, you would have logged this post too next to Runar quote...
But I can understand that quoting posts that without context can be perceived as extremist is better for your business...
A good debate, and a couple more thoughts...
ReplyDelete@Anonymous 09:13, All languages have, as Josh Bloch puts it, a complexity budget, an amount of complexity that the designer can choose to spread in different ways. Scala spends a lot on the higher order type system, other languages spend their budget in different ways, such as less parameterized types and protection against shared mutable state. These are design choices and trade offs, and we can agree or disagree on them. Normally a language leaves some complexity budget left for the future (Java did), whereas IMO Scala has not only spent all of its budget, its gone beyond the budget and into "complexity debt". My blog posts also describe where I see the complexity - notably free/open syntax, implicits and type system.
@Anonymous from 09:44 to 11:08 and Jesper, There is a clear question of how much a language expects in terms of its university/theory knowledge. IMO, Scala has higher expectations than Java on this front. I can appreciate what it offers, but it isn't a direction I'm enthused about (programming is as much an art as it is a engineering). Instead, I'm more interested in languages that strive to tackle major productivity issues, such when garbage collection was introduced in Java. If the language also makes the theoretical side accessible to those without that background then the chances are I'll like it.
@Anonymous 11:13, The context was and is in the provided hyperlink for the curious.
After thinking a litte more about the matter, I realize it's probably a combination of factors that turns me away from Scala.
ReplyDeleteImpedance mismatch
First of all, it does not occupy the same territory as what its effectively replacing. As a successor to Java, and as a contrast to Scala, C# has enticed me time and again with the manner in which it introduces new features and caters to floor-developers problems. This is probably the same effect that causes people to categorize Scala as academic and elitist, and arguably, a dividing rather than a unifying language. It feels to me like an inherent impedance mismatch, even if you make 4ohm speakers work on a 8ohm signal, it's a fragile setup in the long run.
Celebrities
Secondly, although proponents (Dick Wall) speak of ignoring what celebrities think, that's a perfect example of elitist thinking. While it's entirely probable that S.C. graduates working green-field ops in the Valley have great success with Scala, I don't think it's fair to extrapolate this to general purpose corporate computing environments. Indeed, the rest of us mere mortals, look to "celebrities" because they sit well above the vantage point of the average practitioner. In a way "celebrities" then offer sanctioned standards. So when I hear Neal Gafter say he thinks there are too many ideas in Scala, Hejlsberg talking about good [language] taste being extremely subjective and hard to define, Ted Neward talking about how Java developers shouldn't worry as there will always be a need for burger-flippers; it all adds to my nervous feelings about Scala. I'd like to hear more, not less, from my celebrities about Scala.
Interoperability
Third but not least, it strikes me that while all other languages seek to form a compromise between dynamic and static, Scala turns snoppy and marches in the direction of wanting to statically model anything and everything. However, the world is schema-less and a lot of times you can just get a lot of stuff done and forego static aspects where it makes good sense. Even javac went too far in this regard, with anal compile-time complains about catching of exceptions that aren't being throws etc. etc. The compiler should aid without getting in the way.
@Casper, FYI
ReplyDeleteGafter on scala:
"You know, that would be my question. I certainly think there's room for languages other than Java. If I didn't believe that, I wouldn't be working for Microsoft right now. But even on the Java Virtual Machine, there are some excellent alternatives to Java like Scala, for example.
You know, if I were working on the VM and had my choice of language to use, Scala would be very high on my list of preferences."
http://www.infoq.com/articles/neal-gafter-on-java
@Casper
ReplyDeleteTed Neward is also evidently a Scala enthusiast (incidentally, do you really find comfort in his "burger flipper" remark?)
http://www.javaworld.com/podcasts/jtech/2008/061008jtech.html
Dear Stephen, one post with lacking arguments was enought. As second follow up post with more partial and lacking information (not to talk about the selection of quotes) is too much. If Scala is so bad, can you please explain why succesful companies like Twitter, Foursquare or The Guardian use it intensively? And they are more than happy with it?
ReplyDeleteYou know what I think it's the problem? You are an expert in a field. You know about dates. You've worked in Apache Foundation. And suddenly you believe you know more than you do. Maybe you won't do Joda with Scala (that Scala may not need it is another thing), but Scala is good, as it passed the test of being used in real life for big applications.
And in the end this is what matters, that the language is broadly used. Maybe Haskell or SmallTalk may be better languages, but if they are not used outside academic interest, who cares? The purpose of a non-academical language is to be used. Scala is. That's success.
As Mr Odersky said about your previous post: Scala is Play Framework. Whoever compares Scala with EJB 2 doesn't undertand it.
Please step down from your ivory tower, and then aside. Your prejudices founded on no experience and whims aren't needed in the IT community.
@Casper,
ReplyDeleteI don't suppose you would consider James Gosling a a "celebrity"?
Apparently the inventor of Java loves Scala and is an adviser to Typesafe.
http://www.adam-bien.com/roller/abien/entry/java_net_javaone_which_programming
@Anonymous n
ReplyDeleteI was referring to Ted Neward's (often brutal and colorful) opinions of those that have trouble getting a feel for Scala, as evidence of a complex/sophisticated (take your pick) language. FWIW I've also heard the venerable Gilad Bracha, while finding Scala the best choice on the JVM, saying it's probably not for everyone. The question then remains, what *IS* for everyone?
@Anonymous n+1
Certainly, but some are more trustworthy than other and it's 15 years ago he spearheaded with Java. Also he has a history of being proponent of whatever he's involved with this month.
@Casper
ReplyDeleteGroovy inventor James Strachan: "I can honestly say if someone had shown me the Programming Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."
@Stephen,
ReplyDeleteYou once lamented that Java was making you "scream" for it's lack of "self-types":
http://blog.joda.org/2007_08_01_archive.html
So we know you like at least one thing about Scala.
Java is so bad it makes Scala to look great in comparison. Way to fight over which language will be driving those server-side services.
ReplyDelete@Casper: "Scala turns snoppy and marches in the direction of wanting to statically model anything and everything"
ReplyDeleteActually scala even allows you to be dynamic: http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/scala/Dynamic.html
I have never tried, but maybe one could write scala with [AnyRef] everywhere if thats more to your taste.
One could argue that we don't need a Scala or a Fantom. Maybe we just need a CoffeeScript for Java ( I asked this yesterday on SO: http://stackoverflow.com/questions/8246132/is-there-a-coffeescript-for-java-in-other-words-x-gets-compiled-to-java ). Currently it looks like Xtend is the Coffeescript of Java.
ReplyDelete@Anonynous 14:38, I've spent a long time looking at Java and trying to help it move forward, which is slowly happening again - you'll find a lot in the archives about it. Scala *does* fix some of my issues with Java, but the other items it brongs negates the good parts for me.
ReplyDeleteOn "Celebrity", my view is just my view (as are those of a variety of names you might mention). But if my view makes others think a little more deeply before adopting something that in itself is a Good Thing.
@Adam, I think Xtend looks interesting, and I hope to investigate it more soon. The Coffeescript concept of a wrapper to the underlying definitely has some appeal to me.
"CoffeeScript for Java ( I asked this yesterday on SO: http://stackoverflow.com/questions/8246132/is-there-a-coffeescript-for-java-in-other-words-x-gets-compiled-to-java ). Currently it looks like Xtend is the Coffeescript of Java."
ReplyDeleteThe problem with this idea is that whereas the differences between modern dynamically typed languages is substantially in syntax rather than in the type system, the differences between statically typed languages is on both sides: both syntax and type system.
In a statically typed language, the type system is much more important, more visible to the user, and more idiosyncratic. Furthermore, static languages tend not to be as amenable to the kind of metaprogramming that you can do to "fake" language features in a dynamic language.
So whereas you can easily create a "new" dynamic language by wrapping a new syntax around an existing language, that's not quite as easy for a statically typed language. The user cares about the type system a lot more. Indeed, many of the real issues with Java are rooted not in its syntax but in its type system. People perceive that as verbosity, and blame the syntax, but in fact that's often not the real underlying cause. More often the problem is actually the barriers Java's type system puts in the way of abstraction.
"With optional method invocation dot, optional brackets, optional semicolons, symbols for methods/operators and implicits thrown in, it will necessarily be harder than many languages to work out what any individual piece of code does."
ReplyDeleteLast night I was playing around with some multivariate analysis stuff. I grabbed Scalala (A Scala Linear Algebra library) but it didn't quite work how I wanted it to; I needed it to be a bit more Matlab-like. So I added a tiny little DSL wrapper and now I can write matrix math like this: val covarianceMatrix = 1.0 / (nsamples - 1.0) * sumOfSquaresMatrix. Looks like plain-old math even though it mixes matrices with scalar values; easy to write, easy to understand. Seems to me like all those optional syntax can make for some very clean understandable code.
@Stephen, in response to a couple of your points.
ReplyDelete1. Concurrency. No one who is writing Scala code is getting bitten by bugs due to shared mutable state. The standard library makes it very apparent which types are immutable and which are not, and you are encouraged to only share immutable types between actors or threads. (It's also easy to write your own immutable types to share) Your argument here is entirely based on your ideals and feelings and not a single ounce on reality or practice. It's ironic(or is it hypocritical?) that you rail against Scala's type system for adding complexity long past the point of diminishing returns. You then lament that it is missing a feature you want that no one who actually uses the language even needs in practice!
2. Syntax and compile times. You claim that Scala's flexible syntax is the reason for its slow compiles. Again, you are showing ignorance and spreading false information. Scala's compiler is built on a pipelined architecture consisting of 27 phases, only the first of which is parsing. I promise you that Scala's slow compilation time has absolutely nothing to do with this first parsing phase that handles the flexible syntax you are so scared of. :-) As for readability, I can witness to you that after reading the stairway book for a week I felt comfortable reading most Scala code. It's really not that hard to learn the syntax or to read other people's code!
3. Fantom. Most people aren't copying what Fantom does because they probably think its type system is bad idea! I've looked at the language a little and honestly it gives me a bad feeling. I don't go around attacking it because I don't know enough about it, but honestly the ball is in Fantom's court to prove that its "radical departure" from other statically typed languages is actually worth it, and in this regard you would be much better off extolling Fantom's strengths than wasting your time attacking Scala.
I respect that you are doing what you feel is right by arguing against Scala's adoption. If you don't like a language, then you certainly don't want the job market to become flooded with positions using that language! However, I and others truly believe that Scala is the best JVM language right now and for at least another decade. Don't be surprised, then, when we push back and defend it, because we DO want the job market saturated with Scala jobs!
@Casper I think your argument falls flat at the start. We should all be able to agree that Scala is not a replacement for Java. It's something different. If we accept that, then much of the criticism about Scala's unsuitability for Java engineers falls away - because it's not trying to be the next Java.
ReplyDelete@User-unknown, I guess Steve Yegge's "type-type-types" is a reference to Scala's "higher kinded types" which are indeed some form of "Type types". Google it and you'll see what they are good for.
ReplyDelete@Josh Stone: Now we're getting somewhere. Scala is not the next Java... but I am looking for the next Java!
ReplyDeleteSince I am afraid that the all too familiar choice paradox of the Java library ecosystem (i.e. 117 logging frameworks) will now expand into the actual languages as well, I really just wanted a more down-to-earth de-facto language on the JVM.
Looks to me like Scala is becoming the predominant secondary language and I honestly wish it wasn't, there are more pragmatic candidates for this place. Of course this could also just be an illusion, the Scala crowd are tremendously loud advocates, and Tiobe still only lists Scala usage between the 51-10 place.
To anybody who feels scared with all of this:
ReplyDeleteJust start learning Scala with the PinS book http://www.artima.com/pins1ed/. It's an old edition, but the basics are there. If you can, buy the 2nd edition which covers the changes introduced in the collections. The 1st edition is available for free and there are good tutorials online about the changes, here is one pointer http://www.artima.com/scalazine/articles/scala_collections.html
If you find something too hard, just ignore it, you can learn it later if you want.
Maybe another useful pointer is the Typesafe page http://typesafe.com/. This is the company behind Scala (language, libraries), Akka (actors), Play! (web framework), the Eclipse plug-in and SBT (build tool).
One thing is sure: you won't regret studying Scala.
Think about it. Scala is many years ahead in maturity and development and the other promising new languages are, in some way, cropped versions of Scala. In the worst case you will reuse all the things you learned, but in another language.
You can start now to learn the language you will use in the future and, in the same time, form your own opinion about Scala :).
Can I just add that Stephen is a happy young twat now?
ReplyDelete@gerferra
ReplyDeleteClojure is a promising new language that is not a cropped version of Scala....
Scala is the google wave of language design
ReplyDeleteOne thing I do not get: What is wrong with verbosity? It is usually included in the critique of Java. Like someone said: Scala is a language where it is very difficult to understand what a piece of code does at first glance.
ReplyDeleteThe thing is: I have worked with system maintenance and development for more than 15 years, using C, C++, Java, Simula, php, MS Office macros, Basic, VB, Logo, Prolog etc, and when maintaining code, readability comes through as the most important factor of all. One can not expect code to be maintained by seasoned programmers for all future.
And that I think is the main Scala shortcoming: The language attacks the assumed flaw of verbosity, but answers this with shorthand of unreadability.
Hello, Stepen. Hi. I'm a one of Japanese Scala programmer.
ReplyDeleteI read your Scala/EJB2 post fascinatingly. Then, I want to put questions
to you.
1. How many "real" Scala codes did you write ?
Through the position of a Scala programmer, the "problems" of Scala you mentioned
is not problematic in "real" Scala world. I (perhaps other Scala programmers)
want to know that your critisism come from your experiences with Scala or
your preferences. I think that you should this question because you criticize
Scala and its community bitingly.
2. Who castigated those that don't understand as lazy or poor quality developers, as being second class citizens ?
As far as I know, I have not seen such people. It maybe that there is
a few people doing such things. However, such people are not majority of
Scala community.
3. Do you understand difference between
"def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That" and "Java's addAll() on a list" ?
In fact, the two do quite different work. Do you understand it ?
"My point is that you can design a programming language such that shared mutable state does not compile."
ReplyDeleteNo, actually you can't, at least if it should be practical. If you do any IO like file or network access, you're (potentially) using shared mutable state. Static variables is just a special case of shared mutable state.
1. Some say scala is hard to read but you may just not be used to it if you come from Java. If you are a non english speaking person, you may want to argue, "English is not easy to read => English is a bad language!". That would be bad reasoning, lets agree on that.
ReplyDelete2. Scala is quite easy to read if you ask me, once you get used to it (I was not). DSL may help or break here, all depending on if you belong to the initiated and intended audience.
3. EJB: It was crap from first spec. Most did not see it then but I claimed it to be a useless product from day 1 and never allowed it anywhere if I had a say. EJB is nowhere like scala (as said n times before). The EJB complexity is not to do with power but with bad design/tools/requirements etc...
4. Scala for me: I have used it for 2 years and I love it. It grows on you, especially the type system. Mostly the thread was about the type system and I think we have a clean divider for the future here. Programmers that make use of theorem provers (like type systems) will outperform others greatly. If you cannot grok this theory/utility, you may consider another profession! In fact, Scala has done things for my project I have only DREAMED about before.
Guys, leave it. He just wanted to be back on the news. What we call around here "attention-whore". Let him enjoy his opinion, it will be the real developers using the languages and the market who will decide if Scala is good or not.
ReplyDelete@Brian, Your matrix math is a useful DSL, but its also enables poor code http://www.reddit.com/r/programming/comments/dhtor/leaving_net/c10bnmu . This is a Scala goal - to give power to developers. Personally, I think a few more boundaries are helpful, especially for maintenance and mixed teams. BTW, the open and flexible point is not only about humans understanding the code, but the compiler. BTW, I think this example https://gist.github.com/1278bb05712b4f237e32 also shows how the smallest change can have a big impact. Open and flexible syntax is a trade off, and it has negative consequences that I don't like.
ReplyDelete@sreque, I'm glad that concurrency is working out for you. Scala sells itself in conferences as being good for concurrency, but I'm simply pointing out that goodness is about programmer skill through correct library use, rather than any actual language feature (where it is technically no better than Java). Syntax I mentioned above, and on Fantom I'd not expect anyone that has drunk the Scala kool-aid and enjoyed the type system to appreciate Fantom. Lots of C++ developers believe they *need* to control memory usage - eventually some realise they don't need to. Scala is a powerful language, but is not IMO suitable for the mainstream.
@kmizushima, I covered my experience in 3rd paragraph. I consider it to be a benefit of experience to judge whether something is right or not without having to spend years suffering the pain. I've also provided links to people who have tried it and found it wanting, especially in maintenance. On community, well judgements there tend to be more subjective than objective, although if I really cared I'd love to do an analysis of the mailing lists and the type/style of each thread/message. And yes, I do understand what the ++ method does and why it has a complex signature.
@Jesper, Technically, IO is shared state as you say, but a developer is far more likely to think about the problems of shared access to an obvious resource like a file, than to a static variable. I tend to think language design is as much about understanding the psychology of the target market as clever technology.
@Anonymous 10:07, My objection is not to Scala's syntax being different (although I have posted previously about why I think certain choices are the wrong ones). No, the main thrust of the syntax objection is around overuse of symbols and an open/flexible style, which combine with features like implicits to create the potential for difficulties for both humans and compilers to understand what is going on. I'm glad you enjoy Scala, but I don't think that means I'm a dinosaur and should leave the profession. A few years ago, Ruby developers claimed to be 10 times more productive than Java and that they would outperform all others who stayed with Java, yet Java is still here and hugely successful (and I still campaign for an improved Java). I just ask you to accept that nothing, including Scala, is a silver bullet.
@Anonymouse 09:26
ReplyDelete"One thing I do not get: What is wrong with verbosity? It is usually included in the critique of Java. Like someone said: Scala is a language where it is very difficult to understand what a piece of code does at first glance."
Quick, where is the business code in this Java snippet?
List adults(List people) {
List result = new ArrayList();
for (Person person : people) {
if (person.age() >= 18) {
result.add(person);
}
}
return result;
}
Quick, where is the business code in this Scala snippet?
val adults = people.filter(_.age >= 18)
Okay, so obviously that should have been: where is the *non* business code?
We have got extremely good at filtering out the crappy boilerplate in Java - but it still takes time and energy to read code like that all over the place. We probably forget how much we struggled with programming as novices when learning imperative languages like Java.
I never really appreciated this point until I started using Scala for real problems, but I think verbosity in a language makes it much more difficult to prepresent your business code in a readable way - unless you work pretty hard, it tends to get lost in the boilerplate. In Scala, the boilerplate is minimal. This means I can more-or-less directly encode the business rules into the language and even have a knowedgable business user recogise and understand those encoded rules (where I wouldn't like to try to explain the same thing in Java code).
I think much of the perceived complexity in Scala is due to features provided to allow writing powerful libraries and frameworks, but consumers of those libraries do not need to be exposed to such implementation details. They don't need to understand those advanced features in order to write large-scale applications.
@Stephen - what 3rd paragraph covered your scala experience? The third para of this post doesn't give any overview of how much you have used it and neither does the 3rd para of your original "EJB2" post. I'm genuinely interested in what experience you have had with it, as this clearly has quite a bearing on your "right" to pontificate on the language's complexity. Actually, you have that right regardless, but it has a clear bearing on whether others decide to attach any credence to your observations :-)
ReplyDeleteI mentioned in my talk at the London Scala eXchange earlier this year, the complexity of any language pales into insignificance when compared with the systems developed in that language. Even at the small scale, I have had to deal with methods written in Java with nested control structures 12 deep, hundreds of lines long with variable re-assignment, breaks and side-effects all over the place. In practice, your concerns about symbolic methods and implicits are just totally not-an-issue. I have literally *never* been bitten by an implicit in 3 years of scala. Python enthusiasts say the same about their whitespace; I have never coded much Python, so how could I possibly disagree with them?
As an aside, funnily enough, Steve Yegge's anti-scala rant introduced me to the language - most notably when I read Martin's riposte (http://www.artima.com/weblogs/viewpost.jsp?thread=245183): which seemed eminently reasonable to me and made me look at Steve's comments as being, well, slightly shrill in tone.
@Gavin wrote
ReplyDelete"""
...can easily create a "new" dynamic language by wrapping a new syntax around an existing language, that's not quite as easy for a statically typed language.
"""
Ahh... Xtend is a statically typed language not a dynamic one. It just makes Java more syntactical elegant while adding closures, some AOP magic, and some type inference. So its looking very good.
"""
... Indeed, many of the real issues with Java are rooted not in its syntax but in its type system. People perceive that as verbosity, and blame the syntax, but in fact that's often not the real underlying cause. More often the problem is actually the barriers Java's type system puts in the way of abstraction.
"""
I call BS on that. I really like Type systems. Types is how I model, convey and solve problems. I have spent equally as many years programming Python and Javascript as Java and I can tell you Java code is much easier to maintain. Java's Type system while not as powerful as Scala is still very useful and very mature (in terms of bugs). Now having to make Getters and Setters for Java properties, annoying constructors, no closures, no literals are REAL WORLD annoyances.
Just out of curiosity Gavin what languages have you used and prefer?
If Mono F# had better support on Linux it would probably prefer it over Scala or Java.
@Stephen. In response to: "I'm glad that concurrency is working out for you. Scala sells itself in conferences as being good for concurrency, but I'm simply pointing out that goodness is about programmer skill through correct library use, "
ReplyDeleteI appreciated your last response as one of your well reasoned -arguments in this whole debate. It made me ask myself, as someone who has written concurrent code in Scala, what actually makes it easier? Of course, the answers are:
1. Superior library support for both concurrency constructs and immutable data types.
2. Much Easier to write functional code, or, more specifically, side-effect free expression-oriented code.
3. Much easier to write data-oriented code (ADTs and pattern matching).
4. Built-in support for delimited continuations.
When the top-most pure Java actors library relies on both annotations and runtime bytecode weaving, you know there is something about Scala that makes it easier to work with concurrent code. Of course, most of the advantages listed above apply equally well to Clojure, which also sells itself as a great language for concurrency without needing to track shared mutable state.
Now, to your kool-aid remark! :)
"I'd not expect anyone that has drunk the Scala kool-aid and enjoyed the type system to appreciate Fantom."
I've in fact spent lots of time coding in dynamic languages. Even though Scala is my favorite language, I still think there is a large class of problems that are more easily solved without a static type system getting in the way, and is one of the reason I feel there is plenty of room for both Scala and languages like Clojure and JRuby on the JVM. However, I have yet to see anything in Fantom that looks like it can successfully have its cake and eat it too, or rather, that it can have all the advantages of a good type system and still better solve problems for which type systems tend to get in the way. I'd be happy, to learn, though.
@Kieron, In case you didn't know, I shared authorship of the FCM closures proposal for Java, whose semantics are closest to that being adopted in Java 8. I've been talking about closures and language design for some years, noting how Java has many design patterns that are just working around language flaws or missing elements. I accept that Scala has dealt with a lot of those Java flaws. But I don't think it dealt with enough of them (choosing to maintain Java compatibility probably seemed like a good idea, but Scala would have been a lot cleaner with a little less compatibility). I also say that what Scala added in syntax and features are markedly in the wrong direction for me.
ReplyDelete@oxbow, The above covers my credentials. As I've indicated, I'm avoiding using Scala beyond reading and examples - given my dislike, I'd be crazy to do otherwise. But I think my other work, such as FCM, gives me more credence to comment than a random drive-by guy.
@sreque, IIRC, Scala allows you to convert collection manipulation from serial to parallel by adding .par(). But how does it know that the functions passed to each method are thread-safe? Fantom's model would allow the compiler/code to check that only immutable thread-safe functions were passed to an equivalent library. I think that is interesting, and potentially much more valuable to the mainstream than relying on skill through libraries. BTW, Fantom doesn't try to "have all the advantages of a good type system", it simply uses types for basic communication, documentation and very basic error checking - technically its static typing, but you don't really use it for the same things you'd use types in Java or Scala. Perhaps a little more info can be found by the language author http://fantom.org/sidewalk/topic/1709#c11730 and http://fantom.org/sidewalk/topic/675
@Stephen.
ReplyDeleteIt's one thing to think Fantom's approach to concurrency is more interesting than Scala's, but it's quite another thing to claim that Scala is no better than Java at concurrency, or that Scala falsely markets itself as being good at concurrency. It's also intellectually dishonest to put forth as reasons not to use Scala missing features that exist in no other released JVM language except Fantom. The same goes for modules!
Coincidentally, it's amusing to find out after a little googling that the Fantom community doesn't get it either. On their own website at http://fantom.org/sidewalk/topic/1101, they claim that Clojure is the only other JVM language they are aware of that supports built-in immutability, when it is just as possible in Clojure to, for instance, put a side-effect in an STM transaction as it is in Scala! (see http://stackoverflow.com/questions/5427778/stm-and-alter-in-clojure)
In the end, when we strip your arguments down to the core, the only things you really dislike about Scala are its syntax and type system. It's clear by your other comments that you have basically zero experience actually coding in Scala, which means you are one of the least qualified people to argue about its syntax. I hate Perl, but I've at least spent man-months of time coding in it, enough to realize that its syntax is the least of its problems. I therefore feel very confident and informed when I tell others not to use it.
As to its type system, you again appear to lack qualifications to attack it. Its for these reasons that I and many others feel that your posts lack substance, supported as they are by your gut feelings instead of a much sturdier foundation of true insight.
I think you would be a lot more successful focusing more on why Fantom is good, something you probably know a lot more about. In this regard, if Fantom really is a good language, then I wish you lots of success in the future!
I think this is a question on Scala adoption as much as anything. If Scala is the next Java why does it not appear to be so? For me it is simple. Too much for too little gain.
ReplyDeleteI agree with sreque. I found these FOXNews-style tactics you employed very disappointing, dishonest and not the level on which technical discussions should happen these days.
ReplyDeleteYou cherry-picked everything which made your arguments look good and ignored everything which didn't support your personal opinion, including the selective quotes of “sane” people agreeing with you and “idiots” disagreeing in the second part.
This began by basically stating up-front in the first article that — I paraphrase a bit — “everyone disagreeing with me is probably a language zealot”.
After that, the completely needless EJB slur, which was guaranteed to insult a maximum of people without bringing any meaningful points across.
You criticized that Scala doesn't build its own module system, when you pretty much knew with all your involvement in Java that the first Jigsaw builds are around the corner.
You evaded pretty much every quesion concerning the source or the cause of these accusations until it was clearly evident — even to non-programmers — that the criticisms lacked any form of knowledge, experience or facts.
Your points about immutability and the comparisons to Fantom (which I guess Fantom developers won't be happy about) sound laudable first but fall completely flat in the real world.
In fact, you would pretty much get the same applause for complaining that compilers should emit code optimized for lambda-calculus hardware and not this stupid turing-machine harware.
Just like the harware out there all pretty much revolve around turing machines today and compiler authors have accepted it, we have to understand and accept that the todays runtimes lack any notion of immutability and languages can't do more than provide a very superficial look of immutability to the user of the language.
Pretty much every language — including Fantom, Clojure and Scala — work that way. They encourage immutability, but stay honest that some guarantees cannot be provided. If you don't like that, you have to go the full way to Haskell. There is just nothing meaningful in between “mutable” and “immutable”.
Again, this point was optimized for a maximum agreeability with your emotions, intended to make people disagreeing with you look like idiots.
[Continued]
ReplyDeleteIn the type system paragraph and in the further discussion about it, you make it pretty clear that you a) haven't actually understood what Scala does here and are b) completely unwilling to actually understand it. This is an exceptionally bad stance in a supposedly technical discussion.
Sadly, in the syntax part you didn't even try to find a reasonable example for your point. I find it pretty amusing that people complain about the horrible syntax, but fail to come up with any meaningful example except that sad piece of code now shown for 3 years in a row, where probably every opportunity was taken to avoid using the already existing `l.sum`.
Additionally it is pretty dishonest to complain about line noise when your own code example a blog post earlier contains stuff like `Str:Int[:]{def=0}` (the equivalent Scala code would be a very readable `Map[String,Int]() withDefaultValue 0`). While it is possible to avoid the ugly `/:` in Scala, it is not possible to avoid the line niose above, because this is actual syntax built into Fantom.
Quite dishonest to first trying to misrepresent facts by selectively quoting people while quietly ignoring that the picture suddenly looks very different when compared, for instance to the language you're advertizing:
Scala: more than 4300 test files — https://github.com/scala/scala/tree/master/test
Fantom: less than hundred test files — http://hg.fantom.org/fan-1.0/file/6c45b00c4b10/src/testSys/fan http://hg.fantom.org/fan-1.0/file/6c45b00c4b10/src/testCompiler/fan
While you can do pretty much everything you want on your blog, I'm pretty sure this is not the best way to be a credible person advocating for or against stuff you like or dislike.
I hope in the future a debate can be held soleley based on facts and actual experience, without insults and unfair discussion tricks.
@steve, and to a lesser degree @sreque, I can see you've reached the conclusion that my blog on this topic has little value, that I have no real knowledge on the topic, that I'm intellectually dishonest and that my opinion is not worthy. And I'm fine with that - I can take it. After all believing that I'm an evil idiot protects your world view of Scala's greatness.
ReplyDeleteYet, the fact remains that I *really* dislike Scala. It rubs me up the wrong way far more than any other comparable language. And I'm far from alone in that view, no matter how much you try to scare and intimidate opponents.
So, if you want you can go away believing my dislike is unimportant and it is just because I think Fantom is interesting. You'd be totally wrong of course, but it would save you from having to look inwards and really figure out why I dislike Scala so much.
I think Steven's comment "programming is as much an art as it is a engineering" is illustrative.
ReplyDeleteThis is patently not true, _programming_ is most definitely a logic based engineering exercise. There are some areas of computer science, like concurrency (specifically related to controlling non-deterministic composition of side-effects) that may appear to be magic, and there is aesthetic beauty in algorithms and data-structures, or to an elegant solution to a problem, and programming may even be used to create art, but programming itself isn't art.
This doesn't mean that some people aren't able to approach programming in the style of an artist – Jackson Pollack like they throw code at a problem until it seems to work, then they commit and go home. This is unfortunately common, and is successful enough of a sort for people to believe it is a sustainable approach to building software "in the real world™".
These "software artists" do not like and will never like languages that reward study and learning, that do not necessarily yield quickly to a superficial total understanding. That is OK, there are languages, tools and sandboxes for them. You can even build them within a language like Scala.
Scala (and languages like Haskell and OCaml and many others) reward the engineers and the scientists. If you don't believe in the science, then clearly you won't understand the point of these languages.
@Stephen, I apologize for the "intellectual dishonesty" comment. I think you are biased against Scala, but not purposefully trying to deceive the world. Perhaps a better word to use would have been "unfair". For instance, I think saying "Fantom is great because it enforces no shared mutable state" is fine. So would saying "Fantom is better than Scala because it enforces shared mutable state". However, you said the following:
ReplyDelete"Before I start I should mention that although I like the Fantom programming language, I also see merit in aspects of other languages - Groovy, Kotlin, Ceylon, Gosu, Xtend and many others. I also respect Clojure. "
"I don't see myself writing a post in quite the same way about Groovy, Ceylon, Kotlin, Xtend, Clojure,... I may critique them (all do or will have flaws), but I don't see myself ripping into them in the same way. There is just something about Scala..."
Given these statements, I feel it is unfair of you to say, "don't use Scala! It lets you share mutable state between threads!", because so do all those other languages you mentioned as being less bad and not worthy of of being ripped to shreds. I also had similar thoughts on your module and quality points. I hope that clarifies the "honesty comment" as being more about what I perceive as your bias and less about what I perceive as your evilness.
Also, I'm not interested in bullying or intimidating you, and apologize again if I've given that impression. I'm much more interested in convincing your other readers to give Scala a chance anyways. This isn't about you. It's about mindshare! :-)
@ Steve. Just gonna address your two points. Str:Int[:] isn't the only way to create a map. You can also say Map(Map#.parametrize["K":Str#, "V":Int#]). Hopefully brian will add Map(Type key, Type val) in future to complement the List one. There are couple of hurdles learning the Fantom (from java perspective) if you are new and those are closure syntax, with-block and maps. Basically this is the hardest thing I remember about Fantom.
ReplyDeleteI'm not totally defending Fantom but number of files is a really, really bad metrics on how good is something tested. Size of test files would be a bit better, number of tests would be way better and total code coverage would be the best metric.
Like good scientists, I stand by my opinion until the facts change.
ReplyDeleteSince the very first post you made it abundantly clear that you want to be seen as a victim of the to-be-expected horde of angry Scala zealots. I strictly oppose this kind of story setting as unfair and dishonest.
How — in your opinion — should a meaningful debate work, when you repeatedly evade any technical discussion by hand-waving and coloring people not agreeing with you as the “bad guys”, trying to attack their victim?
The way you try to reinforce your image as the “lone truth-teller and victim” attacked by people not being able to reflect their own opinion is very disappointing.
The reason why you have been asked so often and repeatedly about your actual experience and the work you have already done with Scala is not because people try to belittle you for spreading unfounded claims and “gut feelings”, but because your complaints and issues are light-years away from the complaints and issues actually appearing in “the real world” and people try to understand where you come from.
What do you think about actually joining the debate you caused (instead of trying to discredit your opponents) and stop evading the discussion?
Working with the points I brought forward the last time — which you elegantly side-stepped by claiming people disagreeing with you want to protect their “world view of Scala's greatness” and “try to scare and intimidate opponents” — would be a great start.
What do you think?
@Daniel:
I think that the closure syntax is actually pretty OK in Fantom. Sure, it is not familiar, but since when was familiarity connected with quality and taste? :-)
The only thing I'm wondering about is why there are no spaces around the thin arrow. Maybe it is just me, but for instance |Int a, Int b->Int| is grouped like (Int a) (Int b->Int) in my head. Subjectively I prefer it when the “input” is separated from the “output”, e. g. (Int a, Int b)(->Int). Would it be considered bad style to write |Int a, Int b -> Int| instead?
The small magic around with-Blocks is not that bad — actually I have no problem with that. It would be comparable with things like “apply” in Scala which enable some syntactical niceties.
Some of my concerns about Fantom are the missing user-defined generics and the built-in collection literals. Both make it hard to write specialized collections, which are necessary because there is no one-size-fits-all in terms of data structures.
How would forward compatibility look like here when support for this is added? Deprecating the built-in collection literals? Adding special rules for user-provided classes which would allow them to “emulate” the built-in syntax?
But how would the compiler decide which implementation to choose for the literals if multiple implementations are in scope etc etc...
I think Fantom is neat, but in the current form it is lacking on the systems programming level, while being a nice language on the scripting side. I'm not sure this will change in the future, because that would require solving hard problems which are currently put aside in the favor of simplicity.
I have nothing against Fantom, they made their design choices and live with it, but I think people should evaluate their options and stay realistic.
Yes, counting only the amount of files is by no means accurate. This was just pure laziness on my side after I had verified that both Scala and Fantom in fact exercise multiple pieces of functionality in a single file. Nevertheless, I'm pretty sure that introducing the better metrics you mentioned don't change the result in a meaningful way.
Thanks!
@Adam Gent
ReplyDelete"Ahh... Xtend is a statically typed language not a dynamic one. It just makes Java more syntactical elegant while adding closures, some AOP magic, and some type inference."
Yes, I know what Xtend is and does. And its approach of wrapping a new syntax around Java's type system and SDK places a *lot* of limitations on what problems it can address.
"I call BS on that. I really like Type systems. Types is how I model, convey and solve problems. I have spent equally as many years programming Python and Javascript as Java and I can tell you Java code is much easier to maintain."
FYI, I'm currently working like 16 hour days developing a compiler and IDE for a new statically typed language http://ceylon-lang.org.
The point is that not all static type systems are equal. Java's type system has a number of problems, especially since the somewhat botched introduction of parametric polymorphism.
@Steven
ReplyDeleteTrue. I've looked at Lisp and Haskell recently and decided to learn me some Haskell (it looks slightly better syntax wise).
As for Func object you can group it anyway you like Fantom ignores white-spaces, so if I recall correctly |Int i, Float f->Int|, |Int i,Float f->Int| or |Int i,Float f -> Int| are the same signature.
User defined generics are a bit of a sore spot for Fantom. They should be quite useful for actors but the problem is that adding them would make the otherwise quick reflection sluggish. Not many people really complained about built in collection litterals. Mostly argued for Set as a special data structure. Hopefully we can nag brian into adding it :P As for the forward compatibility I don't think it's gonna be that much of a problem unless it requires new fcode (Fantom bytecode) to be added.
Yeah having a look at the tests proved that Fantom has ~1MB of test (.fan files) while Scala has ~2.8MB (.scala and .java files). Rest is txt files.
@Stephen
ReplyDeleteYes, I am indeed aware of your credentials. I also absolutely love JodaTime (worked a lot with j.u.Calendar!), which is now pervasively used at my work, and am looking forward to working with the results of JSR310, so thanks so much for your excellent work on that. If anything, this familiarity with your efforts has made me all the more disappointed to see your comments on Scala. I rather expected you to be more objective I guess.
As to compatibility with Java. I'd love for a language to throw away Java's baggage, but realistically such a language has zero chance of being introduced at my work (at least). We (and I am sure we are very far from alone) have too much invested in Java, and anything we use could not be anything less than seamless. For us, Scala does an excellent job of being able to work with what we have, but with a modern and productive language that actually does a pretty excellent job of papering over Java's flaws (stuff that makes things more difficult for me every day). One bad thing about Scala is that it makes me notice Java's annoying quirks all the more...
Lamda's in Java 8 is shaping up pretty nicely from my perspective. But I can't see Java being able to provide the kinds of features I am now used to for a long time to come (if ever, but hopefully it will take away much of the current every-second-minute pain).
val averageAge = people.map(_.age).sum / people.size
val blotter = trades.filter(_.user == me).sortBy(_.time)
val winner = tickets.maxBy(_.score)
val cheapest = prices.min
This is every day collection stuff that Scala makes breathlessly easy and extremely clear. There is so much more too.
I realise you are not likely to change your mind. As echoed by others - people reading this should try it out for themselves before making a decision about it.
@jed, If you view programming solely as science then you are deceiving yourself. There are very many value judgements made in development all the time, from naming, to where to split classes in an API, to trade offs (eg. performance/space), to what API to call. Choosing between those is artistic. Google art vs science in computing and you'll see its a well discussed area.
ReplyDeleteAnd for proof, just look at discussions on Scala mailing lists about the "right way" to tackle any given problem. Scala's design approach, offering multiple ways to achieve the same thing, will naturally encourage debate as to the right way to do something, at least in part because the right way is a value judgement, aka art.
On Fantom/Scala test cases. Firstly, the podcast is from June 2011, so it is not unreasonable to hope that testing has increased since then. But when performing a comparison, it is only reasonable to think in terms of the size of the problem. Scala is described by a core committer as having an "astronomical" feature intersection. Fantom has a much, much smaller feature intersection. (Modules limit the scope of compilation dependencies, compiling modules whole provides all necessary information in memory to work with, there is almost no overloading to disambiguate, the type system is minimal and syntax ambiguity is very low - all the language/library features work together here).
ReplyDeleteTesting is fundamentally proportional to intersections, not codebase size. You aim to test each path through the system (or enough paths to be confident). My intuition is that Scala has at least one order of magnitude (and possibly more) intersections than Fantom. Thus I would expect Fantom's smaller test suite to actually cover far more of the code, and especially more of the corner cases. If someone wants to do the proper analysis, it would make a good blog post.
And while I discussed the above without talking about complexity, it is hard not to make the link (its at the core of my case). The intersections make it hard to write a good IDE. They make it hard for humans and compilers to know what a piece of code does. Of course there are upsides - its a trade off - but I prefer simpler choices whenever they make sense.
@Stephen. A conversation which goes like this...
ReplyDeleteA: I don't like X
B: really, why not? Have you tried it?
A: why would I try it? I don't like it
...is one you might normally expect to have with a toddler. And involve peas.
@oxbow, You missed the stage where I examined it, the feature set, the trade offs, the community dynamic, and more, but found it hugely wanting. Of course its far easier to believe my thoughts are irrational and child-like than the product of deep thought.
ReplyDelete@Kieron, Scala in the small (in examples and conference talks) can be made to look simple. But, ironically given the name, I don't think Scala's feature set scales well to the enterprise. Or more precisely, I think you'd need very strong technical management practices to define standards for the code and enforce that they are stuck to. I note that most comments of those that used Scala and left refer to lack of maintainability as the reason they left.
@Steve, I could repeat my arguments ad nauseam, but it wouldn't get either of us anywhere at this point, especially as you appear to believe that I should have no opinion until I solve world peace in Scala. Put simply, there is more to language design than a long list of features, an over the top type system and a loose syntax. Those things allow individuals to work effectively if they put in the effort, but they are terrible things for teams and long term maintenance. I value simplicity wherever possible, and nothing I've seen convinces me that Scala really understands what that means.
@Stephen - my apparently risible attempt at humour was in response to the fact that you have been continually asked about to what extent you have actually used scala to actually write programs. Eventually you reveal that you have not, actually written any programs in it.
ReplyDeleteI say "eventually" because you were first asked this question months ago (http://blog.joda.org/2011/07/kotlin-and-search-for-better-java_9066.html?showComment=1311244492000#c5642344349924991752).
There is, of course, a place for both initial impressions and up-front analysis. However, to criticise the complexity of scala's type system, in particular to invoke Steve Yegge's type-type-types refrain, is to reveal the weakness of the sageful ponderama you must have undertaken. Because, as any programmer who has used scala for any period of time will understand: Scala's type system gets out of your face *so much more* than Java's, allowing you to concentrate on solving the problems at-hand, rather than trying to decode an error like "? capture-of ? cannot be applied to ? capture-of ? extends T", (or some equally dismal outpouring).
@Stephen
ReplyDeleteWell, I don't know what code you have been looking at, but most of my normal application business logic looks like my examples (to somebody that understands our business logic of course). Even better, my tests look that simple too. Add to that the very clear syntax for creating methods and classes (which you do more often because it is so easy, and hence your code is made even more understandable), and you get something that is hugely more readable than the equivalent Java code. Hence why I said it is much more likely I will show Scala code to business users, which I don't think I could ever do with Java.
I do wonder what the few people commenting here mean when speaking about lack of maintainability. I can only assume that they have had code dumped on them by people who are using advanced features of Scala inappropriately - using features just because they want to learn about them. I can understand the temptation, but submitting to it is a sign of a person not doing their job properly. Indeed, having weak development oversight is always a bad idea, but I can see that some companies have little choice. Even so, they are hurting themselves in the long run whatever language they choose.
Or, maybe these people found the functional programming style, sometimes used in Scala, difficult. I can understand that. Functional programming can indeed look alien to somebody not familiar with it. That is not a problem with Scala the language though.
If the answer to all this is to throw out features that are hugely beneficial in their intended use cases, then that strikes me as a clear case of throwing out the baby with the bathwater. I really don't think a good answer is to hobble a language just because certain features can be abused. As long as the features of the language work well together (and they do), and possible edge cases don't cause problems in practice (not for me so far), then I'll take the overwhelming benefits.
To be honest, I think if people want to say that Scala doesn't scale up well in the enterprise, they should realise that the burden of proof is on them to provide evidence for that.
@Gavin
ReplyDelete"Yes, I know what Xtend is and does. And its approach of wrapping a new syntax around Java's type system and SDK places a *lot* of limitations on what problems it can address."
Could you provide some examples?
@Sven Efftinge
ReplyDeleteThe other languages under discussion here (Scala, Kotlin, Ceylon) are not just a new syntax wrapped around the Java compiler. Rather, they have type systems that are significantly different to and more powerful than Java's. (Even Fantom has its own type system, though it's actually strictly-speaking less "powerful" than Java's.)
You can find out lots of information about the differences from the websites of these languages, so I'm not going to try and write up a full list. But I'm thinking about things like mixin inheritance, being able to write a generic type that abstracts over "primitive" numeric types, typesafe handling of null values, declaration-site variance, fully-reified types, algebraic types, more expressive generic type constraints, and modernization of the numeric types.
And in the case of Ceylon, a type system based upon analysis of principal, denotable types, allowing elimination of the awful cryptic error messages that the Java compiler sometimes spits out when dealing with generics. This brings first-class union and intersection types into the picture.
Note that the net result of implementing the above list of things actually makes the type system *simpler* and more regular than Java, rather than more complex. But if you really want all that, then you're going to need to write your own typechecker.
And of course, you can't fix the Java SDK without ... a new SDK.
Looking at xtend, I can see what's nice about it: it's a simple frontend for the Java compiler, almost a "DSL for Java", if that's not an oversimplification. And that made it easy and quick to build. But that kinda puts it in a different space to the other languages we're discussing here.
(P.S. Apologies if I misrepresented anything about your project in this post, I'm just going by the information on the website, and filling in certain details by guessing. I'm sure you'll correct me if I guessed wrong anywhere.)
Oxbow,
ReplyDeleteI don't understand your insistance at getting Stephen to say how much Scala he wrote, except maybe in an attempt to use the "Not a true Scottsman" fallacy on his arguments ("We don't need to listen to him, he's not a real Scala programmer").
The amount of Scala he wrote is irrelevant, focus on his arguments. If, like you think, he hasn't written much, then his arguments will be stupid and easy to demolish. This doesn't seem to be the case since you choose to attack the messenger instead of the message, which should cause you to pause about your own arguments.
Stephen,
ReplyDeleteFirst off, as Kieron stated, thank you for Joda Time!
I'm currently evaluating and learning scala for myself. I have to say, for me, it's been tremendously fun, enlightening, and thought provoking. In many ways, I believe it has pushed me to be a better Java programmer, or a better programmer in general. The functional style was difficult for me to grapple with at first. I felt like I had to unlearn what I had learned. I think it's a good exercise to go thru as a programmer. (Since we're talking analogies, it's like how Tiger Woods re-invents his swing every once in a while.)
I must admit, I do share some of your concerns over maintainability. Years ago, moving from C++ to Java, I was glad to give up operator overloading. (Also, glad to give up pointers, glad to give up memory management, etc.) I do agree not everything is perfect in scala. But I won't let that stop me from further exploration and continued learning.
The functional style has some positives, especially regarding concurrency, in my opinion. And the more I play with the functional style and the more I push myself a little bit, the more it starts to make sense to me. I realize there are other functional languages on the JVM, but I feel like Scala has a few things going for it: 1. It is statically typed. I like that. 2. Use of existing java libraries is a good thing! 3. Tool support is good, and getting better. I believe a good IDE will help tremendously regarding things that otherwise might be confusing. (operating overloading, implicits)
I do think some of your points against Scala are valid, but I also have to agree with Kieron and say some of the points seemed a bit unfair and make it come off like a smeer campaign.
@Gavin
ReplyDeleteYou didn't mention a single example, did you?
Xtend reuses Java's type system not because it's easy to implement (it is definitely not a simple task to do), but to ensure seamless integration with any existing Java library. You are talking about the JDK but that's just the basis. There are thousands of interesting libraries and frameworks out there all designed against this type system. And all of them are built on top of the JDK. If you want to avoid the JDK you'll have to start from scratch.
The main problem with Java's SDK is the lack of higher-order functions and convenience methods. That is solved by Xtend's extension methods. If there are abstractions you don't like just don't use them.
Calling Xtend a syntax-wrapper is indeed oversimplified. It's after all much harder to compile to statically typed Java code as it is to compile to byte code. But compiling to source code allows for reusing sophisticated optimizations in Java's compiler, understanding how Xtend is translated to Java and use it on platforms like Android without any extra tools.
In the end it's a matter of scope. I'm pretty sure Xtend hits a sweet spot by carefully choosing what to change and what not. It's a big mistake to get into the "while we are at it let's change this keyword since I think it's not ideal"-mode.
@Kieron
ReplyDelete"As to compatibility with Java. I'd love for a language to throw away Java's baggage, but realistically such a language has zero chance of being introduced at my work (at least). We (and I am sure we are very far from alone) have too much invested in Java, and anything we use could not be anything less than seamless. For us, Scala does an excellent job of being able to work with what we have, but with a modern and productive language that actually does a pretty excellent job of papering over Java's flaws (stuff that makes things more difficult for me every day). One bad thing about Scala is that it makes me notice Java's annoying quirks all the more..."
Have you tried Xtend (http://xtend-lang-org) ?
"""
val averageAge = people.map(_.age).sum / people.size
val blotter = trades.filter(_.user == me).sortBy(_.time)
val winner = tickets.maxBy(_.score)
val cheapest = prices.min
"""
The Xtend version of the Sclaa code above would look like this:
val averageAge = people.map[age].sum / people.size
val blotter = trades.filter[user == me].sortBy[time]
val winner = tickets.maxBy[score]
val cheapest = prices.min
@Sven
ReplyDeleteThanks for that. I'll certainly have a look at Xtend. I did have a quick look, but I couldn't find any API documentation? Does it have a standard library or would I just use Java's?
I ask because one of the reasons I posted those particular examples is that they demonstrate how useful Scala's collection API is.
Here are two example "killer" features of Scala's collections API for me:
1) Provides a rich set of functions, which allow me to do all sorts of things on collections with very little effort. Not just the usual things like filter, map & reduce, but things like zip, splice, partition, collect, diff, intersect, patch, etc, etc. The API is consistent across collection types, and once you become familiar with those methods, code using them becomes much easier to read than manually tracing through loops to see what is going on.
2) Note the methods .sum, .maxBy and and .min - those only work on collections containing numeric types. If the collection does not contain numeric types, your program will not compile. I find that pretty amazing, even after discovering how it works.
Does Xtend offer this sort of functionality?
@Kieron
ReplyDeleteXtend provides a thin extension library for Java SDK, which includes the typical filter, map and reduce among other functionality. You can easily build your own extensions and of course you can have a maxBy function which only works on certain types. To have it working for elements of Comparable you would define it like this:
def <A,B extends Comparable<? super B>> A maxBy(Iterable<A> iterable, (A)=>B maxOn) {
iterable.sortBy(maxOn).head
}
It's 'just' Java generics. Note that (A)=>B is a function type.
The standard lib is likely to get more functionality added over time.
The JavaDoc can be found here : http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.1.1/org/eclipse/xtext/xbase/lib/package-summary.html
(only that package)
@Anonymous 23:21
ReplyDeleteI don't think the "no true Scottsman" fallacy applies very well here, because Stephen has said he hasn't done any Scala programming. In similar fashion, I am not French, let alone a "true Frenchman".
It is important to know how much experience somebody has with something for us to be able to properly apply weighting to their arguments, particularly when those arguments are value statements.
The arguments should of course also be addressed, and many of the commenters here have done so.
"You didn't mention a single example, did you?"
ReplyDeleteExample of what? I gave quite a long list of practically useful improvements to the type system that are not possible without writing your own typechecker. I thought that was what was being asked of me. No, of course I'm not going to go and write up code examples of each one here. I've already spent hours documenting these things on our website.
"Xtend reuses Java's type system not because it's easy to implement (it is definitely not a simple task to do), but to ensure seamless integration with any existing Java library."
Right, so there are tradeoffs here. If you just say "our type system is Java's", you immediately resolve almost all issues of interop. If you have a different type system, you need to think carefully about how to do transformations between the two type systems. Again, xtend is a lot less difficult to implement than something like Ceylon or Kotlin, but it's not addressing all the problems that those projects address.
"The main problem with Java's SDK is the lack of higher-order functions and convenience methods. "
Yeah, so this is a statement I can't disagree with enough. To me it's just completely wrong. To me, the main problem with Java today is the awful (and awfully bloated) Java SE class libraries. But I don't have space/time to really get into the issue here.
"But compiling to source code allows for reusing sophisticated optimizations in Java's compiler, understanding how Xtend is translated to Java and use it on platforms like Android without any extra tools.'
Interestingly, Ceylon has this same advantage, because the Ceylon compiler, after our dedicated typechecker has done its work, transforms the Ceylon syntax tree to a javac internal syntax tree for Java (working completely at the syntax tree level), and lets javac generate bytecode. So we get the best of both worlds :-)
Pretty clever, huh? :-)
@Gavin
ReplyDelete"xtend is a lot less difficult to implement than something like Ceylon or Kotlin"
It seems like we are degrading into a discussion like 'I can implement a more complicated thing like you' which obviously does not help in any way.
If the mapping to existing libraries and thereby bridging the gap is more complicated for the language implementor, it's likely to be more complicated for languages users, too, isn't it? I don't think that's a good idea.
"Yeah, so this is a statement I can't disagree with enough. To me it's just completely wrong. To me, the main problem with Java today is the awful (and awfully bloated) Java SE class libraries."
So what are you up to? Rewriting all the libraries and make your users relearn all kinds of new APIs in order to get startet? Doesn't sound appealing to me at all. The JDK contains tons of useful classes for my daily work and other libraries out there - that usually are working on top of that - make that even more useful.
"Interestingly, Ceylon has this same advantage, because the Ceylon compiler, after our dedicated typechecker has done its work, transforms the Ceylon syntax tree to a javac internal syntax tree for Java (working completely at the syntax tree level), and lets javac generate bytecode. So we get the best of both worlds :-)
Pretty clever, huh? :-)"
Especially if your users want to know what's going on with their code (espeically in the interop scenarios with Java) javac's internal syntax tree sounds really helpful. A language for the clever ones, huh? ;-)
Don't get me wrong: I think the goals of Scala, Ceylon and Kotlin are very ambitious. I'm just not sure that it's the right track in the short- or midterm. Xtend adresses a very nice sweet spot in that regard and therefore is more useful in a broader range and right from the beginning. People can just start using it without wrapping their head around union and intersection types. The Java type system is by far not the best on earth but it's well known, devs are familiar with its quirks and it integrates seemlessly with existing code bases. That doesn't sound too bad to me as a starter.
"It seems like we are degrading into a discussion like 'I can implement a more complicated thing like you' which obviously does not help in any way."
ReplyDeletePlease don't put words in my mouth. I made a factual statement, which you don't dispute, and FYI, I actually consider ease-of-implementation an extremely positive point for any technology.
"If the mapping to existing libraries and thereby bridging the gap is more complicated for the language implementor, it's likely to be more complicated for languages users, too, isn't it?"
Well, to some extent, I suppose, but not really. You see the compiler implements the transformation, and the IDE presents the transformed types to the programmer. This is the kind of problem where tooling really shines.
"So what are you up to? Rewriting all the libraries and make your users relearn all kinds of new APIs in order to get startet?"
Well, pretty much, yeah. The Ceylon project is a project to build a whole new modular platform that replaces the legacy SE and EE platforms.
"The JDK contains tons of useful classes for my daily work and other libraries out there - that usually are working on top of that - make that even more useful."
We've already started the process of wrapping the truly useful bits of the SE platform (a pretty small part of the entire mess that is the JDK) in modernized APIs. This is obviously a big job that will take time to complete.
For stuff we don't wrap, there is Java interoperability.
"Especially if your users want to know what's going on with their code (espeically in the interop scenarios with Java) javac's internal syntax tree sounds really helpful."
In the unlikely even that a Ceylon programmer needs to see the equivalent Java code, the Ceylon compiler has a -verbose option that dumps javac's syntax tree as formatted, readable Java code. But I don't expect that Ceylon developers will even need this. We, on the other hand, use it every day. Much better than trying to inspect bytecodes when we want to find a bug in the compiler.
"That doesn't sound too bad to me as a starter."
OK, so it's a start. And then what? In ten years time from now we'll still be stuck with the same type system and SDK that is already outdated today?
I'm not sure a Scala blog is the best place for a discussion about Ceylon and Xtend! My current view on both is on hold, but I would say that they seem to have different goals and target different niches. So, I'm not sure there is any need to fight.... :-)
ReplyDeleteStephen, sure, as you wish.
ReplyDelete"if I add a string to a list of integers I should get a compile error, not a list of Any"
ReplyDeleteList in Scala is not part of the language, it is just a class in the standard library. No one is forced to use the standard library. If you don't like the default list behaviour, you are free to implement your own list, just as you are free to implement your own Date class if you don't like the standard Java Date class...
Holy crap. I am switching right back to .NET. Thanks Stephen for saving me from scala. Simple FTW!
ReplyDelete"if I add a string to a list of integers I should get a compile error, not a list of Any"
ReplyDeleteThis is perfectly true for scala - you just have to be explicit about what you want. You can't blame a language for not reading your mind.
Proof:
var a: List[Int] = List(1,2,3)
a = "error" +: a
:8: error: type mismatch;
found : List[Any]
required: List[Int]
a = "error" +: a
^
But I agree that the "no boilerplate hype" sometimes seduce people to drop those annoyances like type declarations because they can be sooo easily inferred...
But it's not the fault of the scala compiler if people get caught by their own lazyness.
It's a hallmark of a professional to know where you can get away with lazyness and where it will turn around and bite you. Is this the fault of the language? I'd say: No.
Beside that I agree that Scala does not fit everybody. But that's the benefit of a living ecosystem - you can always find a place of comfort. For the one it's Scala - for others it's plain old Java or Kotlin or Ceylon.
Greetings
Bernd
Ok, so Scala's type system is just so complicated, that's elitist. You just can't get a normal level team for a Scala project.
ReplyDeleteNow think about : all those gory details about pointers arithmetic, bitfields, stack, heap, explicit memory managment, it's too complicated. You just can't get a normal level team for a C project !
Wait... You can get an normal level team to program in C ! Why then ? Because people learned all those low-level gory details at school. Today, people learn those high-level language theory gory details at school.
Yes that means people coming out from schools don't know the same things than some years ago. And yes, that means that one day you might have to learn some new theory. But in a field like computer science, you did not really expect something else, did you ?
@Stephen
ReplyDeleteThank you for these two posts and the comments provided. For me programming is like a puzzle game and I love how the creator(s) of Scala tried to maximize freedom of expression while keeping static typing.
That said, where you dislike Scala and it feels very wrong for you, I like Scala and it feels very right for me. I want to thank you for reminding me of the 'fact' that there is no universal truth to things. And that for every opinion or emotion I have about something, there is bound to be someone on the other side.
The posts and comments were very instructive.
Erik
@Yoann Ricordel Now think about : all those gory details about pointers arithmetic, bitfields, stack, heap, explicit memory managment, it's too complicated. You just can't get a normal level team for a C project ! Wait... You can get an normal level team to program in C !
ReplyDeleteBecause those things are much less complicated than you are trying to imply. They are not difficult to understand, they just tend to be error prone. Almost all C programmers understood them. Making them right required conscious effort which can be more effectively better spend elsewhere, so people moved to higher level languages.
That is completely different argument than what you are trying to make.
>> And yes, that means that one day you might have to learn some new theory ...
There are tons of theories, libraries, frameworks, languages and what not to learn in computer science. In addition, there are things like security, process and best practices. If you work on business project, there is also a lot of domain knowledge you are supposed to learn.
Type system theory competes with them all. People may spend whole their lives learning new things and not spend a minute with it.
Stephen,
ReplyDeleteI absolutely agree with you on Scala "rubbing me the wrong way", and that is after spending a day with Lift, some time with Finagle, around 40 hours with SBT, and some time with Play 2.0. Even with all of my enthusiasm about Scala, I still find it rubbing me the wrong way.
I argue against that the type system is too complex, simply because it is such a value judgement. Who is to say that typed collections are just right but typed types is too complex? But I do agree that it can be daunting for most people.
More than one way to do things. I have a huge dislike for languages with this particular trait. The various syntax for defining functions, different ways to define mutable properties, pattern matching vs higher order functions for flow control. It is overwhelming! I wish there is a "Scala" way of doing things. The community can benefit from that. Then again, having more than one way of doing things has never hurt JavaScript, so maybe it is a non-issue?
Version incompatibility. Java developers are spoiled by strong backward compatibility. For most cases, pre Java 1.5 libraries will be compatible with the latest code. For Scala, your project needs to target the right version of Scala. This is a major "rub me the wrong way". For example, I can't use the latest collections API from 2.9 if I want to use Finagle.
Intellectual dishonesty regarding "good for concurrency". I strongly agree with you here. Scala has sold itself as good for concurrency. But the truth is that for most developers, creating safe concurrent apps is going to be just as difficult with Scala as it is with Java. While Scala does include features that CAN make it easier to write concurrent code (ease of creating immutable objects, good collection library, FP pattern in library, and the Scala community has a "concurrency is important" mindset), I would argue that concurrency is so hard to get right and involves much more than the application code, that no language feature can make it easy. Anyway, you can argue on both side of the fence on this. I would say if you want to be truly critical, you should not carelessly make the "Scala makes concurrency easier" claim.
Hackiness in the language - A limit of 22 on tuples? Function22.java? The magical 22 in the language should rub anyone the wrong way.
Here's the thing though. Java is horrible. Java rubs me the wrong way much more than Scala. Java, under the stewardship of Oracle feels like a language doomed to be stagnant. Is there an alternative that provides both strong typing and first class function support? You can't even find Ceylon or Fantom on Github's languages page. The popularity of Scala is a huge win for anyone looking to move past Plain Old Java.
So that's where we're at. Scala - it doesn't quite feel right, but it is the best we've got.
@Bernd, Thank you for showing that Scala can validate code as I'd expect, although I note you relied on a var, when good Scala coders use val AFAIK.
ReplyDelete@Yoann, Garbage collection in Java was a huge move forward, but before Java many developers would have said that life would be impossible without managing your own memory. I think the same is true today about some of the core things we think we need in our languages. (My points on Fantom are about challenging perceptions of what we as a community really need in a language - Java threw away so much from C, and Fantom is the only language I've seen that attempts anything close in terms of throwing away stuff from Java)
@John, Thanks for the comment. I think we agree on a lot, except the conclusion. Someone commented elsewhere that Scala is like the emperors new clothes - it can easily appear to offer a better Java, but really its a fake front which will leave you naked and in a mess.
Hello Stephen,
Delete"I note you relied on a var, when good Scala coders use val AFAIK."
This is an unfortunate misconception. A good java and scala coder knows when he/she can get away with mutability (I am not claiming that I am a good coder). Scala's libraries use mutability beneath the hood. It's when you share state when immutability makes a difference. But you're right - to make the little example a little better I should have written "private var ..." and should make sure that all methods/functions accessing this var (none in this example) are not used concurrently on the same instance.
That's the good part of scala - it made me think (more) about those things and introduced me quite gently to some of the FP concepts.
And that's also the strength of scala. I still can use tried and tested "java patterns" - scala allows it. And sometimes it is wise to do so. But I can summon all the other tools when I want to encapsulate and "immutabilize" the public interfacing parts to allow for concurrency (which is NOT a no-brainer in scala either - but it is way easier than with java 5/6).
Scala gets hairy (in my hands) when I try to do things which I wouldn't even remotely try in Java. That is when I want to extend type safety in areas where I'm already miles long in "object and cast" land in java. That's because I like that the compiler tells me reliably when I'm wrong (which happens annoyingly often).
But sometimes such a goals is too ambitious... but I am able to give in anytime and resort to casting when correct typing gets too arduous. This is also supported by the scala compiler - you just have to know what you are doing.
But I don't subscribe to the notion that scala leaves you in a mess - it's just that it allows you to create a mess. But that's true for all languages I know of. The mess most often starts with the solution concept - or the lack thereof.
Java allows you to go silently wrong a loooong way helping yourself with more and more convoluted constructs here and there (we've all seen (or used) them - I can safely assume) thus creating an impenetrable solution mess in the end.
Scala begins to strangle you - things no longer fit together nicely, the compiler complains to no end about mismatching variances or other type failures. And it's right. The solution would not work reliably in the end. Whenever this happened to me I had to learn that I did something wrong. Conceptually wrong. While this can cause nightmarish feelings and you curse the darn peace of software by the hour - it's still correct. It's the solution that is wrong.
And that's why I hold the scala compiler in high respect - it can prove my solution wrong where any other language would let me stroll into possible production nightmares. In this respect Java is akin to assembler and C - just on a "higher level".
Greetings
Bernd
Scala fans must hate the fact that JJJJJAAVA and JJJJJJJAVA-VIRTUAL-MACHINE is the only selling point of the language. I mean really, if we didn't know it is a JJJJJJVM language, would we even care? Would Steve write this post? You know the answer...
ReplyDeleteThank you Stephen for speaking up on what so many Java developers (of all levels) have been quietly thinking since their first glance at Scala (perhaps one should try to count the quiet majority for a change). If it can't pass the readability test - it's bad. That in and of itself should end all discussions period. If it relies too much on libraries - well why a new language then?
ReplyDeleteIs Scala really the best we've got? Have we really started trying and why can't we create one collectively? Maybe we should just fork Java and make it the next Java, a better Java (without the trademarked name of course).