Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Codata in action, or how to connect FP and OOP

javiercasas.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Codata in action, or how to connect FP and OOP

#31

Post by mirekrusin »

pansa2 wrote: post #24
mirekrusin wrote: post #22

Earlier quoted context omitted.

I don't think you can classify Julia like this. It's kind of both. Julia has types on bindings, in that sense it is statically typed.

“Julia is squarely in the dynamic camp” - Stefan Karpinski, Julia co-creator https://stackoverflow.com/a/28096079

...but you've ommited what I meant "(...) Unlike many dynamic languages, however, Julia has a fairly sophisticated language for talking about types, and you can annotate expressions with types. (...)"

Also other answers have some good information, ie:

" (...) It can also be useful to indicate the argument types to restrict the kind of parameters passed when calling. Our function header for floating point numbers would then look as function mult(x::Float64, y::Float64). When we call this function with mult(5, 6), we receive an error, ERROR: 'mult' has no method matching mult(::Int64, ::Int64 ), proving that Julia is indeed a strongly typed language. It does not accept integer parameters for the floating point arguments. (...) "

...in other words saying that "Julia is dynamic langauge, full stop." doesn't answer the question fully as for many readers it implies "weak typing", however it's dynamic, but strongly-typed, with state of art optimisations available as in statically typed languages, with proper multiple dispatch on all arguments (not single/this dispatch as in ie. java) etc.

It is definatelly worth playing with the language for people who hesiate on learning it - Julia provides some very interesting features not seen anywhere else.

Re: Codata in action, or how to connect FP and OOP

#32

Post by tsimionescu »

jcelerier wrote: post #11
tsimionescu wrote: post #10

Earlier quoted context omitted.

> Any OOP with inheritance does multiple dispatch. Java, C++ vitual functions, python via ducktyping. Java, Python and C++ require Visitor machinery that you ahev to write, for each case, to implement multiple dispatch (and Visitor only works for double dispatch, if you want more than 2 arguments you need even more boilerplate). Julia and CLOS essentially have that machinery built in. In case this is not clear, multi…

> Java, Python and C++ require Visitor machinery that you ahev to write, for each case, to implement multiple dispatch (and Visitor only works for double dispatch, if you want more than 2 arguments you need even more boilerplate). Julia and CLOS essentially have that machinery built in. we're in 2020 using value = std::variant ; void foo(value a, value b, value c) { struct { void operator(int, float, string) { } void…

Sure, it's 2020 and you have less boilerplate to write. It's still a little more than Julia or CL. Also, Java doesn't have anything similar in the std lib as far as I know.

More importantly, this is not as powerful as true multiple dispatch like in CLOS. There is no way to call other methods, there is no way to specialize partially (e.g. combine the variant with subtypes, and define methods only for some combinations of subtypes and super types on the parameters, and allow the implementation to choose the most specific one).

Edit: to add a few more details on my second point. CLOS (and I assume Julia too) allows you to call 'parent' implementations from a child implementation, similar to calling base type methods in virtual dispatch - you can call the next-most-specific method that would have matched the params, which you can't with the visitor. Also, say I have a generic function F(Foo, Bar). I could define methods for F(FooSubtype1, Bar) and F(Foo, BarSubtype1), and then call F(FooSubtype1() , BarSubtypeOfSubtype1() ) and have the right implementation get called (F(Foo, BarSubtype1)).

Re: Codata in action, or how to connect FP and OOP

#33

Post by shele »

saithound wrote: post #19
shele wrote: post #16

Earlier quoted context omitted.

People using Julia are quite happy how it alleviates the expression problem compared to languages they used before. Your argument, if I get it right, that Julia can't solve the expression problem because "the expression problem requires maintaining static type safety" reminds of the "Bumblebees can't fly" fable.

Well, the expression problem is a clearly formulated question: how can we have three desirable things at the same time (no need to modify existing code, no need for code repetition and no need for runtime type errors [1])? See also the project management triangle: if you need something fast, good and cheap, then fast, good and expensive won't be a satisfactory answer, no matter how many millionaires are satisfied wit…

Honestly, if you want to discuss the progress made on the expression problem by a dynamical language whose power and extensibility partly comes from a collection of informal, consensus based interfaces you have to start from a different theory.

Re: Codata in action, or how to connect FP and OOP

#34

Post by tsimionescu »

codr7 wrote: post #28
tsimionescu wrote: post #6

Earlier quoted context omitted.

I don't think multiple dispatch fixes this problem in any way. The idea here is that you can have an opaque interface. Then, adding new implementations of that interface is very easy. But, if you want to extend the interface, you need to modify all of the existing implementations. Multiple dispatch suffers of this problem just as much as single dispatch. In the other case, you have a transparent interface - anyone ca…

There is no need to modify existing implementations when extending an interface using multiple dispatch. You would need to add the required implementations, but there's really no way around that since the logic has to go somewhere. And as soon as you start actually dispatching on multiple arguments, using sum types to solve the same prolem quickly turns into spaghetti.

> There is no need to modify existing implementations when extending an interface using multiple dispatch.

Sure there is. If I have a function that takes a Foo and a Bar, and it calls a generic method on them, the generic method must have methods that cover the real subtypes of Foo and Bar. If someone had created subtypes of Foo and Bar and defined methods on all the generic methods that they knew about, and now you create a new generic method, you have absolutely broken the interface just as much as adding a new method to Iterable in Java.

Re: Codata in action, or how to connect FP and OOP

#35

Post by ivansavz »

mirekrusin wrote: post #3

"Category Theory is a branch of Mathematics mainly used by haskellers to annoy everyone else." :)

he heheh, I guess that's is a good an application as anything else.

Last month there was a conference on applied category theory https://act2020.mit.edu and as part of it there were some excellent introductory tutorials, which I highly recommend for anyone interested in CT: https://www.youtube.com/playlist?list=PLCOXjXDLt3pYPE63bVbsV...

It's the first time I watch lectures on CT and I actually understand something ;)

Re: Codata in action, or how to connect FP and OOP

#36

Post by dustingetz »

> Codata looks a lot like objects and methods, where the codata value is the object, and the eliminators are the methods. ... the usual Functional Programmer has been an Object Oriented Programmer before. Because of this, he is likely to know codatafrom OO, and now is starting to understand data from FP

To me Python, Java, C++ are about encapsulation of imperative effects, but article is not about that kind of OOP

I think article is talking about v.f() "eliminator" vs f(v) "constructor" and that objects and closures are equivalent, but I am missing the deep insight beyond that. I don't understand how this helps with the expression problem (lets me not recompile my code to add new match cases to add additional data constructors)

Re: Codata in action, or how to connect FP and OOP

#37

Post by heavenlyblue »

ori_b wrote: post #25
hlasdjlfhalwjk wrote: post #15

Earlier quoted context omitted.

Some Rust libraries use a trick to make sum types extensible without introducing breaking changes when a new invariant is added. There is a private/undocumented invariant in the type so every pattern match over the type must have a default/catch-all/wildcard branch (e.g. it is not possible to do an exhaustive match by naming all existing variants). By having a default branch, the match is always exhaustive and there…

Forcing a default case is a big step back towards dynamic typing.

“Hey - we have a solution to your type problem; we just disabled type checking. Genious”

Re: Codata in action, or how to connect FP and OOP

#38

Post by codr7 »

tsimionescu wrote: post #34
codr7 wrote: post #28

Earlier quoted context omitted.

There is no need to modify existing implementations when extending an interface using multiple dispatch. You would need to add the required implementations, but there's really no way around that since the logic has to go somewhere. And as soon as you start actually dispatching on multiple arguments, using sum types to solve the same prolem quickly turns into spaghetti.

> There is no need to modify existing implementations when extending an interface using multiple dispatch. Sure there is. If I have a function that takes a Foo and a Bar, and it calls a generic method on them, the generic method must have methods that cover the real subtypes of Foo and Bar. If someone had created subtypes of Foo and Bar and defined methods on all the generic methods that they knew about, and now you…

It must have enough methods to get the behavior you want, that doesn't always mean all subtypes.

Assuming you're running a version of Java that supports default implementations, which may often be used to avoid breaking the interface.

Sum types are a different story, as you would have to dive into existing code.

Re: Codata in action, or how to connect FP and OOP

#39

Post by rjsw »

I know people who are members of CODATA [1], didn't know they were working on this kind of thing. Maybe people could search for previous uses when they are picking a name for a concept, I think there are websites that let you do that /s.

[1] https://en.wikipedia.org/wiki/Committee_on_Data_for_Science_...

Re: Codata in action, or how to connect FP and OOP

#40

Post by peterkelly »

rjsw wrote: post #39

I know people who are members of CODATA [1], didn't know they were working on this kind of thing. Maybe people could search for previous uses when they are picking a name for a concept, I think there are websites that let you do that /s. [1] https://en.wikipedia.org/wiki/Committee_on_Data_for_Science_...

It's a polymorphic name.
Post reply on HN