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

241–250 of 384 posts

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

#241

Post by lelf »

objektif wrote: post #74
WalterBright wrote: post #50

Earlier quoted context omitted.

It's difficult to write a fair comparison without being a fairly competent programmer in each of the languages. The trouble is, if a person is an expert C programmer and then translates it to Python that he's only modestly familiar with, the Python program will look like C. It won't be idiomatic Python. For example, my early Fortran programs looked like Basic. My early C programs looked like Fortran. My early C++ pro…

How do you like D btw? Is it worth learning for a c++ programmer? I find the syntax very appealing.

I find compilation times very appealing.

D compiler can compile itself in under 5s (+ 10s for stdlib).

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

#242

Post by grumdan »

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.

Describing two well-engineered compilers of two relatively used languages as not impactful is quite a statement. In particular, given the good performance results they achieve, for languages that are quite far away from the normal execution model of the machine they produce code for.

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

#243

Post by lozenge »

hermitdev wrote: post #182
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…

Lately I've been doing a lot of greenfield development in Python, developing libs for in house use at my employer. We're using 3.7 currently, and I've fully embraced type hints. With proper type hints and use of pylint, you get the static checking that you'd otherwise miss. Bonus, if you're using an IDE like PyCharm, VS code or visual studio, you usually get the linting for free either as you type or on save.

Pylint is not designed to be a thorough type checker, you should take a look at mypy or pytype.

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

#244

Post by dymk »

sbergot wrote: post #231
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…

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

> 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 faced with C++ for the first time.

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

#245

Post by k_bx »

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…

I disagree about lens. My new projects don't use them in main code-base and it was a great decision:

- TAGS work like a charm to access field definitions

- compile times are ok

Of course, if library's API needs lens, they're used.

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

#246

Post by grumdan »

origin wrote: post #163
roca wrote: post #116

Earlier quoted context omitted.

No matter what, you need a rigorous schema for your data. If you write a complex JS/Python program without doing the equivalent of "come up with the right set of types" then you will have a bad time. I'm sure in the OP here the skilled Python programmer did think carefully about the shapes of her data, she just didn't write it down. To be sure, having to write down those data structure invariants in a rigorous way th…

It's also hard to massage your invariants into a form that a type checker will accept, since you're now restricted to weird, (usually) non-Turing-complete language. A good example of this is matrix operations - there are plenty of invariants and contracts to check (e.g. multiplication must be between m x n and n x p matrices), but I don't believe there's yet a particularly convincing Haskell matrix library, in part b…

This particular example can be encoded into the Haskell type system though. For example, there's a tensor library where all operations are (according to the description) checked for the correct dimensions by the type system. It seems to require a lot of type-level magic though, and that may disqualify it for "cleanly".

http://hackage.haskell.org/package/easytensor

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

#247

Post by jquery_dev »

edem wrote: post #240

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.

I very much disagree with your opinion. OP never tried to determine a winner, just wanted to share some insights into the project.

If we go by what you say, we would never have any comparisons at all, as there are always unknowns.

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

#248

Post by jodrellblank »

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…

When reading about APL recently, arcfide - the chap working on a GPU compiler - has expressed that he likes APL's terse code because you can throw it away and rewrite it without too much trouble. His compiler is around 750 lines of code after 6 years of development, but[1]:

"If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In that time I've added roughly 4,062,847 lines of code to the code base, and deleted roughly 3,753,677 line of code. [..] It means that for every one of those 750 lines, I've had to examine, rework, and reject around 5400 lines of code."

Yet a 750 loc codebase sounds like someone with very little experience and a few days or a long weekend.

I'm not saying only the trivial "some languages are denser than others", but also that it would be interesting to compare projects in total lines of code written including all commit history, and that it would be interesting to compare people's experiences and project designs in terms of "how many times something got implemented in several ways before settling on a final version", or "writing once and the design got set in concrete because it was too big to bother changing", how many prototypes that work differently were explored before deciding - and what that does to people's skills, and to project designs.

I'm guessing thousands of lines of F# would make you more skilled than the same thousands of lines of C#, even moreso if the F# was higher-abstraction than the C#, would you agree?

[1] - https://www.sacrideo.us/smaller-code-better-code/

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

#249

Post by fnord123 »

grumdan wrote: post #242
fnord123 wrote: post #225

Earlier quoted context omitted.

I think big here means impactful.

Describing two well-engineered compilers of two relatively used languages as not impactful is quite a statement. In particular, given the good performance results they achieve, for languages that are quite far away from the normal execution model of the machine they produce code for.

>two relatively used languages

Relative to what? Haskell and OCaml are important languages for PLT but not in the context of "production", or as I understood "production" to mean: shipping products with features. To call them anything but niche players in this context is not accurate in my opinion.

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

#250

Post by Avi-D-coder »

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…

Take a look at https://github.com/well-typed/optics.

It's like lens, but with the design goal of being easier to use and producing better error messages.

Post reply on HN