Live data from Hacker News

Codon: A high-performance Python-like compiler using LLVM

github.com

171–180 of 184 posts

Re: Codon: A high-performance Python-like compiler using LLVM

#171

Thanks a lot for all the comments and feedback! Wanted to add a couple points/clarifications: - Codon is a completely standalone (from CPython) compiler that was started with the goal of statically compiling as much Python code as possible, particularly for scientific computing use cases. We're working on closing the gap further both in what we can statically compile, and by automatically falling back to CPython in c…

I'm very interested to try Codon, though I note there are no Windows binaries. Do you think building from source on Windows would be straightforward?

Re: Codon: A high-performance Python-like compiler using LLVM

#173

Earlier quoted context omitted.

I just did a quick check (apparently DuckDuckGo has a built in JSON validation function lol love it) and `[1, "foo"]` does pass their JSON validation. Not surprised but I did want to confirm.

Am I missing something, why wouldn't a non-homogeneous array literal pass?

Because mixing types in an array is stupid enough that I thought it might just not be valid.

Re: Codon: A high-performance Python-like compiler using LLVM

#174
post #28

Ugly, confusing naming choices: ``@par`` instead of ``@parallel``.

How do you feel about `def` instead of `define` ?

Abbreviations are good to the extent that they're commonly used. It's a bit of a chicken-and-egg problem. At the time Guido picked `def`, I might have argued with him. Now, it's the standard.

If I were writing my own language, I might choose `let` instead of `def`. For example, `let x = 1`.

Re: Codon: A high-performance Python-like compiler using LLVM

#175

Thanks a lot for all the comments and feedback! Wanted to add a couple points/clarifications: - Codon is a completely standalone (from CPython) compiler that was started with the goal of statically compiling as much Python code as possible, particularly for scientific computing use cases. We're working on closing the gap further both in what we can statically compile, and by automatically falling back to CPython in c…

I can see myself using Codon for projects in the future. One thing that concerns me, though, is "automatically falling back to CPython in cases we can't handle". Sometimes, I want the compilation to fail rather than fall back, because sometimes consistent high speed is a requirement. Please keep that in mind as you design that part.

Great work so far!

Re: Codon: A high-performance Python-like compiler using LLVM

#176

Earlier quoted context omitted.

In 25 years you’ve never once created a list with more than one type of object in it?

I have also been using python a long time and i honestly can’t remember a time i used mixed type list.

Never have to handle/forward function calls with arbitrary arguments? What do you think *args is?

Re: Codon: A high-performance Python-like compiler using LLVM

#177

Earlier quoted context omitted.

Am I missing something, why wouldn't a non-homogeneous array literal pass?

Because mixing types in an array is stupid enough that I thought it might just not be valid.

Mixing types in an array/list is not remotely stupid. How exactly would you suggest expressing the lack of a value in a series of numbers without None/null? There's your mixed types.

Don't let weird dogma get in the way of practicality.

Re: Codon: A high-performance Python-like compiler using LLVM

#178
post #176

Earlier quoted context omitted.

I have also been using python a long time and i honestly can’t remember a time i used mixed type list.

Never have to handle/forward function calls with arbitrary arguments? What do you think *args is?

a tuple

Re: Codon: A high-performance Python-like compiler using LLVM

#179
>"Typical speedups over Python are on the order of 10-100x or more, on a single thread. Codon's performance is typically on par with (and sometimes better than) that of C/C++"

Nice! A super-fast compiler LLVM compiler for Python! Well done!

You know, if Python is one of the world's most popular languages, and it was originally implemented as a dynamic and interpreted language (but fast compilers can be written for it, as evinced by Codon!) -- then maybe it would make sense to take languages that were implemented as compilers -- and re-implement them as dynamic interpreted languages!

Oh sure -- that would slow them down by 10x to 100x!

But, even though that would be the case -- the dynamic interpreted versions of the previous compiled-only language -- might be a whole lot more beginner friendly!

In other words, typically in dynamic interpreted languages -- a beginner can use a REPL loop or other device -- to make realtime changes to a program as it is running -- something that is usually impossible with a compiled language...

The possibilities for easy logging, debugging, and introspection of a program -- are typically greater/easier -- in interpreted dynamic languages...

Oh sure, someone can do all of those things in compiled languages too -- but typically the additional set-up to accomplish them is more involved and nuanced -- beginners typically can't do those things easily!

So, I think when I think about programming languages from this point forward -- I'm going to think about them as having "two halves":

One half which is a compiled version.

And another half -- which is a dynamic interpreted version...

Usually when a new programming language is created in world, it is created either as a compiled language or as a dynamic interpreted language -- but never both at the same time!

Usually it takes the work of a third party to port a given language from one domain to the other, usually from dynamic interpreted to compiled, but sometimes (as is sometimes the case with scripting languages derived from compiled languages), sometimes in the reverse!

Point is: There are benefits to be derived from each paradigm, both dynamic interpreted and compiled!

So why do we currently look at/think about -- most computer languages -- as either one or the other?

I'm going to be looking at all computer languages as potentially both, from this point forward...

(Related: "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022): https://www.youtube.com/watch?v=8Ab3ArE8W3s&t=1383s)

Re: Codon: A high-performance Python-like compiler using LLVM

#180
post #177

Earlier quoted context omitted.

Because mixing types in an array is stupid enough that I thought it might just not be valid.

Mixing types in an array/list is not remotely stupid. How exactly would you suggest expressing the lack of a value in a series of numbers without None/null? There's your mixed types. Don't let weird dogma get in the way of practicality.

JSON has a `null` value already, and null is its own special case in most languages where `null` is a universal type.

Otherwise you tag your data so that it's an array of objects.

Post reply on HN