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

111–120 of 384 posts

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

#111

Post by new4thaccount »

geofft wrote: post #79
trishume wrote: post #61

Earlier quoted context omitted.

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

Tangentially - do you know how fast her compiler was compared to the compiled-language implementations? I have a vague sense that for many applications, interpreted languages are totally fine and reaching for a compiled language is premature optimization, but I'm curious how it actually holds up for a compiler, which is more computationally heavy than your average web app or CLI.

Yep, the takeaway for me was that the Python project required far less code, but we're not sure how fast it ran. Further below, the author states the inputs were so small it didn't matter. What if it did? Would the Python solution still be viable?

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

#112

Post by torben-friis »

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…

My experience is that you always use a type system. If the language doesn't include one, you'll end up making a bunch of extra tests and control code that in practice is constraining your data to resemble a type. It's a worse system: more verbose, harder to refactor and it's way easier to miss corner cases.

It's either that or assuming that your data will contain exactly what you want to, ignoring every possibility outside the happy path, which is a recipe for disaster.

That said, I have to say that modern JS produces the cleanest looking and less verbose code I've ever worked with so far. I wish there was a way to work with types without adding verbosity and harming readability.

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

#113

Post by stretchwithme »

galaxyLogic wrote: post #66
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.

It would certainly help people decide what tobecome an expert in. And there must be some correlation with what an expert and an amateur can do.

Of course, I can think of examples where that isn't true.

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

#114

Post by z3phyr »

jancsika wrote: post #94
WalterBright wrote: post #49

Earlier quoted context omitted.

A typical translation of C++ code into D reduces the line count by a substantial amount, simply because D doesn't require .h files.

What are relative compile times like? Building Chromium atm, and to be honest I'd be happy if it were written in a trillion lines of BASIC if that would somehow achieve even a 10x build time speedup.

For chromium, the most important concern will be runtime speed, more than compile time

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

#115

Post by chenglou »

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 complex abstractions. The definition of a “strong” programmer, as per the post and usually in real world, should probably be rectified to include not only “the person knows how to use this abstraction”, but also “the person knows when to stop”.

In the same vein of idea, it’d be interesting to know how Go would fare in this project. Go’s philosophy is pretty much the opposite of a language that’s usually used for compiler research; but I’ve seen indicators that using it could be surprisingly effective (and in light of this post, maybe less surprising).

More importantly, it’d be nice to know the perf characteristics of each project =)

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

#116

Post by roca »

galaxyLogic wrote: post #75
trishume wrote: post #61

Earlier quoted context omitted.

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

I've read my share of cryptic JavaScript written by others and in that sense I agree that in multi-person long-term projects static typing no doubt will have its advantages. My hunch is however that what is often overlooked in development with statically typed languages is that it takes considerable time and effort to come up with the right set of types. Many examples are written showing how types almost magically ma…

No matter what, you need a rigorous schema for your data. If you write a complex JS/Python program without doing the equivalent of "come up with the right set of types" then you will have a bad time. I'm sure in the OP here the skilled Python programmer did think carefully about the shapes of her data, she just didn't write it down.

To be sure, having to write down those data structure invariants in a rigorous way that fits into the type system of your programming language has a cost. But the hard part really is coming up with the invariants, and it's dangerous to think that dynamic languages obviate the need for that.

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

#117

Post by mannykannot »

trishume wrote: post #61
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 lan…

In my personal notion of code quality, being correct counts for a lot, and this programmer aced the tests, while apparently delivering more within the deadline that any of the multi-person teams.

While writing the previous paragraph, I wrote 'programmer' where I had previously put 'implementation', because I would guess that this study's outcome is better explained by human factors than language differences.

I share the attitudes you state in your last paragraph, but I would add that we should be skeptical of concepts of quality that seem plausible, but which lack empirical evidence for their effectiveness.

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

#118

Post by zmmmmm »

galaxyLogic wrote: post #97
zmmmmm wrote: 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…

No I would not reach quite that conclusion I would say "Python saved 20% code lines over Scala!". The results say something about the greatness of Scala, not of statically typed languages in general. The other ones did not do quite as good as Scala. From what little Scala I've read it looks very terse indeed. That can be a benefit but at the same time makes it harder to understand code written in it, in my opinion.

I think most people would consider 20% basically within the margin of error induced by stylistic and other non-meaningful differences.

For example, it's not completely clear from the post but it seems like the 0.5x figure is from wc -l, which means Python wins a line every time there is a conditional or loop just because it doesn't need a closing brace. That alone might eat up a lot of the 20%, but you would be hard pressed to say that is a meaningful difference.

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

#119

Post by new4thaccount »

analog31 wrote: post #62

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" p…

Give Julia a try if you haven't. If you're coming from Python and also have some Octave experience, it will be easy and worth a look.

For scientific coding I usually use either Python or Julia and Fortran or Octave at home sometimes.

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

#120

Post by tanin »

ibejoeb wrote: post #109
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'm not sure what your example is illustrating. The SO question asks for the idiomatic one-liner to get the first non-null element of a list. The accepted answer does that. next(iter(your_list), None) This is 100% standard library.

Maybe I should have given the comparable example in Ruby, which is `array.first`. Even Scala offers `array.headOption`. Both are more succinct than Python's.

The degree of richness and/or the height of abstraction seem lower in Python. (Not that this is a bad thing. It depends on people's taste, of course.)

Post reply on HN