Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

*Stateless* methods vs. functions

 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can even do cool stuff like this:
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To me, a beginning Scala programmer, that stuff is plain unreadable. Function values are great but can be taken too far.
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 375
Monad Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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."
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[..]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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 375
Monad Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I found this discussion about currying in Scala interesting:
http://www.codecommit.com/blog/scala/function-currying-in-scala
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic