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

Pages: 1-

Non-Lisp languages

Name: Anonymous 2013-08-27 9:29

What's the best among them and by best I mea least shit.

Name: Anonymous 2013-08-27 9:49

Ruby

Name: Anonymous 2013-08-27 9:50

Perl6

Name: Anonymous 2013-08-27 10:36

Node

Name: Anonymous 2013-08-27 10:42

Java

Name: Anonymous 2013-08-27 10:46

Fjölnir

Name: Anonymous 2013-08-27 10:52

>>5
Java IS shit.

Name: Anonymous 2013-08-27 11:07

C.

Name: Anonymous 2013-08-27 11:10

>>7
C++

Name: Anonymous 2013-08-27 11:20

>>9
Even worse

Name: Anonymous 2013-08-27 12:51

D

Name: Anonymous 2013-08-27 12:55

There are no languages except GNU / Lisp.
GNU / Lisp is the only language.

Name: haskeλλ 2013-08-27 13:31

Name: Anonymous 2013-08-27 20:07

Haskell

Name: Anonymous 2013-08-27 20:11

Gaelic

Name: Anonymous 2013-08-28 1:17

Name: LISP 2013-08-28 1:18

LISP

Name: Anonymous 2013-08-28 1:23

>>13
http://engineering.linkedin.com/49/linkedin-coding-competitions-graph-coloring-haskell-c-and-java

One team used Haskell to implement the algorithm found in "3-Coloring in Time O(1.3289^n)". Specifically, the solution implemented covered the CSP transform and the CSP algorithm. It did not cover the graph preprocessing simplification steps. Getting the algorithm to work correctly proved to be very time consuming. By the time they got it working, the team only had time to try a few simple unit tests before submitting. You can play around with the code here.
Theoretically, with a worst-case run-time of O(1.32^n), we expected the Haskell solution to outperform the two other solutions, which used O(2.45^n) greedy algorithms. In reality, the Haskell team stumbled out of the gate: on small graphs, performance was poor, possibly due to some sort of Haskell overhead. For the larger graphs, the implementation tended to run out of memory or hit stack overflows. Perhaps if they had more time and test code, they could've caught these problems earlier, but as it is, the Haskell code lagged far behind the Java and C++ solutions, which are so much faster that they are barely visible on this chart: (...)

Name: Anonymous 2013-08-28 1:27

>>18
the implementation tended to run out of memory or hit stack overflows.
B-but muh recursion. It's beootiful and elegant

Name: Anonymous 2013-08-28 1:30

>>19
back to /g/

Name: Anonymous 2013-08-28 1:31

>>18
It's nice to see Haskellfags get smacked down (see http://jacquesmattheij.com/when-haskell-is-not-faster-than-c ), but to be honest, I'd be more inclined to blame the developers than the language in that situation, and certainly with such a small sample size. Otherwise, I'd be no better than the Enterprise Java managers who replace 25-year industry veterans with college grads and expect equivalent output.

Name: Anonymous 2013-08-28 1:58

Haskell is a language where strings are essentially garbage-collected
struct string {
     wchar_t *(*head)(void*);
     struct string *(*tail)(void*);
} *(*string)(void*);

and people are concerned with performance?
Actually it's more complicated than this because the functions are in CPS, strings are a boxed type so there's a tagged union to tell whether the character is a value or a thunk, anything could throw an exception, and there are probably more things I forgot about.

Name: Anonymous 2013-08-28 7:51

>>22
oh for fuck's sake, you'd think it'd have a decent optimizer considering half of your code is type information

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