6 ms·

Cool stuff! 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 extensio

by occz 2y ago

Cool stuff! 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: val fiveBucks = 5.usd val fiveBucks = 5.money("USD") val tenPercent = 10.percent How come you went for "increaseBy" and "decreaseBy" instead of overloading `plus` and `minus`? Just curious, preference is a valid answer.

nwatson 2y ago
`decreaseBy` is a multiplication and subtraction combined, map naturally to commerce domain, and is more complex than plain addition / subtraction.
sigh_again 2y ago
Nothing is preventing you from using it this way ? Infix functions are just syntactic sugar, some prefer it, some don't, but there's zero downsides to it (aside from your coworkers abusing it.) 5 money "USD" is literally the exact same thing as 5.money("USD"), and Int.usd = this.money("USD") + 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)
refulgentis 2y ago
This does a better job of showing an uneasy feeling I have about Kotlin than anything I could say. - 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.
- t-writescode 2y ago
  I have used Kotlin professionally for a couple-few years; and, in my experience, infix operations are a choice and you don't have to use them. - in fact, I don't think any bit of code in anything I've used uses infix operations, this is my first time seeing them in Kotlin in the wild. 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?
  - refulgentis 2y ago
    I agree, you nailed it. Operators are something that feels like using the new shiny but are repeating well-trodden mistakes that are well-understand in languages ranging in age from C++ to Swift.
    - t-writescode 2y ago
      I was referring to in-fix, like can be found in Kotlin and Ruby, not necessarily operator overloads. I've found pretty usable operator overloading, in appropriate contexts, like adding two lists meaning append.
- mrcrumb1 2y ago
  You can bikeshed in any language. Kotlin introduced a lot of optional syntactic sugar so that Java devs could choose their level of comfort with the language features. I don't really see this as a problem unless your devs are prone to this sort of bikeshedding (see: your use of "smells funny"). I've used kotlin for Android since right before it was officially supported and there has been almost no downside other than the occasional hiccup with Java/Kotlin nullability interop
gus_massa 2y ago
> overloading `plus` and `minus` Perhaps I'm misunderstanding your idea, but what about val total = price + 10.percent * 2 If the price is 10, then the total is 12 or 22?
- callmeal 2y ago
  >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.
  - ternaryoperator 2y ago
    price + (10.percent * 2) looks like 12: If 10.percent = 1, 1*2 = 2. 10 + 2 = 12. Under the usual rules of operator precedence, that would be the expected answer (multiplication having higher precedence than addition).
    - bloated5048 2y ago
      How does computer know it's 10% of 10? Unless specified, 10% is 0.1 Or am I an idiot and missing something here
      - gus_massa 2y ago
        If you oveload "+" to mean whatever-you-want, it's possible. Using bad python [1], it's something like: 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 I don't claim it's a good idea, but it's possible if the language allows operator overload. [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.
  - kelnos 2y ago
    How do you get 10.2? I can only think of two (reasonable) ways to think about this: (price + 10.percent) * 2 = (10 + 1) * 2 = 11 * 2 = 22 and price + (10.percent * 2) = 10 + 20.percent = 10 + 2 = 12 Personally I would assume the latter, given standard operator precedence, where multiplication precedes addition.

by occz 2y ago

nwatson 2y ago

`decreaseBy` is a multiplication and subtraction combined, map naturally to commerce domain, and is more complex than plain addition / subtraction.

sigh_again 2y ago

Nothing is preventing you from using it this way ? Infix functions are just syntactic sugar, some prefer it, some don't, but there's zero downsides to it (aside from your coworkers abusing it.) 5 money "USD" is literally the exact same thing as 5.money("USD"), and Int.usd = this.money("USD") + 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)

refulgentis 2y ago

This does a better job of showing an uneasy feeling I have about Kotlin than anything I could say. - 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.

t-writescode 2y ago
I have used Kotlin professionally for a couple-few years; and, in my experience, infix operations are a choice and you don't have to use them. - in fact, I don't think any bit of code in anything I've used uses infix operations, this is my first time seeing them in Kotlin in the wild. 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?
- refulgentis 2y ago
  I agree, you nailed it. Operators are something that feels like using the new shiny but are repeating well-trodden mistakes that are well-understand in languages ranging in age from C++ to Swift.
  - t-writescode 2y ago
    I was referring to in-fix, like can be found in Kotlin and Ruby, not necessarily operator overloads. I've found pretty usable operator overloading, in appropriate contexts, like adding two lists meaning append.
mrcrumb1 2y ago
You can bikeshed in any language. Kotlin introduced a lot of optional syntactic sugar so that Java devs could choose their level of comfort with the language features. I don't really see this as a problem unless your devs are prone to this sort of bikeshedding (see: your use of "smells funny"). I've used kotlin for Android since right before it was officially supported and there has been almost no downside other than the occasional hiccup with Java/Kotlin nullability interop

gus_massa 2y ago

> overloading `plus` and `minus` Perhaps I'm misunderstanding your idea, but what about val total = price + 10.percent * 2 If the price is 10, then the total is 12 or 22?

callmeal 2y ago
>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.
- ternaryoperator 2y ago
  price + (10.percent * 2) looks like 12: If 10.percent = 1, 1*2 = 2. 10 + 2 = 12. Under the usual rules of operator precedence, that would be the expected answer (multiplication having higher precedence than addition).
  - bloated5048 2y ago
    How does computer know it's 10% of 10? Unless specified, 10% is 0.1 Or am I an idiot and missing something here
    - gus_massa 2y ago
      If you oveload "+" to mean whatever-you-want, it's possible. Using bad python [1], it's something like: 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 I don't claim it's a good idea, but it's possible if the language allows operator overload. [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.
- kelnos 2y ago
  How do you get 10.2? I can only think of two (reasonable) ways to think about this: (price + 10.percent) * 2 = (10 + 1) * 2 = 11 * 2 = 22 and price + (10.percent * 2) = 10 + 20.percent = 10 + 2 = 12 Personally I would assume the latter, given standard operator precedence, where multiplication precedes addition.