News for hackers. Stuff that matters.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by ufmace on Saturday June 15, 2019 @07:18PM (#20192803)
I haven't made it through the whole thing yet, but I do want to register a vote in favor of using Lines Of Code count as a rough measure of program complexity. I think it's a perfectly valid things to do, provided that it isn't used as an evaluation metric and nobody is gaming it, and everyone is a reasonably good programmer, not doing crazy things like trying to stuff a massive algorithm onto one line to be clever, or copy-pasting the same code in 20 places because they don't understand functions and classes.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by hart_russell on Saturday June 15, 2019 @08:39PM (#20193106)
I'd like to hear others' opinions: There's a guy at my work who loves to use doubly, triply, quadruple-ly nested ternary operators. I always find them super hard to read. Am I just a dunce, or do I have a point in thinking it's unnecessarily terse.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by antonvs on Saturday June 15, 2019 @10:01PM (#20193391)
Ternary operators can be fine. Nested ternary operators are hardly ever a good idea.

One thing that people writing this sort of code seem to miss is that it's not just about expressing the code as concisely as possible - other people including oneself in future need to be able to read it easily.

What I would recommend in a code review for anyone using nested ternary operators is just to break them up using meaningful variable names so that you have one ternary operator per statement. It'll be easier to read and the names will help understand what's going on more easily.

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by Krssst on Sunday June 16, 2019 @03:22AM (#20194302)
Nested ternary operators are hardly ever a good idea.

Would using ternary operators as a terser switch statement be fine?

  int a =
    b == 1 ? 2 :
    b == 2 ? 3 :
    b == 3 ? 5 :
    -1;
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by masklinn on Sunday June 16, 2019 @04:17AM (#20194446)
I like those, but they do need to be properly formatted and only "tail-nested".

I also tend to format them thus:

    int a = b == 1 ? 2
          : b == 2 ? 3
          : b == 3 ? 5
          : -1;
Feels much more "case analysis-y" and clearer.

Still, a language having proper support for expressive conditionals is probably better.

Also the way Python's ternary was defined means it should never ever be nested, it looks nasty.

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by WalterBright on Saturday June 15, 2019 @08:46PM (#20193128)
Format them like you would if-else, then they're easy to read:

    x = y ? 1
          : 2;
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by geofft on Saturday June 15, 2019 @09:38PM (#20193297)
I'd encourage your coworker to use a language where if/else is an expression and not a statement. :) Of the languages mentioned in the article, Rust, Haskell, Scala, and OCaml all have this as the only form of if/else: you can write something like x = if foo then bar else baz, so you can nest them with some parentheses for readability. Python's if/else is a statement, but it has a slightly different syntax for the if/else as an expression - bar if foo else baz - which is a little less readable but still workable.

It's only the Algol-syntax-family languages (C, C++, Java, JavaScript, etc.) that have the inscrutable ternary operator and if/else as a statement.

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by pincus on Sunday June 16, 2019 @09:34AM (#20195356)
Algol family syntax is not the same as C syntax. Algol 60 has if-then-else as an expression like "x := if foo then bar else baz". In Algol 68, an ENCLOSED-clause like if-then-else-fi is a PRIMARY, so it can be used anywhere other primaries like identifiers and denotations (literal constants) can be used. "Begin" and "end" are synonyms for ( and ). Both languages are defined on the level of symbols instead of bytes or characters. These symbols can have multiple representations including punctuation and text in non-English languages like Russian. A lot of people today don't know what Algol family syntax looks like which is a real shame because they're very clean and elegant languages.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by giggzy on Saturday June 15, 2019 @08:48PM (#20193135)
I prefer less terse code for readability too. LOC is a decent approximation for complexity but it breaks down when people optimize for it.

It's a tricky problem to decide which idioms are most expressive/readable/maintainable as it's has a group dynamic. My rule of thumb, if I feel I've written clever code it's time to rethink approach.

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by lyjackal on Saturday June 15, 2019 @08:51PM (#20193144)
Usually it's awful. I wish JavaScript had if else expressions. Sometimes it can help to break up the lines with indents if you need a single expression:

  var myvar = foo < bar
    ? bar
    : bar < baz
      ? baz
      : 0
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by _jsdw on Sunday June 16, 2019 @03:08AM (#20194245)
I settled on this a while ago which I think is perfectly readable:

    const myvar
      = foo < bar ? bar
      : bar < baz ? baz
      : lark < 10 ? lark
      : 0
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by Avi-D-coder on Sunday June 16, 2019 @04:04AM (#20194413)
Your wish can come true. Take a look at this stage 1 of the TC39 proposal. https://github.com/tc39/proposal-do-expressions
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by piaste on Sunday June 16, 2019 @03:22AM (#20194300)
I would format that as either:

  var myvar =
    foo < bar ? bar :
    bar < baz ? baz :
                0
or:

  var myvar =
     foo < bar ? bar
   : bar < baz ? baz
   : 0
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by nateberkopec on Saturday June 15, 2019 @08:45PM (#20193124)
I love ternary operators, but nesting them is a recipe for turning your code into an unreadable mess.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by 1f60c on Saturday June 15, 2019 @08:48PM (#20193134)
The latter, IMO.

Something like

  Screen.oled ? "black" : "rgb(21,21,21)"
is easy enough to read. Beyond that, if statements win for me.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by _hardwaregeek on Saturday June 15, 2019 @10:46PM (#20193548)
Personally I'm not a fan. A lot of people love using conditional operators (?, &&, ||) in React, but having overly nested chains of these operators is a code smell for me. Probably means they can refactor the logic into separate components, or into intermediate boolean variables. Or just into a plain old if statement.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by wvenable on Sunday June 16, 2019 @01:14AM (#20193957)
Nope, even code with doubly, triply, or quadruple-ly nested if statements is typically hard to read. I usually refactor that down to avoid that level of nesting.

I don't think there's ever a good excuse for that much nesting of ternary operators.

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by Forge36 on Saturday June 15, 2019 @10:51PM (#20193560)
I love them. I also just managed to mess up a function because of one and not realize it until a late stage of testing I don't know that I've doubly nested them.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by ufmace on Sunday June 16, 2019 @09:21AM (#20195311)
IMO, that's awful and should never, ever be done.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by AlexCoventry on Sunday June 16, 2019 @12:38AM (#20193873)
If he's making the code hard to read, hopefully you can talk that through with him. It sounds like a reasonable concern.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by cozzyd on Sunday June 16, 2019 @01:14AM (#20193956)
Just wait until you learn about PHP's ternary operator.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by nickysielicki on Saturday June 15, 2019 @08:53PM (#20193159)
It depends on the context. Declarative vs procedural. Ternary statements are 2:1 multiplexors.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by kitd on Sunday June 16, 2019 @02:28PM (#20197081)
The traditional method of measuring code complexity is Cyclomatic Complexity [1] which, roughly speaking, measures the number of branch points in the code.

[1] https://en.wikipedia.org/wiki/Cyclomatic_complexity

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by ben_jones on Saturday June 15, 2019 @09:15PM (#20193231)
IMO a good start would be to create a metric based on a combination of:

* Lines of code

* # of keywords/operators

* # of non-standard keywords/operators (i.e. 'go' versus 'if')

* Use of std. library vs. 3rd party libraries

* Depth of call-stack, i.e. is it passing through 3 parent classes

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by chimpburger on Saturday June 15, 2019 @07:39PM (#20192889)
When comparing different languages it becomes more of a measure of the relative abstraction levels of languages. The exact same program will have hundreds (or thousands) of times more LOC in Assembly than in Python.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by applecrazy on Saturday June 15, 2019 @07:48PM (#20192926)
Not only that, the LOC heuristic depends on the verbosity of the language. Java, for example, is more verbose, than say, Python, even though you’re close in abstraction level.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by gpm on Saturday June 15, 2019 @08:10PM (#20193000)
And just syntax decision.

    if (x) {
        y
    }
    else {
        z
    }

    if x:
        y
    else:
        z
Assuming x and y are 1 line but long enough expressions you don't want to use a trinary operator (available in both) the python is 2/3rds the length of the c because of bracketing. Obviously cherry picked, but I bet these differences add up.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by saagarjha on Saturday June 15, 2019 @08:14PM (#20193016)
Of course, you can omit the braces if there’s a single statement (though I personally never do this).
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by gpm on Saturday June 15, 2019 @08:19PM (#20193032)
Sure, and you can put the else on the same line as the end of the if block even without doing that. Or you could make the difference bigger by putting the opening brace on a newline.

I wrote the style of C that I actually write, but it's probably not fair for me to label it as a property of just the language.

Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by saagarjha on Saturday June 15, 2019 @08:21PM (#20193042)
I think it’s a fair point to bring up given that many people actually do write their code that way.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by gpm on Saturday June 15, 2019 @08:29PM (#20193072)
I agree, I hope I didn't come across otherwise, just wanted to clarify why I wrote it like that.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by masklinn on Sunday June 16, 2019 @04:20AM (#20194454)
Or even use allman / gnu where opening braces are also on their own line.
Re:Comparing the Same Project in Rust, Haskell, C++, Python,... by saagarjha on Sunday June 16, 2019 @04:26AM (#20194470)
Yes, but those people clearly have issues ;)