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

331–340 of 384 posts

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

#331

Post by firethief »

gricjeh wrote: post #321
celrod wrote: post #300

Earlier quoted context omitted.

These were different teams of students taking a class. Variance in student effort/quality is generally high. There were two Rust teams. One had 3x the code and passed less tests than the other. This is our only reference for how much noise is owed to team rather than language; no other language was used by more than one team. Python did best (least amount of code, yet also the most features) less because of Python, b…

And then again still, the “best programmer” sacrificed code quality in pursuit of quickly producing features. The article doesn’t define code quality measures but I’d still take the lines of code metric as either not a measure of value in itself or with a massive grain of salt.

That was the right tradeoff for the situation. I think any attempt to use this case study to draw conclusions about maintainability would be a mistake; that's just not what this is useful for.

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

#332

Post by karmakaze »

I've condensed the relative source code sizes and notes for quick ref:

  Rust_1  1.0 using recursive descent, visitor
  Haskell 1.0-1.6x depending on how you count for interesting reasons
  C++     1.4x for mundane reasons
  Python  0.5x fancy metaprogramming, dynamic typing, single author
  Rust_2  3x different design decisions
  Scala   0.7x LR table generator, online Java grammar
  OCaml   1.0-1.6x depending on how you count, similar to Haskell
> AST visitors and recursive descent [...] weren’t taught in the course

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

#333

Post by pyrale »

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…

Recoding a viable subset of lens would have taken 50 locs in haskell. Likewise, rewriting parser combinators would not have taken long for experienced devs. The problem here is that requiring people to recode the libs on top of the compiler is disingenuous. And if you ban idiomatic libs, you also ban most online help, tutorials, etc.

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

#334

Post by karmakaze »

karmakaze wrote: post #332

I've condensed the relative source code sizes and notes for quick ref: Rust_1 1.0 using recursive descent, visitor Haskell 1.0-1.6x depending on how you count for interesting reasons C++ 1.4x for mundane reasons Python 0.5x fancy metaprogramming, dynamic typing, single author Rust_2 3x different design decisions Scala 0.7x LR table generator, online Java grammar OCaml 1.0-1.6x depending on how you count, similar to H…

Looking at this, my takeaways are different:

  Similar implementations in Rust(1) and C++ are roughly the same
  Similar implementations in Haskell and OCaml are roughly the same
  A similar implementation in Rust(2) to one in Haskell/OCaml is roughly 2x-3x
  Don't underestimate dynamic typing, metaprogramming, and individual effectiveness
But for real world, long lived projects I still promote static typing with the exception of startup development (MVP/product validation, early iterations) of new product ideas.

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

#335

Post by pyrale »

fnord123 wrote: post #225
nybble41 wrote: post #149

Earlier quoted context omitted.

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.

I think big here means impactful.

Both GHC and ocaml have a pretty good claim at being among the most influential compilers of their generation.

If you look at Java for instance, generics were made by one of the Haskell creators, and it has been implementing functional features for years now.

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

#336

Post by tanin »

snazz wrote: post #295
mruts wrote: post #282

Earlier quoted context omitted.

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.

Could you point to some specific examples?

Here was one example I encountered a while back: https://stackoverflow.com/questions/952914/how-to-make-a-fla...

In Python, it's `import itertools` and `list(itertools.chain.from_iterable(list2d))` or `[item for sublist in list2d for item in sublist]`. In Scala, it is `list2d.flatten`.

In fact, Python is against making a richer stdlib in general.

"It has been discussed ad nauseam on comp.lang.python. People seem to enjoy writing their own versions of flatten more than finding legitimate use cases that don't already have trivial solutions." from https://softwareengineering.stackexchange.com/questions/2542...

And, intuitively, when you don't want to provide a helper function, the user code gets longer.

Not that this is better or worse. It's just that, specifically, on the brevity aspect, Python code would generally becomes longer. Because, as you see in the quote, "People seem to enjoy writing their own versions of flatten".

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

#337

Post by pyrale »

garmaine wrote: post #151
tomasato wrote: post #103

Earlier quoted context omitted.

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.

Lens is far from being used by everyone in the space. On a sample of 5-6 professional users I talked with at this zurihac, most didn't use it.

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

#338

Post by tanin »

xenator wrote: post #326
tanin wrote: post #126

Earlier quoted context omitted.

I know. It's strange to say that. But Scala's library is very very rich. Another example is that Scala offers a lot of ways to process a list like foldLeft, foldRight, unzip, headOption, lastOption, flatMap, groupBy, and many methods around Map, Set, and etc. Python probably doesn't offer many of these methods. Of course, this comes with the cost of higher learning curve.

List of standard methods of this kind https://docs.python.org/3/library/itertools.html

Yes, itertools is great. But its stblib is still much lighter than Scala's and Ruby's.

Actually, that seems to be the direction/principle of Python, where it is less inclined to add a helper function.

"It has been discussed ad nauseam on comp.lang.python. People seem to enjoy writing their own versions of flatten more than finding legitimate use cases that don't already have trivial solutions." from https://softwareengineering.stackexchange.com/questions/2542...

Not that this is better or worse. It's just that, on the brevity aspect, Python code is gonna be longer.

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

#339

Post by kitd »

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

The traditional method of measuring code complexity is Cyclomatic Complexity [1] which, roughly speaking, measures the number of branch points in the code.

[1] https://en.wikipedia.org/wiki/Cyclomatic_complexity

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

#340

Post by anaphor »

willtim wrote: post #188
anaphor wrote: post #72

Earlier quoted context omitted.

The article says that the instructor for the course cautioned against using Haskell because some people overestimated their competency with it. I think it is actually very likely that people would chose a programming language or system for reasons other than how competent they are with it. E.g. to seem "smart" because you wrote your compiler in Haskell, even though you actually have much more experience with Java or…

Sounds like he (edit: or more accurately, the university) has hasn't taught them enough functional programming and Haskell.

It's my understanding that UW offers some undergrad courses in Racket, but apparently they're optional so if you hadn't taken that course you might not know much about functional programming.
Post reply on HN