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

A Year of Functional Programming

japgolly.blogspot.com.au

Post reply on HN
Print view View original

121–130 of 172 posts

Re: A Year of Functional Programming

#121

Post by _Robbie »

vram22 wrote: post #120
noelwelsh wrote: post #21

Earlier quoted context omitted.

1. I think "avoid globals" is a reasonable way into FP, but FP itself involves a lot more than just avoiding coupling via global state. I would say the main components are - nested definitions; - lexical scoping; - first class functions; - static typing; and - a whole bunch of programming techniques (e.g. monads) that have grown around them. 2. You certainly can use FP ideas in low-level programming but you'll have d…

>- static typing; I'm not an expert on the theory or design of programming languages, but isn't static typing orthogonal to FP?

I will discuss Haskell, since I am not very familiar with other FP languages. In Haskell static typing is more useful than in other languages. This is because in Haskell the type signature of a function gives an upper bound of what the function does. In an impure language, a function may change any accessible mutable values and/or perform IO. These possible side effects mean that in an impure language the type of a function is a very weak indicator of what the function actually does.

Re: A Year of Functional Programming

#122

Post by chetanahuja »

jerf wrote: post #98
pron wrote: post #63

Earlier quoted context omitted.

> With Haskell their reuse was an order of magnitude higher as measured by the number of external library dependencies! If we're talking real world -- as we should -- then this should be contrasted with the tradeoffs and alternatives. The most important kind of code reuse, IMO, actually happens at a larger scale, and in the past few years has worked remarkably well, since the advent of open-source. I'm talking about…

"The most important kind of code reuse, IMO, actually happens at a larger scale," There's a hidden instance of begging the question here, which is that the reason why "large-scale" code reuse is "more important" in the real world is that OO has largely been a failure for mid-scale code reuse. You can build enormous frameworks in OO that serve a need (at some cost in constraining your options, but one that can be wort…

'Therefore, since OO has been the dominant paradigm for decades now, we do not see any middle-scale reuse in the "real world" '

I'm not a blind fan of any one type of software methodology but this assertion is completely wrong. Java and C++ world is replete with widely used code libraries that are used and reused in millions of diverse software projects. This fact is so obvious that I don't feel the need to list out the examples here, but I will if challenged.

Re: A Year of Functional Programming

#123

Post by briantakita »

> Realisation: Abstractions

Objects are coarsely grained abstractions. Separating function Modules from the Data allows more opportunity to be DRY, better performance, and more complexity scalability.

> Realisation: Confidence. Types vs Tests > In Ruby, that often meant testing it from every angle imaginable, which cost me significant effort and negated the benefit of the language itself being concise.

This is largely a cultural artifact from the history of the Ruby & Java communities.

We are discovering that is is more useful to have your tests written from a black box perspective (in any language). White Box Testing is less useful and causes the architecture to be locked down. White Box Testing should be a rare occurrence.

From my development practices, Static + Strong typing helps with performance & debugging failing tests, but not much else. It imposes rigidity in the architecture & delays my development feedback loop.

I know that this is a matter of taste & I will catch much flak for my opinion as it conflicts with other peoples' taste, but it's my truth :-)

Re: A Year of Functional Programming

#124

Post by jimbokun »

brudgers wrote: post #112
takeoutweight wrote: post #94

Earlier quoted context omitted.

I suppose I can only speak for myself, but as a functional programmer I would never ask you to give up mutation completely. I do think it's nice that most FP languages give us pure functions and persistent data structures that are easy to use and relatively performant, so we don't have to go out of our way to provide a pure (by construction) abstraction when we want to. The key idea is to be honest when you are askin…

Maybe, what I am thinking is that a language which makes it easy to program in a functional style, should make it equally easy to program in an imperative one. By extension, this may mean that a good language for functional programming ought to make it easier to program imperatively than languages designed to facilitate imperative programming. Of course, this begs the question of what is easier and harder and better…

"But the von-Neumann model is useful because it is a model that we can easily get our heads around."

I am skeptical of this statement.

Programmers make a lot of errors when reasoning about mutable state, so I don't think it's fair to say "we can easily get our heads around the von-Neumann model". My intuition is programs written without mutable state will, on average, have fewer errors, which suggests to me the more "mathematical" nature of functional programming is actually easier to wrap one's head around.

Not sure what empirical data is out there to test this hypothesis.

Re: A Year of Functional Programming

#125

Post by vram22 »

_Robbie wrote: post #121
vram22 wrote: post #120

Earlier quoted context omitted.

>- static typing; I'm not an expert on the theory or design of programming languages, but isn't static typing orthogonal to FP?

I will discuss Haskell, since I am not very familiar with other FP languages. In Haskell static typing is more useful than in other languages. This is because in Haskell the type signature of a function gives an upper bound of what the function does. In an impure language, a function may change any accessible mutable values and/or perform IO. These possible side effects mean that in an impure language the type of a f…

So you're saying that static typing helps FP and hence is sort of a part of it?

Thanks for the answer.

Re: A Year of Functional Programming

#126

Post by noelwelsh »

vram22 wrote: post #120
noelwelsh wrote: post #21

Earlier quoted context omitted.

1. I think "avoid globals" is a reasonable way into FP, but FP itself involves a lot more than just avoiding coupling via global state. I would say the main components are - nested definitions; - lexical scoping; - first class functions; - static typing; and - a whole bunch of programming techniques (e.g. monads) that have grown around them. 2. You certainly can use FP ideas in low-level programming but you'll have d…

>- static typing; I'm not an expert on the theory or design of programming languages, but isn't static typing orthogonal to FP?

Yes and no.

A lot of the action in modern programming languages is in type systems. Static typing is synonymous with the dominant group of programming languages that subscribe to the "functional" label. There are other languages, such as Scheme, that are not statically typed that also subscribe to this label but they don't have the same mindshare at present.

It's important to keep in mind that FP does not name some formally defined concept like the number 3 or the function cos. Rather it's a name given to a group of people and programming languages that share a common ancestry and world view. The definition is fuzzy and can be split many ways.

Re: A Year of Functional Programming

#127

Post by jimbokun »

coolsunglasses wrote: post #80
jacquesm wrote: post #2

" Recently I looked at some code I wrote 8 months ago and was shocked! I looked at one file written in “good OO-style”, lots of inheritance and code reuse, and just thought “this is just a monoid and a bunch of crap because I didn't realise this is a monoid” so I rewrote the entire thing to about a third of the code size and ended up with double the flexibility. Shortly after I saw another file and this time thought…

Real world example: https://github.com/bitemyapp/bloodhound/blob/master/Database... https://github.com/bitemyapp/bloodhound/blob/master/Database...

1. What does this code do? 2. Where is this previous code this replaced that was 3 times the size?

Re: A Year of Functional Programming

#128

Post by vram22 »

noelwelsh wrote: post #126
vram22 wrote: post #120

Earlier quoted context omitted.

>- static typing; I'm not an expert on the theory or design of programming languages, but isn't static typing orthogonal to FP?

Yes and no. A lot of the action in modern programming languages is in type systems. Static typing is synonymous with the dominant group of programming languages that subscribe to the "functional" label. There are other languages, such as Scheme, that are not statically typed that also subscribe to this label but they don't have the same mindshare at present. It's important to keep in mind that FP does not name some f…

Interesting, thanks.

>It's important to keep in mind that FP does not name some formally defined concept like the number 3 or the function cos.

Got it.

Re: A Year of Functional Programming

#129

Post by tieTYT »

mark_l_watson wrote: post #40

Nice article! I have been using Clojure for years, initially because a repetitive customer mandated its use, later for my own projects because it reduced my development time and is fun to code in. I tried Scala (really liked Martin Odersky's Coursera class!) but it did not stick. That said, Haskell has started to win my mind share. At least for my own projects I have been mostly using Haskell this year, with some bit…

I'm pretty ignorant of both languages (but I have novice experience in both): Moving to Haskell, don't you miss Lisp macros? How do you deal with that?

Re: A Year of Functional Programming

#130

Post by brudgers »

jimbokun wrote: post #124
brudgers wrote: post #112

Earlier quoted context omitted.

Maybe, what I am thinking is that a language which makes it easy to program in a functional style, should make it equally easy to program in an imperative one. By extension, this may mean that a good language for functional programming ought to make it easier to program imperatively than languages designed to facilitate imperative programming. Of course, this begs the question of what is easier and harder and better…

"But the von-Neumann model is useful because it is a model that we can easily get our heads around." I am skeptical of this statement. Programmers make a lot of errors when reasoning about mutable state, so I don't think it's fair to say "we can easily get our heads around the von-Neumann model". My intuition is programs written without mutable state will, on average, have fewer errors, which suggests to me the more…

I probably wasn't clear enough. My point is that the von-Neumann model allows us to walk up to a computer and point and say, "Here is the memory and here is the processing unit and here on this test probe of register 47 we see the instruction to move the contents of memory address 42 from memory into register 19." Even my mom can understand a sketch of the von-Neumann model to some degree.

Because functions are not a model of a computer, but a means of computation, there's no obvious picture. Indeed, if I look at the test probe, I don't see a function but an instruction to move the contents of memory address 42 from memory into register 19. I can draw a diagram of a Turing machine in a few minutes, not so with the lambda calculus. The equivalence is only mathematical, and that cuts both ways. There's no way to write a functional version of The Art of Computer Programming because mathematical equations don't have running times.

Post reply on HN