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

Replacing Python

roscidus.com

Post reply on HN
Print view View original

21–30 of 144 posts

Re: Replacing Python

#21

Post by wikiburner »

gmantastic wrote: post #18
wikiburner wrote: post #15

Earlier quoted context omitted.

Isn't Cython a solution that frequently requires significant code changes (refactoring to C-like code) beyond adding typing?

It's selectively adding C-like type declarations to Python code speed up the slow bits. C code is then generated and compiled into a Python extension module. This is similar to adding type information to Common Lisp code to allow the compiler to optimise it. http://docs.cython.org/src/quickstart/cythonize.html

My impression was that you sometimes have to refactor your Python to make the code more C-like. From what I have heard generators aren't supported, and there are other situations where you need to make your loops (and other elements of your code) more C-like.

That's not the case?

You just add typing to your python and you're good to go?

Re: Replacing Python

#22

Post by pron »

tikhonj wrote: post #10

I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out by now. In particular, I think it's good advice to avoid both ATS (however much I like dependent types) and Go, both for completely different reasons. You probably wouldn't want to use Rust in the short term either. [1]: http://roscidus.com/blog/blog/2013/09/…

I think you may be overestimating the importance of the programming language over the whole programming environment. I think it is the programming environment that is the most important tool – not just the language. There are often many requirements that might lead you to choose a possibly inferior language because it lives in an altogether superior environment for your needs.

I have been writing large, server side software for many years. These are long-running applications that require superb performance as well as first-class monitoring tools. So, for me, one requirement for a language is that it runs on the JVM. The JVM gives you superb performance as well as unparalleled monitoring tools (made even better by the inclusion of the flight-recorder and Java Mission Control in the latest version of the JVM); you also get a vast ecosystem with a huge selection of very high quality libraries (and some other important features like dynamic linking) – all that before you even choose a particular language. You can also buy commercial support for every single component you're using if you need it.

On the other hand, if you're writing a command-line tool that needs a very fast startup time, or if your RAM is very constrained, then the JVM might be a bad choice for you, which would rule out the JVM languages no matter how good they are.

My point is that there are more important issues to consider than the mere merits of the language itself.

Also, you're putting a lot of emphasis on expressivity, while downplaying the importance of a short learning curve. I think the two are of similar importance. It's been my experience that programs written in some of the more expressive languages are actually harder to maintain than code written in the easy-to-learn ones. The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. The easier-to-learn languages usually work at a lower level of abstraction, which can sometimes be easier for others to follow because its a well-understood common denominator.

Now, I'm not saying that worse is better, or that more "primitive" languages are better, or even that one should pick them over more expressive ones. I'm just saying that, especially when working in a large team or writing code that would need to be maintained for a long time, there are other issues to consider.

Re: Replacing Python

#23

Post by ssadler »

I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a serious contender in brevity too.

Re: Replacing Python

#24

Post by jzwinck »

tikhonj wrote: post #8
jzwinck wrote: post #6

Perhaps the title should be "Why Python is good enough." Between this post and the preceding one ( http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... ), the takeaway for me is that the author didn't find sufficient benefit in any of the candidate languages to justify switching an existing product--perhaps not even a new product. It's true that Python can leave you with hidden crash bugs in unusual code p…

Except in the end, the author switches to OCaml[1]. So Python might be good enough , but he certainly found OCaml better . And since when are we willing to settle for good enough ? [1]: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/ (In fact, the author writes that he's basically willing to move to OCaml in the conclusion of this post.)

"Good enough" the way I'm using it is nothing to be ashamed of. It is very difficult to find computing systems that are "good enough."

Here are some of the motivating factors identified by the author at the outset of the search for a better language:

- Canonical’s Colin Watson is worried about Python’s performance on mobile phones.

- Marco Jez and Dave Abrahams proposed a C++ version.

- Bastian Eicher would like a .NET version (though IronPython might work here).

It doesn't seem like OCaml effectively addresses the above very well. On the other hand, here are some items the author liked about Python which may now be lost:

- Widely known and easy to learn.

- A large standard library.

- You only need to ship source code (interpreted).

- Can run inside a Java or .NET VM (using Jython/IronPython).

- All current 0install contributors know it.

- The current code is all Python and is well-tested.

Of course the last item is the most alarming: see http://www.joelonsoftware.com/articles/fog0000000069.html (2000), Brooks' Mythical Man Month (1975) for the Second System Effect, etc.

Re: Replacing Python

#25

Post by gmantastic »

wikiburner wrote: post #21
gmantastic wrote: post #18

Earlier quoted context omitted.

It's selectively adding C-like type declarations to Python code speed up the slow bits. C code is then generated and compiled into a Python extension module. This is similar to adding type information to Common Lisp code to allow the compiler to optimise it. http://docs.cython.org/src/quickstart/cythonize.html

My impression was that you sometimes have to refactor your Python to make the code more C-like. From what I have heard generators aren't supported, and there are other situations where you need to make your loops (and other elements of your code) more C-like. That's not the case? You just add typing to your python and you're good to go?

There's some info on semantic differences here: http://docs.cython.org/src/userguide/limitations.html - it doesn't bring up much, and the design goal is full language compatibility. I've only played with it so far, but it's case of optionally adding type info, and also writing some distutils scaffolding to say how to build the module as a cython extension. This is then callable from Python via the regular import mechanism.

Re: Replacing Python

#26

Post by Herbert2 »

tikhonj wrote: post #8
jzwinck wrote: post #6

Perhaps the title should be "Why Python is good enough." Between this post and the preceding one ( http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... ), the takeaway for me is that the author didn't find sufficient benefit in any of the candidate languages to justify switching an existing product--perhaps not even a new product. It's true that Python can leave you with hidden crash bugs in unusual code p…

Except in the end, the author switches to OCaml[1]. So Python might be good enough , but he certainly found OCaml better . And since when are we willing to settle for good enough ? [1]: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/ (In fact, the author writes that he's basically willing to move to OCaml in the conclusion of this post.)

I seriously doubt OCaml's benefits over Python are so great that they overweigh not being able to hire someone proficient in it.

Re: Replacing Python

#27

Post by wikiburner »

gmantastic wrote: post #25
wikiburner wrote: post #21

Earlier quoted context omitted.

My impression was that you sometimes have to refactor your Python to make the code more C-like. From what I have heard generators aren't supported, and there are other situations where you need to make your loops (and other elements of your code) more C-like. That's not the case? You just add typing to your python and you're good to go?

There's some info on semantic differences here: http://docs.cython.org/src/userguide/limitations.html - it doesn't bring up much, and the design goal is full language compatibility. I've only played with it so far, but it's case of optionally adding type info, and also writing some distutils scaffolding to say how to build the module as a cython extension. This is then callable from Python via the regular import mech…

Thanks for the link. I was just poking around the Cython site myself, and it looks like they've come a long way since I last looked into it. It seems that they're getting much closer to full compatibility.

It makes me wonder if we're closing in on the day when Cython gets rolled into Python proper, and you can just "import static-types" to activate optional typing, then add some static typing to your code, and you would get Java performance from your Python code.

Re: Replacing Python

#28

Post by mercurial »

ssadler wrote: post #23

I find it suspicious that Java or Scala didn't make the list. Java may not be sexy but it checks many boxes... And I suspect that Scala would have been a serious contender in brevity too.

C# was excluded for being too slow to start. JVM-based languages would not fare any better.

Re: Replacing Python

#29

Post by tikhonj »

Herbert2 wrote: post #26
tikhonj wrote: post #8

Earlier quoted context omitted.

Except in the end, the author switches to OCaml[1]. So Python might be good enough , but he certainly found OCaml better . And since when are we willing to settle for good enough ? [1]: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/ (In fact, the author writes that he's basically willing to move to OCaml in the conclusion of this post.)

I seriously doubt OCaml's benefits over Python are so great that they overweigh not being able to hire someone proficient in it.

In practice, people have found that hiring good programmers is actually easier with certain more obscure languages. Paul Graham, amusingly enough, called this the "Python paradox" because, back in 2004, Python was one of the obscure choices! Oh how things change.

This certainly holds for OCaml as well. The main OCaml company I'm familiar with is Jane Street, and they certainly have no issues finding OCaml programmers. More importantly, many of their programmers come in with no OCaml experience or even no functional programming experience, and yet they have no trouble getting up to speed. In fact, these days they even teach their traders--often complete non-programmers--OCaml. And it works. I don't think I'd ever want to hire somebody incapable of learning a language like OCaml in a reasonable time frame.

So yeah, this is not an issue in the least. If anything, it seems to work out more favorably for the companies using OCaml, Haskel and the like!

Re: Replacing Python

#30

Post by Dewie »

tikhonj wrote: post #10

I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out by now. In particular, I think it's good advice to avoid both ATS (however much I like dependent types) and Go, both for completely different reasons. You probably wouldn't want to use Rust in the short term either. [1]: http://roscidus.com/blog/blog/2013/09/…

Can you think of some niches/circumstances where ATS might be worth using?

EDIT: might it be possible to develop ATS programs that are easily called from other languages? ATS seems to have strong ties to C, so maybe one could call ATS code like one calls C code, or call C code that is a thin wrapper around the ATS code? Then you hopefully could have efficient, statically verified (to a high degree) code that can be use by other languages.

Post reply on HN