|
It's interesting to see in this discussion that one of python's more attractive features is seen as a disadvantage 8)
Once again, the debate here about whether the language is 'good' or not seems to have nothing to do with whether it actually is good or otherwise, but simply amounts to 'does it fit my idea of how a language should work'.
If I've learnt anything from over 40 years of software development, it is that (with a few domain specific exceptions) the skill of writing good software - don't mistake me here, I'm not saying that I write good software! - has almost nothing to do with the language you write it in, and everything to do with domain knowledge and the skill of the programmer(s).
Every language has rules; every language has flaws. Being aware of both and using/avoiding them so you produce good code is what it's all about.
The behaviour cited above as being 'problematic' is exactly why I use Python for certain types of project.
8)
|
|
|
|
|
Mike Winiberg wrote: has almost nothing to do with the language you write it in, and everything to do with domain knowledge and the skill of the programmer(s). I agree.
I am glad you used the word "almost", because using Windows batch scripting for some devops work I have been doing has resulted in me having to work around the language and do things in a manner that I would not see as particularly elegant.
Of course I could rewrite it with powershell scripting, which is on my list, but when you are working on systems that are business critical - doing a large code refactor is not always possible largely due to the cost to the business.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Oh yes, I was careful to say "almost"! 8)
It never ceases to amaze me how complex a process could be constructed with DOS batch scripts - often by relying on obscure side-effects of small .COM files etc. I've always liked Powershell (although I rarely use it!) because it seemed a genuine attempt to provide a full batch environment for windows with 'proper' controlled access to the entire system.
I do find the verbosity of the naming convention somewhat off-putting though (as indeed is the case for some other languages) - ridiculously long and complex variable names can be as difficult to manage as i, ii, iii and iiii etc!
(I once spent over a day hunting down a bug in some C++ code where a stupidly long descriptive variable name had been used in multiple places with two different internal spellings via a macro such that the compiler didn't 'notice' the variants!)
|
|
|
|
|
But a var (as in C#, say) isn't at all the same thing as an untyped (or rather, dynamically-typed) variable (as in Python). When you write var x = 5; , x is still an int just the same as if you'd written int x = 5; , you're just helping yourself save some keystrokes and letting the compiler infer the type (ok, you're not saving any keystrokes in that example, but not every type name is as succinct as int ). You can't then turn around and write x = "snuggles"; or the compiler will throw a fit, unlike Python where it would be perfectly legal. More and more people might be using var , but let's not confuse that with "no one will be using proper typed variables any more!"
|
|
|
|
|
Dictionary<string, IEnumerable<IEnumerable<SomeValue>>> valuesPerLineFromACsvFileByKey = new Dictionary<string, IEnumerable<IEnumerable<SomeValue>>>(); or:
var valuesPerLineFromACsvFileByKey = new Dictionary<string, IEnumerable<IEnumerable<SomeValue>>>();
|
|
|
|
|
Supporting and encouraging good (consistent) formatting is a good thing, but requiring it isn't.
(In my opinion) one of the strengths of C-like languages is that whitespace is pretty much unimportant. With C and C# -- unless you have directives -- each sequence of whitespace can be reduced to a single SPACE without affecting the meaning of the code.
When I write C, I try to put all the directives in their own files, away from the actual C code.
|
|
|
|
|
I know Haskell has it too.
I know, because I had a school assignment that I've been looking at for two hours because I mixed up a few spaces with a tab...
if x is a:
do Isn't the same as:
if x is a:
do
It does produce some really clean and concise code though!
|
|
|
|
|
I started looking at Python in my home hobby time around 6 months ago and while it is a bit strange at first, I now find the indentation makes the code easier to read without brackets.
I know IDEs allow you to indent bracketed languages but I find that Python easier to read.
If you find the indentation strange, wait until you get on to the coding standards where lines should not exceed 79 characters in length.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I my days, when C squeezed out Pascal, one argument you could frequenty hear in favor of C was "There's so much typing in Pascal! In C, you can just use {}, and don't need those BEGINs and ENDs. You don't need to write FUNCTION or PROCEDURE, and so on".
So we threw out a well designed, fairly safe language in favor of a "you asked for it, you got it" language, to save a few keystrokes.
To some people that wasn't enough; even braces required keystrokes (even shifted ones, on most keyboards). Let's get rid of those! And we got Python.
If you really want to save keystrokes, why don't you go for APL? Other crazy ways of saving keystrokes is to insist on using tabs rather than spaces, sometimes with semantic significance. (No, I am not talking about Whitespace, but seriously meant file formats.)
Obligatory Geek & Poke[^]. You may argue that keywords do not reduce complexity - but it does help you to understand that this closes the while loop, that closes the method definition, and there is the end of the class definition. Besides, distinct keywords help the compiler back on the track after an error, and facilitates much more meaningful error messages.
|
|
|
|
|
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 ...
|
|
|
|
|
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.
|
|
|
|
|
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?
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 is the case in Python: Remove some whitespace in a Python program, and its semantics change. But appearenly, I am too stupid to understand why you do not see the relevance.
My stupidity is also displayed by wasting time replying to your post. I will try to control it by not answering to whatever you respond with to this.
|
|
|
|
|
Yes, just one of the many "features" that relegates python to a 'fast food' language. What's not a 'fast food' language - Tcl\Tk
Net: Take a look at Tcl and then you will asking yourself "Why does python even exist?"
|
|
|
|
|
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.
|
|
|
|
|
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
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?
|
|
|
|
|
I experienced this when Python 3 was released. Is this a Python 2 throw-back other than the semi-colon Python 3 wants?
"Courtesy is the product of a mature, disciplined mind ... ridicule is lack of the same - DPM"
|
|
|
|
|
Check this out: CODE - Apply for a position Visual FoxPro Dev[^]
Posting says: We have multiple offerings for this position and will consider candidates who seek full-time employment or contracting opportunities.
When I read that, my eyes bugged out of my head.
According to wikipedia[^] :
Final release of Visual FoxPro was
v9.0 SP2[1] / October 16, 2007; 11 years ago
Wow!
|
|
|
|
|
I spent 15+ years doing FoxPro and Visual FoxPro. At one time it was a powerful language. The advent of .Net spelled the beginning of the end of VFP.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: I spent 15+ years doing FoxPro and Visual FoxPro.
Would it be interesting to you now? Or is it so old that it'd be terrible?
Just curious.
Also, maybe there is some $$$ for you to make?
|
|
|
|
|
I'm not really interested. There are conversion jobs out there, but I'm plenty busy doing .Net
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I started with VFP and VB6 back in the day. Wow!! I feel so old.
|
|
|
|
|
Slacker007 wrote: I feel so old. Tell me about it. I started with FoxPro before it was "Visual".
v2.0 I think...
The Beer Prayer - Our lager, which art in barrels, hallowed be thy drink. Thy will be drunk, I will be drunk, at home as it is in the tavern. Give us this day our foamy head, and forgive us our spillage as we forgive those who spill against us. And lead us not to incarceration, but deliver us from hangovers. For thine is the beer, the bitter and the lager, for ever and ever. Barmen.
|
|
|
|
|