Tag Info

New answers tagged

2

I'm not sure how easy this would be to implement in Scala, but here's how I'd look to structure it in Haskell: To begin I'm going to review a couple of the monads which Haskell and F# provide -- You're probably familiar with them, but I'll review them just to set the stage. In Haskell there is the IO monad which is used for doing IO operations (e.g. web ...


9

In general, you use higher-rank polymorphism when you want the callee to be able to select the value of a type parameter, rather than the caller. For example: f :: (forall a. Show a => a -> Int) -> (Int, Int) f g = (g "one", g 2) Any function g that I pass to this f must be able to give me an Int from a value of some type, where the only thing g ...


6

Higher rank polymorphism is extremely useful. In System F (the core language of typed FP languages you're familiar with), this is essential for admitting "typed Church encodings" which is actually how System F does programming. Without these, system F is completely useless. In System F, we define numbers as Nat = forall c. (c -> c) -> c -> c ...


8

In the java world, it is called Runnable. In the C# world, it is called Action. But, there is a better name which nicely fits within a larger view of things. The larger view of things comes later, when you decide that besides your parameterless void functional interface you also need to have similar functional interfaces that accept one, two, or more ...


37

Java's choice to do it that way with a separate name for every arity was stupid. It's not exactly worth emulating. However, if you must for the sake of consistency, or if you're writing very generic library code, Konrad's suggestions are good. I might throw Procedure into the ring. Using a pseudo-functional paradigm doesn't mean normal naming principles ...


14

Why not Command? Given that it takes no data and returns no data, but assuming that calling it causes some effect (otherwise it would be rather pointless really), I imagine that's roughly the only thing it can do - fire an action, make something happen. Speaking of which, there's also a generic Action delegate in .NET. Unlike Java's Consumer it can take ...


3

Why is an anemic domain model considered bad in C#/OOP, but very important in F#/FP? Your question has a big problem that will limit the utility of the answers you get: you are implying/assuming that F# and FP are similar. FP is a huge family of languages including symbolic term rewriting, dynamic and static. Even among statically-typed FP languages ...


0

I am not too familiar with Haskell, so I will try to answer the general part of the question as a non-academic functional C# developer. After doing some reading, it turns out that: 1) Java wildcards are similar to existential types: http://stackoverflow.com/questions/1031042/difference-between-scalas-existential-types-and-javas-wildcard-by-example?rq=1 ...


0

From the OOP point of view functions can be considered to be single-method interfaces. Interface is a stronger contract than a function. If you are using a functional approach and do a lot of DI then in comparison to using an OOP approach you will get more candidates for each dependency. void DoStuff(Func<DateTime> getDateTime) {}; //Anything that ...


5

is Functional Programming a viable alternative to dependency injection patterns? This strikes me as an odd question. Functional Programming approaches are largely tangential to dependency injection. Sure, having immutable state can push you to not "cheat" by having side effects or using the class state as an implicit contract between functions. It ...


8

Dependency management is a big problem in OOP for the following two reasons: The tight coupling of data and code. Ubiquitous use of side effects. Most OO programmers consider the tight coupling of data and code to be wholly beneficial, but it comes with a cost. Managing the flow of data through the layers is an unavoidable part of programming in any ...



Top 50 recent answers are included