Hacker News new | past | comments | ask | show | jobs | submit login

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 my program (double-precision floating point numbers and aggregations thereof), and I don't want to play some guessing game where I figure out which types I have to declare to get something to run fast. Same with garbage collection (what! the GC might move this while LAPACK bashes on it? I need to explicitly tell it not to? Fuck!).

emacs + paredit is also the best structured editing tool I have used in any language.




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?


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: