Live data from Hacker News

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

thume.ca

211–220 of 384 posts

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

#211

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

Your wish can come true. Take a look at this stage 1 of the TC39 proposal. https://github.com/tc39/proposal-do-expressions

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

#213
post #7

I really wish when counting code that people would use one of the more modern code counters, or at least use cloc. Tokei, loc, scc, polyglot, loccount or gocloc give a much better idea over wc because they account for comments and blank lines and in the case of scc and tokei strings. I had a similar experience in university. Class had to implement a modified Turing machine. We could use whatever language we wanted. O…

> I really wish when counting code that people would use one of the more modern code counters, or at least use cloc. Tokei, loc, scc, polyglot, loccount or gocloc give a much better idea over wc because they account for comments and blank lines and in the case of scc and tokei strings.

And even that only tells some of the story e.g. do code counters count separators ({ or } alone on a line) as blank or as code? Are multiline strings (e.g. python docstrings) counted as code or comments?

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

#214
post #198
post #96

Earlier quoted context omitted.

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;

I like those, but they do need to be properly formatted and only "tail-nested".

I also tend to format them thus:

    int a = b == 1 ? 2
          : b == 2 ? 3
          : b == 3 ? 5
          : -1;
Feels much more "case analysis-y" and clearer.

Still, a language having proper support for expressive conditionals is probably better.

Also the way Python's ternary was defined means it should never ever be nested, it looks nasty.

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

#215
post #32

Earlier quoted context omitted.

Sure, and you can put the else on the same line as the end of the if block even without doing that. Or you could make the difference bigger by putting the opening brace on a newline. I wrote the style of C that I actually write, but it's probably not fair for me to label it as a property of just the language.

I think it’s a fair point to bring up given that many people actually do write their code that way.

Or even use allman / gnu where opening braces are also on their own line.

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

#216
post #35

I find it curious that both the team that used C++, and the author, both appear to believe that sum types and related facilities are not usable or conveniently expressible in C++. I got that Boost Spirit, a powerful parsing library, was forbidden. Were all the Boost libraries similarly embargoed?

> Boost Spirit, a powerful parsing library I regularly use Boost Spirit as an example of "sounds good but actually a nightmare", and am always surprised to see it mentioned in the wild. It is truly a modern horror. Boost is like Apache -- a collection of libraries of various quality and stage of development, not all alike. A lot of stuff in there is designed to prove out experimental language features ahead of the ne…

> I regularly use Boost Spirit as an example of "sounds good but actually a nightmare", and am always surprised to see it mentioned in the wild. It is truly a modern horror.

huh, I have written a few parsers (half a dozen maybe ?) with spirit and absolutely don't regret it - why would you say that ?

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

#217

Earlier quoted context omitted.

I think it’s a fair point to bring up given that many people actually do write their code that way.

Or even use allman / gnu where opening braces are also on their own line.

Yes, but those people clearly have issues ;)

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

#218
post #154
post #139

Earlier quoted context omitted.

Sounds like you just don't like Python, but you don't have great reasons for not liking it. The standard library is fantastic in Python. Find better reasons to back up your unfounded dislike.

Saying Ruby/Scala have richer standard lib than Python isn't really a stab at Python. Like dragonwriter says, it shows that "Python expresses the concept fairly compactly in the core language without even resorting to stdlib". It depends on your taste whether you like richer stdlib, and I do. But some don't. We are talking about how short the code can be in this post, and `my_list[0] if my_list else None` (Python) is…

I think there are just a lot of people here getting touchy and defensive because other people aren't automatically leaping to false conclusions from this article's data, preferring to imagine that the article validates their personal choice of favourite programming language rather than engage in proper speculation about the quality of the conclusions made within the article.

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

#219
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…

"python doesnt offer a rich standard library" Python is usually considered one of the richest standard libraries out there. Yes, the is no standard way to get this one edgecase, but every language has warts and things like that. It sounds like you are just looking for an excuse to hate on Python.

> It sounds like you are just looking for an excuse to hate on Python.

That's a big claim to make based on a couple of assertions that are neither about the quality of Python as a language nor the quality of its standard library, merely observations and comparisons.

Are you sure it's not you who is upset to see Python 'attacked' (for lack of a better term) in any way?

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

#220

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 proof of concept for a future programming language based around it.

If I were to start a project with Haskell the use of lens would be explicitly forbidden.

Post reply on HN