Okay, Scala is a bit scary-powerful

[jducoeur]

I just had my first brush with what I gather is a common issue in Scala programming: trying to figure out why my program is working. I was passing type A into my method, which takes closely-related-but-not-identical type B. And yet, it was simply working.

As it turns out, I was slightly ahead of myself -- apparently, last week I wrote an implicit converter from A to B, which I'd forgotten about. Implicits are one of those power features in Scala that can produce remarkably concise code, but must be used with great care, for exactly the reason I just found. Essentially, an implicit converter does exactly what it sounds like: it declares how to go from A to B, so you can use A wherever a B is expected. The compiler simply takes care of the conversion silently.

Very neat feature, and I think it'll be useful to me. But I'm going to have to be really careful with it, lest I confuse myself even more. I suspect it should be used sparingly.

In general, I'm finding that I'm often preferring to be a little more verbose than Scala requires -- for example, it permits me to omit return types most of the time (the compiler susses them automatically), but I actually prefer to have them there, for clarity and self-documentation, if the method is more than a one-liner. It's one of many examples that Scala is a language of remarkable expressiveness, but that just makes it *easier* to write bad code if you aren't sensitive to the issues. It's also easier to write good code, mind -- the language comes closer to the DWIM ideal than anything else I've ever seen -- but it's up to you...

Comments

[mindways]

In general, I'm finding that I'm often preferring to be a little more verbose than Scala requires. ... It's one of many examples that Scala is a language of remarkable expressiveness, but that just makes it *easier* to write bad code if you aren't sensitive to the issues.

My favorite illustration that the theory of "conciseness => less code => on average, fewer bugs" breaks down after a certain point has always been Perl. Truly concise Perl can be terrifyingly difficult to eyeball / debug / maintain...

[crschmidt.livejournal.com]

Is the 'implicits' particularly different than things like Python's __str__, __dict__, etc.? As I understand it, these things allow you to treat an object as a replacement for a dictionary in cases where you would ask for one...

Ah, but one difference is that I don't think you can do those for two different user created types. So you can tell Foo how to act like a dict, a string, an int -- but no how to act like a Bar. (Or rather, I don't know how -- but then again, I can't think of when I've ever tried either, so I won't say that it's not possible.)

[jducoeur]

Is the 'implicits' particularly different than things like Python's __str__, __dict__, etc.? As I understand it, these things allow you to treat an object as a replacement for a dictionary in cases where you would ask for one...

I don't know the Perl feature, but it sounds different -- this is much more general. (Which is typical of Scala -- the language designers hate special cases.) It actually converts from type A to type B automatically. You can use both freely: it just does the autoconversion when circumstances demand.

The feature is generally used in Scala when you want to add new features to existing types -- so far example, there is a RichInt subclass of Java's Int that adds lots more methods. The autoconverter means that if you try to use one of those methods on a plain Int, it converts it to a RichInt and keeps going. (This is affectionately known as the "Pimp My Type" pattern in the Scala community.)

In this particular case, I had a method that takes my own XMPPPacket type; I was passing in Packet. Now, XMPPPacket is a wrapper around Packet, but I wasn't doing any explicit conversion -- I was simply passing in a Packet. Moreover, the receiving code was clearly getting the right *kind* of XMPPPacket (which has two subclasses, XMPPIQ and XMPPMessage), which is clearly beyond even Scala's dangerously clever compiler.

In fact, it turned out that I had already written a converter method, which knows how to take a Packet, figure out which kind of packet it is, and wrap it in the appropriate subclass of XMPPPacket. The compiler saw that I was trying to pass a Packet into a method that takes XMPPPacket, so it simply assumed that it should apply the conversion. (Correctly, but it left me scratching my head for a while...)

Not that Scala

[new-man.livejournal.com]

Every time you post about Scala, I think of this one

Re: Not that Scala

[leanne-opaskar.livejournal.com]

And here I am thinking this one (http://www.pralnia.xco.pl/index_pliki/pazl/dscala.JPG). (;

[metahacker.livejournal.com]

Eep.

A few weeks ago I said to a coworker, "y'know, it's really hard to write good perl." He replied, "No -- it's just really easy to write *bad* perl."

I guess you're saying the same is true of Scala?

[jducoeur]

More or less, yes. I don't actually think it's hard to write good Scala, but if you get too carried away by the features you can definitely produce a concise, correct, elegant and utterly incomprehensible program. Between things like implicit converters, importing of objects into scope (kind of like the "with" command in some languages, but more powerful), changing names of classes during import, and stuff like that, you can get pretty muddled. They're all hugely powerful and useful features -- but I suspect I don't want to use any of them too frequently.

Now that I think of it, though, there *really* needs to be an Obfuscated Scala Contest. Even without C-style macros, I'd bet that you could produce really impressive results...

[metahacker.livejournal.com]

I was a little annoyed that the Obfuscated Foo contests became a contest to see who could use string encoding and its equivalents more obtusely. Seemed like a lowest common denominator hack.

Can you do self-modifying/eval'ing code in Scala? If so, then you've got my private trifecta of ununderstandability/unmaintainability (overloaded syntax, leaky scoping, and self-modifying logic).

[jducoeur]

Hmm. Not easy, but yes, it's clearly possible, since they have a REPL-based interpreter. So the compiler must be available somewhere in there...

[learnedax.livejournal.com]

Hmm, the JVM sort of limits how much you can directly do in this regard. I know that Clojure also uses a REPL, and my impression was that it shelled out to a separate JIT compiler and then used ClassLoader to insert the results. Which seems fairly slow, but perhaps there are streamlined ways of doing that now.

[learnedax.livejournal.com]

We use C#'s implicit casting operators here, but only with great care. A primitive upcasting transparently to some heavier type can be quite helpful , whereas seamlessly transforming major distinct types is more likely to cause damage.

Explicit casts might actually be a less scary approach, because it means that you are always aware when using them of what it implies.