What is hard in Java but easy in Scheme?

Question

These two languages are very different. They're each well-suited to their own particular tasks. What tasks are easy to do in Scheme, yet are hard / require lots of ugly code to do in Java? Another way of putting it: what is Scheme better at?

If you can think of things that Java is better at, see this question.

Answer 1

Function objects

Scheme has first-class functions, in the form of lambdas. Java does not, so in order to pass around functions or define anonymous inline functions, you need to define a new class or interface and then subclass it. Even with anonymous subclasses, it's still a bit of a pain:

# Scheme: sort in descending order with a custom comparator
(sort '(3 1 4 2) (lambda (x y) (> x y)))  # close ' to un-confuse source colorizer

// Java: call a sort function with a custom comparator
Integer[] array = new Integer[]{3, 1, 4, 2};
Arrays.sort(array, new Comparator<Integer>()
    {
        public int compare(Integer i1, Integer i2){
        {
            return i1 > i2;
        }
    });

Answer 2

I suppose anything that had to do with continuations. A good example is On Lisp style nondeterminism. Basically you provide several different possible choices to the choice function. If at any point you are able to determine that the choice made is incorrect, you call fail and another choice is made. What's great about this is that it restores the state of the stack at the exact time the choice is made, so you don't have to worry about backtracking at all - the end result is a program that chooses the correct choice every time seemingly by magic.

This would be quite difficult to implement in Java as seamlessly as Scheme because as far as I know Java does not provide any facilities for saving and restoring its runtime stack. In fact, I'm not sure how you'd do this at all in Java save for manually keeping your own stack at every step.

edit: Here's an implementation in Scheme:

(define *paths* ())

(define (choose choices)
  (call-with-current-continuation
   (lambda (cc)
     (set! *paths*
           (append *paths*
                   (map (lambda (choice)
                          (lambda () (cc choice)))
                        choices)))
     (fail))))

(define (fail)
  (if (null? *paths*) 'fail
      (let ((p1 (car *paths*)))
        (set! *paths* (cdr *paths*))
        (p1))))

Answer 3

Writing a Scheme interpreter

Answer 4

Tail call optimization, Java does not even support it in the JVM's bytecode (which is a roadblock for Clojure with respect to the goal to bring Lisp power to the JVM, by the way).

Answer 5

Integrating new functionality as if it were syntax - here's parallel OR (excerpted from here):

(define-syntax por
  (syntax-rules ()
    ((_ x ...)
     (first-true
       (list (make-engine (lambda () x)) ...)))))

(define first-true
  (lambda (engs)
    (if (null? engs)
        #f
        ((car engs) 1
          (lambda (ticks value)
            (or value (first-true (cdr engs))))
          (lambda (eng)
            (first-true
              (append (cdr engs) (list eng))))))))

Answer 6

Well, being in the refactoring business myself:

handling code (analyse, rewrite, macro-expand, automatic refactoring and all the rest) is very hard in Java. Having code-as-data around (or the same format for it) as in Lisp definitely helps a lot with all this. Actually, not having ANY syntax is pure fun when doing this.

This of course includes "self modifying code", which sounds bad first, but is just another phrase for "learning".

regards

PS: so its not a surprise, that many language processing systems use Lisp or a Lisp-like representation internally...