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

61–70 of 144 posts

Re: Replacing Python

#61

Post by Herbert2 »

tikhonj wrote: post #29
Herbert2 wrote: post #26

Earlier quoted context omitted.

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…

I'm pretty sure that at Jane Street you get to solve engaging problems and get paid 250K+. OCaml or not, they're not going to have problems with hiring.

Re: Replacing Python

#62

Post by mercurial »

alextingle wrote: post #58
mercurial wrote: post #53

Earlier quoted context omitted.

Sounds more like trolling than participating to a rational discussion

Java aficionados don't seem to realise just how obnoxious many of us find the JVM. If you live with it, and do your work with it, I guess you come to accept it as a fact of life - always there in the background. If literally nothing that you do uses it, then it's a massive extra dependency to add to a simple desktop app - a dependency that is often quite difficult to manage and keep updated.

Re dependency: you probably have a point on Windows, but it's your choice to use an OS without a package manager to keep things up to date. I don't know about Mac but on Linux it is a non issue.

That said it does not do well for desktop apps due to slow startup, high memory use and lack of native toolkit. It does much better as a server side runtime.

Re: Replacing Python

#63

Post by virtualwhys »

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.

Agreed, pretty large omission given that C# was included.

Not such a big fan of Java, but Scala seems to be a strong contender for Java.Next* , and is certainly a viable dynamic-to-static transition language given its terse syntax, deliciously rich collections library, and implicits support (for the MOP fans).

* Twitter being able to withstand spikes of 140K+ tweets per second without lagtime is impressive to say the least.

Re: Replacing Python

#64

Post by steveklabnik »

NateDad wrote: post #52
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/…

You didn't really say why you think Go is a bad choice. I think there are a lot of things Go has going for it, including clarity, productivity, native cross platform support, and a best of both worlds static typing system with implicit interfaces.

> best of both worlds

I'm just curious, how much time have you spent with a really strongly statically typed language like Haskell or OCaML?

Re: Replacing Python

#65

Post by steveklabnik »

spongle wrote: post #48
mercurial wrote: post #28

Earlier quoted context omitted.

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

I can't say I've had that problem myself. They are quite startup heavy but typical c# console apps start up on an ssd based system in ~150ms and 700ms on rust disks. If you're calling something thousands of times, fast process startup times are good. This isn't the model windows uses though which is the primary target of c#.

In the tests, his OCaML implementation takes 7ms, and his Python one takes 64 or 109 ms. So even on your SSD, that's 50% to an order of magnitude too slow, just for startup.

Re: Replacing Python

#66

Post by mynameisme »

alextingle wrote: post #55
RivieraKid wrote: post #50

Earlier quoted context omitted.

Why, because the JVM is too big?

It's a crazy moving target that never seems to work right. Even if it does work right, pretty soon some update breaks it. And then there's the fact that most (desktop) Java applications look like arse and run like a dog.

The JVM is a crazy moving target? Can you give an example of that please?

Re: Replacing Python

#67

Post by Demiurge »

zanny wrote: post #46
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…

The other thing is his only complaint (slowness) isn't really a problem. If you have a critical hot spot in your server code, extract it, implement it in C / C++, and use ctypes to call it.

CFFI is the latest trendy way to call C, compatible with PyPy ;)

Re: Replacing Python

#68

Post by mynameisme »

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.

Yeah, it's a joke that Rust (which I think will be a great language, but all of the syntax hasn't even been decided yet) is being considered, when Java and friends are not.

Really, this article is about "I want to rewrite my program in the newest, coolest language", not about which is the best tool for the job. And that's fine, but the author should present it that way.

Re: Replacing Python

#69

Post by mattdeboard »

tghw wrote: post #9

The first Python example throws up a big red flag: manually parsing command line arguments instead of using argparse. Why reinvent the wheel when there is a standard library to handle it? Likewise, asserting that "For storing general records, Python provides a choice of classes and tuples" completely ignores one of Python's fastest and most powerful data types: dictionaries. Lastly, in get_value, the nest of ifs is u…

There are many examples of archaic/non-idiomatic/gross Python. Old-style classes, unnecessary cyclomatic complexity, and so forth. Using Python effectively (i.e. expertly) means wantonly abusing hash tables, generators and its functional paradigms.
Post reply on HN