I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.
If you don't like the term flame war, why are you writing in a way that could be construed as flaming?
Casting mild criticism as "flaming" is characteristic of someone who (1) is very sensitive to criticism of the mildest sort, (2) has never been flamed or they'd know it for what it is. It's also a poor debating technique as it's characterising the person as being somehow "nasty" to you as a way to discount their arguments when in fact they're not.
I don't dismiss your arguments, I read all of them with interest.
But there are sentences that are not arguments and try to be offensive. I don't consider myself a Python fanboy, but I'm not going to change my mind no matter how much you argue if my arguments seem better to me.
Trust me, if I was trying to be offensive you'd know it. However, that is not my style unless provoked beyond my tolerance. Fanboy is not, in and of itself, offensive, merely descriptive and was intended as such, you're being way too sensitive. Check out the dictionary definition if you don't believe me "s boy or man who is an extremely or overly enthusiastic fan of someone or something" (Mirriam-Webster). If it was generally received as pejorative they would say so, cf "asshole - usually vulgar : a stupid, annoying, or detestable person" (also Mirriam-Webster).
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
I think you need to introspect a little there. Fanboy is wholly contextual and the context was carefully applied in your comment. It was verging on a personal attack against OP from a third person perspective.
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.
It's both. As I've already said, I'm acutely aware of the potential for supply side attacks and you could characterise that as a procedural problem, but it's one comes bundled into the tools that you use because with imported libraries and frameworks you're exposing yourself to the procedural weaknesses of the people who build them.
This leads to an irony of its own. I've always been wary of the "not invented here" phenomenon and the tendency of architects/programmers to love to build their own worse version of tools that can be had for free or relatively little money. (And have had to fight tooth and nail with people who are desperate to roll-their-own, thereby busting budgets, deadlines and introducing brand new bugs all of their own.) But with imported tools comes imported risks and opacity and I sometimes find myself thinking "Wouldn't it be safer to run up our own [relatively limited] version of this tool?". It's usually at that point that I realise that what I really need is a good stiff drink.
Let's go on a bit of a tangent, then, related to blocks delimiters. (Python and Makefiles use indentation and not delimiters; and Makefiles' one is even more annoying, because it does distinguish between tab and space as the first character in indentation. I avoid that mess by using four spaces per indentation level in Python, and only a single tab in Makefiles.)
It seems that those who dislike indentation, prefer braces AKA curly brackets, { and } as the block delimiters. These are used in many languages (C, C++, Java, Javascript, Awk, CSS, Tex/LaTeX/MathJax) which makes them familiar to many. Are there any better suggestions?
Again, one of personal favourites come to the fore, Algol68. As well as BEGIN and END for blocks (which isn't, and wasn't then, unique) it also has IF ... THEN ... ELSE ... FI, DO ... OD, CASE ... IN ... ESAC to make "unitary clauses" from "serial clauses". The great advantage here is the additional information provided to both the programmer and the compiler as to what kind of block is being closed.Code: [Select]void junk(void)
{
for (i = 1; i <11; i++)
{
switch (i)
{
...
}
}
}
Has a crowd of undifferentiated closing braces (which relies on indenting for easy human comprehension), whereas in:Code: [Select]PROC junk = (VOID) VOID:
BEGIN
FOR i FROM 1 TO 10
DO
CASE i IN
...
ESAC
OD
END
it is immediately obvious which type of clause each closing 'brace' is closing.
Also, I don't think anybody dislikes indentation per se, merely the reliance on indentation for semantics.
for i = 1 to 10
next i
Suppose Python offered an optional syntax where blocks where delimited by '{' and '}' instead of the current way. Would that cause a shift in opinion?
It think a simple script (written in Python) could convert source files back and forth between the two styles, so anyone could be writing Python my new style in an hour.
exec()
exec()
The fact that a construct exists doesn't mean it should be used, other than in weird edge cases. Much like goto i suppose. For completely different reasons, but still.
Suppose Python offered an optional syntax where blocks where delimited by '{' and '}' instead of the current way. Would that cause a shift in opinion?
It think a simple script (written in Python) could convert source files back and forth between the two styles, so anyone could be writing Python my new style in an hour.
while stream = STDIN.gets ; stream = stream.strip ; if (stream =~ /fubar/) then puts stream ; end ; end
generic function Add<T>(aArg1, aArg2: T): T;
begin
Result := aArg1 + aArg2;
end;
SomeStr := specialize Add<String>('Hello', 'World');
SomeInt := specialize Add<LongInt>(2, 5);
operator + (const D2,D1:TDate):longint;
operator - (const T2,T1:TTime):longint;
I genuinely don't think anyone in this thread lives in the real world or deals with real products or real development teams or has built any significant software infrastructure on any of the tools they are commenting on. There is so much disparity the contents and reality here it's unreal.
Yeah. I've been doing this professionally for 25 years. As an amateur about 38 years now.
Perl is completely fucking DEAD. Fortran is mostly DEAD. Mainframes are breathing their last breaths. C is dead outside embedded and systems programming because of the security focus of modern systems.
The only inevitability is change, you're right. But that's a good thing because it keeps me in pocket as I've bothered to keep up with the times and don't call anything limp dicked I can make some coin on
Uh yeah. All those buffer overflows, CVEs and crying users are the agenda...
It's a warzone out there and you don't go in to a war with a 1960s tank.
Edit: Note taken on embedded interpreters. Usually we use python
They will be replaced by a whole new list of new and improved BUGs...
Paul