Scala: sharp and gets things cut
One of my favorite talks at last month’s Strange Loop conference was Martin Odersky‘s keynote entitled “The Trouble With Types.” There were many interesting points made in his talk, some that I agree with and some not. However, I’d like to focus in on a very small, seemingly throwaway statement made by Dr. Odersky that bothers me. That is, the statement is one that I see gaining popularity amongst many advocates of static typing that takes the form:
I’m not a great programmer, so static typing helps me to be a better programmer.1
My position is that this statement is incredibly weak, ringing hollow at best and disingenuous at worst. I don’t know exactly why this phrase is gaining mind-share, but I suspect it’s an attempt to counter the idea that strong static type systems like Scala’s are complicated. One reason that it rings hollow is that anyone can explore the code written by those who say this phrase and more often than not their skill is easily apparent.2
It’s my opinion that this watered-down phrase needs to die, and quick. I personally would be more impressed if advocates instead took a more positive position and stated some to the effect of:
I am a great programmer and I choose static type systems because I demand sharp tools.
Of course by taking this position you run the risk of pushing a fallacious, authority-based angle. However, in the weak or strong case you’re already pushing anecdotes around, so you may at least choose the one that is open for objective measurement. I’d much rather learn from and participate in a debate centered around whether Scala is a sharp tool 3 than if Scala makes weak programmers stronger.
Besides if we can come to the agreement that Scala is a sharp tool then the latter point is moot. Sharp tools always make everyone better at their craft, regardless of skill level.
:F
-
Odersky at about 9.5 minutes into his talk mentions his experience in using types to constrain the possibilities of his programs to such an extent that when and if they compile then they tend to be correct. I’ve experienced this also during my ~3 years with Scala circa 2008 and 2011 and it is incredibly empowering. However, this power did not come magically, but was instead the result of careful thought and type design — something that I’ve not seen typically bad programmers do. ↩
-
Additionally, that weak phrase immediately provokes the question: if you’re a not a good programmer then why should I use your language? ↩
-
Does it really need said that sharp tools can cut the craftsman as well? ↩
26 Comments, Comment or Ping
Martin
I do mean it that way. When i was younger I was made to write some C and C++ code. I never could get more than a couple dozen lines done before I gave up facing a maze of inscrutable errors. I would be utterly hopeless as a programmer in these languages, and I suspect, in Lispy languages as well :-). Types are a fantastic help to abstract from unnecessary detail.
Oct 7th, 2013
Lucian
I don’t think the phrase should die. The mythical “great” programmer always writes correct code, supposedly. Hence, all of us need help dealing with mistakes.
A good type system does indeed help find mistakes before you code is even run. The reason I use Python is because it’s practical and comfortable, not because it offers the most power (I could use Clojure, but JVM) or because it helps me write correct code (I could use Haskell, but it is overly prescriptive).
Oct 7th, 2013
Martin
Also, a small correction: I said (or meant to say, have not seen a video yet):
“I am not that great a programmer” …
(implied context: … that writing 100’s of lines of code without the help of a good static type system would work at first try).
That’s a relative statement, not an absolute one.
Oct 7th, 2013
Patrick Logan
“this power did not come magically, but was instead the result of careful thought and type design — something that I’ve not seen typically bad programmers do”
Yes, people’s experience and abilities tend to make more of a difference than language selection. And I would suspect FP languages tend to have a higher proportion of experienced, good programmers than most other languages.
And so people need to be wary of selection bias when drawing conclusions about languages, per se.
Oct 7th, 2013
Franklin Chen
As you mentioned in your footnote, successful and enjoyable use of types is a matter of using them as part of design, but this is not typically taught very well or at all. Not enough people are spreading the word about typeful programming or type-driven design. There are no popular books with titles such as “Designing with Types”.
I know, I’m setting myself up for responses like “go write that book”.
Oct 7th, 2013
Alex
I don’t understand the problem with this argument. I use Java mostly and I have to say that the type system mostly acts as a hand-holding system that lets me relatively quickly write programs that work. I know this because when I use Javascript or Groovy which are pretty similar to Java just with dynamic types, I find myself running my tests a dozen or so times before all the variable types are coherent – i.e. the process of removing what would result in compilation errors in Java.
If I say this and use it as an argument to use Java, I am assuming that you might also be an equally bad programmer as I and so perhaps, if you chose my language, you’d benefit from static types for the same reason.
Oct 7th, 2013
Tim
Can you explain exactly what you mean by “sharp tool”? I think you’re making it even less clear what you mean, by using a strange metaphor.
Urban Dictionary says: “A sharp tool is someone who has a knack for something, is a smooth operator, and can make things happen. They may or may not also be a bit of a knob. If you are called a sharp tool, you should be initially flattered when the word ‘sharp’ is said, then more uneasy following the word ‘tool’.”
It sounds like you’re saying that Scala can be effective, but is obnoxious to use, which doesn’t sound all that different from what the “Scala’s type system is overly complex” people are saying.
Oct 7th, 2013
Mark Derricutt
Franklin – GO WRITE THAT BOOK ;-)
(* had to be said *)
Oct 7th, 2013
Gubatron
In my case being both a python and java programmer, I find types extremely more powerful when you have a tool that makes your coding time faster (in my case eclipse).
Odesky could tell you things like, there’s no amount of unit tests that will ever compare to static type checks (and boy will they save you a lot of headaches), and then when your code is typed, boy it’s easy to do huge refactors.
I’m on the type camp.
Oct 7th, 2013
MarkusQ
There’s a simpler explanation that fits the data and has greater explanatory power. If we posit a Dunning–Kruger effect, it could just be that people who are aware of their own limitations (possibly due to greater knowledge of the field) see more value in a good type system than people who just assume their code is golden.
Thus it isn’t a weak claim at all, it only appears to be one if you take the self assessments of people who do not make the claim at face value. :)
Oct 7th, 2013
gasche
I would guess that this “I’m a weak programmer” phrase came off as a response to the dynamic typing crowd’s argument that “types are holding your hand and stopping you from writing perfectly fine programs, we want ultimate freedom to express anything we want”. So the argument focus on types preventing some mistakes, and emphasize the fact that we all still make mistakes.
I guess a phrasing that you would approve is “Even great programmers make mistakes, I’m happy to use type systems catch to them and let me write better programs”. I personally appreciate some form of humility (I certainly wouldn’t use a slogan starting with “I am a great programmer”).
A better reason why this is perhaps unconvincing is that it fails to highlight other strength of type systems, which are not restricted to mistake-hunting (they also help code maintenance, documentation, modularity, and guide program construction in the first place). Besides, there is little hard evidence that static typing is more time-efficient as other techniques (eg. unit tests) to catch mistakes. Most proponent of static type systems (myself included) believe they are an indispensable complement to tests, but there haven’t been enough empirical studies to be conclusive.
Oct 8th, 2013
Patrick Logan
“There are no popular books with titles such as “Designing with Types”.”
Sadly I can think of only one such book for object-oriented programming, and it has the horrible title of…
Designing Object-Oriented C++ Applications Using the Booch Method, Robert Martin
…which I recall was more the publisher’s doing than the author’s. But in this book you will find initial designs evolved under constraints to more complete designs. I used to recommend this book to programmers of all stripes because Martin provides a glimpse of how to think as well as how to think about design, as well as how to use specific tools (fairly early C++) and notations (C++ and “Booch” (pre-UML) diagrams).
The book is hardly about C++ or “Booch” at all. I’d still recommend people read it, for what it is.
Oct 8th, 2013
Dax Fohl
re footnote 3: Yes, if you’ve ever used ReSharper you’ll have come across many recommendations that are either undesired (makes code less intuitive) or plain wrong (introduces bugs), but I’d say I’ve learned much more good stuff (which is permanent) from ReSharper’s recs than I’ve been hurt by bad stuff (which lasts one compile-test cycle, and which usually are so marginal that you learn something by trying them and failing).
Oct 8th, 2013
fogus
@Martin
Thank you for reading and commenting. It’s not my intention to pick on you per se, although it may seem that way. My only gripe is with the growing trend of a weak term used to make a weak point. I can’t say much for your C and Lisp code as I’ve not seen any in the wild, but I can say that I have seen a lot of your Java and Scala code and have learned a lot from it. Scala is a very good language and I would hate to see it get (unfairly) lambasted because it’s not an elixir against bad developers.
Oct 9th, 2013
fogus
@Lucian
I’m not sure that anyone said that there are any programmers who write error-free code. Language will not help to write error-free code.
Oct 9th, 2013
fogus
@Tim
By sharp tool I mean the same as in http://blog.fogus.me/2011/09/02/scala-is-for-drivers/
Oct 9th, 2013
fogus
@MarkusQ
I would be down for that line of reasoning. I suspect that many people will react negatively to the statement”you’re not that great. get over yourself and use types.” ;-)
Oct 9th, 2013
Patrick Logan
“In my case being both a python and java programmer… when your code is typed, boy it’s easy to do huge refactors.”
Unfortunately many dynamic languages like python, ruby, and javascript have poor tool support for things like refactoring.
Smalltalk was developed hand in hand with good tools, and has had a very good refactoring tool for decades, even though it is dynamically typed and not all that different from the above list of languages.
Oct 9th, 2013
Antti Virtanen
A static type system is valuable only if it’s powerful, easy to use and easy to understand. C++ type system is powerful but not easy to use and quite incomprehensible. Haskell’s type system is easy to use and powerful, but very difficult to understand for average programmers. For someone well versed in the arts of mathematical category theory it may make perfect sense.
Thus, to say that “static types help programmers” is not saying really much. But to state that “Scala’s type system helps average programmers” is something that can be validated or falsified to a certain degree.
Also, a dynamic system is not the same as runtime system. It is runtime in the technical sense but if it’s reasonably easy to implement the type checking as an automated test this is not much different from static compiler checks. As a developer I don’t actually care about this distinction as long as I get the results before my program is deployed outside my own machine.
We have been experimenting on this idea with Clojure lately – kind of “best of both worlds” approach. I love the Clojure’s dynamic type system but there are things I want to check before the program is up and running in the wild internet.
Oct 9th, 2013
scottw
@Franklin
Apologies for the self-promotion, but I wrote a series of blog entries with exactly the same title, focusing on domain driven design in F# (but would be equally useful for any language with algebraic types) http://fsharpforfunandprofit.com/series/designing-with-types.html, and I’ll be giving a talk on this subject at NDC London. I’d be interested in any feedback or comments.
Oct 9th, 2013
Franklin Chen
@scottw: I love your site. I browsed it some months ago, actually. I didn’t look at that particular section, but I’ll check it out.
Also, I realize that people have been writing about designing with types for some time, in isolated articles or series or even as sections or underlying themes in books, but my point was that there has not been a book that explicitly makes that the fundamental topic and markets it.
@Patrick: I actually still have my copy of “Uncle” Bob Martin’s old book, back from when I was doing C++ development professionally and OMT, Booch were all the rage (before Rational and UML). C++ of the day was extremely primitive and gave little help for truly type-oriented design, however. By the way, I assume you are aware that two decades later, he not only turned against static typing but also apparently switched to Clojure as his main language of choice.
Oct 10th, 2013
Mike S.
Maybe this is orthogonal to the discussion, but I think the difficulty in appraising the value of static typing versus dynamic typing is that it’s not too difficult to write a “type-safe” short program in a dynamic language.
That pushes us into programs with large code bases, and that makes it much harder to make direct comparisons.
And of course a common source of error is complexity. If you’ll forgive the appeal to common knowledge, the general consensus is that most dynamic typed languages permit developers to write programs more simply than most static typed languages. Haskell and Scala are the two best attempts that I am aware of to make a static type system so flexible you don’t sacrifice any code size or simplicity to dynamic type languages.
But how many times has someone taken a half a million line Scala or Haskell program and translated it into Python, Perl, or Clojure, or vice versa, so a very direct comparison can be made?
Oct 11th, 2013
Ankur
Well, types are everywhere, even in our daily life (just that they are not formal due to our human’s natural languages weakness). For me, types are about understanding any System, they help you think about that System and help you in designing the System. Types are about thinking about structures and their relationships (that sounds like mathematical thinking).
Now if you have a strong static type language, the compiler is like your friend who will warn (error) you about doing something stupid/weird once you tell it about the structures and relationships that you designed (AKA types).
Mostly (C#, Java etc) this friend is not so good and will not scold you even if the design has some loop holes and will say “it’s ok dude, you can cheat here, go ahead”.
So, I guess the proper way to interpret Martin quote in the talk would be, I am programmer and types provide me a “way towards more sound design” to make me a
Oct 13th, 2013
Ankur
Read the last line of my comment as: I am a “particular stage programmer” and types provide me a “way towards more sound design” and take me to next stage.
Oct 13th, 2013
Dick
Bit late to the game on this one, but when I heard Martin’s keynote, as always, I overlaid my own understanding based on context on to it. When a well-known programmer says “I am not that great a programmer”, two things spring to mind, first that Martin may not be comfortable living up to the image that people have of him, and second that he may not be as great as he aspires to be. For the former, I am reminded of an (unconfirmed) story I heard about the legendary Guy Steele, when a comment was made by one of his staff along the lines of “well I think this could work, but I am no Guy Steele” he responded “neither am I!”. The latter is good advice for any programmer: aspire to be better no matter how good you are (or think you are). Perhaps I read more into this comment than reason would dictate as prudent, but that is no worse than taking the statement out of context and treating it as a flat declaration.
Oct 14th, 2013
Thomas
Maybe this has to do with application domain and/or application size. But types as a defensive measure against bugs has played a ridiculously small role for me. I have been programming in dynamic languages for the last 15 or so years, starting with Perl and Shell and then Python and JavaScript. The amount of runtime errors I could trace back to type issues during that time where, uhm, 4?!
The errors I’m really struggling with are much more on the design/analysis side of things, and that is what I hear from fellow programmers. So I’m naturally skeptical when I hear the hoorays for types as a means for catching bugs. These kinds of bugs seem negligible.
Rather, on the design and analysis side types were mostly getting in the way, as they made continuous and ongoing code reorganisation difficult. They seem to impose a waterfall model of software development, where you only hit the editor once all design specs are finalized. Which is not the world I live in. (But this impression stems from my time with C and Java, and I hear modern type systems go a long way to alleviate this.)
Another big issue (and a source for those semantic bugs) is the question which changes have been applied to a particular piece of data which is passed around in a large system, at anyone time. Immutability has hence a much higher appeal to me than types.
What rather kindles my interest in types is this “type-oriented design” thing, where types become a different way to approach a problem, and a means of decomposing and structuring a solution.
Nov 12th, 2013
Reply to “Scala: sharp and gets things cut”