upvote
> I like Julia approach, compile everything on first launch, then reuse without speed penality, if you change a function, recompile that.

Python already compiles to bytecode (the .pyc files are a cache thereof). It's just that interpreting even the simple bytecode instructions can take dozens of clock cycles each. I imagine that a lot of this is not in the interpreter loop (which has seen quite a bit of optimization, IIRC up to the level of "predictive" gotos within a big switch statement within a loop) but just unwrapping objects and moving values to and from registers, dealing with the fact that there is basically never any cache coherency for anything etc.

Basically I'm not convinced that writing out the set of machine-code instructions needed to interpret the bytecodes would be a big win, because it takes too many instructions for simple tasks.

reply
The Julia approach is the same as BASIC (as originally designed), Lisp, Prolog, as added info.
reply
I don't recall being able to inspect compiled machine code in basic like I can in Julia.

[EDIT - I assume you are commenting on Dartmouth BASIC.]

reply
And? That doesn't change the fact it was compiled into machine code before execution, nor that with exception of 8 bit home computers, there were plenty of compiled BASICs in mainframes and later 16 bit home computers.

Since we have to prove everything on Internet forums,

https://archive.org/details/bitsavers_dartmouthB_3679804/mod...

=> Saving of Compiled Programs

reply
The language forum is the place to start- you should already have a thread there gathering feedback before writing a pep?
reply
Thank-you, it's a longtime idea, but I was finally able to implement it, but now I'm trying to learn the procedure
reply
However because of this, Julia has has persistent problems with "time to first plot", which has gotten better, but they cannot fully ameliorate due to the way it fundamentally works. So there are tradeoffs -- the performance gets better, but the interpreted REPL experience is markedly worse.
reply
By the way, the current nightly (especially if considering the optimized build) has a very substantial TTFX drop compared to the current release [1]

[1] https://perf.julialang.org/?tab=overview

reply
It is overly exaggerated, especially when taken into account how long it takes to compile native libraries that people keep calling "Python" libraries, if there isn't a suitable wheel for the current environment.
reply
I think it's true that it's exaggerated, but that doesn't mean the tradeoff doesn't exist.
reply
A tradeoff that doesn't make sense to complain about, when the alternative is waiting for native libraries being compiled, in a mix of C, C++, Fortran and more recently Rust.

A pain point that is big enough that at least two programming languages, Julia and Mojo, were created to move beyond it.

Which would not even be an issue, if Lisp, Scheme and Prolog had not lost their aura among AI devs.

reply
Julia and Mojo are attempts at solving the "two language problem", which not every Python user actually has -- they're fine doing work exclusively in Python, not even using any of the libraries you're talking about.

Mojo in particular recognized to compete with Python they'd have to be a superset, then they backed of that goal when they realized it would be too hard.

So at the end of the day, Python has a value proposition and it cannot be entirely subsumed by other languages, because those languages make tradeoffs that move away from Python's value.

reply
Python's value is being a portable scripting language, a better Perl, unfortunately some try to do full blown applications with an interpreted language.
reply
Perhaps it's worse that some even succeed in building very complex systems that can handle a lot of load too (see eg. Instagram)? ;-)

Python has a known set of trade-offs, mostly related to loop performance. But if you understand the trade-offs and available mitigations, it should not stop you from building good software. You know, just like any other ecosystem.

reply
There’s an #internals-and-peps channel in the Python discord where some folks hang out.
reply
That's basically how Python already compiles source to byte-code.
reply
Julia gets a lot more benefit out of it because it's compiling type-specialized version of the function all the way down to machine code. So for example, a function that's being called with a `Vector{Int64}` ends up dealing with an array of unboxed ints, not going through dynamic dispatch on a generic array for every operation.
reply
I have no doubt Julia's far better with this. I just wanted to point out Python does have a similar precedence for ahead-of-time compilation, albeit with byte-code only. If the Python steering council ever gets its act together, maybe Python could have real AOT and JIT.
reply
[dead]
reply