/fpt/ - Functional Programming Thread

Next-level programming thread.
The purest code is never written.

Last one: Resources:
>Elixir
chimera.labs.oreilly.com/books/1234000001642/index.html
>Elm
guide.elm-lang.org/
>Erlang
learnyousomeerlang.com/content
>F#
fsharp.org/learn
>Haskell
en.wikibooks.org/wiki/Haskell
>Lisps
>>Common Lisp
gigamonkeys.com/book
Common Lisp Recipes
Land of Lisp
>>Clojure
braveclojure.com/foreword/
>>Scheme
SICP
Little Schemer

Feel free to add more.

Other urls found in this thread:

rosettacode.org/wiki/FizzBuzz#J
papl.cs.brown.edu/)
ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/
alecb.me/blog/stack-language-ocaml
realworldocaml.org/
artima.com/weblogs/viewpost.jsp?thread=147358
medium.com/@jlouis666/on-functional-programming-df28cc9078de#.9d52x610l
ghc.haskell.org/trac/ghc/blog/ghc-8.0.1-released
twitter.com/SFWRedditImages

I dunno why, but it pretty much reminds Prolog code:

fizzbuzz(fizzbuzz, X) :- 0 is mod(X, 15), !.
fizzbuzz(fizz, X) :- 0 is mod(X, 3), !.
fizzbuzz(buzz, X) :- 0 is mod(X, 5), !.
fizzbuzz(X, X).

print_fb(1) :-
fizzbuzz(Fizzbuzz, 1),
write(Fizzbuzz), nl, !.

print_fb(X) :-
Y is X - 1,
print_fb(Y),
fizzbuzz(Fizzbuzz, X),
write(Fizzbuzz), nl, !.

goal :- print_fb(100), halt.


I don't know, why, maybe it must have something with declarative nature of those languages.

Friendly reminder that you can practice principles of functional programming in any language and pure stateless programming is a meme.

can somebody do fizzbuzz in apl

>no ocaml
Just fuck off faggot

Purity is not a meme but stateless is (mostly). The fact is you can write a stateless, pure function and call it in a stateful (also pure) way in a non-shit language.

>Friendly reminder that you can practice principles of functional programming in any language
Sure, but some languages lend themselves to FP much more than others. I wouldn't want to hack together a pure, functional program in C because that would be a waste of time.

This is called return value optimization, to maybe ring some bells.

Provide some good resources for OCaml, you are welcome.

>common lisp
>functional
yeah if your language can only construct functional manners through hacks, then it's not functional

You know, there are tools for specific tasks.
Like you use hammer to nail, but not microscopes, you use functional languages to program FP-way efficiently.
Yes, there are FP tools in non-FP languages, but they are complementary to those languages, but not the principles those languages are built upon.

who /readingsicp/ here

I'll be adding those:

>The Seasoned Schemer (intermediate)
>The Scheme Programming Language by Kent Dybvig (intro)
>Realm of Racket (intro)

No, it's a meme book that's worthless, won't teach you anything good that can be applied to the real world and you could be reading something that will actually have applications.

Read a practical book on your language of choice.
Read a book on systems engineering.
Read a book on project management.
Read a book on the topic that you're interested in.
Hell go to sad panda and jack off.

There is literally no reason to read structure and interpretation of computer memes

Abelson and Sussman had given up on reading SICP 20 years ago, actually.
We're doomed.

I have to agree that, while the first few posts in this thread were shameless trolling, I've seen more interesting Haskell posted than weeks of /dpt/s.

Here's what Rosetta Code has on APL Fizzbuzz:
⎕IO←0
(L,'Fizz' 'Buzz' 'FizzBuzz')[¯1+(L×W=0)+W←(100×~0=W)+W←⊃+/1 2×0=3 5|⊂L←1+⍳100]

Hell, it seems I have not enough characters for this language.

Exactly.
The book is not bad but it's not useful. It's like reading a very hard puzzle book.

The problem with the book is its length, there are so many good books one could be reading instead like
>gang of four
>code complete
>concrete mathematics
>mythical man month
>rapid development
And so on. Never mind books on specific languages or topics one is interested on.

All those books will give you something real that SICP will not.

The modern equivalent to APL is called J:
rosettacode.org/wiki/FizzBuzz#J

Could you spoonfeed me on J and APL? I can't even think why these languages were created in the first place.

APL was one of the first languages ever made (and stands for literally “a programming language”), next to stuff like FORTRAN. It was a time when computers weren't widespread at all, but the thing of universities and used highly specialized hardware and single-purpose software (this predades operating systems).

APL machines in particular had special keyboards designed solely for them. The goal was to make mathematical computation easier. It was designed for mathematicians.

APL was designed for interactive mathematical queries, and suported mathematical constructs such as matrices and vectors natively. Many of the symbols come straight from mathematics.

Basically, an APL expression like m ← +/(3+⍳4) is the notational equivalent of pic related. It's not really designed for “general purpose” programming, and it's certainly not designed around any modern concepts of what we expect programming languages to be.

J is basically a fork of APL that replaces the difficult-to-input characters by sequences of ASCII characters. It has no real value except novelty / education / fun.

APL was the 70s' and early 80s' MATLAB. It had some graphing capabilities and was good for analyzing data.

I'm working through SICP right now, but I don't think that image is entirely accurate. For one, I am using the HTML version on MIT's website. I prefer that to print. Second, the video lectures are with HP employess, not MIT students. Third, the material is difficult. It is doable, but difficult.

>No, it's a meme book that's worthless,

And specifically the reason it's worthless is because of its truly bizarre order of presenting topics -- an ordering that's totally out of touch with what's going on in actual computer science classrooms.

For example, it starts right out in chapter 1 by jumping into recursion and recursive tree algorithms. A vast majority of computer science faculty know that you can't just walk into an introductory programming class and on the first week show the students how Ackermann's function works, and how to recursively calculate the nth Fibonacci number in log n time using a clever tree-walking approach. For this reason, the book is pretty much totally ignored by a vast majority of computer science departments.

Here's an example footnote from chapter 1, that shows you just how utterly ignorant they are about the concept of communicating effectively to a student in an introductory programming course:

"31 Tail recursion has long been known as a compiler optimization trick. A coherent semantic basis for tail recursion was provided by Carl Hewitt (1977), who explained it in terms of the ``message-passing'' model of computation that we shall discuss in chapter 3. Inspired by this, Gerald Jay Sussman and Guy Lewis Steele Jr. (see Steele 1975) constructed a tail-recursive interpreter for Scheme. Steele later showed how tail recursion is a consequence of the natural way to compile procedure calls (Steele 1977). "

I'd agree with all the "SICP = meme" posts. How to Design Programs is a much better book to learn programming from scratch, and only after that would I suggest moving onto SICP.

I've heard good things about Programming and Programming Languages (papl.cs.brown.edu/) too but not got around to reading it. It uses a weird language though but the author argues that it was designed and created purely for educational purposes. To me, that sounds like a dumb idea and students but should be taught a real language, but what the fuck do I know?

SICP is not intended for total beginners. It was a textbook for university freshmen. The students in the course would likely already have taken a calculus class (hence the calculus exercises in the book), and even some kind of programming or computer science class. We did similar recursive exercises in high school.

Students in video course are HP workers.

Yup. Mentioned that above.

ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/

(defun fizzbuzz (n &aux (f (mod n 5))
(g (mod n 3)))
(cond ((= f g 0) 'fizzbuzz)
((= g 0) 'fizz)
((= f 0) 'buzz)
(t n)))

yeah those are the most disgusting pieces of shit haskell examples I've ever seen

nearly made me vomit

fizzbuzz n = mapM (\i -> putStrLn $ fromMaybe (show i) (("Fizz"

absolutely disgusting. break that shit up and reorganize it, then we'll talk

main = mapM putStrLn $ fizzbuzz 100

fizzbuzz n = map f [1..n] where
f i = fromMaybe (show i) $ (g "Fizz" 3 i) (g "Buzz" 5 i)
g s n i = s

Just realized there are redundant parens.
main = mapM putStrLn $ fizzbuzz 100

fizzbuzz n = map f [1..n] where
f i = fromMaybe (show i) $ g "Fizz" 3 i g "Buzz" 5 i
g s n i = s

Haskell is CUTE and PURE!

>People are stupid and don't like to put effort into things.

What ever happened to learning about a topic you're curious about *before* going to university to study it further?

Why is it the norm that people expect to just waltz into a university with absolutely no prior knowledge on a subject and expect to be spoonfed?

> SICP is not intended for total beginners.

This is true. But that does not change the fact that the ordering of the material in SICP is totally out of sync with the broad consensus about the most effective ordering for teaching it. It's no coincidence that most universities' computer science curricula have their topics arranged in roughly the same order. That ordering was developed by a broad consensus of computer science educators over a period of decades.

>What ever happened to learning about a topic you're curious about *before* going to university to study it further?

What ever happened to teachers trying to figure out how to best communicate technical material to students in a clear, straightforward manner that's carefully designed to make the material as easy for the students to learn as is feasible possible?

There is no fucking reason why any textbook needs to EVER be perceived as hard or challenging. If the author truly cares about explaining the material clearly, and has the communication skills to do so, any subject can be explained in a way that most of the students find easy and straightforward to learn. Unfortunately, not nearly enough authors care to develop that skill, and SICP is one of the most atrocious examples of that.

There are reasons why SICP has been rejected by a vast majority of universities for their computer science program. It's good to learn those reasons -- because that helps you understand how to write better textbooks.

I'm trying to write my first Monad in haskell, but having trouble writing the >>= function. The monad computes basic boolean algebra. The idea is that a Token manipulates a stack [Bool] and passes the stack, and if the stack doesn't contain enough bools, it returns Invalid_t. I think my syntax is off but I can't get it to load into ghci.

data Token = True_t | False_t | Not_t | ... | Invalid_t

instance Monad Token where
Token stack >>= f = case t of
True_t -> f (True:stack)
False_t -> f (False:stack)
....
Invalid_t -> ???


Is this a good way of doing this? Should I be using Maybe instead?

>There is no fucking reason why any textbook needs to EVER be perceived as hard or challenging.
Textbooks are only perceived as hard or challenging if you lack the prerequisites for understanding said textbook

Human time is finite, including that of the authors. If you can spend 70% of your time on novel content and 30% on refreshers and introductory fluff, you'll have more content than if you spend 70% of your time in introductory fluff and only 30% on novel content.

This is why you don't see books on category theory start by explaining to you the concept of addition and subtraction using pictographic examples. If they had to build up a lifetime of mathematical understanding first, how much category theory would they get done?

Btw, I'm not defending SICP; I'm just calling your argument terrible. “it's bad because it assumes prior knowledge” is nonsensical because you're always assuming prior knowledge. Heck, I'm assuming prior knowledge of the english language, why shouldn't I assume prior knowledge of what a fucking tail call is

You shouldn't be trying a free monad as your first monad. Free monads are pretty advanced and are engineered from the ground up to be monads so they can crib the syntax.

For one, Token has no type parameter so it cannot be a monad.

Kind error. ‘Token’ has kind * but ‘Monad’ requires something of kind * -> *

What if I did something like this?

data Token = true_t | false_t | ... | invalid_t
true_t, false_t, ..., invalid_t :: [Bool] -> Maybe [Bool]
true_t stack = Just (True:stack)
false_t stack = Just (False:stack)
...
invalid_t _ = Nothing


Would that be easier?

Yes, and now you can combine them using fmap.

Thanks bud

Though you wouldn't have that Token definition anymore. You would have type Token = [Bool] -> Maybe [Bool].

With RebindableSyntax you could do:
newtype Token = Token { runToken :: [Bool] -> Maybe [Bool] }

true_t :: Token
true_t = Token $ \stack -> Just (true : stack)
-- etc.

(>>) :: Token -> Token -> Token
t >> u = Token $ runToken u . runToken t

foo :: Token
foo = do
true_t
false_t
and_t

please stop rebinding (>>)

Does this look alright? I haven't got the hang of any fancy syntax just yet.

type Token = [Bool] -> Maybe [Bool]
true_t st = Just (True:st) :: Token
false_t st = Just (False:st) :: Token
... etc

Oh hold on, It doesn't like the Token type declaration at the end.

Btw, I'm very sure there was a really simple way to do “stack operations” like these using nothing but continuation passing style (?) and a bunch of appended function calls, but I don't remember the exact details.

(The source code basically looked like your do block but without the do and with an extra ‘E’ at the end or something)

I mean I can do it the brute force way by using a type class to construct the infinite type, but that's sort of lame, and I'm sure there was some ultra-elegant way I'm trying hard to remember. Maybe somebody else knows what I might be referring to?

The :: Token you have there applies to the expression Just (True:st), not the whole function.

Got it, thanks. I'll just stick with the sticking the type sig of the tokens above it (even though it looks a bit tiresome to use 10 lines to type 10 variables)

Reading Joy of Clojure the "cool" uncle in the lisp family.

found it

type Stack = [Bool]
type Op t = Stack -> (Stack -> t) -> t

true_t, false_t :: Op t
true_t s k = k (True : s)
false_t s k = k (False : s)

and_t :: Op t
and_t (x:y:s) k = k $ (x && y) : s

go k = k []
stop s = s

foo :: Stack
foo = go
true_t
false_t
and_t
stop


extending this to support Maybe is left as an exercise to the reader

forgot URL

alecb.me/blog/stack-language-ocaml

>tfw Haskell is so close to your ideal language but the community is shit
>ridiculous need to invent a fucking 2 character symbol for every thing making code impossible to read
>language is indesicive so you have a million unofficial extensions in ghci which means 2 different projects are basically using 2 different languages
>stupidly clever and complicated solutions like backpack because String is still [Char] instead of solving it the simple way

>language is indesicive so you have a million unofficial extensions
I think it's both a blessing and a curse. It basically goes to show that Haskell in practice is more of a research language than anything else. While you can use it in practice just fine, its main goal is still pushing the envelope of functional programming.

It needs a lot of time to mature and gain industry acceptance if it ever wants to be used at a larger scale in the real world (i.e. companies).

>implying Haskell is pushing the envelope anymore

Which functional language should I learn? I've looked into a bit of Haskell, but should I continue or pick another?

That all depends. Do you like Haskell?

write a function to return factors

factors :: Int -> [Int]
then
numFactors = length . factors


e.g.

factors n = filter (\x -> n `rem` x == 0) [1 .. n]

>a million extensions
The majority has a common opinion on which ones to use though.
I think the issue is a lot of them haven't been standardised, hopefully they will be for Haskell 2020

>The purest code is never written.

>2016
>he still needs to write code
sad!

Reminder that you can discuss functional programming in /dpt/ and you're more likely to get a reply.

bump

public class Fuckyou{
public Fuckyou(){
System.out.println("Hey fagz");
}
public static void main(String[] args){
new Fuckyou();
}
}

You should probably move the println to the main method. You don't really need a constructor for something like that.

but that's not OOP at all

in Haskell this is just

main = print "Hey fagz"

If you wanted to OO more, you should have an interface of FuckYou and have a "class Thing" that uses them in some way, that way your output isn't bound to a specific implementation.

This is also good for testing, because you can then test both sides of the interface.

This kind of testing absolutely everywhere is both great since you can usually run your entire test suite in less than a second, and is important if you want to refactor things nontrivially later to make sure you satisfy the interface's contract.

Yeah, this lets you avoid integration tests. That's a good thing because integration testing is horrible for OO systems. (Actually, integration tests are horribly inefficient in general)

Avoid those like the plague by making sure your OO is separated enough, and make sure your designs use interfaces for everything. Otherwise you will inevitably find bugs almost any time you want to add some new functionality that isn't super-basic.

Honestly, it's kind if a pain. I think a lot of us here like functional because it lets us avoid this headache.

A generic isn't needed either. Just make sure the interface defines methods that accept FuckYou and you should be fine.

Written code changes the state of the Universe.

The more you can do with the least amount of changes, the better.

>implying a new Universe isn't created whenever anything happens

Well, it is, but most of the new universe is shared with the old universe. Otherwise that would be really, really expensive.

Ah yes, the persistent universe theory.

bump

Memory is cheap now, we can handle the whole new universe.

Professional OCaml coder here. >tfw

Why haven't Haskell and OCaml been brought together yet?

let () =
print_char '\007';
flush stdout
;;

>You know, there are tools for specific tasks.
but there is no task that demands a programming language that is primarily focused on functional programming.

I watched all the lectures on youtube, does that count?

Language manipulation (ie. compilers).

Functional programming is the basis of all good programming.

Highly parallel operations. Infact Scala is going beyond threads and cores and into distributed computing in a principled way with Scala spores.

Daily reminder that functional programming is a dead-end fad.

Real World Ocaml
realworldocaml.org/

I'll be adding this.

Functions are first class citizens in python. Can python be considered as a FP language?

It can be considered a shit language in which you can do -


actually aren't closures fucked in python?

guess not faggot

Is functional programming a meme?

It's not designed to be a functional language, and competence of the creator in FP is to be questioned.
artima.com/weblogs/viewpost.jsp?thread=147358

Despite the name "Functional Programming", FP means more than having functions as first class citizens.

Nowadays your language needs to implement at least a few of these to be considered a FP language: medium.com/@jlouis666/on-functional-programming-df28cc9078de#.9d52x610l

>implying it isn't
Have you seen a list of GHC 8.0's new features?

ghc.haskell.org/trac/ghc/blog/ghc-8.0.1-released

Haskell is still very much evolving, and it's going in directions I would never have predicted. TypeInType pretty much blows my mind. It's basically inching closer and closer to simulating full dependent types without requiring an actual dependent type system, which is a major breakthrough.

Haskell was created as a common language for introducing PLT ideas without everyone having to define their own language in each of their papers, it will continue to serve its academic purpose.

Obviously a few of those ideas will prop up and actually be used in the real world.