Python becomes the most popular language

[bd139]

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.

[coppice]

90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.

Most security problems come from a reality of complex systems that explains a huge number of problems that don't get caught before deployment: Its much easier to understand how something complex works, than how it fails. If you've ever worked on failure mode and effect analysis (FMEA) this comes into stark relief.

[bd139]

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 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.

We should be respectful of each other's arguments. It's fine to chuck the odd comedic point around but when the thread diverges into semantic discussions about how points are taken, then there's a line crossed somewhere. An I know that is ironic.

tl;dr: lets be better people about this and keep on topic because the topic is really interesting.

I didn't come back here to watch someone with a valid perspective get chased away or watch the moderati descend.

[Cerebus]

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.

Oh there's a lot of python out there in a 'web framework' rôle, it's just that you don't see it because it's being used for RESTful interfaces and microservices. As far as the security of that goes I'll just say that the last job of that ilk that I worked on we spent a lot of time worrying about supply chain attacks and putting mitigations into place like not just 'pip install'-ing stuff and getting a random version of a dependency from a random place - we staged everything very carefully so that we'd know exactly what version of everything we had and where it came from. 'Modern' ecosystems, whether they be python, javascript or whatever are rife with opportunities for supply chain attacks.

[Cerebus]

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.

As I've said, it wasn't intended pejoratively, in fact I was trying not to do that while still calling it as I see it, hence "fanboyism" (-ism implying the behaviour not the person) not "<pejorative adjective> fanboy". Like you say, context, and the context was: "[given your repeated returning to appeal to "popularity"] At this point it really is difficult to judge your position as anything other than unalloyed fanboyism". I don't think that verges on a personal attack because if I did I wouldn't have said it. If "fanboyism" offends substitute "uncritical personal judgement of a thing as the best while offering scant argument in its favour except that it's popular".

Anyway, let's be clear. No personal attacks intended.

[Cerebus]

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.

[Picuino]

PyPI security pitfalls and steps towards a secure Python ecosystem
https://www.activestate.com/blog/pypi-security-pitfalls-and-steps-towards-a-secure-python-ecosystem/

About half of Python libraries in PyPI may have security issues, boffins say
https://www.theregister.com/2021/07/28/python_pypi_security/

The security risks of pip and PyPI
https://carles-garcia.net/python/python_pip/

[bd139]

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.

This is why I am currently unemployed. I don't want to be responsible for it any more 

[eugene]

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.

We can do even better with BASIC. Yes, we can say something good about basic

Code: [Select]

for i = 1 to 10

next i

I like the idea of (optionally) having the start and end of any block marked with a tag. Just as an example, nested loops might be tagged "outer" and "inner."  The same tags could be used elsewhere in the program, but if one end of a block has a tag, then there must be a matching tag at the other end.

It's a little bit interesting that some types of errors could be caught at compile time that wouldn't be caught in other languages. It's scary that C will let you write overlapping for() loops. Obviously it interprets the code in a way that you did not intend, which is to say that it's your own fault if you actually try to make overlapping for() loops. You can't expect a compiler to identify stupidity. This compiler could.

(It may or may not be interesting that overlapping for() loops are not possible in Python.)

[eugene]

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.

[brucehoult]

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.

One word.

exec()

An even worse feature in a language than significant whitespace.

[bpiphany]

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.

[Siwastaja]

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.

Goto isn't a "weird edge case". If you want something more comparable to exec() in weirdness and danger, how about setjmp()/longjmp()?

[PKTKS]

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.

SHORT ANSWER ? NO.

Long answer...  no..  Python is what it is.. a pathetic space based ident oriented newbie thingy..

RUBY is FAR way better..  you can do a simple direct one liner ... (like any POSIX tool )

Code: [Select]

while stream = STDIN.gets ; stream = stream.strip ; if (stream =~ /fubar/) then puts stream ; end ; end

and use a real Object oriented elegant script tool..
in long terms:
-  PHP is FAR way better than JAVA or JS
- RUBY is FAR WAY better than Python... really  better..
- PERL is way above them all as the real de facto POSIX tool..

For serious programming any replacement for real de facto C/C++ should be PASCAL.

Modern Object Oriented Pascal now can do things like

Code: [Select]

    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);


And fancy tricks like

Code: [Select]

operator + (const D2,D1:TDate):longint;
operator -  (const T2,T1:TTime):longint;

there is absolute no need for odd ducks...

Paul

[bd139]

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.

[PKTKS]

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.

The mileage vary... a lot..

By real .. or team..   it enumerates...   
IF GOOGLE...   GO or RUST..   are the hype .. you apply the job..
IF  anything SYSTEMD    related...   Python..   that thing is the  limp dick tool...

IF anything  academic or de facto  programming  C/C++ ... FORTRAN for the gray beards..
PASCAL for entry level

EMBED?  that no doubt is LUA...

POVs are  BIASED

MONEY flows today into  newbie distros.. totally systemd/Python biased..

(PS btw  - that *** is not related with serious scopes)

Paul

[bd139]

Realistically most people start at the problem and work back to the solution with the skills and experience available on the market. Most of that is attention and interest based if anyone likes it or not. Knowing what is realistic is the exact opposite of bias.

As for limp dick, perhaps you should crank the maturity up a little bit and look at the market. I just finished a long term position at a very large fintech who's core business was developed with a limp dick tool. As with limp dicks, it's how you use it that counts

Europe/US/Asia markets look like this:

Embedded -> C

Desktop -> C++/C#/JavaScript(Electron)

Web -> JavaScript/Python/Go/Java/C#

Back end / data processing -> Python/Java/C#/Go mostly

HPC -> C++

Mobile -> Java/Swift

No Pascal, Lua, PHP, Rust...

Python features a lot because it's a fairly powerful language out the box, easy to deploy and manage, has good market penetration, reasonable documentation and allows people to solve problems quickly and efficiency. When applying the trifecta of compromises, it comes out pretty much in the middle.

[PKTKS]

I lived countless  HYPES "market"  things...

by 80s  by 90s...  by 2000s...

NOVELTY has the place...  but serious stuff always surface... sooner or later.

Seriously .. Python , GO and RUST are just the "moment" hype ..
There is absolute nothing better on any of these tools..

If you (like me) lived 3 or 4 decades the HYPE IT "market" ... you know...

FORTRAN and SQL  and  C  and PERL will  not vanish or change any time soon

No matter how popular or hype  are the others..
I saw countless others  go and vanish...  by 80...90...00...

Paul

[bd139]

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. People love C so much there is focus in rewriting core system utilities in other languages now.

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 .

Some things do stay. Python is one. I first used it as the workflow descriptor DSL in CoCreate WorkManager from HP circa 1998...

[PKTKS]

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

I don't  see  dead anyway...

If you ought to use OCTAVE you will be using modern FORTRAN..
If you will use MAXIMA you will use LISP like it or not...
If you are using a *NIX distro..  you are using PERL in autoconf and dozen other tools..
and you just can not  replace that overnight..

Market IT "JOBS"   exploit HYPE  novelty  solutions...

The fact remains.  almost 90% we use is C based
no matter how much newbie folks like Python scripts...

It is not going to change..  it will just surface again ahead...
Paul

[bd139]

Market IT jobs, which is a very loose term, solve real business problems. That's what builds value, increases attention and provides development effort.

Things are already changing. Large vendors are building their own compiler infrastructure and languages to support the future. We now have Rust, Swift, Go etc as safe systems programming languages and a layer of scripting languages available. There have been various experimental operating systems which do not have C as a basis at all as well.

And we already have Python interpreters written in Rust available as an example of where this is going.

It's a lot to replace but it doesn't take a lot to replace it when the tools are there.

Edit: some dickhead built powershell as well. That's now not to do things.

[PKTKS]

not  a simple change....

It is a complete  AGENDA

The amount of money invested in trying to replace widespread C with RUST comes with (obviously) an undisclosed agenda...

By late 80/90s  the incredible popular and widespread DELPHI could be swear the future of IT...

by late 90s MS imploded the heads .. hired key devels.. and made their own ### crappy..
thanks to hired ex-delphi  devels..

nothing really new .. big pockets AGENDAS  will prevail...
but the serious stuff will not vanish that easy


btw..  embed means interpreter  not embed gizmos (ASM/C based)
Paul

[bd139]

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.

Delphi was never an option. It was a commercial product, closed source, poor development ecosystem and targeting. People were tired of navigating licensing and compiler purchases by then which created the entire open source ecosystem really.

Edit: Note taken on embedded interpreters. Usually we use python 

[PKTKS]

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

PS>  LUA was meant to be embed ...  by design
Python.... well  it has been hacked for RPI and stuff...

[bd139]

They will be replaced by a whole new list of new and improved BUGs...

Paul

Correct. That we can agree on

That's an opportunity not a problem.

As for Lua, until indices start at 0, I invoke Knuth.