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

71–80 of 144 posts

Re: Replacing Python

#71

Post by dragandj »

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.

So, effectively, Python is not enough - you and your team have to be experts in C/C++ too?

Re: Replacing Python

#72

Post by burntsushi »

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…

I was under the impression that using a class (with `__slots__` set) or a tuple is generally more performant than using dictionaries. At least, I assume that's why he didn't mention dictionaries.

Re: Replacing Python

#73

Post by mjhoy »

mynameisme wrote: post #68
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.

> newest, coolest language

I'm sure you meant "newest and/or coolest", or "recently become coolest", but it's worth noting that Haskell is about as old as Python, and OCaml is not much younger.

Re: Replacing Python

#74

Post by njharman »

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.)

> since when are we willing to settle for good enough?

Ever since we decided to get shit done, ship, finish our weekend project, etc. Ever since we first read "premature optimization is the root of all evil" and understood it as wide, abstract truism.

Re: Replacing Python

#75

Post by burntsushi »

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/…

> But, more generally, Go has very little to commend itself and--compared to the other options--quite a few shortcomings.

By what standard of measure? I personally appreciate the simplicity that Go brings to the table, usually at the cost of features we've come to expect in other programming language environments. Do I miss those features? Sure. But do I like simplicity and straight-forwardness? Definitely. Do I believe there is a way to combine them? I'm not sure. Rust is probably the closest contender. But certainly, languages like Haskell or Java don't do it for me (as frequently as Go does, anyway).

What I'm trying to say is that I won't tell you which side of the trade-off you should take in every instance, and maybe you shouldn't either.

Re: Replacing Python

#76

Post by spongle »

steveklabnik wrote: post #65
spongle wrote: post #48

Earlier quoted context omitted.

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.

Do you really notice that though?

Re: Replacing Python

#77

Post by njharman »

tikhonj wrote: post #7
hartror wrote: post #2

> A major benefit of OCaml and Haskell is the ease of refactoring. In Python, once the code is working it’s best not to change things, in case you break something that isn’t covered by the unit-tests. In OCaml and Haskell, you can rename a function, delete old code or change a data structure and rely on the compiler to check that everything’s still OK. These sort of statement always bothers me when I encounter it. If…

He never said anything about not writing unit tests. Rather, his claim is that--even with unit tests--refactoring is not safe in Python et al; in Haskell and OCaml, by contrast, many of the same actions are guaranteed safe by the type system. Static types do not mean you don't have to write unit tests. But they do mean you can write fewer . (And, looking at libraries like QuickCheck, a static type system can make wri…

> his claim is that--even with unit tests--refactoring is not safe in Python et al;

Well that claim is False. I and thousands of other Python developers disprove it daily. Just because they can't refactor dynamic languages doesn't me we can't. Something not-dynamic is probably the language for them. And Python is the language for us.

In other words there is far more variability between developers than there is between languages. Find the language(s) that work for you and quit believing they are the languages for everyone.

Re: Replacing Python

#78

Post by zanny »

dragandj wrote: post #71
zanny wrote: post #46

Earlier quoted context omitted.

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.

So, effectively, Python is not enough - you and your team have to be experts in C/C++ too?

If your team can't write a few hundred lines of critical section code in another language, or at least pick it up in a week - especially when the syntaxes are very similar (this isn't going from closure to java here) - you have bigger issues with your team than their language choice.

Re: Replacing Python

#79

Post by rossjudson »

rhizome31 wrote: post #56
RivieraKid wrote: post #50

Earlier quoted context omitted.

Why, because the JVM is too big?

Because it's too big, it's very slow to start, it's controlled by a company that is not very lovely, it's not installed by default on our system, it's free and opensource without in fact being very libre, it has frequent security flaws that don't seem to be addressed seriously... Some of this is probably only partially true, but it gives you an idea why people don't want to use it, whether they're right or wrong.

So it's a good thing you're propagating partial truths then, right?

The JVM isn't easy to beat for software that's more complicated than "Hello World". Sure you can beat it, but you're going to have to work very, very hard.

The security flaws exist in the area few people care about (and shouldn't even really be installed any more) -- the sandboxing and web start code.

Did you include gcc and friends in your "too big" calculations? Hard to program without them.

Re: Replacing Python

#80

Post by [deleted] »

opminion wrote: post #12
hartror wrote: post #2

> A major benefit of OCaml and Haskell is the ease of refactoring. In Python, once the code is working it’s best not to change things, in case you break something that isn’t covered by the unit-tests. In OCaml and Haskell, you can rename a function, delete old code or change a data structure and rely on the compiler to check that everything’s still OK. These sort of statement always bothers me when I encounter it. If…

If you're not testing the code you are refactoring how do you know it still works or even worked in the first place? There are other ways, different than testing, to convince yourself and others that a program does what it is meant to do. They complement testing. You use them already while constructing the deterministic parts of your program: much of what the machine does for you is predictable, and good languages an…

[deleted]
Post reply on HN