Comment by lispm | Hacker News Reader

Comment by lispm | Hacker News Reader

Parent Full thread

Many have been done.

ICAD has been written in Lisp and many turbines of several commercial aircrafts have been designed with it.

CDRS was the conceptual design and rendering system, written by Evans & Sutherland in Lisp. Many cars from Ford and Jaguar have been designed with it. It was then taken over by PTC and sold as Pro/Engineer Designer.

Mirai is a 3d graphics tool used for example to create the animations of Gollums's face in Lord of the Rings. Earlier versions of this software have been used for animation films and many computer games, for example by Nintendo to design the 3d worlds. There were other uses of this software, for example the Orca in 'Free Willy' was animated with it.

Here is a screenshot of Mirai: http://lispm.dyndns.org/lisp/pics/Mirai-P5-Paint-Front.jpg

Let us know when there is a similar Haskell app that supports 2d+3d painting, 3d modelling, 3d animation, 3d rendering, 3d motion editing, etc. in a nice application for, say, SGIs or Windows machines - then show how to script it in Haskell at runtime.

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?

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...

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?

Reply on news.ycombinator.com