The Artima Developer Community
Sponsored Link

Articles Forum
How Scala Changed My Programming Style

50 replies on 4 pages. Most recent reply: Feb 15, 2013 4:25 AM by Oliver Plow

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 50 replies on 4 pages [ « | 1 2 3 4 | » ]
Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 1:03 PM
Reply to this message Reply
Advertisement
> Thanks for the article. That's a great angle to think
> about the languages we have used.
>
> val nameHasUpperCase = name.exists(_.isUpperCase)
>

> Scala's exists reminds me of Groovy's each..essentially if
> I am following it _.isUpperCase is the closure.
>
You're right that Groovy's each is similar to Scala's exists in that both take a function as a parameter, but the Scala method that exactly corresponds to Groovy's each is called foreach. This will print each character of name on a separate line:


name.foreach(println)

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 1:25 PM
Reply to this message Reply
Having a single return point is structured -- which gives a simple, uniformity of shape (check: ‘Notes On Structured Programming’/ewd249; Dijkstra; 1970). It should be the default, unless the code can be made even simpler otherwise.

I rate Scala even more compact than Ruby and Python: 86% of the size to be exact! (45% of C++) -- see: http://www.hxa.name/minilight/#comparison and http://www.hxa.name/minilight/minilight-scala-code.html for full code.

Scala struck just right balance with its type inference, that is: types stated explicitly at function parameters, but not needed elsewhere. OCaml doesn't require them at function parameters, but it is sometimes hard to make it compile -- each time you try to fix it, the error messages change because it infers from a different point.

OCaml changed me a bit earlier, but that prepared me for immediately liking Scala.

Dave Briccetti

Posts: 2
Nickname: 64382
Registered: Dec, 2008

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 1:56 PM
Reply to this message Reply
I suppose you could continue to use looping over a java.lang.String with old-style for in this example if you said that the String could be very long and memory and time tight, precluding copying it to a char[]. Just so it’s a realistic need to use old-style for.

Thanks for bringing Scala to so many new people, Bill.

Tom Corcoran

Posts: 2
Nickname: boardtc
Registered: Sep, 2003

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 1:59 PM
Reply to this message Reply
> >
> > val nameHasUpperCase = name.exists(_.isUpperCase)
> >

> > Scala's exists reminds me of Groovy's each..essentially
> > if I am following it _.isUpperCase is the
> > closure.
> You're right that Groovy's each is similar to Scala's
> exists in that both take a function as a parameter

Ok, that was my point really that the exists took a closure. Does the fact that you did not use this terminology suggest it is not used in Scala because of the more functional slant? It's all; semantics anyway!

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 3:30 PM
Reply to this message Reply
> Having a single return point is structured -- which gives
> a simple, uniformity of shape (check: ‘Notes On Structured
> Programming’/ewd249; Dijkstra; 1970).

Structured programming and this rule specifically is baked into Java. This isn't surprising given that Java was created 20 years later. It's implicit. Doing it explicitly is redundant and has provides no benefit.

Like I said before, the reasoning that people give for doing this is based on older languages that allow for things that Java does not.

> It should be the
> default, unless the code can be made even simpler
> otherwise.

It's almost always simpler otherwise. Tree shaped methods are easier to follow than onion shaped methods which is why the compiler can verify tree shaped methods and not onion shaped methods.

I've worked with reams of code written in single return style. It's much buggier and harder to understand than multiple return style code. You are just substituting an assignment to variable (a vague operation) for the return keyword (a clear operation.) The variable is completely extraneous.

Yes, you know there is one return at the end. Why is that important? It tells you nothing about what is returned. You still have to do the look through the code to figure out what value the variable will be i.e. what will be returned. And often this is more difficult than it is to determine than in the equivalent multi return code for multiple reasons. For example consider the following snippets:

boolean isFoo()
{
   for (item : things) {
      if (item.hasBar()) return true;
   }
 
   // more code ...
}


boolean isFoo()
{
   boolean returnValue = false;
 
   for (item : things) {
      if (item.hasBar()) returnValue = true;
   }
 
   // more code ...
 
   return returnValue;
}


In the first example, I can see immediately that if one of the items has bar, the method returns true. If that's all the information I need, I'm done. In the second, all I know is that returnValue is set to true at that point in the method. I might think that probably means the method returns true in that case but I can't be sure. I must look through the rest of the code or risk error. Most of the time it will be but I've seen cases where it would set later. I often found this kind of logic while hunting down bugs because the later assignment to the return variable was in error.

And, on a side note, any decent IDE is going to allow the return keyword to be syntax highlighted. The simple assignment won't be. I seriously don't understand why people continue to insist that this unequivocally bad practice is good.


Consider this:
boolean isFoo()
{
   for (item : things) {
      if (item.hasBar()) return true;
   }
 
   if (useDefaultFoo) {
      if (LOGGER.isTraceEnabled()) {
         LOGGER.trace("using default foo: " + defaultFoo);
         return defaultFoo;  // real error I've seen
      }
   } else {
      return false;
   }
}


boolean isFoo()
{
   boolean returnValue = false;
 
   for (item : things) {
      if (item.hasBar()) returnValue = true;
   }
 
   if (useDefaultFoo) {
      if (LOGGER.isTraceEnabled()) {
         LOGGER.trace("using default foo: " + defaultFoo);
         returnValue = defaultFoo;  // real error I've seen
      }
   }
 
   return returnValue;
}


Both are wrong. The first doesn't compile, the second does. By using return variables, you are impeding the compiler's ability to catch mistakes. I can't count the number of times using multiple returns has saved me from errors.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 4:50 PM
Reply to this message Reply
I see nothing wrong with multiple returns in pure functions, however they may sometimes be more dangerous in methods with side effects.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 4:59 PM
Reply to this message Reply
> I see nothing wrong with multiple returns in pure
> functions, however they may sometimes be more dangerous in
> methods with side effects.

Can you elaborate?

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 5:14 PM
Reply to this message Reply
In a pure function you need only verify that the valuye returned by each return is sensible. With a method evaluated for its side effects you have also to verify that all the required side effects have been produced in preceding code. You might modify such a method and fail to notice that an earlier return takes place without causing your modifed side effect to take place.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

This is why Scala Syntax annoys me Posted: Apr 30, 2009 5:20 PM
Reply to this message Reply
From Bill's article:

"The exists method iterates through a collection of objects and passes each element in turn to the passed function object"

Why the heck is this call "exists"???

Actually, I think the name is o.k., it's Bill's description that is wrong - the "exists" matches that reverse E (or is it forward???) thing from math, right?

But it's still a fairly technical term - how about "eachOr" or "checkEach" whatever???

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 5:21 PM
Reply to this message Reply
Incidentally, Scala reminds of a feature which I would like to use but which Java doesn't support efficiently and where Scala's support is limited: tail recursion.
A JVM could do a much better job of this than Scala's compiler can do.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Scala Changed My Programming Style Posted: Apr 30, 2009 5:44 PM
Reply to this message Reply
> In a pure function you need only verify that the valuye
> returned by each return is sensible. With a method
> evaluated for its side effects you have also to verify
> that all the required side effects have been produced in
> preceding code. You might modify such a method and fail to
> notice that an earlier return takes place without causing
> your modifed side effect to take place.

Generally, I would deal with this either by structuring the code such that logic and side effects are not executed in the same method. I'll create another class (usually inner or nested) if there's a lot of state that's shared between logic and persistence. If necessary, I'll use a finally block.

If you can "miss" an early return, the method is probably too long. I seen many many bugs where not returning immediately was the root cause and I have never seen one caused by the situation you describe that I can recall. My insistence on this matter is derived from the number of times I've had to fix such bugs. Overall, though, keeping the methods short is the most important thing.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: How Scala Changed My Programming Style Posted: May 1, 2009 5:25 AM
Reply to this message Reply
> I'm with you on this Bill. I was taught to set the
> variable so you could see the return variable's value in
> dbx before the return.

I think that's the point. The variable only exists for the potential benefit of using a debugger if you have to step through the code. Apart from that, it's existence adds nothing to the method and it could be replaced by a return statement because the return value has been calculated, so there is no longer any reason to remain in the method.

(Overall though, it's just a minor distraction since the point of the article was to demonstrate Scala capabilities not Java coding style artifacts.)

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: How Scala Changed My Programming Style Posted: May 1, 2009 5:32 AM
Reply to this message Reply
>
> I'm with you on this Bill. I was taught to set the
> variable so you could see the return variable's value in
> dbx before the return.
>

We could do with debuggers that show a functions return value without needing artificial variables.

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: How Scala Changed My Programming Style Posted: May 1, 2009 6:56 AM
Reply to this message Reply
> We could do with debuggers that show a functions return
> value without needing artificial variables.

Works just nicely for C++ with Visual Studio 2008 :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: How Scala Changed My Programming Style Posted: May 1, 2009 9:13 AM
Reply to this message Reply
> (Overall though, it's just a minor distraction since the
> point of the article was to demonstrate Scala capabilities
> not Java coding style artifacts.)

You're right. Sorry about that.

Flat View: This topic has 50 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: How to Write an Equality Method in Java Previous Topic   Next Topic Topic: How the Use of Scala's Features Affects Compile Time


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us