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

161–170 of 172 posts

Re: A Year of Functional Programming

#161

Post by soegaard »

brudgers wrote: post #160
samth wrote: post #152

Earlier quoted context omitted.

I'm not sure what you mean by "syntactically a mess" but Racket provides `mlist` which sounds like exactly what you want [1]. [1] http://docs.racket-lang.org/compatibility/mlists.html

Thanks. It's not linked from the Racket Reference. Clicking on "mutable lists" in 4.10 is a 'did you mean recursion ?' experience. http://docs.racket-lang.org/reference/mpairs.html?q=mcons#%2... That it takes an intimacy with the code base of a regular repo contributor to find it suggests how deeply buried 'mlist is.Or to put it another way, Racket the language does not provide 'mlist. Racket the ecosystem does but d…

For us that were around when the default changed from mutable to immutable cons cells, known the rule "just prepend an m". I agree that the link in section 4.10 can be improved - but calling it "obfuscation" and "deliberate" is taken it too far. File a bug report, and I bet it will be fixed.

Re: A Year of Functional Programming

#162

Post by nbouscal »

pron wrote: post #157
mightybyte wrote: post #141

Earlier quoted context omitted.

> And as long as Haskell is used by such a tiny group of people I'm guessing Haskell is used by more people than you think. There are 6500 packages on hackage. The Haskell subreddit has more than 16,000 subscribers. And there are usually more than 1300 people in the #haskell IRC channel at any given time. That's more than #ruby and ##javascript and about the same as #python. Also, Standard Chartered bank has roughly…

> We look at the language features and think about how they can help us manage common situations in software development Maybe some people do, but when I pick a programming language, language features are among the last things on my mind. I look at the available tools (profilers etc.), available libraries (particularly in the domain that interests me), quality of documentation, the size of the community and its vibra…

If there were superb tooling, libraries, and documentation available for Brainfuck or INTERCAL, you would not find that sufficient reason to program in those languages. Of course, you will say, such a situation would never exist, because nobody is going to write libraries for INTERCAL. With this argument, though, you concede that language features are important. You just estimate them by proxy: languages with features that encourage library authorship pass your test. Rather than use this proxy test, some of us who are well informed about PLT choose to judge languages on their merits directly.

Nobody in this thread is talking about toy projects. Developers who use mainstream programming languages do not have a monopoly on real work. The consistent assumption made in these discussions that FP practitioners don't work on "serious projects intended for production" is misguided and insulting.

Re: A Year of Functional Programming

#163

Post by nbouscal »

pron wrote: post #132
mightybyte wrote: post #116

Earlier quoted context omitted.

> The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. This is an instance of begging the question too. Newer, less popular languages will always have fewer libraries and bindings relative to more popular languages. It might be an argument against using Haskell at the current point in time, but it has nothing to do with the merits of the language itself. Bu…

> It might be an argument against using Haskell at the current point in time, but it has nothing to do with the merits of the language itself. The merits of the language itself don't matter that much. A language isn't a piece of art to be admired. And as long as Haskell is used by such a tiny group of people, the merits of the language itself can't even be argued well, because it's unclear how they work in practice f…

Merit is not exclusively a characteristic of art. Tools have merits, and awareness of those merits is very important for any practitioner who seeks to use those tools in their work. If I went into my father's woodshop and sought to use his lathe to attempt to plane a board, he would rightfully yell at me.

Merits of programming languages can be argued well, because there is an entire theoretical discipline dedicated to the understanding of programming languages (PLT). Your lack of knowledge of this field does not mean that it does not exist.

Re: A Year of Functional Programming

#164

Post by pron »

nbouscal wrote: post #162
pron wrote: post #157

Earlier quoted context omitted.

> We look at the language features and think about how they can help us manage common situations in software development Maybe some people do, but when I pick a programming language, language features are among the last things on my mind. I look at the available tools (profilers etc.), available libraries (particularly in the domain that interests me), quality of documentation, the size of the community and its vibra…

If there were superb tooling, libraries, and documentation available for Brainfuck or INTERCAL, you would not find that sufficient reason to program in those languages. Of course, you will say, such a situation would never exist, because nobody is going to write libraries for INTERCAL. With this argument, though, you concede that language features are important. You just estimate them by proxy: languages with feature…

I think your cause and effect are reversed. I think that the biggest difference between "pragmatic" languages and research languages, is that pragmatic languages are driven by actual need, and with consideration for current practices and workflow. The language features are designed around that. Research languages, OTOH, are made to explore an idea, or conduct an experiment, usually made to answer the question "how would these language features affect development" (they could increase productivity, reduce bugs, improve performance etc). The result of the experiment are very valuable, and the successful, proven, ideas are then integrated into pragmatic languages. It is very rare that a research language achieves mainstream adoption. In fact, I would argue that if it does, it's failed as a research language because its widespread adoption probably means it wasn't adventurous enough.

Haskell is a prime example of a rather adventurous research language. It's an experiment that's been run for about 15 years now. First the early steps, and now people are experimenting with real world applicability. I'm really interested in the results, so I'd really like more people to run the experiment, but I have no doubt that Haskell itself will never gain widespread adoption. If it does its job well, its best ideas will be copied by other, non-research languages.

Now, I'm certainly not saying that Haskellers don't work on serious projects. But it is a fact that Haskell is much more common in academia than it is in the industry. Again, this is intentional. Haskell is meant to venture into unchartered territory and explore. Some of the things it aims to do work well and might be adopted in the industry, and others don't and won't. If Haskell teaches us even a few things, then it is a great success. What I don't like is that some Haskellers deny the true purpose of the language, and instead of examining it as researchers should do, they preach it.

Re: A Year of Functional Programming

#165

Post by coolsunglasses »

jimbokun wrote: post #127
coolsunglasses wrote: post #80

Earlier quoted context omitted.

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?

I've seen a lot of code that was larger than necessary because the author didn't know what a Monoid or Functor were.

Cf. "Visitor pattern"

I wasn't ignorant enough at the time I wrote the code to fuck up in the way you describe. I can only show an example of stuff I've made.

Here we go, three more uses of Monoidic functions (mempty, mappend)

https://github.com/bitemyapp/bloodhound/blob/master/Database...

It's not just about code, it's about conceptual memoization.

If you know what a Monoid is and you're learning how a data type like ByteString works, you can intuit how to "stitch" bytestrings together as well as how to get an "empty" ByteString.

It's about killing off unnecessarily ad-hoc APIs as much as anything.

Being able to realize when you're implementing a Functor/Monoid/Applicative/Monad is powerful because it lends you intuition on what the rules for a well-behaved API are and allow powerful, polymorphic code-reuse.

Consider the reusability of the functions here across the vast set of Monadic types out there: http://hackage.haskell.org/package/base-4.7.0.0/docs/Control...

This is worth pondering as well: https://github.com/jwiegley/simple-conduit

The code savings described are usually associated with not having to rewrite the polymorphic generic functions used in the Haskell ecosystem for the one-off a person made. The conceptual power from having a community that understands these patterns is more important.

You'll learn more and faster by learning Haskell.

https://github.com/bitemyapp/learnhaskell

Re: A Year of Functional Programming

#166

Post by brudgers »

soegaard wrote: post #161
brudgers wrote: post #160

Earlier quoted context omitted.

Thanks. It's not linked from the Racket Reference. Clicking on "mutable lists" in 4.10 is a 'did you mean recursion ?' experience. http://docs.racket-lang.org/reference/mpairs.html?q=mcons#%2... That it takes an intimacy with the code base of a regular repo contributor to find it suggests how deeply buried 'mlist is.Or to put it another way, Racket the language does not provide 'mlist. Racket the ecosystem does but d…

For us that were around when the default changed from mutable to immutable cons cells, known the rule "just prepend an m". I agree that the link in section 4.10 can be improved - but calling it "obfuscation" and "deliberate" is taken it too far. File a bug report, and I bet it will be fixed.

'mcons is part of 'racket/base. 'mlist is part of a library that contains two layers of warnings, is not linked to by the Racket Guide or Racket reference and lives under the 90th of 96 links on the Documentation page. It's lower in the great chain of being than "Unstable May Change without Warning".

(cons 1 (cons 2 (cons 3 '()))) is commonly required in the Racket family of languages for purely pedagogical purposes. That it is the only pattern for 'mcons provided by 'racket is a deliberate statement of community values in regard to mutable lists.

In regards to filing a bug report, the bug is that there is mention of mutable lists and a hyper-link in the documentation for the Racket Language. Because mutable lists are not part of the language the bug fix is properly removing the reference - at least in so far as maintaining consistency with the rest of the documentation because other libraries are not cross linked from the Guide and Reference. Linking "mutable lists" to 'compatibility/mlist, would just replace one bug with another...unless leaving 'mlist out of 'racket/base was itself a bug. That that is the case, is unlikely.

Re: A Year of Functional Programming

#167

Post by nbouscal »

pron wrote: post #164
nbouscal wrote: post #162

Earlier quoted context omitted.

If there were superb tooling, libraries, and documentation available for Brainfuck or INTERCAL, you would not find that sufficient reason to program in those languages. Of course, you will say, such a situation would never exist, because nobody is going to write libraries for INTERCAL. With this argument, though, you concede that language features are important. You just estimate them by proxy: languages with feature…

I think your cause and effect are reversed. I think that the biggest difference between "pragmatic" languages and research languages, is that pragmatic languages are driven by actual need, and with consideration for current practices and workflow. The language features are designed around that. Research languages, OTOH, are made to explore an idea, or conduct an experiment, usually made to answer the question "how wo…

You're starting with a fundamental assumption that there are two classes of languages, which you are calling pragmatic languages and research languages. I disagree. Researchers study languages of all sorts (there are plenty of research papers on Java), and practitioners use languages of all sorts (there are plenty of businesses using Haskell). Furthermore, many of the characteristics that make a language worth studying also make it worth using in practice.

Haskell has been around for nearly 25 years, not 15, and the ML family has been around for nearly 40. Strong type systems are not a research curiosity, and have not been for decades. They have significant and well-understood benefits, in practice.

I wish your hypothesis that the best ideas from research would be copied by other languages were true, but the history does not bear this out. A notable recent example is Swift: though it does make progress compared to its reference class, it still does not use any research more recent than roughly the 1970s. Clearly, the "pragmatic" languages are not keeping up. In what sense is it "pragmatic" to constrain yourself to decades-old technology?

The Haskell language is not constrained by some God-given purpose to be a research language for all time. Haskellers aren't "deny[ing] the true purpose of the language", they're choosing to use a useful tool, because doing so is pragmatic.

Re: A Year of Functional Programming

#168

Post by tel »

seanmcdirmid wrote: post #158
tel wrote: post #155

Earlier quoted context omitted.

Yep, exactly :) I don't find definitional wars interesting, and I'd, in the stream of everyday things, be very sympathetic to "OO and FP are different because they were built from different POVs". The only reason I am being a stickler is that I'm pretty interested in the idea that both FP and OO have a representation in type theory/category theory/logic and thus can be put into common representation. Haskell definite…

I would go farther and say Haskell is the only popular general purpose language that can get away without exposing programmers to object-like abstractions in the general case. Of course, these languages are general enough that you could probably shove whatever paradigm you wanted on top of them, but they do optimize for a particular kind of paradigm. A type theorist's definition of OO will be quite different from a g…

That's an interesting claim—that Haskell doesn't need object-like abstractions. I think it's really worth examining. I've said in the past the Haskell (and the ML-family) is possibly the only language which takes seriously initial data. That said, it still needs jerry-rigged abstract types to be efficient and I'm happy calling codata "object-like".

So really what I believe is that Haskell does a better job of being OO-FP than Scala does. I think there's still a happier medium between the two, though.

I'm also really eager to explore the type theorist's definition of OO in order to tease and bend the generalists definition. I'm not sure I completely agree about the idea of names that you outline, though. Existential types (and their dualized universal presentation) present unique types which could be named. State-transformer style (and the state-like monads) present a notion of identity-as-entity.

Again from the perspective of Haskell being a stab in the direction of a type theorists FP-OO language I find all of these features really interesting.

Re: A Year of Functional Programming

#169

Post by dllthomas »

seanmcdirmid wrote: post #104
tel wrote: post #96

Earlier quoted context omitted.

Haskell completely has something you can mistake as an object system! The entire typeclass machinery works that way less classes and inheritance. There's even a highly functional subtyping relation.

Type classes work strictly over values, with none of the naming machinery to give these values names and identities. Type classes only resemble classes in their unfortunate label; subtyping and polymorphism isn't really exclusive to OOP (with the exception of name-oriented nominal subtyping). The only way to create an object in Haskell is through giving it a GUID of some kind.

I feel like the nearest thing to OO in Haskell in common use is the records-of-closures pattern. Still doesn't have persistent identity, of course.

Re: A Year of Functional Programming

#170

Post by tel »

dllthomas wrote: post #169
seanmcdirmid wrote: post #104

Earlier quoted context omitted.

Type classes work strictly over values, with none of the naming machinery to give these values names and identities. Type classes only resemble classes in their unfortunate label; subtyping and polymorphism isn't really exclusive to OOP (with the exception of name-oriented nominal subtyping). The only way to create an object in Haskell is through giving it a GUID of some kind.

I feel like the nearest thing to OO in Haskell in common use is the records-of-closures pattern. Still doesn't have persistent identity, of course.

Records-of-closures is pretty much what I'm talking about. There is a notion of identity when those records are recursive, though the state management is still manual (as you'd expect).

    data Complex = { rotate :: Degrees -> Complex }

    -- thus
    -- rotate :: Complex -> Degrees -> Complex
where `rotate` is a state transformer and thus produces a notion of identity.
Post reply on HN