4 ms·

Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?

yummyfajitas 15y ago
I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses. [edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential: class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a ]
- CodeMage 15y ago
  I'm genuinely curious: is this because Haskell is generally hard to learn[] or because of some inherent property of Haskell that makes type classes unnecessary when you have first class functions? [] This statement is based purely on my own experience. I find the Haskell documentation a bit unfriendly with its "academic" style. The content is great, but the form makes it a bit hard to assimilate. Monads were especially painful.
- xyzzyz 15y ago
  Once Haskell introduced first class functions, everyone stopped using typeclasses. What do you mean? From what I've seen, everyone uses typeclasses in Haskell.
- calpaterson 15y ago
  I don't think typeclasses were in from day one, they were added quite late in the development of the language (but some years before H98). I don't think they're in Miranda, for example. Here's a paper introducing them. http://dl.acm.org/citation.cfm?id=227700 http://dl.acm.org/citation.cfm?id=227700
  - yummyfajitas 15y ago
    I stand corrected. I guess Haskell before H98 was a very different language than it is today.
  - SamReidHughes 15y ago
    Type classes were in Haskell 1.0. See http://webcache.googleusercontent.com/search?q=cache:rtFsiQCtqxYJ:www.haskell.org/definition/haskell-report-1.0.ps.gz+&cd=2&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:rtFsiQC...
hythloday 15y ago
Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener: interface MouseClickListener { void mouseClicked(MouseEvent e); } one often uses an anonymous class to do so: void init() { mouse.setClickListener(new MouseClickListener() { void mouseClicked(MouseEvent e) { println(e); } }); } the exact effect could be achieved with a reference to a named function (if Java supported them, which presumably it will once "everything is an object"): void init() { void mouseClick(MouseEvent e) { println(e); } mouse.setClickListener(mouseClick); } given that interfaces are simply syntax for function routing, when you have the ability to reference functions by first-class types (i.e. you have the ability to determine function routing yourself), the set of things that you can only sensibly do with interfaces is a lot smaller. This is how C# delegates work, right? Any Java -> C# programmer want to comment on whether they rely less on interfaces now and what they use them for?
- eropple 15y ago
  I bounce between Java and C#. I'm not sure at all what he's talking about. I use interfaces all the time in C#. I even specify delegate properties (as distinct from events, when I don't want them to be multicast) in interfaces. I think both concepts are probably independent of one another.
- bermanoid 15y ago
  First class functions pretty much have no bearing on whether or not interfaces are useful. Sure, one use case for inner classes is to implement interfaces in-place in situations where what you really want to do is just pass a function, and in those cases it's probably better to use a function instead, but the equivalence doesn't go the other way. There are plenty of cases where you really need to pass an object to a function and know that the object supports multiple operations, for instance take a look at Map<K,V>: http://docs.oracle.com/javase/6/docs/api/java/util/Map.html http://docs.oracle.com/javase/6/docs/api/java/util/Map.html There are 14 methods there, and when I write code that takes a Map object, I really mean it - I'm not just using the interface as a hack because I want a function pointer, I need an object that supports all of those methods, and I'm probably going to be using several of them.

yummyfajitas 15y ago

I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses. [edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential: class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a ]

CodeMage 15y ago
I'm genuinely curious: is this because Haskell is generally hard to learn[] or because of some inherent property of Haskell that makes type classes unnecessary when you have first class functions? [] This statement is based purely on my own experience. I find the Haskell documentation a bit unfriendly with its "academic" style. The content is great, but the form makes it a bit hard to assimilate. Monads were especially painful.
xyzzyz 15y ago
Once Haskell introduced first class functions, everyone stopped using typeclasses. What do you mean? From what I've seen, everyone uses typeclasses in Haskell.
calpaterson 15y ago
I don't think typeclasses were in from day one, they were added quite late in the development of the language (but some years before H98). I don't think they're in Miranda, for example. Here's a paper introducing them. http://dl.acm.org/citation.cfm?id=227700 http://dl.acm.org/citation.cfm?id=227700
- yummyfajitas 15y ago
  I stand corrected. I guess Haskell before H98 was a very different language than it is today.
- SamReidHughes 15y ago
  Type classes were in Haskell 1.0. See http://webcache.googleusercontent.com/search?q=cache:rtFsiQCtqxYJ:www.haskell.org/definition/haskell-report-1.0.ps.gz+&cd=2&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:rtFsiQC...

hythloday 15y ago

Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener: interface MouseClickListener { void mouseClicked(MouseEvent e); } one often uses an anonymous class to do so: void init() { mouse.setClickListener(new MouseClickListener() { void mouseClicked(MouseEvent e) { println(e); } }); } the exact effect could be achieved with a reference to a named function (if Java supported them, which presumably it will once "everything is an object"): void init() { void mouseClick(MouseEvent e) { println(e); } mouse.setClickListener(mouseClick); } given that interfaces are simply syntax for function routing, when you have the ability to reference functions by first-class types (i.e. you have the ability to determine function routing yourself), the set of things that you can only sensibly do with interfaces is a lot smaller. This is how C# delegates work, right? Any Java -> C# programmer want to comment on whether they rely less on interfaces now and what they use them for?

eropple 15y ago
I bounce between Java and C#. I'm not sure at all what he's talking about. I use interfaces all the time in C#. I even specify delegate properties (as distinct from events, when I don't want them to be multicast) in interfaces. I think both concepts are probably independent of one another.
bermanoid 15y ago
First class functions pretty much have no bearing on whether or not interfaces are useful. Sure, one use case for inner classes is to implement interfaces in-place in situations where what you really want to do is just pass a function, and in those cases it's probably better to use a function instead, but the equivalence doesn't go the other way. There are plenty of cases where you really need to pass an object to a function and know that the object supports multiple operations, for instance take a look at Map<K,V>: http://docs.oracle.com/javase/6/docs/api/java/util/Map.html http://docs.oracle.com/javase/6/docs/api/java/util/Map.html There are 14 methods there, and when I write code that takes a Map object, I really mean it - I'm not just using the interface as a hack because I want a function pointer, I need an object that supports all of those methods, and I'm probably going to be using several of them.