Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml • Hacker News Board

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

#301

Post by ginnungagap » Sun, Jun 16, 2019, 2:32 PM UTC

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…

The github link in [1] is dead, where is the repo now? I was curious about that compiler

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

#302

Post by exceptione » Sun, Jun 16, 2019, 2:39 PM UTC

k_bx wrote: post #245

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…

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?

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

#303

Post by floatboth » Sun, Jun 16, 2019, 2:58 PM UTC

grumdan wrote: post #258

fnord123 wrote: post #249

Earlier quoted context omitted.

>two relatively used languages Relative to what? Haskell and OCaml are important languages for PLT but not in the context of "production", or as I understood "production" to mean: shipping products with features. To call them anything but niche players in this context is not accurate in my opinion.

As in, there are a handful of large projects the languages are used for. For Haskell, Facebook's spam detection system, Sigma[1], comes to mind, along with some use by banks (Standard Chartered); then there's a bunch of smaller places using Haskell (Wire, a secure messaging app, like Signal; Galois, a US defense contractor doing software verification and related things) plus some open-source tools like pandoc. I know…

Facebook's static analyzer Infer https://fbinfer.com is written in OCaml.

There's a lot of OCaml in the program verification space: https://frama-c.com http://why3.lri.fr https://alt-ergo.ocamlpro.com

And for mysterious reasons, OCaml is now kinda popular for.. web frontends. Bloomberg created an OCaml-to-JS compiler https://bucklescript.github.io and Facebook (again!) created an alternative syntax https://reasonml.github.io and this combination is apparently a new hipster way of writing web apps.

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

#304

Post by jodrellblank » Sun, Jun 16, 2019, 3:00 PM UTC

ncmncm wrote: post #46

akhilcacharya wrote: post #19

Loved this part and thought it was hysterical - > Since my team had all interned at Jane Street the other language we considered using was OCaml, we decided on Rust but I was curious about how OCaml might have turned out so I talked to someone else I knew had interned at Jane Street and they indeed did their compiler in OCaml with two other former Jane Street interns. Relatedly this is why I get annoyed at people tha…

In the 90's, the Swedish Ericsson and German Siemens companies participated in a joint (crash) project. Each sent 250 engineers. After six months, they delivered. A friend counted up lines of code written by each engineer, at the end. Fully half the code in the final product was written by one person: N lines by him, N lines by the other 499 people. He was a lead programmer, who issued two-week assignments to other e…

Price's Law - that the square root of the number of people in an organization do half the work - predicts that about 22 people should have done half of it, regardless of anything about 10x engineers.

It also predicts that the N lines by the remaining people would be half done by about 22 of them and half done by 4xx of them; I wonder if that pattern was seen?

Even if the original engineer was 10x as productive, that would leave 12 people doing half of it, not 1. It makes me think that if the average team worked twenty days a month for six months the project should have been 60,000 units of goodness, and if he was as productive as all of them, 120,000 units of goodness. If, instead, he wrote rushed low-quality code, they spent a week trying to untangle and integrate with it, then he ignored their work and rewrote it himself, demoralizing the team and refusing to play nice with them, it might have reduced the overall units of goodness way below what it could have been. And at the same time he gets the boost of writing it all himself his way and not having to care about making it stable for others to work on, so he looks disproportionately better for that as well. What did the other team members say about it? What happened to the project after?

> He was a lead programmer, who issued two-week assignments to other engineers

You ought to expect a lead programmer to be better, otherwise why would they get and deserve that position? You'd also expect a leader to be way better than assigning work people can't complete, not working with them, not stopping doing that, then taking over from them. What would a 10x exceptional leader who wasn't a worker, get out of a team of 500 average workers?

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

#305

Post by agentultra » Sun, Jun 16, 2019, 3:03 PM UTC

Avamander wrote: post #275

dymk wrote: post #236

Earlier quoted context omitted.

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.

Some C++ has horrific messages, new compilers do a much better job at complaining about most errors - some even suggest fixes. I don't remember seeing Haskell doing that.

Haskell does do that. It provides suggestions and alternatives: you probably meant X or you forgot an import to Y or try enabling the Z extension.

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

#306

Post by galaxyLogic » Sun, Jun 16, 2019, 3:10 PM UTC

roca wrote: post #174

galaxyLogic wrote: post #169

Earlier quoted context omitted.

> 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.

I don't think "change" is a good reason not to write them down. I think I'd rather have them written down so I have a history of those changes.

Good point. Keep them under version control.

What I'm trying to think about is that in a language that requires you to write the types down they have to be always written down correctly. So if you have to change the types you use or something about them you may have a lot of work to do because not only do you have to rewrite the types you will also have to rewrite all code that uses those types.

That does allow you to catch many errors but it can also mean a lot of extra work. The limitation is that types and executable code must always agree.

Whereas in a dynamic language you might have some parts of your program that would not even compile as such, if you used a compiler, but you don't care because you are currently focusing on another part of your program.

You want to test it fast to get fast feedback without having to make sure all parts of your program comply with the current version of your types.

A metaphor here could be something like trying to furnish a house trying out different color curtains in one room. In a statically typed language you could not see how they look and feel until all rooms have curtains of the same new color, until they all follow the same type type-constraints.

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

#307

Post by davemp » Sun, Jun 16, 2019, 3:14 PM UTC

wjw94 wrote: post #201

My take-away from this article is that the university I graduated from was terrible

I assume OP is in grad school. I took a few grad classes during my undergrad and the difference was night and day (teaching and cohort). So maybe your school was fine and you were just in the wrong classes. :)

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

#308

Post by 0xab » Sun, Jun 16, 2019, 3:18 PM UTC

foldr wrote: post #267

dymk wrote: post #244

Earlier quoted context omitted.

> However it is much easier to get what is a dictionary compared to a random "optic". This is exactly what I disagree with. We come from a prior understanding of mutable/imperative dictionary/shared_ptr/std::pair, because that's what we started out with. Had we been initially been trained on monads, functors, lenses, those would be the familiar tools, and we'd go "Huh, that's an... interesting way to write code" when…

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.

If you use lens as just a way to access records like you do in other languages, then there is absolutely nothing hard about it. Literally all you need to know is:

Name your records like "data Prefix = Prefix { prefixFieldName :: ... }" call "makeFields ''Prefix" once at the bottom of your file and use "obj ^. fieldName" to access and "obj & fieldName .~ value" to set.

That's it. You now have 100% of the capabilities of record update in any other language. This doesn't get any simpler in any other language. It even pretty much looks like what you would do in other languages.

I'll grant you, Haskell and lens do a terrible job of explaining subsets of functionality that are simple and let you get the job done before jumping in the deep end.

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

#309

Post by tanin » Sun, Jun 16, 2019, 3:24 PM UTC

nindalf wrote: post #199

tanin wrote: 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 arc…

> But don't mischaracterise python's standard library.

My main point is Ruby's stdlib is richer than Python's.

(And that's not either better or worse. Some people prefer lighter stdlib, and that's fine.)

> If you don't want to write 19 characters to find the first item in a list, pick another language.

Yes, if Python supported `.first`, I wouldn't want to write the longer version of it.

Since the article focuses on brevity, I did propose another language here, which was Ruby. It would serve better at how succinct a dynamic-typed language can be because of its richer stdlib, especially when we compare a dynamic-typed lang with Scala, which has an extremely rich stdlib. Using Ruby would be a fairer comparison.

I gave one small example (`.first` vs `a[0] if a else None`) to illustrate my claim. Two more examples (from https://ruby-doc.org/core-2.4.1/Array.html) are `.rotate` and `.transpose`. I'm sure there are more examples around Hash and other data structures.

Python don't have these methods, and we have to make them ourselves. To make code even longer, we need to maintain and write unit tests on them.

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

#310

Post by galaxyLogic » Sun, Jun 16, 2019, 3:25 PM UTC

zapzupnz wrote: post #218

tanin wrote: post #154

Earlier quoted context omitted.

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.

I would agree that the sample size was small so programmer competency may be a big factor.

The interesting takeaway from this study I think is that it does not show that statically typed (even "pure") functional languages are not obviously better than plain old Python.

The interesting thing is not what this study proves, but what it does not prove.