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

311–320 of 384 posts

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

#311

Post by OnlyOneCannolo »

boyter wrote: post #207
OnlyOneCannolo wrote: post #95

Earlier quoted context omitted.

For anyone interested in this sort of thing, there's also Unified Code Count (UCC) [1]. It has a lot of interesting design goals like being open and explicit about the counting rules, which is really useful if you want to predict things like cost and reliability. [1] https://csse.usc.edu/ucc_new/wordpress/

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 does exactly what's needed.

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

#312

Post by smallnamespace »

dymk wrote: post #244
sbergot wrote: post #231

Earlier quoted context omitted.

I didn't say Haskell's error messages are bad. If you stick with explicit types on your functions and no language extension they are absolutely great. I wanted to point out that type checking errors with lens are hard unless you really know how all the different type aliases relate to each other. It was a few years ago so maybe things are better. C++ also had this problem with the standard containers. However it is m…

> 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 a pile of mathematical abstractions in your head before you can really get off the ground with lenses. Not everyone has that aptitude or interest.

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

#313

Post by mruts »

snazz wrote: post #295
mruts wrote: post #282

Earlier quoted context omitted.

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?

Python has Lists (arrays), Dict, and Sets. That's pretty much it.

There's no linked lists. There's no sorted maps, no sorted sets, no maps that preserve insertion order, no queues, no priority queues, no bitsets. And there's no immutable collection in Python besides strings.

Meanwhile, Scala has all of that and more: https://docs.scala-lang.org/overviews/collections/overview.h...

Moreover, scala has synchronized collections that can work over multiple threads. I guess all collections work that way in Python, but that's because Python doesn't even support true thread parallelism in the first place!

Also, if we're talking about the number of methods on the collections, Scala has way way more. map/foreach/filter/foldl/foldr/option/drop/take/first/last etc etc.

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

#314

Post by foldr »

0xab wrote: post #308
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.

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…

Yeah, so it's a less good way of accessing record fields than the one present in 99% of other programming languages. Your own description makes this plain. Let's compare to Javascript:

* I don't need to import a module to make available the syntax for getting and setting fields of an object.

* I can use the same syntax for any object, and don't have to worry about doing a bunch of code generation via a badly-designed metaprogramming hack.

* I don't have to worry about adding prefixes to all my field names.

* The syntax uses familiar operators that I won't have to look up again on hackage if I stop writing Javascript for a few months.

* No-one modifying my code can get "clever" and use one of ~50 obscure and unnecessary operators to save a couple of lines of code.

What bugs me is when Haskell advocates try to use all the additional esoteric features of the lens library as an excuse for this fundamental baseline crappiness.

Haskell really just needs proper support for record types. Then people could use lenses when they actually need lenses (never?). At the moment, they're using lenses because they want something that looks almost like a sane syntax for record updates.

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

#315

Post by [deleted] »

galaxyLogic wrote: post #97
zmmmmm wrote: post #82

Earlier quoted context omitted.

Seems like a bit of a bold claim when the author themselves directly contradicts that in their own conclusion: > I think my overall takeaway is that design decisions make a much larger difference than the language After all, Scala was 0.7x the size and is one of the most strongly statically typed languages. So you could almost invert your conclusion and say the big result is "Python only saved 20% code lines over ful…

No I would not reach quite that conclusion I would say "Python saved 20% code lines over Scala!". The results say something about the greatness of Scala, not of statically typed languages in general. The other ones did not do quite as good as Scala. From what little Scala I've read it looks very terse indeed. That can be a benefit but at the same time makes it harder to understand code written in it, in my opinion.

[deleted]

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

#316

Post by trishume »

davemp wrote: post #307
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. :)

Nope undergrad. UWaterloo just has a special co-op program that extends the degree and fits in six four-month internships in alternating school and work, for a total of two years of work experience by graduation.

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

#317

Post by vedantroy »

ginnungagap wrote: post #301
jodrellblank wrote: post #248

Earlier quoted context omitted.

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

https://github.com/Co-dfns/Co-dfns

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

#318

Post by _fq4v »

foldr wrote: post #314
0xab wrote: post #308

Earlier quoted context omitted.

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…

Yeah, so it's a less good way of accessing record fields than the one present in 99% of other programming languages. Your own description makes this plain. Let's compare to Javascript: * I don't need to import a module to make available the syntax for getting and setting fields of an object. * I can use the same syntax for any object, and don't have to worry about doing a bunch of code generation via a badly-designed…

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.

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

#319

Post by tathougies »

tomasato wrote: post #103
steveklabnik wrote: post #43

Earlier quoted context omitted.

My understanding is that in production compilers, hand rolled parsers are the norm. Parsing libraries are cool, but just aren’t used for big projects.

Excluding the lens library (as per the article) is unusual, it provides natural getter/setter and row polymorphism type functionality. More anecdotally, I’d argue parsing libraries are common, just look at the prevalence of attoparsec and others. But most parsing libraries in the ecosystem are parser combinator libraries which don’t support as performance and nice error messages that compilers need

I dunno, libraries like earley in Haskell, provide pretty nice error messages.

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

#320

Post by tathougies »

mlthoughts2018 wrote: post #298
sbergot wrote: post #220

Earlier quoted context omitted.

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…

With the exception of very few extensions that I've never seen used in practice, Haskell language extensions are mutually compatible and create a language that is a strict superset of the old language. In this sense, I'm not sure how they're much different than the --c++=14 flag in GCC.
Post reply on HN