Things I miss since learning O'Caml

[wtd]

I learned O'Caml, but I miss some things about Java/C++...

• I miss braces.
  
  I miss having to enclose all of my functions and method bodies in braces, even if they're only composed of single expressions.
  
  

  code:

  void foo(int bar) {    printf("%d\n", bar); } ------------------------------ let foo bar =    printf "%d\n" bar

  
  
  
• I miss "return."
  
  I miss having to use return, even with really simple functions and methods.
  
  

  code:

  int foo(int bar) {    return bar + 1; } ------------------------------ let foo bar = bar + 1

  
  
• I miss preprocessor guards.
  
  I miss having to use the preprocessor to protect against multiple inclusion of header files. O'Caml's module system is no replacement at all.
  
  

  code:

  #ifndef __FOO_H #define __FOO_H void say_hello(); #endif ------------------------------ module Foo = struct    let say_hello = print_endline "Hello!" end

  
  
• I miss control statements.
  
  I liked having to create a variable, then assign to it within a control structure. Having control structures that return values just messes with my mind, and I don't like my programming languages trying to outsmart me. I should be the one in control.
  
  

  code:

  public class Test {    public static void main(String[] args) {       int a;                      if (args.length > 0) {              a = Integer.parseInt(args[0]);           } else {              a = 0;           }                      System.out.println(a);    } } ------------------------------ let a = if Array.length Sys.argv > 0 then    int_of_string Sys.argv.(0) else 0;; Printf.printf "%d\n" a

  
  
• I miss getting away with incomplete conditionals.
  
  O'Caml actually refuses to compile my code if I've not handled some possibility in my conditionals. It's incredibly frustrating. I just want my code to compile. I don't care if I've missed an obvious source of error.
  
  I'll find out about it when my code produces weird runtime errors. They make for interesting challenges.
  
  

  code:

  public class Test {    public static void main(String[] args) {       int a;                      if (args.length > 0) {              a = Integer.parseInt(args[0]);           }                      System.out.println(a);    } } ------------------------------ (* Doesn't compile. *) let a = if Array.length Sys.argv > 0 then    int_of_string Sys.argv.(0);; Printf.printf "%d\n" a

  
  
• I miss explicit types.
  
  I miss writing out the types of variables, return values, and parameters. It gave me the chance to essentially document my code. And no, I do not buy the explanation that you can load up a module in the interpreter and quickly find out the types involved.
  
• I miss non-named parameters.
  
  I liked having to remember the order function parameters occur in. It was a great sense of achievement. Yes, O'Caml has positional parameters, but it doesn't force me to use them, sadly.
  
• I miss contructors.
  
  I miss having to explicitly set up the initial state of objects. O'Caml's method of doing this is just too easy for the amount of work being done. I dislike it when the power of code, and the difficulty in writing it are not proportional.
  
  

  code:

  class Foo {    private String a, b;        public Foo(String a, String b) {       this.a = a;           this.b = b;    }        public String toString() {       return a + " " + b;    } } ------------------------------ class foo a b = object    val mutable a = a    val mutable b = b    method to_string = a ^ " " ^ b end

  
  
• I miss null.
  
  I miss having to wonder if a parameter is actually an object at all.
  

[[Gandalf]]

Lies, I say!

No, but it's an interesting comparison. If only O'Caml wasn't so brain melting.

[wtd]

[Gandalf] wrote:

Lies, I say!

No, but it's an interesting comparison. If only O'Caml wasn't so brain melting.

How so?

[OneOffDriveByPoster]

wtd wrote:

I miss control statements.

I liked having to create a variable, then assign to it within a control structure. Having control structures that return values just messes with my mind, and I don't like my programming languages trying to outsmart me. I should be the one in control.

code:

public class Test {    public static void main(String[] args) {       int a;                      if (args.length > 0) {              a = Integer.parseInt(args[0]);           } else {              a = 0;           }                      System.out.println(a);    } } ------------------------------ let a = if Array.length Sys.argv > 0 then    int_of_string Sys.argv.(0) else 0;; Printf.printf "%d\n" a

Let's have something else...

Java:

public class Test {     public static void main(String[] args) {         int a = args.length > 0 ? Integer.parseInt(args[0]) : 0;         System.out.println(a);     } }

[md]

Methinks people are missing the point... this was sarcastic...

Though I do like the idea of return. Explicitly returning something is nice... what if I want to add one to bar, and do nothing else, but not return bar+1? This could be the case where code is commented out to test something else...

[[Gandalf]]

Cornflake wrote:

this was sarcastic...

Yes...

wtd wrote:

How so?

Mostly because my brain is frozen in imperative programming mode. It's a slow process to change.

[wtd]

Cornflake wrote:

what if I want to add one to bar, and do nothing else, but not return bar+1? This could be the case where code is commented out to test something else...

You have two problems there.

In one case, you're returning void. In another, you're returning int. O'Caml is statically-typed, so this is no good.

The other problem is that you're counting on bar being mutable. Values in O'Caml are by default immutable. This leads to more optimization, and not less, by the way.

[wtd]

OneOffDriveByPoster wrote:

Let's have something else...

Java:

public class Test {     public static void main(String[] args) {         int a = args.length > 0 ? Integer.parseInt(args[0]) : 0;         System.out.println(a);     } }

There's that, but it doesn't scale well. And why have two different constructs for the same concept? Java is supposed to be about not reinventing the wheel, right?

[Cervantes]

It seems odd that if the ternary operator can return a value, why can't an if-construct?

[OneOffDriveByPoster]

wtd wrote:

I miss getting away with incomplete conditionals.

O'Caml actually refuses to compile my code if I've not handled some possibility in my conditionals. It's incredibly frustrating. I just want my code to compile. I don't care if I've missed an obvious source of error.

I'll find out about it when my code produces weird runtime errors. They make for interesting challenges.

code:

public class Test {    public static void main(String[] args) {       int a;                      if (args.length > 0) {              a = Integer.parseInt(args[0]);           }                      System.out.println(a);    } } ------------------------------ (* Doesn't compile. *) let a = if Array.length Sys.argv > 0 then    int_of_string Sys.argv.(0);; Printf.printf "%d\n" a

code:

Test.java:9: variable a might not have been initialized         System.out.println(a);                            ^ 1 error

[wtd]

Thanks for pointing that out.

[rizzix]

Cervantes wrote:

It seems odd that if the ternary operator can return a value, why can't an if-construct?

If constructs are statements in Java, whereas the ternary operator is an expression.

Unlike ruby blocks/statements in Java can not return values, unless they are defined to do so (and if they are, you must explictly return a value).

[wtd]

rizzix wrote:

Cervantes wrote:

It seems odd that if the ternary operator can return a value, why can't an if-construct?

If constructs are statements in Java, whereas the ternary operator is an expression.

Unlike ruby blocks/statements in Java can not return values, unless they are defined to do so (and if they are, you must explictly return a value).

Oh, I think we're all pretty well aware that is how Java works. Cervantes' question was not "how" but rather "why?"

[Cervantes]

Indeed. I understand that Java's if constructs are statements and not expressions. I'm just saying, y'know, it sucks.

[rizzix]

Java likes to make a clear distinction between expressions and statements? gee..