[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the benefits of immutability

Quoting Jakub Travnik <J.Travnik@sh.cvut.cz>:
> From: vkarvone@mappi.helsinki.fi:
> > public class FunctionalJava [...]
> Sorry, your program is too complex (contrary to original version in
> lisp) to be written without errors.

I noticed the bugs as soon as I actually compiled and ran the code. The
second version I sent, used some "syntactic sugar" for function application
(the static apply() method) and also the binary function COMPOSE was
implemented as a function that returns a function.

> toString is particularly bad example since toString conversion is what
> Java does anyway.

I guess you mean with respect to the println in the main method. Yes, I
agree, but the use of toString was requested in the original "challenge" and
I was too lazy to make a more appropriate example (e.g. demonstrating that
the result is a string).


I have previously used similar techniques (using anonymous classes to
represent functions) in Java to implement higher-order functions for
manipulating Collections, ResultSets, etc... And I think that compared to
writing the same things using (nested) for/while/etc... loops the code isn't
that bad. The nice thing is that you can then eliminate variable
declarations and it is easier to compose complex processes out of simple
building blocks.

Personally, I'm not very fond of Java. If I'd have to choose, my language
preference would be Scheme, because it is so easy to emulate other languages
in Scheme (for example, I recently wrote syntax-case macros that perform
(somewhat simplistic) ML-style type checking of restricted Scheme code).
Scheme isn't perfect, though. I think that *core* Scheme's semantics related
to parameter lists are too complex (look at the denotational semantics in
Queinnec's LiSP, for example). I also think that the standard syntax-rules
macro system is too complicated and too weak (Yes, I know about CPS style
syntax-rules macros in Scheme). As a third problem in Scheme (and most other
GC-languages), the lack of any sort of (or good enough) guarantee for soft
real-time / incremental behaviour of GC makes (standard) Scheme (and every
Scheme implementation that I know at that detail level) unsuitable for many
kinds of programming that I have been involved in (interactive games).

  Vesa Karvonen