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

291–300 of 384 posts

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

#291

Post by liquidify »

dymk wrote: post #236
StreamBright wrote: post #232

Earlier quoted context omitted.

Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.

You say "not at all", but only cite Rust (which I didn't mention). C++ has horiffic error messages, certainly at the level of a bad Haskell error message. I'd say my point stands pretty well.

I don't think C++ errors are bad any more. 2019 compilers generally produce very good error messages. The situations where you get into pages of template nonsense in an error are becoming fewer and further between all the time.

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

#292

Post by ufmace »

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.

IMO, that's awful and should never, ever be done.

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

#293

Post by StreamBright »

pjmlp wrote: post #255
StreamBright wrote: post #233

Earlier quoted context omitted.

Sure but 100k LOC Java is bot equal to 100k LOC Rust or Clojure because there is a huge discrepancy between expressiveness of those languages.

It also depends if one is using Java 12 or Java 1.4 programming style.

Exactly. Even within the same lang, it does not work.

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

#294

Post by StreamBright »

dymk wrote: post #236
StreamBright wrote: post #232

Earlier quoted context omitted.

Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.

You say "not at all", but only cite Rust (which I didn't mention). C++ has horiffic error messages, certainly at the level of a bad Haskell error message. I'd say my point stands pretty well.

You are predicating something on your experience with C++. I am saying it does not apply to other languages.

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

#295

Post by snazz »

mruts wrote: post #282
nindalf wrote: post #199

Earlier quoted context omitted.

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

I have also found Python’s stdlib to be laughably bad. Just compare the data structures available to Scala. I write Python everyday and honestly, it’s a chore. The language is primitive and inexpressive. The sad part is that it totally didn’t have to be this way. But instead of evolving, Python is just stuck in the past.

Could you point to some specific examples?

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

#296

Post by pincus »

geofft wrote: post #84
hart_russell wrote: post #48

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.

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…

Algol family syntax is not the same as C syntax. Algol 60 has if-then-else as an expression like "x := if foo then bar else baz". In Algol 68, an ENCLOSED-clause like if-then-else-fi is a PRIMARY, so it can be used anywhere other primaries like identifiers and denotations (literal constants) can be used. "Begin" and "end" are synonyms for ( and ). Both languages are defined on the level of symbols instead of bytes or characters. These symbols can have multiple representations including punctuation and text in non-English languages like Russian. A lot of people today don't know what Algol family syntax looks like which is a real shame because they're very clean and elegant languages.

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

#297

Post by mlthoughts2018 »

fmap wrote: post #274
foldr wrote: post #267

Earlier quoted context omitted.

Lenses don't really give you anything that you can't get from (a) a sensible syntax for record updates and (b) intrusive pointers. Lenses only exist because of Haskell 98's uniquely bad support for record types. Record access and update in most other languages just is simpler.

Lenses are more than reified record labels though. There is a hierarchy of concepts that can be freely composed based on which features your data structure actually supports. In particular, lenses can be composed with traversals ("lenses" pointing at multiple fields) yielding "LINQ" like features without introducing new syntax or concepts. The main problem with lenses is that common lens libraries look extremely comp…

fmap replying to foldr in a subjective argument about functional lenses... what have I done to deserve this hell.

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

#298

Post by mlthoughts2018 »

sbergot wrote: post #220
Avi-D-coder wrote: post #202

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

Same for me, except also the incredibly obtuse set of ~20 compiler pragmas you need in Haskell. If you ask for help to do some simple programming concept, like multiple dispatch based on type at runtime, then from the Haskell community you first get a bunch of tone deaf “you shouldn’t want to ever do that” responses, followed by a huge tome of all the language extensions (fundamentally changing or adding syntax) that you need.

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

#299

Post by Intermernet »

jodrellblank wrote: post #248
tigershark wrote: post #160

Earlier quoted context omitted.

There were people with 2k to 10k loc of experience in some language. That seems extremely low for any meaningful comparison and I would really hope that “average” programmers have way more experience than that... I think I was pretty junior after writing north of 100k loc and working on 1M loc projects. And for sure I don’t consider myself highly competent in F# after writing some thousands lines. I agree with the co…

When reading about APL recently, arcfide - the chap working on a GPU compiler - has expressed that he likes APL's terse code because you can throw it away and rewrite it without too much trouble. His compiler is around 750 lines of code after 6 years of development, but[1]: " If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In th…

That's the best example of why loc is the worst indicator of both work and talent available. Thanks!

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

#300

Post by celrod »

azov wrote: post #283

One big difference (which the article seems to mostly ignore) is that the shortest project was written by a single developer, while all others were a team effort. Having the whole project - design, architecture, all implementation details - in one head is not a trivial advantage. Even ignoring communication overhead, there might be subtle duplication of code simply because different people choose to do similar things…

These were different teams of students taking a class. Variance in student effort/quality is generally high.

There were two Rust teams. One had 3x the code and passed less tests than the other. This is our only reference for how much noise is owed to team rather than language; no other language was used by more than one team.

Python did best (least amount of code, yet also the most features) less because of Python, but more because the best programmer was using it.

Would the other students have been able to take advantage of the duck typing and metaprogramming in the same way, or ended up following different designs? I'd have my doubts about the second Rust team.

Although that Python allowed these is a feature, but I think we're really just looking at noise.

Post reply on HN