3 ms·

Thank you! I'm working on a team that inherited some Scala code from contractors that no longer work for us and we've found that (at least their) Scala is almo

by MrRadar 12y ago

Thank you! I'm working on a team that inherited some Scala code from contractors that no longer work for us and we've found that (at least their) Scala is almost as hard to read as bad Perl. Compounding this is a severe lack of good online documentation outside of the standard library reference and simple tutorials which don't go into the depths we need to know (like how do you create a Manifest from Java to call into Scala code that needs it? Or what even is a Manifest?). At least with Perl you have decades worth of online discussions and pretty good documentation of the core language.

teacup50 12y ago
> we've found that (at least their) Scala is almost as hard to read as bad Perl. At least with Perl you have decades worth of online discussions and pretty good documentation of the core language. Programming languages you don't know are harder to read than programming languages you do know. Unlike "bad perl", you have types that tell you exactly what something does. > ... and simple tutorials which don't go into the depths we need to know (like how do you create a Manifest from Java to call into Scala code that needs it? Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop.
- MrRadar 12y ago
  > Programming languages you don't know are harder to read than programming languages you do know. I will definitely agree with you there. It would help our team significantly if we had a Scala expert we could consult but there's not enough in the budget (monetary or political) to hire one. We are pretty much left to fend for ourselves with Google, Stack Overflow and a couple reference books. This project also contains a C++ component that would probably have been just as impenetrable to my teammates (who have C but no C++ experience) if I hadn't already been fairly familiar with the language. > Unlike "bad perl", you have types that tell you exactly what something does. Static typing doesn't help always when you actively try to subvert it. There are casts to and from Any all over this codebase. Reflection is used everywhere even when it's not necessary. There are even places where they convert between types by serializing an instance of one type and deserializing it as an instance of another (with similar fields but not actually related in the type system). They also loved Option[] types which might not be so bad if they weren't also storing Some(null) into them in just enough places you forget to check for it but it still blows up in your face at least a once a month. Basically, the original authors of this code tried their best to destroy the usefulness of the Scala type system and succeeded fairly well. > Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop. By mandate of our management we are not allowed to write any new Scala code except where absolutely necessary. The contractors went behind our management's back to write it in the first place (we told them they could use Java 8 which they interpreted to mean they could use anything that would run on a Java 8 JVM). After that was found out (about a 1/3 of the way through the contract and too late to rewrite everything without blowing our contractual deadline with our customer) new Scala code was banned and they had to (and we have to) use Java as much as possible after that point. This is also not helped by the fact that at the time they handed the code over it was barely half-baked and performing at less than 25% of the needed throughput and we're left trying to finish and fix it. Of course, when it can take three or four developers (with a combined background in Java, C#, C, C++, Python, Javascript, and an academic familiarity with OCaml-family functional languages) a half hour or more to figure out what a some of the methods in this codebase even do (at both a syntatic and conceptual level) I am going to put (a small) part of the blame on Scala for allowing such impenetrable code to be written in the first place. I'm certainly not placing all or even a significant amount of the blame for this project's problems on Scala but it is certainly not helping. Thanks for letting me vent.
ssmoot 12y ago
I think you just need to hire an experienced Scala Developer for a month or two until your team gets up to speed. It'd be like a c# team having a Ruby app dumped in their lap. You're practically preordained to hate it. ;-) The documentation for Scala is actually pretty outstanding IMO. I had a much easier time compared to Ruby. Daniel Westheide's introduction series "The Neophyte's Guide to Scala" is the single best language intro I've ever seen, for any language. It even goes into enough of Akka to get a basic chat application going. And while Akka works nicely with Scala, it's conventions are so different it might as well be a different language. In idiomatic Scala you probably don't run into mapTo or vars too often for example, but that's going to be a pretty common sight working with Akka. At least the documentation on PlayFramework.com is mostly current, and doesn't gloss over important detail. Unlike rubyonrails.org, where even five years ago the basics were horribly dated, inaccurate, and skip important background.
dragonwriter 12y ago
> Thank you! I'm working on a team that inherited some Scala code from contractors that no longer work for us and we've found that (at least their) Scala is almost as hard to read as bad Perl. I've seen C# that is almost as hard to read as bad Perl -- also, not surprisingly, from contractors who weren't going to be maintaining the code. I don't think this says anything about C# or Scala, I think what it says is something about the natural result of the economic incentives of people being paid to throw code over the wall before they leave for greener pastures.
- MrRadar 12y ago
  Yeah, I would agree with that. Scala is, at most, probably 2-3% responsible for the problems we're having with this project (due to inexperience with it). The vast majority of the blame rests on our contractors and on our management's lax oversight of them.

by MrRadar 12y ago

teacup50 12y ago

> we've found that (at least their) Scala is almost as hard to read as bad Perl. At least with Perl you have decades worth of online discussions and pretty good documentation of the core language. Programming languages you don't know are harder to read than programming languages you do know. Unlike "bad perl", you have types that tell you exactly what something does. > ... and simple tutorials which don't go into the depths we need to know (like how do you create a Manifest from Java to call into Scala code that needs it? Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop.

MrRadar 12y ago
> Programming languages you don't know are harder to read than programming languages you do know. I will definitely agree with you there. It would help our team significantly if we had a Scala expert we could consult but there's not enough in the budget (monetary or political) to hire one. We are pretty much left to fend for ourselves with Google, Stack Overflow and a couple reference books. This project also contains a C++ component that would probably have been just as impenetrable to my teammates (who have C but no C++ experience) if I hadn't already been fairly familiar with the language. > Unlike "bad perl", you have types that tell you exactly what something does. Static typing doesn't help always when you actively try to subvert it. There are casts to and from Any all over this codebase. Reflection is used everywhere even when it's not necessary. There are even places where they convert between types by serializing an instance of one type and deserializing it as an instance of another (with similar fields but not actually related in the type system). They also loved Option[] types which might not be so bad if they weren't also storing Some(null) into them in just enough places you forget to check for it but it still blows up in your face at least a once a month. Basically, the original authors of this code tried their best to destroy the usefulness of the Scala type system and succeeded fairly well. > Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop. By mandate of our management we are not allowed to write any new Scala code except where absolutely necessary. The contractors went behind our management's back to write it in the first place (we told them they could use Java 8 which they interpreted to mean they could use anything that would run on a Java 8 JVM). After that was found out (about a 1/3 of the way through the contract and too late to rewrite everything without blowing our contractual deadline with our customer) new Scala code was banned and they had to (and we have to) use Java as much as possible after that point. This is also not helped by the fact that at the time they handed the code over it was barely half-baked and performing at less than 25% of the needed throughput and we're left trying to finish and fix it. Of course, when it can take three or four developers (with a combined background in Java, C#, C, C++, Python, Javascript, and an academic familiarity with OCaml-family functional languages) a half hour or more to figure out what a some of the methods in this codebase even do (at both a syntatic and conceptual level) I am going to put (a small) part of the blame on Scala for allowing such impenetrable code to be written in the first place. I'm certainly not placing all or even a significant amount of the blame for this project's problems on Scala but it is certainly not helping. Thanks for letting me vent.

ssmoot 12y ago

I think you just need to hire an experienced Scala Developer for a month or two until your team gets up to speed. It'd be like a c# team having a Ruby app dumped in their lap. You're practically preordained to hate it. ;-) The documentation for Scala is actually pretty outstanding IMO. I had a much easier time compared to Ruby. Daniel Westheide's introduction series "The Neophyte's Guide to Scala" is the single best language intro I've ever seen, for any language. It even goes into enough of Akka to get a basic chat application going. And while Akka works nicely with Scala, it's conventions are so different it might as well be a different language. In idiomatic Scala you probably don't run into mapTo or vars too often for example, but that's going to be a pretty common sight working with Akka. At least the documentation on PlayFramework.com is mostly current, and doesn't gloss over important detail. Unlike rubyonrails.org, where even five years ago the basics were horribly dated, inaccurate, and skip important background.

dragonwriter 12y ago

> Thank you! I'm working on a team that inherited some Scala code from contractors that no longer work for us and we've found that (at least their) Scala is almost as hard to read as bad Perl. I've seen C# that is almost as hard to read as bad Perl -- also, not surprisingly, from contractors who weren't going to be maintaining the code. I don't think this says anything about C# or Scala, I think what it says is something about the natural result of the economic incentives of people being paid to throw code over the wall before they leave for greener pastures.

MrRadar 12y ago
Yeah, I would agree with that. Scala is, at most, probably 2-3% responsible for the problems we're having with this project (due to inexperience with it). The vast majority of the blame rests on our contractors and on our management's lax oversight of them.