Live data from Hacker News

Functional Programming Is Hard, That's Why It's Good

dave.fayr.am

51–60 of 112 posts

Re: Functional Programming Is Hard, That's Why It's Good

#51
post #44

I love Erlang so much I haven't yet gotten around to learning another functional language. (still growing with erlang). I learned it reading Armstrong's book from Pragmatic Programmers. It was a joy. I'm also reading the OReilly book, and it seems good as well, though I can't tell how it would be if I didn't know the language already. As for the titles-- one is Programming Erlang, and the other is Erlang Programming!

I think you should learn Brainf*ck. It has awesome mental/intellectual benefits to you as a Erlang lover. No, but really.... ! And if you don't you will suffer! Muahaha!

Erlang is easy to read and makes a lot of sense, without requiring much brainpower... if you'll take a few days and read about it.

I think its kinda silly that people will just ignore a language because it doesn't look like java/C/pascal. Its not like the syntax of erlang is stupid, or pointlessly obtuse.

Re: Functional Programming Is Hard, That's Why It's Good

#52
post #40

Earlier quoted context omitted.

Just for record. Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later). Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-c…

All sorts of interesting stuff and then... ... OOP is inherently less useful that FP ... Is it that hard to see different uses for different languages? Original BASIC was neither OO nor FP and came after both. Still it satisfied a particular need. C++ is the worse programming language in the world, except for all the others - in the domain it is used in.

>Is it that hard to see different uses for different languages?

Okey. How about language that could encompass all of them? The thing about such language is that it have to be functional one, at the core. Be it Lisp, or Haskell, or Agda2.

Let's look at Haskell. It has OO: http://homepages.cwi.nl/~ralf/OOHaskell/ Everything in mainstream OOP languages and then some, all in Haskell type system. It has BASIC: http://hackage.haskell.org/package/BASIC

I embedded to Haskell a MIPS assembler, a language to describe CPU cores, and some other things.

I am not an expert in Lisp, but an avid reader of HN should know that it pretty good in encompassing languages.

As for C++, it's domain shrinks every year.

Re: Functional Programming Is Hard, That's Why It's Good

#53
post #6

FP is becoming the new OOP. People who don't understand its original meaning are misinterpreting it and incorrectly expounding its usefulness. Newcomers are not grasping how it fits into the bigger picture. Be cautious.

You know, I've learned something today! When some people talk about functional programming, they talk about monads and iterating with recursion and lambda calculus. Other people talking about functional programming mean using data-oriented abstractions, where functions operate on data in well-defined ways, to avoid state and interlocked dependencies[3]. I've been calling the latter a "functional style", but clearly t…

functional in the small and OO in the large" seems a good path.

That's what I like about Erlang as well. Once you recognize processes as your objects, this philosophy just flows out of the language.

Re: Functional Programming Is Hard, That's Why It's Good

#54
post #50
post #40

Earlier quoted context omitted.

Just for record. Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later). Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-c…

Unfortunately, I don't think type theory has a whole lot to do with programming or software engineering. The most practical languages (as measured by popularity, which seems to be the best way to do it over a period of decades) do not have sound type systems, nor even particularly interesting ones theoretically.

You should reconsider your stance.

Types allow requirements changes to be propagated through all program. State-of-the-art type systems even allow accounting of effects, like prevent deadlocks by ensuring a specific order of locking: http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf

This is just another tool in a toolbox. You can use it. Or you can throw it away as "no one seem to use it".

Re: Functional Programming Is Hard, That's Why It's Good

#55
post #51

Earlier quoted context omitted.

I think you should learn Brainf*ck. It has awesome mental/intellectual benefits to you as a Erlang lover. No, but really.... ! And if you don't you will suffer! Muahaha!

Erlang is easy to read and makes a lot of sense, without requiring much brainpower... if you'll take a few days and read about it. I think its kinda silly that people will just ignore a language because it doesn't look like java/C/pascal. Its not like the syntax of erlang is stupid, or pointlessly obtuse.

IMO, the only really ugly part of Erlang is it's record syntax, but it's binary handling more than makes up for it!

Doing Erlang at the day job for the last few months has been awesome. I really wish it would catch on more. Maybe when the JVM supports tail-call optimization and there is a JVM implementation of the runtime...

Re: Functional Programming Is Hard, That's Why It's Good

#56
post #50
post #40

Earlier quoted context omitted.

Just for record. Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later). Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-c…

Unfortunately, I don't think type theory has a whole lot to do with programming or software engineering. The most practical languages (as measured by popularity, which seems to be the best way to do it over a period of decades) do not have sound type systems, nor even particularly interesting ones theoretically.

"I don't think type theory has a whole lot to do with programming or software engineering. The most practical languages ... do not have sound type systems"

well i mean most software isn't understood, using Linus's metaphor, most software works due to "years and years of testing on thousands of machines", not due to "thinking and analyzing"[1]. and, i think, teams that are capable of "think and analyse" can out-compete teams that don't.[2]

[1] http://www.dustingetz.com/linus-think-and-analyze-motherfuck... [2] http://www.dustingetz.com/re-seth-godin-how-do-you-know-when...

Re: Functional Programming Is Hard, That's Why It's Good

#57
I'd really love to hear PG defend this line: "But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too."

I'd really love to see the code for something that one would do in a day or two in Lisp, but would be much longer in another language. I don't suspect there exists a wide class of such things -- I suspect the features tend to look like embedding Lisp compilers.

Re: Functional Programming Is Hard, That's Why It's Good

#58
post #52

Earlier quoted context omitted.

All sorts of interesting stuff and then... ... OOP is inherently less useful that FP ... Is it that hard to see different uses for different languages? Original BASIC was neither OO nor FP and came after both. Still it satisfied a particular need. C++ is the worse programming language in the world, except for all the others - in the domain it is used in.

>Is it that hard to see different uses for different languages? Okey. How about language that could encompass all of them? The thing about such language is that it have to be functional one, at the core. Be it Lisp, or Haskell, or Agda2. Let's look at Haskell. It has OO: http://homepages.cwi.nl/~ralf/OOHaskell/ Everything in mainstream OOP languages and then some, all in Haskell type system. It has BASIC: http://hack…

Uh certainly, FP language are certainly the most powerful and flexible languages, aside from maybe logic languages, far beyond OO. FP language definitely encompass more, you are correct there.

I just think it's important to not to confuse power and flexible with usefulness. Rigidity and limits have their uses.

As far as c++ goes, it's market share shrinks every year yet since the market grows and c++'s share began huge, c++ gains more users and more market position every years than the total users of functional programming languages. That may change in the future. FP will have to show its usefulness and not only its power and flexibility for this to happen.

Re: Functional Programming Is Hard, That's Why It's Good

#59
post #5

This is the lie that every functional programmer has perpetuated for the last 50 years since the dawn of Lisp - that somehow, automagically, productivity or effectiveness of programmers increase with the use of functional languages. It's the biggest lie in the programming world, and it was designed to make the uber-geeks of this world, those people that you walk around the block just to avoid saying hello to because…

You're making the same mistake that the Java loyalists did when Rails came out: judging something based on your distaste for the advocacy around it without any real understanding. I'm not going to pretend to know your motivations here, but often times people throw up this defense mechanism to protect their own professional knowledge; but here's the thing, that does nothing but stunt your own growth. Functional progra…

In practice functional programming is not the fastest way to solve many problems, but it is an excellent way to push forward the state of computer science as a whole.

I don't think the state of computer science is really held back much by the current state of programming ability. SW Engineering is maybe held back by it, but many of the best computer scientists I know don't program at all and would think discussing Lisp vs Java would be like asking a mathematician if he preferred to use an ink or gel pen.

Re: Functional Programming Is Hard, That's Why It's Good

#60

I'd really love to hear PG defend this line: "But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too." I'd really love to see the code for something that one would do in a day or two in Lisp, but wou…

i speculate the edge compounds as, say, a competitors java codebase's complexity increases faster than a lisp codebase. exponentiate this over time and the edge is obvious.
Post reply on HN