Hacker News Reader

Comment by ane | Hacker News Reader

Your Python example is functional programming! You're doing exactly the same thing as in Clojure, just not in a Lisp syntax.

Therefore, in your question, you could substitute Clojure with functional programming, and the examples in which FP allows you to express thoughts you wouldn't know how to express in for, while and so on -- are plentiful.

I may not be answering your question, but there's a reason for that: the functional programming aspect isn't Clojure's main selling point. It's the other ideas. Software transactional memory, immutability, its emphasis on state and identity, the protocol system, transients, concurrency, transducers, the list goes on.

View on HN

You are referring to higher-order function I assume. I don't think that is a property of FPL.

I am definitely not dismissing FPL, I am just arguging about the actual examples given were not strong enough to dismiss Java being hard to read.

Higher order functions are _the_ defining property of FPL. Even though a lot of FPL people might want you to believe it's types.

Lambda calculus (the theoretical foundation for all functional languages) was initially untyped.

The big difference is that Clojure defaults to immutable data structures. While you can chain functions together in Java and Python, you still have to manually keep track of all the references.

The main benefit of modern functional languages is in their use of revisioned data structures. This has same benefits as garbage collection.

Without GC you have to manually track where you allocate and deallocate things, and this is highly error prone. With GC the runtime does this for you, and you can focus on other things.

Same thing applies with mutable and immutable data. With mutable data structures all the changes are done in place, and you have to keep track of everywhere it's used to update it predictably. With immutable data structures you're "copying" the data any time you make a change, and the runtime keeps track of the references for you.

There's nothing preventing you from writing analogous data structures in any language.

No one wants to admit that their language choice is because of the cultural norms in their language community, but if you can hide some complexity behind a language construct, you can hide the same complexity behind a function call. It's just a question of how much of the work required to do that has already been done by the community.

You're just not going to win the "my language can do x more concisely than a function called x in your language!" argument. You're better off with "this is easy and my language and you'd have to write a function to do it in yours."

You're right, _you_ can write immutable data structures in any language. But for example, immutable.js and/or mori do practically nothing to fix the mutability problems with javascript, since immutability is not the default.

There's nothing preventing you from writing analogous data structures in any language.

The problem is the language culture and what is idiomatic. I write Python in my day job and while I could certainly write immutable data structures in Python and code in a way that treats data as immutable, it would be going against what is idiomatic in the language, which means that it won't play well with libraries and that my coworkers can still trample over my data without my knowledge. That is, the language gives me no guarantees whatsoever that my immutability is actually respected and that other code somewhere else that I did not write (either application code written by a coworker or library code written by a stranger) respects the immutability.

I find this argument similar to asking why bother writing in any high level language when you can implement the same things in assmembly. Hell, why don't we all just program turing machines directly?

Languages carry a lot more with them than just the features - they carry idioms and culture and community trends. All of these (and even small syntax differences) influence how we think about problems and how we create and structure solutions. They also influence how my code will interact with other peoples (and theirs with mine).

Exactly. But there are also cultures within languages. Just because your language has a clique doesn't mean you have to hang out with them.

True, but how far away you can get or how well you can play with libraries or other code can be limited.

Arguably, first class higher order function (and immutability) is defining characteristics of functional programming.

Although, I don't think the functional/ imperative is necessary a good axis for categorizing languages. There are potentially more differences between Clojure/Ocaml than Python/Clojure, for example.

They are no longer exclusive to FPLs but higher order functions are definitely a property of FPLs

Reply on news.ycombinator.com