Live data from Hacker News

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

thume.ca

191–200 of 384 posts

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

#191

Earlier quoted context omitted.

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.

Usually it's awful. I wish JavaScript had if else expressions. Sometimes it can help to break up the lines with indents if you need a single expression: var myvar = foo

I settled on this a while ago which I think is perfectly readable:

    const myvar
      = foo 

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

#192
post #92

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…

The takeaway for me was: "The next comparison was my friend who did a compiler on her own in Python and used less than half the code we did because of the power of metaprogramming and dynamic types." So it's the output of ONE Python programmer vs teams of other languages programmers?

It was also stated, though, that the reason she worked on her own was that she was a very good programmer; presumably, better than a lot of the people who worked in groups. And, as the sibling mentions, teams introduce overhead.

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

#193
post #11

> I think the smaller differences are also large enough to rule out extraordinary claims, like the ones I’ve read that say writing a compiler in Haskell takes less than half the code of C++ by virtue of the language Specifically the "by virtue of the language" part: Seems to me like it's unreasonable to claim the languages are on equal footing because fancy parser libraries aren't allowed to be used for the project.…

My understanding is that in production compilers, hand rolled parsers are the norm. Parsing libraries are cool, but just aren’t used for big projects.

It depends entirely on whether the big project still has an elegant and complete formal grammar. Hand-rolled parsers are only common in industrial languages because many have grown to be far too complex and ad-hoc, requiring e.g. additional analysis and disambiguation during parsing. It is not a situation to aspire to.

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

#194

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've written a Pratt (TDOP) parser in Go and I thought it was a great experience. Only thing I wished was done for me by the language was that it would tell me the byte position of the cursor in a file stream.

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

#195
post #72

Earlier quoted context omitted.

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…

Sounds like he (edit: or more accurately, the university) has hasn't taught them enough functional programming and Haskell.

He teaches compilers. Not programming or fp, so definitely not the professors fault

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

#197

Earlier quoted context omitted.

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.

Usually it's awful. I wish JavaScript had if else expressions. Sometimes it can help to break up the lines with indents if you need a single expression: var myvar = foo

I would format that as either:

  var myvar =
    foo 
or:

  var myvar =
     foo 

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

#198
post #96

Earlier quoted context omitted.

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.

Ternary operators can be fine. Nested ternary operators are hardly ever a good idea. One thing that people writing this sort of code seem to miss is that it's not just about expressing the code as concisely as possible - other people including oneself in future need to be able to read it easily. What I would recommend in a code review for anyone using nested ternary operators is just to break them up using meaningful…

Nested ternary operators are hardly ever a good idea.

Would using ternary operators as a terser switch statement be fine?

  int a =
    b == 1 ? 2 :
    b == 2 ? 3 :
    b == 3 ? 5 :
    -1;

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

#199
post #87

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…

Your linked stackoverflow question - how do you return the first item of the list or None.

Proposed solution - `a[0] if a else None`

Your reaction - Python doesn't offer a rich standard library.

I disagree, and I suspect most programmers would too. We'd much rather have ergonomic libraries to make http requests, parse command line arguments, datetime, itertools, data structures like heaps, filesystem access, data archiving, data serialization and deserialization and a million other nice-to-haves. It's actually at the point where I've heard criticism of Python's stdlib doing too many things, rather than too few.

If you don't want to write 19 characters to find the first item in a list, pick another language. But don't mischaracterise python's standard library.

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

#200

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…

Less code doesn't imply lower quality code. A more expressive language + less boilerplate allow you to write high quality, readable code with fewer lines.
Post reply on HN