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

131–140 of 172 posts

Re: A Year of Functional Programming

#131

Post by brudgers »

the_af wrote: post #119
trobertson wrote: post #117

Earlier quoted context omitted.

Only after the learning curve, though. It isn't immediately approachable as an imperative language.

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 which can be deferred [and probably will be given a significant learning curve].

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

Re: A Year of Functional Programming

#132

Post by pron »

mightybyte wrote: post #116
pron wrote: post #63

Earlier quoted context omitted.

> With Haskell their reuse was an order of magnitude higher as measured by the number of external library dependencies! If we're talking real world -- as we should -- then this should be contrasted with the tradeoffs and alternatives. The most important kind of code reuse, IMO, actually happens at a larger scale, and in the past few years has worked remarkably well, since the advent of open-source. I'm talking about…

> 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 for different kinds of software and different kinds of developers. And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language.

Re: A Year of Functional Programming

#133

Post by [deleted] »

cageface wrote: post #28
pron wrote: post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haskell, are yet to be demonstrated in the real world. I've been reading religious advocacy of FP for almost 15 years now and yet there still don't seem to be many non-trivial apps written in any of these languages. Certainly many individual features of FP have bee…

[deleted]

Re: A Year of Functional Programming

#134

Post by JackMorgan »

cageface wrote: post #28
pron wrote: post #7

I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…

The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haskell, are yet to be demonstrated in the real world. I've been reading religious advocacy of FP for almost 15 years now and yet there still don't seem to be many non-trivial apps written in any of these languages. Certainly many individual features of FP have bee…

What have you contributed? Or are you just waiting for _someone else_ to put in the effort to prove it for you first? Multiply that by every developer in every company, and you start to see why it's not that common.

I am currently trying to write something in F#, which is still OO, only the rest of my team won't let me because there is "no proof it's better". Well, no. And there won't be if everyone says that. And where is the proof C# was better than VB.NET? Oh, right, the proof is VB.NET doesn't look like Java! Curly braces, the only evidence we need!

As long as the majority can hold back the minority that WILL learn something new just to see if it's better, everyone stays with the status quo.

"Just don't make me learn anything new" <- the developer motto.

Re: A Year of Functional Programming

#135

Post by steveklabnik »

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…

> One of the big things though that I look for is an over-abundance of documentation and resources.

..... stay tuned.

Re: A Year of Functional Programming

#136

Post by tel »

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'm not claiming typeclasses are classes, but more like modules and that modules achieve at least some of OO. Entity-like identity is a notably more difficult thing to pull off, but still is easily embedded in IO or ST.

I'm not saying it's a complete OO implementation, but instead that it's not so far as to be completely unconfusable, though it might be hard to, say, do Smalltalk-in-Haskell.

Re: A Year of Functional Programming

#137

Post by dllthomas »

kasey_junk wrote: post #103
seanmcdirmid wrote: post #62

Earlier quoted context omitted.

There are plenty of side effect free ways of dealing with change...you can make the effects you know...explicit. Anyways, for a game like SMB, FRP should work relatively well. Just be careful with collections.

But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects. Of course there are ways of abstracting those side effects and acting like they are the same as pure functions. Or conversely instead of hiding them, you could point them out and make them "exceptional", which is what I assume you mean by making them explicit. These mach…

"But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects."

No, those are precisely effects. They can only be side effects once you've defined how you're distinguishing side effects from effects generally.

A common way is labeling intended results "effects" and unintended results "side effects". By this definition, they're clearly effects not side effects, though this equally clearly isn't the usage in question.

Another way - common in Haskell - is to label effects that do not appear in a function's type signature "side effects". By this definition, it clearly depends on the implementation and there are "side effect free ways of changing pixels on the screen".

I don't think there is another useful definition to be had.

Re: A Year of Functional Programming

#138

Post by seanmcdirmid »

dllthomas wrote: post #137
kasey_junk wrote: post #103

Earlier quoted context omitted.

But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects. Of course there are ways of abstracting those side effects and acting like they are the same as pure functions. Or conversely instead of hiding them, you could point them out and make them "exceptional", which is what I assume you mean by making them explicit. These mach…

"But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects." No, those are precisely effects . They can only be side effects once you've defined how you're distinguishing side effects from effects generally. A common way is labeling intended results "effects" and unintended results "side effects". By this definition, they're cle…

In FRP, you basically define your UI as a function to display pixels. Physics is a bit weirder, but that is handled by event streams over ticks and "stepping." Actually, the effect system doesn't really come into play, because you can define everything effect free.

I'm not a big FRP proponent though. In my own work [1], I believe that manipulating pixels and doing physics should be effects...even side effects that are at least explicit during run-time. Of course, to achieve this, I needed to do special things to achieve commutativity and idempotence, which is otherwise taken for granted in a pure functional program.

[1] http://research.microsoft.com/pubs/211297/managedtime.pdf

Re: A Year of Functional Programming

#139

Post by JackMorgan »

tieTYT wrote: post #129
mark_l_watson wrote: post #40

Nice article! I have been using Clojure for years, initially because a repetitive customer mandated its use, later for my own projects because it reduced my development time and is fun to code in. I tried Scala (really liked Martin Odersky's Coursera class!) but it did not stick. That said, Haskell has started to win my mind share. At least for my own projects I have been mostly using Haskell this year, with some bit…

I'm pretty ignorant of both languages (but I have novice experience in both): Moving to Haskell, don't you miss Lisp macros? How do you deal with that?

For the basic "I want a better conditional abstraction", no, I don't miss it. Lazy-by-default Haskell makes that sort of tool even easier to make.

I've also been realizing that a lot of things I would use a macro for in Lisp I can get with monads. Not everything, but so far, I haven't really missed macros much at all. They are both powerful tools for abstraction. I'm starting to think monads are a bit less powerful, but much simpler to get right and maintain long term.

Re: A Year of Functional Programming

#140

Post by JackMorgan »

morkbot wrote: post #51
mark_l_watson wrote: post #40

Nice article! I have been using Clojure for years, initially because a repetitive customer mandated its use, later for my own projects because it reduced my development time and is fun to code in. I tried Scala (really liked Martin Odersky's Coursera class!) but it did not stick. That said, Haskell has started to win my mind share. At least for my own projects I have been mostly using Haskell this year, with some bit…

That's a bit of an off-topic but may I ask, why Haskell over Clojure. What are the differences? You partly asked that in the 2nd part, but I would like to know more. I never did any serious FP so would love to know where to start: Scala? Clojure(Script)? Haskell? F#?

I'd start with Haskell or Scheme. They are a lot easier to get started and learn than anything JVM. For Haskell, this course is awesome: http://www.seas.upenn.edu/~cis194/lectures.html

For Scheme, just do the first two chapters of SICP. In fact, do that anyway!

Post reply on HN