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

91–100 of 144 posts

Re: Replacing Python

#91

Post by luikore »

tikhonj wrote: post #43
Dewie wrote: post #30

Earlier quoted context omitted.

Can you think of some niches/circumstances where ATS might be worth using? EDIT: might it be possible to develop ATS programs that are easily called from other languages? ATS seems to have strong ties to C, so maybe one could call ATS code like one calls C code, or call C code that is a thin wrapper around the ATS code? Then you hopefully could have efficient, statically verified (to a high degree) code that can be u…

I've always thought it would be a perfect language for things like aerospace. NASA, for example, uses unsafe languages like C and compensates for that with extremely rigorous processes. Of course, this means that it takes forever to get anything done. I can't help thinking that using a better tool like ATS would actually increase productivity without compensating safety. If anything, the types would provide an extra…

If the mission is critical, choosing programmers matters more that choosing languages. If ATS is hard to use, then it's the right choice because the users who mastered such difficult technique must be the smartest guys...

Re: Replacing Python

#92

Post by nostrademons »

pron wrote: post #22
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/…

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…

Programming will always be a matter of modeling your own thought process. That's what domain knowledge is: a model of the problem domain so precise that a machine can follow it.

The important part is how easy that model is to communicate to the other programmers on your team, because that's what source code is. And that's going to depend upon their backgrounds. Hire a bunch of hackers that are all familiar with idiomatic Python, and Python is a great tool for communicating. Hire folks who like things spelled out in more detail, and Java is a great tool for communicating. Hire people who all think at the level of the machine and C is a great tool for communicating.

I do think that one of the major benefits of choosing a language is that you pick the people who will be willing to work with you. If you pick Haskell you will end up with a lot of folks with mathematical backgrounds and an interest in programming languages for programming languages' sake, which may or may not be a good thing depending upon problem domain. If you pick Python you will end up with a lot of folks that have command of large toolbox of scripting functions, although that toolbox may not perform great when adapted outside its original domain. If you pick Java you will end up with a lot of folks that don't want to think too hard about their language.

Of possible interest: http://www.nhplace.com/kent/PS/Lambda.html

Re: Replacing Python

#93

Post by nostrademons »

pron wrote: post #38
berntb wrote: post #37

Earlier quoted context omitted.

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.

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 that era (Search and much of the infrastructure) are still in C++. In general rewrites from C++ -> Java have not gone well; I know at least one such frontend that was rewritten back in C++ a year later.

Re: Replacing Python

#94

Post by nostrademons »

alextingle wrote: post #57
fauigerzigerk wrote: post #45

Earlier quoted context omitted.

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!

Google's styleguide makes it clear that the reason they don't use exceptions is because all code that calls a function that may throw an exception needs to be exception-safe, and Google has a large body of code that was written before exceptions were reliably supported by many compilers and so isn't exception-safe. It's a historical accident, in other words. The styleguide is also clear that if they were designing the it in the present without having to deal with a large body of legacy code, they might make a very different choice.

Re: Replacing Python

#95

Post by spongle »

steveklabnik wrote: post #84
spongle wrote: post #76

Earlier quoted context omitted.

Do you really notice that though?

I cannot remember exactly, but in the discussions about page load times translating into revenue, 100ms was the number being tossed around, IIRC. I certainly notice any time I boot something up that requires the JVM, I refuse to use the CLR, so I can't tell you much about my own experience with that.

Once it gets going though it screams. Not sure I want to trade the miniscule difference in startup time for that.

As for page load times, this is silly. There is no startup time on a page at all. Possibly the first hit but there are warm start options for that in CLR at least which make this a complete non issue.

To give you an idea, 98% of our page hits are under 80ms processing time and we have big, heavy pages (we're old school asp.net mostly).

Re: Replacing Python

#96

Post by steveklabnik »

spongle wrote: post #95
steveklabnik wrote: post #84

Earlier quoted context omitted.

I cannot remember exactly, but in the discussions about page load times translating into revenue, 100ms was the number being tossed around, IIRC. I certainly notice any time I boot something up that requires the JVM, I refuse to use the CLR, so I can't tell you much about my own experience with that.

Once it gets going though it screams. Not sure I want to trade the miniscule difference in startup time for that. As for page load times, this is silly. There is no startup time on a page at all. Possibly the first hit but there are warm start options for that in CLR at least which make this a complete non issue. To give you an idea, 98% of our page hits are under 80ms processing time and we have big, heavy pages (we…

I'm not talking about page load times. A server side app is a great use-case for something that has slow startup. I was just using that as a citation for perceptions on speed and how it can negatively affect experience.

I'm talking about command-line applications, like the one in the article and in your first post. Then you get the startup every single time you run the command.

Re: Replacing Python

#98

Post by dilap »

pjmlp wrote: post #82
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.

Yes, in terms of concepts, Go is pretty much a Java 1 with a native compiler as default implementation. However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language.

Seems to be a common sentiment, but from where I'm standing there are at least a few huge differences between Go and Java:

* duck typing * goroutines * channels

And some smaller but still important differences:

* Very light-weight Public/private distinction * Slices * Objects that embed directly in other objects, not as references * Return-value error handling; only a very restricted form of exceptions

Re: Replacing Python

#99

Post by oscargrouch »

pjmlp wrote: post #82
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.

Yes, in terms of concepts, Go is pretty much a Java 1 with a native compiler as default implementation. However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language.

>> However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language.

Yeah, only that you wont do this sort of things in a memory managed language like Go.

They make you think is low level(PR ?), only that it isnt THAT low level ;)

Go should be able to switch off the GC, and allow people do to manual memory management if it really want to be that low-level..

Also, a way to take off the runtime, and work as skinny as any C program could..

Only than, you could make real low-level programming like OS, device drivers and the like..

The use cases for Go right now in its current incarnation, are things like: cloud/distributed stuff(against C++), or command line tools (against Python)

To make it a contender against C, there's a long road.. and im sure its one route they dont want to go..

Re: Replacing Python

#100

Post by steveklabnik »

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.

The syntax of Rust is 99.9% (approx) decided. There was only one (or maybe two?) syntactic change in 0.8, and it was trivial to fix: https://github.com/steveklabnik/rust_for_rubyists/commit/a18...

It's the standard library and such that are moving fast still.

Post reply on HN