Em 10/04/2012 09:10, Invisible escreveu:
> Suppose, for example, that I wanted to implement a lambda expression
> interpreter.

I don't think most java programmers would want that. :p

but kudos for installing and configuring netbeans just for that... :)


> In reality, you /probably/ want to make it insert some brackets and
> stuff

you really can't spell parenthesis, huh? ;)


> , but the above is the gist of it. If we remove the "deriving"
> line, we have a total of 10 lines of code here.
>
> Now let's try the same thing in Java:
>
> public abstract class Expression {}
>
> public class Variable extends Expression
> {
> private String Name;
>
> public Variable(String n) {this.Name = n;}
>
> public String toString() {return this.Name;}
> }
>
> public class Lambda extends Expression
> {
> private String Variable;
> private Expression Body;
>
> public Lambda(String v, Expression b)
> {
> this.Variable = v;
> this.Body = b;
> }
>
> public String toString()
> {
> return "λ " + this.Variable.toString() + " → " + this.Body.toString();
> }
> }
>
> public class Apply extends Expression
> {
> private Expression LHS, RHS;
>
> public Apply(Expression l, Expression r)
> {
> this.LHS = l;
> this.RHS = r;
> }
>
> public String toString()
> {
> return this.LHS.toString() + " " + this.RHS.toString();
> }
> }
>
> If your screen is anything like mine, that lot doesn't even fit on one
> page. This is /a lot/ of code.


Java is very obviously verbose, and it doesn't help when people even go 
further and write damn "public" all over in every occasion!

class Apply?  Really?  The name itself and the behaviour conveying an 
action shouldn't be best served as methods of Expression?


> And yet it doesn't even "do" anything, as
> such. It just lets you construct data structures, and print them out.
> The same thing as the 10 lines of Haskell code did. I count 44 lines.
> Or, if you're feeling generous, 36 non-blank lines. And I even tried to
> scrunch Lambda.toString() onto one line, even though it's really too big.

Now try to write an object system in haskell.


> Now suppose that, for some strange reason, I want to be able to check
> whether two expressions are the same. (Realistically, I can't think why
> you'd want to do that for anything except variables.) In Haskell, I can
> simply append "deriving Eq", and the compiler will write the code for me
> in the obvious way. In this instance, it does the right thing. In
> Java... well OK, I'll go easy on Java and only write the code for
> Variable. Here goes:
>
> public class Variable extends Expression
> {
> private String Name;
>
> public Variable(String n) {this.Name = n;}
>
> public String toString() {return this.Name;}
>
> public boolean equals(Object obj)
> {
> if (obj == null) return false;
>
> if (obj instanceof Variable)
> {
> Variable v = (Variable) obj;
> return this.Name.equals(v.Name);
> }
>
> return false;
> }
>
> public int hashCode() {return this.Name.hashCode() + 9;}
> }
>
> OK, so only 14 lines of actually new code. The hashCode() override is
> not /strictly/ necessary, but the IDE whines like hell if you don't, and
> it's highly likely that you're going to put variables as keys into a
> HashMap at some point, in which case hashCode() had better work correctly!
>
> In Haskell, you can simply say
>
> e `equals` f =
> case (e, f) of
> (Variable x, Variable y) -> x == y

as far as I can tell, this is not the same code as the java one:  you're 
not checking here if the variables have the same name too, only if they 
are instances of the same type.

>
> and you're done.
>
> In Java, you have to check whether the argument is null. (Impossible in
> Haskell.)

it's about the same as checking for an empty list.

BTW, that check could be at the base class in an ancestor method.  But 
you wrote it as abstract for whatever reason...


> You have to check whether the argument is of a comparable
> class. (Haskell's static type checking does that for you at
> compile-time. Actually Java's generics could do that too if they
> extended it a teeny weeny bit... but they haven't.)

I'm sorry, but if you wanted at least some type checking in java, 
shouldn't you do:

public boolean equals(Expression obj)

instead of

public boolean equals(Object obj)

?

The compiler then would warn you whenever you passed something like 
exp.equals(2) (which, yes, reads kinda weird since a number literal like 
that should be an expression after all).  Then again, even as is it 
already should warn you, since it expects an instance of Object...


> In consequence to the above, I just spent an entire morning coding in
> Java, and all I actually have to show for it is a boat-load of classes
> which can hold data and generate a graphical representation of
> themselves. They have no actual /behaviour/ yet. It's taken me this long
> just to do that... Man, Java is a blunt knife! (But oh so hard to hurt
> yourself with... yeah, right!)

all in all, it read like object oriented code from a C programmer...

now, I'm not a java programmer nor enjoy it.  But people frequently 
enjoy making it sound actually worse than it is.

Post a reply to this message