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

321–330 of 384 posts

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

#321

Post by gricjeh »

celrod wrote: post #300
azov wrote: post #283

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…

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.

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

#322

Post by carapace »

Ooo lolly! I want to do this in Prolog!

The bit about "no parsing helpers even if they’re in the standard library" makes me wonder about using DCGs, but if disallowed re-implementation would be straightforward and add only a small constant to the code volume.

I would like to see metrics on speed of compilation and size of resulting asm.

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

#323

Post by foldr »

_fq4v wrote: post #318
foldr wrote: post #314

Earlier quoted context omitted.

Yeah, so it's a less good way of accessing record fields than the one present in 99% of other programming languages. Your own description makes this plain. Let's compare to Javascript: * I don't need to import a module to make available the syntax for getting and setting fields of an object. * I can use the same syntax for any object, and don't have to worry about doing a bunch of code generation via a badly-designed…

Record types are not a solution to the problem lens solves. Lens is a good library and a good concept. If we spent some time on it in programming class, most people would get it. When moving to non-Haskell languages, the lack of proper lenses is something I notice almost immediately.

I know what the lens library does - I write Haskell for my day job.

In practice, the main reason people use it is to work around the deficiencies of Haskell's built-in record system:

>I never built fclabels because I wanted people to use my software (maybe just a bit), but I wanted a nice solution for Haskell’s non-composable record labels.(http://fvisser.nl/post/2013/okt/11/why-i-dont-like-the-lens-...)

The other features of lenses don't strike me as particularly useful. YMMV. I'd also question the quality of the library. It's full of junk like e.g. http://hackage.haskell.org/package/lens-4.17.1/docs/src/Cont..., which is just an invitation to write unreadable code.

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

#324

Post by tanin »

galaxyLogic wrote: post #310
zapzupnz wrote: post #218

Earlier quoted context omitted.

I think there are just a lot of people here getting touchy and defensive because other people aren't automatically leaping to false conclusions from this article's data, preferring to imagine that the article validates their personal choice of favourite programming language rather than engage in proper speculation about the quality of the conclusions made within the article.

I would agree that the sample size was small so programmer competency may be a big factor. The interesting takeaway from this study I think is that it does not show that statically typed (even "pure") functional languages are not obviously better than plain old Python. The interesting thing is not what this study proves, but what it does not prove.

> The interesting takeaway from this study I think is that it does not show that statically typed (even "pure") functional languages are not obviously better than plain old Python.

Could you elaborate more on this statement? Not a native english speaker here, so I don't quite understand the sentence. Thank you.

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

#325

Post by dymk »

smallnamespace wrote: post #312
dymk wrote: post #244

Earlier quoted context omitted.

> However it is much easier to get what is a dictionary compared to a random "optic". This is exactly what I disagree with. We come from a prior understanding of mutable/imperative dictionary/shared_ptr/std::pair, because that's what we started out with. Had we been initially been trained on monads, functors, lenses, those would be the familiar tools, and we'd go "Huh, that's an... interesting way to write code" when…

> because that's what we started out with Yes, but not from programming, but from general life experience. Everyone knows what an actual dictionary is, and even non-programmers can easily grasp how a one-way 'map' works. Mutation is also how the real world works. If you want to record something, you write it down—you've just mutated the world, not encapsulated your operation in the WorldState monad. You need to build…

Haskell has maps.

You 100% do not need to build a "pile of mathematical abstractions in your head" to use lenses. It's a handful of types and functions. Do you need to build a pile of abstractions in your head to use `std::unordered_map` or getters/setters in C++?

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

#326

Post by xenator »

tanin wrote: post #126
saagarjha wrote: post #100

Earlier quoted context omitted.

> Scala has a very rich standard library. Python doesn't. This is not something I could have expected someone to say about Python's standard library…

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

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

#327

Post by fluffything »

dymk wrote: post #224
sbergot wrote: post #220

Earlier quoted context omitted.

This is why I gave up on Haskell. Lens works as advertised, but is a pain to learn and to use in practice: the abstraction is tough to grasp and it is hard to form an intuition about it. The compilation errors are laughingly esoteric. The number of adhoc squwiggly operators is ridiculous. You also need to understand a lot of language extensions to get how the type checking works. To me it looks like an impressive pro…

It's about as esoteric as somebody learning C++ for the first time. And from that perspective, it's totally normal for errors or syntax to be weird looking for a long time. Most of us, including myself, are biased towards languages like Java, C, C++, Javascript, because those are what we learn first - and so our expectations of what errors (or syntax) look like are shaped by our early experiences. So I don't think it…

> And from that perspective, it's totally normal for errors or syntax to be weird looking for a long time.

This isn't normal. This is just using a tool that sucks. Those who consider this normal are just masochists.

Rust, elm, etc. have great error messages. That took a lot of time and effort to achieve. The fact that it is impossible to implement a C++ compiler that produces good error message is just proof about how broken the language is. The fact that some people find this normal is just Stockholm syndrom at work.

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

#328

Post by zodiac »

mruts wrote: post #313
snazz wrote: post #295

Earlier quoted context omitted.

Could you point to some specific examples?

Python has Lists (arrays), Dict, and Sets. That's pretty much it. There's no linked lists. There's no sorted maps, no sorted sets, no maps that preserve insertion order, no queues, no priority queues, no bitsets. And there's no immutable collection in Python besides strings. Meanwhile, Scala has all of that and more: https://docs.scala-lang.org/overviews/collections/overview.h... Moreover, scala has synchronized coll…

> And there's no immutable collection in Python besides strings

frozensets, tuples?

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

#330

Post by fmap »

liquidify wrote: post #291
dymk wrote: post #236

Earlier quoted context omitted.

You say "not at all", but only cite Rust (which I didn't mention). C++ has horiffic error messages, certainly at the level of a bad Haskell error message. I'd say my point stands pretty well.

I don't think C++ errors are bad any more. 2019 compilers generally produce very good error messages. The situations where you get into pages of template nonsense in an error are becoming fewer and further between all the time.

C++ has bad error messages because of language design. Contemporary C++ compilers are very good at reporting clear error messages about common mistakes, but template heavy code still yields arcane error messages. Templates are untyped, so there is no way to give sensible error messages when defining or instantiating a template. Instead you have to typecheck after template expansion, at which point you are left with an error message about compiler generated code.

There are some proposals which address this (e.g., concepts), but none of them are part of the language standard yet. Concepts in particular made it into the C++20 draft, but they also made it into a draft of the C++17 standard and were ultimately rejected. Somewhat vexingly C++ concepts actually come with the same problems only at the level of concepts instead of at the level of templates.

Post reply on HN