Live data from Hacker News

Replacing Python

roscidus.com

31–40 of 144 posts

Re: Replacing Python

#31
post #22
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…

Agreed. For example, if your environment is Google App Engine, your choices are more limited, and Go suddenly becomes a very attractive performance option.

Re: Replacing Python

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

> So it seems extremely shortsighted to choose a language because it's easy to learn and similar to what you already know!

But the benefits are that many new people will be able to pick it up quickly and easily. Other people's code will be easy to understand and maintain. So it's good for everyone in the long run. Being able to express complicated ideas in simple ways is very valuable.

If you think it's an advantage that it'd take someone else years of learning a language before they can understand the code you wrote, Go is not for you. [1]

[1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...

Re: Replacing Python

#33
post #22
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…

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

I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less abstraction, even if it leads to more verbose code. That's the whole secret of Java. I've been implementing a small part of my current project in Go and it has similar benefits.

That said, when working alone or with one or two others, I feel kind of dumb repeating some things over and over at the same level of abstraction. There are lots of things like this little piece of C++ code that I tried to translate into reasonably efficient Go:

  template
  R defaulted(const V& val, const R& default_val) {
    return val == V() ? default_val : val;
  }
I came away scratching my head a little, probably because I'm a Go newbie.

Re: Replacing Python

#35

Earlier quoted context omitted.

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

"and you would get Java performance from your Python code."

Nah, I doubt it would ever use _that_ much memory.

Re: Replacing Python

#36
post #22

Earlier quoted context omitted.

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…

>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. I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less ab…

As an aside, Go is also "a Java" in the same sense that Clojure is a lisp (similar syntax and concepts, same level of abstraction, same philosophy). In fact, Google seems to be turning out many of these "Javas" lately (Android, Go, Dart).

While Java and its variants' appeal at most large organizations is considered by some a sign of their conservatism, Google is anything but when it comes to picking the best tools. Google's fondness of Java is evidence of the merits of the Java philosophy when it comes to maintaining large codebases by large teams.

Creating a language that follows this philosophy while still boosting productivity (and maybe providing other benefits as well) is an interesting challenge. I think Go falls short. Kotlin looks interesting.

Re: Replacing Python

#37
post #36

Earlier quoted context omitted.

>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. I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less ab…

As an aside, Go is also "a Java" in the same sense that Clojure is a lisp (similar syntax and concepts, same level of abstraction, same philosophy). In fact, Google seems to be turning out many of these "Javas" lately (Android, Go, Dart). While Java and its variants' appeal at most large organizations is considered by some a sign of their conservatism, Google is anything but when it comes to picking the best tools. G…

I always thought the Java love at Google came from needing speed more than a startup -- they automatically will get factors of ten more users directly for most everything they do. (Edit: Point is, "Java-like" is Google's optimum for other reasons than being conservative.)

Re: Replacing Python

#38
post #37
post #36

Earlier quoted context omitted.

As an aside, Go is also "a Java" in the same sense that Clojure is a lisp (similar syntax and concepts, same level of abstraction, same philosophy). In fact, Google seems to be turning out many of these "Javas" lately (Android, Go, Dart). While Java and its variants' appeal at most large organizations is considered by some a sign of their conservatism, Google is anything but when it comes to picking the best tools. G…

I always thought the Java love at Google came from needing speed more than a startup -- they automatically will get factors of ten more users directly for most everything they do. (Edit: Point is, "Java-like" is Google's optimum for other reasons than being conservative.)

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.

Re: Replacing Python

#39
post #35

Earlier quoted context omitted.

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

"and you would get Java performance from your Python code." Nah, I doubt it would ever use _that_ much memory.

:) I guess what I meant to say was Java speed (or greater) Python.

Re: Replacing Python

#40
post #22

Earlier quoted context omitted.

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…

>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. I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less ab…

Wouldn't it be better to avoid calling the V() default constructor every time the function is called? You never know, it might have some long-winded side effect...

    template
    R defaulted(const V& val, const R& default_val) {
      const static V v0;
      return val == v0 ? default_val : val;
    }
Post reply on HN