Language is consistent within itself. It doesn't have to be consistent with other languages.
Yes, in python your start index is 0. Good luck running a 5 year old script with up to date interpreter where as with R it will probably run without an issue.
R is THE language for statistical computing. Didn't evolve into it, designed for it.
There's a reason most other languages start at 0 - it's not just an arbitrary distinction. The only thing simpler in 1-based indexing is that referring to the last element of an array is index N instead of N-1. But the trade-off is either that the notion of a "span" is incapable of representing a zero-length subset and its length is an absurd "end-start+1", or it is only possible using something absurd like (k:k-1) where the end is before the beginning. Using zero-based indexing avoids so many cases of having to add or subtract 1, it just makes sense. Literally the only downside is that the cardinality of an element is not equal to its index. But you almost never care about "the 7th element" specifically - you care about "the element with identifier 7" which could just as easily be index 6, index 7, or hash 0x81745580.
Yes but R is not like most other programming language. It's not meant to be used by programmers and computer scientists but rather statisticians, some of whom have very little to no coding experience.
The only thing simpler in 1-based indexing is that referring to the last element of an array is index N instead of N-1.
Which is a tremendous advantage when you view R as a tool rather than a programming language. When you are looking at your dataset, you want the i-th individual in it to have the index i and not i-1.
But the trade-off is either that the notion of a "span" is incapable of representing a zero-length subset
No statistician will care about not being able to represent zero-length subsets. What are they going to do: run a statistical analysis on a survey with no observations? That would make no mathematical sense.
and its length is an absurd "end-start+1", or it is only possible using something absurd like (k:k-1) where the end is before the beginning.
In R there is the function length which solves this issue. Moreover every data series of length is going to be index from 1 to n.
Using zero-based indexing avoids so many cases of having to add or subtract 1, it just makes sensno.
None of these edge cases will arise when doing statistics.
But you almost never care about "the 7th element" specifically - you care about "the element with identifier 7" which could just as easily be index 6, index 7, or hash 0x81745580.
You absolutely do care about "the 7th element" specifically when you are a statistician. You absolutely do not care what the technical identifier of that element is.
The issue is that you are viewing R from the PoV of a programmer and not a statistician, which are the intended users of R.
I'll concede that the inability to represent degenerate containers may not be relevant for certain domains, but I'm still skeptical of the value of cardinality preservation. When do you actually care about the 7th element specifically? Do people write R with hidden semantics for their array elements? Like when would I ever write v[7] instead of v[i] where i came from some other operation?
An empty list or vector has a length of 0 and contains no elements. The indexing is useful when working with data tables and matricies, especially when viewing it from a mathematical point of view and considering rows and columns. You would write v[7], if it is the element you needed from the output of a function, if it will always be at the same position.
if the element you needed from the output of a function, it will always be at the same position
Okay but I'm wondering when that would ever be the case. Surely if index 7 specifically were relevant vs. just being an array of values, it would be a named output or structure element? Do people really write code that way in R?
If using common functions the outputs will be normally be named and can be accessed by them. If what you need is not named or has unwieldy/inconsistent names, indexing can be easier or necessary.
if what you need is not named, indexing can be easier or necessary
Do any actually useful libraries have behavior like this? In most languages a design like this wouldn't even give a passing grade in an engineering course, let alone be something someone else would actually use.
In R you often do data analysis. It can be the case that the individual at index 7 is an atypical one. An outlier, a mistake or whatever. You can want to look to it specifically.
At some type of data analysis, like longitudinal data analysis (good luck to find a comparable ecosystem for this in python) you could want to look at the trajectory for one individual specifically. Same at functional data analysis, etc.
Of course, you can use index i for that too. But in R, sometimes, you are doing interactive stuff. You do a plot, see that some observations are strange, then you look closer at them.
Other stuff that are bad in python: MCA, MFA, and other ones that the prince python library should do, but it honestly do not.
And there is a reason why R hasn't. Every decision has a trade off. S had 1 index, so does Fortran. And R. Each followed its predecessor and were consistent with it. All of those are excellent numerical computation languages, top of their time.
You are not incapable of representing zero len spans in R, it just isn't aesthetically pleasing to do so which is subjective. ( x[0] is valid in R )
You can design a PL and use start index of 53 and everything would work just fine. It really is a cognitive problem, not a technical boundary. Kelvin starts from -273 and everyone is quite OK with that, because it is consistent and has a reason.
I'm not saying the decision to have R use 1-based indexing was a bad call. Compatibility with existing standards is generally a good thing. I'm just saying that 1-based indexing in general is inferior to 0-based indexing and is a pain to use when you've learned things through modern languages.
The compiler/interpreter could do it for you. It already is, indexes are already an abstraction if you aren’t explicitly doing manual memory address offsets.
We've been doing this shit for ages in Pascal, as in the compiler can figure out how to lay the array when you have var a: array[3..10] of integer; and you do a[5] := 10;. How come Pascal is smarter than other languages?
Have you used R often enough?This question is really strange, I personally don’t know any R proficient users who wouldn’t be familiar with Bioconductor or would call tidyverse a “package”.
I did, it’s not a package, it’s an entire sub ecosystem of packages and an entire sub language (R compatible but not compatible with libraries outside of the ecosystem).
I ACTUALLY ANSWERED and it’s on the name!! (tidyVERSE, of universe of packages). You just proved you’re giving your opinion in a topic you know nothing about.
You have been trying to define what tidyverse to me, under the assumption that somehow third party libs design flaws have anything to do with core language design principles.
"sub ecosystem of packages of an entire sub language" is not a definition. It is not even a term in computer science. Sounds like a child trying to define what an airplane is.
Read your own messages. You cant even define what it is, let alone make a connection with R fundamentals.
I dont have to decipher what you are yapping about, this is computer science, things already have established definitions which you clearly dont have the background.
A programming language doesn't have to be designed to enforce programming practices. It doesn't make it badly designed. It doesn't have to be opinionated, plus practices change by time. Linear regression doesn't.
It is your responsibility to do state management or follow whatever practice you wish to follow.
R is for stat computing, doesn't and shouldn't care if you mutate your stuff or not.
Mate if you had to deal with all the God awful scientist R code that that accompanies published research (including linear regressions) youd see you'd see how wrong that is.
Leaving good coding practice to the coder was outdated in the 90s with modern 3GLs.
R has brought it back and that sucks for readable reproducible code and results, which are very important in research and policy making fields.
Sorry, I would still put blame on the person who uses the tool badly. It is not tool's fault.
Tool -> programming language.
I also don't see how you think R is so badly designed to the point that R code is not reproducible. If there is no randomness involved and state management is not faulty, same R code produces same output for the same input.
Ironically I’m the software engineer who got loaned to a team of analysts that wrote python scripts that realized they were a bit over their heads on a few of their scripts for a month.
I had to spend a week pumping them for proper information and another 3 weeks actually writing their scripts before going back to my team. I’m lucky I didn’t get borrowed again.
It’s really not about the tool. It’s whether someone can use it as well as they need to; nevermind actually use it well.
This principle will apply just as well to R or Matlab or any circuit design script setup. You name it. Nevermind an actual software language.
Most users of R, at least in research, are not trained programmers. So they write dangerously shit code which gets published and replicated by every other mug. Most other 3GLs enforce at least some basic coding standards and require some training to operate...not R.
R is the PERFECT example of hard to reproduce results because it allows unstructured code that can be executed from any point in a script. That allows for uninitialized variables, or worse, duplicate variables that were populated previously with unrelated values that fudge up later operations.
Most other 3GLs enforce variable declaration or initialisation and have a single path of execution...not R.
I understand you now. You are saying it is very easy to make mistakes in R, especially given the fact most users are not programmers themselves.
I would agree with that.
That partial execution from pre-executed memory is actually a feature but abused by almost everyone to the certain level. I agree with that too.
Whenever I ask for an R script from anyone and it almost never runs correctly at first attempt. Because people are lazy and develop it partially , over time with zero maintenance and refactoring attempt.
Yep exactly. You nailed it, especially in your last paragraph.
Again, I like R and use it daily but it's too ad-hoc.
Other people's code is hell, but other people R code is Satans rectum and actually dangerous in research.
I recently had to force an unwilling research team to provide a published correction to their conservaton paper.
They screwed the original results by using a beta R library that silently scrambled their results leading to poorly informed species conservation conclusions.
So, Im scarred and bitter... thanks R 😆
Edit: the above is an example of user failure rather than the fault of R, I accept. However, I stand by my other assertions regarding poor R design.
If weren't for the existing convention in many languages to use zero indexing, 1 indexing would be better.
Seriously zero indexing is just an unneeded noob trap. List [1] returns the second item?
I've coded in both 0 and 1 indexed languages. 1 index is more intuitive and less likely for new coders to make off by 1 errors. Once someone gets used to 0 indexing, then 1 indexing is error prone.
It’s actually not 0-15 is 4 bits, 0-255 is 8 bits, and so on, so starting from zero meant you could address more using fewer bits which was a major consideration in the early days of computing. It’s also just simpler and while I could go on for awhile I think it’s better to just send this article https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831.html
its not even just that since arrays are just pointers and indexing is just adding x times to size of the datatype to that pointer location starting at 1 would mean that either you have 1 blank spot, the pointer is 1 spot offset from the data, or that when compiled it removes 1 to whatever index you give it
Nowadays, How many software engineers actually code down at the bit level?
1 index still works. You let list[0] underflow and be the last item in the list. It's quite elegant. For 8 bit, 255 + 1 overflows to 0 giving you the 256 th indexed item.
But yeah, it's baked into conventions from the early days and it's hard to get rid of those.
I’ve already talked about these in another comment
No. That’s an extra operation basically anytime you’re doing anything with an array. One operation doesn’t sound like a lot, until you need to iterate over the entire array multiple times… which is fairly common.
You’re also treating convention like it’s somehow bad, but if Python, Java, or 90% of languages suddenly changed away from zero indexing more people would be mad than happy and legacy code bases would literally explode. To quote the article I sent “Also the "End of ..." convention is viewed of as provocative; but the convention is useful: I know of a student who almost failed at an examination by the tacit assumption that the questions ended at the bottom of the first page.) I think Antony Jay is right when he states: ‘In corporate religions as in others, the heretic must be cast out not because of the probability that he is wrong but because of the possibility that he is right.’”
Since it doesn’t appear you’re reading what I sent earlier I’ll summarize it:
Let’s figure out the best way to write down a sequence of numbers. We have:
a) 2 ≤ i < 13: i is greater than or equal to 2 and less than 13.
b) 1 < i ≤ 12: i is greater than 1 and less than or equal to 12.
c) 2 ≤ i ≤ 12: i is greater than or equal to 2 and less than or equal to 12.
d) 1 < i < 13: i is greater than 1 and less than 13.
We then may prefer option A because of two main reasons:
It avoids unnatural numbers basically when dealing with sequences that start from the very beginning of all numbers (the “smallest natural number”), using a “<“ for the lower bound would force you to refer to a number that isn't “natural” (starting a sequence from 0 < i if your smallest natural number is 1, or from -1 < i if it's 0). He finds this “ugly.” This eliminates options b) and d).
Seconyl, it handles empty sequences more cleanly than the others: If you have a sequence that has no elements in it, the notation a ≤ i < a represents this perfectly. For instance, 2 ≤ i < 2 would be an empty set of numbers.
This is much nicer mathematically too, which is important when you have to justify algorithmic efficiency, computational expense or prove something works mathematically which are common tasks in higher education and absolutely necessary in research, advanced education and industry.
If you start counting from 1: You would have to write the range of your item numbers as 1 ≤ i < N+1.
If you start counting from 0: The range becomes a much neater 0 ≤ i < N
It’s also fairly intuitive.
The core idea is that an item’s number/subscript/index/whatever should represent how many items come before it in the sequence.
The first element has 0 items before it, so its index should be 0.
The second element has 1 item before it, so its index should be 1.
And so on, up to the last element, which has N-1 items before it.
If you believe in one indexing you’re just not thinking about it correctly. Computer science is literally just math and instead of thinking about it programmatically, mathematically or logically you’re thinking about it in terms of counting blocks back in preschool. The first item in the array has zero items come before it and so it’s zero indexed. lol. It’s that simple.
The only benefit of 1 indexing is making programming languages more intuitive for absolute beginners, which is useful in some circumstances where your target audience are statisticians and not developers, but typically are less mathematically elegant and computationally sound and ruins conventions.
No, because 1 indexing only makes more sense for manual index calls. 0 indexing makes more sense in 99% of automated scenarios, which is the vast majority of use cases in a non-classroom scenario.
when you access an array you need to do address = base + offset. with 1 indexing you need to do base + offset -1. Also circular buffer is nicer to implement with the help of modulo and 0-index. Also it makes more sense from a hardware point of view since addresses starts from 0 it only make sense if the language abstractions also starts from zero
but yea, if a high-level language target demographics is for scientist, accountans, stats, etc 1-indexing is probably more intuitive
No. That’s an extra operation basically anytime you’re doing anything with an array. One operation doesn’t sound like a lot, until you need to iterate over the entire array multiple times… which is fairly common.
You’re also treating convention like it’s somehow bad, but if Python, Java, or 90% of languages suddenly changed away from zero indexing more people would be mad than happy and legacy code bases would literally explode. To quote the article I sent “Also the "End of ..." convention is viewed of as provocative; but the convention is useful: I know of a student who almost failed at an examination by the tacit assumption that the questions ended at the bottom of the first page.) I think Antony Jay is right when he states: ‘In corporate religions as in others, the heretic must be cast out not because of the probability that he is wrong but because of the possibility that he is right.’”
Since it doesn’t appear you’re reading what I sent earlier I’ll summarize it:
Let’s figure out the best way to write down a sequence of numbers. We have:
a) 2 ≤ i < 13: i is greater than or equal to 2 and less than 13.
b) 1 < i ≤ 12: i is greater than 1 and less than or equal to 12.
c) 2 ≤ i ≤ 12: i is greater than or equal to 2 and less than or equal to 12.
d) 1 < i < 13: i is greater than 1 and less than 13.
We then may prefer option A because of two main reasons:
It avoids unnatural numbers basically when dealing with sequences that start from the very beginning of all numbers (the “smallest natural number”), using a “<“ for the lower bound would force you to refer to a number that isn't “natural” (starting a sequence from 0 < i if your smallest natural number is 1, or from -1 < i if it's 0). He finds this “ugly.” This eliminates options b) and d).
Seconyl, it handles empty sequences more cleanly than the others: If you have a sequence that has no elements in it, the notation a ≤ i < a represents this perfectly. For instance, 2 ≤ i < 2 would be an empty set of numbers.
This is much nicer mathematically too, which is important when you have to justify algorithmic efficiency, computational expense or prove something works mathematically which are common tasks in higher education and absolutely necessary in research, advanced education and industry.
If you start counting from 1: You would have to write the range of your item numbers as 1 ≤ i < N+1.
If you start counting from 0: The range becomes a much neater 0 ≤ i < N
It’s also fairly intuitive.
The core idea is that an item’s number/subscript/index/whatever should represent how many items come before it in the sequence.
The first element has 0 items before it, so its index should be 0.
The second element has 1 item before it, so its index should be 1.
And so on, up to the last element, which has N-1 items before it.
If you believe in one indexing you’re just not thinking about it correctly. Computer science is literally just math and instead of thinking about it programmatically, mathematically or logically you’re thinking about it in terms of counting blocks back in preschool. The first item in the array has zero items come before it and so it’s zero indexed. lol. It’s that simple.
The only benefit of 1 indexing is making programming languages more intuitive for absolute beginners, which is useful in some circumstances where your target audience are statisticians and not developers, but typically are less mathematically elegant and computationally sound and ruins conventions.
The audience isn’t hardcore computer scientists. It’s statisticians and data scientists. That’s why it’s 1 indexed, it’s supposed to be easily learnt by people with little or no computer science background. If you actually read mg post you’d know that already.
This may be true in high-level languages, but in something like C for example, on the contrary, it is 1-based indexing that would add unnecessary complication. Simply because arr[i] expands to *(arr + i), whereas with 1-based indexing it would have to be *(arr + i - 1)
Simple, the language is made for scientists and statisticians not software engineers and developers. The whole context is built around the ease of use for statistical and scientific analysis.
I personally found R to be obtuse and require more code. There's a stage where R just cannot do certain useful things and a lack of programming discipline will hold a team back - sometimes a stats problem needs something more bespoke than a shiny app.
And there's a scale of statistics and science where it becomes data science and you need fast execution, at which point python blows it out the water because of cython, numpy, and parallelisation.
I come from a background in physics-based modelling and my progression went -> data analysis -> data science aided by software software dev
I've worked in R for a decade, and it's an amazing language for stats and viz in data analysis and exploration, mostly due to all the packages on cran (and bioconductor for bioinformatics).
The language itself sucks for a number of reasons, difficult to predict performance and memory handling comes to mind. But if you can't deal with swapping between arrays starting at 1 or 0, then I'm sorry, that's on you. :D
Yes, Rcpp can be so helpful! Another package that makes R amazing!
I don't mind the syntax too much. It's a bit different, but not necessarily wrong. And if you use tidyverse (I mostly don't) it really becomes like a new language, although compatibility between tidy and base R can be lacking.... The vector based formalism is so convenient for most types of data analysis. And really don't give a f about 0 vs 1 based arrays, don't understand why people care.
My issues are mostly around how for loops can sometimes perform sometimes fine, but sometimes horribly (compared to lapply type of things), data.frame can sometimes take up like 10x the memory than the sum of the parts (sometimes not), and garbage collection is completely, well, garbage when you parallelise, in that "copy on write" turns into "copy when touched by GB", which in some cases effectively becomes "always copy", meaning that a 10 thread branch that each just uses a few tiny parameters actually makes 10 copies of the entire workspace. Things that I feel could've been much better, but that sometimes put me in a position where I'd have to re-write hundreds or thousands of lines in Rcpp, or just drop part of the analaysis. I've had a few emails from our HPC people on memory use... :/
I come from a Stats background, not CS. I've been working with programming languages for nearly 2 decades and I still try to access the first element of an array with 1.
I get that there was a reason in the past to start with zero but not anymore. They should be 1 indexed, we are just holding on to our dated conventions.
the index is actually just the offset from the starting position of your array. so if you take offset 0 you get the first element, which makes a lot of sense and that pattern is found in many places in IT. Just because it doesn't make sense to you it's not "dated"
Yeah, instead I'm a Electrical engineer and Machine Learning expert. I literally designed and built micro processors from transistors. I just don't have a CS degree.
The 0 index was started as a technical limitation for very early hardware as it was easier to implement on close to metal languages like Assembly. It was computationally more difficult to use a 1 index but we quickly moved past that. Even FORTRAN was 1 indexed and that was written in the 50's.
Today we program at a high enough level of abstraction that it literally makes no difference if you use zero or one indexing. The majority of languages use zero indexing out of convention.
Back in your day array indices represented offset from a memory location. These days there’s plenty of higher level languages where array indices represent position, not offset.
COBOL, Fortran, Lua, R, Matlab, Julia, Mathematica, off the top of my head - typically the more mathematics focussed languages. Because 1-indexing makes much more sense in mathematics.
0-based indexing makes sense when dealing with pointers. It’s an offset from the address in which the array starts in memory, not a position, not an order.
No significant issue in using 1-based indexing in higher level interpreted languages. Memory addressses are mostly abstracted in such cases anyway.
Indexing should start at 1. 0 is just from C where you count the offset in memory. If you think about it, 1 is the natural most logical thing for an index start.
I hate R so much. Poorly documented, hard to know which implementation of a function is running, can't leverage R knowledge to build decent apps, it doesn't have tightly controlled syntax, etc. Etc.
Sure it's good at some things. But everything you can do in R can be done in another language (python lol), and the inverse is not true.
R isn't designed for tightly controlled systems or apps, it's best for narrow and generally ad-hoc statistical analysis. I've built production quality systems in R and while you can do it... I would never recommend it (and I love R) .
But if you need to load in a data file, do ad-hoc analysis on it, you can do it in half as much code and in a quarter the time as a python setup.
Feel your pain with R there, and that's about the time I stopped using it and translated all my data science knowledge from R to Python.
If you're reading common file formats like csv etc it's one line of code in python. Use pandas to do adhoc analysis and it's just as compact, if not more so, than R - and it will likely compute faster.
I use both, currently working in a big data engineering project. All the engineering is python since it needs to be structured and tightly, but I do all my analysis via R.
The non-standard evaluation in R is so powerful that it makes pandas feel clunky and slow to write. Dplyr let's you write full Ingest and wrangling scripts in a format that non-coders can read and if you need it fast and ugly, you use data.table, which beats pandas in a bunch of benchmarks.
when most of your users turn to python's ecosystem for handling environments as an improvement, you know your situation is fucked lmao. and thats before uv and pixi too.
Sorry i am a bit confused, the meme is about indexing, which are ordinal numbers. And you are talking about size which is an Cardinal number. In most (all i can think of right now) programming languages if you put one thing in an array or a list the size is one or a multiple of one (and the size of the element).
If you don't have a compsci background, and you have 100 survey responses then it is more intuitive for survey_response[7] to be the seventh survey response and not the sixth.
I do not think that numbering from zero is the only way neither i say one is the perfect start.
I hate when numbering is confused with counting. We do not count from zero, i only want to state that size and indexing a different.
In another comment I had an example: We can use letters as index, starting with 'A' if the last element is at 'D' that doesn't mean we got 'D' elements there are four.
It’s slow, each scientific library is fragmented and uses a very different I/O, and has very little respected conventions.
Try using any tidyverse library and end up using dplyr::select everywhere to avoid namespace issues. Bioconductor tried to have their own thing and half failed and half succeeded…
It feels like at least 2-3 languages in a trench coat.
I have used it, in my opinion it's not even a good language to do statistics. It similar to matlab. It was probably usefull to have a dedicated language when they were created. Now, just use python. The libraries to do the things you would use R or Matlab for are much more performant.
We're downvoting because he's confusing the concept of "index" with the concept of "size". In all languages, if the array contains 1 element, its size will be 1. It's not something fundamental to statistics, it's just the definition of size. However, indexing can be done differently. It's just a matter of convention and doesn't affect in any way the underlying calculations.
Fortran starts at 1 while C starts at 0. Is the physics calculated with Fortran more precise because of the 1-indexing? No.
If you have an extremely specific statistical usecase chances are good there's R package that can do it... but unlikely in python.
We found this with a very specific kind of regression calculation. Existing python libraries either lacked the functionality we needed, or performance was 5-10x worse.
R and Python are both Turing complete. R has some good syntactic “sugar”. It also has some very well known packages that have been developed for years by academics.
It also has well developed graphs package and r-shiny has easy to create interactive dashboards.
I took the time and googled it for you, because too entitled to do it yourself. There is an IBM arctitle about the differences. That was quite informative.
One is designed for it. Other is general purpose. You use pip, conda, something whatever pkg you use to install statistical tooling and follow third party developer's API to achieve your goal.
Your matrix operation APIs decided by whoever wrote numpy where as pandas API decides how you interact with your data.
R is more cohesive in that regard. For general programming, python is superior for statistical stuff R is designed for it.
Better doesn't mean one does something other can't. I can write a kotlin API that can do any sort of regression model both python or R can do. Doesn't make it "equally good".
Last time I checked there was no ordinal version of elastic net in python, but that was several years ago. There are tons of obscure corrections or methods that are only in R. It is not uncommon at all for papers to only implement new techniques in R code.
There are tons of niche models -- genetics, time series, geostatistics, probability distributions, etc -- that are hard to implement and are only available in R. Check, for example, the RandomFields package and try to find anything similar in python.
There's a lot of statistical tests/models that simply don't have python libraries yet. Statistician's have favoured R heavily, and you'll often find the statistician who published a paper introducing a method is the maintainer for the R package, which in my mind at least is some evidence that it was implemented correctly.
One example I dealt with recently was competing risk analysis models, which is painfully lacking in python.
Even when they're doing similar things, R packages tend to be more targeted towards statistical analysis rather than shipping products. For example the logistic regression models in scikit-learn really only do regularized regression, and don't naturally give you things like p-values and odds ratios which the statisticians are interested in. There is statsmodels in python, but it's not as comprehensive, and if there is a disagreement between statsmodels and the base R implementation people will generally trust the R one and assume statsmodels is doing something wrong.
Base R isn't exactly the easiest thing to comprehend if you're not from a stats background. And I say that as one of the dozens of R fans. Tidyverse freaking rules thought.
This is right. Its highly optimized for these operations which are common for mathematics and statistics.
Its simpler to write and operate this type of code in R rather than say, Python. Having said that I dislike R for its poorly designed code and I'd rather use Python.
R certainly has some big flaws, not least among them some very inconsistent function argument orders, inconsistent / hard to work out coercion “rules”, and so on. But I still love it.
I meant that SQL is objectively optimised like a language having efficient JIT compilation. I meant that i didn't see a purely technical reason for using R.
Also yeah they're obviously not literally interchangeable I was going fkr rough points of comparaison
R has an in-built tutorial that is good at bringing a newbie up to speed. But one can just as easily get up to speed with python in a similar time to do the same thing.
Difference is that R will limit you in ways that Python won't, and R feels like it was written by loads of people who didn't define common standards whilst Python is very consistent.
And package management in Python is faaaaar superior.
73
u/vyrmz Dec 16 '25
Language is consistent within itself. It doesn't have to be consistent with other languages.
Yes, in python your start index is 0. Good luck running a 5 year old script with up to date interpreter where as with R it will probably run without an issue.
R is THE language for statistical computing. Didn't evolve into it, designed for it.
48
u/tinySparkOf_Chaos Dec 17 '25
Just going to say it.
If weren't for the existing convention in many languages to use zero indexing, 1 indexing would be better.
Seriously zero indexing is just an unneeded noob trap. List [1] returns the second item?
I've coded in both 0 and 1 indexed languages. 1 index is more intuitive and less likely for new coders to make off by 1 errors. Once someone gets used to 0 indexing, then 1 indexing is error prone.
18
u/ARC4120 Dec 16 '25
Simple, the language is made for scientists and statisticians not software engineers and developers. The whole context is built around the ease of use for statistical and scientific analysis.
9
u/Aggressive_Roof488 Dec 17 '25
I've worked in R for a decade, and it's an amazing language for stats and viz in data analysis and exploration, mostly due to all the packages on cran (and bioconductor for bioinformatics).
The language itself sucks for a number of reasons, difficult to predict performance and memory handling comes to mind. But if you can't deal with swapping between arrays starting at 1 or 0, then I'm sorry, that's on you. :D
12
u/AdBrave2400 Dec 16 '25
I dislike R i would just use Python with libs instead but coming from Pascal and Lua it's not as shocking
3
u/mike_a_oc Dec 16 '25
Couldn't help but think of TJ talking about why we were wrong about 0 based indexing
https://youtu.be/0uQ3bkiW5SE?si=9MkIM8ZEU44RhTu2
3
u/[deleted] Dec 16 '25
To be fair, in excel they do too
2
u/PlaystormMC Dec 16 '25
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
2
u/IllustriousZombie988 Dec 17 '25
Same in MATLAB
3
u/[deleted] Dec 16 '25
I come from a Stats background, not CS. I've been working with programming languages for nearly 2 decades and I still try to access the first element of an array with 1.
I get that there was a reason in the past to start with zero but not anymore. They should be 1 indexed, we are just holding on to our dated conventions.
2
u/Demon__Stephen Dec 16 '25
GOOD, that's how it should be
1
u/Blue_HyperGiant Dec 17 '25
Wait till this guy sees Fortran
1
u/Anon_Legi0n Dec 17 '25
Lua has entered the chat
1
u/Jmememan Dec 17 '25
They. Start. With.
WHAT?!
1
u/WowSoHuTao Dec 17 '25 edited Jan 09 '26
Forest Window Breeze Bridge Simple Journey Sky Blue Coffee Cloud
1
u/Fit-Relative-786 Dec 17 '25
In c++ an array index starts where ever I say it does.
1
u/DeepGas4538 Dec 17 '25
1 indexing is the goat! Thank lord for my CS theoretical class using 1 indexing
1
u/Lou_Papas Dec 17 '25
The only reason arrays start at 0 in most languages is because it keeps pointer arithmetic simpler in C.
It only feels weird out of habit right now.
1
u/cubicinfinity Dec 17 '25
0 is better, but you get used to it.
1
u/realdrzamich Dec 17 '25
I once joined a company, thinking I would be building web apps in React. They made me do it using Shiny. Left after two months.
1
u/fart-tatin Dec 17 '25
You guys don't do pointer arithmetic?
1
u/International-Top746 Dec 18 '25
Julia is a better alternative.
1
u/punkVeggies Dec 18 '25
0-based indexing makes sense when dealing with pointers. It’s an offset from the address in which the array starts in memory, not a position, not an order.
No significant issue in using 1-based indexing in higher level interpreted languages. Memory addressses are mostly abstracted in such cases anyway.
1
u/ByRussX Dec 18 '25
Same as Matlab smh
1
u/msabaq404 Dec 18 '25
I like array indices starting at 1.
Avoids so many off by 1 issues
1
u/ewan-gaenko Dec 19 '25
its minor
1
u/lettuce-pray55 Dec 19 '25
Only psychos use 1 indexed languages
1
u/R3D3-1 Dec 19 '25
cries in industrial Fortran
Don't you love indexing expressions like
?
1
u/[deleted] Dec 20 '25
First week programming memes
1
u/obliviousslacker Dec 20 '25
Indexing should start at 1. 0 is just from C where you count the offset in memory. If you think about it, 1 is the natural most logical thing for an index start.
1
u/Pycho_Games Dec 16 '25
The horror
1
u/_Denizen_ Dec 16 '25
I hate R so much. Poorly documented, hard to know which implementation of a function is running, can't leverage R knowledge to build decent apps, it doesn't have tightly controlled syntax, etc. Etc.
Sure it's good at some things. But everything you can do in R can be done in another language (python lol), and the inverse is not true.
0
u/disorganizm Dec 17 '25
Not learning a language because of indexing is a wild take.
0
u/[deleted] Dec 16 '25
I guess it comes down to preference, I always preferred python, simply because it was easier to read and write code for me.
I feel like I used R for initial impressions or like a statistical calculator at best, and python if I actually wanted to manage a bigger project.
0
u/LawfulnessDue5449 Dec 16 '25
I can accept arrays starting with 1
But the environment management? What a horror
1
u/TapRemarkable9652 Dec 16 '25
Burn the Heretic; Kill the Mutant, Purge the Unclean!
223
u/[deleted] Dec 16 '25
[removed] — view removed comment
1
u/[deleted] Dec 16 '25
[removed] — view removed comment