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

351–360 of 384 posts

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

#351

Post by boyter »

OnlyOneCannolo wrote: post #311
boyter wrote: post #207

Earlier quoted context omitted.

I actually lot ucc in the not so great categories. Counters like scc and Tokei are getting close to having the same accuracy as a compiler when it comes to code while being much faster. They are also support for more languages and are updated way more often. Very much second generation tools that learnt from the first.

Different tools for different use cases. Your use cases seem to prioritize language support, update frequency, and speed (what do you mean by the accuracy part?). For this, Scc and Tokei would of course be better than UCC. The (admittedly niche) use cases I described require understanding the counting rules very well, and keeping those rules stable. For this, scc and Tokei are as useless as anything else, while UCC d…

Have a look at the tests in scc and tokei. They support nested multiline comments, string escapes and other odd language features. As such both get very close to counting lines the way a full tokeniser used by the compiler or interpreter do making them very accurate.

I see your point. I’d argue however the rules for counting should be language rules not some higher level generic set.

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

#352

Post by mathgladiator »

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

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

#353

Post by tathougies »

foldr wrote: post #323
_fq4v wrote: post #318

Earlier quoted context omitted.

Record types are not a solution to the problem lens solves. Lens is a good library and a good concept. If we spent some time on it in programming class, most people would get it. When moving to non-Haskell languages, the lack of proper lenses is something I notice almost immediately.

I know what the lens library does - I write Haskell for my day job. In practice, the main reason people use it is to work around the deficiencies of Haskell's built-in record system: >I never built fclabels because I wanted people to use my software (maybe just a bit), but I wanted a nice solution for Haskell’s non-composable record labels.( http://fvisser.nl/post/2013/okt/11/why-i-dont-like-the-lens-... ) The other…

My biggest use case for lenses that I miss in other languages is the ability to interact with all elements of a collection, or elements in deeply nested collections.

For example, if I had a list of records with a field named 'categories' holding a list of objects with a field named 'tags', and I wanted to get all of these names in one list, without nested loops, lens makes it easy 'record ^.. categories . each . tags . each' or I could update them all, etc. It's just so easy to do this kind of data munging with lens that writing fors, whiles, etc in other languages is painful.

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

#354

Post by Thaxll »

StreamBright wrote: post #232
dymk wrote: post #224

Earlier quoted context omitted.

It's about as esoteric as somebody learning C++ for the first time. And from that perspective, it's totally normal for errors or syntax to be weird looking for a long time. Most of us, including myself, are biased towards languages like Java, C, C++, Javascript, because those are what we learn first - and so our expectations of what errors (or syntax) look like are shaped by our early experiences. So I don't think it…

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.

Rust errors are not all good, some of them are pretty bad like the "inferred type" ones.

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

#355

Post by rkrzr »

smallnamespace wrote: post #312
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…

> because that's what we started out with Yes, but not from programming, but from general life experience. Everyone knows what an actual dictionary is, and even non-programmers can easily grasp how a one-way 'map' works. Mutation is also how the real world works. If you want to record something, you write it down—you've just mutated the world, not encapsulated your operation in the WorldState monad. You need to build…

> Mutation is also how the real world works. If you want to record something, you write it down—you've just mutated the world, not encapsulated your operation in the WorldState monad.

But is it, though? Perhaps you just appended something to the world-log in a purely functional way. Time seems to always go in one direction (at least in my experience, YMMV), kind of like a DB primary key that is monotonously increasing. It really depends on how you look at this.

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

#356

Post by Ericson2314 »

garmaine wrote: post #237
aliceryhl wrote: post #228

Earlier quoted context omitted.

I mean, it seems like it was an university course, and writing a compiler from scratch is probably a decent exercise in a compiler course.

Restrict the students from using a parser library. I get that. But allowing nothing except that standard library? That’s stupid. It also makes the language comparison useless. Python has a standard library that is continuously improved and people reach to that when writing programs. Haskell, like C, ossified it’s standard library when it was created and people use the external packages for equivalent up to date libra…

Parsers are not the interesting parts of compilers.

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

#357

Post by rcxdude »

ncmncm wrote: 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?

I mean, they aren't. The ergonomics of sum types in C++ are terrible and are actually useful in far fewer situations than they are in nearly any other language which supports them.

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

#358

Post by OnlyOneCannolo »

boyter wrote: post #351
OnlyOneCannolo wrote: post #311

Earlier quoted context omitted.

Different tools for different use cases. Your use cases seem to prioritize language support, update frequency, and speed (what do you mean by the accuracy part?). For this, Scc and Tokei would of course be better than UCC. The (admittedly niche) use cases I described require understanding the counting rules very well, and keeping those rules stable. For this, scc and Tokei are as useless as anything else, while UCC d…

Have a look at the tests in scc and tokei. They support nested multiline comments, string escapes and other odd language features. As such both get very close to counting lines the way a full tokeniser used by the compiler or interpreter do making them very accurate. I see your point. I’d argue however the rules for counting should be language rules not some higher level generic set.

Ah, now I see what you mean by 'accuracy'.

Each language does have its own counting rules. There's a separate PDF for each one describing the rules for that language, which is the cool part.

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

#360

Post by shaklee3 »

jcora wrote: post #270
shaklee3 wrote: post #128

Earlier quoted context omitted.

C++ has had sum types for years, so I'm not sure why that was mentioned. If you aren't familiar/experienced with the language, then the comparison is not fair overall.

Yeah it's had everything for years. I'd rather shoot myself than use those features outside of a modern language where they aren't just bolted on along a billion other things.

That's not a useful comment. Would you rather they just kill the language instead of improving it?
Post reply on HN