Functional programming beyond Haskell

We have all learned functional programming in Haskell, but there are more functional languages like Lisp, Scheme, ML, and Clean.

Why should we even bother to look further than Haskell?

- You want your programs to run faster.
- Monads drive you mad (what are they anyway? warm fuzzy things?).
- You need objects.
- You sometimes need a more powerful module system.

http://www.cs.uu.nl/wiki/pub/Stc/BeyondFunctionalProgrammingInHaskell:AnIntroductionToOCaml/ocaml.pdf

Slides are retarded

lets see what want:
- You want your programs to run faster. C++
- Monads drive you mad (what are they anyway? warm fuzzy things?). C++
- You need objects. C++
- You sometimes need a more powerful module system. C++ classes

>>3
Blub.

>>4
Blub-fighter-diary:

Day1:Blub programmers don't see the benefit of writing less code, they're just code monkeys paid by the line. Who cares if all the programs you runs are made in Blub, thats just a conspiracy by Blub architects. They purposefully made Blub so efficient and fast so everyone chooses blub.
Day2:I wish that Blub would disappear, its so inelegant and obtuse compared to my language. It doesn't even have autism-express-stack-apply-in-reverse, because this is impossible to implement in there.
Of course i use autism-express-stack-apply-in-reverse everyday, thats my favorite function.
Day3:What do you mean "wrote any useful program"? i'm computer scientist not a code monkey.,I develop the tools and algorithms, so I essentially contribute more.
Day4:I submitted a proposal to add autism-express-stack-apply-in-reverse into Blub with minimal modifications to the Blub core , but they didn't like it. Its so kawaii and they didn't like it, monsters. How the world can be so cruel? I hope it garbage collects itself.

>>5
Blub isn't about the language, it's about the user. But I can see how a Blubber would miss the distinction.

>>6

Blub isn't about the language

you totally missed the point....

>>7
Sorry, you'll have to spell it out.

The solution to BlubParadox is simple:
writing lots of simple code only tires you physically, your mind is at rest and you're in some trance state which is enjoyable.
writing smarter,more abstract code tires the mind and stops any trance/flow but minimizes effort to code.
probably a middle ground is to write a code that doesn't force you to think of very complex ideas, and is compact enough to not tire you physically. Object-oriented design with information hiding allows to operate on black box interfaces, which can be arbitrary complex structures.
So essentially OO-Blub is both simple to think of(intuitive interface) and fast to write(using a black box).
What "non-Blub superior languages" fail at is that they provide very rich, possibly arcane tools and expect the programmers(the average programmer is not a genius) to think hard how to use a tool. To add to injury syntax which needs more mental effort slows down the programmer. The code becomes mentally hard to write and interpret, the advantage of it being compact is viewed as a black box interface.
Except not a Blub black box, an unconventional hard-to-modify piece of code without a OO interface to large piece of simple code. Blub wins adherent by being simple to learn, modify and create abstractions. It doesn't have anything really "hard" and "complex" but that works to Blub advantage: it makes far easier to parse, compile and modify Blub than the "superior language".
Some things can't be expressed in Blub they say. When someone actually expresses the things, they're inelegant. When made elegant they're called unsafe and ugly on the inside. Blub rarely needs to express the things, it doesn't need to emulate lambda-calculus to solve problems of its domain. The things hard to express in Blub are with rare exception heavily abstract representations of academic ideas. Blub is not fundamentally crippled because it lacks these things: when Blub will need it it can linked from a module or library outside Blub.

>>9
This post gave me Java

>>1

Lisp

Unityped mess.

Scheme

A type of Lisp, see above.

Thus, there aren't even any alternatives to Haskell. Idris is perhaps the only hope right now. But you know you need to check'em.

ML

Ancient, half-assed shit. Not even purely functional.

Clean

Dead and abandoned.

>>11

ML
Meta-Language

Haskell was made for the purpose of having a functional language.
ML was made with an actual purpose.

IHBT

>>12
"Meta" is just a fancy buzzword. ML isn't any more of a metalanguage than Haskell or Clojure. Is being named after a buzzword a real purpose? I think not.

Haskell was made for the purpose of research, by the way. And ML? It serves no purpose at all, except perhaps its Camel and F# incarnations, but those are just "inturdprice OOP but with them first-class functions shit so you can brag about being a functional porgrammer" languages.

"Meta" is just a fancy buzzword.

And so are ``anus'' and ``hax'' by your reasoning.

Haskell was made for the purpose of research, by the way.

Right. ML's original purpose was to implement other languages (i.e. metaprogramming). It is practical. ``Research'' as a purpose is about as vague as you can get; my point still stands.

OOP but with them first-class functions

``Look, ma! I'm spewing baseless opinions on something I know nothing about again!'' --u

If you cannot argue without misquoting, you cannot argue at all.

>>15
OK. I'll just take that as you graciously bowing out.
Try again next time!

>>14
Yes, they are.
Computer PL research is a definite enough purpose. The number of GHC extensions and things you can do in Haskell that you can't in 99% of languages confirms that Haskell is successful.
ML? Metaprogramming? Seriously? It's even worse than Lisp.

You are an idiot and all your points are false.

>>17

Computer PL research
Haskell was made for the purpose of having a functional language.

Yep. Haskell's purpose is for PL researchers to play around with what they can do in Haskell. Ergo, Haskell's purpose is itself.

things you can do in Haskell

You can do many things in Javascript that you can't in most other languages. That makes it successful, yes, but the people who are doing that kind of thing are making dorodango.

Metaprogramming

Yes. ML is a fantastic family of languages to write compilers in. Metaprogramming is about programming programs; that does not necessitate targeting the host language.

You are an idiot and all your points are false.

Thank you for validating all that I live for. I'm sure your PhD thesis contains this very sentence.

>>18
You are an obvious idiot. I will not even waste time explaining you why you are wrong.

>>19
OK. I'll just take that as you graciously bowing out.
Try again next time!

check'em

>>21
You're like that sperm cell that was just one sperm cell late to the egg and ended up not creating you.

>>13
Buzzword this and buzzword that. Does buzzword mean to you, "I don't like people creating new words to describe things"?

>>23
>le pedophile sage

u͔n͈̰̎i̙̮͚̦c͚̉o̼̩̰͗d͔̆̓ͥé

>>19
Thanks for confirming that all lisp-haters are from /g/ and rednigger. I never saw you huskel niggers before 2013.

>>24
Sage doesn't exist here, shit for brains

>>17
The number of GHC extensions and things you can do in Haskell that you can't in 99% of languages confirms that Haskell is successful.

Prelude> let f x = x x

<interactive>:2:13:
Occurs check: cannot construct the infinite type: t1 = t1 -> t0
In the first argument of `x', namely `x'
In the expression: x x
In an equation for `f': f x = x x

>>28
Yes, this kind of type safety is a necessary condition for Haskell's success, but it's not really a fancy thing. Other languages can forbid type-unsafe programs as well. So what's your point?

>>29
Just because Haskell can't do it doesn't mean it's unsound.

>>30
Can't do what? Apply x to x? I've never ever needed to do that.

>>31
There is no end to the list of sound things you've never needed to do.

>>32
Is there a list of things x x is good for?

>>31
"need" is the worst argument, maybe you're just too ignorant to notice the need?

>>33
That's not the point. See >>29:

Yes, [b]this kind of type safety[b] is a necessary condition for Haskell's success

is bullshit. There's nothing inherently unsafe about infinite types.

But if you really want to know what x x is good for, it comes up a lot in lambda calculus. In fact, application of the X combinator to itself is good for everything, being a basis of combinatory logic: https://en.wikipedia.org/wiki/Combinatory_logic#One-point_basis

>>35

There's nothing inherently unsafe about infinite types.

Except that they're infinite, thus unable to be tested for equivalence. Have you read your TAPL today?

>>35

it comes up a lot in lambda calculus

Lambda calculus is not an example of practically valuable application. Try writing a hello world in it.

In fact, application of the X combinator to itself is good for everything

And unary encoding (Peano numbers) is good for everything too, but nobody uses unary (except some proof assistant academics).

>>36
That's not a safety issue. There are a lot of things in Haskell that are incomparable.

>>37
Haskell Curry used it. Without combinatory logic the Haskell type system doesn't even work. Combinators are used all the time in Haskell, MLs, Lisp and even shit like Javascript.

A form of Peano numbers are used in miniKanren and probably core.logic.

>>38
It's a safety issue because it's a type-safety issue. How are you going to ensure type-safety if you've got some uncomparable infinite types floating around?

>>38
What the fuck does combinatory logic have to do with x x? Are there any actual practical examples of where it is useful, or not? Lisp apply is practical but not compelling. Anything else?