4 ms·
The preferred workflow that you've described seems to be a (more considered) form of the standard Cython workflow that I see described: (1) Write Python. (2) C
by jboy 11y ago
The preferred workflow that you've described seems to be a (more considered) form of the standard Cython workflow that I see described:
(1) Write Python.
(2) Compile with Cython.
(3) Run compiled Cython, profile & review.
(4) Consider what Cython annotations to make to code; make code changes.
(5) Goto 2.
The emphasis is always on iteration & incremental additions.
Of course I practice iterative & incremental development, and of course I'll prototype a quick proof-of-concept implementation first (often in Python+Numpy) before profiling & algorithmic optimization. But the Cython workflow seems to me to add more iteration (of incremental Cython syntax additions) than is really necessary. When I'm working to implement some algorithm, I don't really want to iteratively learn how Cython or CPython implement various Python functions; I'd rather write my "proper version" code just once, properly the first time.
So why not take it to the logical extreme and write it all in Cython-lang from the start? If we're writing for-keeps code in a language with Pythonic syntax & static types, I find Nim-lang a more expressive, more full-featured language (with features such as generics & type-safe Lisp-like macros, in particular; I note that Cython does support pointers & operator overloading) than Cython-lang in general-purpose uses, without being very different at all in simple uses.
For example, there is an example `primes` function in the Cython tutorial: http://docs.cython.org/src/tutorial/cython_tutorial.html#primes http://docs.cython.org/src/tutorial/cython_tutorial.html#pri...
Here is an equivalent implementation in Nim. As you can see, it's really almost identical in syntax:
proc primes(kmax: int): seq[int] =
var kmax = kmax
var n, k, i: int
var p: array[1000, int]
result = @[]
if kmax > 1000:
kmax = 1000
k = 0
n = 2
while k < kmax:
i = 0
while i < k and n mod p[i] != 0:
i = i + 1
if i == k:
p[k] = n
k = k + 1
result.add(n)
n = n + 1
return result
All of this said, I understand that a great deal of this decision comes down to personal preference: Would you rather start with Python & then iteratively diverge? Would you rather start & stay in Nim? And I can also see the benefit of both approaches in different circumstances. :)
- Nrpf 11y agoOr you can use numba and with pure python syntax and get really fast.
- porker 11y ago> The emphasis is always on iteration & incremental additions. > All of this said, I understand that a great deal of this decision comes down to personal preference: Would you rather start with Python & then iteratively diverge? When doing scientific research, I'd prefer to start with Python and then iteratively diverge. The aim is to get my task done as quickly as possible (so I can go write those 15 journal articles due last Monday) and go just as far as is needed. It's the scientist/engineer vs programmer mindset difference. However, if the code was done and I knew I'd need to use it again, I like the idea of rewriting it from scratch in Nim - not that I or any scientific colleagues know Nim (only one has heard of it). Anyway, I look forward to keeping an eye on your work and maybe using it in the future :)
- andreasvc 11y agoIf you're writing in Cython (not Python) from scratch you don't need to work any more iteratively than in any other language. You can start out with low level memory management with malloc and declare everything with C types. Granted, generics and macros are a nice advantage of Nim. What I think is the essential difference here is that Nim is higher level than Cython. So it seems to boil down to a matter of preference. However, when Python is not fast enough, Cython lets you go all the way to generating C code without garbage collection, inline assembly etc. With Nim there's yet another layer between Python and C.