Yet another icon stepping away - Guido van Rossum, Python

[RoGeorge]

- Remember Richard Stallman, the father of GNU stepping away?
- Remeber Linus Torvalds, the father of Linux taking crap like banning the use of 'master/slave'?
- Remeber Guido van Rossum, the father of Python stepping away?

Wait, what?!  Yes, him too.

The most controversial Python feature | Walrus operator

The walrus operator := and assignment expressions, PEP 572, was opposed by majority of Python core developers, and led Guido van Rossum to step down from BDFL role.

LINKS:
PEP 572: https://www.python.org/dev/peps/pep-0...
Zen of Python: https://www.python.org/dev/peps/pep-0...
Vote against PEP 572: https://www.mail-archive.com/python-c...

OUTLINE:
0:00 - Walrus operator
1:26 - Use cases
3:33 - Criticisms
5:59 - Guido van Rossum

[CatalinaWOW]

Strange.  While I started on Fortran, I grew up on Algol and Pascal, two languages that use the "Walrus" operator for assignment.  I like it as used in those languages.  But in spite of this background and affinity I found all of the examples of Walrus use in Python 6.8 obscure and gave opportunity to generate hard to maintain code.  I can see why there were intense arguments and hard feelings over this decision.

[ebastler]

I can only hope that van Rossum's decision to step down was driven by larger underlying reasons, and that the argument over this operator was just the final straw. Throwing in the towel over a syntax dispute seems a bit childish, to be frank.

[free_electron]

Create a new language.
One that isn't boneheaded and does not bank on whitespace for flow control.
One that does has a parser that understands when = is an assignment and when it is a comparison.
One that doesn't need every line to be ended in a semicolon, but uses a continuation character when needed.
One that doesn't smell like C, C++ or c# or Java or quiche-eaters pascal and its derivatives.
One that doesn't look like a bunch of cryptical mathematical equations
One that is easy to understand, uses simple english keywords.

something along these lines

a = 12
b= 14
c= b-a
for x = a to b
   c = c^x
  print a,b,x,c
next x


- simple english with a small vocabulary of keywords
- smart compiler that understands syntax and knows when to assign and when to compare. no need for walrus operators or == and other shenanigans
- smart code environment that uses autocompleteand puts the closing quotes around strings and fixes many speeelling errors
- interactive debugger that lets you singlestep through a program , examine data , add or remove instructions and rerun sections of code. No continuous code, attempt to compile, fix typing errors , missing brackets and semicolons , run , crash and not know where or why or even able to see or save the data. Fire up the program. if a mistake is encountered the program stops without loss of data. the debugger tells yu the most likely cause, lets you fix the source and then attempt to continue the run with the fix in place. while in debug you can execute code interactively , examine and alter data contents and even dump the current state of program and data to disk so it can be examined later without having to rerun the entire shebang. the entire machine state, data and all, can be saved.

I'm thinking to call it something along the lines of 'Ultima' or maybe something simple and basic... like 'Basic'.

[dave j]

This isn't exactly news. He announcement he was stepping back from being benevolent dictator for life over two years ago. Whilst PEP 572 might have been the trigger for him stepping back, it's not the sole reason why. As that article linked to mentions:

He’s left behind no governing principles or a successor, but said a debate on those issues was coming anyway, citing the potential for him to be hit by a bus and the fact that “I'm not getting younger... (I'll spare you the list of medical issues.)”

All open source projects need to deal with the fact that their creator isn't going to be around forever. It's probably better that they do so whilst they are still around.

[RoGeorge]

My bad for not double checking the sources for that video, sorry, I didn't know it happened 2 years ago.

Still, my sorrow for his stepping down remains.

[CatalinaWOW]

Create a new language.
One that isn't boneheaded and does not bank on whitespace for flow control.
One that does has a parser that understands when = is an assignment and when it is a comparison.
One that doesn't need every line to be ended in a semicolon, but uses a continuation character when needed.
One that doesn't smell like C, C++ or c# or Java or quiche-eaters pascal and its derivatives.
One that doesn't look like a bunch of cryptical mathematical equations
One that is easy to understand, uses simple english keywords.

something along these lines

a = 12
b= 14
c= b-a
for x = a to b
   c = c^x
  print a,b,x,c
next x


- simple english with a small vocabulary of keywords
- smart compiler that understands syntax and knows when to assign and when to compare. no need for walrus operators or == and other shenanigans
- smart code environment that uses autocompleteand puts the closing quotes around strings and fixes many speeelling errors
- interactive debugger that lets you singlestep through a program , examine data , add or remove instructions and rerun sections of code. No continuous code, attempt to compile, fix typing errors , missing brackets and semicolons , run , crash and not know where or why or even able to see or save the data. Fire up the program. if a mistake is encountered the program stops without loss of data. the debugger tells yu the most likely cause, lets you fix the source and then attempt to continue the run with the fix in place. while in debug you can execute code interactively , examine and alter data contents and even dump the current state of program and data to disk so it can be examined later without having to rerun the entire shebang. the entire machine state, data and all, can be saved.

I'm thinking to call it something along the lines of 'Ultima' or maybe something simple and basic... like 'Basic'.

Here is one of the reasons there have been so many languages over the years.  Free electron is speaking as a user - someone who just wants to get something done.

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

A perfect language for one group will never be the perfect language for the other. 

[ebastler]

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

I think you are missing the point there. All the redundancies you mention -- syntax, declarations, strong typing -- are not meant to make writing the compiler easier, or to help catch compiler bugs. They are meant to make it easier to catch user (programmer) errors.

Whether they are an effective way to reach that goal is, of course, a matter of debate. "Wordy" languages with redundancy, and writing lots of comments besides the actual program, certainly works for me. (Probably because I am sloppy and forgetful...) Others feel that "terse" languages allow them to focus on the essentials when reading and writing code, and argue that this reduces their error rate. You can watch the occasional "VHDL vs. Verilog" debates in another part of this forum for a taste. 

There certainly is a pain threshold for me where I feel terseness in programming languages becomes counter-productive and error-prone. The way C and its offspring allow you to write "if (a=b) {...}", where the "=" operator is an assignment and the value of b is quietly converted into a boolean, is my favorite example. And yes, I have fallen into that trap more than once when I sporadically programmed in C or C++...

[CatalinaWOW]

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

I think you are missing the point there. All the redundancies you mention -- syntax, declarations, strong typing -- are not meant to make writing the compiler easier, or to help catch compiler bugs. They are meant to make it easier to catch user (programmer) errors.

Whether they are an effective way to reach that goal is, of course, a matter of debate. "Wordy" languages with redundancy, and writing lots of comments besides the actual program, certainly works for me. (Probably because I am sloppy and forgetful...) Others feel that "terse" languages allow them to focus on the essentials when reading and writing code, and argue that this reduces their error rate. You can watch the occasional "VHDL vs. Verilog" debates in another part of this forum for a taste. 

There certainly is a pain threshold for me where I feel terseness in programming languages becomes counter-productive and error-prone. The way C and its offspring allow you to write "if (a=b) {...}", where the "=" operator is an assignment and the value of b is quietly converted into a boolean, is my favorite example. And yes, I have fallen into that trap more than once when I sporadically programmed in C or C++...

I will concede that they are dual purpose.  Whether they help depends on the type of errors that the programmer is likely to make, and they are more effective for some than for others.  They are most effective on errors that result from variations in number representation.  Humans doing math don't separate integers of various sizes, floating point numbers of various sizes and complex numbers into different and incompatible classes, so it is easy to make mistakes of understanding in how the machine responds to multiplying 2 times 2.0.  Particularly when sending the result to a DAC.

[free_electron]

Create a new language.
One that isn't boneheaded and does not bank on whitespace for flow control.
One that does has a parser that understands when = is an assignment and when it is a comparison.
One that doesn't need every line to be ended in a semicolon, but uses a continuation character when needed.
One that doesn't smell like C, C++ or c# or Java or quiche-eaters pascal and its derivatives.
One that doesn't look like a bunch of cryptical mathematical equations
One that is easy to understand, uses simple english keywords.

something along these lines

a = 12
b= 14
c= b-a
for x = a to b
   c = c^x
  print a,b,x,c
next x


- simple english with a small vocabulary of keywords
- smart compiler that understands syntax and knows when to assign and when to compare. no need for walrus operators or == and other shenanigans
- smart code environment that uses autocompleteand puts the closing quotes around strings and fixes many speeelling errors
- interactive debugger that lets you singlestep through a program , examine data , add or remove instructions and rerun sections of code. No continuous code, attempt to compile, fix typing errors , missing brackets and semicolons , run , crash and not know where or why or even able to see or save the data. Fire up the program. if a mistake is encountered the program stops without loss of data. the debugger tells yu the most likely cause, lets you fix the source and then attempt to continue the run with the fix in place. while in debug you can execute code interactively , examine and alter data contents and even dump the current state of program and data to disk so it can be examined later without having to rerun the entire shebang. the entire machine state, data and all, can be saved.

I'm thinking to call it something along the lines of 'Ultima' or maybe something simple and basic... like 'Basic'.

Here is one of the reasons there have been so many languages over the years.  Free electron is speaking as a user - someone who just wants to get something done.

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

A perfect language for one group will never be the perfect language for the other.

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )


Why is it so hard to discriminate when  = means 'assign' and when it means 'compare' ?
When used in conjunction with an 'if' clause : comparison , anything else : assignment. is it really that hard to figure out for a compiler ?
The same thing with semicolons. At the end of the line of code there is a CR/LF ( or LF if you are on oonix ) in the source file. There is your bloody line ending and end of statement. if, and only if, it is so long  you really must spread it over multiple lines , use a continuation character. The number of times a command needs to be split over mulitple lines is far less than single line , so it saves keyboard hammering. besides, if your statement realyl is that long : maybe split it in a few simpler statements ? A book is made from many sentences. Not just one long sentence. If you want to keep it simple and approach a wide audience : use short sentences.

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
c = a+b ' since the compiler knows the type of a and b it will resolve to float
d = int(c)   ' the int operator always returns an integer so cast d as integer.
d = 5.0 ' throw an error . i goofed up .
b = b and &hff ' throw an error b is a float
d = int(b) and &hff ' works

for all i care you can have two operators : toint and tofloat

It is 2020 . The compilers should be able to figure these things out without us humans needing to spoonfeed them each and every time.

[Doctorandus_P]

They're fighting over something like this, while failing to adress the horrible whitespace dependency of python?

Sigh.

>>> 3+3
6
>>>  4+5
  File "<stdin>", line 1
    4+5
    ^
IndentationError: unexpected indent


Oh gosh, I had the guts to place a space before "4+5".

[free_electron]

They're fighting over something like this, while failing to adress the horrible whitespace dependency of python?

Sigh.

>>> 3+3
6
>>>  4+5
  File "<stdin>", line 1
    4+5
    ^
IndentationError: unexpected indent


Oh gosh, I had the guts to place a space before "4+5".

don;t get me started. They should reduce the twat that came up with that to whitespace ...

[ebastler]

They should reduce the twat that came up with that to whitespace ...

That would be Guido von Rossum himself, presumably?

Like it or not, but the idea to encode nesting depth via indentation seems pretty central to the Python syntax.
So if you don't like it, or can at least tolerate it, better find yourself another programming language. 

[Bassman59]

They should reduce the twat that came up with that to whitespace ...

That would be Guido von Rossum himself, presumably?

Like it or not, but the idea to encode nesting depth via indentation seems pretty central to the Python syntax.
So if you don't like it, or can at least tolerate it, better find yourself another programming language. 

I don't really care about how Python requires indentation for nesting depth.

I hate how it allows you to override a variable's definition in mid-stream. First, let's declare that foo is an integer and use it as such! OK, now, five lines later, let's declare foo to be a dictionary!

[Bud]

That is the consequence of using a language named after the clown TV show.

[RenThraysk]

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
c = a+b ' since the compiler knows the type of a and b it will resolve to float
d = int(c)   ' the int operator always returns an integer so cast d as integer.
d = 5.0 ' throw an error . i goofed up .
b = b and &hff ' throw an error b is a float
d = int(b) and &hff ' works

for all i care you can have two operators : toint and tofloat

It is 2020 . The compilers should be able to figure these things out without us humans needing to spoonfeed them each and every time.

As soon as add blocks and scope, the compiler cannot determine if you are reusing a variable from an outer scope, or creating a new variable in the inner scope, unless you specifically prohibit variable shadowing in the language.

Before 2015 JavaScript/ECMAScript just had var keyword to declare either function scoped or globally scoped variable. And it seemed to create a lot of confusion. So much so the ECMAScript 6 standard added let and const keywords to the language in 2015, to create block scoped variables or constants. Since then I think var usage has virtual stopped.

[gmb42]

I don't really care about how Python requires indentation for nesting depth.

I hate how it allows you to override a variable's definition in mid-stream. First, let's declare that foo is an integer and use it as such! OK, now, five lines later, let's declare foo to be a dictionary!

That's another fundamental part of the Python language, it's dynamically (but strongly) typed.
https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language

[AntiProtonBoy]

I'm gonna go against the trend and say i don't mind Python's strict indentation requirements. And this is coming from a C++ developer. Yes, it forces you into  writing code in very particular way, but that's the beauty of it: everyone else has to do it, too. The end result is that coding style becomes consistently similar across different authors. Programming communities for other languages have to endure the never ending bike-shedding over code formatting, which gets tiresome sometimes.

[free_electron]

I'm gonna go against the trend and say i don't mind Python's strict indentation requirements. And this is coming from a C++ developer. Yes, it forces you into  writing code in very particular way, but that's the beauty of it: everyone else has to do it, too. The end result is that coding style becomes consistently similar across different authors. Programming communities for other languages have to endure the never ending bike-shedding over code formatting, which gets tiresome sometimes.

ok. but here is the problem : how many spaces is a tab ? and do all operating systems / editors use the same convention ? THAT is the misery with using whitespace for code flow. the CR / CR/LF problem is already bad enough , now we have that shit too.

[Bassman59]

I don't really care about how Python requires indentation for nesting depth.

I hate how it allows you to override a variable's definition in mid-stream. First, let's declare that foo is an integer and use it as such! OK, now, five lines later, let's declare foo to be a dictionary!

That's another fundamental part of the Python language, it's dynamically (but strongly) typed.
https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language

I understand that, but it doesn't mean that it's not fucking stupid.

Of course, any rational person won't write code that takes advantage of that "feature," right? Right?

[RenThraysk]

I'm gonna go against the trend and say i don't mind Python's strict indentation requirements. And this is coming from a C++ developer. Yes, it forces you into  writing code in very particular way, but that's the beauty of it: everyone else has to do it, too. The end result is that coding style becomes consistently similar across different authors. Programming communities for other languages have to endure the never ending bike-shedding over code formatting, which gets tiresome sometimes.

I don't like Python's white space indentation, though I do like go's approach...

Formatting issues are the most contentious but the least consequential. People can adapt to different formatting styles but it's better if they don't have to, and less time is devoted to the topic if everyone adheres to the same style. The problem is how to approach this Utopia without a long prescriptive style guide.

With Go we take an unusual approach and let the machine take care of most formatting issues. The gofmt program (also available as go fmt, which operates at the package level rather than source file level) reads a Go program and emits the source in a standard style of indentation and vertical alignment, retaining and if necessary reformatting comments.

Taken from https://golang.org/doc/effective_go.html#formatting

Most IDEs or advanced text editors with go extensions/plugins run gofmt on saving. Means don't have to spend time pfaffing with white space.

[Marco]

One that does has a parser that understands when = is an assignment and when it is a comparison.

But how are you going to develop a human which can do so with an useful level of consistency? They have trouble when it's two operators, making an extensive set of contextual rules for when it means one or the other seems utter folley to me.

[Marco]

ok. but here is the problem : how many spaces is a tab ? and do all operating systems / editors use the same convention ? THAT is the misery with using whitespace for code flow. the CR / CR/LF problem is already bad enough , now we have that shit too.

Can't mix spaces and tabs for leading white space in 3, so it's entirely irrelevant.

[ozcar]

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )
...

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
...

Older still -  the default IMPLICIT INTEGER(I-N), REAL(A-H,O-Z).

I write it like that, not to imply shouting, but because the code editors of the day were not so good with lower case (eg https://twobithistory.org/2018/06/23/ibm-029-card-punch.html ).

[AntiProtonBoy]

ok. but here is the problem : how many spaces is a tab ? and do all operating systems / editors use the same convention ? THAT is the misery with using whitespace for code flow.

It doesn't matter. Python needs only one space to declare a different block scope. As for how much to indent, that is up to you.

the CR / CR/LF problem is already bad enough , now we have that shit too.

That's also a non-issue. Most editors worth their salt will gracefully handle line-endings and will happily convert between the conventions.

[AntiProtonBoy]

I don't like Python's white space indentation, though I do like go's approach...

Most IDEs or advanced text editors with go extensions/plugins run gofmt on saving. Means don't have to spend time pfaffing with white space.

You brought an apple to the table, when we're talking about oranges. Formatting in this case is not inherent to the Go language itself, rather it's a tool that is applied on code, which is basically equivalent to clang-format for C++ or C.

[RenThraysk]

I don't like Python's white space indentation, though I do like go's approach...

Most IDEs or advanced text editors with go extensions/plugins run gofmt on saving. Means don't have to spend time pfaffing with white space.

You brought an apple to the table, when we're talking about oranges. Formatting in this case is not inherent to the Go language itself, rather it's a tool that is applied on code, which is basically equivalent to clang-format for C++ or C.

You are incorrect. Due to the nature of automatic semicolon insertion, formatting can change the meaning of go code. It probably wasn't intentional, but it does.

For example, https://play.golang.org/p/qHJOMHGooMd

[free_electron]

ok. but here is the problem : how many spaces is a tab ? and do all operating systems / editors use the same convention ? THAT is the misery with using whitespace for code flow. the CR / CR/LF problem is already bad enough , now we have that shit too.

Can't mix spaces and tabs for leading white space in 3, so it's entirely irrelevant.

yeah , but what if you are stuck on 2.7 because you know. radical incompatibility int he language ( libraries )
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable. any goofy line of code can redefine pi to whatever. Kind of like B.S.Johnson which made a circle where the diameter to circumference ratio is exactly 3. Then again he also is famous for making such things as explosive mixtures containing nothing else but common sand and water , or making a triangle with three right angles.

[Bassman59]

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )
...

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
...

Older still -  the default IMPLICIT INTEGER(I-N), REAL(A-H,O-Z).

I write it like that, not to imply shouting, but because the code editors of the day were not so good with lower case (eg https://twobithistory.org/2018/06/23/ibm-029-card-punch.html ).

Ooooh, FORTRAN.

[jfiresto]

...
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable....

Not exactly. You could attach them to a class as read-only properties/descriptors, and get them from an instance. It is probably better to say that everything is a reference, but that is nit-picking until it isn't.

[free_electron]

...
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable....

Not exactly. You could attach them to a class as read-only properties/descriptors, and get them from an instance. It is probably better to say that everything is a reference, but that is nit-picking until it isn't.

so i have to create an entire class with all associated hoopla ( instance  creation et al ) to do something that could be done using a simple keyword

const pi = 3.17
print pi


class maths_constants
  property get pi
     return 3.17
  end property
end class
print math_constants.pi


this is going the wrong way ... the less keyboard pounding i need to do the better. newer languages are supposed to make it faster and easier. not more cumbersome and elaborate. come to think of it. pi should be a baked-in constant that automatically casts to the precision of the target variable.

double x
x = pi yields 3.17+ 23 more digits
in x
x = pi
x is 3
single x

and languages really need to do away with this notion of integers and floats. there needs to be a uniform numerical type that automatically expands to the highest precision possible. i don't care about the compute time. the compiler can figure out what is the best mapping onto hardware
a= 2 , b =4, c = a+b : compiler would use unsigned integer math
a= 2 , b =4, c = a-b : compiler would use signed integer math.
a= 2 , b =4, c = b-a : compiler would use unsigned integer math since b is larger than a and thus negative number is ruled out.

tTe machine code can examine the contents of the variables , determine if they are signed or unsigned , integer or float , and decide what needs to be done. this can be done in a few instructions
No more shit like 'we tried to stuff a 32 bit number into 16 bits and all went to hell' no more need of cint ,cint16 and other stuff. you would retain those functions so you can cast when it is required for a specific purpose ( like bit twiddling in integers that drive i/o ) but a variable by default should be 'modeless' and the compiler can figure it out. unless i specifically tell it to be of a given type.
and if i tell it to be of a given type then conversion needs to be implicit.

var a,b  'modeless numbers
int x ' hard defined integer
a= 4
b = 3.14
x = a * b

' x containins 13  (4x3.14 was evaluated as float yielding 12.56. cast to integer = 13 ( rounded up )
x = round_down(a*b) . x contains 12

the compilers KNOW the type you gave , so why do yo need conversion functions ? they can figure out exactly what to do.

[ebastler]

the compilers KNOW the type you gave , so why do yo need conversion functions ? they can figure out exactly what to do.

Explicit type conversion are not meant to help the compiler figure out what to do. They are meant to enable the compiler to check that you knew what you were doing. 

[CatalinaWOW]

Explicit type declarations for much code (small projects, test code, personal code and many others) is kind of like a forced check to make sure your shoelaces are tied.  A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.  If it is code with safety of life consequences it is definitely worth it.  In other cases not so much.  A smart enough compiler could flag instances where the shoelaces seemed to be untied.

[Bud]

Explicit type declarations .. A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.

The whole Flir Ex thermal cameras shenanigan became available thanks to  (lack of) that.

[free_electron]

Explicit type declarations for much code (small projects, test code, personal code and many others) is kind of like a forced check to make sure your shoelaces are tied.  A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.  If it is code with safety of life consequences it is definitely worth it.  In other cases not so much.  A smart enough compiler could flag instances where the shoelaces seemed to be untied.

semi-Agree. Then can we at least have upward expansion for free ? if there is no risk of loss of data : convert. And can we make a smart IDE that underlines conversions that can go bad ? if, during the coding step you do
int x
float a,b

x = a/b  : put a red squiggle under X. hover mouse and it says : warning : converting float to integer

int x,a,b
x = a/b : red squiggle
x = a\b : no squiggle. this is integer division

That would help a lot. These checks should be easy to implement in visual studio.

[CatalinaWOW]

Explicit type declarations .. A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.

The whole Flir Ex thermal cameras shenanigan became available thanks to  (lack of) that.

Even experienced shoelace users make mistakes.  The question isn't whether checking shoelaces is useful, but under what circumstances the cost is worth it.  Even Flir might feel that over all their code and product lines they might be ahead.  AFAIK there's is no perfect algorithm to evaluate this.  I am really not upset with anyone's answer to this, only upset with those who don't believe there is a question.

[free_electron]

Even experienced shoelace users make mistakes.

It's 2020, can we have velcro please ?

[Mattjd]

I can only hope that van Rossum's decision to step down was driven by larger underlying reasons, and that the argument over this operator was just the final straw. Throwing in the towel over a syntax dispute seems a bit childish, to be frank.

GvR stepped down because of health, age, and because core developers took to social media to complain about the new operator. He didn't like that part, instead of keeping the problem in house they made it public. I wouldn't have liked it either.



Personally, I think the operator is great and fits into python nicely. When you look at code people produce, very often people will write less lines at the cost of computation. The walrus allows people to get away with that, while increasing code speed. I don't get what the big deal is.


If you guys really want to shit a brick go check out PEP 622 for Pattern Matching ... I've got strong mixed feelings for it.

https://www.python.org/dev/peps/pep-0622/

[Mattjd]

...
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable....

Not exactly. You could attach them to a class as read-only properties/descriptors, and get them from an instance. It is probably better to say that everything is a reference, but that is nit-picking until it isn't.

so i have to create an entire class with all associated hoopla ( instance  creation et al ) to do something that could be done using a simple keyword

const pi = 3.17
print pi


class maths_constants
  property get pi
     return 3.17
  end property
end class
print math_constants.pi


this is going the wrong way ... the less keyboard pounding i need to do the better. newer languages are supposed to make it faster and easier. not more cumbersome and elaborate. come to think of it. pi should be a baked-in constant that automatically casts to the precision of the target variable.

double x
x = pi yields 3.17+ 23 more digits
in x
x = pi
x is 3
single x

and languages really need to do away with this notion of integers and floats. there needs to be a uniform numerical type that automatically expands to the highest precision possible. i don't care about the compute time. the compiler can figure out what is the best mapping onto hardware
a= 2 , b =4, c = a+b : compiler would use unsigned integer math
a= 2 , b =4, c = a-b : compiler would use signed integer math.
a= 2 , b =4, c = b-a : compiler would use unsigned integer math since b is larger than a and thus negative number is ruled out.

tTe machine code can examine the contents of the variables , determine if they are signed or unsigned , integer or float , and decide what needs to be done. this can be done in a few instructions
No more shit like 'we tried to stuff a 32 bit number into 16 bits and all went to hell' no more need of cint ,cint16 and other stuff. you would retain those functions so you can cast when it is required for a specific purpose ( like bit twiddling in integers that drive i/o ) but a variable by default should be 'modeless' and the compiler can figure it out. unless i specifically tell it to be of a given type.
and if i tell it to be of a given type then conversion needs to be implicit.

var a,b  'modeless numbers
int x ' hard defined integer
a= 4
b = 3.14
x = a * b

' x containins 13  (4x3.14 was evaluated as float yielding 12.56. cast to integer = 13 ( rounded up )
x = round_down(a*b) . x contains 12

the compilers KNOW the type you gave , so why do yo need conversion functions ? they can figure out exactly what to do.

I think your biggest issue is that you want to able to make things immutable, and python wasn't built with that in mind. Don't like it, then don't use it. Go write your own language.

You want constants? Here you go

Code: [Select]

In [36]: class Unit_Constant(type):
    ...:     _constant = 5
    ...:     _units = "kg"
    ...:     
    ...:     @property
    ...:     def constant(cls):
    ...:         return cls._constant
    ...:         
    ...:     def __add__(cls, other):
    ...:         return cls.constant + other
    ...:     def __str__(cls):
    ...:         return f"{cls.constant} {cls._units}"
    ...:     def __repr__(cls):
    ...:         return str(cls)
    ...:                                                                                                                               

In [37]: def make_constant(value, unit, description):
    ...:     class new_constant(metaclass=Unit_Constant):
    ...:         _constant = value
    ...:         _units = unit
    ...:         __doc__ =  f"""{description}"""
    ...:     return new_constant
    ...:                                                                                                                               
In [38]: pi = make_constant(3.14,"","circumference of circle over diameter")                                                           

In [39]: pi                                                                                                                           
Out[39]: 3.14

In [40]: e = make_constant(2.71828, "", "euler's number")                                                                             

In [41]: e                                                                                                                             
Out[41]: 2.71828

In [42]: g = make_constant(9.764, "m/s^2", "gravitational acceleration")                                                               

In [43]: g                                                                                                                             
Out[43]: 9.764 m/s^2

In[44]: help(pi)

Help on class new_constant in module __main__:

class new_constant(builtins.object)
 |  circumference of circle over diameter
 | 
 |  Data descriptors defined here:
 | 
 |  __dict__
 |      dictionary for instance variables (if defined)
 | 
 |  __weakref__
 |      list of weak references to the object (if defined)




The help() could be made better by explicitly typing out the class for each constant (which really isn't that bad) but with the class factory within that function you at least get the docstring.


Python wasnt written for this, its duck typed, and there is built in type checking because of what the language called generators. Generators generate the elements of an iterable when next() is called on that generator. I.e. instead of hardcoding out a list, you could do a generator expression and only get the items of what would be in that list as you go to access them. This is good because its fast and saves memory. The downside is that generators can only be iterated over only once. So if you wanted to check if some argument you were passing to a function was a generator, you would then expend that generator by checking it.

Its all a trade off. Don't like the features of the language and what it was written for? THEN DONT USE IT. Theres plenty of other languages.

By the sounds of all your complaining what you want is a statically typed language. Python is dynamically typed.

[Mattjd]

Create a new language.
One that isn't boneheaded and does not bank on whitespace for flow control.
One that does has a parser that understands when = is an assignment and when it is a comparison.
One that doesn't need every line to be ended in a semicolon, but uses a continuation character when needed.
One that doesn't smell like C, C++ or c# or Java or quiche-eaters pascal and its derivatives.
One that doesn't look like a bunch of cryptical mathematical equations
One that is easy to understand, uses simple english keywords.

something along these lines

a = 12
b= 14
c= b-a
for x = a to b
   c = c^x
  print a,b,x,c
next x


- simple english with a small vocabulary of keywords
- smart compiler that understands syntax and knows when to assign and when to compare. no need for walrus operators or == and other shenanigans
- smart code environment that uses autocompleteand puts the closing quotes around strings and fixes many speeelling errors
- interactive debugger that lets you singlestep through a program , examine data , add or remove instructions and rerun sections of code. No continuous code, attempt to compile, fix typing errors , missing brackets and semicolons , run , crash and not know where or why or even able to see or save the data. Fire up the program. if a mistake is encountered the program stops without loss of data. the debugger tells yu the most likely cause, lets you fix the source and then attempt to continue the run with the fix in place. while in debug you can execute code interactively , examine and alter data contents and even dump the current state of program and data to disk so it can be examined later without having to rerun the entire shebang. the entire machine state, data and all, can be saved.

I'm thinking to call it something along the lines of 'Ultima' or maybe something simple and basic... like 'Basic'.

Here is one of the reasons there have been so many languages over the years.  Free electron is speaking as a user - someone who just wants to get something done.

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

A perfect language for one group will never be the perfect language for the other.

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )


Why is it so hard to discriminate when  = means 'assign' and when it means 'compare' ?
When used in conjunction with an 'if' clause : comparison , anything else : assignment. is it really that hard to figure out for a compiler ?
The same thing with semicolons. At the end of the line of code there is a CR/LF ( or LF if you are on oonix ) in the source file. There is your bloody line ending and end of statement. if, and only if, it is so long  you really must spread it over multiple lines , use a continuation character. The number of times a command needs to be split over mulitple lines is far less than single line , so it saves keyboard hammering. besides, if your statement realyl is that long : maybe split it in a few simpler statements ? A book is made from many sentences. Not just one long sentence. If you want to keep it simple and approach a wide audience : use short sentences.

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
c = a+b ' since the compiler knows the type of a and b it will resolve to float
d = int(c)   ' the int operator always returns an integer so cast d as integer.
d = 5.0 ' throw an error . i goofed up .
b = b and &hff ' throw an error b is a float
d = int(b) and &hff ' works

for all i care you can have two operators : toint and tofloat

It is 2020 . The compilers should be able to figure these things out without us humans needing to spoonfeed them each and every time.

You really think this is clear?

Code: [Select]

A = 1;
B = 0;
C = A = B;

Sure, a compiler could be written to understand, but to the programmer, and other programmers reading it? = having two meanings is clear? Because it honestly looks like the person is assigning B to C. Not assigning whether A equals B to C.

[Mattjd]

ok. but here is the problem : how many spaces is a tab ? and do all operating systems / editors use the same convention ? THAT is the misery with using whitespace for code flow. the CR / CR/LF problem is already bad enough , now we have that shit too.

Can't mix spaces and tabs for leading white space in 3, so it's entirely irrelevant.

yeah , but what if you are stuck on 2.7 because you know. radical incompatibility int he language ( libraries )
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable. any goofy line of code can redefine pi to whatever. Kind of like B.S.Johnson which made a circle where the diameter to circumference ratio is exactly 3. Then again he also is famous for making such things as explosive mixtures containing nothing else but common sand and water , or making a triangle with three right angles.

Python 2.7 isn't even supported as of 2020 iirc, time to move on. The issue was realized and addressed.

[0culus]

Create a new language.
One that isn't boneheaded and does not bank on whitespace for flow control.
One that does has a parser that understands when = is an assignment and when it is a comparison.
One that doesn't need every line to be ended in a semicolon, but uses a continuation character when needed.
One that doesn't smell like C, C++ or c# or Java or quiche-eaters pascal and its derivatives.
One that doesn't look like a bunch of cryptical mathematical equations
One that is easy to understand, uses simple english keywords.

something along these lines

a = 12
b= 14
c= b-a
for x = a to b
   c = c^x
  print a,b,x,c
next x


- simple english with a small vocabulary of keywords
- smart compiler that understands syntax and knows when to assign and when to compare. no need for walrus operators or == and other shenanigans
- smart code environment that uses autocompleteand puts the closing quotes around strings and fixes many speeelling errors
- interactive debugger that lets you singlestep through a program , examine data , add or remove instructions and rerun sections of code. No continuous code, attempt to compile, fix typing errors , missing brackets and semicolons , run , crash and not know where or why or even able to see or save the data. Fire up the program. if a mistake is encountered the program stops without loss of data. the debugger tells yu the most likely cause, lets you fix the source and then attempt to continue the run with the fix in place. while in debug you can execute code interactively , examine and alter data contents and even dump the current state of program and data to disk so it can be examined later without having to rerun the entire shebang. the entire machine state, data and all, can be saved.

I'm thinking to call it something along the lines of 'Ultima' or maybe something simple and basic... like 'Basic'.

Here is one of the reasons there have been so many languages over the years.  Free electron is speaking as a user - someone who just wants to get something done.

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

A perfect language for one group will never be the perfect language for the other.

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )


Why is it so hard to discriminate when  = means 'assign' and when it means 'compare' ?
When used in conjunction with an 'if' clause : comparison , anything else : assignment. is it really that hard to figure out for a compiler ?
The same thing with semicolons. At the end of the line of code there is a CR/LF ( or LF if you are on oonix ) in the source file. There is your bloody line ending and end of statement. if, and only if, it is so long  you really must spread it over multiple lines , use a continuation character. The number of times a command needs to be split over mulitple lines is far less than single line , so it saves keyboard hammering. besides, if your statement realyl is that long : maybe split it in a few simpler statements ? A book is made from many sentences. Not just one long sentence. If you want to keep it simple and approach a wide audience : use short sentences.

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
c = a+b ' since the compiler knows the type of a and b it will resolve to float
d = int(c)   ' the int operator always returns an integer so cast d as integer.
d = 5.0 ' throw an error . i goofed up .
b = b and &hff ' throw an error b is a float
d = int(b) and &hff ' works

for all i care you can have two operators : toint and tofloat

It is 2020 . The compilers should be able to figure these things out without us humans needing to spoonfeed them each and every time.

OK, then come up with a compiler that can take a natural language as input, make perfect sense of it, and give you an executable. That's essentially what you're asking for. All the programming languages that I know of are operating somewhere on the Chomsky hierarchy. Wolfram Alpha sort of tries to break this barrier, but I've found that you still have to be very specific about parentheses and how you arrange things when feeding it something non-trivial.

[free_electron]

You really think this is clear?

Code: [Select]

A = 1;
B = 0;
C = A = B;


my language would prohibit that kind of nonsense. that is bad programming . just like in c 'for' statements  with all their trickery. bad ! it is unreadable.

[free_electron]

you still have to be very specific about parentheses and how you arrange things when feeding it something non-trivial.

parenthesis are good !. i like parenthesis. Mainly cause i hate having to figure out what things like this result to :
x = a + b * c - d /e + f

x = ((a+b) * (c-d)) / (e+f).  There. now it's clear.
 There is a programming language where you can write this actually as

x = (a+b) * (c-d)
         ________             <- underscore(s) . one or many , doesn't matter it means 'divide'
           (e+f)

Why ? because this guarantees that there is no bone headed mistakes in critical maths .
Where ? Space Shuttle flight control software. HAL/S

[0culus]

you still have to be very specific about parentheses and how you arrange things when feeding it something non-trivial.

parenthesis are good !. i like parenthesis. Mainly cause i hate having to figure out what things like this result to :
x = a + b * c - d /e + f

x = ((a+b) * (c-d)) / (e+f).  There. now it's clear.
 There is a programming language where you can write this actually as

x = (a+b) * (c-d)
         ________             <- underscore(s) . one or many , doesn't matter it means 'divide'
           (e+f)

Why ? because this guarantees that there is no bone headed mistakes in critical maths .
Where ? Space Shuttle flight control software. HAL/S

What?

Clearly, by the well known rules of operator precedence and associativity which most programming languages use

\$x = a + b \cdot c - d / e + f \$

is in no way the same expression as

\$x = ((a+b) \cdot (c-d)) / (e+f)\,.\$

You're just using parentheses to override the standard rules of precedence to make a different expression. There is no ambiguity here. Also, using formal language theory as your underpinning also allows your programs to be evaluated using formal methods...which goes towards the space shuttle software. The idea is the eliminate ambiguity; to do that you have to lose the subtleties of natural language. If you can't handle that, it's on you.

[boffin]

You really think this is clear?

Code: [Select]

A = 1;
B = 0;
C = A = B;


my language would prohibit that kind of nonsense. that is bad programming . just like in c 'for' statements  with all their trickery. bad ! it is unreadable.

How about using something else for assignment, like  perhaps :=

A := B + 1;

There were a lot of good ideas in Algol/Pascal.  It's a shame that people went to C for anything other than OS level stuff.

[free_electron]

Clearly, by the well known rules of operator precedence and associativity which most programming languages use

\$x = a + b \cdot c - d / e + f \$

is in no way the same expression as

\$x = ((a+b) \cdot (c-d)) / (e+f)\,.\$

You're just using parentheses to override the standard rules of precedence to make a different expression.

of course i'm doing that, to make my point ! it takes time to figure out what is written there. And do your programming languages also take into account things like sqrt  and "power of" when evaluating operator precedence ?
How about stupid mistakes when coding this simple formula :

Code: [Select]

         a
x =  ------
       b x c

how do you code this ?

Code: [Select]

x = a + b - c
are you certain it works correctly both on signed and unsigned numbers ? what if c is negative ? or b is negative ?
what if i do this :
x = a - b + c

What is the result of 5 + 3 -2 -9 *8 +2 * 3 / 5 + 2 ? . let the guesswork begin ...

go read this and panic :
https://en.wikipedia.org/wiki/Order_of_operations

excel does it different from wolfram or matlab of google.

x = -3^2 is what ? -9 or 9 ? depends on the programming language  -(3^2)  or (-3)^2 ...
it gets worse : do this x = 0-3^2  and the parser produces the opposite !

That kind of stupidity needs to stop. Use the goddamn brackets. Even fucking calculators get it wrong !
Code should evaluate left to right. There is no other order than left to right , except where explicitly stated by using brackets.
Many times complex formulas get coded wrong by people who think they are expert in operator precedence and 'brackets are for wussies'

[0culus]

RTFM?

Really, I don't see what the problem is. If you're writing C, you refer to C's rules for precedence and associativity and write your expressions accordingly. Writing Python? Refer to the documentation and figure out what the rules are. Doesn't really matter if they are "wrong" as long as you follow the rules.

If you want to invent your own language that does what you want, that's fine, but just know that attempting the create a grand unifying standard is always a fool's errand.

[TK]

We have for(int a=0; a<10; a++) in C/C++ for 20 years, move on.

Actually almost 50 years

[free_electron]

RTFM?

Really, I don't see what the problem is. If you're writing C, you refer to C's rules for precedence and associativity and write your expressions accordingly. Writing Python? Refer to the documentation and figure out what the rules are. Doesn't really matter if they are "wrong" as long as you follow the rules.

what if the rules change per language ( it does) , bloody annoying ...
what if it depends on the compiler !

i always use brackets. leave nothing to some quirck.

[ebastler]

I think this thread illustrates nicely why Guido van Rossum, after nearly 30 years of directing the development of Python, might have gotten fed up: Preferences on programming language and style are a very personal thing, often become the subject of strongly voiced opinions, or even heated debates. I would have had enough after one year...

[free_electron]

I think this thread illustrates nicely why Guido van Rossum, after nearly 30 years of directing the development of Python, might have gotten fed up: Preferences on programming language and style are a very personal thing, often become the subject of strongly voiced opinions, or even heated debates. I would have had enough after one year...

but , he was the dictator for life. So , what's the issue. he dictates. it's his language !

[ebastler]

but , he was the dictator for life. So , what's the issue. he dictates. it's his language !

Maybe there was a rebellion? 

[iteratee]

I wouldn't cry too many tears if python died away in time. I suspect it probably will. It's the product of an era when it was assumed that a slow interpreted dynamic language was needed to create expressiveness and high-abstraction. Its role was mainly as a "better" perl but ended up filling other roles as a general purpose language.

We now have better "gradually typed" multi-paradigm languages with solid support for both strong static types and optional dynamic types that easily match python in high-level abstraction and productivity while also being suitable "script-like" languages, embeddable extension languages, or systems programming langs usable in high-performance applications. I don't even have one particular replacement in mind - there are numerous worthy candidates.

Python isn't bad. You can do worse. I struggle though to think of any aspect of python that remains uniquely superior enough to justify choosing it for a new project today. There are quite a lot of things written in or that use python that are way cooler than the language itself. Thankfully porting python code isn't very difficult.

[0culus]

Python is used all the time to write research code at my work. Whether or not it is GOOD code is a different story...but it's still extremely useful for this type of code because there is a library for damn near anything you need. NumPy can be exceptionally fast too if you take advantage of it's features.

[Bud]

As a casual user trying to replicate others' python based projects my understanding is python perhaps is good for Right Now and Today type of projects. It is absolute nightmare however trying doing anything from some time ago because of python's poor back compatibility and because project authors rarely if any time at all specify which version of python they used. More than once i wasted time trying to run "just use python" type of projects to only realize the project used  one of previous python versions. Guido himself said python versions non-compatibility was intentional. Hows that can be good is beyond me.

[jfiresto]

As a casual user trying to replicate others' python based projects my understanding is python perhaps is good for Right Now and Today type of projects. It is absolute nightmare however trying doing anything from some time ago because of python's poor back compatibility and because project authors rarely if any time at all specify which version of python they used....

Could that be because there was just one branch of Python at the time, Python 2, and they would have needed a time machine to know about Python 3, let alone write code for it? Could you point me to an example so that I can duplicate the nightmare and understand where and how things went off the rails?

[Fixpoint]

Here is one of the reasons there have been so many languages over the years.  Free electron is speaking as a user - someone who just wants to get something done.

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

Why is it so hard to discriminate when  = means 'assign' and when it means 'compare' ?

In computer science, there is a very rich mathematical theory behind programming languages. This theory is responsible for those design decisions. Computer scientists do not create a language in a certain way so that it is "easier" because it doesn't get easier. Fom a computer-scientific perspective, the parser and compiler are just a diligent but routine piece of work. The *design* of the language itself -- i.e., the type system -- is the difficult part. Once you got that, the compiler is straight-forward.

make the compiler easier to write

No. The compiler doesn't get any easier or more difficult to write because the mathematics behind that doesn't change. As I said, this is just a routine piece of work and the really difficult part is the type system because that's the core of any language. What you see -- the syntax -- is NOT where the magic happens. From a computer-scientific perspective, the type system is. The syntax is of course important, but for a different reason and it is a completely different thing!

When used in conjunction with an 'if' clause : comparison , anything else : assignment. is it really that hard to figure out for a compiler ?

No. It is even trivial (and it always has been). As I said: that is a conscious design decision.

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out.

There is no "guesswork" involved. The compiler doesn't "figure" anything "out". For us as developers, there may be a difference between the LET or "=" syntaxes, but from a computer-scientifc perspective, it is exactly the same, and the complexity of the parser and compiler doesn't change in any way. The reason why they had this LET in BASIC was because they wanted BASIC to read like natural language, and LET is the usual mathematical expression for a definition: "Let x equal 5." That was the idea, the program should read like just like a natural English mathematical sentence. Keep in mind that computer science is a close relative of mathematics and follows the same line of thought, and this sometimes shows in the syntax of programming languages. This is especially true for modern ones that are designed not by hackers (like a very famous one from the 70s) but by people with a strong background in theory.

Same thing with creating variables. Why do i need to create a variable ?

Please believe me that the answers for this question have been around since the 1960s. Honestly, just familiarize yourself at least a LITTLE bit with computer science before writing a post like this. (I am sorry, but I feel very annoyed when reading this.) You are supposed to "create" a variable in order to express intent via the type system. That enables static analysis. Without expression of intent, there is no predicate that the internal theorem prover could use for verification. If you think you don't need something like that still in 2020, please learn more about software engineering -- it's time now!

It is 2020 . The compilers should be able to figure these things out without us humans needing to spoonfeed them each and every time.

They are able to "figure this out" and always have been. It is a conscious design decision to force the developer to express intent. In software engineering, there is a large amount of theory that piles up upon this fundamental principle. If you don't know any of this, of course variable declarations etc. may seem redundant to you.

[Howardlong]

It is absolute nightmare however trying doing anything from some time ago because of python's poor back compatibility and because project authors rarely if any time at all specify which version of python they used. More than once i wasted time trying to run "just use python" type of projects to only realize the project used  one of previous python versions. Guido himself said python versions non-compatibility was intentional. Hows that can be good is beyond me.

Been there, done that. I totally agree.

[Fixpoint]

It is absolute nightmare however trying doing anything from some time ago because of python's poor back compatibility and because project authors rarely if any time at all specify which version of python they used. More than once i wasted time trying to run "just use python" type of projects to only realize the project used  one of previous python versions. Guido himself said python versions non-compatibility was intentional. Hows that can be good is beyond me.

Been there, done that. I totally agree.

What Guido means is that at some point in time, you just need to clean up the mess. Python is a very old language (designed in the 1980s), so when you keep backwards compatibility, it can become very difficult to solve problems inherent in the old language design, and if you try to work around them, you introduce other problems that also may be severe. The language suffers and so do the projects associated with it. At some point, it is a reasonable decision to make a cut and break backwards compatibility.

"Just use Python" basically refers to the libraries. The reason why Python is so successful is not because of the languague design but because there is a huge amount of libraries available for basically each and everything that gets you started very quickly. Library availablity is a real killer argument in many discussions. The language itself has extreme drawbacks when we are talking about software design, architecture, and verification, but -- as always -- nobody cares.

[Howardlong]

It is absolute nightmare however trying doing anything from some time ago because of python's poor back compatibility and because project authors rarely if any time at all specify which version of python they used. More than once i wasted time trying to run "just use python" type of projects to only realize the project used  one of previous python versions. Guido himself said python versions non-compatibility was intentional. Hows that can be good is beyond me.

Been there, done that. I totally agree.

What Guido means is that at some point in time, you just need to clean up the mess. Python is a very old language (designed in the 1980s), so when you keep backwards compatibility, it can become very difficult to solve problems inherent in the old language design, and if you try to work around them, you introduce other problems that also may be severe. The language suffers and so do the projects associated with it. At some point, it is a reasonable decision to make a cut and break backwards compatibility.

"Just use Python" basically refers to the libraries. The reason why Python is so successful is not because of the languague design but because there is a huge amount of libraries available for basically each and everything that gets you started very quickly. Library availablity is a real killer argument in many discussions. The language itself has extreme drawbacks when we are talking about software design, architecture, and verification, but -- as always -- nobody cares.

C is an even older language. You can still compile K&R style if you want.

I found the incompatibilities between 2 and 3 of Python on my first foray to be enough to leave a permanent bad taste in my mouth. You shouldn't need to be a programmer to have to deal with having the right version of Python installed. It would have been better if they'd used a change of file extension such as .py3 to allow  for this and make it blindingly obvious. It won't be unusual to have V2 and V3 Python scripts co-existing on the same machine, but that doesn't seem to have been taken into account.

[Fixpoint]

C is an even older language. You can still compile K&R style if you want.

So? You can still use Python 2, if you want. The interpreter isn't suddenly gone.

"C 2.0", if you will, is C++, and that's not backwards compatible with C. You can still use C, but in general, you can't compile C with a C++ compiler, except in border cases.

[Howardlong]

C is an even older language. You can still compile K&R style if you want.

So? You can still use Python 2, if you want. The interpreter isn't suddenly gone.

"C 2.0", if you will, is C++, and that's not backwards compatible with C. You can still use C, but in general, you can't compile C with a C++ compiler, except in border cases.

... and C++ source files have extensions showing as such.

You can compile C with C++ compilers, that’s a very common use case. I’ve been doing exactly that for decades.

If you want to discuss versions of C, you can look at K&R, ANSI/ISO, C89, C99 etc etc. They are all backwards compatible.

The point is that the average Joe gets given some Python script to run which happens to have been developed in, say, 2.6. Without any other instructions, understandably they install the latest Python 3.x environment. And the script doesn’t run. That’s another very common use case.

[Fixpoint]

The point is that the average Joe gets given some Python script to run which happens to have been developed in, say, 2.6. Without any other instructions, understandably they install the latest Python 3.x environment. And the script doesn’t run. That’s another very common use case.

Isn't there the .py3 file extension?

[Howardlong]

The point is that the average Joe gets given some Python script to run which happens to have been developed in, say, 2.6. Without any other instructions, understandably they install the latest Python 3.x environment. And the script doesn’t run. That’s another very common use case.

Isn't there the .py3 file extension?

Is there? But a V3 interpreter interprets a .py as V3. That's the point, no backwards compatibility.

[tszaboo]

const pi = 3.17
print pi

print (numpy.pi)

the standard rules of precedence

Whoever invented it was an evil man, who wanted to create the single largest collection of mistakes in any programming language. It's evil and unnesesaey.

but , he was the dictator for life. So , what's the issue. he dictates. it's his language !

Maybe there was a rebellion? 

It just became so big, because people actually are using it.

As a casual user trying to replicate others' python based projects my understanding is python perhaps is good for Right Now and Today type of projects. It is absolute nightmare however trying doing anything from some time ago because of python's poor back compatibility and because project authors rarely if any time at all specify which version of python they used. More than once i wasted time trying to run "just use python" type of projects to only realize the project used  one of previous python versions. Guido himself said python versions non-compatibility was intentional. Hows that can be good is beyond me.

They painted themselves into a corner. With exceptions like the print statement. And 3/2=2. It had a bunch of nonsense result, it had to die. Only reason they keep it alive, because there are a bunch of server backend already running on 2.7. I think it is more annoying that it doesnt have python38.exe python27.exe, and the installation folder keeps jumpring around in windoes. I think it is somewhere in the appdata folder now.

Explicit type declarations for much code (small projects, test code, personal code and many others) is kind of like a forced check to make sure your shoelaces are tied.  A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.  If it is code with safety of life consequences it is definitely worth it.  In other cases not so much.  A smart enough compiler could flag instances where the shoelaces seemed to be untied.

semi-Agree. Then can we at least have upward expansion for free ? if there is no risk of loss of data : convert. And can we make a smart IDE that underlines conversions that can go bad ? if, during the coding step you do
int x
float a,b

x = a/b  : put a red squiggle under X. hover mouse and it says : warning : converting float to integer

int x,a,b
x = a/b : red squiggle
x = a\b : no squiggle. this is integer division

That would help a lot. These checks should be easy to implement in visual studio.

No, they shouldnt do this. This is working code in python:

def mul(a,b):
   return a*b
mul(1,2)
mul(1.51212,2)
mul(numpy.array([[1, 2], [4, 5]]),numpy.array([[7, 8], [9, 10]]))
Yes the same function will multiply matrices if you want to. Once you really learn the language, it feels like C is checkers, and Python is "5d chess with multiverse time travel"

I'm seeing this with many people who are new for python, and worked with C for a long time. They have problems, like how to run indexes on lists in for loop. And when I see their code, I can rewrite the entire 5+ line code into a list comprehension.

Honestly, the entire walrus operator fight was nonsense. I mean, I understand, that it is his language, but what we are writing is our code. Nothing forces them to use the operator. Dont like it, dont use it.

[jfiresto]

... I'm seeing this with many people who are new for python, and worked with C for a long time. They have problems, like how to run indexes on lists in for loop. And when I see their code, I can rewrite the entire 5+ line code into a list comprehension....

Back in the days when C was becoming popular, we used to say that you could write FORTRAN in any language. Trying to write C in FORTRAN usually does not end well.

Honestly, the entire walrus operator fight was nonsense. I mean, I understand, that it is his language, but what we are writing is our code. Nothing forces them to use the operator. Don't like it, don't use it....

The same used to be true of Python and people used it because they liked to. The problem now, and with the latest, possible cruft Python has been gaining, is that some are forced to use it and overall it is not making their lives happier.

[Fixpoint]

In order to stay relevant in the long term, Python must do what all other languages must do, namely adapt and modernize. Honestly, my impression is that those who complain about adaptations and modernizations usually just want to hack quick & dirty code like they have been used to for 20 or even more years and are not interested in what the world around them does or how it evolves, in computer-scientific reasoning and/or the rationale behind it all. Instead they use an argumentum ad ignorantiam. "WHY must I do this now?" "WHY should this be better?" Also, they abuse the "keep it simple" paradigm by trying to use it as an argument for keeping everything within their own limited intellectual reach. And all of this despite the fact that the language designers explain everything in great detail. But a lack of interest and understanding is a bad position for reasonable criticism.

[CatalinaWOW]

In order to stay relevant in the long term, Python must do what all other languages must do, namely adapt and modernize. Honestly, my impression is that those who complain about adaptations and modernizations usually just want to hack quick & dirty code like they have been used to for 20 or even more years and are not interested in what the world around them does or how it evolves, in computer-scientific reasoning and/or the rationale behind it all. Instead they use an argumentum ad ignorantiam. "WHY must I do this now?" "WHY should this be better?" Also, they abuse the "keep it simple" paradigm by trying to use it as an argument for keeping everything within their own limited intellectual reach. And all of this despite the fact that the language designers explain everything in great detail. But a lack of interest and understanding is a bad position for reasonable criticism.

The way I hear this argument is that a language that was designed to make quick easy code hacks has grown in popularity and starting taking on big jobs that require coding rigor.

So it is trying to become Ada and has abandoned its original purpose.

The comment shares a lot with the previous comment on FORTRAN, a language designed for scientific computing and which is still quite suitable for that purpose.  But it is shear agony to write a compiler or a windowing user interface in FORTRAN.  I am personally quite happy that FORTRAN has not been forced to modernize into a language suitable for the latter purposes.

[Fixpoint]

So it is trying to become Ada and has abandoned its original purpose.

Well, it is not *trying* to become something else -- it HAS become something else just because of its wide acceptance in the development community. When large projects are implemented using Python, the requirements change. That's just a fact of life.

I am personally quite happy that FORTRAN has not been forced to modernize into a language suitable for the latter purposes.

Believe me, I am also happy about that. Of course, you can achieve every goal with FORTRAN, but from a software development/CS perspective, it is just an awful language that is beyond hope. It always has been.

[CatalinaWOW]

When large projects are implemented....

Instead of changing an entire language should have chosen an appropriate language for big projects

[tszaboo]

Honestly, the entire walrus operator fight was nonsense. I mean, I understand, that it is his language, but what we are writing is our code. Nothing forces them to use the operator. Don't like it, don't use it....

The same used to be true of Python and people used it because they liked to. The problem now, and with the latest, possible cruft Python has been gaining, is that some are forced to use it and overall it is not making their lives happier.

Yes, true. I had to learn it in my previous job, because the device-backend communication was written in it. Current job our entire ERP system is in python.

When large projects are implemented....

Instead of changing an entire language should have chosen an appropriate language for big projects

What exactly do you think makes a language suitable for large projects?

[CatalinaWOW]

Honestly, the entire walrus operator fight was nonsense. I mean, I understand, that it is his language, but what we are writing is our code. Nothing forces them to use the operator. Don't like it, don't use it....

The same used to be true of Python and people used it because they liked to. The problem now, and with the latest, possible cruft Python has been gaining, is that some are forced to use it and overall it is not making their lives happier.

Yes, true. I had to learn it in my previous job, because the device-backend communication was written in it. Current job our entire ERP system is in python.

When large projects are implemented....

Instead of changing an entire language should have chosen an appropriate language for big projects

What exactly do you think makes a language suitable for large projects?

Probably the same things you do.  The kind of requirements that have changed for Python. 

The only argument for changing the implementation of the language rather than changing the language used for the task is the investment in code.  But that investment is thrown out the window if the new rules don't allow for backward compatibility.

[Fixpoint]

The only argument for changing the implementation of the language rather than changing the language used for the task is the investment in code.

What do you mean by that? When the language changes, the implementation (i.e. the interpreter or compiler) always has to change. If the implementation changes, this does not necessarily mean that the language has changed. Compilers are changed all the time without changing their respective languages.

But that investment is thrown out the window if the new rules don't allow for backward compatibility.

It's by far not that simple. Backward compatibility has extreme drawbacks. A notorious example is Java. Nobody really knows why, but Mr Gosling designed Java with multiple severe flaws in the type system. Later, because of concerns for backwards compatibility, the issues were not completely solved. Instead, workarounds were built. We have been suffering from these workarounds since at least 2004 now. What I want to illustrate is that backwards compatibility can significantly impair code quality and design quality in the long run..

[CatalinaWOW]

OK.  I will spell it out.  I am suggesting that if a project grows to where the benefits of strong typing, variable localization and many other features of a language well suited to large projects it should bite the bullet and select an appropriate language.  It would have been better to make that selection at the outset, but there are many reasons that doesn't happen.

Attempting to upgrade the language in use is always possible, but what is the point?  Maybe a smaller learning curve for those who selected the small simple language in the first place.  But if the existing body of code cannot be re-used most of the labor invested in the legacy is lost.  Rather than upgrading the language, port the legacy code to a language of your choice.  Your points about Java are another way of saying the same thing.

Think of it this way.  Would you like to see FORTRAN upgraded to modern programming standards, and if so, why?  I wouldn't.  But for its original purpose it remains one of the best languages around.

[Fixpoint]

I am suggesting that if a project grows to where the benefits of strong typing, variable localization and many other features of a language well suited to large projects it should bite the bullet and select an appropriate language.

You are completely right. But there are two problems:

• Those benefits you are talking about are needed pretty soon, much much sooner as most people think who are just used to tinkering and hacking. In a professional environment, software grows extremely quickly -- and yes, even that software that was never supposed to grow in any way! So, you need to lay the foundations for that right from the beginning. You cannot do that later. In a colloquial sense, software architecture can be described as those properties that cannot be changed but only re-engineered.
• Real-world contraints prohibit any kind of re-engineering. No boss, no client, and no deadline will ever ever ever allow me to scrap the existing code base and rebuild the system. It's not gonna happen. I have been working in the software industry for many years now, and I always advocate for solid designs. And if I know one thing then that a solid design must be built right from the start because refactorings are not gonna be approved. Even if, then only under very limited conditions. And it is not fun at all. Why do a refactoring if you could have done it right in the first place?

It would have been better to make that selection at the outset, but there are many reasons that doesn't happen.

EXACTLY.

Rather than upgrading the language, port the legacy code to a language of your choice.

Ok. But who pays for that? The client will give you the finger. Even for a small to midsized project, that can cost millions of dollars. It's not only simple arithmetics that has to be translated. Whole technologies must be exchanged because they are bound to a specific programming language. You might have to rebuild complete frameworks. If your software is safety-critical, the complete risk analysis and certification (expensive and time-consuming) has to be done again. And third-party software might have to be adjusted too! It can be an enormous, endless endeavor. It just doesn't work that way.

Think of it this way.  Would you like to see FORTRAN upgraded to modern programming standards, and if so, why?  I wouldn't.  But for its original purpose it remains one of the best languages around.

No, I don't want to see FORTRAN *anywhere*. I had to deal with it, and it's just an abomination. The code is a basically a time travel back into the earliest beginnings of human reason.

[tszaboo]

Probably the same things you do.  The kind of requirements that have changed for Python. 

The only argument for changing the implementation of the language rather than changing the language used for the task is the investment in code.  But that investment is thrown out the window if the new rules don't allow for backward compatibility.

I think you misunderstand me. I think python is an excellent language, starting from 4 liner BASH replacement to massive software protects. It is extremely versatile language. You can write your code on your laptop, and changing a few lines, you can run it on multiple CPU cores, multiple servers, Google TPU, your video card or heck, you can run massive computation projects on AWS.

Rather than upgrading the language, port the legacy code to a language of your choice.

Ok. But who pays for that? The client will give you the finger. Even for a small to midsized project, that can cost millions of dollars. It's not only simple arithmetics that has to be translated. Whole technologies must be exchanged because they are bound to a specific programming language. You might have to rebuild complete frameworks. If your software is safety-critical, the complete risk analysis and certification (expensive and time-consuming) has to be done again. And third-party software might have to be adjusted too! It can be an enormous, endless endeavor. It just doesn't work that way.

Actually, people do this, because the performance gain is immense. You could write maybe coprocessing FORTRAN,  but it is the second circle of hell. And then it runs on your CPU. If you have the same calculation done in python, you have to replace "import numpy" with "import cupy" ... and suddenly your code runs maybe 500 times faster, and the limit is just how much you are willing to pay for hardware or the time on someone else's computer.

[0culus]

Nvidia has their cuGraph library that boast some pretty impressive speedup on notoriously intensive graph problems too. It's not as mature as I'd like yet, but it is incredibly fast if you have some GPU compute available.

[Fixpoint]

changing a few lines, you can run it on multiple CPU cores, multiple servers, Google TPU, your video card or heck, you can run massive computation projects on AWS.

As far as I know, the Python language does not have any support for parallelization. The magic is done by the modules "threading" and "multiprocessing" which are just regular libraries. Just have a look at the source code and you'll see.

So, that is possible with virtually all other languages as well, C included. It has nothing to do with the Python language.

Actually, people do this, because the performance gain is immense.

Well, as I explained in great detail, this is in general not possible because the costs are way too high. If you can translate a project from one language into another, you are living in a very lucky special case. Your application is probably just arithmetics and well-understood.

you have to replace "import numpy" with "import cupy" ... and suddenly your code runs maybe 500 times faster

You can have a special case where this happens, yes, but in general, no. It is mathematically provable that this is in general a false statement.

And again: It is not a matter of Python but of a library. You can do that in each and every other language as well. If you are interested, I'll explain how.

[tszaboo]

changing a few lines, you can run it on multiple CPU cores, multiple servers, Google TPU, your video card or heck, you can run massive computation projects on AWS.

As far as I know, the Python language does not have any support for parallelization. The magic is done by the modules "threading" and "multiprocessing" which are just regular libraries. Just have a look at the source code and you'll see.

So, that is possible with virtually all other languages as well, C included. It has nothing to do with the Python language.

It is possible, however the amount of work to make some code working with parallel processing is 5 minutes on python and probably months on C.

Actually, people do this, because the performance gain is immense.

Well, as I explained in great detail, this is in general not possible because the costs are way too high. If you can translate a project from one language into another, you are living in a very lucky special case. Your application is probably just arithmetics and well-understood.

I gave you an example, why projects are re-written. You have to treat it as an example.

And again: It is not a matter of Python but of a library. You can do that in each and every other language as well. If you are interested, I'll explain how.

No, not really interested. Any time I start programming something, two things come to my mind:
1) This would be a lot simpler in python.
2) Why am I programming, I am an EE. I should be designing a PCB.

[Fixpoint]

Any time I start programming something, two things come to my mind:
1) This would be a lot simpler in python.

I understand that, for two reasons:

• Usually, a tool you know well is a tool that is efficient for you. Greybeards who have used C or FORTRAN all their life usually tell me "C/FORTRAN is a great language". Problem is, they live in a bubble.
• You say you are an EE, so that means that you are probably doing things of a certain nature, maybe computational or control stuff. Python has very strong library support for that. But from a wider software development perspective, there are more things to consider. Unfortunately, Python has weaknesses in those areas.

My problem with Python is the culture it is associated with.

In my life, I have met too many people who had a tendency to view the hardware part as "the project" and the software part as "the nonsense that has to be done for technical reasons but that nobody cares about". Python caters to this viewpoint of "just get it done and don't care", and that's why it frustrates me. The result is bad software and bad products. I think we all agree that a product is not good or safe just because it works somehow.

It's not Python's fault as such, but it just has come this way. I have learned to see Python as the leader of a "don't know, don't care" culture. So, maybe you understand where I come from and what my reservations are.

[Howardlong]

In my life, I have met too many people who had a tendency to view the hardware part as "the project" and the software part as "the nonsense that has to be done for technical reasons but that nobody cares about". Python caters to this viewpoint of "just get it done and don't care", and that's why it frustrates me. The result is bad software and bad products. I think we all agree that a product is not good or safe just because it works somehow.

Is that not because of Python, rather than despite Python? I mean, you don't go to Python to write bare metal, which is where us deeply embedded hardware people live. I like to think most of us care about performance and efficient use of resources. Most of that mindset goes out of the window with Python.

[Fixpoint]

Is that not because of Python, rather than despite Python? I mean, you don't go to Python to write bare metal, which is where us deeply embedded hardware people live. I like to think most of us care about performance and efficient use of resources. Most of that mindset goes out of the window with Python.

Yes, bare metal isn't done with Python, but there are other things that are done with Python that can still be safety-critical. I once worked in such a project, and in a meeting I pointed out some fundamental problems with the Python system (safety-critical!), but they didn't know AND didn't care. That's an example of the "don't know, don't care" culture I was talking about.

And the other thing: today's microcontrollers are so powerful and the software projects oftentimes so complex that it wouldn't be a good idea to optimize down to the individual clock cycle. If you have a 32-bit chip running at 20 MHz and 16, 32, or 64 KB of RAM, there is rarely an excuse anymore for bad software design (or the lack thereof). The chip is by far powerful enough to accommodate a few clock cycles and some bytes of overhead.

[Howardlong]

And the other thing: today's microcontrollers are so powerful and the software projects oftentimes so complex that it wouldn't be a good idea to optimize down to the individual clock cycle. If you have a 32-bit chip running at 20 MHz and 16, 32, or 64 KB of RAM, there is rarely an excuse anymore for bad software design (or the lack thereof). The chip is by far powerful enough to accommodate a few clock cycles and some bytes of overhead.

“a few clock cycles”.... if only it were. That’s the problem, performance is so often an afterthought, not part of the design criteria. I beleive that this stems from the mentality of separation of functional and non functional requirements, inevitably non functional requirements become afterthoughts.

A practical demonstration is to compare a Keysight Infiniivision scope to a Tek MDO scope. One is built from the ground up to perform well in all use cases, it’s in its DNA. The other one isn’t.

[Mattjd]

Whats faster a program that takes 8 months to write and finishes in 5 minutes or a program that takes 1 day to write and finishes in 5 hrs?

People like Python because its easy to learn, intuitive to write, and there is loads of open source community support for it. Why is there loads of open source community support though? Well that's because if you learn the lower level details of the language such as the CRO and Dunders then you can write very dynamic, portable, and minimalist code.

Duck typing is one of the best features of Python imo. Tell me C++ coders don't want it. Literally almost every C++ developer where I work just loves loves loves Templates. Wouldn't it be nice to not have to write a template for every possible type?

This is all a trade off people.

Python is realizing the need for static type checking, hence core Python is in full support type annotations of variables, functions, and classes. There are then non-definition time tools just as MyPy which will tell you if you are reassigning or passing an annotated variable incorrectly. If you're still stuck in 2.7 land, well sucks to be you and your company. Like I stated earlier, its not even supported anymore. I don't even think python 3.5 is being supported since earlier this year.


Again, if you don't like Python, don't use it.

Reading these posts, it really seems like what everyone wants is for Python to be written like Java. Go write Java then

[Howardlong]

Whats faster a program that takes 8 months to write and finishes in 5 minutes or a program that takes 1 day to write and finishes in 5 hrs?

People like Python because its easy to learn, intuitive to write, and there is loads of open source community support for it. Why is there loads of open source community support though? Well that's because if you learn the lower level details of the language such as the CRO and Dunders then you can write very dynamic, portable, and minimalist code.

Duck typing is one of the best features of Python imo. Tell me C++ coders don't want it. Literally almost every C++ developer where I work just loves loves loves Templates. Wouldn't it be nice to not have to write a template for every possible type?

This is all a trade off people.

Python is realizing the need for static type checking, hence core Python is in full support type annotations of variables, functions, and classes. There are then non-definition time tools just as MyPy which will tell you if you are reassigning or passing an annotated variable incorrectly. If you're still stuck in 2.7 land, well sucks to be you and your company. Like I stated earlier, its not even supported anymore. I don't even think python 3.5 is being supported since earlier this year.


Again, if you don't like Python, don't use it.

Reading these posts, it really seems like what everyone wants is for Python to be written like Java. Go write Java then

Absolutely right, it's horses for courses, with a sprinkling of bias to using the skillsets and tools that you have at hand.

[tszaboo]

In my life, I have met too many people who had a tendency to view the hardware part as "the project" and the software part as "the nonsense that has to be done for technical reasons but that nobody cares about". Python caters to this viewpoint of "just get it done and don't care", and that's why it frustrates me. The result is bad software and bad products. I think we all agree that a product is not good or safe just because it works somehow.

Is that not because of Python, rather than despite Python? I mean, you don't go to Python to write bare metal, which is where us deeply embedded hardware people live. I like to think most of us care about performance and efficient use of resources. Most of that mindset goes out of the window with Python.

That is not strictly the case. If you have some general purpose code, with lot of branches, creating and deleting variables, then yes, python will be slower. Sometimes this doesnt even matter, because the code is short, and a few microseconds makes no difference.

When it comes to disc read, computational tasks, database handling, etc... it can reach speeds that are very close to C/C++. It's all in the libraries, that were written and optimised by the experts. When you write code to do matrix multiplication, the underlying function is not going to be pure python code, it is going to call from a selection of optimised functions (maybe written in C / C++) one that will do the multiplication, and return the result. There is an overhead, but it is small.

And here is to consider something: Most C / C++ coders dont know the optimiser. They dont understand how branch prediciton works on modern CPUs. They dont know about cache sizes. Or they dont know how to optimise the code to several different architectures. There will be that champion programmer, that can do it. But an average python programmer, using the usual well understood libraries could write a faster code, with less bugs than an average C programmer.

Yes, bare metal isn't done with Python, but there are other things that are done with Python that can still be safety-critical. I once worked in such a project, and in a meeting I pointed out some fundamental problems with the Python system (safety-critical!), but they didn't know AND didn't care. That's an example of the "don't know, don't care" culture I was talking about.

Yes, safety critical... I mean, you are supposed to use the right screwdriver for the job, right? Project requirements not communicated well, and not understood well is not really a problem of the language. I'm not even sure, if you can write safety critical code in python in the first place, because you would need to prove that the interpreter is safe in the first place.  That is not done AFAIK.

[Howardlong]

In my life, I have met too many people who had a tendency to view the hardware part as "the project" and the software part as "the nonsense that has to be done for technical reasons but that nobody cares about". Python caters to this viewpoint of "just get it done and don't care", and that's why it frustrates me. The result is bad software and bad products. I think we all agree that a product is not good or safe just because it works somehow.

Is that not because of Python, rather than despite Python? I mean, you don't go to Python to write bare metal, which is where us deeply embedded hardware people live. I like to think most of us care about performance and efficient use of resources. Most of that mindset goes out of the window with Python.

That is not strictly the case. If you have some general purpose code, with lot of branches, creating and deleting variables, then yes, python will be slower. Sometimes this doesnt even matter, because the code is short, and a few microseconds makes no difference.

When it comes to disc read, computational tasks, database handling, etc... it can reach speeds that are very close to C/C++. It's all in the libraries, that were written and optimised by the experts. When you write code to do matrix multiplication, the underlying function is not going to be pure python code, it is going to call from a selection of optimised functions (maybe written in C / C++) one that will do the multiplication, and return the result. There is an overhead, but it is small.

And here is to consider something: Most C / C++ coders dont know the optimiser. They dont understand how branch prediciton works on modern CPUs. They dont know about cache sizes. Or they dont know how to optimise the code to several different architectures. There will be that champion programmer, that can do it. But an average python programmer, using the usual well understood libraries could write a faster code, with less bugs than an average C programmer.

Yes, bare metal isn't done with Python, but there are other things that are done with Python that can still be safety-critical. I once worked in such a project, and in a meeting I pointed out some fundamental problems with the Python system (safety-critical!), but they didn't know AND didn't care. That's an example of the "don't know, don't care" culture I was talking about.

Yes, safety critical... I mean, you are supposed to use the right screwdriver for the job, right? Project requirements not communicated well, and not understood well is not really a problem of the language. I'm not even sure, if you can write safety critical code in python in the first place, because you would need to prove that the interpreter is safe in the first place.  That is not done AFAIK.

In this case you're right, of course. About three or four years ago, I was talking to an old work colleague and was surprised to find they were using Python on their backend high frequency trading systems: of course, this wasn't for the real grunt low latency response stuff, it was for scripting and managing processes.

Now you mention databases: this is another bone of contention. There's been a huge shift over the past decade or so towards using ORM abstractions on databases such as Hibernate and Linq. While this might make the programmer's life easy, and is all fluffy and nice for the architects, when those abstractions don't perform in given use cases, it's difficult to create maintainable resolutions when the code is hidden away in the abstraction. It's a paradigm almost as old as the hills to rely on programmer apathy and optimiser telepathy! For a DBA, when a vendor says their new optimiser is so much better, it's a signal that, while there may be fewer performance edge cases, those that remain will be even harder to fix.

[Marco]

Your complaint would be equally valid for relational databases. If you're going to suffer opaque execution, might as well get pretty code.

It's only half the shift any way, there's also NoSQL in the other direction. Choice is great, except the choice of using SQL for web development in the last 3 decades ... that was a trillion dollar mistake.