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

361–370 of 384 posts

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

#361

Post by sanityinc »

exceptione wrote: post #302
k_bx wrote: post #245

Earlier quoted context omitted.

I disagree about lens. My new projects don't use them in main code-base and it was a great decision: - TAGS work like a charm to access field definitions - compile times are ok Of course, if library's API needs lens, they're used.

What do you mean with TAGS?

Presumably etags/gtags/hasktags etc., ie. having built a TAGS database for such a helper program, you can use it in an editor to jump from a field name to its definition. That wouldn't be the case with a lens accessor.

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

#362

Post by FullyFunctional »

rjayatilleka wrote: post #137
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…

Could you clarify what you mean by "don't abstract idioms?"

One example (taken from the real world):

   addr = (addr + PAGESIZE - 1) & ~PAGESIZE;
contrast with

   addr = P2ALIGN(addr);
The former is idiomatic and immediately readable. For the latter I have to go lookup the definition of P2ALIGN (and make sure I got the one actually used as there may be multiple!), check that it does what I expect, and memorize it.

The value of abstracting the idiom is debatable. If it _is_ used sufficiently often, then it might be worthwhile, but often it isn't.

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

#363

Post by runeks »

mathgladiator wrote: post #352
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…

As I have aged, I have learned that duplication of code can become a feature in terms of building redundancy inside of teams. This is one of the reason that "enterprise code" really sucks, but the people turn-over and need to transfer knowledge over generations is more important than minimalism and the power of individuals (sadly).

> […] I have learned that duplication of code can become a feature in terms of building redundancy inside of teams.

Could you elaborate on how this works?

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

#364

Post by k_bx »

exceptione wrote: post #302
k_bx wrote: post #245

Earlier quoted context omitted.

I disagree about lens. My new projects don't use them in main code-base and it was a great decision: - TAGS work like a charm to access field definitions - compile times are ok Of course, if library's API needs lens, they're used.

What do you mean with TAGS?

File named TAGS generated from hasktags (in case of Haskell) that gives you an easy way to "jump to definition" from Emacs or other editors. Good way to navigate codebases even if you don't know how to build them.

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

#365

Post by pkilgore »

jwm4 wrote: post #135

Prohibition was an extremist political movement. Widespread public rejection of it, in the form of stills, speakeasy and other means proved it to be a law without public sopport, resulting in its repeal within 10 years - an absolute public rejection of a limit unsought by the majority. OP pov has zero basis in fact.

Am I.... Missing something?

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

#367

Post by esarbe »

galaxyLogic wrote: post #133
zmmmmm wrote: post #118

Earlier quoted context omitted.

I think most people would consider 20% basically within the margin of error induced by stylistic and other non-meaningful differences. For example, it's not completely clear from the post but it seems like the 0.5x figure is from wc -l, which means Python wins a line every time there is a conditional or loop just because it doesn't need a closing brace. That alone might eat up a lot of the 20%, but you would be hard…

My surprise from this study was simply that dynamic languages are clearly not much worse than the best-of-breed statically typed languages. Maybe 20% is within the margin or error, but you definitely can't take that as any evidence that Scala is "better" than Python. The reason I think this is "big big news" is I thought the general consensus had already been reached in academia if not the programming community that…

I don't know where you get that. This is about code base size. Dynamically typed languages have always had fewer LOC than statically typed languages.

If there's a surprise, it's that Scala is able to snuggle up to Python so nicely, while being one of most strongly typed languages.

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

#368

Post by nybble41 »

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…

> Yet a 750 loc codebase sounds like someone with very little experience and a few days or a long weekend.

For the purpose of evaluating experience you count the total amount of code written, not the final codebase size. Four million lines of code is a fair bit of experience in any language, even if most of those lines were later deleted or replaced.

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

#369

Post by nybble41 »

sonnyblarney wrote: post #177
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…

"that it takes considerable time and effort to come up with the right set of types. " I've written once here before, this is one of the 'accidental advantages' of TypeScript: you set the compiler 'loose' when you're hacking away, writing quickly, and then 'make it more strict' as you start to consolidate your classes. I almost don't bother to type something until I have to. Once I see it sitting there for a while, an…

You can do that in Haskell also. Just turn on the -fdefer-type-errors GHC option and leave out most of the type signatures. Any expression with a type error will be reported when/if the expression is evaluated at runtime. You'll probably still need a few type hints, to avoid ambiguity, but otherwise it's not that different from programming in a dynamically-typed language.

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

#370

Post by [deleted] »

runeks wrote: post #254
orbifold wrote: post #235

Earlier quoted context omitted.

That's a total stretch, lens is not used in GHC for example and lots of other smaller compilers written in Haskell. It is used in Ermine but that is stuck in a semi complete state for a while now and Ekmett has moved on.

I second this. I’ve written tens of thousands of lines of Haskell, and I’ve never used lens . Also, putting it in the same category as text and vector doesn’t make sense — these are indeed unavoidable, and practically all my projects use them.

[deleted]
Post reply on HN