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

81–90 of 384 posts

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

#81

Post by galaxyLogic »

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…

I have the same experience with Java. But I would have expected languages that have type-inference like Haskell, Scala and OCaml to do much better. But maybe their advanced features in fact make programs written in them harder to understand, which slows down development. Don't know.

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

#82

Post by zmmmmm »

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…

Seems like a bit of a bold claim when the author themselves directly contradicts that in their own conclusion:

> I think my overall takeaway is that design decisions make a much larger difference than the language

After all, Scala was 0.7x the size and is one of the most strongly statically typed languages. So you could almost invert your conclusion and say the big result is

"Python only saved 20% code lines over fully statically typed language"

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

#83

Post by zimablue »

I feel like what you're actually testing with this is "amongst the top percentile of programmers, what are the proclivities of people by choice of favourite language"

Because the implementations vary so much, that's the source of a lot of the LOC-difference. They effectively delivered more or less (if you count more stages as "more" which I would as it will make it easier to reason about/debug, and count a typesystem as "more", since it gives you more guarantees).

python - solves the problem brutally fast, some ugly shortcuts haskell - solves the problem quite slowly/delivered the most rust/c++ - intermediate scala - solved fast, took shortcuts ocaml - this is the one that surprised me I'd have expected it to be the shortest with python

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

#84

Post by geofft »

hart_russell wrote: post #48
ufmace wrote: post #9

I haven't made it through the whole thing yet, but I do want to register a vote in favor of using Lines Of Code count as a rough measure of program complexity. I think it's a perfectly valid things to do, provided that it isn't used as an evaluation metric and nobody is gaming it, and everyone is a reasonably good programmer, not doing crazy things like trying to stuff a massive algorithm onto one line to be clever,…

I'd like to hear others' opinions: There's a guy at my work who loves to use doubly, triply, quadruple-ly nested ternary operators. I always find them super hard to read. Am I just a dunce, or do I have a point in thinking it's unnecessarily terse.

I'd encourage your coworker to use a language where if/else is an expression and not a statement. :) Of the languages mentioned in the article, Rust, Haskell, Scala, and OCaml all have this as the only form of if/else: you can write something like x = if foo then bar else baz, so you can nest them with some parentheses for readability. Python's if/else is a statement, but it has a slightly different syntax for the if/else as an expression - bar if foo else baz - which is a little less readable but still workable.

It's only the Algol-syntax-family languages (C, C++, Java, JavaScript, etc.) that have the inscrutable ternary operator and if/else as a statement.

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

#85

Post by geofft »

dbpatterson wrote: post #77
saagarjha wrote: post #31

Earlier quoted context omitted.

> 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?

I mean, if you design an esolang for the competition task and implement an optimizing compiler that's faster than any general purpose language out there, that absolutely feels like something that should be rewarded by the spirit of the competition! So it's okay that it's allowed by the letter of the competition, too.

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

#86

Post by mhh__ »

FullyFunctional wrote: post #56

That was a really interesting article. I completely agree with >>> Abstractions may make things easier to extend in the future, or guard against certain types of errors, but they need to be considered against the fact that you may end up with 3 times the amount of code to understand and refactor, 3 times the amount of possible locations for bugs and less time left to spend on testing and further development. Choosing…

I think thinking carefully about the abstractions is also key, ideally not while at the computer. Good abstractions should be obvious and not really requiring refactoring as per se.

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

#87

Post by tanin »

The Scala result confirms my bias :P I love Scala because it strikes a great balance between being succinct and offering type safety.

I wish you would use Ruby instead of Python. Python is strangely inconsistent. For example, Python doesn't really offer a rich standard library; people have to resort to ugly solutions for a simple problem (here's an example: https://stackoverflow.com/questions/363944/python-idiom-to-r...)

Ruby would be better at an example of how a dynamic language can be more succinct.

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

#88

Post by tanin »

zmmmmm wrote: post #82
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…

Seems like a bit of a bold claim when the author themselves directly contradicts that in their own conclusion: > I think my overall takeaway is that design decisions make a much larger difference than the language After all, Scala was 0.7x the size and is one of the most strongly statically typed languages. So you could almost invert your conclusion and say the big result is "Python only saved 20% code lines over ful…

One factor on why Python only saves 20%.

Scala has a very rich standard library. Python doesn't. An example is: https://stackoverflow.com/questions/363944/python-idiom-to-r...

Ruby would have been a better example of how succinct a dynamic-typed language can be.

(I made a similar comment on the parent level.)

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

#89

Post by mhh__ »

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.

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: The Pegged library for D can generate a parser, D code which gets compiled, directly from a grammar specification in a text file [inside a D program, e.g. mixin(Grammar("Your Grammar Here"))]

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

#90

Post by trishume »

geofft wrote: post #79
trishume wrote: post #61

Earlier quoted context omitted.

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.

No I don't know how fast her compiler was. This also isn't a good setup for comparing language performance, since all the test programs were small and there was no incentive to make your compiler fast. Many groups probably used O(n^2) algorithms in their compiler and differences in algorithm choice would probably add too much noise to get a good performance signal.

That aside, speaking off the cuff totally separately from my post, I'm extremely dissatisfied with the performance of current compilers. The fastest compilers written by performance-oriented programmers can be way faster than ones you generally encounter. See luajit and Jonathan Blow's 50k+ loc/second compilers and the kind of things they do for performance. One example of a compiler task it's really difficult to do quickly in a language like Python/Ruby is non-regex parsing, I've written recursive descent parsers in Ruby and compiled languages and the Ruby ones were 1-2 orders of magnitude slower, non-JIT dynamic languages are really bad at tight loops like that.

Post reply on HN