In a paragraph...

or two, describe to me why you love functional programming and lisp/scheme/haskell so damn much /prog. You guys seem to be convinced that it's a superior way to program when conceptually it seems rather limited in comparison to imperative programming.

Imperative programming relies upon side effects.

Theoretical-academic types love these languages because they allow them to write shit code fast.

>>2

Programming anything of use relies upon side effects. The side effects (changes) are the entire purpose. If you can't the state of something, the only useful programs you can make are ones that are making calculations.

>>4

Nope, in a functional language you state what happens ans what the answer is and then work to get there, not the other way around like in imperative.

Wow, I hadn't realized how much sense that makes.

>>5
Not much, as why would you tell the computer the answer if that's what you want him to calculate

Enterprise Best Practices In Synergy With Turn-Key Solutions To Business Requirements.

>>6
Ok, instead of do y until I have x.

It's I have x, do y until true.

>>8
It's like King Crimson.

>>9

Have you ever actually gotten to know a functional language well?

In a paragraph...
or two, describe to me why you love imperative programming and C/BASIC/COBOL so damn much /prog/. You guys seem to be convinced that it's a superior way to program when conceptually it seems rather limited in comparison to functional programming.

>>11'
Implying we don't love both C and Haskell.

>>11

Imperative languages can usually do everything functional languages can do, plus change state. Also, BASIC and COBOL are terrible languages to lump in with C.

Here's an argument for imperative style...

Let's say I'm writing a game. Say... an RPG. In this game I have multiple characters to manage, we'll say at the moment that the main characters (mage, warrior, thief) are in a battle with three goblins and an ogre. Although a purely functional language would have no problem calculating the damage I deal to the Ogre, or the XP I receive from killing it, it would be quite confused when I told it to level up the Warrior. "What do you mean you want to permanently increment it's level by one?" it might ask. That would of course, be changing the status of something, creating side effects. Or, perhaps it found a way to achieve this in some other way. Now it comes time to update the stats (attack, defense, speed) of the Warrior. The imperative programmer takes the warrior's base stats and level, calculates the new stats, and re-updates them. The functional programmer, too scared of changing the state of the warrior, decides instead that he'll write a function for calculating the stats, but will instead call it whenever he needs the stats, instead of making it so he can make O(1) calls to Warrior.Attack whenever it is needed.

Functional programmers hate the idea of procedures, functions with side effects. They hate the idea of changing the state of things. They think everything can be done with functions, which take something in and spit the same thing out every time. Perhaps they are unaware of the idea that computers can be used for more complex applications than advanced math. Pure functions can be fine for calculating primes, or finding the arc cosine of some value... but what about changing the state of some window from full screen to minimized?

The truth is your CPU does not think functionally, it thinks imperatively. If computers were not meant to change state, they would not have had the ability to change state. But they do, and millions of applications rely on that ability.

>>13
COBOL is better than C, it has objects.

>>6

you tell the computer the answer symbolically, and then the computer evaluates it.

>>14
it would be quite confused when I told it to level up the Warrior. "What do you mean you want to permanently increment it's level by one?" it might ask.
Because you, as a person who apparently has zero functional programming experience, should know exactly how you would implement something in a functional language. And if you can't think of a way to do it without knowing anything about functional languages, it must be impossible.

The truth is your CPU does not think functionally, it thinks imperatively.
Because fuck abstraction, right? The CPU also doesn't know anything about object-oriented programming. Should we write programs as just a bunch of procedures operating on integers? (I'm not a big fan of OOP, by the way, it's just an example.)

IHBT

>>17
Functional programmer here, I'd still use side-effects if I were to implement >>14's shit. But most of the complexity would still be in purely functional functions.

>>17

Then tell me, how do you update the value of something when you can't change state?

Also, OOP is a hell of a lot less abstracted from the CPU's line of thinking when it isn't taking away one of the most basic operations, which is reading and writing to memory.

>>19
http://cvs.haskell.org/Hugs/pages/libraries/mtl/Control-Monad-State.html
http://dis.4chan.org/read/prog/1324805504/12
The implementation of the State monad is purely functional, by the way. There are no ugly compiler hacks or anything going on behind the scenes.

I'll admit, doing it this way can lead to a bunch of ugly imperative code that makes it pointless to use a functional language in the first place. The advantage, like >>18 said, is that you minimize the amount of code that explicitly uses state.

There are other ways, though. One example is functional reactive programming, which completely eliminates explicit handling of state like that. I don't know enough about it to comment on exactly how powerful it is, but it seems interesting.

>functional
That word, I don't think it means what you think it means.

In technical terms, functional languages completely replace their products and modifications with an entirely new data set. Like if you had one list and you modified it, it would create an entirely new list while not replacing the old one.

If you mean the general notion of "higher level" languages, than I prefer Lisp-likes only for Computer Science reasons.

For general programming I'd do C++ preferably as I find more useful tutorials and previous code written in that for the tasks I want to pursue, though coding in C might be nicer since it's supposed to be more efficient.

In truth, I'd like to make my own compiler and language for Lisp-likes, as that's how they're most powerfully used, you understand what you want to happen, so you create a custom compiler, then you understand how you want to express your thoughts, so you create the custom language. Neither process comes first, they must be done simulatenously, this is why Autists and elitists prefer languages in and of themselves, they don't understand what they're doing and they have no intent to, they just like using the language they comprehend for the tasks they want to complete.

>>14
What? No, absolutely not.
battle is a function GameState -> List Enemy -> GameState.
GameState is a tuple (Party, Money, MoreStateHere).
Enemy is a tuple (Lvl, GivenExp, MoreStats)
Party is a tuple (List Character, List Character) (active, inactive).
Character is a tuple (Lvl, ToNextLvl, Class, Atk, Def, Spd, MoreStats).
giveexpr is a function Character -> Nat -> Character.
levelup is a function Character -> (Atk, Def, Spd) -> Character.
...

The functional programmer, [...] decides instead that he'll write a function for calculating the stats, [...] instead of making it so he can make O(1) calls to Warrior.Attack whenever it is needed.
O(1) doesn't mean fast, it doesn't mean an atomic operation, it means it takes a constant number of operations to compute something:
f x = 1 is O(1),
f n m x = cbrt(log(2^32*n+2-m)/x is O(1),
fib n = (phi^n + (1-phi)^n) / sqrt 5 is O(1),
getstats lvl class = map (*lvl) (getatkcoeff class, getdefcoeff class, getspdcoeff class) is O(1) too.

And, your CPU thinks imperatively because it is designed to do so. Even then, there's a whole lot of (pure) combinatorial logic in there.

>>14
The truth is your CPU does not think functionally, it thinks imperatively.
You must have never used a Lisp machine or Reduceron, ``faggot''.

>>23
They're both the worst pieces of shit ever designed. I wish Haskell programmers would just fucking die in a fire already.

why does /prog/ have these threads every week.
why do the functionalists fall for it every time.
the imperativists wont be converted.

>>14

you can create a new copy of your warrior whose level has increased by one. This can be expensive if your warrior data structure is flat and very long, but if it consists of maybe 5 or 6 references to other immutable objects, then a copy can be implemented very quickly by only making copies of the sub objects that have changed, and reusing references to objects that don't need to be changed. This may seem silly, but it is a generalization of the inplace modification approach in imperative programming. In fact, it is exactly what you would need to do if you still needed a reference to the old version of the warrior. Like what if the player died in the level and you were to restart it? This would be trivial if you still had a copy of the old warrior. But if inplace modification was used, then you would explicitly back up the warrior before starting the level, so that you could revert back to the old stats upon death. And what if several different components needed their own version of your warrior, which they should be able to modify freely? In the worst case, you'll have to do about as much if not more copying.

Creating a new version of an object instead of modifying it is a generalization of in place modification. If you want to, you could think of in place modification as an optimization of the copy method, and it could be used if the reference count of the object you are reassigning is equal to one, since it is about to loose its only reference, there is no harm in inplace modification. If you use inplace modification explicitly in your code, then you commit to never sharing the data from multiple points, and this assumption may be valid at the current time, but you may have to violate it later, or might become more efficient to violate it.

But inplace modification of objects can be used as a communication device between different threads, but there are other models that are less error prone, like sending and receiving messages.

>>25
imperativists
If that's your term for people who think that purely functional languages are purely shit, then fuck you faggot.

>>27

who so defensive blain?

>>28
fuck off and die, purely functional faggot

>>29

who so defensive andy?

>>30
eat shit and die, fagcake

>>27
state is sin.
the imperativists rejection of referential transparency makes them tainted and unmemoizable.

>>32

How is state sin?

>>33
Software cannot be referentially transparent whenever state is involved.

>>33
>>32
no no no state is not a sin.

however using it too much can lead to horrible consecuenses, we all know the wrong doing of  global variables and how to design code block that use internal varibles only to make them play nicely with other threads etc.

the thing is that if you are going to do all that, why don't use a language that promote that idea? functions as in mathematics, state (Marked) and also purely functional (in haskell for example state is passed as a hidden varible by the state monad, is quite simple actually, i can be expressed with word correctly but the code is simple to understand)

lisper also understood this, schemer if i recall correctly mark their function ending with and ? when the programmer coded them as pure. that because pure function a deterministicals (make promises) instead when dealing with the real world thing can go wrong (you have to make sure a file exist, the disk is not full, there is enough ram)

fuck off and die haskell faggots

Erlang > all

>>37
because it uses all the thread and doesn't leave space for everybody else !

isn't it a problem with haskell style state monads that then all your functions have to take monads instead of the underlying value and it "infects" the program?

Try passing Google's matrices by copy, that's right, your shitty toy languages are useless. Mutability is king.

The Haskell Cabal > Imperialists

Haskell is shit. fuck you faggots

>>40

If you are free to arbitrarily mutate the matrices, then you must pass them by copy. If they are immutable, then you can always pass by reference.

>>39

sounds like const in seeples, except the other way around.

>>39
Nope. Here's a non-monadic function calling a monadic one.

import Control.Monad.State

-- f is pure
f :: Int -> Int
f = evalState incWithState

-- incWithState runs in the State monad
incWithState :: State Int Int
incWithState = do
  y <- get
  put (y + 1)
  get

Immutability is a very powerful invariant to code against, not a restriction.

>>45
It's shit either way, which causes Haskell itself to be fucking shit.

>>46
No.

I'm amused by how C++ tards think "everything is a value" means "everything passes by value.

No.

To put it in your terms, everything passes by const reference.

If you're too fucktarded to read one of the hundreds of “paragraphs” about the benefits of functional programming, go fuck yourself and change fields, in no particular order.