Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

Is it just me - but writing correct and clear code depends less on the language and more on the problem being solved and the domain - and ones understanding of both.

Someone with a detailed grasp of both can write clear code in C, Haskell, Python even BASIC

If you don't grasp either and have no time to be allowed to do it, no language will save you.

View on HN

Given a certain level of understanding of the problem, certain languages can make it easier to write clear and correct code. For example, code that does physics or 3D graphics calculations is clearer in a language that can represent matrices and vectors as types providing the expected operations (e.g. C++ over C) and if the code involves physical quantities it can be easier to enforce correctness in a language that supports units in the type system.

Agree. This is one of the reasons that Fortran remains popular for scientific computing:

* dead-simple array/vector operations (http://www.mathcs.emory.edu/~cheung/Courses/561/Syllabus/6-F...)

* many useful built-ins (e.g., DOT_PRODUCT, MAXVAL/MAXLOC, MATMUL, TRANSPOSE)

* standard math libraries (e.g., LAPACK) with lots of very fast functions for linear algebra

This. I hate this relativism about the merits of languages. There's an entire field of study dedicated to that and just because you can write a web app in all your languages of choice doesn't actually invalidate the vast conceptual differences that exist and have real effects on how you program

what field of study?

Programming Language Theory

Both C and C++ can represent matrices and vectors as types with related operations. In my view, the key difference between these two languages is RAII.

but only C++ allows you to write `c = a * x + b` instead of

    mat a, b, x, tmp, c; 
    // ...

    mat_mul(&tmp, &a, &x);
    mat_sum(&c, &tmp, &b);

which is what OP meant if I'm not mistaken.

True, operator overloading is definitely convenient for math.

As a real world (-ish) example, I wrote some Python code to do some effects on DMX lights. OpenLighting did all the talking to the lights, so the Python code was really just focused on constructing a list of numbers that would eventually find their way into OpenLighting and onto a DMX cable.

Inside the Python code, each light has a Colour, and I built the Colour class with support for various math operators.

Want to make a Colour that's half as bright as another? Colour = OtherColour * 0.5. Want to blend two Colours? BlendedColour = OneColour + AnotherColour.

Doing this made all of the stuff that the code was doing incredibly obvious and straight forward. The alternative would have involved non-obvious helper functions and object methods or doing math directly on the rgb components encapsulated by each Colour object.

This was, for me, somewhat of a "light bulb" moment for operator overloading.

If it's done in good taste overloading is fine. But if abused it makes code totally unreadable and unmaintainable.

Color me skeptical :) The reason why unnamed operators work so well for math code is that their meaning is already well established.

OneColor + AnotherColor does not have any obvious meaning. If colors are RGBA vectors, it could be vector addition. But is that what your blend operation does?

What's wrong with:

  BlendedColor = blend(OneColor, AnotherColor)

I agree, this is where you have to be careful.

The meaning makes sense to me which, for a one developer codebase, is OK, but it's not something I'd want to do in a codebase supported by a larger team. I expect that in a more complete product that even the term "blend" would have multiple meanings.

And it's also one of the easiest ways to write unmaintainable codes. I once inherited a code where the previous developer seemed to just have found out how cool operator overloading is. So there were a ton of overloads everywhere and you couldn't really tell what is just built-in operators and which is our own code. Total nightmare. After this I would be fine with operator overloading removed from languages.

Nothing wrong with writing:

Matrix_Multiply(m1,m2);

vs.

m1*m2

The first is not harder to read and not harder to write but I know exactly what's going on.

So this code is from Go's big.Int documentation (slightly adapted):

    func main() {
        a := big.NewInt(0)
        b := big.NewInt(1)

        var limit big.Int
        limit.Exp(big.NewInt(10), big.NewInt(99), nil)

        for a.Cmp(&limit) < 0 {
            a.Add(a, b)
            a, b = b, a
        }
        fmt.Println(a)
    }

I can't say I'm particularly keen on having to read

  a.Cmp(&limit) < 0

instead of

  a < limit

The question is whether it's worth it to write code like this in order to prevent others from misusing operator overloading. I guess it may depend on how much math code you write and how disciplined your coworkers are.

> The first is not harder to read and not harder to write but I know exactly what's going on.

For your example, maybe so. But:

  m = a * b * c + d * e + f

will be clearer than three Matrix_Multiply and two Matrix_Add calls. And one screen full of lines like mine will be far clearer than five screens full of Matrix_Add and Matrix_Multiply calls.

I agree if it’s very mathy but I have seen operator overloading for things like invoices and orders. That’s just horrible.

Oh, I agree.

  invoice++

is not better than

  invoice.addToSystem()

FWIW i prefer mul_x, even in languages such as C++ where operator overloading is available i put methods with names like mul, div, etc instead of operators as i am not fan of infix function calls.

Also specifically for vectors and matrices for 3D graphics, i prefer to use float mtx[16], vec[3], etc instead of specifying custom types (then i can use the vec_foo calls with matrices with the proper offsets or the normal part of a float plane[4] which is encoded as normal+distance or use the vec_foo calls directly in a vertex buffer, etc).

> If you don't grasp either and have no time to be allowed to do it, no language will save you.

That is certainly true.

But the language can have a big impact on the difficulty of getting the implementation correct.

Reply on news.ycombinator.com