I have been using SBT now for about two years and I really like it's features. I very much grok it.
It is definitely growing up, in terms of new features and stability. However, of course there is an however, "I can't give this to my friends".
It is just not ready for the corporate world. The likes of Gradle, and yes even Maven make it so much easier to explain the build process. Actually, I can explain the build process with gradle and maven. But SBT is SUCH a massive barrier. We really can do better folks.!
I think I can base my gripes down to two areas: Syntax, and then a higher level, the complexity of creating a build setup.
Syntax
In short, SBT has confusing and ugly syntax. (shocking really) Watching Martin Odersky's key note at the Scala 2013 days, he discussed the notion that we should be very careful with Symbolic vs alphabetic Method names.
http://parleys.com/play/51c1994ae4b0d38b54f4621b/chapter35/about (see from 59:10)
Here Martin discusses Alphabetic vs Symbolic method names. Can we have some normal reading config please ? Looked at a gradle build file lately ? I can explain that to a junior developer of 3 months very easy - but sbt. not a chance (I have tried). It just represents - "forget it - what do you know about node.js ?"
Build and Customisation Complexity
What Ruby on Rails and Maven and (some other stuff I am sure) have in common is the Convention over Configuration. Gradle does this well, where to extend a plugins execution, just define "more stuff for it to do".
The way settings are applied in a .scala definition is almost appalling. It really needs a rethink as when I show people the various methods, you get blank stares or squizzed up faces.
With SBT, I find I have to write some very complex logic if I want to move files, or process config files etc etc. I feel this comes from SBT lacking a "customer API". It has an Engineers API at the moment but ease of extending it's activities really requires some serious depth knowledge of Scala AND SBT.
My issue
SBT is shaped as the defacto build too for Scala; yes Maven and Gradle can do it. But SBT does it better. Because it is defacto, and because we want new users to learn the languages, and because we want the new users to have good projects (for longevity of maintenance) we want them to use a build tool. But our option .. sticking them in front of SBT ?? oh dear.
Scala is a fantastic language, simply my favourite and I know a LOT of languages and environments. Ant was a brilliant help, and Maven improved that massively (yes yes, ant v maven). So when I train new users (ok / so so developers) in a project, I don't want to confuse them with "take up", I just want to get them on the road to exploring. Training Java, it might be Spring, or Drools or JAX-RS or something else. With Maven (and now with Gradle as that is my preferred Java build tool) I can simply setup a build script, easily (and I mean easy), explain the script to someone, and get them on their way.
The new-ish developer does not need to know much about Java to understand Maven and even less knowledge to understand Gradle as it reads better.
But if I wanted to get someone up and running with Scala, giving them a default Build tool, I can show them an SBT build setup. Oops. that doesn't work.
Parallel this poor experience with how Scala compares to Java, I can show them a case class and how simple that is, so at the high level, Scala as a language is easy, but SBT is just killing take up for the less experienced.
I have read that sbt is like vi, once you grok it, you get it.. and yes I am definitely there. (vi is my favourite editor) - but please can we work on a new build definition language - and I really mean something that it's GOAL is user friendliness, to overlay on top of the vi-ness ?
If we get that right, because SBT is a defacto build tool, we might get even more developers!
Is there something in the works that will help SBT be a tool for the masses ? Because at the moment you need a degree and a year on Scala to understand how to do more complex things (and sometimes something basic).
Every so often I do consider switching a project to Gradle but, of course, SBT just does work better with Scala and I like it, but I can't share a build setup with a new junior developer. I have tried and it just confuses to the point on non-productiveness
So I have an itch, I may scratch it.. .. but I haven't yet
There, I can have a coffee now.
<rant-off/>
It is definitely growing up, in terms of new features and stability. However, of course there is an however, "I can't give this to my friends".
It is just not ready for the corporate world. The likes of Gradle, and yes even Maven make it so much easier to explain the build process. Actually, I can explain the build process with gradle and maven. But SBT is SUCH a massive barrier. We really can do better folks.!
I think I can base my gripes down to two areas: Syntax, and then a higher level, the complexity of creating a build setup.
Syntax
In short, SBT has confusing and ugly syntax. (shocking really) Watching Martin Odersky's key note at the Scala 2013 days, he discussed the notion that we should be very careful with Symbolic vs alphabetic Method names.
http://parleys.com/play/51c1994ae4b0d38b54f4621b/chapter35/about (see from 59:10)
Here Martin discusses Alphabetic vs Symbolic method names. Can we have some normal reading config please ? Looked at a gradle build file lately ? I can explain that to a junior developer of 3 months very easy - but sbt. not a chance (I have tried). It just represents - "forget it - what do you know about node.js ?"
Build and Customisation Complexity
What Ruby on Rails and Maven and (some other stuff I am sure) have in common is the Convention over Configuration. Gradle does this well, where to extend a plugins execution, just define "more stuff for it to do".
The way settings are applied in a .scala definition is almost appalling. It really needs a rethink as when I show people the various methods, you get blank stares or squizzed up faces.
With SBT, I find I have to write some very complex logic if I want to move files, or process config files etc etc. I feel this comes from SBT lacking a "customer API". It has an Engineers API at the moment but ease of extending it's activities really requires some serious depth knowledge of Scala AND SBT.
My issue
SBT is shaped as the defacto build too for Scala; yes Maven and Gradle can do it. But SBT does it better. Because it is defacto, and because we want new users to learn the languages, and because we want the new users to have good projects (for longevity of maintenance) we want them to use a build tool. But our option .. sticking them in front of SBT ?? oh dear.
Scala is a fantastic language, simply my favourite and I know a LOT of languages and environments. Ant was a brilliant help, and Maven improved that massively (yes yes, ant v maven). So when I train new users (ok / so so developers) in a project, I don't want to confuse them with "take up", I just want to get them on the road to exploring. Training Java, it might be Spring, or Drools or JAX-RS or something else. With Maven (and now with Gradle as that is my preferred Java build tool) I can simply setup a build script, easily (and I mean easy), explain the script to someone, and get them on their way.
The new-ish developer does not need to know much about Java to understand Maven and even less knowledge to understand Gradle as it reads better.
But if I wanted to get someone up and running with Scala, giving them a default Build tool, I can show them an SBT build setup. Oops. that doesn't work.
Parallel this poor experience with how Scala compares to Java, I can show them a case class and how simple that is, so at the high level, Scala as a language is easy, but SBT is just killing take up for the less experienced.
I have read that sbt is like vi, once you grok it, you get it.. and yes I am definitely there. (vi is my favourite editor) - but please can we work on a new build definition language - and I really mean something that it's GOAL is user friendliness, to overlay on top of the vi-ness ?
If we get that right, because SBT is a defacto build tool, we might get even more developers!
Is there something in the works that will help SBT be a tool for the masses ? Because at the moment you need a degree and a year on Scala to understand how to do more complex things (and sometimes something basic).
Every so often I do consider switching a project to Gradle but, of course, SBT just does work better with Scala and I like it, but I can't share a build setup with a new junior developer. I have tried and it just confuses to the point on non-productiveness
So I have an itch, I may scratch it.. .. but I haven't yet
There, I can have a coffee now.
<rant-off/>
No comments:
Post a Comment