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

161–170 of 384 posts

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

#161

Post by tigershark »

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…

This comparison doesn’t tell absolutely nothing about the strength and weaknesses of dynamic types languages vs static types languages in real world projects. Obviously dynamic languages are better for toy projects. If for you 4-5k loc is a project of “significant size” then we must have pretty different points of view.

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

#162

Post by Matthias247 »

chenglou wrote: post #115

Hey trishume! It’s been a while (this is the Reason person). Great post; it echoes all the experiences I/we’ve personally had, especially the alternative Rust section: on the spectrum of how much intelligence one needs to understand fancy abstractions, all of us programmers, good and bad, are pretty much lumped to the lower end. I’ve seen plenty of skilled folks “decompensate” their expertise by reaching for overly c…

> In the same vein of idea, it’d be interesting to know how Go would fare in this project.

I would say a bit worse than the mentioned alternatives, which all have better type systems and thereby e.g. make it easier represent and manipulate the trees that are everywhere in compilers. But most likely it's still fine, and the line count metric would be more influenced by the fact how experienced the author is than the language.

Things will get worse in Go if one wants not write a lexer/parser manually but use tooling for that. Parser combinators and other tools benefit a lot from generics.

On the other hand e.g. writing a network server with decent performance will be in Go a lot easier and more straightforward than in any of the other mentioned languages. While all those languages are general purpose programming languages they definitely have their strengths in different areas. Some are better for some tasks (e.g. compilers), other are better for others.

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

#163

Post by origin »

roca wrote: post #116
galaxyLogic wrote: post #75

Earlier quoted context omitted.

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

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 because the range of relevant mathematical invariants don't cleanly fit into Haskell's type system.

For those cases, checking the invariants at runtime is your escape hatch to utilize the full expressive power of the language.

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

#164

Post by datashaman »

jancsika wrote: post #94
WalterBright wrote: post #49

Earlier quoted context omitted.

A typical translation of C++ code into D reduces the line count by a substantial amount, simply because D doesn't require .h files.

What are relative compile times like? Building Chromium atm, and to be honest I'd be happy if it were written in a trillion lines of BASIC if that would somehow achieve even a 10x build time speedup.

I assume you are using ccache?

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

#165

Post by tigershark »

galaxyLogic wrote: post #81
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…

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.

I don’t think that you can consider people with 2k locs of experience in Haskell highly competent in that language.

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

#167

Post by cozzyd »

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.

Just wait until you learn about PHP's ternary operator.

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

#168

Post by wvenable »

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.

Nope, even code with doubly, triply, or quadruple-ly nested if statements is typically hard to read. I usually refactor that down to avoid that level of nesting.

I don't think there's ever a good excuse for that much nesting of ternary operators.

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

#169

Post by galaxyLogic »

roca wrote: post #116
galaxyLogic wrote: post #75

Earlier quoted context omitted.

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

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…

> But the hard part really is coming up with the invariants,

Surely. But if you have to write them down it becomes hard to change them because then you will have to rewrite them, and you may need to do that many times if your initial invariants are not the final correct ones.

The initial ones are likely not to be the final correct ones because as you say coming up with the invariants is ... the hard part.

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

#170

Post by chenglou »

Matthias247 wrote: post #162
chenglou wrote: post #115

Hey trishume! It’s been a while (this is the Reason person). Great post; it echoes all the experiences I/we’ve personally had, especially the alternative Rust section: on the spectrum of how much intelligence one needs to understand fancy abstractions, all of us programmers, good and bad, are pretty much lumped to the lower end. I’ve seen plenty of skilled folks “decompensate” their expertise by reaching for overly c…

> In the same vein of idea, it’d be interesting to know how Go would fare in this project. I would say a bit worse than the mentioned alternatives, which all have better type systems and thereby e.g. make it easier represent and manipulate the trees that are everywhere in compilers. But most likely it's still fine, and the line count metric would be more influenced by the fact how experienced the author is than the l…

I’m familiar with these positions (static types, ADT, parsing, etc). But my comment on “less surprising” was meant for Python; it turned out that you can get pretty far with it with no static types nor ADT. So it’s very possible that Go can fare not too badly. The reason why I wondered about Go is because I’ve seen several HN posts about using Go for writing parsers/compilers with surprisingly ok result.

(I don’t advocate dropping static types or ADT; just that in the spirit of this blog post, it might be worthwhile to examining our assumptions.)

Post reply on HN