Hacker News Reader

Comment by tel | Hacker News Reader

There is still no construction of a study that I would think would convince me of those figures. The number of confounders is invariably far too high.

But there are definitions of at least the latter two which are substantially justified via an FP take on the world.

Really, though, I think FP does itself a disservice by claiming to be a "style" of computing much like OO. It's really just a back-to-the-basics take on what "is" computing and from it you can get a very well-behaved foundations of formal languages to build your CS (of whatever brand you like) atop. This has proven to be incredibly fruitful as a theory since, honestly, something like 1907.

View on HN

This is a really important point that I'm not sure I've seen before in a discussion about the adoption of FP. You're completely right, but I can't imagine FP language advocates would get very far by leading with the history of type theory.

IMO when it comes to productivity most of the time the platform, and by platform I mean documentation, build tools, package managers and such, are a big influence if not the biggest.

From my experience with functional languages, they slack in that aspect.

I like Lisp's simplicity and I like the elegance in Haskell but the only Lisp I know that have a workflow that kinda matches my taste is Clojure, which reeks of java. I tried Haskell several times and I liked the language but I can't stand cabal.

That's why I believe in Go, the language isn't eye popping, but every aspect of the workflow makes me smile and think "that's how you do it".

And by that I mean the no-versioning policy, web stuff built in to the language, and I just love the workspace structure[0].

It is transparent, no need to google to find out where external packages are installed if you want to fiddle with it's source, no worries about version hell, no worries about unicode.

I've read good things about racket in that aspect but I'm yet to try it.

[0]https://golang.org/doc/code.html

Lots of people are and have been "productive" in Haskell, various Lisp dialects, O'Caml, and so on.

I worked at a startup whose Haskell backend was quite pleasant to work with and served them very well. This site itself is written in Arc, as you probably know, and Paul Graham has written several essays about the "productivity" he and his team achieved using Common Lisp.

People can work productively with software using all kinds of tools and languages. As you mention, a lot of it might come down to taste, likes and dislikes, habits, etc. Of course you're going to be more productive if you're familiar with your tools. So your experience with productivity isn't really an objective indicator for anyone else.

I didn't mean you can't be productive in functional languages. What I'm criticizing are the platforms and I don't see that as too much of a subjective matter.

For me as a user Haskell(the platform) is inferior to, say, Go, simply because I can manage external packages that much easier. Thus if I needed to get something done I'd rather use Go, not because I think it's a better language than Haskell, but because of the pain in dealing with package versions, building, etc.

Basically what I'm saying is that you don't see that much adoption, and thus data to endorse the productivity claims because of the platforms and not because the languages per se are bad.

Pg said people don't use lisp because it looked weird and it's not popular[0] and I think it applies to functional languages in general. I don't think you can/should solve the former, but by having friendlier/better platforms you could start solving the latter.

http://www.paulgraham.com/iflisp.html[0]

How do you personally do package management with versioning in Go? Last time I checked Haskell was better than Go here.

Go packages have no versions, if you make breaking changes you should make a new package so you don't need to specify a version in some metafile to stop the build process from breaking.

So basically use master or fork all your dependencies to freeze versions.

Why would you freeze it? I understand that even with the Go policy on versions it can happen that a change on some external package can cause problems, but that's unlikely to happen and as you have the packages as git repos you can just git reset it back to a commit when it was stable or even better: fix the problem and contribute back.

Why does Java have Maven, Haskell have Cabal, or Python have pip? So you can grab some old code written by someone no longer at a company, build it, fix bugs, and complete your task in a reasonable amount of time.

Without version constraints it's much harder to even say "I can build this program" much less "I can fix this bug".

> that's unlikely to happen and as you have the packages as git repos you can just git reset it back to a commit when it was stable

You seem to be assuming you are the one who wrote the code. I'm more speaking in cases where someone you don't know and can't contact wrote the code. Have you ever had to reverse engineer a very large dependency chain? It is absolutely no fun :/

To be honest, while I am empathic to the argument you're making I think it's orthogonal. There is a fundamental difference in the design of languages to consider and then, atop that, one about actual existing technologies and their platforms.

I agree that Go's workflow philosophy is great. I wish more languages adopted it. But that's the thing, it's easily mixed and matched. On the other hand, making something like Ruby genuinely type-theoretically typed, while an admirable and interesting goal, will probably never happen. Their worlds are just different.

> back-to-the-basics take on what "is" computing... to build your CS (of whatever brand you like) atop

I feel that we've given many years of attention to functional programming, and it's been disappointingly unfruitful in most areas of CS, such as computational complexity, cryptography, machine learning, or computer graphics. Most new ideas coming out of the FP camp are applicable only to FP itself, like monads. We've discussed that before: https://news.ycombinator.com/item?id=8563817

Part of the mismatch is that many interesting algorithms are impure and cannot be easily made pure. I'd like the "foundation" of CS to give a faithful mathematical description of what computers can and cannot do. Is that too much to ask?

But the bigger problem is that FP treats functions as black boxes, and that's just not enough to prove interesting results in most areas of CS. A better "foundation" would try to describe computational behavior and reason about it, instead of abstracting it away. I admit that's a very vague idea, but I'm not smart enough to make it concrete :-)

> I'd like the "foundation" of CS to give a faithful mathematical description of what computers can and cannot do. Is that too much to ask?

http://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis

> A better "foundation" would try to describe computational behavior and reason about it, instead of abstracting it away

A lot of interesting research does exactly this, and a lot of it has found its way into ML-family languages. The starting point (or "foundation") in every case is a typed lambda calculus. Machine models, like turing machines, are just annoying to reason about and not extensible in any meaningful way.

Alas, the Church-Turing thesis doesn't say that every imperative algorithm can be translated to lambda calculus while keeping the same time and space complexity. The two main culprits are in-place mutation and O(1) array indexing.

Sorry for the glib answer. I'm not arguing for programming in the pure, untyped lambda calculus.

My point was that it's possible to systematically extend (or restrict) the lambda calculus and associated techniques. You can add effectful operations and give them semantics (e.g. as functions on stores), define a cost semantics and prove whatever you want while being completely formal.

Try extending RAMs with dynamic allocation, call stacks, or anything to make it more natural to write down a whole algorithm. Try proving something about the composition of RAM programs. I don't think you'll get very far.

Maybe we're talking about slightly different things?

There are many interesting algorithms that are usually analyzed in an imperative setting, like in-place quicksort, Knuth-Morris-Pratt, or Gaussian elimination. There doesn't seem to be any benefit to analyzing them in an FP setting, because it's not easier and doesn't yield new insights.

It seems to me that the FP approach only really shines on algorithms that are "naturally tree-like". For example, I'm a big fan of Okasaki's work on purely functional data structures, and of Blelloch's work-depth model. But let's not oversell FP techniques as the foundation of all algorithm work.

Yes, we're talking about different things. I took the parent comment to mean that talking narrowly about "FP" as programming with pure functions isn't very useful any more. It may have made sense in the 90s when few widely-used languages had h.o.f, but that fight has pretty much been won.

The field that gave rise to FP has a lot to say about how we specify languages and their properties and how we prove things about programs in general. That includes languages with all kinds of effects: state, exceptions, concurrency, etc, and equally as imporant, mechanisms for abstraction and modularity. There's currently no other "foundation" for computation that lets us define these ideas formally.

In discussions of FP, the contributions of the field get reduced to "programming with functions".

It doesn't even say that any imperative algorithm can be translated---merely Turing Machine algorithms which also don't happen to have O(1) array indexing, e.g..

Elsewhere mafribe mentions parallel processing... which is also clearly in another class.

I think pure FP gives a better foundation for mutation, too. It's very straightforward to use something like a pure FP language to make very clear the choice of semantics involving mutable slots.

Reply on news.ycombinator.com