functional programming considered stupid

learn a real language morans

define "real"

>>2
C and its derivatives.

Functional programming is just as awesome as C. Don't get pissy just cause you're too lazy to learn something new. Kiss my monad-ridden ass.

>>4
Show me a functional language that isn't
A) Slow
B) Harder to use than C
C) Full of philosophical bullshite
D) Unnecessarily complex
and I'll believe you.

A) Compiled lisp is typically faster than C for complex applications due to better handling of complexity.  Erlang is typically faster than C for highly threaded applications, sometimes even when interpreted.  For something that spends its life in tight numeric loops, compiled FP languages tie with C.

B) C is one of the most error prone, finicky, hard to code/maintain languages in existence, only next to assembler.  Given that C is "portable assembly", that stands to reason.

C) FP has been around long enough and been used enough to have solid practical underpinnings.  Yes, any new language has its wankery (whether imperative, OOP, stack, FP, etc, and including C's history), but practicality fights against it.

D) C is incapable of scaling to complexity in terms of programmer load, without adding custom intermediate layers (ie, custom code generators or scripting engines, so why not use an already designed language?).  FP is about the same level of effort to do easy stuff with and FAR easier for complex programs.

>>6
A) Specific examples?
B) Did you ever think that perhaps you find more bugs in C programs just because there *are* more C programs?
C & D) these are too hard for me to argue with purely for the sake of trolling. You win, FP is awesome.

>>7
B = false

>>7

B) is not about finding bugs in C, it's about it being "harder to use" because of the clunky build system (dumb compiler, include files everywhere, no language-level macros, etc) and the assembly level "do everything yourself" workload involved just to get the basic framework for any basic application going.

>>9 is a pussy.

>>7
A) Look for some simple benchmark comparison of a hundred compilers and interpreters. Some functional language environments featuring Common Lisp (SBCL) or OCaml for example, as well as some dynamic specializers on Python (psyco) or Scheme (forgot the name) achieve a pretty respectable performance for numerical computation. They can get very close to C.

And even if they didn't exist, I'll take Ruby — probably the slowest of the bunch — over C, because it's faster. How so? Let's suppose you want to write a program that 1000 people will run 1000 times, which you'd have to admit is more than usual. I could write it in C, taking 1000 hours of work and coming up with a program that's OMG optimized and runs in 0.1 seconds, or in a functional langauge, or at least a flexible dynamic language with support for functional programming elements, taking 100 hours of work and coming up with a program that runs in 1 second - an order of magnitude slower if you want. The programs will be ran for a million times, the C one taking 100000 seconds (~ 28 hours) to run for everybody, and the other one taking 1000000 seconds (~ 280 hours). The total amount of human time spent on either programs are 1028 hours for the C program, and 380 hours for the Python program. And that's assuming the hour of a user is the same worth as the hour as a developer, which isn't. (The hour of a luser, especially if outside your organization, is worth shit.) And that's assuming the user could actually take advantage from the C program taking 0.1 seconds to run instead of the other one taking 1 second. Most lusers are clickfags and run everything by click-click-click-fagging them, which takes them more than a second anyways (not to mention launching a new command window or terminal, which could take most of the time).

B) No, man, no. C is inherently error-prone. I don't expect any better, because it's portable assembly, but when you have to specify exactly how to deal with every octet, if not every bit, what points where, and so on, you are bound to make mistakes. If, on the contrary, you specify things as closely possible as your abstract, original idea of "I want it to work this way", chances are that you'll do it right. Compare what you need to do in C to create dynamic list (i.e. no arrays) with the elements of another dynamic list (i.e. no arrays) without repetition. I can do that in Python with set(l). And comparison takes place regardless of object type; it would work nicely on list (1, 2, "hello", "hello", apple, orange, (1, 2, 3), True) and yes, that had a nested list.

C & D) Fucking faggot son of a bitch. I wrote all that before reading this line. Consider myself successfully trolled. Well, at least it was fun to write.

>>3,7,9
Different person.

Ruby has the potential to be slow as shit.

>>10
Maybe so, but I'm sick and tired of having to put up with yet more buggy software crap because programmers are too hardcore to use less error prone tools or insist on reinventing the wheel (which is bad, because most programmers are crap and therefore do it wrong).
Programming is already an error prone process, don't make it worse by using error prone languages.

>>11
They can get very close to C? Sometimes they can exceed C.


Programmer time is more expensive than processor time nowadays, so I'd prefer to use a slower language which is faster to develop in.

Contrary to what the python, ruby, perl people want you to believe, it doesn't take that much time to code the same thing in C, especially if you are looking for performance. Their languages are fine for speed of shitty little shell scripts and maybe the incredibly I/O laden BitTorrent.

That said people who claim it takes longer to code it in C are ignoring the fact that they don't know C well enough to confidently code it in C.

OCaml is a good functional contender against C, although if you code in a functional style it usually won't be as fast as the imperative styles.

Contrary to what the C, C++, C# people want you to believe, it doesn't take that much time to code the same thing in Ruby, especially if you are looking for speed. Their languages are fine for speed of shitty little compiled executables and maybe the incredibly I/O laden BitTorrent.

That said people who claim it takes longer to code it in Ruby are ignoring the fact that they don't know Ruby well enough to confidently code it in Ruby.

Scheme is a good functional contender against Ruby, although if you code in a functional style it usually won't be as fast as the imperative styles.

Ruby is great for little chan boards but thats it.

Ruby is fucking slow it is unbelievable. Their self-righteous author Matz is such a prick that he didn't bother reading anything on how to make a language. So he shat one out in the simplest way he knew how. This results in a language which often TCL will beat. TCL passes code as strings. Ruby has a hard time beating TCL. That's nuts.

Try coding some numerical code in ruby that runs in O(n^2) and verify it actually works with test cases. Your development time has just sky rocketed waiting for your horribly shallow unit tests to finish fucking type checking. Language performance effects programmer performance, if your language is slow, you won't do things which are slow and valuable, in fact you'll try to avoid them because you know what will happen, you'll have to code in C. But since you're a ruby zealot you obviously don't know C very well thus that scares you.

Ruby is incredibly slow. Code density does not imply maintainability either. Even if you follow the idiotic ruby way. 5 levels of deep of dot operators simple code does not make.

>>16
Contrary to what the python, ruby, perl people want you to believe, it doesn't take that much time to code the same thing in C, especially if you are looking for performance.
OMG OPTIMIZED. Now code [(x, y) for x in xrange(10) for y in (3, 4, 5, 10) if x < y] in C. It should return a mutable, dynamic, heterogeneous linked list of tuples (immutable, dynamic, heterogeneous and linked). I wrote my crap as fast as I could, because I just expressed what I wanted to get. Can you do that in your OMG OPTIMIZED language? BTW, if my crap runs slow, I can buy a better computer for it with the money I make in the time I save.

That said people who claim it takes longer to code it in C are ignoring the fact that they don't know C well enough to confidently code it in C.
Not true. I've been using C for years and have a very good knowledge of it. I once tried to abstract and do all the shit I'm doing right now. Until I got tired of writing and debugging 20 lines that do what I could have done with a single obvious line in a better language.

OCaml is a good functional contender against C, although if you code in a functional style it usually won't be as fast as the imperative styles.
Again, but man, WHO GIVES A FUCK IT'S SLOWER!? It's much faster, cheaper an development, which is what matters. If you don't like the execution speed buy better hardware. You can't be that poor.

>>19
I never said that:
1. Ruby was fast
2. Ruby was good (it's certainly better than C, but I hate its Perlish syntax)
3. Functional programming is simple

I said that functional programming is far more effective, cheap and fulfilling, and helps getting things done in the end. I also said only teenagers who just discovered C and produce the buggiest, worse algorithms that execute at the fastest speed care about OMG OPTIMIZATION and CFLAGS (wait, it's USE flags where it's at!).

>>20

You (1 person) save maybe an hour on development time
Everyone else (Up to a million and beyond for an ENTERPRISE XML WEB 2.0 SOLUTION) have to waste their time running the slow ass piece of shit, and spend a thousand dollars on new hardware.

Conclusion: You're a fucktard weenie who is too pussy to use C.

>>21
Keep writing the OMG OPTIMIZED stuff and don't mind me, I'll just be getting things done.

Nobody expects suave yoshi lisp!
[code]
                       //`'''```,
             o        // LISP   `.,
       ,....OOo.   .c;.',,,.'``.,,.`
    .'      ____.,'.//
   / _____  \___/.' 
  | / ||  \\---\|
  ||  ||   \\  ||
  co  co    co co
[code]

Nobody expects suave yoshi lisp!

                       //`'''```,
             o        // LISP   `.,
       ,....OOo.   .c;.',,,.'``.,,.`
    .'      ____.,'.//
   / _____  \___/.' 
  | / ||  \\---\|
  ||  ||   \\  ||
  co  co    co co

Ruby was made in the OMG OPTIMIZED language.

>>23
Shut up, chibi suave yoshi lisp!

>>24
Shutup suave Lisp space toad

>>21

Oh noes!  My web query took 30msec in $SLOW_LANGUAGE instead of only 15msec if it were OMG OPTIMIZED C!!!!one!!!eleventeen!!1

Fuck off.  Speed doesn't matter outside of action games and supercomputing.  Computers are "fast enough" nowadays.

plus you'll hit IO limitations long before you'll ever choke your CPU in any language, if you're not a faggot programmer.

Listen, program in whatever the hell you want. The only dudes complainin' are the ones that are rushing to learn languages for fear that they might go out of style. If you can make something awesome in QuickBasic, do so. If you find Ruby more effective for your project, stfu and use it.

>>28
Speed doesn't matter outside of action games and supercomputing.

You are the cancer that is funding .NUT and Java

LOL.

>>31
I'm sure >>28 is not fond of Java and most of all of .NET.

Now code [(x, y) for x in xrange(10) for y in (3, 4, 5, 10) if x < y] in C. It should return a mutable, dynamic, heterogeneous linked list of tuples (immutable, dynamic, heterogeneous and linked).

how about you implement this in whatever language that is:
int factor(int num,int* factors){
 int n=num,i,l=0;
 if(num<2)return 0;
 for(i=2;i<=num/2;++i){
  while(!(n%i)){
   n/=i;
   factors[l++]=i;
  }
 }
 if(!l){
  l=1;factors[0]=num;
 }
 return l;
}

it should take an int and a pointer to enough memory to to hold all prime factors of the number as an int array, put the prime factors of the number into the array, and return the number of factors as an int.
for example, if you do int n=factor(12,factors);, n should be 3, factors[0] and factors[1] should be 2, and factors[2] should be 3.

>>34

In Perl:

£%*(%"&&*(%"&*(%&"*)(^$8^*_)9split^£"^)&("^!join()*£"()"&*$&"print&£"&^

Plenty of programs could use machine learning and AI to help out. Specifically UI tasks. Your image collection is a good example where massive amounts of CPU time are needed to effectively segment, index, tag, indentify, cluster, relate images.

Your music could also benefit from machine learning. Don't you feel like asking your computer to find audio that sounds similar to another piece of audio? Or find related audio. MusicBrainz only works so far, what if you want to beatbox into the microphone and find related songs?

All of these require performance. Even GUI apps require performance, hell you probably whine everytime you open a java app.

Performance is more important than you realize.

>>34
what about lisp?
(defun factor (num factors)
  (let ((l 0) (n num))
   (loop for i from 2 to (<= i (/ num 2)
    do (while (/= 0 (mod n i))
        (setf n (/ n i))
        (setf (aref factors (incf l)) i)))
   (when (= 0 l)
    (setf l)
    (setf (aref factors 0) num))
    l))

then again, there is no real reason to use arrays, so we will use lists. so there is no reason to return the length... the user can easily do (length list)... so we end up with this

(defun factor (n &optional (i 2))
   (cond
      ((> i n) '())
      ((divisible n i) (cons i (factor (/ n i) i)))
      (t (factor n (+ 1 i)))))
  
[45]> (factor 22)
(2 11)
[46]> (factor 34)
(2 17)
[47]> (factor 40)
(2 2 2 5)

Yes, it is not that efficient. but it's nice and clean, and if you really need to, you can use the above version.

>>37
lol, you managed to make it even less readable than it is in c.

>>38
Looks readable enough to me. Could it be that you aren't an EXPERT PROGRAMMER yet? I'm not either (note my BBCode failure), but at least I can read that. Looks like the definition of DIVISIBLE is missing though.

(defun divisible (a b) (zerop (mod a b)))

>>39
i didn't say it's not readable enough. i just said it's less readable than the c code in >>34.

>>40
read it outloud

>>40

It's way smaller and with far less punctuation.  How is that less readable?

>>40
Well, by "readable enough" I really meant that a four line function is a lot easier to come to terms with than a umpty-ump line thing that provides no hint of what it's meant to do.

>>42
))))

Don't forget to add in the complexity of determining what size of array you need to pass in (*snicker*), allocating and deallocating it if it's on the heap (*laugh*), and having no good terminator so you have to (*haha*) manually pass around the length in a separate variable! (*BWAHAHAHAH!*)

Your mom loves the C

>>45
You're an idiot, ever heard of sizeof you stupid shit.

>>47
what?!

>>45
passing around the length has it's advantages. it makes the time complexity of determining the length of the list once you've filled it O(1) instead of O(n), for example.
also, for any number n, there aren't going to be more than log₂(n) prime factors.

then again...
typedef struct { int car; List* cdr; } List;
List* cons(int car, List* cdr)
{
   List* a;
   a = malloc (sizeof(List));
   a->car = car;
   a->cdr = cdr;
   return a;
}

List* factorAux(int n, int i)
{
      if (i > n) return NULL;
      else if divisible(n,i) return cons(i, factor(n/i, i));
      else return factor(n, i + 1);
}
List * factor(int n) { return factorAux(n,2); }

>>49
s/log₂(n)/floor(log₂(n))/

>>47

1) sizeof doesn't tell you how much memory is allocated to an array passed by int*.

2) even if it did, sizeof doesn't tell you how many entries are actually used in an array.

3) you stupid shit.

>>50

Yeah, now clean up your allocations after your done.  Now imagine that with a tree structure, and branches that might not have remained in the final result.

still don't like it?
int factor(int n, int* array)
{
    int i = 2;
    int* begin = array;
    while(!(i > n))
    {
        if(divisible(n,i)
        {
           *array++ = i;
           n \= i;
        }
        else i++;
    }
    return array - begin;
}

>>52
you've proven yourself a worthy ... IDIOT.

sizeof(x)/sizeof(x[0])

Did you lose your brains? Ever heard of division, you simpering mental midget?

ITT You're stupid to understand C

>>55

LOL.  Sure, buddy.  Pop quiz:  what does "sizeof(x)" return when x is an int*?

>>57
4, lol

>>57
int* is not an array you fucking retard

LOL ok there buddy, so what would happen if I replaced sizeof with malloc?

>>60

#include <stdio.h>


int main(int argc, char **argv)
{
    int * x;
    x = (int *)malloc(sizeof(int));


    printf("%d", malloc(x)/malloc(x[0]));
    return 0;
}

LOL ok buddy heres what happens!

>>59

>>47 was claiming sizeof would work for the "array" parameter in >>34 which is actually int*.

PROTIP, 73wJdw8T:  int* is not an array you fucking retard

int * is the same as array of int

Not quite. But very nearly.

>>61
LOL, You casted malloc NOOB

>>63
no it is not.
int * is a pointer to an int
int[] is an array of int's of unspecified size

read the first example at http://4-ch.net/code/kareha.pl/1187046689/17
(i'm 17 there)

>>66

array[3] == *(array + 3)

you damn dirty n00b

volatile auto const *(int(** const ********const [][]*const int(****void[])*[]int[][])) var

OMG I THINK I FOUND JESUS

>>68
OMG I don't see him, where‽ Can you give us a pointer?

>>69
I lol'd

>>61
>>63
>>67
Wow, you're such an idiot. You don't understand the semantic difference do you. They are similar yet in the standard they are not the same. You fail. Even worse your stupid idiotic code:

printf("%d", malloc(x)/malloc(x[0]));

Good job asshole, printing %d of whatever random value is in x? You just probably just tried to allocate millions of bytes of memory, twice! Or divide by zero if you're lucky.

You're owned, beaten, embarassed, even worse: YOU'RE WRONG. Get the fuck out of /prog/ you goddamn idiot, you can't even code your way out of an example.

>>61
>>63
>>67
Wow, you're such an idiot. You don't understand the semantic difference do you. They are similar yet in the standard they are not the same. You fail. Even worse your stupid idiotic code:

<?php echo "welcum 2 my website"; HitCounter(); ?>

Good job asshole, printing a dumb welcome message. You just probably just tried to allocate millions of bytes of memory, twice! Or divide by zero if you're lucky.

You're owned, beaten, embarassed, even worse: YOU'RE WRONG. Get the fuck out of /prog/ you goddamn idiot, you can't even code your way out of an example.

>>71
well, >>63 isn't me but >>67 and >>61 are the same troll. so congratulations you won

Evidence >>>/prog/ was never good

>>74
That's evidence /prog/ was programming related at some point.

This thread is considered stupid.

Learn to safe faggots.

DUBZTEP

>>77
I laughed, but then I vomitted a little in my mouth.

>>78
I hope you choke on it.

>>76

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.