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

151–160 of 172 posts

Re: A Year of Functional Programming

#151

Post by dllthomas »

nightski wrote: post #150
brudgers wrote: post #131

Earlier quoted context omitted.

If language 'a' lets a person write a program with 'b' bugs in time 't', and language 'aa' lets the same person write the same program with 'b' bugs in time 't-n' then there is a clear net win for all 'n' > zero. If 'aa' also has the advantage of providing semantics for producing significantly less buggy code in time 't-n-m' at some future time then that is also an advantage but a distinctly different one and one whi…

It's greatly overstating the learning curve. It's possible to pick up Haskell by simply writing a few small applications tackling different parts of the language in each one. This can be done in a few months. Not to mention there are now numerous resources available for free such as learn you a haskell, real world haskell, and countless blog posts.

I hear the Wikibook also has a good introduction.

Re: A Year of Functional Programming

#152

Post by samth »

brudgers wrote: post #99
sp332 wrote: post #78

Earlier quoted context omitted.

You could look at Rust? It has mutable state but strict ownership which is enforced at compile time.

My irrational preferences fall along the lines of Lisp, and I think Scheme has the right syntactic approach to mutation: Put a '!' on the end so that it's explicit, but don't make it syntactically a mess like Racket does where mutable lists have to be 'mcons-ed up step by step rather than made in one pass (not that there's anything wrong with writing a macro, it just means that there's an additional layer of misdirec…

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

Re: A Year of Functional Programming

#153

Post by samth »

brudgers wrote: post #67

It's not that I don't think that programming in a functional style isn't a good idea , it's just that the discussions about functional programming and the languages people use to implement its style so often suggest: If you use language 'x', then using mutation is wrong. and recently, I've been thinking about the practically important but socially awkward question: What language is best for implementing mutable state…

This comment is very confusing. You spend a lot of time complaining about how Racket is overly focused on functional programming, leading to slower data structures. But the queue data structure you refer to is an imperative queue with O(1) operations for everything. Also, it isn't a priority queue.

The Rosetta code example for Priority Queues in Racket is also built on a mutable heap data structure. Of course, it has more complex time bounds, because of priorities, but not because of immutability.

Finally, the Rosetta code example for Queues in Racket uses `mcons` (which you claim is somehow taboo) explicitly.

Re: A Year of Functional Programming

#154

Post by seanmcdirmid »

tel wrote: post #148
seanmcdirmid wrote: post #146

Earlier quoted context omitted.

Typeclasses don't give you any specific to OO: they are abstractions over values and that's about it. You wouldn't be able to emulate an existing OO system in Haskell, and anyways, it wouldn't bring you closer to "talking about" and "thinking in terms of" objects. My point that OOP is essentially "thinking in terms of named objects" whereas most of what Haskell focuses on is "expressing math by composing anonymous va…

I disagree, but I think we'd have to go to definitions to make headway on this conversation, so I'll back out. As final thoughts: while type classes give abstraction over values, (a) those values encompass HKTs so they can also be effectual in various ways and (b) universally quantified bounded types are a basically final algebras and codata goes a long way toward modeling objects. Between those two I think you can g…

We then have to argue about what objects really are, and there isn't much consensus :) I don't think my design-oriented linguistic definition is very popular, but it contrasts nicely with pure functional programming; otherwise there is a lot of overlap and I don't think we can say anything very interesting about their differences.

Re: A Year of Functional Programming

#155

Post by tel »

seanmcdirmid wrote: post #154
tel wrote: post #148

Earlier quoted context omitted.

I disagree, but I think we'd have to go to definitions to make headway on this conversation, so I'll back out. As final thoughts: while type classes give abstraction over values, (a) those values encompass HKTs so they can also be effectual in various ways and (b) universally quantified bounded types are a basically final algebras and codata goes a long way toward modeling objects. Between those two I think you can g…

We then have to argue about what objects really are, and there isn't much consensus :) I don't think my design-oriented linguistic definition is very popular, but it contrasts nicely with pure functional programming; otherwise there is a lot of overlap and I don't think we can say anything very interesting about their differences.

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 definitely isn't the best OO language, but if you squint hard enough you can see OO in it much like you can see FP in C's function pointers: painfully. Seeing FP in C helps you examine the implementation challenges of FP. Seeing OO in Haskell helps you pick apart the different semantic pieces which build to form OO.

Re: A Year of Functional Programming

#156

Post by NAFV_P »

brudgers wrote: post #131
the_af wrote: post #119

Earlier quoted context omitted.

Yes, but suppose you could write the same program in two languages, a classic imperative one, and a purist and difficult FP language. For the sake of argument, let's assume the classic imperative language is easier to approach for rookies. If it's also the easiest language to write bugs and make mistakes with , wouldn't the "harder" FP language still be a net win? As long as its learning curve isn't unapproachably st…

If language 'a' lets a person write a program with 'b' bugs in time 't', and language 'aa' lets the same person write the same program with 'b' bugs in time 't-n' then there is a clear net win for all 'n' > zero. If 'aa' also has the advantage of providing semantics for producing significantly less buggy code in time 't-n-m' at some future time then that is also an advantage but a distinctly different one and one whi…

> The first step toward the modern automobile was the 'horseless carriage' not the Countach.

Lamborghini makes shit cars. The only reason people rave about them is because they have giant engines. A car without a reverse gear is one of the stupidest ideas in automobile history.

Re: A Year of Functional Programming

#157

Post by pron »

mightybyte wrote: post #141
pron wrote: post #132

Earlier quoted context omitted.

> 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…

> 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 vibrancy. I also look at similar projects done in the language. Only after all these do I look at the language features, but they don't matter so much, because I know I'll be very productive in a language with a very large selection of libraries and a large user community. I'm saying this after 20 years of developing software in languages like BASIC, Pascal, x86 asm, C, C++, Matlab, Java, Clojure, Scheme and more. I can't think of a single case where language features mattered more than any one of the things I listed.

All this is, of course, for serious projects intended for production. For a toy project I might look at the language features first.

Re: A Year of Functional Programming

#158

Post by seanmcdirmid »

tel wrote: post #155
seanmcdirmid wrote: post #154

Earlier quoted context omitted.

We then have to argue about what objects really are, and there isn't much consensus :) I don't think my design-oriented linguistic definition is very popular, but it contrasts nicely with pure functional programming; otherwise there is a lot of overlap and I don't think we can say anything very interesting about their differences.

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 generalist's. For type theory, various kinds of polymorphisms mostly overlap between paradigms (e.g. generics and structural subtyping are useful in OOP), but nominal typing is both commonly associated with OOP and relatively useless in FP languages to be a distinguishing feature. This also dovetails with my named-oriented definition of OOP: objects have identity, but their types have identity also. If you come at it from the FP perspective, identity for objects AND types aren't very desirable...there are no meaningful names in math!

Re: A Year of Functional Programming

#159

Post by brudgers »

NAFV_P wrote: post #156
brudgers wrote: post #131

Earlier quoted context omitted.

If language 'a' lets a person write a program with 'b' bugs in time 't', and language 'aa' lets the same person write the same program with 'b' bugs in time 't-n' then there is a clear net win for all 'n' > zero. If 'aa' also has the advantage of providing semantics for producing significantly less buggy code in time 't-n-m' at some future time then that is also an advantage but a distinctly different one and one whi…

> The first step toward the modern automobile was the 'horseless carriage' not the Countach. Lamborghini makes shit cars. The only reason people rave about them is because they have giant engines. A car without a reverse gear is one of the stupidest ideas in automobile history.

I used "Countach" for its word value. It's alliterative and has little rhyming potential and is loaded suggestively with images of suits with shoulder pads. An absurdity is not accidental.

Re: A Year of Functional Programming

#160

Post by brudgers »

samth wrote: post #152
brudgers wrote: post #99

Earlier quoted context omitted.

My irrational preferences fall along the lines of Lisp, and I think Scheme has the right syntactic approach to mutation: Put a '!' on the end so that it's explicit, but don't make it syntactically a mess like Racket does where mutable lists have to be 'mcons-ed up step by step rather than made in one pass (not that there's anything wrong with writing a macro, it just means that there's an additional layer of misdirec…

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 deliberately makes it hard to use (by obfuscation) on the moral ground that mutating a list ought incur the pain of iterative 'mcons-ing...and it's associated pretty-print. .

Post reply on HN