>>5 Python makes functional programming hard and not worth it I like Python therefore, functional programming is hipster bullshit
OK.
Name:
Anonymous2011-07-07 6:10
It needs to be said very firmly that LISP is not a functional language at all. My suspicion is that the success of Lisp set back the development of a properly functional style of programming by at least ten years. -- David Turner
>>13
Just implement it in Lisp in like < 100 lines of code.
Name:
Anonymous2011-07-07 18:39
>>16 The toy language transitivity lemma: if a usable interpreter for a programming language can be implemented in less than 100 lines of a toy language, then it is a toy language.
>>17 system("cc -o out source.c");system("out")
What now? (Many languages which allow metacircular interpreters also let you use their lexers/parsers (reader) and compilers/interpreters by calling them directly, but you can also do the same for any more "serious" language that you can think of, and if you can't the language is only useful as a theoretical tool or its just an esolang.)
>>18 echo "What now? (Many languages which allow metacircular interpreters also let you use their lexers/parsers (reader) and compilers/interpreters by calling them directly, but you can also do the same for any more `rm -rf ~` language that you can think of, and if you can't the language is only useful as a theoretical tool or its just an esolang.)" | espeak
>>19
You know, in Common Lisp, you don't even have to make an interpreter (EVAL), I can just call the compiler directly and have it call the (usually native) compiled piece of code: (defun eval (code) (funcall (compile nil `(lambda () ,code))))
Of course, a metacircular interpreter is also possible, but it will be larger than your average Scheme one.
Name:
Anonymous2011-07-07 19:22
>>21
too bad lisp is for faggots. die in a fire ``faggot"
>>22
I know you're trying very hard to offend us, but I don't think you can manage to do that with such meager trolling skills - they are far inferior to most that have graced us before, the only thing you have is persistence. Go play with /g/ or /b/ instead!
Name:
Anonymous2011-07-08 3:58
Haskell- monads for I/O?? do you really want to make apps with monads?
Lisp- no type inference, dynamically typed, parentheses everywhere
>>24 no type inference
Some compilers (like SBCL) can do it, not that I ever had that many typing issues with CL at all. It feels better than being constrained by very strict type signatures as with ML and Haskell. The condition system and the easily accessible REPL make testing/fixing most errors trivial. It's just a different coding style than with statically typed languages. I tend to prefer dynamic typing for most of my general-purpose programming needs (except for low-level ones), but I do recognize the types of problems that are more suited for ML and Haskell. In the end it comes down to personal preference in what trade-offs you're willing to make.