Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPy: An interpreter and compiler for a fast statically typed variant of Python

antocuni.eu

Post reply on HN
Print view View original

101–110 of 133 posts

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#101

Post by ltbarcly3 »

Smaug123 wrote: post #89
ltbarcly3 wrote: post #73

Statically typed. That's just Java with python syntax again, which the article tries to talk it's way out of but that's what it is.

This assertion is so vague as to be meaningless - say more? You're presumably not asserting that all statically typed languages are fundamentally Java, because that would be saying the patently false "C and Haskell are fundamentally Java". Are you specifically saying the article's hope that it's not "Java with Python syntax" is misplaced; if so, why?

Python, if you take away dynamic typing, is very Java like. No pointers, functions/methods always pass by reference, immutable strings, always garbage collected, etc. So if all you did was require static typing in Python, but changed nothing else, it will end up with a lot of java semantics (even if the syntax itself is different).

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#102

Post by antocuni »

intalentive wrote: post #97

As a prospective user the first thing I look for is lists, list comprehension, list slices, string methods, zip, zip*, tuple destructuring, generators, dicts and sets. These data structures, their syntax, and associated methods are what make Python a joy to use. They are what make it possible to solve a puzzle in a one-liner. The examples in the playground are neat but I don’t see any of the Python bread and butter u…

yes (work in progress :))

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#103

Post by kombine »

albertzeyer wrote: post #11
mpweiher wrote: post #7

Looks very interesting! I remember chatting with one of the creators of PyPy (not the author of TFA) a number of years ago at HPI. He had just given a talk about how RPython was used in PyPy development, and I was fascinated. To me, it seemed completely obvious that RPython itself seemed like a really interesting standalone language, but he would have none of it. Whenever I suggested that RPython might have advantage…

I have asked about using RPython as a generic standalone language before. I think the official statement is that is was never intended to become one, and it's really a very minimal subset of Python (so basically no existing Python code will run, it would require heavy refactoring or complete rewrite), and it's only specifically those features that they currently need, and it might also be a moving target, and they do…

A general purpose language should be suitable to writing its own compiler. If it's to slow for that, what's the point?

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#104

Post by oofbey »

ic_fly2 wrote: post #75

If in the end we can just have .spy on some files that have performance critical functions in them and the rest is just normal python, this could be down right amazing. We recently swapped out mypyc optimised module for a rust implementation to get a 2-6x speed up, and not having to do that would be great.

+1 this.

Also, when I read about the language features which make Python intrinsically slow, generally I think "I never use that." e.g. operator overloading meaning you need to do all these pointer dereferences just to add two numbers together. Yes, I get that pytorch and numpy rely critically on these. But it makes me wonder...

Could you disable these language features on a module-by-module basis? That is, declare "in this sub-tree of the source code, there shalt be no monkey-patching, and no operator overloading" and therefore the compiler can do a better job. If anybody tries to do the disallowed stuff, then it's a RuntimeError. Would that work?

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#105

Post by vidarh »

pjmlp wrote: post #88
vidarh wrote: post #61

Earlier quoted context omitted.

> Granted what messes up Python, or better said CPython implemenation, is that C extensions are allowed to mess up with its internals thus making void many possible optimizations that would be otherwise available. I'm doing a Ruby compiler (very, very slowly, though faster again now with Claude Code doing most of the heavy lifting), and the same issue with Ruby has made me seriously toy with the idea of one day embed…

Have you seen how TruffleRuby makes use of LLVM bitcode, to ship C compiler as well?

I haven't, but not surprised given some of the very aggressive (in a good way) things they've done to address performance. It's impressive. I spoke to Chris Seaton back when it was getting started, and loved many of the things they were doing. Personally I want something leaner, and self-hosting, but that's also why mine is still experimental and wildly incomplete and TruffleRuby works for a lot of things.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#106

Post by stonemetal12 »

thomasmg wrote: post #92
PaulHoule wrote: post #70

Earlier quoted context omitted.

One of the standard architectures for complex applications is to put together a scripting language and an systems programming language. You can either look at the scripting language as primary with the systems language used for performance or hardware interfacing or you can look at the systems language being primary and the scripting being used around the edges. The model of having a closely related scripting and sys…

Yes, there are quite many real-world cases of this architecure. But, wouldn't it be better it the same language (more or less) can be used for both? I don't think such a language exists currently, but I think it would be a nice goal.

What would be the point of the second language if it was basically the same language as the first?

In general you want a solid engineering language with a focus on correctness, and a second "scripting" language focusing on quick development.

Second if the languages are very similar but not the same it seems like you would see "confusion" errors where people accidently use lang 1 in lang 2's context or vice versa.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#107

Post by emmelaich »

falcor84 wrote: post #6

This seems to be going for a somewhat similar goal to Mojo [0] - anyone here who used both and is willing to offer a comparison? [0] https://www.modular.com/mojo

There are even older languages with similar goals. At least three are called viper and are older than 6 years. Two linked below and much older one with ocaml-ish features that I could not find a link for.

https://github.com/pdarragh/Viper

https://github.com/appcypher/viper

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#108

Post by seg_lol »

It is has been a hot minute and no one has mentioned ChocoPy, which is basically this project. https://chocopy.org/

The author invents so many terms, I don't want to uncharitably ascribe this to anything, but they should use existing terminology.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#109

Post by almostgotcaught »

rangerelf wrote: post #80
almostgotcaught wrote: post #76

Earlier quoted context omitted.

all of this is well and good if you completely forget that there are billions of lines of Python in prod right now. so your grand epiphany is basically on the level of "let's rewrite it in Rust". i'll let you hold your breath until that rewrite is done (and in the meantime i'll explore workarounds).

I kind of object to this take. Nobody's talking about porting billions of lines of code, for all we know it's just for personal projects, or a learning experience. This kind of replies is like killing an idea before it's even started, smells like the sunk cost fallacy. OTOH I do understand the weight of a currently existing corpus in production, evidence is the ton of COBOL code still running. But still, your reply k…

> Nobody's talking about porting billions of lines of code, for all we know it's just for personal projects, or a learning experience.

am i the only person in the room that can read tone? please tell me what is the force of this statement in what i've responded:

> If you want static compilation, use a language and libraries built with that assumption as a ground rule.

is this an imperative only for hobbyists? not sure.

> This kind of replies is like killing an idea before it's even started, smells like the sunk cost fallacy.

there is no idea - that's exactly my whole point. tear it down and build it again is not an idea.

Post reply on HN