{ id: d2718, ok: 🇵🇸🌈🏳️⚧️🇺🇦 }Okay, #Rstats , this is the kind of thing that drives people _fucking crazy_ .
👎
EndlessMason@d2718
What? You got your integer!
Invader Zim- Zim and his Sandwich
@EndlessMason But I didn't get any integers!
@d2718 It says it right there
[1] "integer"
sounds like an integer to me
I am a perl programmer, so I don't know much about ... you know ... type systems
Weekend EditorTough, but fair.
I mean, there are rationalizations for it, and historical circumstances that led to it, sure.
Whenever you want functions to "spread" over vectors and lists and such, there is always going to be confusion around singletons. I remember several occasions when colleagues stared in disbelief when I explained the difference between x[] and x[[]], which is more or less about that.
But... yeah, it's confusing.
I absolutely realize that
a) R has a lot of "legacy warts"
b) R does a lot of polymorphism, and that fact interacting with (a), combined with (sometimes at odds with!) a tendency to try to give you what it thinks you want sometimes leads to surprising results, especially if you're used to a "type system first" language
(Likewise, the difference between `[` and `[[` very much makes sense to me—they're different functions! they do different things!—although I will admit that I was slightly confused in my early encounters with R.)
But it's just amusing to say it out loud:
"An empty vector is of type 'null', but an empty vector of integers is of type 'integer'."
(Also, it cost me some prettily frustrating time this morning before I figured out what was going on.)
You are correct: R is definitely not a "type system first" language, that's for sure. :-)
My problem is that I used it professionally since about 2000 or so. After that many decades, the quirks are burned into my brain enough that I don't really notice them.
@weekend_editor Yeah, the two languages I use most at work are Rust and R; switching between them inevitably results in some whiplash. The hardest part about R for me is the weird type system that does its best to try to hide itself from you.
Honestly, in a couple decades of battlefield usage of R, I probably only thought about types a couple times.
Using str() to see the structure of things, absolutely. Daily.
But typeof(), or class(), or mode()... not so much.
(In the future you can rant about typeof() vs mode(). :-)
I'm not a particular fan of OOP, but I definitely cut my teeth on Pascal/Java/C++ back in the '90s, so it's still super weird to me that "type" and "class" are completely orthogonal things! (I mean, I get it, I just reflexively find it weird.)
And in Haskell, there's this typeclass thingy... :-)
Somehow this one doesn't bother me. It's almost undoubtedly because I never have to use Haskell for anything. Thank goodness.
Fair enough.
Every time in my adult life that I've learned a radically different programming language, it's opened up interesting opportunities. (E.g., Lisp and R.)
So when I retired, I started messing about in Haskell. No major life changes yet, at least none attributable to Haskell.
So I'm considering going more radical with Piet, whose *source code* is an image resembling a Mondrian painting.
No, no, I took the U. Helsinki MOOC Haskell course, and am glad I did; among other things it got my recursion chops in order for when I got into other functional languages (mostly Gleam and OCaml). I'm absolutely glad that I have some familiarity with Haskell, I'm just also glad I don't have to _work_ in it.
I feel similarly about Lisp—it definitely changed the way I think about writing software (particularly because when I initially forayed into it I didn't have that much experience with other languages, so it was appropriately mind-blowing), but I don't really want to work in it.
I have amused myself by looking at the Piet documentation before. If I were 20 years younger (and in particular as free of obligations and responsibilities as I was 20 years ago), I would absolutely dick around with it. (But I have a job and a kid and a mortgage and a long list of personal projects I'm never going to get to as it is.)
If you don't mind an esolang countersuggestion, I really enjoyed messing around with Befunge:
https://en.m.wikipedia.org/wiki/Befunge
The idea of "code paths" being more akin to actual physical paths is an interesting perspective.
Sergio Oller@d2718 Sorry, I guess I am too used to R. What bothers you about that behaviour?
@zeehio If "an empty vector" is NULL, it seems like "an empty vector of integers" should also be null!
@d2718 ah I see. I see all vectors as typed `character(0)`, `integer(0)`, `logical(0)`... These are zero length vectors of different types. When there is not enough info to infer the type, we have `NULL` as a fallback.
`c()` concatenates vectors.
If there is nothing to concatenate there is no type to infer so `NULL` is the outcome.
If we provide a type to the NULL vector (e.g. as.integer(NULL) we get the empty integer vector `integer(0)`.
That's how I make sense of it. I hope it helps.
Yeah, I think I had conflated this with the Lisp behavior wherein an empty list is nil, so I thought of `c()` (because it's `NULL`) as being an "empty list".
I understand what's going on; I gravitate toward static type systems and their comforting security, so R's extremely "informal" type system trips me up all the time, and this was one of those times!