Hacker News Reader

Comment by jdiez17 | Hacker News Reader

You can actually do functional programming in Go. Lack of generics just means you have to think harder.

In fact, a friend of mine did a Go library to write functional-style code: https://github.com/tcard/functional

We have two differing definitions of functional programming. I would argue that your code represents functional style in an imperative language.

If function pointers are sufficient to qualify a language as a functional, then that would include C/C++.

In contrast, Rust has support for the standard functional language primitives.[0][1][2]

[0]: http://static.rust-lang.org/doc/core/vec.html#function-map

[1]: http://static.rust-lang.org/doc/core/vec.html#function-foldl

[2]: http://static.rust-lang.org/doc/core/vec.html#function-filte...

How about this for functional programming in C? https://github.com/cioc/functionalC

It's got some of your primitives (map and filter but no fold, but I'm assuming that it's just a matter of getting bored before implementing it) and closures.

It's not a serious project, but it serves as a counter-example.

I'm not sure what you're trying to say this is a counter-example to, exactly. wting said "represents functional style in an imperative language"; that's all this seems to be. And as the author of that code themselves all but says, you'd be crazy to use that in production code, so it's not a particularly "good" implementation either.

Nobody's questioning that a map-like thingy can be implemented in any Turing-complete language you choose, the question is whether it's actually useful in the context of the rest of the language. I can in fact write a generic map function in Go, by using reflection, but it'll be very slow, and it will still absolutely require the user of the map function to cast the result into the proper type manually since the Go compiler can't do it for you.

(You actually can do something like closures in C, though managing the lifetime of the closure data struct can be tricky. And that's actually the problem with functional programming in C; the functional style does not technically "require" GC to work properly, but it sure does encourage it awfully strongly. Or you need something like Rust, with strong support for explicit lifetime management. In C you're just begging for memory leaks with a functional style.)

Is that because in C, you have to explicitly pass around your lexical scope as fields in a struct, and then you have to remember to explicitly deallocate the struct and null out any pointers to it later when it's no longer needed?

Pretty much, yeah. Closures can actually be a problem for memory deallocation in garbage collected languages. Someone I know was working on a common lisp app and eventually found some of their performance problems to be related to the amount of data held onto by closures.

The thing about languages is that you can write other languages inside them. You can implement garbage collection in C. You can compile it to Java bytecode. You can convert Java bytecode to x86 assembly. You can write your own preprocessor to allow C++ style templates in Go. You can make a shim that will allow you to make calls to the Go networking library from a shell script.

The question is not whether you can do something, it's how many hoops the language makes you jump through to do it.

Can you be more precise about the difference between a program written in the functional style, and one which is written using functional programming?

Well there is the "official" definition on Wikipedia.[0]

Informally, my definition of a functional programming language is one that supports functional style as the default. (Hooray for using a recursive definition. :p) The language should strive for referential transparency and the language and compiler should be optimized for functional idioms.

Let's define the sum of a list functionally[1]:

    # Python
    sum = lambda x: reduce(int.__add__, x, 0)

    # Haskell
    sum = foldl' (+) 0

You could write this same function in C using function pointers and arrays. However it's not very convenient to do so. You would need to write a reduce function, an add function, anonymous functions don't exist, and syntactically it would be very messy. On top of all this, the compiler is not optimized for reduce functions vs an imperative for loop.[2]

More generally, functional style typically refers a style of programming where most functions are pure and side effects are contained specifically. This allows for easier reasoning of a program's correctness.

John Carmack has a post about functional programming in C++:

http://www.altdevblogaday.com/2012/04/26/functional-programm...

Summed up, functional style is about containing side effects and functional programming has built-in support for common idioms.

[0]: https://en.wikipedia.org/wiki/Functional_programming

[1]: This ignores the fact that sum() is already provided in most functional languages.

[2]: Python straddles my definition of functional programming and that's why it's awesome and frustrating at the same time. It supports many staple functional idioms but is not optimized for it. Function calls are very expensive, and thus recursive performance is also hurt tremendously.

Plus Guido hates functional programming:

http://python-history.blogspot.com/2009/04/origins-of-python...

> Lack of generics just means you have to think harder.

Or use other languages that are more developer friendly.

Name one that has generics and is developer friendly.

Well, you can start with all the functional languages that automatically are able to do these things you're talking about, like Haskell and so on. You can argue they aren't 'developer friendly' but you never defined that term to begin with, and people are certainly productive with those languages (developer friendly compared to what? Go is certainly not the most accessible language)

But in terms of more 'mass market' languages, C++ and C# both have incredibly robust generics that can be used to do real, no-foolin' functional programming, though doing it in C++ certainly takes a lot more effort and leans on modern libraries - closures are a comparatively recent introduction to the language. You've also got 'mass market' functional languages like F# to have fun with.

Then there are the more fun options, like writing your functional code in Lua or Python and running it in a high-performance runtime like LuaJIT/PyPy to get fairly competitive performance without even needing explicit typing or built-in 'generics'.

I think F# has aesthetics similar to Python, despite being a statically typed language in the ML family. It's open sourced, with great IDE support on Windows (via Visual Studio, including a free option) and good IDE support on other platforms via Xamarin's tooling. Does that count as "developer friendly"?

Developer friendly is a matter of taste. As for having some form of generics:

- C++

- Haskell

- Modula-3

- Ada

- Java

- OCaml

- Delphi

- F#

- Virgil (from Google)

- VB.Net

- Eiffel

- Sather

- Zonnon

- Scala

Just a small list.

Reply on news.ycombinator.com