+ and - are already overloaded (see val subtotal = price + shipping), increase/decreaseBy are for operating over percentages (and could be written as subtotal * (1 - discount), which is much less clear). As the other comment say, it has an actual, real life meaning that people understand clearly. Your price increased by 10 percent. the By convention is also already present in the Kotlin stdlib, although it's more for grouping operations, numeric operations are taking the Of suffix now (sumBy has been deprecated in favor of sumOf, increaseBy could become increaseOf without any loss of clarity)
- The infix is weird and footgun-y.
- Extension methods on int/double serving as constructors smells funny.
- Using infix operators as constructors but not using infix operators for addition/subtraction smells funny.
In general, at least in a corporate environment switching off Java for Android, I found Kotlin a distracting step sideways.
Code reviews tended to involve a lot of bikeshedding over how to make it Kotlin-y, and there's a sort of "why not?" approach to language features that creates much room for the bikeshedding.
It left me feeling like we were unconciously choosing to have the same arguments C++ programmers had in 1990, all over again. Except it was even more destructive, because those arguments were centered, and conflated with "proper" coding in the fancy new language.
I'm not against new and shiny: I was the first to use Kotlin in the org., and I dove right into Swift. There's something alarming with this transition.
I'm heartened by starting to see some debate in Android dev communities about whether Kotlin/Compose were a bridge to nowhere that shouldn't have been a focus for years.
For example, I haven't used them even once.
That said, I, personally, have done almost no Android programming in Kotlin, so perhaps I'm missing the main environment where such things are done? For me, Kotlin has mostly been an aggressive amount of syntactic sugar to make Java a nice experience?
And most of the DSL-style code that I write uses function pointers as the last parameter, so I can do doTheThing(parameters) { anonymous function } and that's about it?
I'm sorry that the organization you work with has aggressive bikeshedding. Perhaps this is something your organization, in general, could have a conversation about?
Minor nit: bike shedding refers to, in the original, arguing about the color of the paint on the shed.
It follows that not all discussion is bike shedding.
In this instance, the references to C++ allude to a common best practice for programmers of avoiding custom operators, which goes far beyond an aesthetic, i.e. style, i.e. color of paint on the bike shed difference. There are engineering consequences. This also applies across languages, I'm familiar with it only from trodding the same path you are, through Swift.
Bike shedding bike shedding is indeed possible, so I won't suggest an umabiguous definition. :)
The bike shedding reference in OP is to the different flavors, but equivalent, syntactic sugar that you mention. This uses the new shiny. But this creates toxic baggage, because among other things, because to a naive implementer, there is no solid engineering reason to e.g. avoid custom operators, it's just a scarred C++ graybeard enforcing their opinion :)
I’ve never seen this amount of bikeshedding like in Kotlin. It’s as if whole identity of Kotlin developer is based on “do it differently from Java” which is super ironic for people who use JVM language.
and thus complicating teamwork because there is no "right" way
kotlin is great for the lone cowboy. not so much for teams.
Anyway, I'm not a Kotlin die-hard but I found it quite fun to code in the language. IMHO, it has a gentle learning curve and the community has plenty of great libraries (e.g., Ktor, Koin).
Nevertheless, I think I leaned too much on using the syntactic sugar of the language when writing the docs and the introductory article. But by no means users are bound to this way of coding.
We've learned a lot about what works and what doesn't in programming languages. Goto considered harmful and all that kind of stuff. If you want to get a Lisp/Haskell fanatic really going point out how so many of the features in those languages have finally made their way into mainstream languages (lambdas, etc.).
What we don't often consider are all of the language features that didn't make it.
This process didn't stop sometime in the past. It is happening right now. That feeling of unease may not be an indication of the quality of the features you are considering. It may largely be uncertainty about what features will or will not stand the test of time.
Perhaps as we get older, we want languages that have all of the good stuff we've learned from the past and none of the experimental stuff that we aren't too sure about yet. That might be because we are starting to notice that we won't have enough time left in our remaining days to sort all the new toys into the good/bad bin.
as OP refers to, custom operators are considered harmful in languages ranging from C++ to Swift. It's a great contemporary example of goto.
I've seen some horrors in my time due to custom operators. I've also suffered through some horrors when they are missing and would clearly be appropriate. They seem appropriate for linear algebra libraries for example. Not everyone agrees, obviously.
As an aside, I have been watching a lot of YouTube videos of people programming C. I notice that goto shows up very frequently, especially in modern C. Usually it is a label at the end of a function to manage resource cleanup before returning, almost like a manual `defer`. Sometimes it is to break out of nested loops. I mean, I've always taken Dijkstra's point to be that long jumping out of a procedural boundary was the real problem, not the keyword "goto". And built-in language features that obviate the need to use goto even for the reasonable use cases are my preference.
I feel the same about custom infix operators. I too share an unease about them. But I have to admit they feel right sometimes. I admit I don't have enough information on their use in this kind of case to know if it is one of the good ones or one of the bad ones.
If it's a foot gun, then I'm not seeing how the gun is loaded?
> Extension methods on int/double serving as constructors smells funny.
It doesn't feel meaningfully different from the static factory pattern in traditional Java, where 10.percent() would be something like MoneyUtils.createPercent() or Percent.create() with several overloads. Under the hood, that is essentially what is happening. Only downside I can see is that it muddies what truly belongs to the class, but that's true of any extension function and Kotlin is intended to be used with IDEA's introspection anyway.
The Kotlin standard library has lots of extension functions that construct new objects.
It also reminds me of Ruby, which perhaps you're also not a fan of and that's OK.
Perhaps I'm misunderstanding your idea, but what about
val total = price + 10.percent * 2
If the price is 10, I would expect total to be 10,2.
(price + 10.percent) * 2 would be 22.
I don't see any way to get 12.
Under the usual rules of operator precedence would be the expected answer (multiplication having higher precedence than addition).
def sum(x,y):
if is_number(x) and is_number(y):
return x + y
elif is_number(x) and is_percent(y):
return x * (1 + y.value/100)
else:
raise fatal_error
[1] Sorry, my main current language is Racket, but I thought that python-like is easier to read for most people, in spite people that likes python can find like 10 error in 7 LOC.
(price + 10.percent) * 2 = (10 + 1) * 2 = 11 * 2 = 22
price + (10.percent * 2) = 10 + 20.percent = 10 + 2 = 12
x + y = 100
90% x + 80% y = 84
x + y = 100
90/100 x + 80/100 y = 84
So in a math class, when you see 20% you translate it to .2, and 10+20% means 10.2. But in a calculator and in the OP project the % button is magic and and 10+20% means 12.
[1] You have to buy two item that in total cost $100, but today there is a 10% discount in one and a 20% discount in the other so you pay only $84. ¿How much is each item?
It's possible to avoid making this decision altogether by not implementing `times` for `Percent`, making the user have to be more explicit about what they actually want to happen - for example, requiring them to add parenthesis to arrive at 22:
val total = (price + 10.percent) * 2
val total = price + (10 * 2).percent
The use of infix functions reads a bit weird to me.
If I were to design an API like this in Kotlin, I think I would have gone for regular extensions for many cases and perhaps extension properties, think as such:
How come you went for "increaseBy" and "decreaseBy" instead of overloading `plus` and `minus`? Just curious, preference is a valid answer.