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

Oh, Haskell is also not used very often for those things. It's just my (outsider) perception that Lisp programmers frequently pick on C/C++ as inferior. Haskell programmers instead ask "what can we do to make Haskell performance closer to C/C++?"

However, I am doing graphics for a living, and much of it in C++. I am sincerely interested if I can use another language to give me a higher degree of productivity and not sacrifice too much performance. Common Lisp might be able to pull this off, but it certainly is not often used in this way.

I think you'd agree it's more common for a Lisp person to ask "why do people still use these inferior languages?" rather than "how can we match the performance/scalability/parallelism of these other languages?".




C/C++ are inferior. C and C++ are very bad as a dynamic and interactive languages. C makes it hard to write secure programs and C++ is just horrible in many ways.

But C/C++ are superior as static low-level languages compared to Lisp.

The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usually statically compiled - just like C and C++. If Haskell compilers generate slower code or user code is slow, Haskell users have little excuse, only poorer tools and/or poorer code.

Lisp programmers do have an excuse, since the tools are optimized for safe execution of untyped dynamic (changeable at runtime) code. That's a completely different angle of programming. From there the Lisp compilers try to recover some speed by selectively removing dynamics and safety - where possible or needed. Lisp programmers ask themselves how to improve the compilers, but since both the application domains and the architectures tend to be different, things are hard to compare. C/C++ wins in the static performance contest. Lisp wins in the runtime flexibility contest. But those are really very different domains.

You think that Common Lisp programmers think that C is inferior. The reality is that these are completely different languages developed for different tasks with very different implementation and design decisions.

If you are a Lisp programmer, you can write graphics intensive applications in Lisp - you can also get near to C performance - but it's hard and it often is not full C performance (unless you are using specialized compilers). But still you would be very lonely (unless the company around you uses Lisp), since much of the industry uses C/C++ for graphics (from Low-level drivers to Maya).

Still many Lisp programmers, despite knowing that Lisp and C are different, try to use Lisp either alone or together with C in performance oriented domains: sound processing and image processing were and still are such domains.


The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usually statically compiled - just like C and C++. If Haskell compilers generate slower code or user code is slow, Haskell users have little excuse, only poorer tools and/or poorer code.

Obviously Haskell could improve, but can it be as fast as C? How do you shave the last bit of overhead of type safety and strictness?


I thought type safety in Haskell is a compile time thing? Where are the runtime costs?

Then I thought that non-strictness (!), non-mutability of data and referential transparency offer all kinds of possibilities for optimizations done by the compiler?

But maybe the 'interesting research' done in the Haskell community is more into fancy type system features that get the author a PhD and not so much into compiler optimizations?


Isn't the difficulty with Haskell that evaluation isn't strict? Laziness adds a lot of flexibility but there's definitely a time cost to it...




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

Search: