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

281–290 of 384 posts

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

#281

Post by mannykannot »

gameswithgo wrote: post #271
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…

was development time measured? loc count is not necessarily going to correlate well with time spent.

The work was done under a deadline, and some teams did not complete all of the assignment in the allotted time. The Python programmer not only completed all the required and optional features, passing 100% of all tests (both the revealed and secret ones), but "also implemented more extra features (for fun) than any other team, including an SSA intermediate representation with register allocation and other optimizations."

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

#282

Post by mruts »

nindalf wrote: post #199
tanin wrote: post #87

The Scala result confirms my bias :P I love Scala because it strikes a great balance between being succinct and offering type safety. I wish you would use Ruby instead of Python. Python is strangely inconsistent. For example, Python doesn't really offer a rich standard library; people have to resort to ugly solutions for a simple problem (here's an example: https://stackoverflow.com/questions/363944/python-idiom-to-r…

Your linked stackoverflow question - how do you return the first item of the list or None. Proposed solution - `a[0] if a else None` Your reaction - Python doesn't offer a rich standard library. I disagree, and I suspect most programmers would too. We'd much rather have ergonomic libraries to make http requests, parse command line arguments, datetime, itertools, data structures like heaps, filesystem access, data arc…

I have also found Python’s stdlib to be laughably bad. Just compare the data structures available to Scala. I write Python everyday and honestly, it’s a chore. The language is primitive and inexpressive.

The sad part is that it totally didn’t have to be this way. But instead of evolving, Python is just stuck in the past.

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

#283

Post by azov »

One big difference (which the article seems to mostly ignore) is that the shortest project was written by a single developer, while all others were a team effort.

Having the whole project - design, architecture, all implementation details - in one head is not a trivial advantage. Even ignoring communication overhead, there might be subtle duplication of code simply because different people choose to do similar things in slightly different ways.

While the ratio of Rust to Python code kind of matches my expectations, I wonder how much of it might be due to the difference in team structure vs the difference in chosen language.

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

#286

Post by boyter »

masklinn wrote: post #213
boyter wrote: post #7

I really wish when counting code that people would use one of the more modern code counters, or at least use cloc. Tokei, loc, scc, polyglot, loccount or gocloc give a much better idea over wc because they account for comments and blank lines and in the case of scc and tokei strings. I had a similar experience in university. Class had to implement a modified Turing machine. We could use whatever language we wanted. O…

> I really wish when counting code that people would use one of the more modern code counters, or at least use cloc. Tokei, loc, scc, polyglot, loccount or gocloc give a much better idea over wc because they account for comments and blank lines and in the case of scc and tokei strings. And even that only tells some of the story e.g. do code counters count separators ({ or } alone on a line) as blank or as code? Are m…

Usually they count { on a single line as code. Multi line strings are code in all but scc and Tokei. Tokei counts them as comments or string depending on user settings. Scc will count hem as comments in the next few months.

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

#287

Post by p0nce »

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…

How do we know the big result is "Python!" rather than "work alone!" or "women code better!" ? Because that was 3 features of that one sample. It's hard to make any conclusions from that article.

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

#288

Post by mannykannot »

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

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…

It is actually nearly a 30% reduction with respect to the Scala line count.

More to the point: while the numbers nominally show differences in languages, everyone with programming experience recognizes that unmeasured and uncontrolled human factors probably had a big part in the outcome.

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

#289

Post by p0nce »

bjourne wrote: post #92
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…

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?

It's pretty clear that (like in every programming teams) the size of the output (in LoC) was linear with the number of programmers, which is something our profession should be worried about.

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

#290

Post by pwm »

trishume wrote: post #12
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.…

I don't think monadic parser libraries have a real claim to be that difference. All the languages listed have excellent parsing libraries that make things similarly easy, if not by language power than by grammar DSL with embeddable code snippets. I think if any library could make a real difference for Haskell it's most likely to be http://hackage.haskell.org/package/lens , which a Haskeller friend of mine claims coul…

While I found your article informative and interesting I think it only works in the very specific context of this assignment. Disallowing powerful language features/libraries means it's not a level playing field and thus not a fair comparison. Some languages standard libraries are tiny some are huge. Some languages have lots of advanced features. Eg. GP mentioned GADTs with which one can write type safe/correct by construction ASTs. In other words programs passing specific tests in a specific context does not imply they are comparable in terms of general correctness/robustness/maintainability (as you noted this re caught edge cases).
Post reply on HN