Live data from Hacker News

Lisper's first look at Haskell

tourdelisp.blogspot.com

31–40 of 40 posts

Re: Lisper's first look at Haskell

#31
post #29

I often find myself wishing for a combination of the two languages. An S-Expression based Haskell-alike instead of an S-Expression based Python-alike (yes, yes I know - Lisp came first - whatever ). Bonus points if I can drop into an S-Expression based Fortran-alike when bashing on a chunk of memory is the only way to do something fast. I like macros, but, as a scientific programmer, I know the type of everything in…

Racket has a lazy module that can let you have lisp+laziness. There's also typed scheme which lets you do lisp+types. Now if only someone could make a lazy typed racket.

Yeah, I've been more of a racketeer than a lisper of late. I like their 'batteries included' philosophy.

I don't much like the macro system, though.

I might check out typed racket. I don't care too much about lazy evaluation one way or the other, long as all my doubles get multiplied, added, and divided, and it happens fast.

Re: Lisper's first look at Haskell

#32
post #29

Earlier quoted context omitted.

Racket has a lazy module that can let you have lisp+laziness. There's also typed scheme which lets you do lisp+types. Now if only someone could make a lazy typed racket.

Yeah, I've been more of a racketeer than a lisper of late. I like their 'batteries included' philosophy. I don't much like the macro system, though. I might check out typed racket. I don't care too much about lazy evaluation one way or the other, long as all my doubles get multiplied, added, and divided, and it happens fast.

Well, just as general advice, the fastest way to multiply your doubles is to use single-precision SIMD. Does it do that?

Re: Lisper's first look at Haskell

#33
post #30

Earlier quoted context omitted.

First off, you generally want code to read as much like logically valid relations as possible. A major strength of Prolog is that "clean" Prolog code is extremely easy to reason about with only local context. Chcek out _Clause and Effect_ by Clocksin and _The Art of Prolog_ by Sterling and Shapiro. CAE is sort of like _The Little Schemer_ for Prolog, but has a couple larger case studies as well. TAoP is one of my abs…

> "It's a bit awkward as a fully standalone language, since things like IO don't always mix with backtracking. It's great as a rule engine, though, and would probably also be brilliant as a query language for a document-oriented database." Fully agree. I'm learning prolog too, and it's really fantastic for the types of problems it was designed (e.g. resolving constraints and expressing relations), but I didn't enjoy…

I would love to write a Prolog dialect designed primarily for embedding, much like Lua. I just have a half dozen other serious projects I should wrap up first. :/

Re: Lisper's first look at Haskell

#34

Earlier quoted context omitted.

Yeah, I've been more of a racketeer than a lisper of late. I like their 'batteries included' philosophy. I don't much like the macro system, though. I might check out typed racket. I don't care too much about lazy evaluation one way or the other, long as all my doubles get multiplied, added, and divided, and it happens fast.

Well, just as general advice, the fastest way to multiply your doubles is to use single-precision SIMD. Does it do that?

Huh? Double precision SIMD? SSE2 instructions aren't slower than SSE.

Re: Lisper's first look at Haskell

#35
First thanks to everybody for reading my posts. Currently I'm using regularly common lisp, java, c#,c/c++ and SQL. I bought Programming Clojure & Practical Clojure and went through them. I would have bought both Clojure in action and Joy of Clojure (written by starter of this thread fogus) if Manning accepted credit card payment from Macedonia. I'm little tired of everything Java related, that includes Clojure, so I'm using my spare time to learn OpenCL. Regarding Haskell. I haven't programmed in it since I wrote the post farewell haskell. The reason for that is my programming style for which Haskell is ill suited which described in the farewell haskell post in the paragraph starting with: It may interest you to know that most of my development .. http://tourdelisp.blogspot.com/2008/03/farewell-haskell.html I don't hate Haskell but its not in list my favorite language either() though as one favoring functional style I cheer news like this http://bit.ly/djs4J5. Also I prefer to say what I'm thinking and be rude if necessary then hide my message between being politically correct watered down politician talk. On the other hand I have high opinion about SPJ and enjoy his talks http://bit.ly/4BG5Dp and many of his papers. In the end language wars are pointless, use the language that suits yourself and have a marry hacking.

() For those interested my favorite languages are lisp dialects (cl,scheme and clojure), array languages (j & q), Prolog, Erlang and concatenative languages (Factor, Cat & Joy)

Re: Lisper's first look at Haskell

#36

"Static typing sucks. It reminds me of the dark ages of programming in the c family of languages. " If working in Haskell reminded him of C (and the post is full of rubbish like this [1]), I'd imagine he didn't understand Haskell at all . This is on the order ranting about how lisp is sucky because of "all those parantheses". "And don't even dare to mention Emacs, a lot of people don't like it.It's 2008 and creating…

Emacs is used by many lispers but not all of them.The most famous non Emacs lisper is Paul Graham. I don't mind using Emacs and Slime on Linux but for a visual type of person they suck compared to modern IDE's. I rely a lot on visual clues and speedbar is a poor man alternative. Franz and Lispworks are making good ides and many commercial organizations are buying and using them. The implementations you mentioned are all open source and don't have resources to develop proper IDE since there is no big company to back them up, such as IBM financing eclipse. So they choose proper course of action of improving their implementations with Emacs + SLIME as their programming environment.

Re: Lisper's first look at Haskell

#37
post #23

Hogs a lot of brain resources. It's syntax is complex, and ...(snip)...forces me to spend more resources on dealing with language than with dealing with the problem. I love lispers. I always learn something from their writings, and generally admire their prose. There seems to be some correlation between deftness of expression in fingernail-clipping languages and deftness of expression in English. I don't quote the ab…

ah. To pick on a non-native English speaker's English language prowess - very brave indeed.

Re: Lisper's first look at Haskell

#38
post #37
post #23

Hogs a lot of brain resources. It's syntax is complex, and ...(snip)...forces me to spend more resources on dealing with language than with dealing with the problem. I love lispers. I always learn something from their writings, and generally admire their prose. There seems to be some correlation between deftness of expression in fingernail-clipping languages and deftness of expression in English. I don't quote the ab…

ah. To pick on a non-native English speaker's English language prowess - very brave indeed.

I wasn't picking on his language prowess at all. Quite the opposite: I delighted in reading his post. The contrast that I find amusing is that, so often, those who decry the syntactic complexity of non-lisp programming languages never seem to have any problem at all with the syntactic complexity of English. If complex English syntax doesn't get in the way of expression, why insist that it is such a cognitive burden to have to have to worry about something other than s-expressions?

Re: Lisper's first look at Haskell

#39

Earlier quoted context omitted.

Well, just as general advice, the fastest way to multiply your doubles is to use single-precision SIMD. Does it do that?

Huh? Double precision SIMD? SSE2 instructions aren't slower than SSE.

No, single precision, as in "the fastest way to multiply a double is to use floats instead". I've seen more than enough C programs unnecessarily using double that I wish floating point constants would just be float by default.

(Although it seems like clang does something special here, as I don't see many double-to-float conversions in its output.)

Re: Lisper's first look at Haskell

#40

Earlier quoted context omitted.

Huh? Double precision SIMD? SSE2 instructions aren't slower than SSE.

No, single precision, as in "the fastest way to multiply a double is to use floats instead". I've seen more than enough C programs unnecessarily using double that I wish floating point constants would just be float by default. (Although it seems like clang does something special here, as I don't see many double-to-float conversions in its output.)

Then you aren't multiplying doubles, it would be a shame to get a completely wrong answer on an ill-conditioned problem because the implementation disregarded the spec, cf. "the fastest way to process UTF-8 is to truncate it to ASCII", "the fastest RSA encryption is ROT-13". Also note that floats are only faster with packed instructions (often not possible without changing APIs) or when memory bandwidth is an issue.
Post reply on HN