python - tail stuck under the rocks?
-
Okay, that was an analogy. I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these) For example,
If x is a:
do //indented & worksis different from
if x is a:
do //Non-indented & throws errorIt's funny, and doesn't this sound rudimentary and a bit annoying? :)
Cobol - and Fortran - didn't interpret indents semantically. The coding sheet (or individual line, for those who never saw a coding sheet) was divided into column (or fields of the line), with different functions: Label, line continuation marker, structure level markers, line sequence number etc. This was defined by the column (/field): Within the main field, you could indent or not without changing the semantics. The coding sheets had heavy lines separating the columns; you never misplaced any element accidentally. So even though positioning (in one column, or another column) was significant, it wasn't quite like Python but far more controlled and well defined, and it was very difficult to make mistakes that could pass by without being detected. Those languages had far worse defects ... :-)
-
Okay, that was an analogy. I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these) For example,
If x is a:
do //indented & worksis different from
if x is a:
do //Non-indented & throws errorIt's funny, and doesn't this sound rudimentary and a bit annoying? :)
The indentation is part of Python, take it or leave it. Where it really gets annoying is when you try to cut'n'paste snippets. 8 space characters does not equal 1 tab. I use Vim with a tab equivalent to 2 spaces for real confusion.
-
Okay, that was an analogy. I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these) For example,
If x is a:
do //indented & worksis different from
if x is a:
do //Non-indented & throws errorIt's funny, and doesn't this sound rudimentary and a bit annoying? :)
Man, us "Pythonistas" are getting tired of this criticism. Do you indent your C? Of course you do, it's impossible to read poorly indented code. Does your C compiler whinge at you when you forget curly brackets? Of course it does, they define blocks. Except, you're already defining blocks for human eyes with indentation. Why do you also need to define them for machine eyes with curly brackets? Source code is for humans, not machines.
-
Okay, that was an analogy. I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these) For example,
If x is a:
do //indented & worksis different from
if x is a:
do //Non-indented & throws errorIt's funny, and doesn't this sound rudimentary and a bit annoying? :)
-
Okay, that was an analogy. I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these) For example,
If x is a:
do //indented & worksis different from
if x is a:
do //Non-indented & throws errorIt's funny, and doesn't this sound rudimentary and a bit annoying? :)
This single feature has held me back from investing time into this language. Doing some RCA my opinion is that technology like language generators has promoted the creation of marginally different quite a few languages—so called jvm languages — There was php and Perl. Anyone not intellectually lazy and a bit more egoless would have perfected php instead of whipping up a new language with brain dead features. Not sure python space or dos backslash takes the top spot for an epoch of productivity killer. Backslash inventor now admits that is his worst decision.
-
Okay, that was an analogy. I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these) For example,
If x is a:
do //indented & worksis different from
if x is a:
do //Non-indented & throws errorIt's funny, and doesn't this sound rudimentary and a bit annoying? :)
More python indention confusion ???
# Python program to check if the input number is prime or not
num = 15
take input from the user
num = int(input("Enter a number: "))
prime numbers are greater than 1
if num > 1:
for i in range(2,num):
if (num % i) == 0:
print(num,"is not a prime number")
print(i,"times",num//i,"is",num)
break
else:
#print(num % i)
print(num,"is a prime number")if input number is less than
or equal to 1, it is not prime
else:
print(num,"is not a prime number")What the heck is that else: statement doing out there, who does it belong to? :)
-
Man, us "Pythonistas" are getting tired of this criticism. Do you indent your C? Of course you do, it's impossible to read poorly indented code. Does your C compiler whinge at you when you forget curly brackets? Of course it does, they define blocks. Except, you're already defining blocks for human eyes with indentation. Why do you also need to define them for machine eyes with curly brackets? Source code is for humans, not machines.
So maybe we should shut up and accept that Python Is, After All, Doing The Right Thing? No. If your attitude is that "Noone should keep on critizising my language of choice!", then maybe you should search for another language. There is a distinct difference between visualizing the semantics through indentation (and to some degree braces), and to assign semantics to the intentation in itself. If you think assigning semantics to use of whitespace, you should take a look at the Whitespace language. There you can get everything you want in that direction! Whitespace semantics is crazy, judged from a readability and reliability point of view. Nothing related to indentation has any semantics in the C class of languages, so pretending that they are similar is a complete misunderstanding. A week or two ago, someone posted an April 1st proposal from Bjarne Strostrup (I am assuming that it really was written by him), a proposal about extending the operatior definitinions of C++, to allow operators to be defined for whitespace. He goes on to propose operator definitions for lack of whitespace. Sometimes, I suspect that Python addicts never noticed the publication date. (I did save Strostrup's proposal, but not the link. I might be able to dit it up from my browsing history, if anyone insists.)
-
So maybe we should shut up and accept that Python Is, After All, Doing The Right Thing? No. If your attitude is that "Noone should keep on critizising my language of choice!", then maybe you should search for another language. There is a distinct difference between visualizing the semantics through indentation (and to some degree braces), and to assign semantics to the intentation in itself. If you think assigning semantics to use of whitespace, you should take a look at the Whitespace language. There you can get everything you want in that direction! Whitespace semantics is crazy, judged from a readability and reliability point of view. Nothing related to indentation has any semantics in the C class of languages, so pretending that they are similar is a complete misunderstanding. A week or two ago, someone posted an April 1st proposal from Bjarne Strostrup (I am assuming that it really was written by him), a proposal about extending the operatior definitinions of C++, to allow operators to be defined for whitespace. He goes on to propose operator definitions for lack of whitespace. Sometimes, I suspect that Python addicts never noticed the publication date. (I did save Strostrup's proposal, but not the link. I might be able to dit it up from my browsing history, if anyone insists.)
>So maybe we should shut up and accept that Python Is, After All, Doing The Right Thing? Strawman. >If your attitude is that "Noone should keep on critizising my language of choice!", then maybe you should search for another language. Ad hominem and straw man. >you think assigning semantics to use of whitespace, you should take a look at the Whitespace language Strawman. Whitespace makes the prose easier to read, it's like a foil. >Nothing related to indentation has any semantics in the C class of languages, so pretending that they are similar is a complete misunderstanding. Either a strawman or you're really really stupid. My point is that everyone who writes good C indents their code blocks. It's almost incredible to me that you could fail to understand that, but looking at how your post opened I figured I'd give you the benefit of the doubt. >A week or two ago, someone posted an April 1st proposal from Bjarne Strostrup (I am assuming that it really was written by him), a proposal about extending the operatior definitinions of C++, to allow operators to be defined for whitespace. He goes on to propose operator definitions for lack of whitespace. Sometimes, I suspect that Python addicts never noticed the publication date. What relevance does that have to anything? Did I say that C++ should do away with braces and use indentation instead?
-
Okay, that was an analogy. I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these) For example,
If x is a:
do //indented & worksis different from
if x is a:
do //Non-indented & throws errorIt's funny, and doesn't this sound rudimentary and a bit annoying? :)
-
>So maybe we should shut up and accept that Python Is, After All, Doing The Right Thing? Strawman. >If your attitude is that "Noone should keep on critizising my language of choice!", then maybe you should search for another language. Ad hominem and straw man. >you think assigning semantics to use of whitespace, you should take a look at the Whitespace language Strawman. Whitespace makes the prose easier to read, it's like a foil. >Nothing related to indentation has any semantics in the C class of languages, so pretending that they are similar is a complete misunderstanding. Either a strawman or you're really really stupid. My point is that everyone who writes good C indents their code blocks. It's almost incredible to me that you could fail to understand that, but looking at how your post opened I figured I'd give you the benefit of the doubt. >A week or two ago, someone posted an April 1st proposal from Bjarne Strostrup (I am assuming that it really was written by him), a proposal about extending the operatior definitinions of C++, to allow operators to be defined for whitespace. He goes on to propose operator definitions for lack of whitespace. Sometimes, I suspect that Python addicts never noticed the publication date. What relevance does that have to anything? Did I say that C++ should do away with braces and use indentation instead?
If "you pythonians" are so sensitive and "tired of this criticism", I suggest that whenever you see any critical remark about Python, you leave that discussion thread immediately. When you answer to voices critical to Python semantic indentation with a "tired of this critisism", it is very close to "shut up - we don't want to hear about it", only your opinion about Python should be heard. When I am told, directly or indirectly, to shut up, it is not strawmanning to infer that you believe you have The Right Answer on the issue. When you state that you "are tired of this critisism", it is quite clearly a request from you to stop the critisism. Even though I clearly understand you that way, I still made it conditional, if it is so, then... That is not an "ad hominem attack", it is drawing conclusions based on your statement, on the condition that I have interpreted it correctly. An given that explicit condition, it is certainly not strawmanning. Others may read "us Pythonians are tired of this critisism" as "we welcome critical opinions on this issue", but I guess the way I read it is more like the common interpretation. Sure, we use indentation to ease reading in almost all modern programming languages, but the critisism was on the semantics of indentation - which is non-existent in C. You were the one who brought in C indentation, and then you blame me for strawmanning when I reject your invalid parallels between Python and C. Isn't that sort of turning things upside-down? I pointed out that Python semantic indentation is conceptually different from C layout for readability, and you suggest that I am "really stupid" and I "fail to understand" (but this is of course not ad hominem attacks...). I cannot suggest that you seem to not grasp the difference between assigning semantics to whitespace and not assigning semantics to whitespace - that would be another ad hominem attack, so I am not saying so. I must assume that you understand the difference. But then - maybe because I am "really stupid" honestly "fail to understand" why you, with your full comprehension of semantics and non-semantics, do not see the relevance to Strostrups proposal to assign semantics to whitespace to the degree that you can treat whitespace as an operator. He shows the absurdity of whitespace semantics by suggesting that even the abscence of something that (in C) is without semantics should be given a semantic interpretation... Actually, that
-
lopatir wrote:
but how do you misspell "i"
Right. That cost me a couple days of work, in the days when Fortran, as well as hardcopy code, were still around. (Yes I know there are languages called Fortran today, but they look completely different!). The loop went trhough once (as Fortran always does), but wouldn't repeat. I didn't discover the problem until I sat down with a printout of the disassebled binary code. Fortunately, the disassembler made use of the symbol defintions in the debug info, and fortunately, the printer (as opposed to the screen) used serif fonts. Then I could distinguish an "l" from an "I", so a conditional jump out of the loop used a diferent variable from the intended one. There are several such "false friends". I should have known, because in my student days, one of my friends who was a TA in the elementary Fortran programming class caused and "incident": The professor insisted on Norwegian variable names, so instead of "QUEUE" the variable should be named "KØ". "Ø" isn't recognized in Fortran, but ø is commonly transcribed to English as oe, which makes it "K0E". Because we have Ø as a letter, we do not slash zeroes here. Depending on the typeface, KOE and K0E may look almost perfectly identical. They did on our screens. When Jon discovered, he exclaimed loudly so that everybody around could hear hear it to the very good-looking, 18 year old female freshman: "Look, here you are not saying k-oh-e, you are saying k-null-e!" Zero is "null" in Norwegian and "knulle" means f**k... Jon didn't realize was he was "suggesting" until the word had been pronounced, and he got so ashamed that he wanted to flee away. But the girl did accept his excuses. Actually, it doesn't take national characters, like ø, to confuse 0 and O - even in English-speaking environments, non-slashed zeroes are common. Some typeface do not distinguish much between 1 and l either - I have seen troubles caused by that pair as well.
-
Fortran: screen?? You were doing it wrong. If you'd had the punch card deck you'd have spotted the mistake straight away... :laugh:
During my first student year, we actually did punch cards! Or, we filled in coding sheets, handed them in for punching by trained typists (especially well trained in mistyping...), and the turnaround time could be 36-48 hours in rush periods. Interactive terminals on 300 bps serial lines were reserved for graduate students. During the second year, we got three 16 bit minis, each handling 16 screens at 9600 bps, and a full screen editor, which made the big and proud Univac 1100 mainframe look so much like a clunky old wreck that we were ordered to reduce the line speed of the mini's terminals to 1200 bps, so that we did not put too much shame to the great mainframe. (The TAs, I was one, managed those three minis more or less ourselves.) Then (fall of 1979) Fortran was replaced by Pascal as the language for the "101 Basic programming" course for half of the students. Some departments refused to switch - noone in their branch of engineering would ever be programming anything but Fortran! Other departments accepted Pascal only conditionally: The EE departement accepted it only if the Computer Science students (like myself) were required to take a course which covered e.g. 3-phase power distribution networks... The incident with the I/l mixup happened around 1985, after I had completed my degree and was working at the University Computer Center. The guy with the problem was in the Mechanical Engeneering department; they still clung to Fortran as The Only Language at that time. But they did accept screens then! (Besides, I don't think there ever was delivered any punched card reader for the 32-bit supermini series that they were using.) A few years ago, a studymate of mine, working at the University supercomputer center, surprised me by telling that for FEM, weather forecasts and similar typical supercomputer applications, Fortran is still the language of choice! It is no longer Fortran IV, though... Strangely enough, I cannot find on the Internet who said, in the discussions of the proposed language extensions to become Fortran 77: "I don't know what programming languages will look like in year 2000, but they will be called Fortran..." - one of the big gurus of the time, maybe Hoare or Dijkstra. When I paraphrased that statement in my earlier post, it was intended as a historical reference, but it seems like the quote has not survived history. Whoever said it was perfectly right: Fortran 2003 is called Fortran, but looks nothing like Fortran IV.