Re: [9fans] nice quote

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2988 bytes --]

On Sat, Sep 5, 2009 at 6:58 PM, Jason Catena <jason.catena@gmail.com> wrote:

> Hailed Eris:
> > I was alluding to the expressive power of C versus LISP considered with
> > respect to the primitives available on one's computing platform and
> > primitives in which solutions to one's problems are best expressed.
>
> I think one of the reasons there exists little languages, and cliches
> such as "the right tool for the job", is that the "primitives
> available on one's computing platform" are very often not the
> "primitives in which solutions to one's problems are best expressed."
> In this respect rating the "expressive power of C versus LISP" depends
> very much on the problem domain under discussion.
>
> For "systems programming", C has the advantage in both practice (use
> in running systems) and theory: processes which take a lot of system
> resources to execute also tend to take a lot of C code, whereas in
> most higher-order languages, things which represent high-level
> runtime-consuming abstractions tend look little different than simple
> bit-level operations.  The difference is one of approach, I guess:
> whether you want to write optimal code yourself, and see what the
> machine is doing, or trust the compiler to find a good way to
> translate to machine language and run (in real-time) your
> efficient-to-code higher-order functions.  The better the translation
> from the higher-level language, the more this difference becomes a
> matter of taste, programming style, availability of programmers, and
> the body of domain knowledge already represented in language
> libraries.
>
> I would like to see Haskell fill C's niche: it's close to C's
> execution speed now, and pure functions and a terse style gives real
> advantages in coding speed (higher-order functions abstract common
> "patterns" without tedious framework implementations), maintainability
> (typeclasses of parameters in utility functions means you don't write
> different implementations of the same function for different types,
> yet preserve type compatibility and checking), and reliability (pure
> functions don't depend on state, so have fewer moving parts to go
> wrong).
>
>
Well I can think of 3 operating systems written in Haskell now.  One was an
executable specification for validating a secure L4 implementation.  One is
hOp, and then there's also House, based on hOp.

There's also Kinetic, written primarily in Haskell.
http://www.ninj4.net/kinetic/

The newest fork of House has TCP/IP networking uhm working.
http://web.cecs.pdx.edu/~kennyg/house/

There is a haskell file system in development too now
http://www.haskell.org/halfs/, but a lot of links don't work :-).

I've been writing a good bit of Haskell these days at work as well, mainly
due to the fact that it's possible to write some fairly sophisticated code
quickly, and even get pretty darned good performance out of it.



> Jason Catena
>
>

[-- Attachment #2: Type: text/html, Size: 3874 bytes --]