Support NeoGAF

[Water]

Erm. Whether it breaks expectation depends on what your goal is. 9 / 6 can be seen 1 with a remainder of 3 or 1 and a half.
If you want to know how many complete groups can be formed, you care about only the never 1. For recipes and things of that nature, you want 1.5 of whatever your unit of measure is.

This is not a question of whether integer division is useful - clearly it is. It just shouldn't look like division.

Outside programming, "/" is division, and that's what everyone new to programming will expect. Using it also for integer division breaks the expectation. We aren't running out of ASCII characters, so why not use "//" (Python) or "div" (Haskell) to make it clear that a different operation than division is intended?

 

[CrankyJay]

This is not a question of whether integer division is useful - clearly it is. It just shouldn't look like division.

Outside programming, "/" is division, and that's what everyone new to programming will expect. Using it also for integer division breaks the expectation. We aren't running out of ASCII characters, so why not use "//" (Python) or "div" (Haskell) to make it clear that a different operation than division is intended?

You can overload operators to achieve this sort of functionality.

 

[Laurentius]

Has anybody done any Android programming in Python? Been looking at Kivy. Wondering if anybody here would recommend it or not.

 

[0xCA2]

I'm trying to learn about version control systems this Summer. Where should I start?

 

[V_Arnold]

Visual Studio has a cool UML designer that will lay out your classes and member variables in the background as you map things out. It's really wicked, but apparently it's only available in like the highest paid tier their is.

Hmm, sounds like you maybe want to use UML diagrams?

Thank you. Yes, I think that this is what I am looking for. Will save me a LOT of headache in the long run.

Now to figure out which one to get and try .D
http://en.wikipedia.org/wiki/List_of_UML_tools

 

[Laurentius]

I'm trying to learn about version control systems this Summer. Where should I start?

Here's a good way to start learning Git:

https://try.github.io/levels/1/challenges/1

 

[close to the edge]

Thank you. Yes, I think that this is what I am looking for. Will save me a LOT of headache in the long run.

Now to figure out which one to get and try .D
http://en.wikipedia.org/wiki/List_of_UML_tools

Violet is decent and very easy to use when you get started.

 

[tokkun]

This is not a question of whether integer division is useful - clearly it is. It just shouldn't look like division.

Outside programming, "/" is division, and that's what everyone new to programming will expect. Using it also for integer division breaks the expectation. We aren't running out of ASCII characters, so why not use "//" (Python) or "div" (Haskell) to make it clear that a different operation than division is intended?

If Python really wants to abandon programming language conventions for consistency with other forms of notation they better replace the bitwise XOR operator too, since '^' is more commonly used to express exponentiation and conjunction outside of programming.

 

[Granadier]

This is not a question of whether integer division is useful - clearly it is. It just shouldn't look like division.

Outside programming, "/" is division, and that's what everyone new to programming will expect. Using it also for integer division breaks the expectation. We aren't running out of ASCII characters, so why not use "//" (Python) or "div" (Haskell) to make it clear that a different operation than division is intended?

The '//' would just cause more issues with confusing it for comment declarations though wouldn't it?

I somewhat agree that it's confusing, but it seems to me like something that is only confusing until you learn what the differences are.

I don't have experience with it in the real world though, so maybe it's still a problem writing full software.

 

[Water]

If Python really wants to abandon programming language conventions for consistency with other forms of notation they better replace the bitwise XOR operator too, since '^' is more commonly used to express exponentiation and conjunction outside of programming.

It should be obvious to you that '^' isn't even remotely the same thing. Regardless of whether '^' was originally a reasonable choice for bitwise xor, there's much less reason to touch it now than '/'.

'^' is not currently used in programming for two subtly different meanings in situations where it is easy to accidentally do one instead of the other. If '^' applied to unsigned integers was bitwise xor, and '^' applied to any other numbers was exponentiation, one of those uses absolutely should get its own syntax.

You can find '/' on a basic calculator. It's so well-known that everyone at primary school level and above associates it with a common meaning. The '^' symbol is used only in advanced math, and as you pointed out, has several common uses so even people who are familiar with it would have different associations. Both bitwise xor and exponentiation are relatively rare in code, further reducing the payoff for fiddling with them.

If one was to shuffle operators around for consistency with mathematical notation, the first stop after '/' would be '='. But it doesn't have the double-meaning problem of '/', so fixing it would mainly benefit introductory programming students.

 

[0xCA2]

Here's a good way to start learning Git:

https://try.github.io/levels/1/challenges/1

Thanks! I'll check this out.

 

[Water]

The '//' would just cause more issues with confusing it for comment declarations though wouldn't it?

Of course not. Python line comments start with '#'. If Python used '//' for line comments, using '//' anywhere in the code would be impossible rather than confusing.

I somewhat agree that it's confusing, but it seems to me like something that is only confusing until you learn what the differences are.

If it was merely confusing, like using '=' for assignment is, it wouldn't be so much of an issue. I know perfectly fine what the difference is, but I could still accidentally write "22 / 3" one day when what I intended was "22 / 3.0f". The compiler wouldn't say anything, and the result would be pretty close to correct, which decreases the probability of finding the bug before it does damage. Also, what if I don't screw up and correctly write "getSomeNumber() / 3" intending to get integer division, but a year later I or someone else happens to change getSomeNumber() to return a float instead of an int? The old code breaks silently. Better syntax can prevent that from happening entirely. Readability is also improved; put the expression below in the middle of a bunch of calculations, and it's far too easy to scan as "ok, divide x by 12 and then by 3.5". Not so after syntax fix.

x / 12 / 3.5
x // 12 / 3.5

 

[Chris R]

We could just do it like VB.Net does

10 \ 8 = 1
10 / 8 = 1.25

 

[Granadier]

Of course not. Python line comments start with '#'. If Python used '//' for line comments, using '//' anywhere in the code would be impossible rather than confusing.
If it was merely confusing, like using '=' for assignment is, it wouldn't be so much of an issue. I know perfectly fine what the difference is, but I could still accidentally write "22 / 3" one day when what I intended was "22 / 3.0f". The compiler wouldn't say anything, and the result would be pretty close to correct, which decreases the probability of finding the bug before it does damage. Also, what if I don't screw up and correctly write "getSomeNumber() / 3" intending to get integer division, but a year later I or someone else happens to change getSomeNumber() to return a float instead of an int? The old code breaks silently. Better syntax can prevent that from happening entirely. Readability is also improved; put the expression below in the middle of a bunch of calculations, and it's far too easy to scan as "ok, divide x by 12 and then by 3.5". Not so after syntax fix.

x / 12 / 3.5
x // 12 / 3.5

Well I was referring to programming languages besides Python when talking about '//', but I can see your point.

That's the portion of the 'real world' programming I mentioned I didn't have experience with. Your example of the method change from returning a float instead of an int is a good example.

How could it change though without shifting to a different programming language standard? If they do something with Java or C or C++ like they did between Python 2 -> 3 they would either break legacy code bases, or split the language in two. This question is asked out of curiosity, not a challenge to your argument.

We could just do it like VB.Net does

10 \ 8 = 1
10 / 8 = 1.25

This seems far worse in my opinion.

 

[Slavik81]

The '//' would just cause more issues with confusing it for comment declarations though wouldn't it?

I somewhat agree that it's confusing, but it seems to me like something that is only confusing until you learn what the differences are.

I don't have experience with it in the real world though, so maybe it's still a problem writing full software.

Here's me 5 years ago when I was fairly new to programming:

It took me 15 full minutes to figure out that the reason why my code didn't work was that 3/2 returns 1 in C#.

*sigh*

3f/2f = 1.5

That's really expected behavior though in a lot of languages.

It was unexpected for me! :lol

I understand why I got that, but perhaps they should have had a separate operator for int and float division. Yeah, that's right. I'm calling out the original designers of C.

After all, it's kind of weird that:
3 / 2 * Math.PI = 3.14....
Math.PI * 3 / 2 = 4.71....

(and that difference was my problem)

I rarely make those sorts of errors now, but only because I maintain constant vigilance. It's easy to screw up.

 

[tokkun]

It should be obvious to you that '^' isn't even remotely the same thing. Regardless of whether '^' was originally a reasonable choice for bitwise xor, there's much less reason to touch it now than '/'.

'^' is not currently used in programming for two subtly different meanings in situations where it is easy to accidentally do one instead of the other. If '^' applied to unsigned integers was bitwise xor, and '^' applied to any other numbers was exponentiation, one of those uses absolutely should get its own syntax.

You can find '/' on a basic calculator. It's so well-known that everyone at primary school level and above associates it with a common meaning. The '^' symbol is used only in advanced math, and as you pointed out, has several common uses so even people who are familiar with it would have different associations. Both bitwise xor and exponentiation are relatively rare in code, further reducing the payoff for fiddling with them.

If one was to shuffle operators around for consistency with mathematical notation, the first stop after '/' would be '='. But it doesn't have the double-meaning problem of '/', so fixing it would mainly benefit introductory programming students.

I don't really agree with that. I wouldn't characterize exponentiation as 'advanced math'. Maybe it is more advanced than division, but I'm not sure if differentiating between something you learn in elementary school vs something you learn in middle school is really germane to the question of whether a programmer is going to be accustomed to the symbol having a certain meaning.

You can easily do something like

int n_to_the_tenth = n ^ 10;

It compiles just fine, and can be just as confusing to novices as integer division. It is really a fairly common mistake. The caret appears on some calculators as the exponentiation symbol:

It also is what you use to perform exponentiation in Excel, which many people learn to use before programming.

But I digress...

I do agree that having separate operators is better than having the operation depend on the datatypes being used. That is a recipe for disaster, especially when the datatypes themselves are R-values generated from nested expressions. But that does not mean that I agree with Python's decision to redefine '/'.

If you are worried about the problem of things silently breaking, what is going to happen to Python 2 code where '/' meant integer division when it is run in a Python 3 interpreter where '/' means fractional division? That is a nightmare of code silently breaking. You really almost have to admire the incredible quixotic obstinance. If they just made '//' the fractional division operator and left '/' as integer division, they could maintain backwards compatibility. Instead they will throw tons of legacy code users under the bus just because they want the symbol to match up more closely with its use in a different domain.

 

[r1chard]

Has anybody done any Android programming in Python? Been looking at Kivy. Wondering if anybody here would recommend it or not.

Yes, I have (match3 on the Play Store) and it's a pretty good option. I've also done Java-based app development and really the line for me comes down to how much of the Android API you're expecting to use. For a game (or other mostly-multimedia application) Kivy is fine because you're typically not going to be using much Android API stuff, but for something else that integrates with multiple Android services, you probably want to go with Java. That's not to say you can't integrate with Java, just that there's that slight impedance mismatch with the Java/Python layer.

Kivy's also nice because the same code can target iOS and desktop OSes with no modification. And you're writing in Python, which I happen to like

Edit: Oh, I also released the first version of that game using pgs4a which uses the same underlying Python/Java bridge, but is far less useful in the mobile context since it doesn't use the GPU. Handy for mucking about or really quickly throwing together something using the pygame API which doesn't need heavy pixel-pushing (or uses the limited power intelligently which pygame has APIs for).



I recommend those discussing the change of the division operator in Python 3 go read the relevant PEP "PEP 238 -- Changing the Division Operator". Note that the transition started back in Python 2.2 (not 2.6 as I'd erroneously recalled). 13 years ago now.

 

[Laurentius]

Yes, I have (match3 on the Play Store) and it's a pretty good option. I've also done Java-based app development and really the line for me comes down to how much of the Android API you're expecting to use. For a game (or other mostly-multimedia application) Kivy is fine because you're typically not going to be using much Android API stuff, but for something else that integrates with multiple Android services, you probably want to go with Java. That's not to say you can't integrate with Java, just that there's that slight impedance mismatch with the Java/Python layer.

Kivy's also nice because the same code can target iOS and desktop OSes with no modification. And you're writing in Python, which I happen to like

Edit: Oh, I also released the first version of that game using pgs4a which uses the same underlying Python/Java bridge, but is far less useful in the mobile context since it doesn't use the GPU. Handy for mucking about or really quickly throwing together something using the pygame API which doesn't need heavy pixel-pushing (or uses the limited power intelligently which pygame has APIs for).

Cool, thanks! I've been wanting to learn a bit of Android development, so it sounds like Kivy should work for me starting out. Python is the language I'm most familiar with, and I haven't worked with Java in about 3 years (and don't really feel a huge desire to), so being able to do it in Python would be ideal for me. I suppose I can at least mess around with it, and if it can't do what I want/need, I can brush up on my Java.

 

[Water]

I don't really agree with that. I wouldn't characterize exponentiation as 'advanced math'. Maybe it is more advanced than division,

You can drop the 'maybe'. Exponentiation is more advanced than division, and obviously so. Anyway, that was not my justification for the syntax.

but I'm not sure if differentiating between something you learn in elementary school vs something you learn in middle school is really germane to the question of whether a programmer is going to be accustomed to the symbol having a certain meaning.

It is not just a matter of when you learn them, but how strongly a symbol is associated to a particular thing. '/' is familiar and intuitive to pretty much everyone since it's standard math notation - if you have been taught division and fractions at all, then you have drawn that dividing line on paper countless times, whether horizontal or slanted. This is not even in the same ballpark as "well, ^ stands for exponentiation in Excel and some scientific calculator key labels". When I started programming, I would personally have found conjunction to be the most natural meaning for '^' since I had just been taught boolean algebra.

You can easily do something like "int n_to_the_tenth = n ^ 10;"

It compiles just fine, and can be just as confusing to novices as integer division. It is really a fairly common mistake.

In my experience, if they associate '^' with exponentiation, it is not strongly. In the students I've worked with, it's not a common mistake to begin with, and I have never seen anyone repeat the mistake after being informed once that '^' is not exponentiation, but they happily keep trying to do division with 'x / y' despite x and y being integers.

I do agree that having separate operators is better than having the operation depend on the datatypes being used. That is a recipe for disaster, especially when the datatypes themselves are R-values generated from nested expressions. But that does not mean that I agree with Python's decision to redefine '/'.

If you are worried about the problem of things silently breaking, what is going to happen to Python 2 code where '/' meant integer division when it is run in a Python 3 interpreter where '/' means fractional division? That is a nightmare of code silently breaking. You really almost have to admire the incredible quixotic obstinance. If they just made '//' the fractional division operator and left '/' as integer division, they could maintain backwards compatibility. Instead they will throw tons of legacy code users under the bus just because they want the symbol to match up more closely with its use in a different domain.

And how would that guarantee backwards compatibility? You'd have to go through the code anyway to change every '/' into '//' that was intended to be division instead of integer division! (Unless you keep the meaning of '/' intact and it will also do division on floats, but that means you are still totally letting the programmer screw themselves, and are merely providing a new defensive programming syntax '//' which one has to remember to use. I'm not a Python coder, but that doesn't sound very Pythonic to me. Or a good idea in general.)

Even if I've somehow understood incorrectly and your suggested scheme would provide the full safety of the first solution, I don't find slight short-term convenience in code reuse to be enough of a reason to tolerate permanently unintuitive and tortured syntax. Using '//' for ordinary division would go against not just deeply ingrained association from math, but every other programming language that sensibly uses '/' to denote division (even if some of them have an unfortunate bug when both operands are integral).

In other words, I agree with the PEP r1chard linked:
"the cost of leaving this bug in the language will eventually outweigh the cost of fixing old code -- there is an upper bound to the amount of code to be fixed, but the amount of code that might be affected by the bug in the future is unbounded."

 

[mugurumakensei]

After trying, -3 / 2 in python 2.6 and trying -3 // 2 in python 3. I think I will ignore Python's "integer" division. It doesn't work properly. -3 / 2 in integer division should be -1. Python says -2 since it uses floor division when negatives should really be expected to do a ceiling instead.

 

[OlympicTechno]

Hi,

I'm having trouble with a javascript assignment of mine. I have a 10x10 grid which is made from a two-dimensional array. The user clicks on a cell in the grid and enters their position by typing the letter 'U'. We are supposed to be able to control this letter so it can move around the grid with a key press (up,down,left,right).

What would be the best way to implement this? I know I have to alter the position of the array somehow but I am having alot of trouble.

Thanks.

 

[oxrock]

I'm surprised that my silly oversight sparked such a commotion, haha.

 

[Jackben]

I'm surprised that my silly oversight sparked such a commotion, haha.

All is forgiven, as long as you're using two spacebar taps instead of tab to space your code...

*lights fire and runs*

 

[PetriP-TNT]

Hi,

I'm having trouble with a javascript assignment of mine. I have a 10x10 grid which is made from a two-dimensional array. The user clicks on a cell in the grid and enters their position by typing the letter 'U'. We are supposed to be able to control this letter so it can move around the grid with a key press (up,down,left,right).

What would be the best way to implement this? I know I have to alter the position of the array somehow but I am having alot of trouble.

Thanks.

Want to see how not to do it?

http://jsfiddle.net/78mwT/3/

 

[phoenixyz]

All is forgiven, as long as you're using two spacebar taps instead of tab to space your code...

*lights fire and runs*

I think the logs in that fireplace are still too wet.

 

[OlympicTechno]

Want to see how not to do it?

http://jsfiddle.net/78mwT/3/

Ah! This helps a great deal! Thanks for the assistance.

 

[oxrock]

All is forgiven, as long as you're using two spacebar taps instead of tab to space your code...

*lights fire and runs*

I shall live and die by the TAB! (clueless as to what this references)

 

[CrankyJay]

meh, nvm

 

[Jackben]

I shall live and die by the TAB! (clueless as to what this references)

Just one of the biggest, most pedantic programming arguments

 

[BreakyBoy]

All is forgiven, as long as you're using two spacebar taps instead of tab to space your code...

*lights fire and runs*

You have my sword.

 

[corn_fest]

I really don't get why you'd prefer spaces. If you use tabs, anyone looking at your code can adjust the tabs' size to their own preference in their editor. They serve a purely functional purpose - to denote indentation.
If you use spaces you're hardcoding the formatting into the document. It's like the old HTML4 -> HTML/CSS split debate. In that case, everyone eventually agreed that it made sense to separate style from content. I don't see how the same argument can't be applied to using spaces.

(I realize that this is an ancient debate, and will accomplish nothing)

 

[phoenixyz]

I think the logs in that fireplace are still too wet.

I rest my case.

 

[tuffy]

I really don't get why you'd prefer spaces. If you use tabs, anyone looking at your code can adjust the tabs' size to their own preference in their editor. They serve a purely functional purpose - to denote indentation.

That's the justification behind Smart Tabs. Blocks are indented by tabs but alignment uses spaces. The result is that code looks correct regardless of what the viewer's tab size is.

 

[BreakyBoy]

I really don't feel that strongly about it, but I will say that it's my experience that most people that prefer tabs are the ones that have never had to monkey-patch something in a remote environment via SSH.

Now that I've stoked the flames...

Either way, it's a moot point if you use a good editor with proper Tabs as Spaces support (or Smart Tabs as tuffy pointed out).

 

[FallingEdge]

tabs....

cmon son

#TeamSpace

 

[poweld]

tabs....

cmon son

#TeamSpace

i used to be a tab guy, but recently converted.

so nice to see my code look (mostly) the same everywhere it goes.

edit: 2 spaces, to be specific. i used to be forced to use a style standard where a tab was... 8 spaces. ouch.

 

[BreakyBoy]

Here's the one that grinds my gears.

Follow the Eighty Column Rule people!

Particularly if you're a spaces person.

 

[hateradio]

I just want to say that I hate Google and the way it changes things for no apparent reason other than to say: Fuck you guys, we're doing what we want. -__-


These are just YT embedded player code related feelings relaying the overall scope of the downfall of YT, btw. No hard feelings.

 

[Chris R]

For someone who moves around code using arrow keys you space coders are the worst. Tabs means I get around quickly

I just want to say that I hate Google and the way it changes things for no apparent reason other than to say: Fuck you guys, we're doing what we want. -__-


These are just YT embedded player code related feelings relaying the overall scope of the downfall of YT, btw. No hard feelings.

What changed with embedded youtube stuff?

 

[usea]

For someone who moves around code using arrow keys you space coders are the worst. Tabs means I get around quickly

I feel you, for real. But it's somewhat mitigated if your editor has good home key support (home alternating between beginning of line, and first non-indent character).

 

[poweld]

For someone who moves around code using arrow keys

/r/vim would like to have a little chat

 

[Elfforkusu]

tabs....

cmon son

#TeamSpace

#TeamWhyDoesntYourIdeFixItForYou?

Code conventions are essential and 100% arbitrary. I slightly prefer tabs, but I won't use an IDE that can't automagically turn my hammering of the tab key into spaces if the project requires that.

 

[Treechopper]

Here's the one that grinds my gears.

Follow the Eighty Column Rule people!

Particularly if you're a spaces person.

This is what's really worth debating. I try to conform to this rule as much as possible, but I prefer snake case and sometimes variable names are just long. Even when they're cleaned up the 80 column rule can start feeling restrictive.

 

[Mr.Mike]

So are there any pros to using spaces instead of tabs?

 

[usea]

So are there any pros to using spaces instead of tabs?

If you don't have the luxury of working with modern or fancy IDEs, it's possible you might be writing code in something that doesn't work well with tabs for some reason.

Also in some arenas (languages, frameworks, repositories, companies), using tabs is swimming against the current. The social pressure is extreme.

 

[mugurumakensei]

Here's the one that grinds my gears.

Follow the Eighty Column Rule people!

Particularly if you're a spaces person.

Rule sucks for HTML or well any markup language.

 

[Elfforkusu]

Eighty column rule made a lot more sense when the default resolution was 640x480.

I'd say I follow more like the 130 column rule.

 

[Slavik81]

I really don't get why you'd prefer spaces. If you use tabs, anyone looking at your code can adjust the tabs' size to their own preference in their editor.

But the default is always wrong, requiring adjustments by every coder in every editor. It also makes things like adhering to the 80 column rule tricky if tabs are variable length.

 

[usea]

But the default is always wrong, requiring adjustments by every coder in every editor. It also makes things like adhering to the 80 column rule tricky if tabs are variable length.

80 column rule is dumb anyway. Also many more characters than tabs are variable width. What happens when there's unicode symbols in your code?

The default isn't always wrong. Each editor has its own default. So it goes both ways. Also the adjustment only happens once. You're talking a few seconds, one time, maybe. The smallest of concerns.

 

[Water]

80 column rule is dumb anyway. Also many more characters than tabs are variable width. What happens when there's unicode symbols in your code?

Those Unicode symbols in a fixed width font aren't visually variable width, though?

I have never thought 80 column rule was a good idea, and it's a far worse idea in some languages than others.