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

51–60 of 144 posts

Re: Replacing Python

#51

Post by NateDad »

tikhonj wrote: post #44
shurcooL wrote: post #32

Earlier quoted context omitted.

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

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.

Re: Replacing Python

#52

Post by NateDad »

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.

Re: Replacing Python

#53

Post by mercurial »

RivieraKid wrote: post #50
alextingle wrote: post #42

Earlier quoted context omitted.

If I need to install the JVM just to try your software, then it's going to remain untried - however many design patterns you've managed to cram into it.

Why, because the JVM is too big?

Sounds more like trolling than participating to a rational discussion

Re: Replacing Python

#54

Post by NateDad »

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.

Re: Replacing Python

#55

Post by alextingle »

RivieraKid wrote: post #50
alextingle wrote: post #42

Earlier quoted context omitted.

If I need to install the JVM just to try your software, then it's going to remain untried - however many design patterns you've managed to cram into it.

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.

Re: Replacing Python

#56

Post by rhizome31 »

RivieraKid wrote: post #50
alextingle wrote: post #42

Earlier quoted context omitted.

If I need to install the JVM just to try your software, then it's going to remain untried - however many design patterns you've managed to cram into it.

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.

Re: Replacing Python

#57

Post by alextingle »

fauigerzigerk wrote: post #45
alextingle wrote: post #40

Earlier quoted context omitted.

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; }

There was a time (before C++11) when not even local static variable initialization was guaranteed to be thread safe. And there are a few other reasons why it is discouraged: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... So it's basically defensive programming, but I agree with you that it's probably too defensive nowadays.

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!

Re: Replacing Python

#58

Post by alextingle »

mercurial wrote: post #53
RivieraKid wrote: post #50

Earlier quoted context omitted.

Why, because the JVM is too big?

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: Replacing Python

#59

Post by mjn »

Erwin wrote: post #49
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…

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…

I like this article on that subject, which as it happens uses argument-parsing as the running example: http://www.yosefk.com/blog/redundancy-vs-dependencies-which-...

Re: Replacing Python

#60

Post by jzwinck »

Erwin wrote: post #49
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…

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.

Post reply on HN