WTF Bites
-
-
but accompanied by nonsense.
So standard English then
QED'd
-
Yeah, that's the real kicker. You know what happens when you put
returnthere? It compiles.With unreachable code?
Yes. For some reason, unreachable code cannot benefit from smart casts, and so it uses the original variable, unbreaking it.
-
Yes. For some reason, unreachable code cannot benefit from smart casts, and so it uses the original variable, unbreaking it.
My brain is having problems comprehending that. It's too early in the century for that sort of thing.
-
@Gern_Blaanston said in WTF Bites:
And Calvin is wrong. There is nothing weird about using "access" as a verb. Again, it's an action, you are doing something, and that's what verbs are for.
It's weirder if you use Access as a noun
proper or
impro...common?Vulgar, even
-
@djls45 so, someone would want to.
-
I've said it before, I'll say it again: Microsoft Teams is so incredibly fucking retarded!
Last week when I was in a meeting, it asked me something along the lines of
Hey, it looks like your audio driver needs to be updated. Do you want to update now?
Maybe "audio driver" it its cute euphemism for whoever is currently talking and it reckons they need to get a clue.
-
Oh for fuck's sake Kotlin doesn't even have tuples. Why people like this language, again?
-
Fun fact:
This is out of date as of half a year ago. The
viewModelfunction doesn't take a factory as an argument anymore. It takes a lambda instead. It makes a whole lot more sense, as factories were useless boilerplate that wasn't even typesafe. But it's not something that you change in a MINOR RELEASE. FROM JUNE. Okay, cool, add your new method and let us rejoice, but don't remove the old one! And if you do remove it anyway, at least update the docs! How else are we supposed to know something changed!?Google literally owns half of the internet. And they can't even bother to add "autogenerate docs" step to the CI/CD flow of one of their most important products. Allow that washbasin to enter the premises.
I wish I knew that before I wasted half of yesterday's evening reading various random tutorials (because of course Android docs have nothing on the topic) trying to figure out how to create and use VM factories with Jetpack Compose. But then, if I didn't, you wouldn't be able to read my rant and discover the horrors of Kotlin Smart Cast.
-
Oh for fuck's sake Kotlin doesn't even have tuples. Why people like this language, again?
Someone remind me what those are again?
-
@Tsaukpaetra I see it mentioned every so often. More than any other non-staple languages.
-
Oh for fuck's sake Kotlin doesn't even have tuples. Why people like this language, again?
You want tuples if your language has awkward list syntax, otherwise they're just an efficiency hack. No idea how that applies to Kotlin.
-
@LaoC I didn't choose a statically typed language just to have
List<Object>everywhere.
-
@LaoC I didn't choose a statically typed language just to have
List<Object>everywhere.If you have lots of
List<Object>, maybe you didn't want a statically typed language to begin with?
-
@LaoC you don't understand. Tuples are exactly what allows me to avoid having
List<Object>everywhere - and that's why I'm mourning their loss.
-
@LaoC you don't understand. Tuples are exactly what allows me to avoid having
List<Object>everywhere - and that's why I'm mourning their loss.I understand, so this probably comes down to what I said before, list syntax being more cumbersome than tuples. I was just trolling at your example of
List<Object>which is basically the return type of every Perl function ever and the antithesis of strong typing.
-
@LaoC now I don't understand you. A list is a list. A tuple is a tuple. How would list syntax make sense for a tuple? What would we use for lists if list syntax was reserved for tuples?
-
@LaoC now I don't understand you. A list is a list. A tuple is a tuple. How would list syntax make sense for a tuple? What would we use for lists if list syntax was reserved for tuples?
Tuples are fixed-size lists. If your list syntax is simple, the only reason to have tuples is to enable the compiler to make some optimizations because it knows the size beforehand.
-
@LaoC tuples are heterogeneous. Each element can have a different type. Lists are homogeneous - only one type allowed for all elements (that's where my quip about List<Object> came from). They're not an optimization at all, they're totally different things that aren't replacements for each other. If anything, tuples are syntax sugar for
class ThingIllOnlyEverUseOnce { public ThingIllOnlyEverUseOnce(int foo, string bar) { this.foo = foo; this.bar = bar; } public int foo; public string bar; }. Which is a very welcome syntax sugar.And even with homogeneous tuples. The compile-time guarantee that you're returning exactly two ints, not one, not three, always, always exactly two ints, goes a long way.
-
@LaoC tuples are heterogeneous. Each element can have a different type. Lists are homogeneous - only one type allowed for all elements (that's where my quip about List<Object> came from). They're not an optimization at all, they're totally different things that aren't replacements for each other. If anything, tuples are syntax sugar for
class ThingIllOnlyEverUseOnce { public ThingIllOnlyEverUseOnce(int foo, string bar) { this.foo = foo; this.bar = bar; } public int foo; public string bar; }. Which is a very welcome syntax sugar.And even with homogeneous tuples. The compile-time guarantee that you're returning exactly two ints, not one, not three, always, always exactly two ints, goes a long way.
Oh, you're right of course. I'm just too used to stick whatever I please in a list
-
@LaoC I have a suspicion I'd absolutely hate working with the code you wrote.
-
@LaoC I have a suspicion I'd absolutely hate working with the code you wrote.
Weak typing and FP does that you you.
-
@LaoC you don't understand. Tuples are exactly what allows me to avoid having
List<Object>everywhere - and that's why I'm mourning their loss.I almost never use the base class Object like that... 🤔
-
-
@LaoC I have a suspicion I'd absolutely hate working with the code you wrote.
Weak typing and FP does that you you.
Weak typing, sure. But leave functional programming out of this.
If anything, languages proclaiming to be FP are more likely to have strongly typed tuples.
-
On the other hand, in languages were the tuples aren't strongly typed, you're more likely to end up angry and pressing down on your keys harder.
-
@LaoC I have a suspicion I'd absolutely hate working with the code you wrote.
Weak typing and FP does that you you.
Weak typing, sure. But leave functional programming out of this.
If anything, languages proclaiming to be FP are more likely to have strongly typed tuples.
Neither of the three I've used (Scheme, Erlang and Perl) does. I.e. Erlang has tuples but strongly typed they're not.
-
@LaoC I have a suspicion I'd absolutely hate working with the code you wrote.
Weak typing and FP does that you you.
Oh my god I just got the flashback to the two days I spent learning Clojure for job interview. It was almost as bad as Python.
I don't get people who insist on dynamic typing in functional languages. About 99% of the cool things about functional programming require a good, strong static type system with generics, inference and type classes to work.
-
@LaoC I have a suspicion I'd absolutely hate working with the code you wrote.
Weak typing and FP does that you you.
Weak typing, sure. But leave functional programming out of this.
If anything, languages proclaiming to be FP are more likely to have strongly typed tuples.
Neither of the three I've used (Scheme, Erlang and Perl) does. I.e. Erlang has tuples but strongly typed they're not.Highly recommend checking out F#. It's the best of all pure-blooded FP languages I've ever worked with. It does nearly everything right, and it's not at all obnoxious or annoying to write in. It's the first FP I've seen that doesn't feel like designed by PhD holder for PhD holders. It's basically OCaml stripped of all the stupidities, like having to repeat "in" after every variable because technically it's only good for one expression (said expression being the whole function). It also integrates very well with .Net ecosystem (though mostly one way because F# records and unions, while technically accessible in C#, compile to a bunch of classes with godawful APIs and weird types everywhere. But you can make regular classes in F# too and from the outside they look no different than those from C#.) And because it's not bound to JVM, it's not restricted by that stupid type erasure rule.
-
@LaoC I haven't used any to be honest, so I was talking out of my ass although I meant to talk truthfully. Haskell and F# have strongly-typed tuples as far as I can remember.
Then again, isn't part of the point of FP that you have to care less about types?
Know what? I'll shut up.
-
This is out of date as of half a year ago. The
viewModelfunction doesn't take a factory as an argument anymore. It takes a lambda instead. It makes a whole lot more sense, as factories were useless boilerplate that wasn't even typesafe. But it's not something that you change in a MINOR RELEASE. FROM JUNE. Okay, cool, add your new method and let us rejoice, but don't remove the old one! And if you do remove it anyway, at least update the docs! How else are we supposed to know something changed!?If you were coding Java (Kotlin's older sister) those would be the same thing, as it says that lambdas are instances of interfaces with one (non-defaulted) method, a natural fit for many simpler factories. Probably a
Supplier<T>or related. Main thing is you (almost always) don't have to write type goop at the point of use, but you do need to constrain what sort of lambda could be accepted and Java is much more about typing by name than by structure.Re tuples, common practice is to use an immutable POJO, which has the benefit of naming what the tuple is and what the members are. We have lots of tuples in our Python code, and that gets really confusing as the size of the code goes up. They're an Attractive Nuisance.
-
Then again, isn't part of the point of FP that you have to care less about types?
Almost all FP cares very much about types. They might try to leave them implicit where they can, or use abbreviated syntax, but the types are definitely there.
Unless it is traditional LISP.
-
We have lots of tuples in our Python code, and that gets really confusing as the size of the code goes up. They're an Attractive Nuisance.
What's the performance difference between named and unnamed tuples? I expect the latter to be slightly laggier, but I don't know/remember enough about Python's internals.
Almost all FP cares very much about types. They might try to leave them implicit where they can, or use abbreviated syntax, but the types are definitely there.
Unless it is traditional LISP.I knew these things, but evidently my brain hasn't woken up yet even after
-
Re tuples, common practice is to use an immutable POJO, which has the benefit of naming what the tuple is and what the members are.
If they're long-lived, sure. But in my experience, a lot of time a function simply needs to return two things at once, and they're going to get separated as soon as the function returns. Consider a function creating a matching pair of sockets, one for reading and one for writing. No way around it, it must return both. And the two are going to be passed to the opposite ends of the communication line. Creating a whole new class just so it can be constructed, returned and immediately forgotten about is just wasteful. Doing so for everything that ever returns two or more values at once is wasteful and annoying.
-
We have lots of tuples in our Python code, and that gets really confusing as the size of the code goes up. They're an Attractive Nuisance.
What's the performance difference between named and unnamed tuples? I expect the latter to be slightly laggier, but I don't know/remember enough about Python's internals.
The simple answer is "it depends". Standard tuples are fast if accessed by index. I've not timed destructuring assignment. Then there's named tuples where accessing by name is fast but accessing by index isn't (and I don't remember what happens with destructuring). And classes where it's all dependent on whether you use
__slots__or not, and you can't destructure. Destructuring also works for lists and any iterable class, and indeed for sets and dicts but you probably don't want that.And "fast" is always just "fast... for Python".
-
Oh for fuck's sake Kotlin doesn't even have tuples.
Neither does Java 1.6, does it?
Why people like this language, again?
Because it's better that
poke in the eyeJava and still compiles down to JVM 1.6 bytecode Android uses.
-
-
Highly recommend checking out F#.
I've tried it for a bit a while ago.
I'm still undecided about significant indentation, same as Python.
And my C-like brain really misses the semicolons. But I think I can get over the lack of commas between function arguments.
-
Fun fact:
This is out of date as of half a year ago. The
viewModelfunction doesn't take a factory as an argument anymore. It takes a lambda instead. It makes a whole lot more sense, as factories were useless boilerplate that wasn't even typesafe. But it's not something that you change in a MINOR RELEASE. FROM JUNE. Okay, cool, add your new method and let us rejoice, but don't remove the old one! And if you do remove it anyway, at least update the docs! How else are we supposed to know something changed!?Google literally owns half of the internet. And they can't even bother to add "autogenerate docs" step to the CI/CD flow of one of their most important products. Allow that washbasin to enter the premises.
It's funny. The Android API itself, the non-X package, is versioned fairly carefully. There is no minor or major release distinction; the API version is just one number, but the documentation is there (or at least was; I didn't do any Android stuff for a couple of years) for each version and you can check what has changed.
Why the extensions (androidx) packaged in the SDK can't …
-
Oh for fuck's sake Kotlin doesn't even have tuples. Why people like this language, again?
You want tuples if your language has awkward list syntax, otherwise they're just an efficiency hack. No idea how that applies to Kotlin.
Tuples have approximately nothing to do with lists. They are more closely related to structures. And the main reason to have them is being able to return multiple values. Without those ugly by-reference arguments.
-
And my C-like brain really misses the semicolons.
There are semicolons in F#. You just don't need to use them. Or sometimes you can't use them because your 40-line function is just one long statement stitched together with
|>. Which is actually a very nice way to write code if you ask me.
-
Oh for fuck's sake Kotlin doesn't even have tuples.
Neither does Java 1.6, does it?
Didn't stop Scala. 18 years ago, before Android even existed.
-
Gah, I've seen some real monsters created with the Tuple library for Java. Best left alone. A tuple is usually okay but then some people decide they want tuples of tuples. Glad I don't work with fucker anymore. I need to collect the idiotic ramblings of some of the juniors I've worked with. I do have a good one at the moment but I suspect he's about to be corrupted by a couple idiotic seniors.
-
This post is deleted!
-
Gah, I've seen some real monsters created with the Tuple library for Java. Best left alone. A tuple is usually okay but then some people decide they want tuples of tuples. Glad I don't work with fucker anymore. I need to collect the idiotic ramblings of some of the juniors I've worked with. I do have a good one at the moment but I suspect he's about to be corrupted by a couple idiotic seniors.
I'm making a curry / uncurry library for 1.8!
-
It sure makes sense for some acronyms. "I LOL'd" is common; "at work everybody is BYODding" would be fine. "Let me just LCD this widget" would be weird though, just like "try to IIRC this" or "I hope I've been able to Q.E.D. it". All the right verbs but accompanied by nonsense.
Those are all intelligible in that they (probably, with context) communicate the intended meaning, even if they don't make perfect sense grammatically.
-
@Gern_Blaanston said in WTF Bites:
As for using RSVP as a verb, I see nothing wrong with that. Responding to something is an action, you are doing something, and that's what verbs are for.
I respondpleased is like saying I fuckyouverymuched up. It does contain the verb that expresses what you're trying to say, but the rest of it changes the meaning to something different.
Words, and their use, change over time.
Today it is common for people to shoot video with their phone and refer to it as "filming". It's technically wrong (there is no film involved) but it is now almost universally accepted.
"I RSVP'ed" is technically wrong but is understood to mean "I replied".
Shit happens, and sometimes you just have to stop being the old guy yelling at clouds.
-
@Gern_Blaanston said in WTF Bites:
@Gern_Blaanston said in WTF Bites:
As for using RSVP as a verb, I see nothing wrong with that. Responding to something is an action, you are doing something, and that's what verbs are for.
I respondpleased is like saying I fuckyouverymuched up. It does contain the verb that expresses what you're trying to say, but the rest of it changes the meaning to something different.
Words, and their use, change over time.
Programming languages and their use change too, but it doesn't make those who write in JS any less wrong.
-
On another topic...
You think server-side JS is stupid? I just saw a blog post about server-side WebAssembly.
-
Programming languages and their use change too, but it doesn't make those who write in JS any less wrong.
:zinger:
androidx.lifecycle.viewmodel.compose | Android Developers
