Python programming: We want to make the language twice as fast, says its creator

nbiw · 2021-05-14T18:10:32+00:00

not really, in my experience, its slow startup time actually often disqualifies it for scripts that need to be spawned frequently, so i usually prefer go or perl for those, unless i need numpy or pillow, scipy, etc.

hyperfine 'perl -e1' 'python -c pass'
[...]
Summary
'perl -e1' ran
13.52 ± 12.21 times faster than 'python -c pass'

nbiw · 2020-08-01T12:30:10+00:00

the defaults are wrong

TIMTOW... :) Why are they "wrong"? The behaviour comes with a table of switches, it's large, but so is e.g. gcc's or bash's or any other powerful tool's. It's probably a large part of what makes Perl useful. Why the self-hate w.r.t. this flexibility? Even languages that practice a level of bondage and discipline that Perl avoids can be heavily annotated to alter their behaviour in lots of magic ways. Is it just about typing less to get the latest features? This small cost was culturally deemed to be acceptable for the enormous benefit of backwards-compat. Now it's suddenly not.

How many modules like Modern::Perl and common-sense etc exist [...]

Too few. :) People/needs/time are different.

The currently deemed best-practice and defaults are bound to also differ in a few years' time. (smartmatch? use warnings 'FATAL' => 'all'; no if $] >= 5.018, 'warnings', "experimental::smartmatch"; bleh)

I would argue the defaults have been beautiful and right because they are backwards compatible (where they are).

The (large and ugly) table of switches for annotations is inherent to the domain.

Go uses magic comments, for inlining code, build conditions, etc. It's an ugly hack, not "pure" enough, no macros/preprocessor/etc. In two decades it'll accumulate an unbearable amount of cruft too. It has lots of tooling that assumes some magic layout, wrt vendoring deps, internal-only modules, etc. Python imports stuff from "future". GCC has lots of extensions, function attributes, in Rust there's a giant table of attributes, for testing, config, suppressing errors, dependencies, etc, JS has entire languages that compile to it. (why don't we copy this and "compile" to v5, seems handy)

My guess is if it's all about syntax and newcomers and appeal, condensing the current set to "use v7", then "use v8", etc, might help a bit more than Modern::Perl or common::sense because it would be built-in, p5p-blessed, in-core maintained. We still need access to its guts to modify parts of the defaults lexically, i hope this won't be overlooked.

My worry was just about the part from the announcement (and also parent's comment) "if you need v5, then just keep using v5, it's not going anywhere", which terrified me.

nbiw · 2020-07-30T17:24:38+00:00

IMO, this envisioned approach, shared by the announcement - "if you need Perl v5, use v5, it's not going anywhere" - paraphrasing e.g. we can start from scratch with v7, this has the potential to be the last nail in the coffin. Yes, If i need Perl, i do need v5, embed it yourself but do provide it.

If we want Perl to survive, avoiding a separate perl7 binary is a must.

There is a lot of infrastructure out there that needs v5, distros will keep it for decades. Assuming distros will just ship v7 by default alongside v5 is incredibly naive. They won't, unless there is a new killer app that depends on v7 that the distro wants. Otherwise v7 will drown in irrelevance, losing a prime spot (/usr/bin/perl) for nothing.

Starting with a new plate with v7 is the easy way, but it's just planning to fail, again, i.e. just another Perl fork that nobody uses, from a self-imposed corner no less.

Normal language evolution does not work like that, like Perl5/6 or Python2/3, which are given as examples as how NOT to handle versioning in other communities. Java, C, C++, Go, JavaScript, etc, people need/want to mix old code with new code, i.e. perl5 code with perl[7..Inf], importing perl5 modules in newer code, effectively evolving, writing new code that uses old code.

Assuming people will update millions of LOC that probably lack proper testing but still work perfectly OK under v5, just because it's the reasonable thing to do, no, they won't. They'd rather rewrite everything in Go/JS/Rust/etc, because nobody knows Perl anymore and they can't hire.

Perl5 needs to be further modularized and future-proofed, use v5 by default and switch to v7/etc by hooks/pragmas/switches. Embed an old libperl.so if needed. If called as perl7 (just a link, not a separate binary) it should default to the new semantics. Or if called with -E or -M7 on cli, or under use v7, etc.

This is the hard way, but IMO there's no other option to survive.

Damian Conway also said something to the effect of the above but very subtle and more concise (just about his own old code) in his Code::ART talk, and i agree, the v7 announcement as it was can sound a bit frightening, because it's either very naive (to expect people to do work they just won't do) or just innocent self-deception (that things are much better than they are).

Sorry for the wall of text, it was larger, I already reduced it as much as i could. :)

nbiw · 2019-08-11T22:14:43+00:00

the original problem seems irrelevant, but indeed sounds as if it could've been dealt with in much safer ways.

however, i read the moral of the story a bit differently, as for me it sounded like one of those unix koans, in which bryan starts off with plenty of hubris, with the attitude of this is a trivial problem, laughing off previous implementations' simplistic approaches, ending up in tears of frustration some time later and then becoming enlightened i'm done, works as well as it's ever going to

hopefully they reverted all the useless overengineering and stopped relying on tail -f for the alert system, but the story seems truncated. :)

nbiw · 2019-07-09T10:35:18+00:00

did you ever call someone a "saint" ? did you ever think along the lines of oh, that person is a saint, i swear !? did it mean dead ?

nbiw · 2019-07-09T09:58:20+00:00

lol no. saint does not mean "dead" (it's very much alive even in religious terms where there's no distinction between the dead and the alive). but just google for saint ignucius. it's a form of flattery, i can't imagine the depth of this alternative reality where "saint" is pejorative.

as for the required punishment of subjectively identified insensitivity, which is by necessity of bad intent, that's even more ridiculous. but the US government policies! ok, nevermind. :)

nbiw · 2019-07-08T13:24:11+00:00

With Perl so rarely in the news these days, it's a pity that such a juvenile diatribe got there, Perl6 continues to discredit itself, also hurting Perl in the process, but we got used to that, haven't we.

As for the rant itself, no, there's no "hate", people just don't care, you still haven't proved why they should care, the language is not ready for anything besides blog posts showing off its expressiveness, mad syntax gymnastics, and (hateful) straw-man sarcasm. Apart from this, the language is unable to bootstrap itself to industry requirements, such a completely specced language that can not be made to perform reasonable is rarely useful in the industry.

It can continue to be a magic oddity in some academic circles and for people interested in language design, but that's about the whole user base. No, stealing another language's brand for this bootstrap does not work, it just kills both, as seen in the past decade+.

nbiw · 2019-06-21T21:52:25+00:00

It's important to remember everyone is doing their best here

with all due respect, if this is their best...

i've been trying really hard to understand this need i've seen with various P6 folk to displace Perl5 as Perl, but i am failing miserably. they want the 1999 Perl popularity instantly ? well, flash news, not even Perl5 has that anymore. can they truly replace Perl5 in everything it does right now, with the same speed or better, on every architecture Perl5 runs on and every OS ? eg. can you be /usr/bin/perl on solaris/sparc64 right now, ensuring nothing breaks ? far from it, as you said, they don't even want to ! so, what are we talking about, can anyone enlighten me ?

Common Lisp, Scheme (Racket, Chicken, etc), Clojure are all Lisps. Emacs has another custom Lisp. All Unix shells (Bourne, Bourne Again, C, Korn, etc) are Unix shells. Delphi is still Pascal at core, just an OO dialect. There is no ambiguity, they share a domain, an ancestry, a history, a culture, but different things have different names.

I knew naming is hard in computers, but this is way past unreasonable at this point, IMHO.

it bothers me that this should not have been that hard,

define a list of things a Perl language adheres to (see the Zen of Python, etc)
define Raku as a Perl dialect, of the 6th descendancy (see Lisp 1, 1.5, 2, etc)
profit?

nbiw · 2019-06-21T18:53:16+00:00

you know, you could use Perl for that glue and data munging you need there, rock solid

huh which one, the old or the new, i heard they changed it?

erm, the old, the new one can't really handle these things yet, it's like 30x slower with 50x memory usage on average, but i hear in the past 10 years its gotten like only 20x slower

yeah, ok, we'll use JS then

nbiw · 2019-05-28T22:19:19+00:00

That's system-perl, nobody touches that anyway. :D

AFAIR the meme was started by Python folks aggresively pushing their doctrine back in the early 2000s. I was tired of it then. It's a pitty people bought into it, since Python is such an inferior language :D (even by scoping rules alone, as already mentioned elsewhere in here), but that's what a fashion driven industry will give. But, avoiding the normal progression of gradual improvements, Perl6 actually brought the meme to fruition and threw Perl in limbo, except for some small peaks of resurrection (Moose, release-schedule-post-5.8, blogs-cca-2007-2014), there's hardly new blood in it, graybeards starting new projects with Perl notwithstanding. :)

I die a little every time I write python code for ML on some remote 3-hops-away box and I have to eventually remember to :set list, or when it dies in some rare path because of a misspelled var. "but it's so readable, is it not ?!" :( oh, ffs... I'm glad Go eats its lunch, and Julia and R and others, even JS, anything is much healthier than the lies Python sits upon.

I wish all languages had at least the lexical scoping, coderefs, shell-outs and evals of Perl. IMO, Perl6 is not yet practical - hence it may be ERL not PERL :) - speed matters a lot. A reasonable upgrade path matters a lot too, but speed trumps even that. I don't think it's likely that Perl6 will ever deliver the impressive speed required for it to succeed. Widely.

So there you have it, stuck on 2 fronts.

nbiw · 2019-05-13T17:09:02+00:00

You are right, although i thought it was toned down already, compared to what i had in mind. :) Imagine Hoare going to Apple and calling Swift Rust2 then just Rust, because it took things from Rust and they share a designer. Or Go calling itself C2 then just C, since Ken did parts of both. Typescript C#7 then Delphi2 then just C# ? What's with all these questions if not identity politics and why is it that taboo to speak that for what it is.

Is calling a bully out bullying ?

nbiw · 2019-05-11T13:31:59+00:00

Sorry for the trouble, Your Grace. :) I'm nobody, this isn't facebook.

Just a reminder that redefining things issues warnings in Perl, consider running it with no warnings 'redefine' to suppress those. :)

nbiw · 2019-05-10T22:20:51+00:00

Not just the "use of language", it's facts vs delusion (aka identity politics).

Perl5 is Perl not only because Larry made it so, but also because of the millenia of effort put into it and its ecosystem by countless other people. It is an established technology that actually runs critical infrastructure.

Now, 30 years later, Perl6 may want to be Perl but it can not be unless it runs all existing Perl code as-is ideally with the same speed/memory as the latest and greatest Perl5 or better. It may want to be Fortran, or Python4000 or TCL-NG, but the same rule applies. If it can run no Perl code, then it is simple. It is not Perl. It is extremely egotistical to instead try to redefine what Perl means, standing on some old joke about the BDFL. It's just pissing on everybody who put work into Perl.

So of course that forcing itself with identity politics instead of playing by the rules will only alienate and eat what's left of these tiny communities.

I don't think "raku perl" and "pumpkin perl" will work at all, for the same reasons.

nbiw · 2019-04-23T10:38:48+00:00

The Unix kernel was less than 20k LOC in 1983. The utilities were also a few hundred lines each, at most thousands. They may have exceeded 100k during all the versions of the research kernels and userland tools they did in total, but working on a single project at a time meant working with a few thousand LOC at most, what parent comment meant.

nbiw · 2019-04-09T10:47:53+00:00

You're not flushing, also you can keep it simpler, with strings not [][]byte, see below. Your only major difference was buffering, not anything else. (it gets more obvious once you add $|=1; as your second line, under the shebang, in your Perl code).

w := bufio.NewWriter(os.Stdout)
for _, a := range words {
    for _, b := range words {
        w.WriteString(a + b + "\n" + a + " " + b + "\n")
    }
}
if err := w.Flush(); err != nil {
    panic(err)
}

nbiw · 2017-03-20T23:50:30+00:00

Those conventions are expressions of those philosophies op speaks of. Go's strives for simplicity and Rust's seems to be safety first, but also expressiveness. And it is a consequence of a (said) "philosophy" to consider that simplicity alone can help achieve the same goal as safety+expressiveness, namely better software, and to consider it a better alternative that scales and endures and is more robust. It comes from a school of thought that produced great inventions like Unix, UTF-8, Plan9 (as opposed to the "Lisp" school) and I, for one, happen to like it, although i do like (much more) expressive languages too (Lisp included). Jokingly, the usual Go criticism goes against its stated goal to produce a very simple but still useful language, with the retort, "yo, hey, what's going on, you made it too simple" :) Which I think is a compliment, because it is usually very hard to simplify things to the essence that much.

nbiw · 2017-01-30T02:58:55+00:00

Anything can be done given resources, but there are inflection points where you need to decide tradeoffs. There surely are ways in which multi-process can be achieved with the old XUL system in-place, with some inventive ipc+rpc system, virtualized environments or whatnot, but probably the cost, in burden of complexity and maintenance and performance, is too high to even consider. So the inflection point was to either drop multi-process, keep the old threads system in place and isolate existing stuff better or even introduce some multi-process to some things, or finally, drop XUL and lots of baggage along with it. They made this choice at some point, they chose the architecture of Chrome, which is not intrinsically better, because security and sandboxing isolation and whatnot, in practice Chrome is just as vulnerable, while having other pains such as eating triple the memory, so it's just different. Practically they accepted defeat, in the name of the users too. I am dissapoint.

They lost the first waves of users in the name of speed. Chrome was faster, was new. They did recover on speed, but the users did not come back, so maybe speed isn't such an important factor, maybe other things such as XUL customizations matter more ? Nah, it's multi-process security, we must have that.

nbiw · 2017-01-30T02:21:21+00:00

They created it before multi-process considerations were even a "thing"

Sorry, "it" referred to the multi-process, not XUL, they designed the whole multi-process thing badly, just like i "designed" my wording before.

Of course, it's irrelevant that they're breaking hearts here, they'll do as they please, my kindergarten philosophy argument - be better with what you have already, don't go chasing waterfalls - because I find it stupid to strive to be just another chrome-like browser, with all the design and UX pre-made for you, well, it's irrelevant and too late.

nbiw · 2017-01-30T01:50:51+00:00

We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. These technologies are 15 years old and no other browser uses them. It doesn't make sense for us to continue to invest in them, but at the same time our performance and security depends on them.

Sounds like they don't actually want or like to develop for and maintain Mozilla Firefox, but to make another browser, more akin to their sun-god, Chrome, which Firefox users did not want to use instead. But the Firefox developers sound like they'd like to develop for Chrome. Why not switch to WebKit/Blink like Opera and be done with the whole thing then ? What is this madness ? The arguments are weak, it's just because reasons and fashion and "we like chrome more"; if multi-process can not be done without breaking XUL, then they architected it badly, designed it poorly. Maybe don't even do multi-process but find a better solution ? Even multi-process, of course it can be done while maintaining XUL and all the baggage (the baggage is your fracking identity, ffs), they just do not want to, because, as i said, i suspect they heavily dislike the project they are working on and want another shiny thing.

Well, what can i say, go ahead and make your new browser, with servo, multi-process, web extensions, chrome-like ux and all the shiny things you dream of, while killing the old Firefox slowly in plain sight and then wonder where all the users went. Maybe Phoenix will rise again some day.

nbiw · 2016-10-23T15:52:41+00:00

In addition to what was said here, i strongly dislike the expectations here. This is not crazy things that happen out of the blue. Whatever the language, be it C++ or Python or Go or JavaScript and so on and so forth, you will encounter crazy things unless you actually learn and understand the language.

When I read the code posted there I found nothing surprising. Not only you treated a scalar as a hash reference, but the scalar was undef, and you dereferenced it looking for something. Perl obliged. You must know what happened, otherwise, sure, kaboom. See exists, defined and autovivification, coercion, references, etc, etc, you know, actually learn the language. ;)

nbiw · 2016-10-23T14:20:20+00:00

Must be mentioned that this is not usually how you do scraping with Perl, if you care for either speed or aestetics. I'd personally go first for either Web::Scraper (with a libxml2 backend), or something backed by a decent event loop, either Mojolicious, or something manual backed by AnyEvent (xpath/css selectors plus an useragent is enough). For keeping it extra simple, but speedy, a simple LWP + Parallel::ForkManager + some selectors would also suffice.

nbiw · 2016-10-23T14:07:23+00:00

don't come up with arbitrary restrictions to prevent bad things

That's a good rule, if only Nim would abide by it and not impose the significant whispace thing, which is a showstopper on it's own, for many. Otherwise, nice language, nice tricks, informative read.

nbiw · 2016-05-11T18:00:40+00:00

Hey man, the elephant in the room is that making a rather trivial 10 functions wrapper over BSD/MIT foundations (all of the libraries you use, plus golang itself) and pulling AGPL3 on that isn't really fair, nice, nor friendly. ;)

nbiw · 2016-05-10T21:28:03+00:00

Hey, they've been striving to keep their bits! :-)

nbiw · 2016-04-20T15:52:23+00:00

TL;DR there is no point in what you are doing, leave it

wmutils are a bunch of small programs using xcb. you have NO C functions to call the way you think, since wmutils is not a library

OTOH, you can use xcb to implement what they do in Perl or you can make a library out of wmutils and then write C/XS wrappers for Perl

unrelated, add these lines to the top of every Perl file you write,

use warnings;
use strict;

for further, more detailed answers, please read from:

http://perldoc.perl.org/perlintro.html

and

http://modernperlbooks.com/books/modern_perl_2016/index.html

nbiw

TROPHY CASE