Live data from Hacker News

Functional Programming For The Rest of Us

defmacro.org

61–69 of 69 posts

Re: Functional Programming For The Rest of Us

#61
post #54

After racking my brain for years trying to figure out why shitty "design patterns" have been winning while functional programming (despite its superiority to typical object-obfuscated architecture) remains on the back-burner, I've come to a few conclusions. 1. The name "functional programming" doesn't sell us; it just sounds impractical. What we do isn't really "functional programming" in a purist sense. We need side…

Scala is actually less complex than Java by far. I'm sorry, but I can't let this one go by. I can accept the argument that FP may be less complex once you get used to it (not sure I agree but let's go with it) and immutability by default is great but just because Scala and/or it's surrounding community allow or encourage this style doesn't mean that Scala-the-language is less complex than Java-the-language. That's a…

If I recall correctly, the Scala spec is about one-third the size of the Java spec.

Re: Functional Programming For The Rest of Us

#64
post #54

Earlier quoted context omitted.

Scala is actually less complex than Java by far. I'm sorry, but I can't let this one go by. I can accept the argument that FP may be less complex once you get used to it (not sure I agree but let's go with it) and immutability by default is great but just because Scala and/or it's surrounding community allow or encourage this style doesn't mean that Scala-the-language is less complex than Java-the-language. That's a…

If I recall correctly, the Scala spec is about one-third the size of the Java spec.

If that's true, then Scala was simply specified less precisely than Java. As lemming said, Scala is a massive superset of Java's functionality.

Off the top of my head, I can rattle off a slew of functionality in Scala that's not in Java:

* Regexp literals

* partial/curried functions

* for comprehension

* argument defaults

* case classes (and switches thereon)

* tuples

* combinators

* XML interpolation

* Mixins

* Fine-grained visibility

Caveat: I'm no Scala expert. Some of this may be in the libraries and not the language proper.

Now... what Java functionality can you name that's not in Scala?

Re: Functional Programming For The Rest of Us

#65

Earlier quoted context omitted.

If I recall correctly, the Scala spec is about one-third the size of the Java spec.

If that's true, then Scala was simply specified less precisely than Java. As lemming said, Scala is a massive superset of Java's functionality. Off the top of my head, I can rattle off a slew of functionality in Scala that's not in Java: * Regexp literals * partial/curried functions * for comprehension * argument defaults * case classes (and switches thereon) * tuples * combinators * XML interpolation * Mixins * Fine…

Not that this diminishes your point, but many of these features (e.g. case classes and pattern matching, list comprehensions) actually make real-world code less complex.

You're right that every bit of complexity Java has also trickles into Scala. For example, Java's broken generics certainly add undesired complexity (type erasure, wonky types) to Scala. Still, I think that idiomatic Scala generally is less complex per unit functionality delivered. It's true that "full Scala" must be more complex than Java because it contains Java as a subset, but I think that more can be accomplished in Scala without making code complex or verbose to the point that it becomes a problem.

In other words, to do comparable things requires far less complexity in Scala than in Java, because Scala delivers the best bang-for-buck by picking the most efficient abstractions. For example, Java concurrency requires a JVM expert to get it right (did you know that doubles and longs aren't thread-safe?) whereas Scala concurrency just requires someone who has a basic understanding of the Actor model.

Re: Functional Programming For The Rest of Us

#66
post #56
post #48

Earlier quoted context omitted.

This is a single introductory sentence. You should not reason that far with it. With that reasoning you could claim addition is impure, because time() + 1 changes over time. map is definitely a pure function. If you apply it to impure arguments, of course the result will be impure. The point in FP is to avoid using 'time', not 'map'.

That's a good argument - but it does not really resolve the definition problem. It seems that some people think that 'functional programming' means 'programming with mathematical functions' - while others think that it means 'programming with first-class functions'. I can take this or that definition - but if wikipedia uses one definition - this sounds like a good argument that more people use the 'mathematical funct…

> wikipedia uses one definition

Let me repeat: you used an introductory sentence as a "definition" of FP and are overinterpreting it. If you read later you will see:

> Functional programming languages, especially purely functional ones...

So Wikipedia distinguishes functional programming and pure functional programming. In fact there is a separate article on pure functional programming, which says that destructive modifications are "excluded", not just "avoided".

Functional programming does not have clear boundaries. You can have advantages of functional programming even if you introduce _a bit_ of FP style in a very imperative program. Conversely, you can write in very imperative style in Haskell.

Re: Functional Programming For The Rest of Us

#67
post #7
post #4

Aside: I am maybe 50-60 hours into my first haskell project using yesod. I have read about half of "real world haskell" and about half of "learn you a haskell". Other than this, all of my experience is in iterative languages. (c++,python,php). One thing that comes up is "if your program compiles it's almost certain to be correct"; and it has been true again and again for me. It's an odd, eery feeling that honestly I…

I think the "if it compiles, it works" has to do with Haskell's type system being much more expressive than most static languages, and that most of your code will be declarative and pure. Purity helps because your program will necessarily be composed of small, self-contained modules (usually functions) that have no implicit dependencies. The type system helps because you can encode a lot of the code's intent in type…

On the other hand, mixing multiple monads is sheer hell, and lazy evaluation makes speed and memory usage difficult to predict.

Try Disciple sometime, or Scala!

Re: Functional Programming For The Rest of Us

#68
post #66
post #56

Earlier quoted context omitted.

That's a good argument - but it does not really resolve the definition problem. It seems that some people think that 'functional programming' means 'programming with mathematical functions' - while others think that it means 'programming with first-class functions'. I can take this or that definition - but if wikipedia uses one definition - this sounds like a good argument that more people use the 'mathematical funct…

> wikipedia uses one definition Let me repeat: you used an introductory sentence as a "definition" of FP and are overinterpreting it. If you read later you will see: > Functional programming languages, especially purely functional ones... So Wikipedia distinguishes functional programming and pure functional programming. In fact there is a separate article on pure functional programming, which says that destructive mo…

My point is that the definition of functional programming is this purity you mention not using first-class functions. Pure means that something has more of that thing you want and impure means it has less - so pure functional programming has more 'functional programming' then 'standard functional programming'. Sure completely pure functional programming is impractical - there are degrees to how purely functional are the languages we use in practice - but this is the point practical languages are more or less functional and how much are they functional depends on how much they depend on state manipulation not on using higher order functions or having first class functions.

Defining functional programming as programming with first-class functions is a consistent definition and could be used if not the fact that more people use the other definition (at least that is what the wikipedia definition and other online material makes me believe).

Re: Functional Programming For The Rest of Us

#69
post #68
post #66

Earlier quoted context omitted.

> wikipedia uses one definition Let me repeat: you used an introductory sentence as a "definition" of FP and are overinterpreting it. If you read later you will see: > Functional programming languages, especially purely functional ones... So Wikipedia distinguishes functional programming and pure functional programming. In fact there is a separate article on pure functional programming, which says that destructive mo…

My point is that the definition of functional programming is this purity you mention not using first-class functions. Pure means that something has more of that thing you want and impure means it has less - so pure functional programming has more 'functional programming' then 'standard functional programming'. Sure completely pure functional programming is impractical - there are degrees to how purely functional are…

Is Prolog a functional language, as it avoids state manipulation but has no first-class functions? I think not. There are some characteristics of functional languages - including first class and higher order functions, relying on immutability, declarativity etc. Choosing just one of them to measure how much a language is "functional" is a mistake IMO.
Post reply on HN