Indices starting at 1 are an abomination.

[klngarthur]

Java was released in 1995.

Java has its deficiencies too. Again, though, what is a deficiency from one point of view is a feature from another. There is no perfect programming language.

Good developers can overcome anything.

You act like Lua was forced on them. They chose it.

Python gets used for lots of scripting too. Would lua be improved with significant white-space? Discuss

This would probably not be in keeping with the tenets of the language, so no it would not be improved. Lua, as i have touched on repeatedly, is designed to be picked up quickly and be readable by non-programmers, which is why its control structures are somewhat verbose (if .. then .. end or for k,v in pairs(table) do .. end). Making it white space dependent would run contrary to this goal. That does not mean that significant white spacing is a bad language feature, though. It can be quite useful, especially in markup languages (see haml, sass, yaml, etc).

 

[LDiCesare]

I'd like to mention that, although I prefer languages that start arrrays at 0, lua is not the only one to start at 1. FORTRAN did it too. It's not like it's the epitome of good language, obviously, but not *every* other language starts at 0.
Starting at 1 has its pros and cons. However there is one big con to starting at 1, but it shouldn't matter for most lua users: Lua is coded in C and interfaces with C. Should you want to pass some data to lua from C or the converse, you may end up by mistake sending an array index, and you'll be in deep trouble if you don't do an addition. I guarantee that when you stumble upon that, a lot of swearing is sure to follow.

 

[Rashiminos]

low level languages, like C,

Assembly says hai.

 

[skywalker]

The standard is to start from 0, because it makes offsets much faster to calculate. Please don't say something about mathematicians expectations of indexes, they are unrelated to the reality of programming as it has been practiced for decades.

It has nothing to do with speed of calculation and has everything to do with a convention that started with a minor elegance to the C definition of the subscript notation (x[y] -> *(x+y)). It would have been trivial for C to instead map x[y] to *(x+y-1).

That said, it's a nice convention and people should follow it.

 

[Fnugus]

With the risk of being very wrong in my views, I think that whether arrays start at 0 or 1 is more of a cosmetic difference rather than an obstacle. In a 100x100 map, distance between two coordinates ends up the same, no matter where the array began, as distances should be calculated relative to the starting location. In all my experience with programming, I could swap the beginning of my two-dimensional maps to start at 30,30 without any code going awry.

 

[Zetetic Apparat]

No, Fnugus, as spoooq has calmly explained, he hates you, he hates your family and it's all your fault. I only wish he could find the reserves to throw more meaningless anger and offensiveness into this thread.

 

[LDiCesare]

Ok, Indices starting at 1 ARE A PAIN.
for plotIndex = 1, self.iH * self.iW do
is NOT natural when it's mixed with
for y = 0, self.iH - 1 do
for x = 0, self.iW - 1 do
local plotIndex = y * self.iW + x + 1
Please notice the damn, horrible, nasty +1 which you WILL forget.

I end up writing this piece of :

    South = function(self, x, y)
        if y == 0 then return nil end
        return (y-1)*self.iW + x + 1
    end,
    North = function(self, x, y)
        if y == self.iH - 1 then return nil end
        return (y+1)*self.iW + x + 1
    end,
    West = function(self, x, y)
        if x == 0 then return y*self.iW + self.iW - 1 + 1end
        return y*self.iW + x - 1 + 1
    end,
    East = function(self, x, y)
        if x == self.iW - 1 then return y*self.iW + 1 end
        return y*self.iW + x + 1 + 1
    end,
    NorthWest = function(self, x, y)
        if y == self.iH - 1 then return nil end
        return self:West(x, y + 1)
    end,
    SouthWest = function(self, x, y)
        if y == 0 then return nil end
        return self:West(x, y - 1)
    end,

Notice how the +1's are here just because?
On the other hand, lua makes for nice handy stuff like that:

    Neighbours = function(self, x, y)
        local result = {}
        result[self.South] = self:South(x, y)
        result[self.North] = self:North(x, y)
        result[self.West] = self:West(x, y)
        result[self.East] = self:East(x, y)
        result[self.NorthWest] = self:NorthWest(x, y)
        result[self.SouthWest] = self:SouthWest(x, y)
        return result
    end,

which lets you put nil in a table and then iterate on the list of neighbours without caring whether there are 4, 5, 6 or whatnot.
But starting at 1 is a pain.

 

[oChuckles]

I agree that it's a bit more annoying for graphical purposes, but I think it's a bit less annoying for logical purposes. Normally it just means putting +1's and -1's in different places, but when it comes to graphs, it's kind of odd.

What's wrong with starting your indicies just for the map at 0? Just loop through it with a numerical for whenever you need to instead of using ipairs or whatever. They're deprecating ipairs next version anyway.

If you need to swap back and forth quickly (but not efficiently):

--I like to denote translation functions as "afromb" rather than "btoa" because it puts the return type on the left.

function OneFromZero(t)
  return {t[0], unpack(t)}
end

function ZeroFromOne(t)
  local r = {}
  for i = 1,#t do
    r[i-1] = t[i]
  end
  return r
end

 

[LDiCesare]

The problem is the map coordinates in game start at (0,0), but the array you must pass to the game with the map data starts at 1.
It's not a language issue. It's the way Civ V decided to use it, which is not consistent.
If all had been start at 0 or start at 1, it would have been easy, but this way it's a bastard of both methods.

 

[spoooq]

no, fnugus, as spoooq has calmly explained, he hates you, he hates your family and it's all your fault.

Quoted for truth

 

[spoooq]

It has nothing to do with speed of calculation and has everything to do with a convention that started with a minor elegance to the C definition of the subscript notation (x[y] -> *(x+y)). It would have been trivial for C to instead map x[y] to *(x+y-1).

That said, it's a nice convention and people should follow it.

Just changing the language-level definition would be lying to the programmer and would have resulted in delayed pain. It's not like mixing C and assembly, especially at that time, was a niche thing to do.

 

[spoooq]

FORTRAN did it too.

Yep, that mathematical FORmula TRANslator did indeed start from 1, so the maths guys could do things their way. The first spec was written in 1954! There were no established standards then.

Lua is coded in C and interfaces with C.

Exactly. Scripting C programs is pretty much the entire point of Luas existence. Noone really writes programs entirely in Lua. And unlike FORTRAN, Lua was created in 1993, so it does not have a free pass based on age and intended audience.

With the risk of being very wrong in my views, I think that whether arrays start at 0 or 1 is more of a cosmetic difference rather than an obstacle. In a 100x100 map, distance between two coordinates ends up the same, no matter where the array began, as distances should be calculated relative to the starting location. In all my experience with programming, I could swap the beginning of my two-dimensional maps to start at 30,30 without any code going awry.

Sure you could. But why would you? Would it help the next time you or someone else looked at the code? You would be wondering what the magic number was for. Maybe you reserved a bit of space to display a logo or border or something? Who knows??? Or you could just do things the way every programmer expects, and they could use their time for building on your code rather than trying to figure out what it does. If you start from 1, they may not even notice, and will just assume you started from 0. Principle of least surprise and all that. The point is to not arbitrarily make life more difficult.



Now that the zeros have defeated the ones and won the thread, can we please turn our attention to the real issue here: the vital war of endianness! After that, we should discuss text editors of course.