aspose file tools*
The moose likes Scala and the fly likes *Stateless* methods vs. functions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Languages » Scala
Bookmark "*Stateless* methods vs. functions" Watch "*Stateless* methods vs. functions" New topic
Author

*Stateless* methods vs. functions

Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
For stateless methods in an object, it seems that function values and methods are functionally equivalent in their semantics, but function values are a bit more powerful. They can be composed into other functions, put in collections, you get *free* currying (without the _ symbol), so my question is, is there any downside to this style of coding:


Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
You can even do cool stuff like this:
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
To me, a beginning Scala programmer, that stuff is plain unreadable. Function values are great but can be taken too far.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
Originally posted by Lasse Koskela:
To me, a beginning Scala programmer, that stuff is plain unreadable. Function values are great but can be taken too far.


Thanks for the feedback Lasse. I'm pretty much a beginner in Scala myself. I'm no big FP guy either, I have the Haskell compiler installed on my computer, and I can hack out some stuff but I'm no guru. I still can't totally grasp monads after reading literally 20 or so tutorials, each with their own catchy metaphor.

I must admit, your comment surprised me though. I don't see a lot of difference in readability between defining a method and defining value that is a function.



There's a bit more line noise with the extra =>'s, but there's no difference in the way they are invoked.

One of the things I'm not too sure I like about Scala is that although there are a lot of different ways to do things, there are'nt a lot of *norms*. A Scala programmer doesn't have a lot to go on if they want to write API's that other Scala coders can use comfortably.
[ July 23, 2008: Message edited by: Garrett Rowe ]
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Originally posted by Lasse Koskela:that stuff is plain unreadable.

This has been a complaint against functional languages for nearly 40 years. The initial APL was called a kleenex language, write once and throw it away.

I don't know if gets easier with experience.

But the point of functional languages is to not be sequentially procedural. This is a goal. Because if you describe what you want, and not details on how to do it, then the compiler can make it parallel for you.

Java threads are great, but too hard for 85% or more of the world's Java programmers. Most of the code we write is sequential, and with quad CPU chips being everywhere (I just bought a complete Gateway quad processor PC for $500) and octo and 16 processors just down the calendar, we have to get more parallel to write code that uses the hardware.
Gabriel Claramunt
Ranch Hand

Joined: May 26, 2007
Posts: 375

Originally posted by Garrett Rowe:

I must admit, your comment surprised me though. I don't see a lot of difference in readability between defining a method and defining value that is a function.



There's a bit more line noise with the extra =>'s, but there's no difference in the way they are invoked.

Actually I found "addF: Int => Int => Int = x => y => x + y" not easy to read... looks too Haskell to me . Thinking on currying and looking again I understood, but it takes effort (is normal, we're learning! )


One of the things I'm not too sure I like about Scala is that although there are a lot of different ways to do things, there are'nt a lot of *norms*. A Scala programmer doesn't have a lot to go on if they want to write API's that other Scala coders can use comfortably.

Probably is because Scala is relatively young and being an hybrid OO-FP there's no clearly defined style yet... it doesn't bother me


Gabriel
Software Surgeon
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
Well that +2 for the hard-to-read camp. Since readability directly maps to maintainability, I'd say that that is a valid concern. I still like the flexibility of function values, but I guess its easy enough to reuse implementation and turn a method into a function that I'd probably be better off preferring the easier to read idiom and turning that into a function value as necessary:
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Garrett Rowe:
Since readability directly maps to maintainability, I'd say that that is a valid concern.[/CODE]

Another thought: If our methods are extremely short, there's really nothing to maintain. If our code needs to change, we'd use a different set of functions/methods to accomplish what we need.

Also, right now it seems that there are a lot of mathematically inclined folks loving on the neato-ness of what can be done with a language like Scala. Unfortunately, this is what the "average" programmer is going to see about Scala. They'll conclude that Scala is too difficult to get anything done and brush it aside.

Groovy, on the other hand, never focused much on "The language is much more flexible and look at all the complicated neato things you can do with closures!" No, instead the authors made a few extremely useful tools like the iteration methods (each, collect, findAll) and MarkupBuilder and showed the average programmer how much easier it is to code using those tools. Those tools have internals a little too complicated for most programmer's attention spans, but no one ever has to worry about the details - everyone just knows "When I write intuitive code that looks like X I end up with an intuitive result of Y."


A good workman is known by his tools.
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
[..]instead the authors made a few extremely useful tools like the iteration methods (each, collect, findAll) and MarkupBuilder and showed the average programmer how much easier it is to code using those tools.


I thought about this for a while, and I'm not sure I get your point. Scala definitely has analogs to all those methods in the standard library. (MarkupBuilder however looks pretty cool, I'm not sure I like the way Scala mixes XML directly into the code, it seems a bit kitchen sinkish, I like the idea of having a library for that stuff.) Are you taking exception with the way the language has been marketed, or the overall percieved academic nature of the Scala community?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Garrett, what I was referring to with "unreadable" was exactly what Gabriel pointed out. It's not the simple case that's unreadable - it's this stuff that crosses the line for me:
Gabriel Claramunt
Ranch Hand

Joined: May 26, 2007
Posts: 375

I found this discussion about currying in Scala interesting:
http://www.codecommit.com/blog/scala/function-currying-in-scala
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: *Stateless* methods vs. functions