http://landoflisp.com/#yt
If you take the time to go all the way to the bottom an read the comic you'll see just what i mean by "Lisp has changed my life".
I don't know that it will be well received on /prog/, but as Lisp and Haskell change the way you think about programs, so to will JavaScript. The delightful function semantics and prototypal inheritance make it one of a kind.
If you read a list of complaints about JavaScript, you will find that they are all minor stylistic issues -- the core language and in particular the function semantics are perfect.
* "Waah, I can't implement modules or namespaces." Yes you can! Use functions.
* "Waah, I can't write classically using classes and instances." Yes you can! Use functions.
* "Waah, The parseInt function is a little bit strange, functions don't close over this, arguments isn't an array, constructor semantics are strange." Who actually gives a flying fuck?
* "Waah, I can't represent programs as data using the language AST." Oh.. JavaScript is shit. Use Lisp.
>>3
Why do people keep saying Haskell brings a new way of thinking about programs? It doesn't. It's impractical and ugly language, that reimplements, in a broken way, a limited subset of things that Lisp had for years.
They keep saying that Haskell does functional programming better than Lisp, but just look at map. That shit is completely broken, and it's not just a matter of implementing a new one in couple of lines, it's fundamentally broken at language level that doesn't allow better solution.
Also, it still can't outperform Lisp. Even despite all the hype Haskell fanboys are spouting out about how purity and static type checking can allow for better optimizations. Yet it doesn't happen. Haskell is pure shit and no one should use it.
>>4 but just look at map. That shit is completely broken, and it's not just a matter of implementing a new one in couple of lines, it's fundamentally broken at language level that doesn't allow better solution.
If you're talking about needing zipWith* instead of just map, here's a way to map over an arbitrary number of lists.
Of course, you can't give it a list of lists to map over, but that's an intentional limitation of static typing because the length of the list might not be known at compile time. If you want that then go ahead and use a dynamic language, but stop expecting all languages to have the same design goals.
Name:
Anonymous2012-02-26 12:11
im a recent lisp to javascript convert
all you lispfags can go scrub cdrs
Name:
Anonymous2012-02-26 13:51
Lisp coders might be toilet scrubbers, but Haskellers are homosexual gigolos.
Name:
Anonymous2012-02-26 14:00
>>6 If you want that then go ahead and use a dynamic language, but stop expecting all languages to have the same design goals.
If a language does not have the same design goals as Lisp, then it is objectively misguided and fundamentally broken.
The correct language has already been made and there is literally no imaginable reason for a new one to be made.
>>5
Static typing is premature optimization. Types are supposed to be only compiler hints that result in faster code, which interestingly Haskell fails to deliver.
Lazy evaluation is implementable in Lisp and full featured libraries exist. Simple implementation is even discussed in SICP which you should read, by the way.
type classes
See above about types. The same functionality is available in Lisp nevertheless.
Monads are implementable in Lisp. But 90% of all use of monads in Haskell is to mimic practices that are easily expressible in everything else. They are just hack to make Haskell suck a tiny bit less, but they don't do that much of a good work.
>>6
That's just stupid. What if I don't know how many parameters will I want to supply to the function? If I wanted to use language that limits me even in cases this simple I'd use C. Oh, wait, even C does allow variable number of arguments.
>>10 Types are supposed to be only compiler hints that result in faster code
That's an opinion and if it's what you believe, then like I said, use a language that does what you want and accept the fact that what you want isn't what everybody else wants.
What if I don't know how many parameters will I want to supply to the function?
Then you use a list, and if you want different types, wrap it in another type like data T = A Int | B String | .... It's not pretty, and nobody is claiming that Haskell's type system is perfect, but it's safer than true homogenous lists. If safety isn't that important to you, then for the third time, Haskell isn't what you want so just use something else.
>>10
>Static typing is premature optimization
god no. it isn't implemented with optimization on mind, it is implemented with security in mind. (that you can use it for make the program go faster is not the primary concern)
>>type classes
>See above about types. The same functionality is available in Lisp nevertheless.
type-classes on lisp? you can use macros to archive something alike
>Monads are implementable in Lisp. But 90% of all use of monads in Haskell is to mimic practices that are easily expressible in everything else
true. lisp doesn't have the same design goal of haskell
>What if I don't know how many parameters will I want to supply to the function?
sigh. the list monad is also called the indeterminism monad you specify the type of what are you receiving an then make the function process the list of arguments
integralPolinomio :: Double -> [(Double,Grado)] -> Double
integralPolinomio dif ass@(a:as) =
let gradoMayor = snd a
in dif * (sum $ map (uncurry integralMonomio) ass) / (moduloPolinomio gradoMayor)
look at the [(Double,Grado)] this is an umoptimized program (and a bad one) but it calculates by the legendre method integrals by accepting a list of arguments.
>>9
didn't smalltalkers were teaching you lisper something you didn't know (and found cool back then) in the 70's? how can something like that which wasn't in the design goals of lisp be perfect?
Name:
Anonymous2012-02-26 14:39
>>13 >>12
Variable number of arguments was meant in relation to map example that >>6-kun provided.
>>11
Yeah right fall in love with a girl instead. AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH Oh you such a stupid shitty faggot >>9san.
>>16 [b]CORRECTION:[u] i meant >>11 instead of >>9.
Im so sorry and slightly drunk. >>11 is i huge dick sucking scat loving turd huging shitty faggot. I hope his small dick falls off and and he gets eaten alive by maggots and burns in hell.
>>20
On the contrary, alcohol makes me feel much less angry, one might say it even makes me "happy".
Your denial of insight of the fact that technology is the ultimate good and goal of life as well as implying that humans are actually worth a damn and not to mention insulting lisp, make me want to harm you in such ways that this real does not permit me to.
>>9 If a language does not have the same design goals as Lisp, then it is objectively misguided and fundamentally broken.
Absolutely!
The correct language has already been made and there is literally no imaginable reason for a new one to be made.
Sexprs are the worst fucking shit ever made. Go scrub another toilet you minimum-wage mental midget goy.
>>24
Methinks you doth protest too much. Therefore you are self-hating jew.
Name:
Anonymous2012-02-26 17:33
>>10
If you had read SICP, you would know that they talk extensively about the reasons lazy evaluation ISN'T in Lisp at the language level, and the tradeoffs that has.
>>29
Where in my post did I imply that there is lazy evaluation at language level you fucking toilet scrubber?
Lazy evaluation brings more problems than it solves. Infinite lists aren't worth all those time and space leaks, and not analysable performance for anything non-trivial.
(Also, funny thing, there's no such thing as pure function, since all functions take some time to complete. Debugging for time leaks is much more difficult than to debug for type errors.)
>>32 (Also, funny thing, there's no such thing as pure function, since all functions take some time to complete. Debugging for time leaks is much more difficult than to debug for type errors.)
Eat this, stupid Haskell JEWS!
this thread makes me sad. why do so many of you dedicate yourselves to a language feature war? I guess it helps raise awareness about some language features. Maybe some readers of this thread will look up lazy evaluation. But why argue that a particular language or language feature is shit? Why not understand the differences, the advantages and disadvantages, of all choices at your disposal? It's a sad thing prog. Discussion can be more productive than this.
>>32
We were talking about languages and I said Haskell is lazily evaluated. Where did you get the idea that I meant you could implement lazy evaluation in the language?
I get the idea that you don't know what you are talking about when you say "time leaks." Do you know what the as-if rule is? Have you ever had any trouble debugging a C or C++ program for these so-called "time leaks"?
If your only complaint about lazy evaluation is that it can make programs hard to debug, then you need to get the fuck out of my /prog/.