Re: Groovy Creator James Strachan on Scala
Posted: Jul 14, 2009 4:24 PM
> Can you give a specific example or two? That may help me jog a Scala example like that out of my memory.
I have an example that just happened this morning. It's no where near as dramatic as James' "unlimited damage," but I think it illustrates a point.
We're developing a Django application, but using SQLAlchemy + Elixir to access a multitude of legacy schemas. So this morning a junior developer stops by my desk...
Dev: I deployed the app to the server and it stopped working
Me: That's probably because mod_wsgi is multithreaded and the Django dev server isn't. You have something that should be in a thread local but isn't.
Dev: Ok, yeah, that makes sense. But how do I fix it?
So I go to his desk and we fix it, and right now I'm reviewing and refactoring some of his code to make sure there aren't more insidious threading issues lurking about.
Now I'll use this to illustrate both James' and your points.
If the developer had, say stumbled upon the fact that he could turn off multithreading in mod_wsgi instead of figuring out the root cause of the issue, or had simply randomly jiggled options until it worked, then we could have ended up with a major production issue when the app can only process one request at a time. Of course, such an issue probably wouldn't make it to production, but... I'm pretty sure the developer in question wouldn't do that, but I've worked with plenty who would.
I think that illustrates James' point.
Now the developer is smart, and he learns quickly. He has an innate aversion to magic he doesn't understand. He's not afraid to ask for help and I'm here to give it. So something that could have created severe latent issue was just a short education problem solving exercise.
Which brings me to your point. You make a mistake, the compiler yells at you, you try different things and find something that works, you know why your new thing works and eventually you figure out why the old things didn't.
This is a harmless problem solving/education exercise for you because you are a smart, senior developer and no doubt like to learn.
But more commonly people will flip bits until their problem goes away, without any clear knowledge of why the solution they find works. Their code fills up with cruft. Eventually even small code bases become completely unmaintainable because they flip a variable here and unflip it there and null it out in this other place (which, btw, is a much more compelling argument for immutability than parallelism). They can't explain what their code is doing. They just know that pretty much everything there was put there to solve some problem, and are afraid to delete it because then the problem might come back.
I think this is the type of developer who James' is afraid of. I know it's who I'm afraid of. It's the developer who spend years with a technology without ever learning how to do more than repeat patterns from simple how-to articles.
The more complex a technology is, even if that complexity is elegant and justified, the more likely a given developer is to fall into randomly poking code and repeating patterns without understanding. There is a cognitive load in Scala that is not present in Java or C#, and I think Scala could reduce some competent, disciplined Java/C# developers into a very frustrated random pokers.