What's with unorganized code?

General Discussions
#41

Don’t make up your own wacky name. It’s a Vec3i. Or a Point3i.

You probably should use one of the zillions of existing classes rather than rolling your own, unless you’re doing your own engine.

This code highlights Java’s flaws in making something so simple, so verbose and filled with lots of details that distract from it’s function. Look at the Scala version:


case class Vec3i(val a1: Int, val a2: Int, val a3: Int)

Or the Haskell version:


data Vec3i = Vec3i Int Int Int deriving (Show)

Such a simple type should really be a one-liner.

#42
  • The Scala and Haskell versions in my previous post are way more concise. One line rather than a bulky 5.
  • Even in Java, I would write that much more concise. Use immutable final fields and don’t bother with getter functions.

    public class Vec3i {
        public final int a1, a2, a3;

        public Vec3i(int a1, int a2, int a3) { this.a1 = a1; this.a2 = a2; this.a3 = a3; }
    }
  • The C# version has the disadvantage of being mutable and having really obscure rules around that. C# architect says that this was a mistake in the language: http://blogs.msdn.com/b/ericlippert/archive/2008/05/14/mutating-readonly-structs.aspx
  • C# has internal efficiency advantages with structs over Java, Scala, and Haskell.
  • Java 9 will have proper value types in Java, that are fully immutable and runtime efficient. I’m sure Scala will take advantage of this.
  • Haskell has newtype and Scala has it’s single field value types, but those are limited to single fields. JDK 9 will be better.
#43

Immutable is overrated for hard/soft realtime and system programming. In many languages you don’t even need to define a type for this.

#44

Overrated? There are several advantages and zero drawbacks.

Many languages will let you use a tuple… A simple type is appropriate in a statically typed language. And ideally, it’s a single line like Scala/Haskell/others.

#45

Zero drawback? How it’s required to be lowered = large drawback. And yes, a tuple shouldn’t require any type definition.

#46

I don’t comprehend “How it’s required to be lowered = large drawback”

On second thought, a tuple with an optional type alias is a better choice than a distinct type.

Scala


// Alias to tuple
type Vec3i = (Int, Int, Int)
// Function
def addVec3i(v1: Vec3i, v2: Vec3i) = (v1._1 + v2._1, v1._2 + v2._2, v1._3 + v2._3)
// Example usage
addVec3i((1,2,3),(5,5,5))

Haskell


-- Alias to tuple
type Vec3i = (Int, Int, Int)
-- Function
addVec3i :: Vec3i -> Vec3i -> Vec3i
addVec3i (x1, y1, z1) (x2, y2, z2) = (x1 + x2, y1 + y2, z1 + z2)
-- Example usage
addVec3i (1,2,3) (5,5,5)
#47

It means you’re not thinking low-level and what must happen with immutable types.

#48

I’m gonna hop in as a haskell fanboy (for / right now).

I’m not going to say that Immutability is THE thing, but in the general case it has proven itself to be working good enough and with a lot of advantages in functional languages.

The nice thing about haskell is also not that it’s only got immutable data, because it hasn’t. Things that work better with mutability can use gems like ArrayST, which is still type-safe because of nice abstractions.

(Clearly I think that haskell’s strong and almost-pure type system is the nice thing about it. Monads ruuule :stuck_out_tongue_winking_eye: )

#49

No comment on Haskell. It just isn’t suited for system programming. That whole hammer/nail meme thing.

#50

No comment on Haskell? Followed by a comment on Haskell?

Java + Scala probably aren’t suited for real systems programming either. All three are more for applications programming + server programming.

There are definitely advantages to mutability for certain data structures, and while I love Haskell and its extreme immutability, I’m not arguing that that is always the best tool. But for a three integer tuple, I see a completely pareto improvement for immutability with zero drawback.

#51

I’m the only one here that organize the code like this:


public void method()
{
  //stuff
}

and not like this:


public void method(){
 //stuff
}
#52

Nope.

#53

Are you being serious or just purposely obtuse?

No argument. The JVM doesn’t give the needed tools.