I agree, but since there's no many definitive reasons to start at 1 instead of 0, I'd say... Why bother?
Out of curiosity (I need to dive more into F#), would this also be correct?
let rec someRecursiveHelper acc = function
| 0 -> acc
| n -> someRecursiveHelper (acc+1) (n-1)
let someRecursiveFunction = someRecursiveHelper 0I actually prefer 1-indexed sequences and closed intervals. The reason is that I just think the nth element in a sequence should be indexed as n, not n-1. It's just... more... intuitive! And I also don't believe in array iteration by number, anyway. BCPL actually had a for-each construct and Ken Thompson removed it for simplicity in B. What a bad move! Arrays should have always been two words. Etc. As for the intervals, we clearly just need to range constructs. One which has a start and an end (closed interval). And another which has a closed start and how many elements you want in the sequence.
Yeah, that works, and the function keyword is handy. But nowadays I wish for SML's/Haskell's version of the same thing, which lets you match multiple arguments at once. Yes, I wrote it too fast and flipped my arms, btw. What I meant was
let rec f n acc =
if n > 0 then f (n-1) (acc+1)
else accSeems logical, but I must be too used to 0-indexed, because I'm having troubles with 1-indexed. I believe I associate now the index with an offset.
I also don't, but there's plently of cases where iterators don't work. Each case you couldn't use a list, in fact. For example, most divide-and-conquer algorithms. Also, when you have several tables where A and B are related, having a common index is really handy.
At least, it's coming back on C++X11
Or n-tuitive
int count(uint64_t x) {
int v = 0;
while(x != 0) {
x &= x - 1;
v++;
}
return v;
}No way! Reusing intuition saves us from having to teach more. In math, 0 indexing if sequences corresponds to the number of times a transformation is applied to the initial value. The first is 0 because it has not yet been transformed. Since most programming sequences are not like mathematical sequences it seems far more appropriate to just requisition natural language and the most intuitive definitions: the number of elements up to and including the ith element in a sequence should be i.
Touche. I was only stating my preference because one of the arguments for 0 indexing is that if you are using it frequently, you should be able to easily calculate the length of the interval. But I don't think you should be using it frequently!
Oh, no way. That would make the grammar highly context sensitive!
Practically 100% of the functional syntax of OCaml is available in F# because it was designed that way! You get fun.
Negatives. The function is defined inductively with 0 as the base case so supplying a negative number would cause it to not terminate.
Uh oh!
Sounds like you do the right thing. I would expect engineers to make use of exceptions (although error codes are preferable) and I would expect a science program to occasionally use list comprehensions just because they're so succinct.
Using exceptions as non-lexical control flow is terrifying.
Mono has gotten fantastically better ever since .NET open sourced and .NET core became a thing. You will probably like the language, as long as you are not attached to your functors.
You used to work at INRIA? Wow.
I've been using it for a year (1.0). One of my favorite programming languages. Definitely an improvement over C++ and probably most other languages you can think of. Its primary abstraction mechanism (traits) is very well designed and comes from Haskell and Scala. My favorite part is that it proves that a high level program doesn't need to be slow at all.
template <typename T>
class SomeRandomClass
{
public:
T storeSomeStuffMate;
SomeRandomClass<T>* awYiss;
SomeClass(T feedMe)
{
storeSomeStuffMate = feedMe;
awYiss = NULL;
}
};template <typename T>
void SomeRandomClass<T>::someRandomFunction() {
this.doSomethingCool();
}This is why I think it's better to go from C/C++ to Java instead of the reverse order.
Yeah I had a hard time too last semester, it felt so fragile. Even when some miracle happened and it finally compiled, I either got some memory problem or something literally no one in history has ever gotten according to google. If you have the time you should write some unit tests for even the most basic things, they really helped me
I can understand why it would be better, but I followed this path, and I'm totally allergic to Java. In fact, it's at the very bottom of the list of languages I'd like to use.
After having been burned last summer by numpy implicit casts*, I'm even more fine with explicit casts than before. And yes, Rust a nice language.
>>> T = np.array([9876543210123456789], dtype='uint64')
>>> T[0]
9876543210123456789
>>> T[0]=T[0]+1
>>> T[0]
9876543210123456512It's not just you. I've talked to people who work on Java (note that's ON java, not IN. As in, the language itself) who hate it
It's nice that you can avoid a lot of the memory management, but that require a lot of care (and understanding) when you write constructors (such as copy constructors), if you don't want the program to spend a lot of time copying the same data. I can understand how it's hard for newcomers.
Aww... I feel their pain...
Heh, but imagine if you learned it the other way and the way you feel about Java was the way you felt about C/C++ or any other high level language that allows you to have a similar amount of direct control on memory management.
I still have nightmares from my computer architecture classes.
The way memory is handled isn't really the thing I dislike in Java. I've used several languages with different philosophies about this. It's a matter of design choices, design patters, verbosity, problems I've had with it (for example, when you want to include a look-up table in the code and the compiler refuse because your function is "too big to compile"), etc.
I think Java gives you too much control over memory.
Lol
// old way
Foo *f = new Foo(1, 2, 3);
// new way
auto f = std::make_unique<Foo>(1, 2, 3);