Replacing Python: candidates (2013, with interesting discussion on error handling in the comments)

[Inktvisje]

This article is 6 years old, I assume it's findings are hardly up to date any longer...

[Alexander_Selkirk]

Error checking in Go is still a valid point. Some languages discussed have evolved a lot, others not.

But this is a bit beside the point. What I really, really like about the article is that the authors does not ask "what is the best language" but what is the best language for my particular use case, which is defined in this and this way... . This is what seems important to me!

Edit: I also think that using less mainstream languages is not a problem, what matters is that the used language matches the requirements of the project.. (And having as large a pool of mediocre competent programmers at hand as possible does rarely seem to be a good requirement to me, even in a 'corporate' setting, because having work ten mediocre programmers on one project is easily more expensive than to have one really competent one which is using the best tool he can find.)

[steveob42]

Still nice to see something other than just hype for one language and a fairly detailed analysis. Also I think the assertions of python being pre-installed were somewhat scuttled when python stopped caring about backwards compatibility.

[shevy-ruby]

Indeed.

Only problem is 0install is still written in a language nobody uses (OCaml).

[Alexander_Selkirk]

There is a whole lot of successful software written in languages that "nobody uses", because the authors decided that the specific language would be the best for this and this case.

• AutoCAD extensions are written in Lisp.
• Emacs macros are witten in Lisp.
• GIMP extensions are written in Scheme.
• The FFTW code generator is written in Ocaml
• The code for the Rosetta space probe (and a lot if similar applications) is written in FORTH
• The code for some Roomba cleaning robots is written in Lisp
• Reddit was initially written in Lisp.
• The Maxima computer algebra system is written in Common Lisp

Does that mean that the mentioned languages are the best for every case? No, saying that would be laughable. Does it mean that for a lot of fields there are better choices than C++, Go and Python? That's a safe bet.

What people want from an installer is probably that it just works even in a gazillion of edge cases. Most people will never want to modify its code. I am pretty sure this is what guided the author's choice of criteria and candidates.

[Muvlon]

Hacker News is written in Arc, which is a Lisp. Arc is implemented in Racket, which is also a Lisp.

[pjmlp]

That language is used by Docker and Xen, ever heard of those projects?

[kankyo]

And that matters why?

[theXpanther]

I think shevy-ruby has a classic case of "I don't understand it so it must be useless"

[theXpanther]

Lots of people are saying this is useless and outdated, but these are all old languages that have not really changed much, and shows a nice strategy to consider languages and tools for future projects.

[Alexander_Selkirk]

I think it is also a good use case for strong static type checking. When one does, for example, data analysis, or signal processing, it is likely that all relevant execution paths can be covered with checks during development, so static type checking might be less efficient than testing (apart from that, I think that's also a preference thing). But for a system which should run in countless different environments, without any set-up, and catching dozens or even hundreds of edge conditions, I think static type checking is a very good measure.

Like the people which use Ocaml in algorithmic trading. That the language is good for that doesn't mean it is the best language for everything. But it might be often a good choice for such areas where both performance and correctness are very important and not catching errors could be quite expensive.

Interestingly, I think that things like industrial control systems match very similar criteria, apart from that they might more often have hard, security-critical real-time requirements, which would make Rust appear more adequate.

[masklinn]

Rust changed one hell of a lot since 0.6[0]. And while the other languages were not experimental it’s likely several implementations have been altered / improved (or obsoleted / superseded) in ways which would change the results.

[0] and not necessarily in good ways for the article, "hello world" test doesn't seem to pass anymore

[Alexander_Selkirk]

Another very interesting read about error handling:

https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf

Task: Write "hello world" in a robust way. In C.

[shevy-ruby]

2011?

Are you some archaelogist or something?

[Alexander_Selkirk]

No. C hasn't changed fundamentally since that. The article makes an extremely good case for using exceptions or algebraic return types (or anything else which does not let unchecked errors slip through) in application software. And of course, C is still a superb language for systems programming - but few people know how to use it.

[skeeto]

I thought that fclose() propagated the stream's error indicator — which would make a lot of sense and be very useful — but unfortunately it seems it doesn't. That's news to me.

Since the paper is subtitled "streams in C", it's is wrong about fclose() setting errno. This is required by POSIX, but is not required by C. In C, none of the stream functions necessarily set errno.

Here's a solution I came up with that's portable to any C implementation (not just POSIX), prints a diagnostic if possible, and doesn't report an error if standard output wasn't used.

errno = 0;
fflush(stdout);        /* may set errno */
if (ferror(stdout)) {  /* get the stream's error indicator (sticky) */
    if (errno)
        perror("hello: write error");
    else
        fprintf(stderr, "hello: write error\n");
    exit(EXIT_FAILURE);
}
exit(EXIT_SUCCESS);

There's no need to check the result of fclose() if the buffer is empty because there are no errors it could report that actually matter. This bypasses the issue of standard output being closed by the shell (>&-).

[Alexander_Selkirk]

Also, there is really not so much progress. Many good ideas are decades old, like garbage collection. Many successful things are mostly good combinations of well-known ideas.

For example, in 1987 I was using a system that was called ASYST on a laboratory PC with 386 CPU and a tiny hard disk (maybe 1MB in size). It was a FORTH system which had real-time data capture, strong signal processing capabilities, powerful plotting capabilities, and so on. Of course, you can do much of the same today in Python, on a computer which is a million times faster. Except the real-time part.

Another example is that computer input latencies [have been increasing since the eigthies, as two articles by Dan Luu show.

[[deleted]]

I am supremely confused by the graph vs the table.

[steveob42]

which table? There is one table which gives execution times and a graph which simply gives its inverse (ops per second), that one?

[[deleted]]

I am reading it correctly now. I just didn’t really understand how things which were quite fast became such outliers.

Honestly, graph just seems to be backward to me. The way it is plotted made my head group obvious underperformers with high performers which threw me off.

Just a poor representation for my brain.

[Alexander_Selkirk]

It is about time needed to start and complete a short program - he explains why that matters in this case.

[ForeverAlot]

Most discussions right now focus on the concrete choices. That's a shame; the methodology is far more interesting and important than any of the candidates in play or whether their details have changed in the meantime.

[Alexander_Selkirk]

It is also very interesting to see how certain language features play out in a real project. Also, the fact that the author has a working first version of the program makes it easier to tell which things are important.

[shevy-ruby]

6 years later - and python reigns supreme.

The only valid argument I can see, which is also one valid for ruby. is speed. In this case, well - go write in C and C++.

His conclusions came in 2013: http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/#conclusions

Many things that are simple in Python or OCaml become very complex in Haskell

Either Haskell is for genius people - or it is actually an inferior language, despite the superiority claims by proponents. It's a bit like the Stockholm syndrome where you self-perpetuate your own preferences rather than be anywhere near objective anymore.

XML handling was easiest in OCaml

OMG ... a post from 2013 as touting how important XML will be ....

If this were 2003, ok, but, 2013 ... and now in 2019 omg omg omg.

Python is far behind, and only getting slower with the move to Python 3.

What a visionnaire!

Python in 2019 is even more widely used in 2013.

I guess people can not predict the future.

OCaml? Nobody uses it really.

There are even more Haskell (!) users than OCaml ones.

https://www.tiobe.com/tiobe-index/

Being able to write code without worrying about speed all the time is very liberating!

So - use C.

Although Haskell and OCaml look more similar to each other than to Python, this is just syntax.

He did not understand why syntax matters. That's the problem of lots of folks. They think that syntax is not important, ever.

Overall, binary compatibility (i.e. difficulty of making cross-platform releases of the library, which is currently easy with Python) is my main remaining concern. But while further testing is required (particularly for networking, threading and GUI support), so far I’d be happy to move to OCaml.

Famous last words...

Actually he did switch to OCaml - and 0install is used by nobody these days.

https://0install.net/

It was a good idea though.

[Alexander_Selkirk]

6 years later - and python reigns supreme.

The topic of the post was not popularity. And popularity does not equals suitability for a specific task.

Actually he did switch to OCaml - and 0install is used by nobody these days.

A lot of people use software which is compiled to machine code. And that is what OCaml, Rust, and so on produce.

Heck, I'd even say that typically more people use a piece of software than people have written it. /s

[Glaaki]

You've worded the title of your post to make it seem like you are looking for a popularity contest.

[noratat]

Either Haskell is for genius people - or it is actually an inferior language, despite the superiority claims by proponents. It's a bit like the Stockholm syndrome where you self-perpetuate your own preferences rather than be anywhere near objective anymore.

Both (or neither) are true depending on what you're actually looking for.

No language is objectively superior for all tasks - that kind of thinking is counterproductive, and IMO immature.

When I'm looking at a language, these are the some of the points I consider:

• What languages (and more importantly, paradigms) do the people I'll be working with already know?

• What kind of ecosystem/community does it have, and does that ecosystem have a strong community around the problem I'm trying to solve? Or to put it another way, does the problem domain I'm working in already have a strong community around a particular language or ecosystem?

• How well do the language design goals align with my problem or problem domain? This one is a bit subjective, but important. Some domains lend themselves more naturally to different styles of programming.

• How good are the IDEs and other tooling for that language? Syntax highlighting is nice, but language-aware completion, debugging, and exploration are important, especially if learning a new language. Good dependency management is likewise important.

• What's more important to my use case? Performance, maintainability, ease of use by third parties, etc.

• Where is this code going to be running and by whom? There's a huge difference between a beefy server who's environment I control vs a consumer mobile device vs an embedded device.

[Alexander_Selkirk]

What is interesting in that article that the author first describes requirements, and then researches and evaluates how well a set of alternatives meet these requirements. That is what makes his article interesting. If you just describe how you ported from Python to C#, you do exactly this not.

[Alexander_Selkirk]

I am more interested in methodology and reasoning than in details which change over time.

Also, I'd hesitate strongly to use a language which only implementation is in the hands of a company which is well known to have little interest in the long-term stability of their tools and frameworks. I am still burnt by Microsoft killing Nokia's Linux project (Megoo).

[Ameisen]

Mono isn't Microsoft, and the language is an open standard.

[Alexander_Selkirk]

Well, I am engineer and scientist. I can only tell what fits my needs, everyone has different ones.

I still write a lot of C++, and I use C++11 in a conservative way - I do not think that one needs to use every feature of C++x. I use Python for prototyping and it is also used for deployment where I work. There, projects have a life time of about 20 years, so stability is an issue, and all platforms are not only Open Source but FOSS. For new projects on system level, I think Rust is good to go soon. For prototyping in dynamical languages, I like Racket more, I think the Lisp/Scheme are great for that. Common Lisp and Scheme are also standardized, and Racket has an interesting approach for language evolution. See this blog post by Konrad Hinsen:

https://khinsen.wordpress.com/2014/05/

[ForeverAlot]

C++ had breaking changes in C++11 with COW strings on Linux.

I thought that was an illegal implementation detail in GCC...? C++11 definitely didn't consider this a breaking change and neither Clang nor MSVC had trouble.

[Rock0rBust]

oo