Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

thume.ca

Post reply on HN
Print view View original

151–160 of 384 posts

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

#151

Post by garmaine »

tomasato wrote: post #103
steveklabnik wrote: post #43

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.

Excluding the lens library (as per the article) is unusual, it provides natural getter/setter and row polymorphism type functionality. More anecdotally, I’d argue parsing libraries are common, just look at the prevalence of attoparsec and others. But most parsing libraries in the ecosystem are parser combinator libraries which don’t support as performance and nice error messages that compilers need

That was where I stopped reading. If a library like lens—used by nearly every haskeller in every project—was disallowed, I don’t know what the purpose of this exercise was.

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

#152

Post by tanin »

dragonwriter wrote: post #145
tanin wrote: post #88

Earlier quoted context omitted.

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

While what you say is true, my small example shows that the code is longer in Python for solving the same problem, i.e. `my_list[0] if my_list else None` is longer than `my_list.headOption` or `my_list.first`.

And we are talking about the brevity of a language here.

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

#153

Post by trishume »

chenglou wrote: post #115

Hey trishume! It’s been a while (this is the Reason person). Great post; it echoes all the experiences I/we’ve personally had, especially the alternative Rust section: on the spectrum of how much intelligence one needs to understand fancy abstractions, all of us programmers, good and bad, are pretty much lumped to the lower end. I’ve seen plenty of skilled folks “decompensate” their expertise by reaching for overly c…

I expect Go would end up like C++ without header files or OCaml without sum types and pattern matching, falling somewhere in between them. Although if errors are handled properly instead of by panic then it might really hurt in the line count from all the `if err != nil { return; }`

Also I commented somewhere else in this thread re perf comparison. Short answer is that since there's no incentive towards performance the signal would be swamped by differences in how much people avoid O(n^2) algorithms even if you don't need to.

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

#154

Post by tanin »

vesche wrote: post #139
tanin wrote: post #88

Earlier quoted context omitted.

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.)

Sounds like you just don't like Python, but you don't have great reasons for not liking it. The standard library is fantastic in Python. Find better reasons to back up your unfounded dislike.

Saying Ruby/Scala have richer standard lib than Python isn't really a stab at Python.

Like dragonwriter says, it shows that "Python expresses the concept fairly compactly in the core language without even resorting to stdlib".

It depends on your taste whether you like richer stdlib, and I do. But some don't.

We are talking about how short the code can be in this post, and `my_list[0] if my_list else None` (Python) is longer than `my_list.headOption` (Scala) or `my_list.first` (Ruby).

I'd appreciate more if you elaborate why my example isn't a good illustration on the brevity aspect.

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

#155

Post by friedman23 »

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 don't think the reason why these languages are terser is because they are dynamic. Something that always frustrates me to no end is how many older statically types languages barely have a literal syntax.

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

#156

Post by Buttons840 »

anaphor wrote: post #63

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…

A contest to see how easily code could be broken would be interesting.

"I purposely broke the code somewhere in these 20 lines. Find the bug and fix it."

You can use the compiler, you can use the test suite. You cannot diff the code against the original working code.

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

#157

Post by [deleted] »

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,…

[deleted]

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

#158

Post by AlexCoventry »

hart_russell wrote: post #48
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,…

I'd like to hear others' opinions: There's a guy at my work who loves to use doubly, triply, quadruple-ly nested ternary operators. I always find them super hard to read. Am I just a dunce, or do I have a point in thinking it's unnecessarily terse.

If he's making the code hard to read, hopefully you can talk that through with him. It sounds like a reasonable concern.

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

#159

Post by nybble41 »

galaxyLogic wrote: post #64
WalterBright wrote: post #50

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…

> So they were not exactly novices in their language of choice.

The Haskell team had "maybe a couple thousand lines of Haskell each" at the start. This one project ended up being 9.7k lines, so it constitutes half of their collective experience with the language. I'd say that counts as "novice" in terms of prior Haskell experience. Under the circumstances I think they did remarkably well to produce a thoroughly tested and maintainable end product in just twice the lines of code of the quick-and-dirty Python implementation.

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

#160

Post by tigershark »

galaxyLogic wrote: post #64
WalterBright wrote: post #50

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…

There were people with 2k to 10k loc of experience in some language. That seems extremely low for any meaningful comparison and I would really hope that “average” programmers have way more experience than that... I think I was pretty junior after writing north of 100k loc and working on 1M loc projects. And for sure I don’t consider myself highly competent in F# after writing some thousands lines. I agree with the conclusions when they say that the design decisions are much more important than the language of choice. But I still firmly believe that the language makes a very big difference in real world projects. In toy throw away projects obviously metaprogramming cuts a lot of locs.
Post reply on HN