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

231–240 of 384 posts

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

#231

Post by sbergot »

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…

I didn't say Haskell's error messages are bad. If you stick with explicit types on your functions and no language extension they are absolutely great. I wanted to point out that type checking errors with lens are hard unless you really know how all the different type aliases relate to each other. It was a few years ago so maybe things are better.

C++ also had this problem with the standard containers. However it is much easier to get what is a dictionary compared to a random "optic".

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

#232

Post by StreamBright »

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…

Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.

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

#233

Post by StreamBright »

tigershark wrote: post #160
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…

There were people with 2k to 10k loc of experience in some language. That seems extremely low for any meaningful comparison and I would really hope that “average” programmers have way more experience than that... I think I was pretty junior after writing north of 100k loc and working on 1M loc projects. And for sure I don’t consider myself highly competent in F# after writing some thousands lines. I agree with the co…

Sure but 100k LOC Java is bot equal to 100k LOC Rust or Clojure because there is a huge discrepancy between expressiveness of those languages.

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

#235

Post by orbifold »

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…

That's a total stretch, lens is not used in GHC for example and lots of other smaller compilers written in Haskell. It is used in Ermine but that is stuck in a semi complete state for a while now and Ekmett has moved on.

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

#236

Post by dymk »

StreamBright wrote: post #232
dymk wrote: post #224

Earlier quoted context omitted.

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…

Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.

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.

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

#237

Post by garmaine »

aliceryhl wrote: post #228
garmaine wrote: post #151

Earlier quoted context omitted.

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.

Restrict the students from using a parser library. I get that. But allowing nothing except that standard library? That’s stupid.

It also makes the language comparison useless. Python has a standard library that is continuously improved and people reach to that when writing programs. Haskell, like C, ossified it’s standard library when it was created and people use the external packages for equivalent up to date libraries.

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

#238

Post by wokwokwok »

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.

Hm... well that might be true for extending, I'm not sure you've fully thought through that comment.

Duck types are great for writing new code, but they're very troublesome for refactoring; automated tools have a much harder time automating that process.

Refactoring data structures and implementations in static type systems is bother considerably easier to implement than in dynamic languages, and resultingly, more robust.

Certainly the refactoring tooling these days is pretty sophisticated with type inference, but... well, I've refactoring large python and javascript code bases, and my experience has been that absolutely a static type system makes that process easier, even if you have a comprehensive test suite.

I think it's worth acknowledging that there is a place for static type systems; certainly, it's not a silver bullet, and it results in (usually) a higher lines-of-code count, which is significant; but its naive and wrong to suggest that it has no value at all.

Specifically, for refactoring, it has a lot of value.

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

#239

Post by kreetx »

remify wrote: post #234
wjw94 wrote: post #201

My take-away from this article is that the university I graduated from was terrible

Same here ... I feel dumb now

Now you both have "all the disadvantages for success" - go and make good use of this! :p

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

#240

Post by edem »

These comparisons are actively harmful. What the OP is doing is the same as if you were trying to determine the winner of a race by looking at the competitors at the start. You don't know their speed, their strengths etc. You can't determine how maintainable the code you produce this way, how it performs under real world usage, etc. Please stop doing these.
Post reply on HN