Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Lisp is shit and Lisp users are faggots

Name: Anonymous 2014-05-29 3:13

Anyone who has the gall to say that Lisp is in the same league as C should be shot in between the eyes.

Lisp is an unusable piece of crap with absolutely no use in real life whatsoever. Oh, except for Ganoo /g/eemaks. Yeah, have fun sucking on Stallman's toejam, queers.

Lisp coders are unmitigated faggots no better than the optimahzin mah cloud apes crowd.

By the way, Lisp faggots, did you know that Lisp is so shitty that reddit, yes, reddit, of all people, stopped using it for their back-end because the code written with it was an unmaintainable shitpie and switched to Python?

Name: Anonymous 2014-05-29 3:15

Why would somebody think that /g/roski level posts are funny? They are just annoying crap.

Name: That feel when no deaf qt gf 2014-05-29 3:47

That feel when no deaf qt gf

Name: Anonymous 2014-05-29 5:39

While the OP is definitely right, his post is way too verbose. He would have sufficed to say that Lisp has forced GC.

Name: Anonymous 2014-05-29 6:14

GC
is this a new epic meme?

Lisp is the greatest.

Name: Anonymous 2014-05-29 6:29

>>5
GC stands for "garbage collection", you dilettante. Something your Lisp forces on the programmer.

Name: Anonymous 2014-05-29 9:38

>>5
Sure, if by new epic meme you mean old epic meme.

Name: Anonymous 2014-05-29 10:15

Name: Anonymous 2014-05-29 10:55

>>6
GC stands for Gigabyte Code, you fucking neanderthal.

Name: Anonymous 2014-05-29 11:26

>>9
No, GC stands for Github Codeblog.

Name: Anonymous 2014-05-29 18:35

>>10
No you idiot, it stands for "Gone Campin' with sexy little boys"

Name: Anonymous 2014-05-29 18:55

>>8

Do you guys recommend Haskell for learning?
learning what?

how fast is Haskell?
Haskell uses call-by-name evaluation strategy, which is slow and unpredictable. Haskell discourages side effects, so a lot of call-by-name call-sites can be memoized. Still memoization requires additional memory, eats CPU caches and when you use monads, memoization simply won't work, so common a Haskell bug is text popping on screen, long after you issued any display commands, while you will keep wondering what part of your code produced this crazy-lazy shit.

Haskell uses type tags (dynamic typing) to differentiate between fixnums and bignums, so all arithmetic operations will have to check tags. This alone sets Haskell's performance to the level of JavaScript.

Name: Anonymous 2014-05-29 19:00

>>12
The most popular Javashit interpreters have been extensively optimized. I think you might want to use another analogy, like being SLOW AS BALLS.

Name: Anonymous 2014-05-29 19:05

>>13

Unless you have a Lisp Machine or something, type-tags would still have their overhead.

Name: Anonymous 2014-05-31 10:28

>>12
Your whole post is made of bullshit. Are you sure you're a programmer?

1. Haskell does not use call-by-name evaluation, it uses call-by-need evaluation.
2. Lazy IO has been a problem long ago, now there are much better alternatives.
3. Memoization works with monads, you got something wrong on some level.
4. Haskell uses runtime tags for sum types, that's true, but "fixnums" aren't sum types.
5. Haskell can have runtime type tags if you need them, but by default types are erased, so no bad performance there.
5. It's true that Haskell numeric types are boxed by default, but you can make them unboxed by making them strict and using a compiler flag. Haskell also has unboxed mutable arrays.
6. Haskell performance has been known to reach C performance.

Name: not >>12-kun 2014-05-31 11:10

>>15
1. Haskell does not use call-by-name evaluation, it uses call-by-need evaluation.
still slow as fuck

6. Haskell performance has been known to reach C performance.
in trivial programs

Name: Anonymous 2014-05-31 11:23

>>16
There're seq, pseq and strictness annotations for such cases. No language can be only strict or only lazy and have good performance. Ultimately you need to specify the evaluation strategy for every datatype.

Name: Anonymous 2014-05-31 12:22

>>17
And lazy-by-default is a shitty default because it clashes with the I/O model, creates subtle bottlenecks and makes it harder overall to reason about performance.

Name: Anonymous 2014-05-31 13:40

>>18
A strict-by-default Haskell is definitely possible. It might even be in the works.

Name: Anonymous 2014-05-31 13:47

>>18
It does make it harder to reason about performance in general. It doesn't mess with I/O because you can be very explicit about how you want to sequence I/O, or anything else for that matter. That doesn't just apply to Haskell, you can introduce data-dependant computations (and effects) in any language as long as you can observe the result or effect somehow.

Name: sage 2014-05-31 14:03

>>19
but then why wouldn't you just use a real language?

Name: Anonymous 2014-06-01 5:42

>>8

this is what haskal /prog/rammers look like:

http://blog.sqreamtech.com/wp-content/uploads/2014/05/ori-b-2.jpg

haskal not even once

Name: Anonymous 2014-06-01 8:22

>>22
He's a wise Jewish wizard who conjures the spirits of the computer with his Haskell spells, what's the problem?

Name: Anonymous 2014-06-01 8:45

Name: Anonymous 2014-06-01 9:34

>>16
A common misconception from non-Haskellers is that Haskell, when compiled, pays an ongoing penalty for supporting laziness by default. The idea is that in a lazy language, every expression would suspend to a heap-allocated, garbage collected, thunk. Even if you were to use the variable immediately.

That sounds scarily expensive.

In the real world however, Haskell is often as not a strict language. Compiled Haskell undergoes strictness analysis which filters out the “needs to be lazy” code, from the “just do it already” strict stuff. The end result is purely functional code, written in a lazy style, that gets compiled down to raw, strict assembly, without any thunks, heaps, or GC getting in the way of raw, all out speed.

http://donsbot.wordpress.com/2008/05/04/haskell-is-a-strict-language/

Name: Anonymous 2014-06-01 9:38

>>23

Haskell programmers are not really wizards. They are atheists.

Name: Anonymous 2014-06-01 9:40

>>26
Techno-wizardry does not contradict atheism, or theism, for that matter.

Name: Anonymous 2014-06-01 9:45

>>26
PROGRAMMING IS ALL ABOUT ``ABSTRACT BULLSHITE'' THAT YOU WILL NEVER COMPREHEND

Name: Anonymous 2014-06-01 11:42

>>27
[b]False![/b]
http://en.wikipedia.org/wiki/Things_a_Computer_Scientist_Rarely_Talks_About
Knuth explores the relationships between his vocation and his faith, revealing the unique perspective that his work in computer science has lent to his understanding of God.

Name: Anonymous 2014-06-01 12:37

>>29
magic
Bible

Bible considers magic sinful. Knuth is a schizoid or an idiot. It's still possible to be a magician while being theist, but being an atheist is even less likely to contradict computer magic.

Name: Anonymous 2014-06-01 13:00

>>30
Whom are you quoting?

Name: Anonymous 2014-06-01 16:56

>>31
whom is deprecated and considered harmful

Name: Anonymous 2014-06-01 18:36

>>32
you are

Name: Anonymous 2014-06-01 19:27

>>1

tfw op has no argument

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List