>>14
Go home, Larry. Perl is a horrific mess, mostly because it tries to emulate natural language, which any idiot could tell you is a horrible idea in a programming language not aimed at young girls.
Name:
Anonymous2009-10-14 17:13
>>15
You obviously do not know the pleasure of being Perled inside.
Perl is made of pure awesomeness.
>>35
Then it can't solve complex problems that require them.
Name:
Anonymous2009-10-15 19:59
>>36
Here's an exercise. Write a memory manager in lambda calculus. Oh that's right, you can't because you can't do shit in lambda calculus. How do you like that?
>>39
The right answer is that lambda calculus could be used to emulate the behaviour of a memory manager. It can't be used to make a real memory manager as it's just a formal mathemathical system which has nothing to do with how hardware works. That said, you might be able to implement one if you defined a concrete language based on it and give it an FFI, or just access to primitive memory management functions, but that will no longer be lambda calculus, but a practical language based on it.
>>53
Damn straight it is. I mostly like this example for its bubble_again_perhaps function.
Name:
Anonymous2009-10-16 18:35
>>56
Now write a dual-pivot quicksort in your precious functional language, without using any imperative features (loops, selection, state, etc...). Ensure that it is stable (equal keys appear in order).
Name:
Anonymous2009-10-16 18:39
i demand a functional implementation of a binary tree sort!
What's the point in demanding functional implementations?
You can emulate state generally(not talking just about tail-recursion + TCO here!) in a functional manner, even if without a very smart compiler it would be terribly inefficient when compiled. Of course, a purely functional implementation that just did the right thing instead of emulating state would be much more proper and faster.
>>60
Here's the non-stable version by the way. It could use a refactoring and I guess I'll do that when I write the stable verson.
(define (split num l)
(let iter ((original l) (lt '()) (gt '()))
(cond ((null? original)
(list (reverse lt) (reverse gt)))
((< (car original) num)
(iter (cdr original) (cons (car original) lt) gt))
(else
(iter (cdr original) lt (cons (car original) gt))))))
>>59-61
My point is functional languages will never be elegant or "better" in almost every real-world situation. Don't get me wrong, it's pretty neat being able to define factorial using pattern matching, but it really doesn't belong in mainstream programming.
Here's someone else's implementation in Common Lisp:
(defun quicksort (lst)
(when lst
(let ((pivot (car lst)))
(append
(quicksort (remove-if-not (lambda (x) (<= x pivot)) (cdr lst)))
(list pivot)
(quicksort (remove-if-not (lambda (x) (> x pivot)) (cdr lst)))))))
Name:
Anonymous2009-10-16 19:55
>>62
Surely that's just being rather pedantic, It doesn't have to be better in almost every real-world situation. I'm from the SICP school of thought and I use the best form of modelling for the problem at hand. If it's expressed more clearly/efficiently with state, then I'll use state, but in many cases a functional approach is best.
>>62
I don't know about purely functional languages, but some more pragmatic ones make a lot of things much easier, but I don't care about what other people use(mainstream programming), as long as there's enough community to keep developing libraries and implementations for the language of my choice, in this case, Common Lisp.
Name:
Anonymous2009-10-16 20:06
>>62
Yaroslavskiy's Java implementation is three pages long. So there's one metric functional languages are “better” by.