Yet another icon stepping away - Guido van Rossum, Python

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