Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml • Hacker News Board

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

#61

Post by trishume » Sun, Jun 16, 2019, 12:58 AM UTC

galaxyLogic wrote: post #57

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 agree it's definitely an interesting result and a point in favour of dynamic languages.

A caveat is that I'm pretty sure my friend intentionally sacrificed code quality to do it, I don't think you'd find that project as readable and understandable as the others. Another caveat is that you have to be okay with your codebase being extremely magical and metaprogramming-heavy, which many industrial users of dynamic languages avoid.

As I mention, I'm personally into statically typed languages mostly for the performance and correctness benefits. I think it's plausible that on larger projects with teams the correctness benefits save enough debugging time that overall implementation time is lower, but I'm less confident in this now than I was before this comparison.

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

#62

Post by analog31 » Sun, Jun 16, 2019, 12:59 AM UTC

I conducted a similar exercise, albeit on a much smaller scale, when I was "language shopping." I took a project that I had written in Visual Basic (my go-to language at the time), and re-wrote it in a variety of programming environments.

The project was just complex enough to require maybe 100-200 lines of code at the end of the day, thanks to liberal use of libraries. Not huge, but not atypical for a "scientific" programmer who uses code as a way to solve problems rather than to create software for others to use. It's pretty representative of my life as a programmer.

The exercise forced me to learn enough of each language to get a feel for it, and then I could look at the programs alongside one another to assess their strengths. I also imposed some rules, such as that the language had to run on multiple platforms, and be FOSS. In addition to comparing the languages, I was also implicitly comparing libraries and even access to online help. This was also my first real exposure to StackOverflow.

I tested Javascript, Python, GNU Octave, and wxMaxima. Ultimately Python won out and is my language of choice today. This was just my own little exercise, and not worth publishing, but has made me a believer in learning multiple languages.

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

#63

Post by anaphor » Sun, Jun 16, 2019, 1:00 AM UTC

I think the right metric to measure here is not quantitative, but more qualitative.

In other words, how easy it is to adapt the language to the problem you are trying to solve.

So, in order to do that you need to have a good understanding of the principles each language is based on. Once you've got that, then you look at the resulting code and "measure" how easy it is to understand.

As was already said, this requires having someone with a very good understanding of the underpinnings of each language, which is not really going to be reasonable for most people.

The problem is that if you simply tried to port an idiomatic solution from e.g. C++ or Python into Haskell or Scala, or whatever, then you would probably end up with something very ugly, because you didn't adapt the language to your problem. You tried to force it to do something it wasn't necessarily designed to do.

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

#64

Post by galaxyLogic » Sun, Jun 16, 2019, 1:02 AM UTC

WalterBright wrote: post #50

bfung wrote: 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…

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 are true "on average" .

The author does note he "knew (they) were highly competent". So they were not exactly novices in their language of choice. Writing a compiler is not a task for novices in general.

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

#65

Post by galaxyLogic » Sun, Jun 16, 2019, 1:08 AM UTC

jpittis wrote: post #11

> I think the smaller differences are also large enough to rule out extraordinary claims, like the ones I’ve read that say writing a compiler in Haskell takes less than half the code of C++ by virtue of the language Specifically the "by virtue of the language" part: Seems to me like it's unreasonable to claim the languages are on equal footing because fancy parser libraries aren't allowed to be used for the project.…

Using a fancy parser-library would mean we should also count the lines of code in it. It would basically mean adapting an existing solution. In practice that would make a lot of sense, but if the purpose is to compare the productivity of different languages then not so much.

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

#66

Post by galaxyLogic » Sun, Jun 16, 2019, 1:12 AM UTC

stretchwithme wrote: post #58

It would be interesting to see experts in different technologies compete, in front of a live audience, to implement or change a variety of projects. It would be useful to see what a master can do with each tool or platform.

It would be interesting and educational to see how they would do it, definitely. But when comparing languages it makes sense to compare how well average people perform with them. We can't always hire an expert they are not universally available.

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

#67

Post by krick » Sun, Jun 16, 2019, 1:15 AM UTC

saagarjha wrote: post #31

awwaiid wrote: 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?

Nothing, if it helps you with the challenge.

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

#68

Post by ben_jones » Sun, Jun 16, 2019, 1:15 AM UTC

ufmace wrote: post #9

I haven't made it through the whole thing yet, but I do want to register a vote in favor of using Lines Of Code count as a rough measure of program complexity. I think it's a perfectly valid things to do, provided that it isn't used as an evaluation metric and nobody is gaming it, and everyone is a reasonably good programmer, not doing crazy things like trying to stuff a massive algorithm onto one line to be clever,…

IMO a good start would be to create a metric based on a combination of:

* Lines of code

* # of keywords/operators

* # of non-standard keywords/operators (i.e. 'go' versus 'if')

* Use of std. library vs. 3rd party libraries

* Depth of call-stack, i.e. is it passing through 3 parent classes

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

#69

Post by geofft » Sun, Jun 16, 2019, 1:16 AM UTC

galaxyLogic wrote: post #65

jpittis wrote: post #11

> I think the smaller differences are also large enough to rule out extraordinary claims, like the ones I’ve read that say writing a compiler in Haskell takes less than half the code of C++ by virtue of the language Specifically the "by virtue of the language" part: Seems to me like it's unreasonable to claim the languages are on equal footing because fancy parser libraries aren't allowed to be used for the project.…

Using a fancy parser-library would mean we should also count the lines of code in it. It would basically mean adapting an existing solution. In practice that would make a lot of sense, but if the purpose is to compare the productivity of different languages then not so much.

Isn't it a facet of productivity of the language that it's easier to write certain types of libraries in one language than another? If you're writing a compiler, the fact that lots of people write parser libraries in Haskell is a point in favor of Haskell, whether if you intend to use those libraries (because they're available and production-tested) or you intend to write your own (because it's demonstrably a productive language for that sort of work).

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

#70

Post by dmurray » Sun, Jun 16, 2019, 1:17 AM UTC

galaxyLogic wrote: post #57

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 !".

> A dynamic language like Python is better here, 2x better.

I was surprised by how small the LOC benefit was from using the dynamic languages. As someone who typically reaches for Python, I'd use a statically typed language (Go or Java, most likely) much more often if I expected only twice as many lines of code. In practice I feel the same project takes 3-10 times as many LOC and that pushes it to where it is more difficult to maintain and understand.