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

221–230 of 384 posts

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

#221

Post by jlg23 »

danmaz74 wrote: post #210
massung wrote: post #132

Earlier quoted context omitted.

I enjoy hacking in dynamic languages as much as the next programmer. But, the big take-away is that "the initial implementation was done in 1/2 the code" not that the resulting code was more extensible or maintainable (by other programmers!). > You might say that surely that additional cost would be compensated in reducing the cost of maintenance later. Maybe but I'm not sure. I am sure. 100%. From many years of expe…

When thinking about extending and refactoring, you also need to keep in mind that static types add a whole layer which is pretty hard to change. There are advantages and disadvantages, having at static types isn't such a silver bullet.

The solutions to these problems in "extending and refactoring" are the same in dynamically and statically typed languages because in both you have to make sure functions/methods get the correctly typed input and return some expected type as output. In both worlds you will either refactor everything, abstract the problem away with interfaces or union types or you'll do type conversions at the boundaries of the code you touch.

That layer is there anyway, except for your interpreter of a dynamic language only knows about problems at run-time, while the compiler that checks a static type system will tell you at compile-time.

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

#222

Post by danielscrubs »

nybble41 wrote: post #159
galaxyLogic wrote: post #64

Earlier quoted context omitted.

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

I thought it very amusing that the teams focus would reflect the language: The Python implementation was as you say quick-and-dirty, while the Haskell one "caught a few edge cases that our team did not" and the C++-team did "optimizations on their IR".

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

#223

Post by julvo »

I like the idea of using this project to compare languages.

However, to me it seems the comparison is more of a comparison between specific implementations rather than languages. The high variance in LOC between the two rust implementations makes me wonder if there's a similar variance for other languages and the samples we have lie somewhere between e.g. 0.5 and 2 times the average size for a given language.

Therefore, the python implementation could just be a really compact one, even when compared to other python implementations. It could be interesting to ask the Professor if he'd be willing to collect some stats over the years.

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

#224

Post by dymk »

sbergot wrote: post #220
Avi-D-coder wrote: post #202

Haskell without lens, text, vector, etc... is a bit like rust with only core not std. The haskell standard library is tiny. Libraries like lens are not optional. In practice you won't understand any open source Haskell without rudimentary understanding of lens. I get why parser libraries were banned, but excluding lens, vector, and text? I like Rust a lot, but haskell minus it's more advanced type system is just Rust…

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's fair to say that Haskell's compiler errors or quirks are fundamentally less intuitive than something that GCC/G++ spits out even on a sunny day. Just odd when we expect errors to look a particular way, but Haskell is playing a totally different (not exactly harder) game.

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

#225

Post by fnord123 »

nybble41 wrote: post #149
steveklabnik wrote: post #144

Earlier quoted context omitted.

Two counterexamples does not disprove “a norm”. There are always exceptions!

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.

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

#226

Post by Lorkki »

danmaz74 wrote: post #210
massung wrote: post #132

Earlier quoted context omitted.

I enjoy hacking in dynamic languages as much as the next programmer. But, the big take-away is that "the initial implementation was done in 1/2 the code" not that the resulting code was more extensible or maintainable (by other programmers!). > You might say that surely that additional cost would be compensated in reducing the cost of maintenance later. Maybe but I'm not sure. I am sure. 100%. From many years of expe…

When thinking about extending and refactoring, you also need to keep in mind that static types add a whole layer which is pretty hard to change. There are advantages and disadvantages, having at static types isn't such a silver bullet.

So do all the implicit assumptions in duck-typed code, but following them relies fully on the programmer's own caution.

You can of course add explicit checks and tests, eventually paying the same amount (or more) in LOC as the typed implementation's initial cost, but then you're also tasked to keep those up to date, without the compiler's aid.

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

#228

Post by aliceryhl »

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.

I mean, it seems like it was an university course, and writing a compiler from scratch is probably a decent exercise in a compiler course.

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

#229

Post by posterboy »

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…

We learn those first, that are not developed as a research platform that happens to have a little production use.

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

#230

Post by mhh__ »

WalterBright wrote: post #172
mhh__ wrote: post #89

Earlier quoted context omitted.

Walter Bright is (along with Andrei Alexandrescu - which should be a good enough reason if you like c++) the BDFL of D. D won't get you hired (probably), but D is designed with hindsight from a C++ compiler writer and a C++ template wizard: It shows, D is objectively better than C++ is many ways. It's worth checking out, at the very least (It's also not hard to learn, so I say go for it) An example of the power of D:…

> D won't get you hired (probably) On the contrary. Many members of the D community have managed to leverage their D expertise into well-paying jobs. Many industrial D users recruit from the D community.

Not me though!

I was aware of that but I meant in comparison to (say) Java or JavaScript etc.

Post reply on HN