Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml • Hacker News Board

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

#71

Post by mpoteat » Sun, Jun 16, 2019, 1:20 AM UTC

dmurray wrote: post #70

galaxyLogic wrote: post #57

I think the big big result from this study is: "Python: half the size !". A dynamic language like Python is better here, 2x better. I assume similar results would apply to other dynamic languages like JavaScript, Lisp, Smalltalk, Groovy etc. This does not say that static typing should not be used but I think it shows unequivocally that there is a considerable extra development cost associated with static typing. You…

> I think the big big result from this study is: "Python: half the size !". > A dynamic language like Python is better here, 2x better. I was surprised by how small the LOC benefit was from using the dynamic languages. As someone who typically reaches for Python, I'd use a statically typed language (Go or Java, most likely) much more often if I expected only twice as many lines of code. In practice I feel the same pr…

The Python developer also added a lot of extra features. A MVP might be half again the size.

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

#72

Post by anaphor » Sun, Jun 16, 2019, 1:22 AM UTC

galaxyLogic wrote: post #64

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…

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…

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 Python.

FTA:

> Another interesting thing to note is that at the start of every offering of the course the professor says that students can use any language that can run on the school servers, but issues a warning that teams using Haskell have the highest variance in mark of any language, with many teams using Haskell overestimating their ability and crashing and burning then getting a terrible mark, more than any other language, while some Haskell teams do quite well and get perfect like my friends.

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

#73

Post by trishume » Sun, Jun 16, 2019, 1:25 AM UTC

mpoteat wrote: post #71

dmurray wrote: post #70

Earlier quoted context omitted.

> I think the big big result from this study is: "Python: half the size !". > A dynamic language like Python is better here, 2x better. I was surprised by how small the LOC benefit was from using the dynamic languages. As someone who typically reaches for Python, I'd use a statically typed language (Go or Java, most likely) much more often if I expected only twice as many lines of code. In practice I feel the same pr…

The Python developer also added a lot of extra features. A MVP might be half again the size.

Note my half the size estimate was after estimating the amount of code dedicated to extra features. The raw line count is only 0.7x the size of our non-test line count. Although my estimate of how many lines it would have taken without the extra features has very wide error bars.

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

#74

Post by objektif » Sun, Jun 16, 2019, 1:25 AM UTC

WalterBright wrote: post #50

bfung wrote: post #37

Excellently written, great topic, and done w/o flaming/too much bias. I'm amazed as many older folks in the industry would not be able to have this level of content and maturity to write an informative article.

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.

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

#75

Post by galaxyLogic » Sun, Jun 16, 2019, 1:26 AM UTC

trishume wrote: post #61

galaxyLogic wrote: post #57

I think the big big result from this study is: "Python: half the size !". A dynamic language like Python is better here, 2x better. I assume similar results would apply to other dynamic languages like JavaScript, Lisp, Smalltalk, Groovy etc. This does not say that static typing should not be used but I think it shows unequivocally that there is a considerable extra development cost associated with static typing. You…

I agree it's definitely an interesting result and a point in favour of dynamic languages. A caveat is that I'm pretty sure my friend intentionally sacrificed code quality to do it, I don't think you'd find that project as readable and understandable as the others. Another caveat is that you have to be okay with your codebase being extremely magical and metaprogramming-heavy, which many industrial users of dynamic lan…

I've read my share of cryptic JavaScript written by others and in that sense I agree that in multi-person long-term projects static typing no doubt will have its advantages.

My hunch is however that what is often overlooked in development with statically typed languages is that it takes considerable time and effort to come up with the right set of types. Many examples are written showing how types almost magically make programs easier to understand. But when you read such an example what is not stated is how much effort it took to come up with just those types.

One way of thinking about it is that type-definitions are really a "second program" you must write. They check upon the primary program and validate it. But that means you must write that second program as well. It's like building an unsinkable ship with two hulls one inside the other. The quality will be great but it does cost more.

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

#76

Post by [deleted] » Sun, Jun 16, 2019, 1:27 AM UTC

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.

[deleted]

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

#77

Post by dbpatterson » Sun, Jun 16, 2019, 1:28 AM UTC

saagarjha wrote: post #31

awwaiid wrote: post #22

If you're into this sort of thing, definitely check out the ICFP Programming Contest -- take next Friday off and join in on the fun! https://icfpcontest2019.github.io/

> Any programming language(s) on any platform(s) may be used. How does this work? What’s stopping me from using some hyperpowered esolang I cooked up for the competition?

That the task description is only posted at the start of the competition?

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

#78

Post by trishume » Sun, Jun 16, 2019, 1:30 AM UTC

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.

Fun fact the person you're replying to is the creator of D, I'm pretty sure he likes it. I've personally played around with D a bit and written maybe 1kloc in it and I like it.

It doesn't have good pattern matching or the borrow checker, but it does have much better metaprogramming than Rust. I think a lot of the metaprogramming used in the Python project could also be done basically as easily in D, which is a big accomplishment.

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

#79

Post by geofft » Sun, Jun 16, 2019, 1:31 AM UTC

trishume wrote: post #61

galaxyLogic wrote: post #57

I think the big big result from this study is: "Python: half the size !". A dynamic language like Python is better here, 2x better. I assume similar results would apply to other dynamic languages like JavaScript, Lisp, Smalltalk, Groovy etc. This does not say that static typing should not be used but I think it shows unequivocally that there is a considerable extra development cost associated with static typing. You…

I agree it's definitely an interesting result and a point in favour of dynamic languages. A caveat is that I'm pretty sure my friend intentionally sacrificed code quality to do it, I don't think you'd find that project as readable and understandable as the others. Another caveat is that you have to be okay with your codebase being extremely magical and metaprogramming-heavy, which many industrial users of dynamic lan…

Tangentially - do you know how fast her compiler was compared to the compiled-language implementations? I have a vague sense that for many applications, interpreted languages are totally fine and reaching for a compiled language is premature optimization, but I'm curious how it actually holds up for a compiler, which is more computationally heavy than your average web app or CLI.

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

#80

Post by aetherspawn » Sun, Jun 16, 2019, 1:31 AM UTC

nautilus12 wrote: post #41

I can hear all the Haskell fanboys screaming that they didn't do Haskell right because a kleisli arrow didn't appear and ascend them into monadic heaven.

To be fair, I don’t think any Haskeller would actually write this project without attoparsec and maybe lens by choice. They’re basically base libraries for this sort of thing.