> > The first is ternaries. What if only simple, non-nested ternaries were > supported? For example, color := temperature > 100 ? “red” : “blue”. This > seems so much more clear than the map[bool]:string trick that some have > proposed. Writing this with an if statement takes either 4 or 6 lines. This > comes up often enough in code to make a significant difference. I think > it’s hard to argue that this has the potential to make code harder to read > if they can’t be nested. > > The thing about this is that no one ever considers the "learning curve" as a cost metric. The thing about ternary is that it encourages composite and hiding logics, as in this pattern: color := <conditions> ? <positive action> : <negative action>
Your given example is straight and 1 of the use case. You probably don't see the cascading effect in other cases after enabling such feature. One is, as usual, new programmers tent to abuse it as such example (Notice the differences between "action" and "value"): color := <condition1> ? (<condition2> ? <first action> : <second value>) : < last value> Such composition only yields more complications. How to mitigate this? Most languages use more documentations, best practices, linters, scanners, machine review, more Medium blogging nonsense, yada yada etc. If you count those learning curves into the learning curve cost just to master the use language, you'll immediately realize why the Go developers team rejected it at the first place: *keeping things simple and killing the root cause*. *If you need a conditional logic, show it. Don't hide it. Show it CLEARLY and correctly, that is, if <condition>; else if <another condition>; else. *It's easier to teach the new comers as young as 8 years old. Lines of codes doesn't matters. Not even in C, the closest to the silicon next to Assembly. The compiler understands what to produce as an output binary; we, as developers, suppose to do our main and the very fundamental job: focus on writing your codes for human to read, even for yourself as well (when you revisit your codes after 2 years). LOC shouldn't even be used as a measurement for software quality assurance or performance from the start. It was meant for marketing hypes and a way to shoo the managers who don't read or maintain the codes from disturbing the developers at work. Arguing LOC is a cost is like arguing "we should not do paragraphing and numbering in English writing; Let's squeeze the entire T&C document in 1 straight line". This request is the same as against why Linux Kernel wants *strictly 80 characters column but 8 characters indent* *discipline*. A LOT of people thought it was meant for those developers who use terminal based editors like vim. In actual fact, *it's not*. (Article 1, Section 2, 3, 4 - https://www.kernel.org/doc/html/v4.10/process/coding-style.html). Peace. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
