Python creator Guido van Rossum sys.exit()s as language overlord

Re: reflecting opinions more than best practice

Flavour of the month for 15 years or so. It's been a widely used niche language for that time, widely espoused by developers as something that "should" take off more widely.

In the meantime, Ruby came as a competitor... and seemingly went.

Re: reflecting opinions more than best practice

"I'm old enough to know that Python is just the present "flavor of the month" programming language"

If using a flavour of the month language means that Perl finally crawls away and dies then thats good enough for me. Anyway, after being around this long I think its fair to say Python is part of the dev furniture now, not a newcomer.

Another language will come along

Yes, one with curly brackets, hopefully (yes, and proper indentation as well).

I’m sorry, but I just find code much easier to read (and write) when I can actually see the block delimiters!

Re: reflecting opinions more than best practice

perl -- not so much since he went on to try to create perl6. Since then it's been a bunch of curmudgeons that want to make it more obtuse and harder to learn. In addition to a recent backtrack on relaxing explicit prefix-sigils (@%) for references (that always include their type), they even added postfix sigils -- little tails you can play "pin the tail on the var" to indicate type.

perl's problem has been that most of those in charge know nothing about computer languages or computer science and have no formal training. A few do and that shows, but machine room operators don't make for good language designers.

This lack of background, but having expertise in perl shows just as it shows for C++ -- the designers

design for experts -- not new users, with ideas & projects to help and attract new users shot down as too simplistic or too DWIM'y (Do What I Mean) - one of the original design goals of perl that it's continued to drift away from. Anything that *they* wouldn't use or that deobfuscates the language is considered wrong. In addition to holes in the language that generate errors rather than provide a logical feature, they are adding more errors by taking away existing usable and useful features -- what a bonus! They don't want the language to go forward without them, so they are designing in its obsolescence. A shame really, especially since in many applications it ran 5-15 times faster than an equivalent python program -- more so if it involved parallelism.

But when it came to new designs, they believed in nuking problems rather than applying touch-up fixes. It took about 20 years to get back to a working unicode that works the same as it did 20 years back -- if they'd just fixed binary files (vs console text files). Instead they killed the whole feature and now perl's unicode has a permanently established bug where you can read in files in a local, 8-bit encoding, and they'll be written out in a multi-byte utf-8 encoding. The believed it was better to preserve this bug for posterity for ancient (20yr+) program compatibility. On one hand they'd keep the bad, but on another hand, they have no problem destroying compatibility by adding new behaviors that would be 'non-optional'. In regard to bugs: they regard them as virtues: "Historically, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility. Any accident of implementation or unintentional side-effect of running some bit of code has been considered to be a feature of the language to be defended with the same zeal as any other feature or functionality -- thus bugs have been cemented into the language with the effect of crippling growth.

Re: Actually, this has already been said about Python. Many times over.

>It looks good enough to get the job done.

Probably true for vast majority of use cases out there. You wouldn't want to use it say for embedded systems development though. It does have some JIT capability IIRC but horses for courses.

Re: Actually, this has already been said about Python. Many times over.

For a while until someone 'upgrades' something. I'm finding it increasingly difficult to 'get the job done again' as code that used to work no longer does due to different choices of which version of the language/libraries to settle on,

I'm trying to teach kids this stuff and having to take them through a virtual environment configuration for each flashy example is getting a bit fucking tedious.

Re: Futuristic progression of Programming Languages?

I agree that visual programming is very limited.

I think the future of code is in frame-based programming. Check out the Stride programming language used in the Greenfoot and BlueJ educational IDEs. It's designed to let you develop traditional line-paradigm code more efficiently by reducing the number of keystrokes and making syntax errors impossible and scope errors rare.

Every type of code statement has a limited range of possible syntaxes, so Stride turns each statement type into a template where you fill in the boxes. As an educational programming language, Stride maps to a subset of Java, and any Java code can be called from Stride.

It also renders the block delimiters vs meaningful whitespace debate moot, as blocks, scopes and indentation are handled by the editor automatically as the programmer is no longer dealing with plaintext.

I think this frame-based paradigm has real potential to change coding practices in a way visual coding never really did.

Re: Futuristic progression of Programming Languages?

"All hardware sucks, all software sucks, all languages suck."

You forgot OSes, they suck too. And worse, you forgot fanbois, who suck in all kinds of spectacular ways.

Re: Futuristic progression of Programming Languages?

"A program written in Python can be a fraction of the number of lines as a program which does the same thing in C."

This is both a blessing and a curse. Unfortunately, the folks who see it as a blessing will probably never fully understand why it's also a curse. Folks who know it's a curse debug code with the compiler's assembly output anyway, and don't care.

Re: Reinventing a more limited wheel

[(x, y, x/y) for x, y in ((x, f(x)) for x in input_data) if y > 0]

The new syntax is using less characters. This appeals to many programmers but I thought Python was not such a language.

Re: Reinventing a more limited wheel

I would be fascinated to hear how you would do the following in one line of idiomatic C using commas.

Well newlines are optional, and there is no limit on the number of statements per line, so pretty easy.

Re: Reinventing a more limited wheel

I'm curious about the example thames posted. Is

results = [(x, f(x), x/f(x)) for x in input_data if f(x) > 0]

really any slower than

results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0] ?

In the first expression, I can see that f(x) could potentially be evaluated three times, but would that actually happen? The example implicitly assumes that f(x) returns the same value each time it's evaluated. If that's the case, is the interpreter not smart enough to cache the result of f(x) for later use? (And if that's not the case - for example if f(x) returned x+time.time() - then the two expressions above aren't actually equivalent.)

Re: Reinventing a more limited wheel

> results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

That would surely be much more understandable in multiple lines:

vector<T> results;

for (x: input_data) {

auto y = f(x);

if (y > 0) results.append( make_tuple(x,y,x/y) );

}

...if that’s what it actually does....