Re: [tlug] recomendations for a functional language

[Curt Sampson <cjs@example.com>]

On 2009-11-04 22:11 +0900 (Wed), Jianshi Huang wrote:

> Could you elaborate why haskell's type system make STM practical?
> 
> For me it's haskell's purify, since the efficiency of STM largely
> depends on whether you can successfully partition the data to avoid
> conflicts.

Correct: control of state. In C it's very difficult to partition the
data that are controlled by STM and the data that are not; in Haskell
it's trivial to keep the STM data from escaping into the non-STM part of
the program. The reason for the partition is that putting *all* of the
data in your program under STM control is enormously inefficient; you
really want to use STM on the smallest possible set of data.

> Why not [learn] both [Scheme and Haskell]? Macros is a reason good
> enough.

Well, what a macro is and how it works is not hard to understand;
I think that most programmers probably already have this level of
knowledge. The next step up, I imagine, is not just learning how to
write a macro or two in Scheme or Lisp, but actually programming in the
large with macros: spend a year coding a reasonably large project that
uses them well, and see how having them makes a difference. That's a
pretty big investment, and I think you'd get more out of a year with
Haskell simply because, though there are no macros, there are many, many
other concepts, most of which people don't even understand the basics of.

> And there's first class continuations. Actually Scheme is a
> very low-level language for understanding how to program, which could
> be as enlightening as Haskell.

Sure, but Haskell has the continuation monad in the standard library,
too, and the advantage that you can write these sorts of things yourself
fairly trivially if they're not present.

> Wrong. Haskell is too far from Lisp.
> 
> 1) Lisp is all about macrology.

True; Haskell is not, though it does provide other tools to produce a
language of equivalant power.

> 2) Lisp is dynamic and all the reflexive.

Haskell supports this, too, through things like the Data.Dynamic
library. We don't use it all that often because it's just not needed as
much.

> 3) Lisp is about incremental development.

I would say that Lisp is "better" in certain ways at incremental
development than Haskell in the way that any dynamically typed language
is, with the ability to have parts of your system blatently incorrect
and still run. But, though this takes some getting-used-to

> 4) Lisp is about hooking to the compiler and runtime.
> which I don't think any of the Haskell implementation focuses on currently.

I'm not clear on what you mean by this. Certainly in Haskell you have
a fair amount of access to the compiler and runtime, and can even do
C-like things, especially with the FFI.

> > With dynamic typing, if you make a mistake, you have a failure at
> > runtime. Static typing systems offer a computer-verified proof that
> > certain types of failures cannot happen at runtime....

> It still can fail. ex. stack overflow is a common mistake.

Sure. Notice that I said "certain types of failures." I don't claim that
good static typing systems eliminate all run-time failures, just more
than dynamic typing systems do, when used correctly.

> Holding but not releasing resources is another. And deadlocks.

Actually, a good static typing system can help with both of these. For
example, in Haskell's FFI, the type system is used to ensure that some
dynamically allocated memory is deallocated, and the memory is not
referenced after deallocation.

> Though I agree Haskell's type system eliminates a large proportion of
> errors.

How large depends, but I think we may be in violent agreement here.

> I think that's why people using dynamically typed languages tend to
> prefer TDD and defensive programming.

Indeed. Static type system users use "defensive programming," too, by
creating new types that let us do checking at compile-time to ensure
that functions can be given values only within the range that they're
able to deal with.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com