Live data from Hacker News

Replacing Python

roscidus.com

81–90 of 144 posts

Re: Replacing Python

#81
I do not understand at all author's statement that OCaml datastructures are big win over Python's

  let {cache; config} = b in
  print_endline (String.concat "," cache);
  print_endline (String.concat "," config)
  ;;
vs, actually I'm not even sure what the ocaml is attempting, some variation of

  print '%s,' % b.cache
  print '%s,' % b.config
Which, in Python, if your printing more than a few should be

  print ',\n'.join((b.config, b.cache, b.data))
Or if want all fields and they are in correct order

  print ',\n'.join(b)
>> The syntax [of NamedTuples] isn’t great, though, and you can’t do pattern matching on the names, only by remembering the order:

Other than misuse of term "pattern matching", that statement is true and is trivially overcome with two line function, one line lambda, or once and for all by subclassing NamedTuple. Here's the function variant:

  def GimmieThing(keyword args in any order)
     return ThingNamedTuple(args in correct order)

Re: Replacing Python

#82
post #44

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.

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.

Re: Replacing Python

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

C# was excluded for being too slow to start. JVM-based languages would not fare any better.

> C# was excluded for being too slow to start.

This is only the case if the code is JITed.

With ngen and mono-aot it can be compiled to native code directly.

> JVM-based languages would not fare any better.

It is all a matter of which JVM is used. Some of them offer AOT compilation and on disk cache of JITted code from previous runs, thus matching the startup time of native binaries.

Re: Replacing Python

#84
post #76

Earlier quoted context omitted.

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?

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.

Re: Replacing Python

#85

Earlier quoted context omitted.

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 dependency: you probably have a point on Windows, but it's your choice to use an OS without a package manager to keep things up to date. I don't know about Mac but on Linux it is a non issue. That said it does not do well for desktop apps due to slow startup, high memory use and lack of native toolkit. It does much better as a server side runtime.

Although one of the best desktop RSS readers (RSSOwl) and two of the best IDEs (Eclipse & IntelliJ) are written in Java.

Re: Replacing Python

#86
post #78

Earlier quoted context omitted.

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.

Yep, no single language except C(/C++) is enough by itself (potential exception here is Java, but even there it's still useful).

C has become the lingua franca of computing. You can call everything (except Go) from C and you can call C from everything. So you want to actually reuse standard libraries, you will want to know C. And if you're a good C hacker you'll know C++. I'm not saying you'll necessarily use it, but you'll know it.

The vast majority of python programmers do not know how to call C/C++ code and are therefore limited to pure python libraries exclusively. They usually use writing to files and os.system() as an alternative. Needless to say, the performance of this approach can be questioned.

Re: Replacing Python

#88

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!

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.

Re: Replacing Python

#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 definitions, and only a couple lines that seem to actually do something.

I always joke around saying that if your Haskell code doesn't have typeclasses and monads, you're doing something wrong. By which I mean that unlike other languages, there's a huge, huge, huge gap between writing great haskell, and regular haskell, with a very steep learning curve.

Re: Replacing Python

#90

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 style guide is written so that mediocre programmers don't get too trapped by C++ nuances.
Post reply on HN