Live data from Hacker News

Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

thume.ca

141–150 of 384 posts

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#141

I can hear all the Haskell fanboys screaming that they didn't do Haskell right because a kleisli arrow didn't appear and ascend them into monadic heaven.

To be fair, I don’t think any Haskeller would actually write this project without attoparsec and maybe lens by choice. They’re basically base libraries for this sort of thing.

Agreed. The rule about not using any library that doesn't ship with the compiler creates a heavy bias in favor of "batteries included" languages like Python. I understand not allowing parsing libraries, given the nature of the assignment, but if even widely used libraries like lens are off-limits the result is not going to resemble idiomatic Haskell. As a matter of basic fairness, if some library or built-in language feature is to be permitted for one implementation then analogous libraries should be permitted for all the other implementations regardless of whether they happen to ship with the compiler.

The eval function leveraged heavily by the Python version should probably also have been off-limits, for the same reason that parsing libraries were prohibited. Using eval amounts to embedding an existing fully-developed parser and runtime environment into the project as a library.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#143
post #37

Excellently written, great topic, and done w/o flaming/too much bias. I'm amazed as many older folks in the industry would not be able to have this level of content and maturity to write an informative article.

It's difficult to write a fair comparison without being a fairly competent programmer in each of the languages. The trouble is, if a person is an expert C programmer and then translates it to Python that he's only modestly familiar with, the Python program will look like C. It won't be idiomatic Python. For example, my early Fortran programs looked like Basic. My early C programs looked like Fortran. My early C++ pro…

I would have liked to see what a team using C would have come up with in the author's set.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#144

Earlier quoted context omitted.

My understanding is that in production compilers, hand rolled parsers are the norm. Parsing libraries are cool, but just aren’t used for big projects.

Both OCaml and GHC use parser generators. It is incorrect to suggest production compilers hand roll parsers.

Two counterexamples does not disprove “a norm”. There are always exceptions!

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#145
post #88
post #82

Earlier quoted context omitted.

Seems like a bit of a bold claim when the author themselves directly contradicts that in their own conclusion: > I think my overall takeaway is that design decisions make a much larger difference than the language After all, Scala was 0.7x the size and is one of the most strongly statically typed languages. So you could almost invert your conclusion and say the big result is "Python only saved 20% code lines over ful…

One factor on why Python only saves 20%. Scala has a very rich standard library. Python doesn't. An example is: https://stackoverflow.com/questions/363944/python-idiom-to-r... Ruby would have been a better example of how succinct a dynamic-typed language can be. (I made a similar comment on the parent level.)

I don't see how that example is relevant, because:

(1) It shows Python expresses the concept fairly compactly in the core language without even resorting to stdlib,

(2) It ignores an option (also in the core language) using a ternary and the truthiness of lists: my_list[0] if my_list else None

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#146
post #22

If you're into this sort of thing, definitely check out the ICFP Programming Contest -- take next Friday off and join in on the fun! https://icfpcontest2019.github.io/

> Any programming language(s) on any platform(s) may be used. How does this work? What’s stopping me from using some hyperpowered esolang I cooked up for the competition?

If I recall correctly, the 2001 ICFP contest was won by someone who happened to have done their thesis on the contest problem. :-)

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#147

I think the big big result from this study is: "Python: half the size !". A dynamic language like Python is better here, 2x better. I assume similar results would apply to other dynamic languages like JavaScript, Lisp, Smalltalk, Groovy etc. This does not say that static typing should not be used but I think it shows unequivocally that there is a considerable extra development cost associated with static typing. You…

> I think the big big result from this study is: "Python: half the size!". I would agree, if and only if I thought a representative sample of Python programmers would all produce something of a similar size and just as correct, but I suspect, in this case, it's the result of one especially talented person.

Raw talent and prior experience no doubt had something to do with it, but there's also the fact that the Python programmer was working alone and not particularly concerned about code quality or maintainability.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#148
post #92

Earlier quoted context omitted.

The takeaway for me was: "The next comparison was my friend who did a compiler on her own in Python and used less than half the code we did because of the power of metaprogramming and dynamic types." So it's the output of ONE Python programmer vs teams of other languages programmers?

That is a good point worth emphasizing. It is well-known that teams cause overhead. Think of the Mythical Man-Moth. But in the end the other teams had 3 people that were able to maintain and develop their project further, if needed. The single-person team had only one such person.

But the Python code was also smaller. Easier to learn and maintain.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#149

Earlier quoted context omitted.

Both OCaml and GHC use parser generators. It is incorrect to suggest production compilers hand roll parsers.

Two counterexamples does not disprove “a norm”. There are always exceptions!

Right, to prove or disprove the norm one would need much more information. Two counterexamples does, however, disprove that "Parsing libraries ... just aren’t used for big projects." GHC and the OCaml compiler are both big projects, and they use parsing libraries.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#150

Earlier quoted context omitted.

It's difficult to write a fair comparison without being a fairly competent programmer in each of the languages. The trouble is, if a person is an expert C programmer and then translates it to Python that he's only modestly familiar with, the Python program will look like C. It won't be idiomatic Python. For example, my early Fortran programs looked like Basic. My early C programs looked like Fortran. My early C++ pro…

That is all true. At the same time here the groups were allowed to use the language of their choice. Presumably they chose languages they felt they were competent in. Of course an expert of a given programming language can write much better in it than a novice. But a comparison like this is not necessarily about comparing top-programmers in every language, but average programmers, because we want to know results that…

I'd say that "on average" results may be very misleading, in formal statistics and in results like this. Variance and median are very important: see comments about Haskell downthread. (Ideally you have a histogram.)

In particular, some languages with a good average may contain pitfalls that could lead to abysmal outlier results (e.g. C++ or Scala, in entirely different ways), some would keep you from doing really dangerous things but also would not let you achieve spectacular things (e.g. Go).

Post reply on HN