Lisp has changed my life

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".

Be sure to click the throbbing text as well.

http://mind.sourceforge.net/lisp.html

is a major artificial intelligence language.

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
static typing
lazy evaluation
type classes
monads

>>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.

Prelude> let (<**>) = zipWith ($)
Prelude> map (^2) [1..10]
[1,4,9,16,25,36,49,64,81,100]
Prelude> map (+) [1..10] <**> [11..20]
[12,14,16,18,20,22,24,26,28,30]
Prelude> map (,,) [1..5] <**> "abcde" <**> [10..15]
[(1,'a',10),(2,'b',11),(3,'c',12),(4,'d',13),(5,'e',14)]

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.

im a recent lisp to javascript convert

all you lispfags can go scrub cdrs

Lisp coders might be toilet scrubbers, but Haskellers are homosexual gigolos.

>>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.

>>9
don't fall in love with your technology

>>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.

Also, you can implement a variable number of arguments of different types in Haskell (http://hackage.haskell.org/packages/archive/base/4.2.0.0/doc/html/Text-Printf.html), but usually I would do it a different way.

>>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?

>>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.

>>13
type-classes on lisp? you can use macros to archive something alike
No, I was thinking more along the lines of generic functions and CLOS.

>>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.

>>18
How did i manage to screw this up.

Im so dradfully sorry >>9 and the rest of /prog/, minus >>11 that is.
>11 is less worth than a nigger and smells atleast twice as bad as a jew.

>>18
>>19
But why are you so angry? Does alcohol make you angry? Maybe you should limit its use.

>>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.

>>21
I'm not >>11-kun. I was just concerned about your well-being.

VIPPER = JEW

>>23
This makes no sense.
>>21
Well failing to see why i am so angry i am forced to ask you why even are on /prog/?

>>24
You're drunk VIPPER. Go home.

>>25
But /prog/ is my home.

I love /prog/ so very very much.

>>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.

>>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
Lazy evaluation should not be in anything at the language level. End of conversion.

>>30
Have fun doing more work than necessary.

>>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.)

>>31
Have fun with space leaks everywhere.

>>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!

>>33
implying

>>34
"The next Haskell will be strict." -- Simon Peyton-Jones

>>32
I can't use lazy programming properly therefore it is not good
Stay classy programmer.

>>37
Nothing supports my argument therefore it's time to turn to ad hominem.

Stay idiotic, toiler scrubber.

what's wrong with lazy evaluation?

>>39
Get the fuck out of the thread you no talent bitch.