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

121–130 of 144 posts

Re: Replacing Python

#121

Post by thinkpad20 »

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.

Having recently started doing python full-time, I would say that by far the biggest problem with python is its propensity to explode in your face. Code written in python seems so fragile; except for the most blatant bugs like syntax errors or too few arguments, nothing gets caught. You end up having to write tons of unit tests, which often expose bugs that would be trivially caught with any kind of typing. Performance is great, but code reliability is much more important. With python you get neither - just rapid development (slowed down by having to write a ton of tests) and expressiveness (which is excellent).

Re: Replacing Python

#122

Post by chimeracoder »

steveklabnik wrote: post #64
NateDad wrote: post #52

Earlier quoted context omitted.

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?

I've done a decent amount of work in both - I've written a compiler in OCaml and a few applications in Haskell.

I do find Go to have the "best of both worlds" when it comes to the type system (ignoring all other features of the languages).

As you know, one of the advantages of writing in dynamic languages like Ruby and Python is that you don't have to think much before writing down the first few lines of (working, runnable) code. This makes it really easy to sit down at a keyboard and bang out a prototype, or even a one-off utility script.

With Haskell, I have to spend a lot of time thinking up-front about how to design my types, because the arrangement of the datatypes largely determines the functionality of your program. The upside is that, once you've sketched out what you need your types to look like in Haskell, the entire structure of your application has essentially been stubbed out - you simply need to fill in the gaps. This is really nice when making incredibly polymorphic functions - as has been pointed out, you can implement an entire Haskell library without understanding anything about the logic, operating solely off of the type annotations[0].

The downside is that it takes longer to get those first few lines of (working, runnable) code down. Maybe that's not a big loss, or maybe it is. But Go does provide a lot more type safety than any of C or Java (and certainly a lot more than any dynamic language than Ruby or Python).

I'm a functional programmer at heart, and given my druthers, I'd probably prefer a little more type safety in Go, rather than less. But having written a lot of Go over the last year, I don't find myself commonly running into the sorts of errors that a stronger type system would have prevented.

In short, (IMHO), the biggest additional benefit to strengthening a type system like Go's to resemble Haskell's would be in how it forces you to change the code-formulating process, not in how it prevents more errors. Unfortunately, this is also the biggest drawback to strengthening the type system - it means one can no longer use the same programming workflow that one uses for Python, Ruby, Java, etc.

[0] http://r6.ca/blog/20120708T122219Z.html

Re: Replacing Python

#123

Post by talex5 »

jzwinck wrote: post #60
Erwin wrote: post #49

Earlier quoted context omitted.

Over the last decade, there's probably been half a dozen "standard" command line parsing tools. getopt being the classic, then we had optparse and that got deprecated, then we got argparse. And there there's e.g. twisted.usage and the pretty cool docopt. In this case the author wants to parse "program [optional args]" and does that in a few lines of code. You seriously think that's a "big red flag" ? Do you also beli…

We've had optparse since at least 2003; programs that don't use standard tools to parse their command lines usually have lame bugs such as not responding properly to "--help" (must do nothing but write to stdout and return 0 on *nix). I'm not the one who first mentioned that hand-written option parsing is a red flag. But it is one--especially in Python, which has nice things built in.

The actual 0install Python code does use optparse.

It wasn't stated in the post, but the next step after writing this code was to use it as a front-end to the real Python version. If invoked as "0install run NAME ARGS..." exactly then we handle it (the fast path), otherwise we fall back to the Python version. In particular, that means that the Haskell/OCaml version must NOT try to handle --help, etc. I wrote the comparison Python code to be similar to the other languages.

This OCaml front-end appeared in 0install 2.3. For 0install 2.4 there is a full option parser written in OCaml. I didn't use a library for this because a) it needs to be 100% compatible with the Python parsing and b) it needs to handle tab-completion too.

Re: Replacing Python

#124

Post by abraxasz »

ijl wrote: post #109
abraxasz wrote: post #89

A quick comment concerning Haskell. I've been learning it on and off, with some help from my roommate who's a Haskell genius. The way he writes Haskell always amazes me. He starts with a very straightforward verbose version, then constantly refactors it (on the fly, it's not a separate step), abstracting stuff out in typeclasses and monads until it seems that most of the code is just monads and typeclasses definition…

Interesting. I wonder about maintainability if the writer's "obvious" version is only there to be refactored out. Can you still read the intent when he's done?

I can't, by a long shot: I don't know Haskell deeply enough. But I think he can read his code without problem.

Re: Replacing Python

#125

Post by pron »

nostrademons wrote: post #93
pron wrote: post #38

Earlier quoted context omitted.

Sure, performance is a big requirement for them, but there are other languages with good performance and better expressivity (like Haskell and Scala), yet they are not used at Google, and Google's new languages did not adopt their philosophies.

Google uses Java because they were able to pick up a lot of really skilled Java developers during the 2001-2004 recession, and those devs built many of the products that were introduced in 2004-2007. Once a product's been built and adopted by the marketplace it's very difficult to change the implementation language. Most of the devs who were hired at Google from 1999 - 2002 still prefer C++, and products built in tha…

I'm not sure I get your point. Are you saying that Google's new programming languages adopt the Java philosophy because of developers they hired over ten years ago? Also, I'm not sure I understood what you were trying to say about C++ at Google.

Re: Replacing Python

#126

Post by steveklabnik »

chimeracoder wrote: post #122
steveklabnik wrote: post #64

Earlier quoted context omitted.

> 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?

I've done a decent amount of work in both - I've written a compiler in OCaml and a few applications in Haskell. I do find Go to have the "best of both worlds" when it comes to the type system (ignoring all other features of the languages). As you know, one of the advantages of writing in dynamic languages like Ruby and Python is that you don't have to think much before writing down the first few lines of (working, ru…

Thanks! Another data point...

I personally tend to see it as the worst of both worlds. I have to deal with types _and_ I don't really get strong guarantees. I don't run into problems in Ruby that Go's type checker could help with. But that's also my personality: I like extremes.

Re: Replacing Python

#127

Post by gtaylor »

thinkpad20 wrote: post #121
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.

Having recently started doing python full-time, I would say that by far the biggest problem with python is its propensity to explode in your face. Code written in python seems so fragile; except for the most blatant bugs like syntax errors or too few arguments, nothing gets caught. You end up having to write tons of unit tests, which often expose bugs that would be trivially caught with any kind of typing. Performanc…

Don't let its ease of use fool you, there are a lot of ways to shoot your foot off in Python. Typically, it's kind of like pulling the trigger (make the mistakes), only to see your foot get blown off a few months/years down the road. I find that your luck with larger Python projects is largely determined by two things:

* Experience with Python, and general experience in duck typed environments.

* Discipline. Not just your own, but anyone else working on your project.

There are certain mistakes that will make your life miserable down the road. These could be bad organizational conventions, inconsistent exception raising/handling policies, lacking a strategy for documentation, etc. If you make mistakes like this, you probably won't get bitten by it until later.

Writing good Python can be harder than writing good . With experience and time, this gets a lot easier.

Re: Replacing Python

#128

Post by DennisP »

jzwinck wrote: post #24
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.)

"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 .N…

Although F# isn't OCaml it is fairly similar, and compatible if you skip certain features of each: http://stackoverflow.com/questions/179492/f-changes-to-ocaml

Re: Replacing Python

#129

Post by sanderjd »

NateDad wrote: post #51
tikhonj wrote: post #44

Earlier quoted context omitted.

In other words, Go is yet another "lowest common denominator"language,a spiritual successor to Java. If you're not working with the lowest common denominator, Go is not for you.

That is a huge mischaracterization and borderline flamebait.

Not even borderline! "Flamebait" was practically invented for that exact type of comment.

Re: Replacing Python

#130

Post by CountSessine »

cmccabe wrote: post #88
alextingle wrote: post #57

Earlier quoted context omitted.

With GCC, at least, you can guarantee that it's thread-safe. (Of course, in some pathological cases you can get then get deadlocks during global static initialisation. C++ is such a lovely language!) Also, I don't think Google's style guide is the be-all-and-end-all of good C++ style. Virtually non of Boost's code would comply with it. "We do not use C++ exceptions" indeed!

You're starting from a false premise, which is that Boost is good. In reality, Boost is stuff that either couldn't make the cut to get into the C++ standard library, or is so new that nobody knows whether it's any good or not.

Boost is stuff that everyone wants to use but can't because they're forced to use an old or broken compiler that isn't capable of building real C++0x/C++2011 code. It's a staging ground. How else are you going to use std::bind or std::thread et. al. with visual c++ 2005?

Also, there are plenty of nice modules in boost that just don't belong in the standard library. ASIO is quite nice, but it has io_service implementations that are platform dependent. Statechart is pretty good, but it isn't the only state machine implementation in Boost and neither is clearly better than the other. Spirit has it's uses, but does it belong in the standard library?

Post reply on HN